Requirements engineering benefits from simplicity

System developers are often confronted with complexity. Complexity gives rise to risks because our brains have only a limited overview of the dynamic interplay of structures and interdependencies. Requirements development is particularly important in this regard because it occurs at the beginning of system development and thus determines its success. In this context, simplicity offers great potential for risk minimization and efficiency gains. However, simplicity is not easy to achieve.

Practice shows that requirements often do not meet the simplicity paradigm. This leads to misunderstandings and lengthy coordination processes as well as increased effort with regard to change management, documentation, and system testing.

Helbling has experience in all areas of converting clients’ wishes into successful innovation projects. Dealing with vagueness and translating it into the best possible project result is a central component of Helbling’s development service.

In Helbling projects, it has thus proven effective to pursue qualified requirements development during system development. This improves the quality of the product, allows greater freedom in finding solutions, leads to more harmony in the customer relationship, and generally promotes enjoyment in development cooperation.

Step 1: Focus on the essentials

In the first step, requirements can be simplified by trimming templates, simplifying the document structure, and omitting unnecessary content. The following aspects, for example, may be omitted: redundant project information, requirements outside the scope of the system under consideration, and development process requirements. Relevant aspects of norms and standards should be interpreted and formulated as concrete functional requirements instead of making blanket references to the relevant norm.

Step 2: Only the interfaces count

Superfluous complexity in requirements often results from a lack of separation between the required behavior at the interfaces of the considered system and specifications relating to the solution. To avoid this, Helbling consistently pursues a black box approach.

Step 3: Open the solution space

For qualified requirements development, it is important to fully and precisely clarify the considered system level and thus its boundaries and interfaces. Requirements that refer to individual subsystems or architecture components are already part of the solution and restrict the solution space respectively. They should only be formulated as requirements if a clear separation between the respective levels is ensured.

Step 4: Look into the past

Requirements depend on internal system states. In systems theory terms, internal system states are the result of an initial state and a sequence of signals at the input interfaces. Thus, in dynamic systems, requirements are also dependent on events in the past. The system thus becomes memory-bound. For clear requirements development, it is important to be aware of this and include operating modes, system states, data, and similar system properties that can change over time.

Step 5: Define system behavior

System boundaries, interfaces, and internal states are not the requirements themselves, but form the basis for the simple formulation of suitable requirements. The DNA of each requirement is the description of a desired effect that is to occur as a consequence of an event under a certain condition. If all system interfaces and internal states are completely determined, the desired system behavior can also be completely defined in principle. The following transition table provides a rough example:

In this sense, the system is understood as a state machine whose state transitions specify the system behavior in their entirety. Each cell of the table can be formulated as a requirement. For continuous or discrete signal processing (e.g., in digital controllers), the requirements are defined analytically, i.e., via differential or differential equation systems. Here, too, the requirement definition corresponds to the description of a cause-effect relationship, based on input signals and internal states that change depending on the temporal course of the input signals.

Example: Solution description instead of requirements development

In a development project, a company commissioned a service provider to integrate a sensor into an existing embedded system. Instead of describing the cause-effect relationships with reference to the system interfaces and internal states, the requirements specification contained flowcharts in the sense of software design. This flowchart represents the procedure:

The new “Start time counting” function to be implemented is marked in orange. In the verification test, it turned out that the activity triggered by this on the serial interface interfered with the simultaneous receipt of . The solution declared as a requirement did not work and had to be corrected in a time-consuming manner, including a change to the requirements document.

A better requirements analysis would have been less time consuming. What is the intention behind the “Start time counting” function call? Transferring the flowcharts into a representation as a state machine leads to the following simplified representation:

The underlying requirement could now be read from the state transitions: “If a wake-up event is detected in the idle state and a request is subsequently received via the radio link, then the system should switch to the idle state within two minutes”. This requirement can be tested accurately and leaves enough room for finding a solution that takes into account cross-effects with existing functionalities.

Summary: In requirements development, simplicity means completeness with minimum scope

To create the optimal conditions for system development, simplicity and completeness are required. This is achieved by concentrating on the essential aspects that determine the system behavior. Only the behavior at the interfaces counts. To this end, the focus should be on the desired effects at the output interfaces (based on current and past events at the input interfaces). Experience from Helbling projects has shown that requirements should always be described as a relationship between cause and effect. With this in mind, Helbling therefore conducts a careful and thorough requirements analysis with its clients at an early stage of the project. Compared with cases where this does not take place, this approach improves quality while reducing time and cost risks.

Author: Ralf Hediger

Main image: iStock