Unit 3: Requirements Engineering
Learning Objectives
- Write precise functional and non-functional requirements using a standard format
- Apply elicitation techniques appropriate to different stakeholder contexts
- Identify ambiguity, scope creep, and missing acceptance criteria in a requirements set
- Construct a requirements traceability matrix and explain its purpose
Core Input
Read through each tab before working through the key concepts.
Requirements engineering is the systematic process of discovering, documenting, and managing the requirements for a software system. Its quality directly determines the quality of everything that follows: a design built on ambiguous requirements will be ambiguous; a test suite written against vague requirements will be incomplete.
Functional requirements (FRs) specify what the system shall do — specific behaviours in response to inputs or events. A well-formed FR has a clear subject, verb, and measurable outcome:
FR-04: The system shall allow a registered patient to book an available appointment slot with a selected clinician, receiving a confirmation reference number upon successful booking.
Non-functional requirements (NFRs) specify how well the system must perform its functions. Poorly specified NFRs ("the system shall be fast") are not requirements — they are wishes. A well-formed NFR is measurable and testable:
NFR-07: The system shall return appointment search results within 1.5 seconds for 99% of requests when serving up to 500 concurrent users.
NFRs are frequently underspecified in practice. "The system shall be secure" and "the system shall be maintainable" tell an engineer nothing actionable. Specifying NFRs requires identifying the quality attribute, the metric, and the acceptance threshold.
Requirements do not exist in a document waiting to be discovered — they must be actively elicited from stakeholders who often cannot articulate what they need, have conflicting priorities, and may not know what is technically feasible. Elicitation is an active, skilled process.
Common elicitation techniques:
- Interviews — structured or semi-structured conversations with individual stakeholders. Effective for understanding roles, workflows, and priorities. Risk: stakeholders describe what they currently do, not what they actually need.
- Workshops — structured group sessions that bring multiple stakeholders together to negotiate conflicting requirements. More efficient than individual interviews but require skilled facilitation.
- Observation / ethnography — watching stakeholders work in their actual environment. Reveals tacit knowledge and workarounds that stakeholders may not mention in interviews because they consider them normal.
- Prototyping — creating low-fidelity mockups or clickable prototypes to make abstract requirements concrete. Stakeholders find it easier to respond to something tangible than to a written specification.
- Document analysis — reviewing existing systems, processes, and documentation to identify implied requirements and constraints.
In practice, a requirements engineer uses multiple techniques. A single interview is rarely sufficient — requirements elicitation is an iterative process that continues throughout the project.
Ambiguity in requirements occurs when a statement can be interpreted in more than one way. Sources of ambiguity include: unclear pronouns ("it", "they"), relative terms ("fast", "secure", "easy to use"), passive voice that hides agency ("errors shall be handled"), and missing acceptance criteria.
Scope creep is the gradual, uncontrolled expansion of a project beyond its originally agreed boundary. It is driven by stakeholders adding requirements after the baseline is set, often with the reasoning that "it's just a small change." In aggregate, small changes exhaust budgets and delay delivery. Controlling scope requires a defined change management process and a clearly documented system boundary.
Requirements traceability is the ability to follow a requirement forward to the design elements, code, and tests that implement it — and backward to the business or user need that originated it. A requirements traceability matrix (RTM) is a table that maps each requirement ID to the design artefacts, code modules, and test cases that address it. An RTM makes gaps immediately visible: a requirement with no corresponding test case will not be verified; a test case with no corresponding requirement is testing something that was never specified.
Key Concepts: Writing Requirements
Requirements writing is a precision skill. Work through each item carefully.
A well-formed NFR has three components:
- Quality attribute — which quality property does this address? (performance, security, availability, maintainability, etc.)
- Metric — how is this property measured? (response time in milliseconds, uptime as a percentage, defect density per thousand lines of code)
- Threshold — what value must be achieved, and under what conditions?
Compare:
Poorly formed: "The system shall be reliable."
Well-formed: "The system shall achieve 99.9% availability, measured monthly, excluding scheduled maintenance windows of no more than 4 hours per month."
The well-formed version specifies attribute (availability), metric (percentage uptime), threshold (99.9%), measurement period (monthly), and an explicit exclusion (scheduled maintenance).
MoSCoW is a requirements prioritisation framework that classifies requirements into four categories:
- Must have — the system cannot function or be released without this. Non-negotiable.
- Should have — important but not critical; can be deferred to a later release if necessary.
- Could have — desirable but low priority; included only if time and resources permit.
- Won't have (this time) — explicitly out of scope for the current release; may be reconsidered later.
MoSCoW is valuable because it forces stakeholders to make explicit trade-off decisions rather than treating all requirements as equally important. The "Won't have" category is particularly useful for scope management: a requirement that is explicitly out of scope cannot quietly become scope creep.
Identifying ambiguity requires knowing what to look for. Common patterns:
- Vague quantifiers — "the system shall handle many users", "results shall be returned quickly". How many? How quickly?
- Unclear subjects — "errors shall be logged." By what? To where? In what format?
- Combined requirements — a single requirement that covers two distinct behaviours. This makes it impossible to trace to a single test case or design element.
- Missing constraints — "the system shall display appointment availability" — for how far in advance? For which clinicians? In which format?
- Undefined terms — using domain terms ("GP", "referral", "triage") without a shared definition. Different stakeholders may understand these differently.
Requirements validation verifies that a set of requirements correctly and completely represents what the stakeholders need. It is distinct from requirements verification, which checks that requirements are internally consistent and well-formed.
Validation techniques include:
- Stakeholder review — requirements are reviewed by stakeholders (not engineers) who confirm that each requirement reflects their intent
- Prototype walk-through — a working prototype is demonstrated to stakeholders who confirm or correct the interpretation
- Acceptance criteria review — for each requirement, can the stakeholder agree on a concrete test that would confirm it is satisfied?
- Scenario testing — stakeholders are walked through realistic usage scenarios to identify missing or incorrect requirements
A requirement that no stakeholder can validate against a concrete scenario is likely ambiguous or misspecified.
Key Concepts: Scope and Traceability
These concepts underpin requirements governance — the ability to control and audit the requirements process.
Scope creep has two primary causes: inadequate initial scope definition and an absence of change management process. If the system boundary is vague from the start, every stakeholder request can be argued to be in scope. If there is no formal process for evaluating change requests, informal additions accumulate unchecked.
Effective scope control requires:
- A clearly documented, stakeholder-agreed system boundary (use a use case diagram with an explicit boundary rectangle)
- A formal change management process: all post-baseline requirement changes are submitted, assessed for impact (time, cost, risk), and approved or rejected
- A MoSCoW classification so that trade-off decisions are explicit, not implicit
- A change log that records what was added, removed, or deferred, and why
A Requirements Traceability Matrix (RTM) is a table that maps each requirement to the artefacts that implement and verify it. A minimal RTM has columns for: requirement ID, requirement description, design artefact(s), code module(s), and test case(s).
An RTM makes the following gaps immediately visible:
- A requirement with no test case — it will not be verified before release
- A test case with no requirement — it is testing undocumented or gold-plated behaviour
- A design element with no requirement — it is implementing something that was never specified
- A requirement with no design element — it has not been addressed in the architecture
In regulated industries, an RTM is mandatory evidence that every requirement has been implemented and tested. In Agile contexts, lightweight traceability links (e.g. requirement IDs in commit messages and test descriptions) serve the same purpose with less overhead.
These are two distinct activities that are sometimes conflated:
Elicitation is the process of discovering what stakeholders need — through interviews, workshops, observation, and prototyping. Its output is raw understanding: interview notes, workshop outputs, and informal descriptions of needs and constraints.
Specification is the process of translating that understanding into precise, testable, unambiguous statements — the formal requirements. Specification requires applying the discipline of precision: removing ambiguity, adding acceptance criteria, and making implicit assumptions explicit.
The gap between what stakeholders say and what they mean — and between what they mean and what they need — is where most requirements failures originate. Elicitation without specification produces intent without precision; specification without elicitation produces precision without validity.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
A requirement states: 'The system shall be easy to use.' What is the primary problem with this requirement?
An engineer uses observation to watch clinical staff using the existing appointment booking system. What advantage does this have over interviewing the same staff?
AI tools are increasingly used to assist with requirements work — summarising stakeholder interviews, detecting ambiguous language, generating candidate user stories from a brief, and even proposing acceptance criteria.
- Assist: AI can process large volumes of stakeholder interview transcripts to surface common themes, flag contradictions, and draft initial requirements lists — tasks that would take hours manually.
- Risk: AI-generated requirements may be syntactically correct but semantically wrong. They reflect patterns in training data, not the specific needs of your stakeholders. A hallucinated requirement — one that sounds plausible but was never expressed by any stakeholder — can be particularly dangerous because it is difficult to detect without validation.
- Principle: Every requirement, regardless of how it was generated, must be validated with a human stakeholder who can be held accountable for it. AI can accelerate the drafting process; it cannot replace the validation process. The RTM is the engineer's tool for ensuring nothing slips through untested.
Activities
Individual task
Write six requirements for the hospital appointment booking system:
- Three functional requirements — each with an ID, a precise description using "The system shall…", and a one-line acceptance criterion
- Three non-functional requirements — each with an ID, a quality attribute label, a measurable metric, and a threshold with conditions
Apply MoSCoW classification to each requirement: label each as Must, Should, Could, or Won't.
Pair task
Review your partner's six requirements. For each one, assess:
- Is there any ambiguity? Could a developer interpret it differently from how the author intends?
- For NFRs: is the metric specific? Is the threshold realistic and testable?
- For FRs: is the acceptance criterion concrete enough to write a test case from?
- Is the MoSCoW classification defensible? Challenge any "Must have" — what would actually happen if this requirement were deferred?
Provide written feedback using the format: [Requirement ID]: [specific concern] — [suggested improvement]
Group task — case study requirements baseline
As a group, consolidate your individual requirements into a shared requirements baseline for the hospital appointment booking system. Your baseline should contain:
- At least 10 requirements (mix of FR and NFR)
- MoSCoW classification for each
- A brief system boundary statement identifying two explicit out-of-scope items
- A starter RTM — a table with columns: Requirement ID | Description | Design Artefact (to be completed in later units) | Test Case ID (to be completed in Unit 8)
This requirements baseline will be used in Unit 4 (behavioural modelling), Unit 5 (architecture), and Unit 8 (testing). Keep it version-controlled and accessible to all group members.
Review
A well-formed NFR specifies a quality attribute (performance, security, availability), a metric (how it is measured), and a threshold (what value must be achieved and under what conditions). Without all three, the NFR is untestable and effectively unenforceable.
The test: can you write a specific test case that would pass or fail based solely on this requirement? If not, the requirement is not yet well-formed.
An RTM maps each requirement to the design elements, code modules, and test cases that implement and verify it. It reveals four categories of gap:
- Requirements with no test case — unverified before release
- Test cases with no requirement — testing undocumented behaviour
- Requirements with no design element — unaddressed in the architecture
- Design elements with no requirement — gold-plating or scope creep in the design
Proceed to Unit 4: Behavioural Modelling when ready.