The RE process is not a single step; it is a cycle of discovery and refinement. If you get this wrong, the entire project will fail, no matter how good your code is.
🔄 The Four Main Activities
The RE process generally follows these four recurring steps:
1. Requirements Elicitation (Discovery) 🔍
This is the "detective work." You gather information from stakeholders (users, managers, customers) to find out what they need.
Methods: Interviews, surveys, brainstorming sessions, observation, and analyzing existing systems.
The Challenge: Users often don't know what they want, or they find it hard to explain.
2. Requirements Analysis & Negotiation ⚖️
Once you have a big pile of "wants," you have to filter them.
Analysis: Checking for conflicts (User A wants the app to be blue, User B wants it green) or impossibilities (The app must work without internet, but update in real-time).
Negotiation: Talking to stakeholders to decide which features are "Must-Haves" vs. "Nice-to-Haves" based on budget and time.
3. Requirements Specification (Documentation) 📄
The finalized requirements are written down in a formal document called the SRS (Software Requirements Specification).
This document becomes the "Source of Truth" for the developers, testers, and the client.
4. Requirements Validation ✅
Before coding starts, we must double-check the document. We ask:
Are the requirements complete?
Are they clear and unambiguous?
Can they actually be tested?
📝 Types of Requirements
In Software Engineering, we divide requirements into two critical categories:
Type | Definition | Example |
|---|---|---|
Functional Requirements | What the system should DO. (Features) | "The system must allow users to reset their password via email." |
Non-Functional Requirements | How the system should BE. (Constraints/Quality) | "The system must load in under 2 seconds." or "The system must be secure." |
🛠️ Requirements Management
Requirements are not static; they change throughout the project. Requirements Management is the process of:
Tracking changes to requirements.
Managing the "Traceability" (Linking a requirement to the specific piece of code or test case that satisfies it).
⚠️ Why do we need this process?
Without a formal RE process, projects suffer from "The Gap":
The Gap: The difference between what the user thought they said, what the developer thought they heard, and what was actually built.
💡 Analogy: If you ask a contractor to build a "nice house" without a blueprint (SRS), you shouldn't be surprised if they build a cottage when you wanted a skyscraper.