Tell functional from non-functional requirements, write both so they can be tested, and organise them in a specification.
Why it matters
A system can do everything users asked for and still fail: it is too slow at 9 a.m. when everyone logs in, it leaks members' phone numbers, or it does not work with a screen reader. Those are not missing features; they are missing qualities. Analysts capture both kinds of requirement, because teams naturally focus on features and forget the rest until it is expensive to fix.
The two kinds
- A functional requirement describes what the system must do: a behaviour, a calculation, a rule, a piece of data it must store or show.
- A non-functional requirement (NFR) describes how well the system must do it, or the constraints it must respect: speed, security, availability, usability, accessibility, compliance.
A quick test: if you can describe it as "the system shall [verb] [something]", it is usually functional. If it describes a property that applies across many functions ("every page", "all data", "at all times"), it is usually non-functional.
Riverside Library examples
| Requirement | Kind | Category |
|---|---|---|
| A member can book a free room for up to 2 hours | Functional | Booking |
| The system sends a confirmation email when a booking is saved | Functional | Notifications |
| A librarian can cancel any booking and record a reason | Functional | Administration |
| The availability page loads in under 2 seconds for 95% of requests | Non-functional | Performance |
| Members' phone numbers are visible only to library staff | Non-functional | Security and privacy |
| Booking works with a keyboard alone and with common screen readers (WCAG 2.2 AA) | Non-functional | Accessibility |
| The service is available 99.5% of the time during opening hours | Non-functional | Availability |
| Booking data is deleted 12 months after the meeting date | Non-functional | Data retention and compliance |
Notice the privacy example: "only staff can see phone numbers" sounds like a rule, and some teams record it as functional. The label matters less than writing it down and testing it. Classify consistently within a project.
Common NFR categories
A checklist helps because nobody volunteers these in interviews:
- Performance: response times, throughput, peak load.
- Scalability: growth in users or data.
- Availability and reliability: uptime, recovery time after failure, backups.
- Security and privacy: who can see and change what, logging, data protection law.
- Usability and accessibility: task completion, WCAG level.
- Compatibility: browsers, devices, other systems it must talk to.
- Maintainability and supportability: logging, monitoring, who supports it.
- Compliance: legal, regulatory and policy rules.
Many teams use a model such as ISO/IEC 25010, which lists software quality characteristics, as a fuller checklist.
Writing requirements that can be tested
Bad: "The system must be fast." Better: "The availability page shows results within 2 seconds for 95% of requests, with 50 members using it at once."
The better version has a measure (seconds), a threshold (2), a percentile (95%) and a condition (50 concurrent users). A tester can check it. The same applies to functional requirements: "the system handles cancellations" becomes "a member can cancel their own booking up to 24 hours before the start time; after that, only a librarian can cancel".
A few writing rules:
- One requirement per statement. "Members can book and cancel rooms" is two requirements.
- Use "must" or "shall" consistently for mandatory items.
- Avoid vague words: fast, easy, user-friendly, flexible, robust, as appropriate.
- Give each requirement an ID (FR-07, NFR-03) so it can be traced to stories, tests and goals.
- Record the source: who asked for it and why.
Where they live
On a traditional project, requirements go into a specification document, often called a business requirements document (BRD) or software requirements specification (SRS). On agile teams, functional requirements become user stories with acceptance criteria, while NFRs usually become constraints that apply to every story, often written into the team's Definition of Done ("every page meets WCAG 2.2 AA") or as separate technical stories. Either way, a traceability matrix linking each requirement to its goal and its tests shows nothing has been lost.
Common mistakes
- Forgetting NFRs until a performance or security problem appears in testing or, worse, in production.
- Unmeasurable NFRs ("secure", "scalable") that nobody can test.
- Gold-plating: demanding 99.999% availability for a library booking system. Every extra nine costs money; ask what the business really needs.
- Solutions disguised as requirements: "must use database X" is a constraint only if there is a real reason.
Quick recap
- Functional requirements say what the system does; non-functional requirements say how well, or under what constraints.
- Use a category checklist to find NFRs, because stakeholders rarely mention them.
- Make every requirement measurable, single, identified and traced.
- On agile teams, NFRs often live in the Definition of Done.