Requirements Engineering

Requirements Engineering (RE) is the process of figuring out what to build before you build it — and making sure everyone agrees on that. It bridges the gap between what a customer wants and what the development team actually delivers. Done well, it prevents the most expensive kind of bug: building the wrong thing.

Software requirements fall into two main types:

Functional Requirements: Defines what the system must do (e.g., “The system must allow users to reset their passwords via email”).
Non-functional Requirements: Defines how the system operates - the criteria used to judge its operation rather than specific behaviors.
- Execution qualities: Security, usability, performance (observable at run time).
- Evolution qualities: Testability, maintainability, scalability (embodied in the static structure).

The Four-Step Process

1. Feasibility Study

Before gathering deep requirements, determine if the project is actually viable:

Technical Feasibility: Do we have the technology and expertise to build this?
Operational Feasibility: Will it actually solve the business problem?
Economic Feasibility: Will it generate ROI or fit within the budget?

2. Requirement Elicitation and Analysis

This is the gathering phase. Analysts work with stakeholders and users to identify needs, resolve conflicting requests, and identify missing details.

Common elicitation techniques:

Technique	Description	Best For
Interviews	One-on-one structured or unstructured conversations with stakeholders	Deep domain knowledge extraction
Workshops	Facilitated group sessions (e.g., Joint Application Development)	Resolving conflicting requirements
Observation	Watching users perform their actual tasks in their real environment	Discovering implicit, undocumented workflows
Questionnaires	Structured surveys distributed to a wide audience	Gathering broad input from many stakeholders
Prototyping	Building a low-fidelity mockup for stakeholders to react to	Clarifying vague or unclear requirements
Document Analysis	Reviewing existing documentation, reports, and legacy systems	Understanding existing workflows

Common challenges:

Stakeholders often don’t know exactly what they want.
Stakeholders use domain-specific language, while developers use technical language.
Political or organizational factors may skew requirements.
Requirements change while the analysis is still ongoing.

3. Software Requirement Specification (SRS)

The SRS is the formal document translating customer needs into technical specifications that the development team can build from.

Common modeling tools used in an SRS include:

Data Flow Diagrams (DFD): Shows how data moves through the system.
Entity-Relationship (E-R) Diagrams: Detail the logical representation of data entities and their relationships.
Data Dictionaries: Centralized repositories defining all data items to ensure the customer and developers use the exact same terminology.

User Stories

In Agile projects, the SRS is often replaced or supplemented by User Stories - short, informal requirement descriptions written from the perspective of the end user.

Format:

As a [type of user], I want [goal], so that [benefit/reason].

Example:

As a registered customer, I want to reset my password via email, so that I can regain access to my account if I forget my credentials.

Each user story is paired with Acceptance Criteria — a set of conditions that must be met for the story to be considered complete. Acceptance criteria are often written in Given/When/Then format:

Given I am on the login page, When I click “Forgot Password” and submit my email, Then I should receive a password reset link within 2 minutes.

Acceptance Criteria vs. Definition of Done

These are often confused, but they operate at different levels:

	Acceptance Criteria	Definition of Done (DoD)
Scope	Per user story	Entire team / all stories
Written by	Product Owner	Team (agreed collectively)
Covers	Business behavior of this feature	Technical quality gate (tests pass, code reviewed, deployed to staging, docs updated, etc.)
Changes	Every story	Rarely — agreed at sprint start

A story can satisfy all its Acceptance Criteria and still fail the DoD if, say, no code review was done or automated tests weren’t written.

4. Software Requirement Validation & Management

Before development begins, requirements must be validated to ensure they are correct, complete, practical, and unambiguous.

Validation Techniques:

Inspections: Systematic manual analysis.
Prototyping: Building an executable mock-up model so stakeholders can “see” the requirement.
Test-case generation: If you can’t write a test for a requirement, it’s too vague.

Prioritization: MoSCoW Method

Not all requirements are equally critical. The MoSCoW method is a widely used prioritization technique that categorizes each requirement into one of four buckets:

Priority	Label	Meaning
🔴 M	Must Have	Non-negotiable. The product cannot launch without this.
🟠 S	Should Have	Important but not vital. A significant omission, but workarounds exist.
🟡 C	Could Have	Desirable but not necessary. Included if time and budget allow.
⚫ W	Won’t Have	Agreed to be out of scope for this iteration. May be revisited later.

Applying MoSCoW early ensures that if time or budget is cut, the most valuable features are guaranteed to ship.

What Makes a Good Requirement?

A complete Software Requirement Specification should be:

Clear and unambiguous
Correct and consistent (requirements shouldn’t contradict each other)
Verifiable (testable)
Prioritized (must-have vs. nice-to-have)
Traceable (you should be able to map every feature back to a business requirement)