EN 
DE Principles of Simplicity in Requirements Engineering
Author: Matthias Moll, Helbling Technik GmbH
Contribution – Embedded Software Engineering Congress 2018
Many prominent figures have recognized simplicity as a key to success, and the topic remains popular today. Especially in the complex field of requirements development, with its numerous stakeholders, influencing factors, and intricate system properties, simplicity offers significant potential for efficiency gains in system development. However, simplicity is not easy to achieve. Nevertheless, fundamental principles can be identified in the context of requirements development that can help develop qualified requirements or simplify existing sets of requirements.
Simplicity in requirements development
Developers of products and systems are frequently confronted with complexity. However, complexity creates risks, as the human brain can only grasp the dynamic interplay of structures and relationships to a limited extent. Standardized process models and development methods address this problem and attempt to break down the complexity of development projects and dynamic systems into smaller, simpler, and therefore manageable units.
Requirements development is of particular importance in this process. Requirements not only mark the beginning of system development and thus largely determine the complexity of the product to be developed, but also form the central interface with the client. In this role, requirements are crucial to the success or failure of system development, because qualified requirements are the "definition of done" for the project.
Simplicity in requirements development offers the potential to reduce the complexity of system development, and thus budget and schedule risks, right from the early project phase. However, experience shows that requirements often fall short of this paradigm of simplicity. This leads to misunderstandings and lengthy coordination processes, as well as increased effort for change management, documentation, and system testing. In contrast, qualified requirements development improves product quality, allows for greater freedom in finding solutions, fosters a more harmonious customer relationship, and generally promotes enjoyment in collaborative development.
Focus on the essentials
As a first step, requirements can be simplified by trimming templates, simplifying the document structure, and omitting unnecessary content. Requirements templates, with their predefined chapter structure, often contain a vast array of aspects that could potentially be relevant, but which are largely irrelevant to the specific project. Furthermore, one often observes an overload of project specifications and information that have no impact on the product. This is where initial simplification measures can be taken:
- Omit a change history in the requirements document if it is managed in a configuration management tool. These tools include version control with a change history. If this is used, changes do not need to be managed separately in the document.
- Disregard project information and requirements, business aspects, and requirements outside the scope of the system under consideration.
- Interpret norms and standards instead of simply referring to the relevant standard. Extract the aspects that are relevant to the system at hand and formulate the standard's requirements as concrete, functional system requirements.
- Structure your requirements according to interfaces and avoid a strict separation between functional and non-functional requirements. Operationalize non-functional requirements, i.e., interpret the required system property as a concrete, functional system requirement.
- Delete fill-in aids, template texts and unnecessary sections instead of marking them with "not applicable", for example.
Only the interfaces count.
Unnecessary complexity in requirements often arises from a lack of separation between the required behavior at the interfaces of the system under consideration and specifications regarding the solution. To avoid this, a black-box approach should be consistently pursued.
In Figure 1 (see. PDFThe black-box approach is illustrated in Figure 1. The key characteristics of the black-box approach are system boundaries, interfaces, and internal states. For qualified requirements development, it is crucial to fully and unambiguously define these characteristics in relation to the system under consideration before formulating the actual requirements. The following points should be noted:
System boundaries and interfaces should refer to the system level under consideration, explicitly without taking the internal system architecture into account. From the perspective of the overall system, an internal interface between components of the system architecture (subsystems) is already part of the solution, as shown in Figure 2 (see Figure 1). PDF) illustrated.
Requirements for subsystems could be part of the initial requirements documentation if the system architecture is at least partially predetermined and a clear separation between the levels under consideration is ensured.
Requirements depend on internal system states. In systems theory, internal system states are the result of an initial state and a sequence of signals at the input interfaces. Therefore, in dynamic systems, requirements are always dependent on past events. The system thus acquires a memory. For clear requirements development, it is important to be aware of this and to include operating modes, system states, data, and similar time-varying system properties.
Cause and effect instead of state and structure
System boundaries, interfaces, and internal states are not the requirements themselves, but rather form the basis for the straightforward formulation of suitable requirements. The DNA of every requirement is the description of a desired effect that should occur as a consequence of an event under a specific condition. If all system interfaces and internal states are fully defined, the desired system behavior can, in principle, also be completely defined.
In this sense, the system is understood as a state machine whose state transitions, taken together, specify the system behavior. Each cell of the table from Figure 3 (see...). PDFRequirements can be formulated as a function or represented using a model-based requirements development approach. For continuous-time or discrete-time signal processing (e.g., in digital controllers), requirements are defined analytically, i.e., via systems of differential or difference equations. Here, too, the requirement definition corresponds to the description of a cause-and-effect relationship based on input signals and internal states that change depending on the time course of the input signals.
Conclusion
Simplicity in requirements development means completeness with minimal scope. This is achieved by focusing on the essential aspects that determine system behavior. Only the behavior at the interfaces counts, i.e., the desired effect at the output interfaces based on current and past events at the input interfaces. Requirements should always be described as a cause-and-effect relationship, rather than merely describing the system's structural design or static system states.
A careful and thorough requirements analysis in an early project phase leads to improved quality with reduced time and cost risks.
author
Matthias Moll is Head of Embedded Software Development at Helbling Technik GmbH in Munich. After studying Information Systems Engineering in Braunschweig, he worked for 11 years at Robert Bosch GmbH as a software developer and software project manager, initially in the area of transmission control units and later fire alarm control panels. In 2016, he joined the management team at the Munich location of the Helbling Group. His main focus is on the efficient development, management, and implementation of requirements in changing technology, industry, and project environments.
Contact
matthias.moll@helbling.de
Requirements – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of requirements/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Requirements – Expertise
Valuable expertise in the field of requirements/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
