“Shooting beyond the target is just as bad as not reaching the target.”
This saying comes from Confucius and perfectly reflects what can happen if insufficient attention is paid to requirements engineering (RE) during complex development projects. Although the importance of RE for the success of development projects has long been acknowledged, efforts are still needed to implement it consistently. This series of three articles provides an overview of the basic concepts of RE in the context of a continuous development project lifecycle.
It may seem paradoxical to start with the result, but without setting a project goal, you will make many costly detours during the project.
“Not reaching the target,” i.e., not implementing the required properties of a product, can have fatal consequences. The same applies to “shooting beyond the target,” i.e., implementing features that were not requested.
The potential negative consequences range from purely economic damage due to lost revenue or high costs from implementing unwanted features (the “gold-plating” effect) to endangering life and limb if safety-critical features are missing or if unnecessary sources of error are introduced.
|
NOTE: In this article, we use the term “Requirements Engineering” or “RE” to refer to the process of continuous development in accordance with requirements. This includes the collection, weighting, selection, specification, adaptation, verification, validation, and management of requirements. You can find a definition here. |
It goes without saying that before deciding to embark on a particular project, the goal is usually clarified and the economic conditions assumed. However, this context can change during implementation, and in many projects, this will happen. It often turns out that ultimately more development costs have been incurred than originally planned. Possible causes include misunderstandings at interfaces, “duplicate” work because specifications were misinterpreted, technical complications arose, efforts were incorrectly estimated or because small changes crept in that led to serious deviations from the target during the project.
All of these are typical indications that requirements engineering can and should be improved (see box for definition).
Requirements Engineering (RE) is probably the most underestimated discipline in systems and software development.
It's not just a question of defining the required outcome with all stakeholders at the beginning of a project. Instead, the real challenge lies in continuous requirements engineering, in other words, setting up the permanent alignment of requirements with current and future engineering artifacts. It includes feedback loops and, if necessary, the correction of both requirements and artifacts.
Enabling and driving this synchronization throughout the development process is one of the most central tasks of requirements engineering. Depending on the industry and the nature of the project, various disciplines may be involved in the requirements engineering process, each with their own perspectives on the system under development (see Fig. 1). The involvement of all relevant specialists in an end-to-end RE process is an important prerequisite for ensuring that the project outcome meets expectations (see Fig. 2).
Fig. 1 – View of the specialists from the disciplines involved. Each has a different perspective on the emerging system (here using the example of roles in a typical RE process for embedded systems)
Here is an overview of the typical questions to consider when planning and implementing projects:
This only concerns the “craft” aspects of requirements engineering, which can be managed with appropriate procedures, processes, and tools.
Fig. 2 - Requirements Engineering ensures that the expected product is built with the involvement of the necessary specialists.
Another often underestimated factor is requirements quality. And this is exactly what we’re going to tackle in the next article... In the meantime, if you are looking for more information on requirements engineering, this is a good starting point: https://www.sodiuswillert.com/en/solutions/requirements-engineering