Formalizing textual requirements in a model to improve articulation between system engineering levels

Natural language textual requirements can be constructed based on templates in order to set up a complete, uniform set of requirements. This enables a common understanding between the author and the reader about the intention of the requirements. These requirements may be implemented systematically into a system analysis model or used in the acceptance criteria for tests and system verifications. The process of starting with an idea up to creating a perfectly written requirement and its further processing, for example in a model, is being systemized.

The analysis and improvement of textual requirements would not be necessary, if requirements of high quality, meaning correct and comprehensible, were available from the start.

Constructing requirements according to certain rules is a means of avoiding mistakes from the very beginning. This way of creating requirements makes it possible to assign a similar structure to each requirement and eliminates many of the possible mistakes being made in wording the requirements, like passive sentences, which usually don’t offer any information about what functionality is being expected from whom. Similar to building a house according to an architect’s plan, it is possible to construct a requirement according to a plan, or rather according to a template.

These are called generic, syntactical requirements templates, since only the syntax (structure) of a requirement is defined, not its semantics (the contents).

Writing perfect requirements from the beginning means to consider several aspects, to ensure correctness, well structured, and consistency. Requirements should free of mistakes, well-structured with the requirements patterns support and consistent with glossaries and models.

Below an image of the three aspects that should be considered:

Requirements management tools are widely used to manage both requirements and relationships between them and often maintained in a database.

Requirements can be depicted on diagrams captured in a Model-Based System Engineering (MBSE) model (model will be referenced as a MBSE model), it is useful in representing the traceability of a single requirement to examine how that requirement is satisfied, verified, and refined, and to analyse its derived relationship with other requirements.

Models aims at centre of the interactions between all engineering stakeholders, in order to benefit from an increased rigour and improved communications. This means not only system architects but also customers, specialty engineers, V&V engineers and others may work and benefit on the basis of the model information, either by contributing to the model or by consuming its outputs.

This connection of architecture models with the surrounding engineering activities is implemented either by linking models to other engineering artefacts, or by extracting and transforming data in the right format (document generated from the model, data in excel sheets, code structure and interfaces generated from the model, etc.).

A combination of tool automation, the requirement management process and configuration management can be defined to synchronise the requirements between the requirements management tool and the model. This capability is intended to improve requirements management throughout lifecycle of a system by enabling rigorous traceability between textual requirements and the model elements.

Models are not intended to replace textual requirements; model elements and textual requirements complete each other and must typically be related to each other, model elements help to formalize a textual requirement, for example, stakeholder requirements.

Requirements engineering is indisputably the backbone of the current engineering practices. Hence, the need of the articulation of requirements with models is essential. As captured in the figure below Model and requirements traceability, a project or organisation may have different needs to create several models, for example, breakdown a system complexity, hand-over a system or component to a team or supplier.

As mentioned above, models help to formalize and consolidate the customer and system textual requirements needs. In Arcadia, need models are covered by the two first engineering perspectives:

• Operational Analysis focus, on the needs of the system from any stakeholders that will interact or do have an interest on it.
• System Analysis focus on the system itself, what is expected from it.

A solution/architecture model helps validate the feasibility and elicit/justify new requirements for the system or its subsystems. In Arcadia, solution is covered by:

• The conceptual Logical Architecture focus on, how the system should work to fulfil the system needs.
• The developed Physical Architecture focus on, how the physical system will be built.

Different types of traces can be created:

1. Between textual requirements: normally created and maintained within the requirements management tool.
2. Between model elements and textual requirements: directly in the model and textual requirements if requirements captured or imported into the model, or a tool that provides the capability to connect both the modelling and requirements management tool to create trace links.
3. Between model elements: normally created by the modelling language or modelling tool.

In the section hereafter, it will be captured examples of different types of traceability relationship links.

Traceability relationship types

Textual requirements and model elements traceability relationships can be specified. These include relationship for defining a requirements hierarchy, deriving, satisfying, verifying, refining, and copying requirements, as well as general purpose trace relationship.

In the table below, it is captured common types of traces accompanied by a description of its intended use:

A requirement specifies a capability or condition that should (or shall) be satisfied, a function that a system must perform, or a performance condition a system must achieve.

In general terms, textual requirements and model elements can be traced and linked as follows:

• Functional requirements are likely to be traced to Capabilities, Functions, Functional Chains, Scenarios, Modes, States.
• Other non-functional requirements can also be traced to model elements, for example, to Functional Chains capturing latency constraints, datatypes, classes, physical quantities, and structural elements.

Life cycle and artefacts

Figure below illustrates the relationships between models and textual requirements across several levels of engineering. A good practice is to separate the artefacts in different modules based on configuration management scopes, so as to preserve independence of lifecycles:

Figure above, shows a typical workflow for architectural design based on the Arcadia engineering method:

1. Stakeholder requirements document captures the stakeholder high-level requirements expectations and their objectives, and normally, the input to the model.
2. Operational Analysis formalizes stakeholder requirements by using Operational Activities and Processes. Performing the analysis of the stakeholder expectations with a model helps check their consistency and completeness.
3. System requirements document captures system requirements that the system must do by analysing both stakeholder requirements and the operational analysis. System requirements are derived, captured, and traced (derivation links.
4. System Analysis goal perspective is to formalize system textual requirements and capture what the system must accomplish. Traceability between Operational Analysis and System Analysis models ensures completeness and paves the ground for later impact analysis.
5. Definition of the solution, justified by the System Need Analysis model. Possibly described at different levels of abstraction Logical Architecture and Physical Architecture , the architecture description specifies first how the system should work to satisfy the needs captured at System Analysis.
6. The Physical Architecture goal is to prepare the contracts for all subsystems and guarantee their proper integration, with the adequate level of detail how the system works and what is expected from each constituent. Instead of simply allocating (or cascading) textual requirements to elements of the Product Breakdown Structure, performing a rigorous, model-based design analysis has multiple benefits. In particular, the solution can easily be shared with all stakeholders: how the system works, what is the contribution of each component, what are the transitions between modes and between states, what are the impacts of modes and states on functional expectations, etc.

The specification of the subsystems with a model comes at no extra cost when the system architecture has been properly modelled. Arcadia advocates a recursive application of the method, and the Capella modelling tool provides an automated, iterative transition from system to subsystem. The context of a given system constituent is entirely computed (anything contributing to the definition of this constituent including allocated Functions, interfacing Components, etc.) and a downstream System Analysis model is initialized and maintained based on the evolutions of the system definition. The subsystem Analysis in Arcadia perspective is a centrepiece of the contract for the downstream engineering team.

The combination of model-based approach and automated system to subsystem transition as illustrated above favours co-engineering over the traditional differentiation between customer requirements and system requirements.

Conclusion

Textual requirements still form the backbone of systems engineering practices. However, textual requirements can be formalized and supported by a model and improving the transition between systems and subsystems.

Arcadia can be used to model text-based requirements and relate them to other requirements and to other model elements. The requirements modelling capability serves as the bridge between traditional text-based requirement and the modelling environment. Requirements can be directly created in the modelling tool or imported from a requirements management tool.

Integrating models in the technical contracts for the subsystems is a way to strengthen their specification and to guarantee their good integration in the global solution.

Finally, bridging textual requirements to models contributes to reduce lack of understanding, promote communication, consistency, completeness, and correctness in a single source-of-truth.

Further reading:

• Arcadia Operational Analysis .
• Arcadia System Analysis .
• Arcadia Logical Architecture .
• Arcadia Physical Architecture .

#mbse #arcadia #capella #systemarchitecture #engineering

#requirements