Requirements Engineering Process
Definition
Requirements Engineering (RE) is the umbrella discipline covering all activities involved in discovering, analyzing, documenting, validating, and managing software requirements throughout the project lifecycle.
The Complete RE Process
┌─────────────────┐ ┌──────────────────┐ ┌───────────────────┐
│ Requirements │──▶│ Requirements │──▶│ Requirements │
│ Elicitation │ │ Analysis & │ │ Specification │
│ (gathering) │ │ Negotiation │ │ (SRS document) │
└─────────────────┘ └──────────────────┘ └───────────────────┘
│
▼
┌───────────────────┐
│ Requirements │
│ Validation │
└───────────────────┘
│
▼
┌───────────────────┐
│ Requirements │
│ Management │
│ (ongoing) │
└───────────────────┘
Sub-Processes Explained
- Feasibility Study — assess whether the project is technically, financially, and operationally viable (often precedes formal RE)
- Elicitation — gather requirements from stakeholders
- Analysis & Negotiation — classify, resolve conflicts, prioritize
- Specification — document formally as SRS (per IEEE 830 or similar)
- Validation — verify SRS correctness/completeness with stakeholders
- Management — handle change throughout the project (traceability, version control)
Key Distinction: RE vs. Requirement Analysis
- Requirements Engineering = the entire end-to-end discipline (all 6 activities above)
- Requirement Analysis = specifically the "classify, resolve conflict, prioritize" sub-step within RE
Why RE is Treated as a Continuous Process
Unlike a one-time activity, requirements keep evolving — so RE (especially elicitation, validation, and management) continues throughout the SDLC, not just at the start.
Exam tip: Draw the full RE process diagram (5–6 boxes with arrows) — examiners frequently ask to "draw and explain the Requirements Engineering process."