Requirement Engineering theory: In most of the requirement engineering publications, the focus is on management aspects. The collection and management of requirements is discussed extensively. In the following blog I discuss important aspects which are not sufficiently considered in the RE theory. I start with the definition of Requirement Engineering in the book “Requirements Engineering Fundamentals” (Klaus Pohl, Chris Rupp).

Requirement Engineering theory – Overview:

Klaus Pohl and Chris Rupp define Requirement Engineering as follows:

Requirement engineering is a systematic and disciplined approach to the specification and management of requirements with the following goals:

1. Knowing the relevant requirements, achieving a consensus  among the stakeholders about these requirements, documenting them according to given standards and managing them systematically
2. Understanding and documenting the stakeholders’ desire and needs, they specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs

Klaus Pohl und Chris Rupp identify four main tasks which need to be performed:
Elicitation, Documentation, Validation and negotiation, Management.

Requirement Engineering in the development of safety critical systems:

In the development of safety critical systems there is always a system break down. Firstly, the entire system with its interfaces to the outer world will be described as a black box in system requirements.

The architecture is then defined for the system. The functions of the blocks created in the architecture are then again described in the form of black-box requirements. An important criterion is the separation between SW and HW requirements. As most of the functionality is usually implemented in SW, there may be additional functional blocks in the software.

The resulting SW and HW requirements are then linked with the system requirements. This creates a continuous traceability which makes the system break down transparent and comprehensible.

Conclusion:

The system break down described supported by Requirement Engineering is an essential aspect in every development of an embedded system. This step is also very important for the verification of many robustness aspects.

Klaus Pohl and Chris Rupp discuss this subject in chapter 8.2 Views on Requirements and 8.4 Traceability of Requirements in the IREB standard book. The engineering aspect of this subject is, however, clearly too short. In practice, you sometimes face rather complex challenges when you want to create the right requirements at the various levels and then trace it properly. All these aspects can only be solved with engineering techniques and not with the management of requirements.

In this sense, I see the definition of Requirement Engineering as incomplete. In addition, the example also shows that there are important differences between IT software and embedded software development. It is therefore time that the Embedded Community also start writing books about Requirement Engineering. The variability of HW interfaces, the programming of embedded operating systems and the proof of a 100% structural code coverage have important implications for the requirements engineering, which are currently not really considered in the standard requirements engineering methods.

Related HEICON Blog posts

• Requirement and Test Traceability – Any added value?
• Requirement Engineering Embedded versus IT systems
• User Stories – The better Requirements?
• Requirement/Code Reviews – The better TDD?
• Economical considerations on requirement reviews!
• Are you still writing documents or are you already specifying?
• Non-Functional Requirements – A challenge?
• Requirement Categories – Why they are useful?

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.