What is Requirements Engineering?
Welcome to the IREB CPRE Foundation Level course. In this first lesson you will learn why requirements engineering is critical, what it actually means, and what happens when projects skip it.
Why Does Requirements Engineering Matter?
The Standish Group's Chaos Report paints a sobering picture of software projects. In 1994, about 30% of software projects failed completely and another 53% exceeded their time or budget constraints. By 2006 the failure rate dropped to 20%, and one of the top three reasons for the improvement was better communication of requirements.
Here is the uncomfortable truth: approximately 60% of all errors in system development originate during requirements engineering (Boehm, 1981). These errors are often discovered much later, during testing or even after deployment, because developers interpret unclear requirements as best they can and keep going.
The later a requirements defect is corrected, the more expensive it becomes:
- Fixing a defect during RE costs 1x effort
- Fixing the same defect during programming costs up to 20x
- Fixing it during acceptance testing costs up to 100x
This is why investing time in RE early pays massive dividends. A requirement that is wrong, missing, or ambiguous will silently cascade through design, implementation, and testing, growing more expensive to fix at every stage.
What Is a Requirement?
The IEEE defines a requirement in three complementary ways:
- A condition or capability needed by a user to solve a problem or achieve an objective.
- A condition or capability that must be met by a system to satisfy a contract, standard, or specification.
- A documented representation of such a condition or capability.
In short: a requirement describes what the system should do or how well it should do it, not how it is built internally.
Requirement (IEEE 610.12)
Click to flipA condition or capability needed by a user to solve a problem or achieve an objective, or that must be met by a system to satisfy a contract, standard, or specification.
Click to flip backThe Four Core Activities of RE
Requirements engineering is not a single task, it is a set of four interconnected activities:
| Activity | What It Does |
|---|---|
| Elicitation | Obtaining requirements from stakeholders and other sources using interviews, workshops, observation, etc. |
| Documentation | Describing requirements using natural language, conceptual models, or both. |
| Validation & Negotiation | Checking that requirements meet quality criteria and resolving conflicts between stakeholders. |
| Management | Structuring, prioritizing, tracing, versioning, and controlling changes to requirements over the system's life cycle. |
These activities apply at different abstraction levels, stakeholder requirements, system requirements, and software requirements, and they can follow different process models.
RE in Different Process Models
How RE fits into a project depends on the process model:
- Plan-driven models (Waterfall, V-Model): RE is a distinct, time-limited phase at the start. All requirements are elicited and documented before design begins.
- Agile models (XP, Scrum): RE is a continuous activity woven into every sprint. Requirements are elicited just-in-time because predicting future needs is difficult and requirements change.
Neither approach is inherently better, the right choice depends on project constraints, domain stability, and team structure.
According to Boehm's research, approximately what percentage of errors in system development originate during requirements engineering?
- ~60% of project errors originate in requirements engineering
- Fixing a requirements defect costs up to 100x more if caught during acceptance testing vs. during RE
- RE has four core activities: Elicitation, Documentation, Validation & Negotiation, Management
- A stakeholder is anyone who directly or indirectly influences the system's requirements
- RE can be a distinct phase (plan-driven) or a continuous activity (agile) depending on the process model