Requirements Quality Improvements through Requirements Modelling

Main -> DEPLOY Success Stories -> Auto-1

Summary
The current practice in the industry with respect to requirements engineering is mainly to use structured textual notations and requirements engineering tools. Solution level considerations are also often mixed with (problem level) requirements. This item of evidence concerns the benefits to requirements quality that come from the use of formal/semi-formal engineering techniques in order to adequately manage this critical part of a development process. The evidence results from an application of such techniques to the specification of an existing system (a cruise control) and comparing the resulting specification with the original one.

Related FAQ
of Interest to Project and QA Managers
 * QI-HM-1 – Is there corroborating evidence that formalism help identify issues and errors earlier in the development cycle?
 * QI-HM-3 – What is impact on the rate of issues identified at each phase of development cycle?

Benefits

 * Improvement in requirements quality.
 * Better communication using diagrammatic notations.
 * Intermediate step towards a formal model and helping the formalization process.

Limitations

 * Single evidence report; results need to be confirmed in other cases and other sectors.
 * Current tool support (student prototype) is not adequate for industrial use. General lack of industrial tools supporting problem frames.
 * Standard compliance not explicitly taken into account at this stage (relevant standard: IEC 61508, upcoming ISO 26262)
 * Limitation to capture non-functional requirements (like timing requirements) with problem frames.

Elaboration
The work started from an existing specification of a cruise control system (originally in German), composed of about 300 requirements distributed over 7 main categories: general instructions (4), analysis of operating lever signals (33), speed regulation (39), controller state logic (116), switch off conditions (97), driver information (3) and monitoring information (3).



Through the systematic approach of expressing problems in relation with the machine, the use of problem frames models led to major improvements in the requirements documents: The global evolution of requirements over time is illustrated in the above figure. The time scale is about 6 month. The top curve (in red) shows the evolution of a number of requirements. It is equal to the initial number of requirements minus the rejected requirements (green curve) plus the new requirements (pink curve).
 * Removal of requirements that were either redundant or expressing the same requirements at different levels (possibly already partly in operational solution oriented ways). The reduction of such inadequate requirements summed up to about 40% of the initial requirements.
 * Identification of missing requirements, about 25% of the final requirements.
 * Requirements illustration using problem frame diagrams, leading to requirements statements that were easier to understand.
 * Semi-formal modelling of requirements using problem frame diagrams
 * Scalable structuring of problem frames (contributed extension)

Those improvements are expected to be repeatable given that: Another positive factor for the internal adoption of the method is the previous experience with problem frames in other projects of the automotive company's research department.
 * a complete methodology guide (internal report) was produced (it is partly described in [D19])
 * problem frames were successfully transferred to the deployment partner active in the automotive sector via a series of successful workshops involving methodology experts (Profs. Michael Jackson and Michael Butler). The topics covered moved from introductory to advanced concepts.

Consolidation
It is well known that a mature requirements specification was an indispensable prerequisite for dependable software systems. Up to 40 percent of the errors occurring during the use of a software-based function can be traced to immature requirements specification. Other requirements engineering notations are available, such as i*, KAOS, NFR, ,. As with problem frames, they have add value when used in the process of eliciting and structuring the requirements. Most of those methods have however mainly been experimented on information systems and less on control systems.

In contrast to Problem Frames, which was specifically developed for requirements engineering (analysing problems), is a generic set of modelling notations. As such it is not fit for the requirements in the automotive domain: UML is for modelling software, it is mainly solution oriented and offer little support for requirements (except use cases). However some derivatives of UML exist and have been experimented with: namely SysML and the MARTE UML profile.
 * SysML addressed systems engineering. It supports the capture of requirements through a specific diagram. Technically it is based on subset of UML extended with standard UML mechanisms (profiles). The requirements notations support the notion of refinement.
 * MARTE (Modeling and Analysis Real-Time and Embedded) is an UML2 profile developed by OMG in order to extent the capacities of UML for real-time modeling in embedded systems. It has the capability to capture specific requirements related to performance and schedulability. It also provides also support for specification, design, verification and validation stages.

The methodology proposed by respects safety standards and benefits from the system modelling languages SysML and MARTE. The requirements’ activities consist of structuring text based requirements from a requirement management tool using the SysML requirements diagrams and of relating them to other modelling artefacts via a set of stereotyped dependencies. During the design to implementation phases, those requirements are attached to functional blocks so that the traceability is guaranteed. However adequate tool compatible with the above profiles was reported to be a problem.

Deploy Specific Contributions

 * To scale up to industrial size, problems frames were extended with structuring mechanisms, documented in.
 * An internal tool for specifying problem frames was used.
 * Mapping problem frame to formal models in Event-B