Personas tell the team who they are designing for. Scenarios tell the team what those users are trying to do. Requirements turn that understanding into testable obligations on the system. This companion lays out the theory, the practice, and the documented cases where requirements quietly defined entire products.
The three artefacts answer three questions that have to be answered in order. Each one constrains what comes next.
Personas answer who the system is for. Their construction was the subject of the previous companion; if you have not read it, the relevant background is on the Personas: theory and practice page. Personas come from research and carry the team's working memory of its users.
Scenarios answer what those users are trying to do. A scenario is a narrative description of an activity that takes place in some context, told from the user's point of view. Scenarios put the persona into motion: now that we know who Aysha is, what does she actually do on a Tuesday morning when her appointment system goes wrong?
Requirements answer what the system must do or be. A requirement is a verifiable specification: a statement that some property of the system is testable, and that the system either has it or does not. Requirements are the design contract between the team and its stakeholders. They define what "done" means.
The three artefacts have a specific dependency order. Scenarios that do not flow from named personas tend to describe an idealised user who does not exist. Requirements that do not flow from named scenarios tend to describe features in isolation, with no account of when or why anyone would use them. Personas without scenarios are static portraits; scenarios without requirements are stories no one can build to.
"Scenarios bridge the gap between requirements and design. They sit between the abstract description of what users do and the concrete description of how the interface works."
Mary Beth Rosson and John M. Carroll. Usability Engineering: Scenario-Based Development of Human-Computer Interaction. Morgan Kaufmann, 2002.Scenarios are concrete stories of use. They are written in plain language and committed to a specific actor, situation, and goal. Their value lies in the specificity.
John M. Carroll, who established scenario-based design as a discipline, defines a scenario as a description that contains four ingredients (Carroll, 2000):
A scenario is not a use case, although they share a common origin. A use case (Section vii) is a step-by-step description of system-actor interaction, usually written in numbered steps and with explicit success and failure paths. A scenario is the story version of the same situation, written in prose, that gives the use case its motivation and its texture.
Suppose the persona is Aysha, a third-year nursing student who books shifts on a hospital scheduling app from a corridor between rounds, often using one hand because the other is holding a clipboard. A scenario for her might read:
It is 7:42 on Tuesday morning, between Aysha's first and second rounds in Paediatrics. She has fifteen minutes. She opens the scheduling app on her phone, one-handed, to swap her Friday night shift with a colleague who has agreed to it. She finds her shift; she taps "Request swap"; she types her colleague's surname; the system shows a long list of partial matches; she sees the correct colleague third from the top, taps the entry, and writes a short note. The system confirms the request. The next round starts on time.
Notice what this scenario does that an abstract requirement would not. It names the time pressure (fifteen minutes), the input modality (one-handed), the environment (a hospital corridor), and the social context (a colleague has already agreed). These details will turn into very specific requirements: the swap flow has to be completable in fewer than fifteen minutes, the colleague search must work with partial last-name input, and the interface has to be usable one-handed without precise tapping.
Not all scenarios serve the same purpose. Rosson and Carroll's scenario-based design framework distinguishes four types that the team writes at different stages, with different audiences in mind.
Describe how users currently experience the problem the new system is meant to address. They capture the current state of the world, including its frustrations. Problem scenarios make sure the team has a shared understanding of what they are trying to fix.
High-level descriptions of what the new system supports. They identify the activities the user will undertake, without yet specifying how the interface looks or what the screens contain. Activity scenarios drive feature scope.
Add detail about what information is shown to the user and where it comes from. They specify the content the system presents, but not yet the controls or the layout. Information scenarios drive data and content design.
Concrete step-by-step descriptions of how the user interacts with the interface. They specify gestures, screens, error messages, and recovery paths. Interaction scenarios feed the visual and interaction design.
The four types are written in order. A team that jumps to interaction scenarios without first establishing the problem and activity has decided what the buttons do before deciding whether the buttons are needed at all. Rosson and Carroll are explicit that scenario-based design is a process, not a single artefact; the same situation is described at four different levels of detail, each one informing the next.
Practitioner extensions of Carroll's framework add two further useful varieties. A negative scenario describes a situation the system explicitly will not support, mirroring the negative-persona idea. A stress scenario describes a situation at the edge of feasible use: the network is slow, the user is interrupted, the task has to complete in seconds. Stress scenarios surface requirements that pleasant-day scenarios miss.
A requirement is a precise statement about what the system shall do or be, written so that a tester can decide whether the system actually does or is that thing. Without verifiability, a requirement is a wish.
Ian Sommerville (Software Engineering, 10th ed., 2015) gives the canonical practitioner definition: a requirement is "a description of a service that the system must provide, or a constraint on the system". The two clauses matter independently. A service is something the system does (let a user book an appointment, send a confirmation, encrypt a file). A constraint is a property the system has (responds within 1.5 seconds, runs on Android 9 or higher, stores data within the European Union).
The IEEE has codified the same idea as a standard. IEEE Std 830-1998 ("Recommended Practice for Software Requirements Specifications"), now superseded by ISO/IEC/IEEE 29148:2018, lays out the qualities a requirement specification must have: each requirement should be correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable, and traceable. We will return to these in Section v.
Sommerville distinguishes two abstraction levels at which requirements are written.
Both layers exist on most projects. The user requirement preserves the customer's intent in the customer's language; the system requirement gives the design and verification team something they can build to and test against. Each user requirement typically refines into several system requirements.
The IEEE/ISO criteria are not optional polish. Each one corresponds to a way requirements have been observed to fail on real projects.
| Quality | What it means | Why it matters |
|---|---|---|
| Correct | The requirement describes a property the system should have. Faithful to the customer's intent. | An incorrect requirement guarantees a wrong product, however well it is implemented. |
| Unambiguous | Exactly one interpretation. Each natural-language requirement is a hazard; precision is non-negotiable. | Ambiguity lets the developer and the tester read the same words and build to different specifications. |
| Complete | Every situation the system has to handle is covered, with no omissions. | Missing requirements are discovered after release, at the highest possible cost. |
| Consistent | No two requirements contradict each other; no two place the developer in an impossible position. | Conflicting requirements cause one of them to be silently dropped, usually the one whose stakeholder shouts least. |
| Ranked | Each requirement has an explicit priority. Some are critical; others are negotiable under schedule pressure. | Without ranking, scope cuts are made by whoever is in the room at the wrong time. |
| Verifiable | A finite procedure exists that decides whether the system satisfies the requirement. | An unverifiable requirement is a wish; you can neither demonstrate compliance nor diagnose non-compliance. |
| Modifiable | The requirement is structured (uniquely identified, cross-referenced, not duplicated) so a change can be made without breaking other requirements. | Real projects revise requirements continuously; a rigid specification becomes obsolete or wrong. |
| Traceable | The requirement can be linked backward to its origin (a persona, a scenario, a regulation) and forward to the design and tests that realise it. | Traceability is what makes change impact analysis possible. Without it, a small change has unknown consequences. |
The difference is rarely subtle. The bad version reads naturally but cannot be tested; the good version is testable but, with practice, reads almost as naturally.
The bad versions are not always wrong as starting points; they are often perfectly reasonable user requirements (Section iv). They are wrong as system requirements because they do not give the tester anything to test against.
Sommerville's two-axis classification is now standard. The functional axis describes what the system does; the non-functional axis describes how well it does it, and any constraints on how it is built.
A functional requirement describes a service the system must provide. The verb is usually "shall", and the subject is usually the system; the system shall accept, the system shall display, the system shall authenticate. Functional requirements are the most concrete and the easiest to write, which is why teams sometimes stop at them and ship a system that works exactly as described and that no one wants to use.
Example: "The system shall allow a registered patient to request a swap of one of their booked shifts with another nurse on the same shift cycle."
A non-functional requirement constrains how the system behaves, performs, or is built. Sommerville further classifies NFRs into three families:
| Family | Subtypes | Examples |
|---|---|---|
| Product | Efficiency, reliability, portability, usability, dependability, security | Response time, mean time between failures, browser compatibility, accessibility level, password strength |
| Organisational | Operational, development, environmental | The system shall run on the customer's existing PostgreSQL cluster; code shall be reviewed by two developers before merge. |
| External | Regulatory, ethical, legislative | Compliance with the Palestinian Personal Data Protection Law; accessibility per WCAG 2.1 AA; HIPAA-like protections for clinical data. |
NFRs are where the difficult work tends to be. A functional requirement is usually a question of "what shall the system do"; an NFR is a question of "how well, how fast, under what load, for whom, with what guarantees". The IEEE qualities (Section v) bite hardest on NFRs because the natural English form of an NFR is almost always a wish.
On a typical industrial project, the team will produce many more functional requirements than NFRs, but the NFRs are responsible for most of the user-visible quality. A bug in a functional requirement is usually fixable in one sprint; a missed NFR (the system is too slow, too hard to use, too insecure) usually requires architectural change.
Use cases (from object-oriented software engineering) and user stories (from agile) are two of the most widely used formats for capturing scenario-and-requirement work. They are not competitors; they are tools for different stages.
Use cases were introduced by Ivar Jacobson in the late 1980s as part of Objectory and its successor, the Unified Modelling Language. Alistair Cockburn's Writing Effective Use Cases (2001) is the standard practitioner reference. A use case has:
Use cases are heavyweight by design. Cockburn distinguishes "fully dressed" use cases from "casual" ones; the choice depends on project formality. They scale well to large teams and regulated domains where written specifications must survive past the original authors.
User stories were popularised by Kent Beck and the early Extreme Programming community, then developed in depth by Mike Cohn (User Stories Applied, 2004). A user story is a short statement of value:
As a <persona>, I want to <do something>, so that <benefit>.
Each story is meant to be small enough to estimate, build, and test within a single iteration. Bill Wake's INVEST criteria (2003) summarise what a good user story looks like:
| Letter | Criterion |
|---|---|
| I | Independent. The story can be built without depending on others (or with minimal dependencies). |
| N | Negotiable. The story is a placeholder for a conversation, not a fixed contract. |
| V | Valuable. The story produces something the customer or user can recognise as worth having. |
| E | Estimable. The team can give a rough estimate of how long it will take. |
| S | Small. Small enough to complete within one iteration. |
| T | Testable. Acceptance tests can be written before the story is built. |
Use cases and user stories carry the same information at different granularities. A use case typically covers a goal that takes a session to achieve; a user story typically covers a chunk of that goal that takes a sprint to implement. Many teams use both: use cases at the requirements-document level, user stories on the backlog.
When a requirement document says "the system shall be usable", what does it mean? Since 1998, there has been an answer.
ISO 9241-11 (last revised in 2018) defines usability as "the extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use". The phrasing has three obligations baked in.
Can the user actually complete their goal? Measured in completion rate (the proportion of attempts that succeed) and error rate (errors per attempt).
What does it cost the user to complete the goal? Measured in time, effort, number of steps, or mental load.
How positively does the user experience the interaction? Measured by post-task questionnaires (SUS, UMUX), Net Promoter Score, qualitative feedback.
The "specified users" and "specified context of use" clauses connect the standard back to personas and scenarios. A usability claim that does not specify these is a claim that cannot be evaluated, because the answer depends entirely on who is asking and where they are asking it.
A usability requirement written against ISO 9241-11 names all three dimensions explicitly, for example:
For the persona Aysha (third-year nursing student, one-handed phone use in a hospital corridor):
This requirement is verifiable, traceable to a persona, and aligned with a standard. It is also testable in a usability lab in a way "the system shall be easy to use" is not.
Four well-documented cases where a single requirement (or its absence) shaped the eventual product. The point of citing them is that requirements work is not paperwork; the choices made at the requirements stage are visible in the final shape of the system.
When Twitter launched in 2006, posts were limited to 140 characters. The number was not chosen for aesthetic reasons. The original requirement was that a tweet had to fit inside a single SMS message; the SMS standard allows 160 characters, of which Twitter reserved 20 for the username, leaving 140 for the message body.
The requirement was technical at origin, but it propagated into every aspect of the product: the conversational style, the prevalence of hashtags and URL shorteners, the editorial discipline of users, the way news organisations broke stories. When Twitter eventually doubled the limit to 280 characters in 2017, the company published the analysis that justified the change, citing user-behaviour research on how often tweets ran out of room. The 140-character constraint had become so central to the product that loosening it was a strategic decision, not a routine engineering one.
Documented in Twitter's official engineering blog (Rosen, 2017, "Tweeting Made Easier") and discussed extensively in HCI literature on micro-blogging design.At the iPhone's introduction in January 2007, Steve Jobs explicitly framed the absence of a stylus as a requirement, not as a missing feature. The competitive landscape at the time (Palm, Windows Mobile, BlackBerry) was dominated by stylus-driven devices. Apple's requirement was that the device be operable with fingers, in all primary tasks, with no accessory.
This single requirement cascaded into a long chain of design constraints: minimum interactive element size (44 points, codified later in the iOS Human Interface Guidelines), gesture vocabulary (pinch, swipe, tap), keyboard design (the on-screen keyboard had to compensate for finger imprecision), and even the screen technology (capacitive, not resistive). Two decades on, the entire smartphone market converged on touch as the primary input modality, and stylus-first designs survive only in niches (digital art, fields with gloves, large-screen tablets where the stylus is auxiliary, not primary).
Steve Jobs, Macworld Conference keynote, San Francisco, 9 January 2007. The introduction is widely transcribed and the design implications are discussed in iOS Human Interface Guidelines.WhatsApp introduced end-to-end encryption for all messages in 2016, in partnership with Open Whisper Systems (the team behind the Signal protocol). The decision was framed as a non-functional security requirement: messages between users must be cryptographically protected so that no party other than the conversation participants, including WhatsApp itself, can read them.
The requirement reshaped the product in ways far beyond cryptography. Backup and message-history features had to be redesigned (a backed-up message could not be decryptable by the cloud); group dynamics changed (administrators see content but cannot mediate it); a class of moderation interventions became impossible. The same requirement was later adopted by Signal, Apple iMessage (selectively), and Facebook Messenger (in part). E2E encryption moved from a niche concern to a baseline user expectation in messaging in less than five years.
WhatsApp Security Whitepaper (2016) and Marlinspike, M. and Perrin, T. The Double Ratchet Algorithm. Open Whisper Systems, 2016. The product implications are surveyed in Schneier, B. Click Here to Kill Everybody, W. W. Norton, 2018.Early automated teller machines dispensed cash before returning the user's card. The functional requirement was satisfied (the user got their money), but a significant fraction of users walked away without their card. The cause was a memory failure: once the goal (cash) had been achieved, the secondary obligation (retrieve card) was forgotten.
The solution was a requirement change, not a feature addition: the system shall return the card before the cash is dispensed, and shall not dispense cash until the card is removed. The pattern is now universal across ATMs and is sometimes called "forcing functions" after Don Norman's analysis in The Design of Everyday Things. The case is canonical in HCI teaching because it shows how a usability problem with a clear behavioural signature was solved at the requirements level, not by tweaking the interface.
Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books. Chapter 5 on slips and forcing functions.Each of these cases shares a structure: the requirement was non-obvious at the time it was made, it cascaded into many downstream decisions, and the product would have been a different product without it. Spending time on the requirements stage is not procedural; it is where the product's identity is decided.
These are recurring patterns in scenarios-and-requirements work, drawn from Sommerville, Robertson and Robertson (Mastering the Requirements Process), and the HCI literature on requirements practice.
If the team does not know who the system is for, every requirement becomes a guess about which user matters more. The result is a specification that contradicts itself when the user community is asked to confirm it.
"The system shall use a drop-down list to select the doctor" prescribes the design before the design is done. The right form is "The system shall let the user select a doctor from the available list", leaving the control choice to interaction design.
Easy, fast, friendly, intuitive, modern, robust, reliable. Each one passes natural-language reading, none passes verifiability. Replace with a measurable property and a threshold.
"The system shall be fast and secure" mixes two unrelated NFRs. They have different acceptance criteria, different stakeholders, and different test procedures. Split them.
"All requirements are critical" is the equivalent of "there is no plan for scope cuts under pressure". Schedule pressure happens; rank the requirements explicitly so the team knows what survives.
A requirement that does not link to a persona, a scenario, a regulation, or a stakeholder request is an orphan. When a reviewer asks "why is this here?", the answer should be in the requirement's traceability link, not in someone's memory.
A complete-looking specification that lists only what the system shall do, with no NFRs, has not specified the system. The result is a system that does everything correctly and is unusable, unreliable, or unsafe.
Real projects discover new requirements after the spec is "frozen". Treating the requirement document as immutable forces the team to either ship the wrong thing or to maintain a shadow spec. The right answer is a versioned spec with a documented change process.
The course textbook is identified at the head of the list; the rest are the works directly referenced in the body.