Requirements Quality Improvements through Requirements Modelling

From Evidence on Formal Methods Uses and Impact on Industry
Jump to: navigation, search
Success Story
Domain Automotive
Keywords requirements, model, problem frames, semi-formal
Source Bosch (DEPLOY)

Main -> DEPLOY Success Stories -> Auto-1


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?


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


  • 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.


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:

  • 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)

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).

Those improvements are expected to be repeatable given that:

  • 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.

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.


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 [1]. Other requirements engineering notations are available, such as i*, KAOS, NFR [2], [3], [4]. 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 [5], which was specifically developed for requirements engineering (analysing problems), [6] 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 [7] and the MARTE UML profile [8].

  • 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 [9] 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 [10].
  • An internal tool for specifying problem frames was used.
  • Mapping problem frame to formal models in Event-B


  1. Klaus Grimm, Software Technology in an Automotive Company – Major Challenges, in Proceedings of the 25th International Conference on Software Engineering, Portland, Oregon, May 3-10, 2003.
  2. E. Yu. Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering. Proc. 3rd International Symposium on Requirements Engineering (RE’97), Washington, USA, January 1997.
  3. Axel van Lamsweerde, Requirements Engineering From System Goals to UML Models to Software Specifications, Wiley, 2009.
  4. L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishing, 2000.
  5. Michael Jackson. Problem Frames, Analysing and Structuring Software Development Problems. Addison-Wesley, 2001.
  6. Object Management Group, Unified Modeling Language, version 2.2, April 2009.
  7. Object Management Group, The Systems Modeling Language, version 1.1, November 2008.
  8. Object Management Group, Modeling and Analysis of Real-time and Embedded systems, OMG Std. Final Adopted Specification, August 2007.
  9. Jean Louis. Boulanger, Quang-Dao Van : Experiences from a model-based methodology for embedded electronic software in automobile, In Information and Communication Technologies: From Theory to Applications, ICTTA 2008. 3rd International Conference on Information and Communication Technologies, 2008
  10. DEPLOY D19, Pilot Deployment in Automotive, January 2010.

Personal tools