Requirements Engineering
Requirements engineering is the systematic discipline of eliciting, documenting, validating and managing requirements for a system over its entire lifecycle. The goal is a shared, verifiable understanding of what the system is supposed to deliver — between customers, developers, testers and all other stakeholders. Errors in the requirements are, by experience, particularly expensive: the later they are discovered, the more downstream work — design, implementation, tests — has to be corrected.
The four main activities
Requirements engineering comprises four closely interlinked activities that are carried out iteratively and over the entire project duration — not as a one-off phase at the beginning:
| Activity | Content |
|---|---|
| Elicitation | Gaining requirements from stakeholders, documents, legacy systems and standards — through interviews, workshops, observation, analysis |
| Documentation | Recording requirements: in natural language, via sentence templates or model-based |
| Validation & negotiation | Checking requirements for quality and resolving conflicts between stakeholders |
| Management | Versioning and prioritising requirements, controlling changes and establishing traceability |
With the IREB (International Requirements Engineering Board) and the CPRE certification scheme, an established, vendor-neutral training foundation exists for the discipline.
What makes a good requirement?
Common quality criteria: a requirement should be unambiguous (only one interpretation), verifiable (fulfilment objectively determinable), atomic (one fact per requirement), consistent (free of contradictions with other requirements) and necessary. The difference is evident in an example:
- Weak: “The system must react quickly to braking requests.”
- Verifiable: “The system must initiate brake pressure build-up within 50 ms of receiving a braking request.”
The first formulation can neither be implemented nor tested without someone silently making the actual decision later — often a different person with a different interpretation. Especially at higher criticality, standards such as ISO 26262 therefore recommend semi-formal specification methods that reduce ambiguity from the outset.
Requirements engineering and traceability
The fourth activity — management — connects requirements engineering with the production of evidence: requirements are not a static inventory, but change throughout the entire development. Every change raises the same questions: which architecture elements, which implementation, which test cases are affected? These questions can only be answered with maintained traceability — the traceable links from the stakeholder requirement through the system requirement to implementation and test. Process models such as Automotive SPICE demand precisely this bidirectional traceability as a base practice.
Requirements engineering in practice: management is decisive
In real projects, requirements engineering fails less often at elicitation than at management across tool boundaries: stakeholder requirements live in the requirements management tool, derived software requirements in a second system, tests in a third. Between these silos, requirements lose their origin and their effect — and with every change, the manual search begins for everything that is affected. Anyone who takes requirements engineering seriously must therefore organise, in addition to the quality of individual requirements, the continuity of the chain: from the source to the test case, across all tools involved.