Non-functional requirements (NFRs) describe how well a software system must work rather than what it does. They set measurable targets for qualities such as performance, security, reliability, usability and maintainability. Functional requirements say “the user can pay by card”; NFRs say how fast, how safely and how reliably that payment must happen.
That difference sounds academic. In practice, it decides your architecture, your hosting bill and whether the product survives its first busy month. This guide covers the main types of non-functional requirements, a measurable example for each, the UK compliance duties behind them and the mistakes we see most often.
What non-functional requirements are, in plain terms
Every requirement answers one of two questions. A functional requirement answers “what should the system do?” A non-functional requirement answers “under what conditions, and to what standard?”
Think of a food delivery app. “Customers can track their courier on a map” is functional. “The courier position refreshes at least every 10 seconds for 95% of active orders” is non-functional. Without the second sentence, a developer could meet the first with a map that updates once a minute. Technically, that passes. Commercially, it fails.
NFRs also go by other names: quality attributes, quality requirements or system qualities. They usually sit in a dedicated section of the software requirements specification (SRS), next to the functional requirements they constrain.
In short, a good NFR has four parts:
- A quality – for example, response time or availability.
- A measurable target – a number with a unit.
- A condition – the load, environment or user group it applies to.
- A verification method – the test or report that proves it.
Types of non-functional requirements mapped to ISO/IEC 25010
The most useful reference for classifying quality is ISO/IEC 25010, the product quality model in the SQuaRE series. The 2023 revision lists nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety.
Two names changed in that revision. “Usability” became interaction capability, and “portability” became flexibility, which now includes scalability as a sub-characteristic. Most teams still use the older, familiar labels, so the tables below do too. Each example shows the level of precision a developer can actually build and test against.
Qualities users notice every day
| Type (ISO/IEC 25010 characteristic) | What it covers | Measurable example |
|---|---|---|
| Performance (performance efficiency) | Speed, throughput, resource use | 95% of search requests return in under 800 ms with 500 concurrent users |
| Security (security) | Confidentiality, integrity, authentication, accountability | All personal data encrypted at rest (AES-256) and in transit (TLS 1.2 or higher); admin logins require MFA |
| Reliability (reliability) | Availability, fault tolerance, recoverability | 99.9% monthly availability; recovery point objective of 15 minutes; recovery time objective of 4 hours |
| Usability (interaction capability) | Learnability, accessibility, error protection | New staff complete a booking unaided within 5 minutes; all public pages meet WCAG 2.2 level AA |
Qualities that decide how the system grows
| Type (ISO/IEC 25010 characteristic) | What it covers | Measurable example |
|---|---|---|
| Maintainability (maintainability) | Modularity, testability, ease of change | Automated test coverage of at least 70% on core modules; a standard release deploys in under 30 minutes |
| Scalability (flexibility) | Growth in users, data or transactions | The system handles 3x current peak traffic by adding servers, with no code changes |
| Compatibility (compatibility) | Co-existence and interoperability | Exports invoices to Xero via its public API; works in the last two versions of Chrome, Safari, Edge and Firefox |
| Portability (flexibility) | Adaptability, installability, replaceability | Runs in containers on any major cloud provider; a new environment installs from scripts in under one hour |
The numbers above are illustrations, not recommendations. Your targets should come from real usage data, contracts and user research.
How to make non-functional requirements measurable
Vague NFRs are the most common problem we find when we review a specification. “The system must be fast”, “secure” or “user-friendly” gives nobody anything to build or test. So, the job is to turn each adjective into a number that the business agrees with and the engineers can verify.
A simple NFR template
Use this sentence pattern for every requirement:
[Component or journey] must [quality] [target with unit] when [condition], verified by [method].
For example: “The checkout journey must respond in under 2 seconds for 95% of requests when 1,000 users are active, verified by a monthly load test.”
Checklist before you sign off an NFR
- Does it have a number and a unit, not an adjective?
- Does it name the condition, such as peak load, device or network?
- Does someone own it on the business side?
- Can a tester prove it passed or failed?
- Does it state a priority, so trade-offs have a rule?
- Does it trace back to a business reason, such as a contract, a regulation or a user need?
Percentiles matter here too. An average response time hides the slowest users, whereas a 95th or 99th percentile target shows what most people actually experience.
UK compliance: where NFRs stop being optional
Some non-functional requirements come from law rather than preference. For UK products, two areas appear in almost every project.
UK GDPR and data protection
UK GDPR requires “data protection by design and by default” (Article 25). It also requires “appropriate technical and organisational measures” for security (Article 32). The regulation deliberately avoids prescribing specific controls. Instead, you translate it into concrete NFRs: encryption standards, access logging, data retention periods and a tested breach response. The Information Commissioner’s Office publishes practical guidance on what “appropriate” looks like.
Accessibility and WCAG 2.2
Public sector bodies must meet the accessibility regulations, which the gov.uk accessibility guidance now measures against WCAG 2.2 level AA. Private companies also have duties under the Equality Act 2010, and public sector buyers increasingly ask suppliers to prove accessibility during procurement. So, if you sell to councils, the NHS or universities, write WCAG 2.2 AA into your NFRs from day one. Retrofitting it later costs far more.
How NFRs drive architecture and cost
Functional requirements tell you which features to build. NFRs, on the other hand, tell you what kind of system to build them on. Consider how a single target changes the design:
- 99.9% availability allows roughly 43 minutes of downtime a month. That usually means redundant servers, automated failover and monitoring with on-call cover.
- 99.99% availability allows about 4 minutes. Now you need multi-zone deployment, zero-downtime releases and much stricter change control.
- Sub-second responses at high load often lead to caching, read replicas or a content delivery network.
- Strict data residency can rule out some SaaS tools and cloud regions altogether.
Each extra “nine” and each tighter latency target adds build effort, hosting cost and operational overhead. That is why the numbers deserve a business conversation, not a guess. A back-office tool used by 20 staff rarely needs the same resilience as a payments platform.
This is where Severus usually sits: between the business owner who knows the cost of an hour of downtime and the engineering team who knows the cost of preventing it. We agree the target first and design the architecture second, often during product discovery.
Worked example: a B2B booking platform
Imagine a UK start-up building a booking platform for physiotherapy clinics. The first draft of the specification says the system must be “fast, secure and always available”.
After a short workshop, the team rewrites those words as five NFRs:
- Performance: 95% of calendar views load in under 1.5 seconds on a 4G connection.
- Reliability: 99.5% availability during clinic hours (07:00–21:00 UK time), with nightly backups restorable within 2 hours.
- Security: patient health data encrypted at rest and in transit, role-based access for clinicians and receptionists, and every record view logged.
- Usability: the patient booking flow meets WCAG 2.2 AA and takes no more than four steps.
- Scalability: the platform supports 200 clinics without redesign.
Notice what the rewrite changed. For instance, “always available” became clinic hours, which is far cheaper to guarantee than 24/7. Meanwhile, health data triggered stricter security targets, because UK GDPR treats it as special category data. The architecture now follows from real needs rather than instinct.
How weak non-functional requirements lead to modernisation projects
Many legacy systems work perfectly well on paper. Every feature exists. The trouble lies in the qualities nobody specified: the system slows to a crawl at month-end, a release takes a weekend, and nobody dares touch the payment module.
Those are NFR failures that accumulated over years. Maintainability was never a requirement, so the code became tightly coupled. Scalability was never measured, so the database design assumed a tenth of today’s volume. Security targets were never updated, so the system still relies on outdated libraries.
Eventually, the business faces a choice: patch it again or modernise. If you are at that point, our legacy software modernisation work starts by writing the NFRs the original system lacked. Then we measure the current system against them. The gap tells you whether you need targeted application modernisation or a deeper rebuild.
Common mistakes with NFRs
- Using adjectives instead of numbers. “Fast” and “scalable” can’t fail a test, so nobody can hold them to account.
- Copying targets from another project. A 99.99% uptime target copied from a bank’s specification can double your infrastructure budget for no reason.
- Leaving NFRs until after the MVP. Security and accessibility work far better designed in than bolted on.
- Ignoring maintainability. It rarely shows in a demo, yet it decides how quickly you can ship every future feature.
- Writing them without a business owner. Engineers can suggest targets. Only the business can decide what an outage or a slow page actually costs.
- Never re-testing. Performance drifts as data grows, so NFRs need regular checks, not a single test before launch.
If you are preparing a tender, include your NFRs in the request for proposal. Otherwise, suppliers will price very different systems and the quotes won’t compare. For more guides like this one, see our startups and SaaS hub.
Severus is a business automation and operations consulting firm helping companies redesign workflows, integrate systems and implement automation and AI to reduce operating costs and manual work. Weak non-functional requirements are a common reason teams later need legacy software modernisation or systems integration work. Get them right early, and old software is far less likely to hold the business back.
Frequently Asked Questions
They define how well a system performs its functions. Common examples include “pages load in under 2 seconds for 95% of users”, “99.9% monthly availability”, “all personal data encrypted at rest and in transit” and “the checkout flow meets WCAG 2.2 level AA”.
The usual types are performance, security, reliability, usability, maintainability, scalability, compatibility and portability. ISO/IEC 25010:2023 groups them into nine quality characteristics, including safety and functional suitability.
Functional requirements describe what the system does, such as sending an invoice. Non-functional requirements describe the standard it must meet while doing it, such as sending 10,000 invoices within an hour without errors.
Ideally, a business analyst or product consultant writes them together with the product owner and a technical lead. The business sets the priorities and acceptable risk, while engineers confirm that each target is achievable and testable.
They usually sit in their own section of the SRS, grouped by quality type. High-level quality expectations can also appear in a business requirements document, then get refined into measurable targets in the SRS.
Strategy before code. Every time.
Not sure your product’s quality targets will hold up as you grow? Book a discovery call with Severus
