Video channel

Los requisitos de baja calidad constituyen una de las principales causas de fracasos en proyectos de ingeniería, indiferentemente del sector de actividad. Las formulaciones ambiguas y a las que les falta claridad, los requisitos contradictorios o la incoherencia de unidades de medida son algunos ejemplos de los numerosos errores que puedan ocurrir durante la documentación de requisitos.

Este webinar introduce al uso de herramientas y técnicas que permiten detectar desde las primeras fases de proyectos las fuentes de errores, con el fin de eliminar esos errores en los requisitos y aumentar así la probabilidad de éxito de estos mismos. Todos esos aspectos fundamentales de la calidad de requisitos están cubiertos por una instalación por defecto de las herramientas RQA – Quality Studio y RAT – Authoring Tools.

Anforderungen von niedrigerer Qualität stellen eine der wichtigsten Ursachen dar, warum technische Projekte scheitern, egal welche Branche man betrachtet. Mehrdeutige und an Klarheit mangelnde Formulierungen, widersprüchliche Anforderungen und Inkohärenz in den verwendeten Messeinheiten sind einige Beispiele von den zahlreichen Fehlern, die in der Ausfertigung von Anforderungen eintreten können.

Dieses Webinar leitet die Benutzung von Anwendungen und Praktiken ein, die das Feststellen von Fehlerquellen zu Beginn des Projekts erlauben, um die daraus resultierende Fehler in den Anforderungen zu beseitigen und damit die Erfolgswahrscheinlichkeit Ihres Projekts deutlich zu erhöhen. Alle diese grundlegende Aspekte der Qualität von Anforderungen werden von der Standardkonfiguration unserer Werkzeuge RQA – Quality Studio und RAT – Authoring Tools abgedeckt.

System requirements are usually written in unconstrained natural language (NL), which is inherently imprecise. Often, requirements authors are not trained in how to write requirements. During system development, requirements problems propagate to lower levels. This creates unnecessary volatility and risk, impacting programmed schedule and cost.

The Easy Approach to Requirements Syntax (EARS) is a mechanism to gently constrain NL requirements. The EARS patterns provide a lightweight, structured guidance that enable authors to write high quality textual requirements. EARS reduces or even eliminates common problems found in NL requirements.

This webinar will give an overview of the key concepts of EARS and provide examples of EARS requirements.

The practical block will show how the RAT – Authoring Tools has implemented the EARS patterns, making it possible to integrate in any Requirements Management System

Krav med låg kvalitet är en av de främsta orsakerna som leder till misslyckade projekt och studier visar på att så mycket som 15% av ett projekts totala kostnad kan härledas till undermålig eller konstant föränderlig kravbild. Oklara och tvetydiga krav, motstridiga krav eller inkonsekventa kravspecifikationer är bara några exempel på de dussintals fel som är mycket vanliga i alla projekt.

Detta webinar introducerar verktyg för att tidigt upptäcka dessa problemkällor och visar på en uppsättning grundläggande tekniker för att övervinna dem och enkelt skriva krav med hög kvalitet. Alla dessa grundläggande aspekter av kravkvalitet täcks med en standardinstallation av verktygen RQA – Quality Studio och RAT – Authoring Tools. Du kan gå från en kravbild med en massa felaktigheter till en komplett kravbild med få överlapp, motstridigheter eller rena felaktigheter på mycket kort tid och med minimal arbetsinsats. Det bästa av allt är kanske ändå att du sedan kan återbruka din kunskap och slipper därmed göra om dina misstag i efterföljande projekt.

Les exigences de mauvaise qualité constituent l’une des principales raisons d’échec des projets d’ingénierie, quel que soit le secteur d’activité. Les formulations ambiguës et manquant de clarté, les exigences contradictoires ou l’incohérence dans les unités de mesures sont quelques exemples parmi les nombreuses erreurs qui peuvent se produire lors de la documentation d’exigences.

Ce webinaire introduit à l’utilisation des outils ainsi qu’aux techniques permettant de détecter dès les premières phases de projets les sources d’erreurs, dans le but d’éliminer ces erreurs dans les exigences et d’augmenter ainsi la probabilité de succès des projets. Tous ces aspects fondamentaux de la qualité des exigences sont couverts par le biais d’une installation par défaut des outils RQA – Quality Studio et RAT – Authoring Tools.

Have you ever dealt with the European Space Agency (ESA)? If so, you must now know how well-written their tender documents are, and how clear and unambiguous the ESA standards are.

In this webinar we’ll present the rules and recommendations described both in the ECSS Drafting rules (ECSS-D-00-01) and in the ECSS-E-ST-10-06C. Furthermore, we’ll also show how the RAT – Authoring Tool implements all these rules so that meeting all these recommendations can be done effortlessly.

While the guide is a worldwide broadly used and recognized reference for requirement engineers, its implementation still poses many challenges. For example, the fact that requirements can be expressed at different levels of abstraction, the components addressed by those requirements are not equally critical and a requirement document might contain requirements of different types or levels. Additionally, because the guide is extremely complete, the implementation of these rules in a single step turns out to be very complex, especially when considering the different skills of different team members, not to mention the amount of effort for the manual inspection of such a large number of quality rules.

The proposed solution is based on the gradual implementation of sets of incrementally demanding quality rules that could address different levels of abstraction and criticality, as well as the different skills of the engineers. Besides, the approach is aiming not only at the quality inspection but mainly at the authoring stage, thus reducing rework and enhancing reusability while boosting the performance of the requirements engineering teams. Requirements patterns (or boilerplates) represent another key factor guaranteeing structural consistency among requirements, while enabling uniformity of structure and content (based on domain-specific dictionaries). This solution is unachievable without a proper set of tools so, a technical solution to the aforementioned challenges will be presented during the meeting.

Low requirements quality is one of the main reasons that lead to unsuccessful projects in any engineering domain. Unclear and ambiguous statements, contradictory requirements or inconsistent measures are just a few examples of the dozens of errors that are very common to happen in requirements specifications. This webinar introduces the tools to early detect these sources of problems and provides with a set of basic techniques to overcome them, so an error-free requirements specification leads to achieving successful projects. All these basic aspects of requirements quality will be covered using a default installation of the tools RQA - Quality Analyzer and RAT - Authoring Tools.

RAT - Authoring Tools providing real-time CCC assessment and consistency with the underlying model.
The seamless integration of textual Requirements within MBSE is a challenge in today’s Systems Engineering state of the art. Requirements are usually elaborated using natural language text and hence provide high expressivity and easiness of production and management. MBSE offers well-structured methodologies (like ARCADIA, OOSE, Systematica (S*), etc.) and a rigorous path for developing high-quality designs, but they demand steep learning curves.

This webinar presents an add-on to Capella that follows all the principles and features of the RAT - Authoring Tools on top of Requirements Modeling Tools (RMS), but now on top of a Modeling tool like Capella; thus enhancing a seamless consistency between textual requirements and models (model requirements).

The webinar will include a demo of this new add-on, showing the following features:

- Assisted authoring of requirements through pattern-based auto-completion
- Real-time quality assessment
- Maintenance of relations between textual and model-based requirements, and capitalization of links for change tracking
- Synchronization of textual requirements: a round-trip approach between Capella and other external Requirements Management Systems

What is the value of good requirements? We have all heard for years now, for instance from the chaos report (https://www.projectsmart.co.uk/white-papers/chaos-report.pdf), that changing or unclear requirements cause big problems for projects and organizations. But, what’s the value if this chaos?

The REUSE Company has developed a method based on the Constructive Systems Engineering Cost Model (COSYMO) to calculate the possible economic upside of having an effective and efficient requirements engineering process.

The COSYSMO model was created by Ricardo Valerdi while at the University of Southern California Center for Software Engineering. It gives an estimate of the number of person-months it will take to staff systems engineering resources on hardware and software projects. Initially developed in 2002, the model now contains a calibration data set of more than 50 projects provided by major aerospace and defense companies such as Raytheon, Northrop Grumman, Lockheed Martin, SAIC, General Dynamics, and BAE Systems.

In this webinar we will look into the findings when we run a development project using requirements with a high vs. low degree of requirements understanding and what the economic benefits would be when using the INCOSE guide of writing requirements “for real” with our state-of-the-art Systems Engineering Suite, offering you the tools, processes and skills to properly tackle the daily issues of complex systems. This with the benefits of increased quality, saved development effort and money.

The ISO 15288 clearly defines what must be done when performing Verification and Validation processes. We must use and manage verification actions and collect evidences. But how should we do it? How to integrate them all in one environment? How to delegate V&V to specialized tools for specific work-products? How to deal with interoperability? This webinar intends to provide insight for these kind of questions.

Current systems engineering makes clear distinction between verification, validation and quality assurance processes. Verification is usually connected with the notion of “developing the system right” (setting the focus on performing SE properly). On the other hand, validation is described as “developing the right system,” making a SOI that meets the stakeholders needs. Both concepts are connected with the notion of quality assurance and management. Verification confirms that the quality is adequate, and Validation confirms that the system maps with correct functions and properties, as a kind of quality issue. Quality Assurance, when applied to product evaluations, helps to prevent incidents and problems. As part of its knowledge reuse approach, The Reuse Company has created the V&V Studio as a software tool ready to provide support to the ISO15288 V&V processes by using (and reusing) information from RQA - QUALITY Studio and the Ontology. The V&V Studio merges the three concepts (Verification, Validation and Quality) and offers V&V by managing the corresponding verification and validation actions through quality and other measures. It uses the concept of metrics and quality functions to verify all kinds of work-products, as well as providing evidences management.

Since 1995 to the 2016 last version, NASA publishes the “NASA Systems Engineering Handbook” (https://www.nasa.gov/connect/ebooks/nasa-systems-engineering-handbook) to bring the fundamental concepts and techniques of NASA Systems Engineering as a discipline at NASA body of knowledge. This handbook offers guidance for current best Agency practices and maintains the alignment of the Handbook with the Agency’s systems engineering policy. The handbook is considered as top-level guidance for good systems engineering practices in the space industry.

We have developed a knowledge library, to be used on our SE Suite, that takes the benefits of the NASA handbook body of knowledge to enhance the quality of requirements. This NASA domain knowledge library includes glossary, acronyms, abbreviations, as well as specific taxonomies, hierarchies, and terms relationships. It also brings guidance for well-formed requirements through rules and patterns. The library incorporates a set of metrics, based on NASA handbook guidance. These metrics implemented in our SE Suite help to ensure the quality of requirements and to optimize the requirements authoring process.

Discover in this webinar how our SE Suite, along with this NASA knowledge library we have developed, can improve the quality of your organization requirement as well as your requirement authoring and checking process. Thanks to this approach, your organization could discover requirements errors in an early stage of the process, to prevent adding potentially huge extra costs and time to market delays to your organization projects.

INCOSE, the International Council on Systems Engineering has done an excellent job in the dissemination of best practices and guides towards the Systems Engineering Community. A wonderful example of this kind of guide is the INCOSE Guide for Writing Requirements (GfWR) that is helping engineers meet the challenging quality standards that every requirement shall have, especially in the Safety Critical disciplines.

While other standards just define a number of nice-to-have, but yet very abstract set of quality characteristics, the INCOSE GfWR also includes a number of comprehensible, and SMART (specific, measurable and easy to automatize), set of quality rules for requirements and for requirements documents.

No matter what tool you use to manage your requirements, RQA - QUALITY Studio and RAT - Authoring Tools from The REUSE Company offer an easy-to-use library including the quality rules described in the GfWR; allowing both quality control of your existing documents, and real-time help during the authoring stage of the requirements. Writing high-quality requirements has never been so easy.

The use of patterns to write structured requirements is strongly recommended in Requirements Engineering in order to avoid defects in engineering systems development that are mainly traced back to unprecise, unclear, or incomplete requirements.

Since the 1990s, the members of the SOPHIST GmbH (usually called “The Sophists”) have been in the forefront of consulting and training services in the area of requirements engineering. The Sophist patterns comprise both functional and non-functional requirement patterns, as well as patterns to express conditions and properties of systems.

The objective of this webinar is to introduce you to the newly integrated Sophist patterns into our RAT - Authoring Tools, with examples of real-time writing assistance enabled by the tool in order to check the compliance with the structure of the selected pattern.

In the world of systems engineering, the importance of having high quality requirements is well known and that is why there are standards and guidelines that establish the characteristics that the requirements must have for considering them of good quality.

To obtain quality measurements of the requirements it is common to use quantitative quality metrics based on established standards. However, the risk is to build assessment methods and tools that are both arbitrary and rigid in the parameterization and combination of metrics. This webinar is focused on the presentation of a flexible method to assess and improve the quality of requirements that can be easily adapted to different contexts, projects, organizations and quality standards, with a high degree of automation.

In the method proposed, the domain experts contribute with an initial set of requirements that they have classified according to their quality, and their quality metrics are extracted. Then machine learning techniques are used to emulate the implicit expert’s quality function. A procedure to suggest least-effort improvements in bad requirements is also provided.

The method is easily tailorable to different contexts, different styles to write requirements, and different demands in quality. The whole process of inferring and applying the quality rules adapted to each organization is highly automated.

Upon landing in Mexico, Conquistador Hernán Cortés famously ordered his men to “burn the boats”. For the same reasons, our journey towards Model Based System Engineering (MBSE) will require the burning of the specification “document boats” used to house and transport the most important artifacts; i.e. the declarations of Stakeholder Needs and System Requirements. No doubt, prior to burning the boats, Cortés had to commit to benefits great enough to obtain the resources required to succeed. Analogous planning must be done to embark on a MBSE expedition that includes transformations in Requirements Management. To this end, this presentation will offer a benefits analysis and realization plan (in the form of a metamodel & tool demo) that may be useful in planning your MBSE expedition.

Traceability is a core activity within the System Development Lifecycle, although a tedious and time-consuming task, especially when the traces involve items coming from different disciplines and tools. Therefore, teams must be provided with tools that allow connection to heterogeneous environments, allowing easy access to the definition of traces, management of traceability matrices and impact analysis, and providing also smart analysis tools to suggest missing traces and suspect links. Finally, all this information must be exported in a flexible, and easy-to-understand yet accurate way.

In this webinar, The REUSE Company will present the first version of its brand new tool TRACEABILITY Studio. This tool, fully integrated with the Systems Engineering Suite, provides an easy-to-use answer to all the challenges mentioned above so that traceability management thus increasing the level of quality of your projects, minimizing the impact of changes and reducing the overall time normally devoted to this activity.

In this era of Lean and Agile principles we tend to focus on collaboration, team cohesion and customer value, so where do requirements come in and how can focused requirements engineering contribute to increased customer satisfaction? It does not matter what type of engineering principles you stick to, if you do all the work in a single team, larger organisation or let someone else deliver the product or service, it all comes down to the same issues of understanding the need and delivering a solution to it.

This webinar will show how requirements are the mean to the end of achieving increased customer satisfaction and the key is a changed view on the importance of requirements being the messenger between all stakeholders.



Topics:
Customer satisfaction is a phrase often used and perhaps misused. When a customer is dissatisfied, what are the reasons? We will look more into this and discuss the view of quality and how high quality can be expressed and eventually be achieved?

After disseminating customer satisfaction, we continue with the different components of human understanding. What does it mean if stakeholders don’t understand each other and what consequences can be drawn out of that?

The third and last topic for the webinar will be to discuss the concept of requirement quality. What is requirements quality? How can one achieve a high degree of requirements quality? We will also briefly look into why requirements review as it is performed today is an inefficient habit just providing the organisation a faulty sense of security without achieving the original goal to increase the information quality.

After the seminar you will have a much clearer view on how to Increase the level of satisfaction by your customers. To share a true mutual understanding on both the customer need and the proposed solution is the end goal and the key is to increase the quality of the requirements.

ECSS - European Cooperation for Space Standardization- represents a set of standards aiming to gain a common understanding across the space industry in Europe. ECSS released the ECSS-E-ST-10-06C (6 March 2009) to provide some guidelines for the development of technical requirements specifications.

The REUSE Company has developed a Knowledge Library coping with the ECSS standard (among others within the ECSS) to guide requirements writers writing high-quality requirements and provide help during the long-lasting requirements inspections, those making easier the compliance with the ECSS standards. This Knowledge Library is part of the SES Suite (Systems Engineering Suite), managed by our tool Knowledge Library (including glossaries, taxonomies of terms, taxonomies of types of requirements, requirements patterns and requirements quality rules).

Ambiguity is a factor that can jeopardize the optimal development of a project, as decisions over the requirements statement are made subjectively. And luckily this aspect can be under control if we apply Systems Engineering centred on Knowledge and Quality to develop better assets of information during the project lifecycle. There are four main aspects that aids KCSE (Knowledge Centric Systems Engineering) implementation within an organization:
- Discovering Information in Requirements Documents
- Controlled information to unify requirements interpretation
- Identifying weaknesses and challenges in requirements documents
- Building up the Knowledge Base or Ontology
Verification analysis: Smarter and Quicker

Requirements are, with no doubts, the main source of re-work in both software and systems intensive projects. This webinar introduces these sources of problems and misunderstanding, and provides a set of basic tricks and techniques to overcome the problems and provide error-free requirements specifications to properly set the roots of successful projects. All these basic aspects of requirements quality will be covered using a default installation of the tools VERIFICATION Studio and the Rich Authoring Tool.

Competition in a fair and transparent manner is the heart of procurement, that is why you probably already have a process in place to ensure the legal aspects of Fairness, Integrity and Transparency through the competition.

But what about the two other corner stones and key guiding principles of Economy and Effectiveness, and not least the principle of Best value for money?

The Procurement Quality Suite (PQS) guarantees that the purchasing body is conducting the procurement process with maximum effectiveness in relation to the overall budget, and that the principle of Best value for money is indisputably and crystal clear from the initiation of the procurement project, through requirements definition, strategy selection and finally, bid evaluation and selection.

PQS consists is an application on using the well proven System Engineering Suite from The REUSE Company and its components. It includes:

A procurement library with the common procurement and bidding terms and acronyms
A set of metrics and rules which makes sure that your bidding documentation becomes complete and is correct and formulated in a consistent way.
A set of templates for developing different bidding documents; technical specification, Statement of Work and support specifications.
A method handbook
Another unique aspect of this suite is its full support for managing the system life cycle perspective, ensuring a complete technical description and the possibility to evaluate and compare the total cost of the system life cycle.

The methodology handbook depicts a set of tailorable processes and methods to suite your specific needs.

A recent blog post by our esteemed colleague Christer Fröling has sparked a tidal wave of interest and his paper “NLP beats DXL (DOORS scripting) every day of the week” has been distributed widely. But can his claim be substantiated?

Dr. Simon Wright will investigate this claim during a webinar and examine the evidence. As someone who has been involved in improving requirements quality for over 20 years and as a DXL programmer for over 10 years he is ideally placed to referee this match, DXL verses NLP.

During the webinar he will briefly review the development of Requirements Quality Tools and draw out the salient features that are needed to effectively and efficiently undertake NLP. He will explain the differences between textural analysis, syntax checking, semantic checking, correctness, completeness and consistency, with simple examples, and seek to match the desired functionality onto the available solutions.

In the world of Model-Based Systems Engineering, we usually find a huge ecosystem full of tools. The community of practitioners will be using a wide variety of different tools for Requirements Management, Logical and Physical Modelling, Traceability, Simulation, Quality Management etc.

With regard to Quality Management, System Quality Analyzer (SQA) performs requirements quality assessment based on the Correctness, Completeness & Consistency (CCC) approach, that is, automatic verification of your requirements and support to requirements authoring. For this purpose, the SQA knowledge base (ontology) can be customized to automatically include -in real-time- the content of Rhapsody models or Simulink files or even external ontologies created with Protégé, among others, so that requirements quality can be assessed against all those models.

In addition to that, the knowledge about a project is a living entity, that means that it will evolve (hopefully) along the project lifecycle. An Ontology Configuration Management process will be presented to keep track of the changes performed on the ontology.

Model-Based (MBSE) is the current trend in regard to Systems Engineering, leveraging testing and simulation activities. However, it’s also clear that textual requirements will remain in the scene since they are also key for testing, certification, and communication with other stakeholders.

This Webinar describes a real scenario where, while working in a model-based project using Rhapsody, there is the need of writing high quality requirements concerning the UML/SysML elements of the project.

In this scenario where UML/SysML models coexist with requirements, a crucial role is played by physical models simulations, indeed requirements feasibility is going to be tested against physical models simulation (FMUs files).

Model-Based (MBSE) is the current trend in regard to Systems Engineering, leveraging testing and simulation activities. However, it’s also clear that textual requirements will remain in the scene since they are also key for testing, certification, and communication with other stakeholders.

This Webinar describes a SMART way to mix both models and textual requirements together, covering topics such as requirements transformation (from requirements to models and vice versa, from requirements to test cases…), traceability of different sorts of items, retrieval and reuse of work products… All these topics will be addressed having in mind the importance of quality standards, since are the key for systems certification, and fully required to always reuse, trace and transform high-quality artifacts.

Nowadays, very few companies develop, distribute, and sell products end-to-end. On the contrary, it’s quite common to find the supply chain approach, where many suppliers might be involved in the whole product lifecycle. This may lead to specialization, cost reduction, and scalability.

This Webinar focuses on the close communication between the OEMs (Original Equipment Manufacturers) and the Suppliers to perform quality assessment and keep track of the evolution of the quality of the supplier assets.

In a nutshell, OEMs will define the quality metrics that must be fulfilled by the different Suppliers along the supply chain. Suppliers will develop their specifications, performing also quality assessment, and will send quality reports to the OEM. With this information, the OEM tracks the quality of the different subsystems.

Completeness is, by far, the most difficult quality characteristic to be checked in our requirements specifications. Completeness is a twofold issue. On the one hand, a requirement statement is complete when it includes and conveys all the information it has to include: who is the subject of the action, when is this action performed, under what conditions, what should be the performance…. In other words, and citing the INCOSE Guide for Writing Requirements, a requirement statement is complete when it “… describes the necessary capability, characteristic, constraint, or quality factor … without needing other information to understand the requirement”.

On the other hand, the entire specification should be analyzed in terms of completeness to answer questions such as:

Are we considering all different types of requirements (safety, security, regulation…)?
Are all the different types of actors mentioned in the high-level requirements?
Are we addressing the counterpart for some specific actions? That is, if a specific item can be created in a system, should it be also removed at any particular time? When a light can be switched on, shouldn’t we also expect a requirement to switch it off?
Are all the system elements described in a model well-covered in our specifications?
Are there interfaces between components where our requirements are not linking together these pair of components?
Are all the actions described at a specific level properly flowed down to the following levels?
Completeness also has to do with links and attributes. Missing links or empty attributes are also sources of incompleteness.
A tool like RQA will never replace the human labor to tackle this issue, but what technology can offer is a quick and exhaustive analysis of large requirements specifications; and, at the same time, having in mind that necessity and completeness are the two sides of the same coin.

Agenda:

Introduction
The completeness problem in systems engineering: how to know when the requirements are complete?
Completeness metrics in Requirements Quality Suite
Live demo:
Tailoring completeness metrics in RQA
Checking completeness for a DOORS specification with RQA
Q&A