What the system does, and how well it does it
Most requirements documents describe what a system should do. A customer can place an order. A manager can approve a holiday request. An invoice is generated at the end of the month. These are functional requirements, and they come naturally from business and product conversations because they describe the features people can see.
Non-functional requirements (NFRs) describe how well the system does all of that. How fast is the order page? What happens if a thousand customers arrive at once? Who is allowed to see the invoices, and how long are they kept? How quickly can the system be restored if the database server fails?
Nobody demos an NFR, and they rarely appear on a roadmap. In reality, they decide whether a system is still trusted a year after launch. A feature that works but takes eight seconds to load, falls over at month end, or leaks customer data isn’t really working at all.
Why they get missed
NFRs tend to be left out for understandable reasons:
- They feel obvious. Nobody asks for a system that is slow, insecure or unreliable, so nobody thinks to write down that it shouldn’t be.
- They’re hard to express in business terms. “The page should be fast” is easy to say and impossible to test.
- They cut across features. Security or performance doesn’t belong to one user story, so it ends up belonging to none of them.
- They cost money up front. Resilience, monitoring and load testing add effort before anyone has seen a benefit.
The result is that NFRs get decided anyway, but implicitly, by whoever builds the system and under whatever deadline they’re working to. They often surface late, as performance problems in testing, a failed security review, or an outage in the first busy week, when they’re most expensive to fix.
Well-known NFRs
There is no single definitive list, but most come down to a familiar set. The ISO/IEC 25010 product quality model is a useful formal reference if you want one. In practice, the following are worth considering in any brief:
| NFR | The question it answers | A measurable example |
|---|---|---|
| Auditability | Can we prove who did what, and when? | Every change to customer or financial records is logged with user, time and before/after values, and kept for 7 years |
| Availability | When does it need to be up? | 99.9% availability during UK business hours |
| Capacity | How much can it hold? | Stores 10 years of transactions without archiving |
| Cost efficiency | What should it cost to run? | Hosting costs stay below £2,000 a month at current volumes |
| Data integrity | Can we trust the data to be accurate and consistent? | Nightly reconciliation finds no mismatches between orders and invoices |
| Data protection and compliance | Which rules apply to the data? | Personal data retained for 6 years, then deleted automatically |
| Deployability | How easily and safely can changes be released? | Releases are automated, take under 15 minutes and can be rolled back in under 5 |
| Internationalisation and localisation | Can it work across languages, currencies and time zones? | Supports English and French, GBP and EUR, with all dates stored in UTC |
| Interoperability | How well does it work with other systems? | Exposes a documented REST API for orders and customers |
| Maintainability | How easy is it to change safely? | A typical change can be built, tested and released within a day |
| Observability | Can we see what it’s doing? | Every error is logged centrally and alerts the support team within 5 minutes |
| Performance | How quickly does it respond? | 95% of searches return in under 1 second |
| Portability | How tied is it to one platform or vendor? | Can be redeployed to another cloud provider without code changes |
| Recoverability | How fast can it come back, and how much data can we lose? | Restored within 4 hours (RTO), losing no more than 15 minutes of data (RPO) |
| Reliability and resilience | How does it behave when parts fail? | Loss of one server causes no user-visible outage |
| Scalability | How does it cope as load grows? | Supports 5,000 concurrent users with no loss of response time |
| Security | Who can do what, and how is it protected? | All access via single sign-on with MFA; data encrypted at rest and in transit |
| Sustainability | How much energy and carbon does it use? | Non-production environments shut down outside working hours; hosting region chosen for low-carbon energy |
| Testability | Can the system be tested reliably and quickly? | Automated tests cover all critical paths and run in under 10 minutes |
| Usability and accessibility | Can people use it easily, whatever their needs? | Meets WCAG 2.2 level AA |
Depending on the system, a couple of others are worth adding: safety, where software can cause physical or financial harm (a characteristic added in the 2023 edition of ISO/IEC 25010), and supportability, for the teams who keep the system running.
The exact list matters less than the habit of asking each question deliberately, rather than finding out the answer in production.
Making them measurable
The difference between a useful NFR and a wish is a number. “The system must be fast” can’t be designed for, tested or agreed. “95% of order submissions complete within 2 seconds at 200 concurrent users” can be.
A good NFR usually has four parts:
- What is being measured, such as response time, availability or recovery time.
- A target value, such as 2 seconds, 99.9% or 4 hours.
- The conditions, such as peak load, business hours or a specific data volume.
- How it will be verified, such as a load test, monitoring dashboard or restore drill.
If nobody can say how a requirement will be tested, it isn’t finished yet.
They involve trade-offs
NFRs pull against each other, and against cost. Higher availability means more redundancy and more infrastructure. Tighter security can make a system harder to use. Extreme performance can make code harder to maintain. Five nines of availability (99.999%) allows about five minutes of downtime a year and costs dramatically more than 99.9%, which allows almost nine hours.
That’s why NFRs are business decisions as much as technical ones. The right target depends on what an outage, a slow page or a breach actually costs the business. An internal reporting tool and a customer-facing payment service rarely deserve the same targets, and pretending they do wastes money on one or puts the other at risk.
Bringing them into the conversation early
The cheapest time to agree NFRs is alongside the business and product requirements, before design starts. In practice, that looks like:
- Using a checklist, such as the table above, in every discovery or refinement session, so each NFR is considered even if the answer is “not important here”.
- Asking business questions and translating them: “What happens if this is down for an afternoon?” becomes an availability and recovery target.
- Writing them as testable statements and keeping them with the other requirements, not in a separate document nobody reads.
- Building them into the definition of done, so performance, security and monitoring are checked as part of delivery, not after it.
- Revisiting them as the system grows, because the right target for 50 users is rarely right for 5,000.
The quiet half of good architecture
Functional requirements describe the system people asked for. Non-functional requirements describe the system they’ll actually live with. Getting both onto the page, with numbers attached, is one of the simplest ways to avoid expensive surprises later.
