Many books have been written in the last 30 years on the subject of requirement engineering. The method has been designed and improved. The great success of these efforts lies in the fact that the awareness of the topic has been raised in a broad professional audience. There is hardly anyone today who would fundamentally deny that requirement engineering is useful for embedded systems and IT systems. On the other hand, it can also be stated that the practical implementation of requirement engineering in projects still has significant shortcomings. This is where the following article starts. On the basis of some selected topics of requirements engineering I show differences between the requirements in the method description and the needs in practice. Possible solutions are indicated but are not part of this article. Here, it is “only” a matter of sharpening the awareness of the problem.

Theoretical background to which this article refers

As an important representation of the documented requirement engineering theory, the following books form the basis of this blog post:

• Requirements Engineering Fundamentals by Klaus Pohl and Chris Rupp
• Systematic Requirements Engineering by Christof Ebert
• Requirements Engineering and Management by Chris Rupp

What is a Requirement?

Christof Ebert defines a requirement as follows:

A requirement describes what the customer or user expects from the product, i.e. conditions, attributes, goals and above all benefits. Requirements are defined as:

• An attribute or condition that is needed by a user (person or system) to solve a problem or achieve a goal.
• A property or condition that a system or system component must fulfill in order to comply with a contract, standard, or other formally specified document
• A documented representation of a property or condition as described in the first two points

What is Requirements Engineering?

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:

• Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards and managing them systematically
• 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.

In the following, I will list important practical points that need to be added to the requirement engineering method in order to use it in a more focussed way.

Software Requirement Engineering

Both of the definitions presented here focus requirement engineering on the capture of requirements at the highest level from all stakeholders.

It is not clear whether requirement engineering should also be carried out at the software and hardware level, or whether it is restricted to the system level. In Christof Ebert’s definition, the term “characteristics” is used to describe the requirements and the system components to be fulfilled. However, this is limited to properties/conditions that are contained in a contract, a standard or other formally specified documents.

All 3 books deal in great detail with the topics of determining, documenting, checking and coordinating requirements, and administration. RE tools are also discussed, as well as soft skills and agile requirements engineering

The focus here is very much on the system level. None of the books discusses the topic of software requirements engineering and how it relates to system requirements engineering.

Hardware Requirement Engineering

Hardware requirement engineering plays no role at all in theory. The topic is almost completely ignored in the requirement engineering method. In the development of embedded systems the question of a hardware requirement engineering method is obvious. The cross-linking of embedded systems and IT systems increases the overall system complexity. Therefore, the requirement engineering method should be supplemented by hardware requirement engineering. Practical projects show more than clearly that hardware requirement engineering is not a copy of software and system requirement engineering. HEICON has gained a great amount of experience in this area over the last years, which should be incorporated into the hardware requirement engineering method description.

Methodical differentiation of requirement and architecture

If, as requirement engineering, you not only define the description at system level, but also include the software and hardware level, then it becomes evident that you also need a methodically defined distinction between architecture and requirements. Many projects in practice that I have been able to supervise in recent years suffer from the fact that this distinction does not exist to a sufficient extent. The books by Christof Ebert, Klaus Pohl and Chris Rupp, correctly define architecture as the implementation of the “how” of a product. Since requirements engineering is seen as the description of the “what” of a product at system level, the distinction is clear for them.

However, if you also extend requirements engineering to hardware and software level, it quickly becomes clear that a precise differentiation is needed. In my experience, software and hardware requirements should define the “what” of a product for the component to be described. If you think further ahead here, you will also come to the clarification of the question in which form the requirement is documented. Clear and comprehensible rules are created as to what is presented in text form and what is represented by graphical means. This practical experience will also contribute to a more precise definition of requirements engineering.

Hardware/Software Interface Requirement

In all 3 books mentioned above, interfaces are only understood as the external interfaces of a system. They represent the system boundaries. This is correct. But already on this level (system level!) the question arises in practice how interface requirements are to be managed. How do you phrase them? Where exactly is the boundary between functionality and interface in requirement engineering?

In practice, the topic becomes even more complex when you are faced with the task of documenting hardware/software interfaces. On the one hand, there are a lot of these interfaces in an embedded system, on the other hand there are data sheets describing these interfaces. Are the data sheets sufficient or does the requirement engineering still have to take action? If so, what exactly has to be done? For this topic, too, it is important to supplement the requirement engineering method in such a way that the practical experience gained is made available to a wide audience of users.

Use Cases as a tool for requirements determination at system level

The books on requirements engineering describe the determination of requirements in great detail. The authors highlight many techniques, such as interviews, 6-3-5 methods, use cases and many more. My practical experience also shows that each technique has its justification in an appropriate situation.

However, my practical experience also shows that many users are often overwhelmed by the multitude of techniques. It is not clear in which order the techniques should be used and which technique is more important than others.

For the majority of projects, it makes sense to create general use cases, with the goal to cover all important topics of a specification. A graphical representation of the use cases is very suitable here. With a first version of these use cases, interviews and workshops with all stakeholders can be conducted. Details of the use cases are then recorded, and the use cases are completed. This information can then be used to phrase initial requirements. The created requirements are then reviewed. After the review, verifiable requirements are usually already available. This is a very effective way to fulfill an important task of requirements engineering in many projects. HEICON will continue to develop this basic concept in order to obtain guidelines that can be applied in practice in the future.

Conclusion

In this article the following gaps between the documented requirements engineering method and the requirements in practice were identified:

• Establishment of software requirements engineering in addition to system requirements engineering
• Definition of the special features of hardware requirement engineering
• Lack of guidelines on the clear distinction between requirements and architecture
• Lack of guidelines on the treatment of interface requirements in general and hardware/software interface requirements in particular
• Practical guide to the procedure for determining requirements

The points are not complete. For example, I have completely ignored the whole topic of traceability strategy. The article shows that there are solutions for most of the points raised. What is missing is to make this knowledge available on a broad basis and thus to realize Requirements Engineering 2.0. The megatrends of our time, such as IoT, Smart Home or autonomous driving, strongly require effective requirements engineering! By the way, the same applies to the fast, sustainable and safe development of technical solutions to defeat Covid-19 with modern medical technology!

Related HEICON Blog posts

• Requirement Engineering – Aspects which even not considerd in theory!
• Requirement Engineering Embedded versus IT systems
• Requirement and Test Traceability – Any added value?
• User Stories – The better Requirements?
• Requirement/Code Reviews – The better TDD?
• How many level of Software requirements are necessary and useful?
• 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.