Non-functional requirement
A non-functional requirement (NFR) specifies how well a system must do its job rather than what it does: qualities and constraints such as speed, security, reliability, and usability. Where a functional requirement says “the system shall send a receipt,” a non-functional requirement says “it shall send that receipt within two seconds, and the site shall stay up 99.9% of the time.”
NFRs are easy to under-specify and expensive to retrofit. Software that does everything it should but is too slow, insecure, or unreliable still fails in practice, which is why NFRs, not features, are often what sink a project.
Also known as
NFRs · quality attributes · quality requirements · the “-ilities” (reliability, scalability, maintainability…) · constraints
Don't confuse with
- Functional requirement: the behavior itself. NFRs describe the qualities of that behavior, not new behaviors. Rule of thumb: functional is a verb the system performs; non-functional is an adverb describing how.
- Acceptance criteria and the Definition of done: NFRs often become acceptance criteria or part of the Definition of Done, but the NFR is the underlying quality target, not the checklist entry.
In plain English
Non-functional requirements are the adverbs. Not “what does it do,” but “how fast, how safely, how reliably?”
The “-ilities” (common quality attributes)
Most NFRs fall under a handful of quality attributes. Below is a practical shortlist of the ones you’ll meet most often; the formal reference is ISO/IEC 25010, whose official set differs slightly (see the note after the table).
| Attribute | The question it answers | Example NFR |
|---|---|---|
| Performance / efficiency | How fast, how resource-light? | 95% of searches return in under 500 ms |
| Scalability | Does it hold up as load grows? | supports 10,000 concurrent users |
| Reliability / availability | Does it stay up and recover? | 99.9% monthly uptime |
| Security | Is data protected? | all traffic encrypted; passwords hashed |
| Usability | Is it easy to use? | a new user completes signup in under a minute |
| Maintainability | Is it easy to change safely? | every module covered by automated tests |
| Portability / compatibility | Does it run across environments? | works on the last two versions of each major browser |
What ISO/IEC 25010 actually lists
The table above is a practical grouping, not a verbatim standard. ISO/IEC 25010’s own top-level product-quality characteristics are functional suitability, performance efficiency, compatibility, reliability, usability, security, maintainability, and portability (2011 edition). The 2023 revision adds safety and renames usability to interaction capability and portability to flexibility. Note that scalability, though everyone talks about it, is a sub-characteristic (of flexibility), not one of the top-level ones.
Why they must be measurable
A good NFR is testable and specific. “The system shall be fast” is useless; “95% of pages load in under two seconds on a 4G connection” can be verified. Vague NFRs are a classic source of disputes late in a project.
Measuring performance: percentiles, not averages
Performance NFRs are almost always written as percentile latency: p95 or p99 (the value 95% or 99% of requests come in under), not an average. Averages hide tail latency, the slow worst case that a few, often important, users actually feel. “p99 under 200 ms” allows only 1 request in 100 to be slower. The rigorous way to pin such targets down is a service level objective (SLO), which belongs to the planned Operations domain.
Where they come from and where they lead
- They are gathered in the Requirements stage of the SDLC, alongside functional requirements.
- They are the main driver of software architecture: you choose an architecture largely to satisfy NFRs (a system needing 99.99% uptime is built very differently from a weekend prototype). Architecture will get its own articles in a future Design and architecture domain.
- In a Feasibility study, NFRs feed the technical and operational dimensions.
See also
- Functional requirement: the “what it does” counterpart
- Software development life cycle: the Requirements stage these belong to
- Feasibility study: NFRs inform technical and operational feasibility
References
- ISO/IEC 25010 (SQuaRE: system and software quality models), the source of the formal quality-attribute list; first published 2011, revised as 25010:2023 (retitled “Product quality model,” now nine characteristics). https://en.wikipedia.org/wiki/ISO/IEC_25010
- ISO/IEC/IEEE 29148:2018 (Systems and software engineering: requirements engineering). https://www.iso.org/standard/72089.html
- K. Wiegers and J. Beatty, Software Requirements (3rd ed., Microsoft Press, 2013). https://www.microsoftpressstore.com/store/software-requirements-9780735679665