Requirements Gathering and the Six Categories
What Is Requirements Analysis?
Requirements gathering and analysis is the process of establishing what a system should do and the constraints it must operate within, before committing to a design. Its three main aims are:
- To understand the users and their tasks well enough to design for them — not for an imagined “average user.”
- To avoid costly late-stage redesign (fixing a requirements error during coding costs roughly 5× what it costs during design; fixing it in production costs 100× or more).
- To produce a documented basis against which the final design can be evaluated — a clear, testable specification of what constitutes success.
In User-Centred Design (UCD), requirements analysis is the first phase of the iterative cycle and feeds directly into user research, prototyping, and evaluation.
The Six Categories of Requirements
Interaction design requirements are broader than software engineering’s familiar functional/non-functional split. The course uses a six-category framework:
| Category | Description | Example (taxi booking app) |
|---|---|---|
| Functional | What the system does — features and functions | Request a ride; view driver location in real time; pay in-app; rate driver; schedule advance bookings |
| Data | What data is needed, generated, stored, or transmitted, and in what format | Pickup/drop-off GPS coordinates; payment card token; trip history; driver availability data |
| Environmental | The physical, social, and technical context of use | Used outdoors, often one-handed while carrying bags; variable network coverage in rural areas; used in daylight and darkness (screen contrast); social context: may be used in a group |
| User Characteristics | Skill level, frequency of use, physical/cognitive constraints, accessibility needs, age range | Wide age range including tourists unfamiliar with the city; occasional users (low frequency → favour Recognition over Recall); some users with visual or motor impairments |
| Usability Goals | Effectiveness, Efficiency, Safety, Utility, Learnability, Memorability (Nielsen/Preece framework) | Efficiency (fast booking under time pressure); Safety (accurate location, no incorrect fare); Learnability (first-time tourist use) |
| UX Goals | The subjective, emotional, and experiential qualities | Feeling of trust and control; low anxiety while waiting for pickup; satisfying to use |
Worked Example: Requirements for Two Contrasting Systems
Air Traffic Control Scheduling System
| Category | Detail |
|---|---|
| Functional | Display real-time aircraft positions; propose take-off/landing sequencing; allow manual override; log all decisions for audit |
| Data | Radar/transponder feeds, runway status, weather data, flight plans — all with extremely high accuracy and low-latency requirements |
| Environmental | High-stress control-room environment; shared display among multiple controllers (collaboration); 24/7 operation; must remain usable under emergency conditions |
| User Characteristics | Highly trained expert users (frequent, expert use → favour Recall-based shortcuts and dense information display over novice-friendly wizards) |
| Usability Goals | Safety is paramount (errors can be fatal); Effectiveness; Efficiency under time pressure — this is a first-wave HCI, task-based, efficiency-driven design problem |
| UX Goals | Largely secondary to safety and efficiency here — illustrating that not all systems weight the six categories equally |
The contrast between a taxi app and an ATC system is instructive: the same six categories apply, but the weighting and specific contents differ radically. A good exam answer shows awareness of which categories matter most for this system and justifies the weighting.
Why the Six-Category Framework Matters
In exam scenarios, you will often be given a brief description of a system (a mindfulness app for students, a COVID-19 contact-tracing app, a career-guidance platform) and asked to “suggest key requirements.” The six-category framework gives you a systematic approach:
- Functional requirements describe what the system does.
- The five non-functional categories describe constraints and context — and often dictate the architecture and design more severely than the functional requirements do.
A requirement must be testable and falsifiable — phrased as a statement the team can point to and say “this is satisfied” or “this is not satisfied.” Vague adjectives (“user-friendly,” “fast,” “intuitive”) do not qualify.
Expected Learning
- Name the six categories of requirements and give a specific, testable example of each for any given system scenario.
- Explain why the same six categories weight differently for contrasting systems (e.g. a consumer app vs a safety-critical control system).
- Distinguish usability goals (objective, measurable: learnability, efficiency) from UX goals (subjective, experiential: satisfying, enjoyable, motivating).
- Phrase requirements as testable, falsifiable statements rather than vague adjectives.
Past Paper Questions
Stakeholder analysis and requirements appear in every single Tripos sitting without exception. The worked Example Sheet 1 (Supervision 1, Question 1) directly asks for the six categories applied to a taxi app and an air traffic control system — the model answer is in the Examinable Material section. Past Tripos questions include: 2025 Q5 (career-guidance app — sketch screens + requirements), 2024 Q5 (ChatGPT — stakeholder interview questions), 2023 Q6 (mindfulness app — stakeholders, requirements, design principle), 2022 Q6 (COVID-19 app — data-gathering, stakeholders, requirements, design principle).