Nonfunctional Requirements: Make Quality Measurable

Quality Attributes and Nonfunctional Requirements

Nonfunctional requirements describe how well a system must behave rather than what it does: how fast, how available, how secure, how accessible, how easy to change. They are better called quality attributes, because they are not optional extras — a checkout that works but takes eight seconds, or a feature that blind users cannot operate, fails just as surely as one that crashes.

They are also the requirements most often written badly. "The system must be fast, scalable, and secure" cannot be designed for, tested, or argued about. This page shows how to turn each expectation into a measurable acceptance condition with a defined load, environment, and verification method — so quality attributes drive architecture decisions instead of surprising teams at launch.

TL;DR

Every quality requirement needs a measure, a condition under which it applies, and a verification method.
Express latency as percentiles at a stated load (p95, p99), never as an average.
Availability targets should be realistic SLOs with error budgets — "100%" is not a requirement, it is a wish.
Recovery needs two numbers: RPO (how much data you may lose) and RTO (how long recovery may take).
Accessibility has an external standard — WCAG 2.2 Level AA is the usual target.
Quality attributes trade off against each other; make the priorities explicit before architecture begins.

Quick Example

Quality requirements for a checkout service, written so each one can fail a test.

Each entry states the measure, the conditions, and how the team will know — which is what turns an aspiration into a requirement.

Core Concepts

The Quality Attribute Scenario

A precise way to write a quality requirement is the six-part quality attribute scenario used in architecture evaluation methods such as ATAM:

Writing scenarios forces the conversation about conditions and measures that adjectives skip.

A Catalog of Quality Attributes

Standards such as ISO/IEC 25010 group product qualities into families — performance efficiency, reliability, security, interaction capability (usability), maintainability, compatibility, and others. Use the catalog as a checklist so nothing important is forgotten, then select the handful of attributes that actually drive decisions for your system.

Making Common Attributes Measurable

Latency: Percentiles at a Stated Load

Averages hide the slow tail that users actually notice, and a target without a load is meaningless — every system is fast when idle. State the percentile, the load, the payload size, and where it is measured (client, gateway, or service).

Availability: SLOs, Not Perfection

Each additional "nine" costs disproportionately more. A target of 99.9% allows about 43 minutes of downtime equivalent per month; 99.99% allows about 4. Choose the target from what users need and what dependencies can deliver, and express it as an SLO with an error budget so reliability work competes fairly with features.

Recovery: RPO and RTO

The recovery point objective is the maximum acceptable data loss, measured in time; the recovery time objective is the maximum acceptable time to restore service. They determine backup frequency, replication design, and failover automation — and they are only real if restore drills prove them.

Accessibility: Use the Standard

Accessibility already has an internationally recognized measure: WCAG. Specify the version and level (usually 2.2 AA), name the critical journeys that must work with assistive technology, and combine automated checks with manual keyboard and screen reader testing. See Accessibility.

Security: Controls and Verification Levels

Security requirements become testable when tied to a control standard such as the OWASP ASVS and to concrete abuse cases — "a user cannot read another tenant's invoices by changing an ID" — that become security regression tests.

Trade-offs Between Attributes

Quality attributes compete: stronger consistency can raise latency, extra security steps reduce convenience, and more flexibility adds complexity. Rank the attributes that matter for a system early — for a payments service, correctness and security outrank latency; for autocomplete, latency outranks completeness — and record the ranking so architecture choices can cite it.

Best Practices

Attach a Verification Method to Every Requirement

If nobody can say how a requirement will be checked, it will not be. Decide whether it is verified by an automated test, a production metric, a drill, or an audit.

Put Quality Into the Definition of Done

Recurring requirements — accessibility checks, performance budgets, security tests — belong in the team's Definition of Done rather than in separate stories that can be deprioritized.

Revisit Targets After Incidents and Growth

A latency target set at 1,000 users may be wrong at 100,000. Review quality requirements when traffic, data volume, or the user base changes, and after incidents that exposed a gap.

Common Mistakes

Averages Instead of Percentiles

Perfection as a Target

Untestable Security Requirements

FAQ

What are nonfunctional requirements?

They are requirements about the qualities of a system's behavior rather than the behavior itself: performance, availability, security, accessibility, maintainability, and similar properties. Because they shape architecture, they need to be specified early and as measurably as functional requirements.

How do I write a measurable nonfunctional requirement?

State the attribute, the measure, the conditions, and the verification method — for example, "p95 latency under 300 ms at 500 requests per second, verified by a nightly load test." The quality attribute scenario format (source, stimulus, environment, artifact, response, response measure) is a reliable template.

What is the difference between a nonfunctional requirement and an SLO?

A nonfunctional requirement states what quality the system must achieve; a service level objective is an operational target measured continuously in production. Availability and latency requirements usually become SLOs once a service is live. See SLOs.

How do nonfunctional requirements fit into Agile backlogs?

Cross-cutting qualities belong in the Definition of Done or as acceptance criteria on relevant stories; one-off work to achieve a target, such as adding caching, becomes its own backlog item. See Agile Software Development.