Requirements Engineering
Requirements engineering is the discipline of discovering, analyzing, documenting, validating, and managing what a software system must do and the constraints under which it must operate.
Definition
Requirements engineering is the systematic process of eliciting, analyzing, specifying, validating, and managing the services a software system should provide and the constraints on its operation and development.
Scope
This area covers the elicitation of stakeholder needs; the analysis and negotiation of conflicting goals; the distinction between functional and non-functional (quality) requirements; specification techniques ranging from natural-language statements to formal models; validation through review and prototyping; and the management of requirements changes and traceability across the life cycle.
Sub-topics
Core questions
- How are the real needs of stakeholders discovered and disambiguated?
- How should functional and non-functional requirements be specified precisely yet understandably?
- How are conflicting requirements detected, negotiated, and resolved?
- How are requirements validated and kept consistent as they change?
Key theories
- Functional versus non-functional requirements
- Requirements are partitioned into functional statements of what the system must do and non-functional (quality) constraints such as performance, security, and usability that often cut across the whole system and drive architecture.
- Goal-oriented requirements engineering
- Systems are analyzed in terms of stakeholder goals that are refined into sub-goals and operationalized into requirements, providing rationale, conflict detection, and traceability from high-level intent to system functions.
Clinical relevance
Requirements errors are among the most expensive defects because they propagate into design and code; rigorous requirements engineering reduces rework, aligns delivered software with stakeholder needs, and provides the basis for acceptance testing and contractual agreement.
Evidence & guidelines
ISO/IEC/IEEE 29148 specifies requirements engineering processes and the contents of requirements specifications, and the SWEBOK Software Requirements knowledge area provides a consensus reference.
History
Requirements engineering grew from structured-analysis methods of the 1970s into a recognized sub-discipline in the 1990s, marked by dedicated conferences (RE) and journals, the rise of goal- and scenario-based modeling, and increasing attention to non-functional requirements and stakeholder negotiation.
Debates
- Up-front versus emergent requirements
- Plan-driven practice favors specifying requirements thoroughly before construction, while agile practice treats requirements as emergent and refined through iteration; the trade-off turns on volatility, contractual constraints, and the cost of late change.
Key figures
- Axel van Lamsweerde
- Bashar Nuseibeh
- Steve Easterbrook
- Michael Jackson
Related topics
Seminal works
- vanlamsweerde2009
- nuseibeh2000
- sommerville2015
Frequently asked questions
- Why are requirements errors so costly?
- A misunderstood or missing requirement is often discovered only late, after design and code have been built on it, so correcting it requires unwinding downstream work; empirical studies consistently show that the cost of fixing a defect rises sharply the later it is found.
- Do agile projects do requirements engineering?
- Yes, but differently. Agile projects elicit, analyze, and validate requirements continuously through user stories, backlog refinement, and frequent feedback rather than producing a large specification document up front.