The quality attributes nobody writes down, such as performance, security and accessibility, with the categories to work through, worked examples, and templates for making each one measurable.
What Are Non-Functional Requirements?
Functional requirements describe what a system does. Non-functional requirements describe how well it does it — the quality attributes that decide whether a feature that passes its tests is actually fit to put in front of real users. They are the adjectives: fast, secure, accessible, scalable, reliable, maintainable. A feature can satisfy every functional requirement and still be too slow to bear, too leaky to trust or impossible to use with a screen reader. The non-functional requirements are what close that gap.
They tend to be the ones nobody writes down. Features are easy to imagine and easy to demand; performance, security and accessibility are ‘cross-cutting concerns’ that belong to the whole product rather than to any one story, so they slip through unless someone is explicitly made responsible for them. This appendix is the inventory to work against. Where Functional vs Non-Functional Requirements explains the distinction and where the line gets blurry, this appendix gives you the categories, concrete and measurable, and the mechanics of documenting them so they survive contact with delivery.
The shape of the distinction, set side by side, is the quickest way in. A functional requirement names a capability; the non-functional requirement sitting beside it sets the bar that capability has to clear in production.
| Functional requirement | Non-functional requirement |
|---|---|
| User can upload a photo | Photos upload within 5 seconds |
| User can log in | Login handles 10,000 concurrent users |
| System sends a confirmation email | Email delivers within 30 seconds |
| Customer transfers money | Transaction completes within 3 seconds |
| System generates a report | Report ready within 30 seconds for 100K records |
The left-hand column creates the feature; the right-hand column makes it production-ready. Appendix A works through how to tell the two apart, including the cases where it is genuinely arguable; this appendix takes the distinction as given and catalogues the right-hand side.
The categories
A non-functional requirement is most useful when it is pinned to a number, a standard or an objective threshold. The categories below are the ones that recur across most products. Treat the table as a checklist to run a feature against — not every row applies to every product, but the question ‘have we said anything about this?’ is worth asking of each.
| Category | What it constrains | Example measurable requirement |
|---|---|---|
| Performance | How quickly the system responds and how much load it carries — response time, throughput, resource usage | Search results return within 500ms for 95% of queries; system handles 1,000 concurrent users without degradation |
| Security | How identity is proved, what users may do and how sensitive data is protected | All passwords hashed using bcrypt with a cost factor of 12; all data encrypted at rest (AES-256) and in transit (TLS 1.3) |
| Accessibility | Whether everyone can use the interface, including people relying on assistive technology | All interfaces meet WCAG 2.1 Level AA; all functionality operable by keyboard; colour contrast at least 4.5:1 for normal text |
| Scalability | How the system copes as users, data or geography grow | Architecture supports horizontal scaling to 50 application servers; database partitioning supports 500M records |
| Reliability and availability | How much uptime is expected, how the system degrades and how fast it recovers | 99.9% uptime (ie. no more than 8.76 hours of downtime per year); automatic failover to standby within 60 seconds, zero data loss for committed transactions |
| Usability | How easily a real person gets the job done — measured, not asserted | First-time users complete core tasks within 5 minutes, measured by user testing; the interface is responsive across the supported screen sizes |
| Maintainability | How cheaply the system can be changed and kept healthy over its life | Documentation and coding standards defined and enforced; critical bugs fixed within an agreed time; test coverage meets an agreed minimum |
| Compliance | The standards, laws and regulatory obligations the system must satisfy | Industry standards such as PCI-DSS, HIPAA or GDPR as applicable; audit trails retained for the required period (eg. 7 years for financial records) |
| Compatibility | The environments the system must work in | Supported browsers and versions; supported devices (mobile, tablet, desktop); operating-system and third-party integration requirements |
Different domains lean on different parts of this list. The categories stay the same; the weighting shifts with the domain, as the worked examples below show.
Non-functional requirements: examples by domain
The same catalogue produces very different priorities once it is applied to a real product. Three domains make the point.
Ecommerce platform
Performance and scale under a spike dominate, because abandoned baskets are lost revenue.
| Category | Requirement |
|---|---|
| Performance | Checkout completes within 30 seconds on 4G |
| Scalability | System handles 10,000 concurrent users during a Black Friday peak |
| Security | Payment data handled to PCI-DSS standards; card details never stored locally |
| Reliability | 99.9% uptime during business hours (8am-10pm) |
| Accessibility | All functionality keyboard-navigable; WCAG 2.1 AA compliance |
Banking application
Security, compliance and reliability come first, because a wrong or lost transaction is unrecoverable.
| Category | Requirement |
|---|---|
| Performance | Transactions complete within 3 seconds |
| Security | All data encrypted at rest (AES-256) and in transit (TLS 1.3) |
| Reliability | Failed transactions roll back automatically — no partial transfers |
| Compliance | Audit trail retained for 7 years |
| Accessibility | Screen-reader compatible; voice-banking support |
Healthcare system
Availability and access control move to the front, because records must be reachable around the clock and every read accounted for.
| Category | Requirement |
|---|---|
| Security | Two-factor authentication on access; data storage meeting the applicable health-data regime |
| Reliability | 99.99% uptime — records accessible 24/7 |
| Performance | Patient records load within 2 seconds |
| Data protection | Patient data backed up hourly to geographically distributed locations |
| Audit | Every data access logged with user, timestamp and reason |
Making non-functional requirements measurable
The single most common failure with a non-functional requirement is that it names a virtue without setting a bar. ‘The system should be fast’ is not a requirement; it’s a wish. Left vague, it means whatever the reader wants it to mean — the developer hears 5 seconds, the product owner expects 1, the user needs sub-second — and nobody is wrong, because nothing was ever pinned down.
The cure is to write the threshold into the requirement. The test is simple: could a tester verify this objectively, and arrive at the same yes-or-no as anyone else running the same check? If not, it isn’t yet a requirement — make it more specific. The contrast is easiest to see paired up.
| Too vague | Measurable |
|---|---|
| The system should be fast | Search results return within 500ms for 95% of queries |
| API performance should be acceptable | API response time under 200ms at the 90th percentile |
| The system must be secure | All passwords hashed using bcrypt with a cost factor of 12 |
| Sessions should time out | Session tokens expire after 30 minutes of inactivity |
| The system should be reliable | 99.9% uptime; automatic failover to standby within 60 seconds |
| The interface should be accessible | All interfaces meet WCAG 2.1 Level AA; colour contrast at least 4.5:1 for text |
| The interface should be intuitive | First-time users complete core tasks within 5 minutes, measured by user testing |
Each version on the right carries a number, a named standard or an objective procedure — exactly the testability standard the handbook applies to every requirement, functional or not. Reviewing Requirements covers it in full as part of the Definition of Ready, and a non-functional requirement earns its place there on exactly the same terms.
Product-level and story-level
Most non-functional requirements belong to the product, not to a single story. Repeating ‘all interfaces meet WCAG 2.1 AA’ in every story is exhausting to write, easy to get inconsistent and easy to forget. Document them once, centrally, and reference them from the stories that need them.
A product-level set reads as a small catalogue the whole team works to — every page loading within 2 seconds on 4G, every interface meeting WCAG 2.1 AA, all data encrypted at rest and in transit, all APIs requiring authentication, the system holding 99.9% uptime. A story then only needs to point at the standard, or to flag where it deviates from it: a report that may take up to 60 seconds against a standard 2-second target, an admin screen that needs additional multi-factor authentication, an endpoint that is deliberately public. The exceptions are what belong in the story; the baseline lives in one place.
Give each requirement an identifier so a story can reference it in a few words rather than restating it. The pattern is a category prefix and a number — NFR-PERF-001, NFR-SEC-002 — and a typical block for a web application documents the categories together:
## Performance (NFR-PERF)
- NFR-PERF-001: Page load time under 2 seconds on 4G (90th percentile)
- NFR-PERF-002: API response time under 500ms (95th percentile)
- NFR-PERF-003: System handles 1,000 concurrent users without degradation
## Security (NFR-SEC)
- NFR-SEC-001: All passwords hashed using bcrypt, cost factor 12
- NFR-SEC-002: All data encrypted at rest (AES-256) and in transit (TLS 1.3)
- NFR-SEC-003: JWT tokens expire after 30 minutes inactivity
- NFR-SEC-004: Failed login attempts trigger account lock after 3 tries
## Accessibility (NFR-ACCESS)
- NFR-ACCESS-001: All interfaces meet WCAG 2.1 Level AA
- NFR-ACCESS-002: All functionality keyboard-accessible
- NFR-ACCESS-003: Colour contrast minimum 4.5:1 for text
Each requirement gets an ID for easy reference. Stories simply state “Must meet NFR-PERF-001” rather than repeating the requirement.
Define them early, test against them
Non-functional requirements are cheapest to satisfy when they are known before the architecture is fixed. They shape the technical approach: a memory limit, a concurrency target or an encryption standard can decide how the system is built. A requirement discovered after development is often one that forces a rebuild. Settle the load, the security obligations, the availability target and the supported environments at planning time, alongside the features, and write the answers down as measurable criteria rather than aspirations.
A documented non-functional requirement that is never checked is just documentation. Each one should have a matching place in the test plan: performance requirements met by performance testing, security requirements by security scanning, accessibility requirements by accessibility audits, uptime targets by production monitoring. Do not assume the bar is being cleared — verify it. Define the requirements early, reference them consistently through stories, the Definition of Done and architecture decisions, and test against them explicitly. That is what turns a feature that demos well into one that holds up in production.