1.5 Requirements Engineering

Requirements Engineering (RE) is the systematic process of discovering, analysing, documenting, validating and managing the requirements for a software system. It is the most important phase of the SDLC — fixing a requirement bug after release costs 100–200× more than fixing it during RE (Boehm's curve).

The Requirements Engineering process

---

Types of Requirements

Requirements split into two top-level categories:

Requirements
    │
    ├── Functional Requirements (FRs)
    │     "What the system must do"
    │     • Login authentication
    │     • Generate invoice
    │     • Send email confirmation
    │
    └── Non-Functional Requirements (NFRs) / Quality Attributes
          "How well the system must do it"
          • Response time < 2 sec
          • 99.9% uptime
          • Support 10,000 concurrent users

Functional Requirements (FRs)

Functional requirements describe what the system does — the visible behaviour. They are usually expressed as user-facing actions:

• The system shall allow a user to register with name, email and password.
• The system shall send an OTP to the user's mobile on login attempt.
• The librarian shall be able to issue a book to a registered member.

Non-Functional Requirements (NFRs)

NFRs describe how well the system performs — they are constraints and qualities. The standard categories are:

Exam tip: A common short-answer question asks for 3 functional and 3 non-functional requirements for a library system. Example FRs: issue book, return book, search catalogue. Example NFRs: response < 1 sec, 99.9% uptime, role-based access control.

---

Domain Requirements

A third category — sometimes treated separately — is domain requirements: requirements that come from the application domain rather than the user.

• Banking domain: "All transactions ≥ ₹50,000 must trigger a compliance flag" (RBI rule)
• Healthcare: "Patient records must be retained for 7 years" (Indian Medical Council Act)
• Aviation: "All commands must be acknowledged within 200 ms" (DO-178C)

These are often invisible to users but mandatory.

---

Requirements Elicitation — Techniques

Getting requirements out of stakeholders is hard. Stakeholders may not know what they want, may say what they think the developer wants to hear, or may have conflicting interests. Elicitation techniques include:

---

Characteristics of Good Requirements

A well-written requirement is SMART (Specific, Measurable, Achievable, Relevant, Time-bound), plus several software-specific properties:

---

Requirements Validation

After the SRS is written, it must be validated — confirmed to be what the stakeholders actually want. Techniques:

• Reviews / inspections — walk through SRS with stakeholders
• Prototyping — show a working model
• Test-case generation — if a requirement cannot be tested, it is not well-written
• Requirements modelling — convert to DFD, UML, ER and check consistency

---

Requirements Management & Traceability

Requirements change throughout a project. A change-control system is essential:

1. Identify — every requirement has a unique ID (FR-001, NFR-PERF-003)
2. Trace forward — each requirement maps to design elements, code modules, test cases
3. Trace backward — each design element / code module justifies itself against a requirement
4. Track changes — Change Control Board (CCB) approves modifications

Requirements Traceability Matrix (RTM)

The RTM is the single most useful tool for showing auditors and regulators that "every requirement is covered."

---

Key Terms — Lesson 1.5

The vocabulary below is what an examiner expects you to deploy fluently when discussing requirements engineering. Each term has appeared in at least one recent PYQ.

Requirement — A statement of what a system must do or what quality it must have, expressed in a form that is testable, traceable, and agreed by stakeholders. IEEE 610.12 defines a requirement as "a condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document."

Requirements Engineering (RE) — The systematic, disciplined process of discovering, analysing, documenting, validating, and managing the requirements for a software system. RE is the most economically important phase of the SDLC because defects introduced in RE cost 100–200× more to fix in production than to fix during RE.

Stakeholder — Any person or organisation with an interest in the system — end users, customers, sponsors, managers, regulators, operators, maintainers, even competitors. Different stakeholders have different requirements and the RE process must reconcile them.

Elicitation — The first activity of RE: gathering raw requirements from stakeholders. Techniques include interviews (structured, unstructured), questionnaires, brainstorming, observation/ethnography, document analysis, prototyping, and JAD workshops. The defining challenge is that stakeholders frequently do not know exactly what they want.

JAD (Joint Application Design / Development) — A structured, facilitated workshop technique pioneered by IBM in the late 1970s, where business stakeholders, users, and developers spend several days in a room hammering out requirements together. The facilitator owns the process; the participants own the content.

Functional Requirement (FR) — A statement of what the system must do — a behaviour, action, calculation, or response. Example: "The system shall send an OTP to the user's mobile on login attempt." FRs are typically numbered (FR-001, FR-002) and grouped by user role or feature area.

Non-Functional Requirement (NFR) — A statement of how well the system must do something — a quality attribute or constraint. Categories include performance, reliability, availability, security, usability, maintainability, portability, scalability, compliance, and interoperability. NFRs are often the architecture-shaping requirements: "10K concurrent users" or "99.99% uptime" decides hosting, redundancy, and database choices long before any FR is implemented.

Domain Requirement — A requirement that originates in the application domain rather than from a specific user. Banking RBI rules ("transactions over ₹50,000 must trigger a compliance flag"), healthcare retention laws ("records kept for 7 years"), and aviation timing constraints ("commands acknowledged within 200 ms") are domain requirements — often invisible to users but mandatory.

SRS (Software Requirements Specification) — The formal documented output of the RE process, capturing all functional, non-functional, and domain requirements, plus interface specifications, assumptions, constraints, and acceptance criteria. SRS is the contract between customer and developer. IEEE 830 provides a standard template.

SMART Requirement — A requirement that is Specific, Measurable, Achievable, Relevant, and Time-bound. Together with the software-specific qualities (complete, consistent, unambiguous, verifiable, feasible, necessary, modifiable, traceable, prioritised), SMART defines a well-written requirement.

MoSCoW Prioritisation — A prioritisation scheme that classifies requirements into four buckets: Must have (non-negotiable), Should have (important but not vital), Could have (nice-to-have), and Won't have this time (deliberately deferred). MoSCoW forces hard prioritisation conversations and protects against the "everything is P1" trap.

Requirements Validation — Confirming that the captured requirements correctly express what the stakeholders actually want — i.e., that we are building the right thing. Validation techniques: stakeholder reviews and walk-throughs, prototyping (show, don't tell), test-case generation (un-testable requirements are not well-written), and modelling for consistency checks.

Requirements Verification — Confirming that the specification is internally consistent, complete, and unambiguous — i.e., that the document itself is well-formed. Verification is checking the document against quality criteria; validation is checking the document against stakeholder needs.

Traceability — The ability to follow a requirement forward to the design element that implements it, the code module that delivers it, and the test case that verifies it — and backward from each implementation artefact to the requirement that justifies it. Without traceability, no one can prove that a requirement was actually implemented.

Requirements Traceability Matrix (RTM) — The tabular artefact that records the traceability for every requirement — source, design element, code module, test case, and status. Auditors and regulators use the RTM to confirm coverage; it is the single most useful artefact for demonstrating compliance.

Use Case — A description of how a user interacts with the system to achieve a goal, including the main success scenario and alternative/exception flows. Use cases are written in plain language (or UML notation) and serve as a bridge between requirements and design. A use-case diagram (UML) shows actors, system boundary, and use cases at a glance.

Scenario — A specific, concrete instance of how a use case might play out — "Rohit logs in with email, password expired, system prompts for reset, Rohit completes reset, system grants access." Scenarios are useful for elicitation (stakeholders can react to a specific story) and for test case generation.

Actor (UML) — Any external entity (a user, another system, a sensor, a timer) that interacts with the system under specification. Actors are represented as stick figures in UML use-case diagrams; the same person can be multiple actors if they play multiple roles.

Change Control Board (CCB) — The committee that reviews, approves or rejects proposed changes to baselined requirements. The CCB exists to prevent uncontrolled scope creep: every change is evaluated for impact on schedule, cost, scope, and other requirements before being approved.

Gold Plating — The anti-pattern of adding features that no stakeholder asked for simply because they seem nice. Common symptoms: SRS contains features no stakeholder can defend; effort is spent on speculative functionality. Cure: rigorous traceability — every requirement must map to a documented source.

Requirements Creep / Scope Creep — Uncontrolled growth of requirements during the project, often through informal channels rather than CCB-approved change requests. Scope creep is one of the leading causes of project failure and is the central reason the CCB and the RTM exist.

Specification by Example (SBE) — A technique (popularised by Gojko Adzic) of specifying requirements with concrete examples of inputs and expected outputs, often written in Given/When/Then form. SBE-style specifications can be executed by tools (Cucumber, SpecFlow) as automated acceptance tests — the specification becomes its own test suite.

Behaviour-Driven Development (BDD) — A development practice that pairs SBE with TDD: requirements are captured as executable scenarios in Given/When/Then form that drive both the conversation with stakeholders and the implementation of tests and code. BDD is to acceptance-level requirements what TDD is to unit-level.

---

Study deep: requirements pitfalls

1. "Gold plating." Developers (or users) add features that no one asked for, simply because they seem nice. Symptom: SRS has features no stakeholder can defend. Cure: traceability — every requirement must map to a documented source.

1. The "yes-man" customer. A customer who agrees to every requirement is dangerous. They may be agreeing to escape a long meeting. Cure: re-validate with prototype, ask them to show (not tell) how they will use the feature.

1. Ambiguous adjectives. "Fast," "easy," "user-friendly," "robust" are all unmeasurable. Replace with numbers: "5-second median response," "trainable in 30 minutes," "handles 10 K concurrent connections."

1. The "all requirements are P1" trap. When everything is "must-have," nothing is. Use MoSCoW (Must / Should / Could / Won't) to force prioritisation.

1. Functional vs Non-functional confusion. A login feature is FR. That login must succeed in under 2 seconds is NFR. That login data must be encrypted in transit is NFR (security). Both decorate the same feature.

1. Requirements evolve. No matter how good your RE process, change is inevitable. Boehm's law: requirements change will happen — the only choice is whether your process accommodates it (Agile) or fights it (Waterfall).

PYQ pattern: "Differentiate functional and non-functional requirements. List five characteristics of a good requirement." — Quote the table above; characteristics: complete, consistent, unambiguous, verifiable, feasible.