Requirements Engineering: An Integral Part of the Development Process (Part 1)

Navigating Projects Safely to the Finish Line 

“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. 

Part 1: The Result of the Development Project 

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. 

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). 

What is requirements engineering? 

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) 

Requirements engineering, a basis for successful projects 

Here is an overview of the typical questions to consider when planning and implementing projects: 

• Have all the experts whose contribution is relevant been approached when gathering requirements? 
• Is the objective clear to ALL stakeholders involved? 
• Do all participants have the same understanding and interpretation of the objectives? 
• What happens if certain aspects of the objective cannot be achieved as planned (e.g., due to previously unknown technical restrictions or because general conditions of customers/users have changed)? 
• How can we regularly check that everyone is still sailing towards the same goal? 
• How can we check “along the way” whether the objectives have been implemented as agreed? 
• Does the tester have the same understanding of the scope of functions to be tested as the customer? 
• How can we ensure that compliance with agreed specifications is tested, and not just the scope of functions implemented? 
• And how can I provide seamless proof of this, e.g., for approval procedures? 

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. 

Sneak Peak of Part 2 

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