Key Concepts
Requirements tell you WHAT to build. Getting them right is harder than writing the code.
Functional Requirements
What the system should DO — specific behaviors, inputs, outputs, and operations.
Non-Functional Requirements
Constraints on HOW the system works — performance, security, reliability, usability.
Requirements Elicitation
Techniques to discover what stakeholders actually need — interviews, observation, prototyping, scenarios.
Requirements Validation
Checking that requirements actually define the system the customer wants before you build it.
Concept Deep Dives
Click each concept to expand — real examples, diagrams, pros & cons.
Functional Requirements
When to Use
Always required — defines the system's core capabilities.
Real-World Example
'A user should be able to reset their password via email' — specific, testable, behavioral.
✓ Advantages
- Directly testable
- Clear acceptance criteria
- Maps to user stories
⚠ Watch Out
- Easy to over-specify (becomes design, not requirements)
- Can miss non-functional needs
Non-Functional Requirements
When to Use
Always — these define quality and are often harder to retrofit than functional features.
Real-World Example
'The login page must load in <500ms' / 'System must be available 99.9% uptime' / 'GDPR compliant'.
✓ Advantages
- Define quality standards
- Drive architectural decisions
- Prevent scope creep on quality
⚠ Watch Out
- Hard to test objectively
- Often vague ('must be fast') — need quantification
Requirements Elicitation
When to Use
Project start — before writing a single line of spec.
Real-World Example
Airbnb's founders actually stayed in people's homes to understand pain points before building features.
✓ Advantages
- Reveals hidden needs
- Uncovers conflicting stakeholder goals
- Builds shared understanding
⚠ Watch Out
- Stakeholders don't always know what they want
- Time-consuming
- Political stakeholder dynamics
Requirements Validation
When to Use
After requirements are written — before development begins.
Real-World Example
A requirements review catching a contradiction before dev saves 10-100x the cost of fixing it in production.
✓ Advantages
- Prevents costly rework
- Ensures completeness and consistency
- Aligns stakeholders
⚠ Watch Out
- Requires time and stakeholder availability
- Can be a bottleneck
Quick Reference
- 1Requirements engineering: process of establishing the services a customer requires and the constraints.
- 2Functional requirements: what the system should do — specific behaviors and outputs.
- 3Non-functional requirements: constraints on system qualities — performance, security, reliability.
- 4User requirements: high-level, natural language statements for stakeholders.
- 5System requirements: detailed technical description for developers.
- 6Requirements elicitation: interviews, scenarios, ethnography, prototyping.
- 7Requirements validation: reviews, prototyping, test case generation — done BEFORE development.
- 8Requirements always change — manage them with traceability and change control.
From the Book & Beyond
Case Study — Mentcare's Drug-Cost Report Requirement
Sommerville's Figure 4.1 shows exactly how vague turns into precise. One user requirement — "The Mentcare system shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month" — expands into five system requirements: generate the summary on the last working day, produce it for printing after 17.30, list drug names, prescription counts, doses and total cost per clinic, create separate reports for each dose unit (10mg, 20mg, etc.), and restrict access to an authorized-user list. Same need, two audiences: managers read the first; developers build from the second.
2026 Perspective — LLMs Draft, Humans Elicit
In 2026, an LLM can turn "monthly drug-cost reports" into a polished list of system requirements in seconds — and spec-driven workflows, where a reviewed spec drives AI code generation, make requirements documents matter more, not less. But the model only elaborates what it's told. Elicitation is still human work: stakeholders contradict each other, can't articulate tacit knowledge, and don't know what's feasible — problems this chapter lists that no autocomplete fixes. The 2026 risk is new, though: AI-generated requirements look complete, making validation reviews more critical than ever.
Quiz — Test Yourself
Think through your answer first, then reveal.