NFR Specification

Overview

An NFR specification replaces adjectives with measurements. Instead of "the system must be scalable", it says what load, at what latency, under which failure conditions, and how that will be measured. The ISO/IEC 25010 quality model is a useful checklist of attributes: performance efficiency, reliability, security, maintainability, and others.

Treat the specification as a living contract between product, engineering, and operations. Agree on it before design starts, and revisit it after each major release using real production measurements, so the targets reflect observed behavior rather than hope.

How it works

Write each requirement as a scenario with a source, stimulus, environment, response, and response measure.

ID:        NFR-PERF-02
Stimulus:  checkout request at 2,000 req/s peak
Env:       normal operation, one AZ degraded
Response:  order accepted
Measure:   p99 latency under 300 ms, error rate under 0.1%
Priority:  high
Verified:  load test per release, SLO dashboard in production

Rank the scenarios. The top few drive architecture; the rest are guidelines. Convert the ones that matter operationally into SLIs and SLOs with error budgets.

Pitfalls

• Specifying averages. Tail latency and worst-case behavior usually matter more.
• Ignoring failure conditions. Availability targets are meaningless without a stated failure environment.
• Setting every target at maximum. Quality attributes trade off against each other and against cost.
• Writing the document once. Load, users, and dependencies change; so must the numbers.
• Having no measurement method, which makes the requirement unfalsifiable.

Key takeaways

• Every NFR needs a number, a condition, and a way to measure it.
• Rank requirements so tradeoffs have a rule.
• Tie targets to SLOs so they stay alive in production.
• Revisit them when assumptions change.