Non-functional Requirements
Non-functional requirements (NFRs) describe the qualities and constraints a system must meet, such as performance, security, reliability, usability and scalability, rather than the specific functions it performs. They define how well the product must work and under what conditions, and they are most useful when stated as measurable targets that can be tested.
How Non-functional Requirements Work
The BABOK Guide defines a non-functional requirement as one that describes the performance or quality attributes a solution must meet. They are also called quality attributes or quality requirements. The ISO/IEC 25010 product quality model gives teams a shared vocabulary, with categories such as performance efficiency, compatibility, reliability, security and maintainability.
A useful NFR names a metric, a threshold and the conditions under which it applies. "The app should be fast" cannot be tested. "Search returns results in under 300 ms at the 95th percentile with 1,000 concurrent users" can.
NFRs work at two levels. Some apply across the whole system, such as encrypting all personal data at rest. Others attach to a single functional requirement, such as a time limit on one export. In a product requirements document (PRD) they often appear as release criteria. Marty Cagan's PRD guidance lists performance, scalability, reliability, usability, supportability and localizability as typical examples. Recurring standards, like accessibility checks or security scans, are often written into the team's Definition of Done so they apply to every item.
Why Non-functional Requirements Matter
NFRs are easy to omit and expensive to retrofit. Many of them shape the architecture: a system designed for 100 users and 99% uptime is built differently from one meant for a million users and 99.99%. Discovering these targets after launch can mean rewriting core components.
They also decide whether a working product is actually usable. A feature that returns correct results in 20 seconds, fails under load or leaks data has met its functional requirements and still failed its users.
AI coding agents tend to optimize for the stated functionality. Unstated qualities, such as rate limits, logging, accessibility or input sanitization, are often skipped unless written down. For guidance on stating constraints precisely, see how to write clear, testable technical requirements.
Non-functional Requirements Example
For a B2B reporting dashboard, a team might specify:
- Performance: dashboards with up to 50,000 rows render in under 2 seconds at the 95th percentile.
- Availability: 99.9% monthly uptime, excluding announced maintenance.
- Security: customer data encrypted in transit and at rest.
- Accessibility: meets WCAG 2.2 Level AA.
- Scalability: 500 concurrent users per customer account without breaching the performance target.
Non-functional vs. Functional Requirements
Functional requirements say what the system does: "users can export a report as CSV". Non-functional requirements say how well it must do it: "the export finishes within 5 seconds for 50,000 rows". Both are needed, and an NFR without a clear functional context is often hard to test.