Non-Functional Requirements: The Categories, With Measurable Examples

Non-functional requirements define how well a system must behave rather than what it does: how fast, how available, how secure, how recoverable, how auditable. They are just as testable as functional requirements when written with a measure, a target, a condition, and a verification method, and they are the requirements that fail projects late when nobody writes them at all.

A non-functional requirement (NFR) specifies a quality the system must have, performance, availability, capacity, security, auditability, recoverability, rather than a behavior it must perform. The functional requirement says the system rejects a payment to a closed account with reason code AC04; the non-functional requirements say it does that at 200 payments per second, with p95 latency under 500 ms, 99.95% of the month, while logging who saw what. Functionally complete systems fail on NFRs all the time, and they fail late: the platform that passed every functional test but folds at the month-end volume peak, or cannot show an auditor who changed a standing order, fails at the most expensive moment there is. Writing NFRs down, with numbers, is core business analyst and systems analyst work, and it belongs in the functional specification alongside the behavior, not in a slide nobody tests against.

What is the difference between functional and non-functional requirements?

A functional requirement defines an outcome the system produces; a non-functional requirement defines a quality that outcome must have. The practical test: a functional requirement is verified by checking what happened, a non-functional requirement is verified by measuring how it happened, usually under defined conditions.

The two are attached to each other, which is why separating them completely is a mistake. “Validate an IBAN” is functional. “Validate it in under 100 ms, because it runs on every keystroke in the channel” is the NFR that decides whether the functional design is even viable. When you turn a business requirement into a functional spec, the non-functional constraints are part of the translation: the business said “customers should not wait,” and someone has to convert that into a number a developer can build against and a QA analyst can test.

Which NFR categories actually matter?

Eight categories cover most systems. The table gives each one a measurable example, because the category name alone specifies nothing.

Category	What it constrains	Measurable example
Performance	Response time and processing speed	p95 API response under 300 ms at 200 requests per second
Throughput and capacity	Volume the system must sustain	2 million payments per day, peak 400 per second at 09:00 cut-off
Availability	Uptime and allowed downtime	99.95% monthly, no planned outage between 06:00 and 22:00
Scalability	Growth without redesign	Handle 3x current peak with horizontal scaling only
Security	Access, protection, secrets	All data encrypted in transit and at rest; access via SSO with MFA; least-privilege roles
Auditability	Evidence of who did what	Every state change logged with user, timestamp, before and after values; retained 7 years
Recoverability	Behavior after failure	RTO 15 minutes, RPO zero lost transactions, tested failover quarterly
Operability	Running it in production	Every failed message alerts within 1 minute and is traceable by payment id

Regulated domains add retention and compliance requirements on top, and they make auditability and recoverability non-negotiable: “RPO zero” for a payments ledger is not a preference, it is the difference between an incident and a reconciliation crisis. Notice that operability is on the list: requirements like “a stuck payment must be findable by id within one query” sound humble but decide whether production support takes minutes or days.

How do you write an NFR that can actually be tested?

Write every NFR with four parts: the measure, the target, the condition, and the verification method. An NFR missing any of the four cannot be tested, and an untestable requirement is a wish that will be ignored until production enforces it.

The difference is visible side by side:

Weak (an adjective)           Testable (measure, target, condition, verification)
The system must be fast.      p95 end-to-end latency < 500 ms at 200 TPS sustained
                              for 1 hour, verified by load test in pre-prod.

The system must be reliable.  99.95% monthly availability measured at the API
                              gateway, verified by synthetic checks every 30s.

The system must be auditable. Every payment state change writes an audit event
                              with user, timestamp, old and new values, verified
                              by test cases per transition.

Two disciplines make the numbers honest. First, get the condition from reality: the peak is not the average, and “200 per second” should come from measured volumes plus growth, not a guess in a workshop. Second, use percentiles, not averages: “average 200 ms” hides the 4-second tail your slowest customers live in, which is why p95 and p99 are the standard way engineering teams state latency targets.

Then treat NFRs as first-class requirements downstream: give each an ID, put it in the requirements traceability matrix, and trace it to the load test, failover drill, or audit-log test that verifies it. An NFR with no linked test is exactly as unverified as a functional requirement with no linked test; the matrix makes that visible.

Why do NFRs fail projects late?

NFRs fail late because their absence is invisible until the system meets real conditions: real volume, a real failure, a real auditor. A missing functional requirement is caught in the first demo, because someone notices the behavior is not there. A missing performance requirement is caught on the first month-end peak, and a missing recoverability requirement is caught during the first serious incident, the worst possible classrooms.

The root cause is usually ownership. Functional requirements have an obvious owner, the person who wants the behavior. NFRs sit between roles: the business assumes “of course it will be fast” is implied, the architect assumes the requirements will state the volumes, the vendor’s default sizing quietly becomes the de facto requirement. The fix is procedural, not heroic: a standing NFR section in the specification template covering the eight categories above, filled in or explicitly marked not applicable, so silence is a decision instead of an accident. It is the same move that makes any checklist work: convert “nobody thought about it” into “someone signed off on it.”

The takeaway

Non-functional requirements define the qualities the system must have: performance, throughput, availability, scalability, security, auditability, recoverability, operability. Write each with a measure, a target, a real-world condition, and a verification method, because an NFR with an adjective instead of a number cannot be tested and will not be built. Put them in the spec and the traceability matrix like any other requirement, and get the numbers from measured reality rather than workshop guesses. Functional requirements decide whether the system works in the demo; non-functional requirements decide whether it survives production.