Solutions rarely fail on features — they fail on the things nobody wrote down. Non-functional requirements (NFRs) are those quality attributes, and pinning them down early is what keeps a design honest.
Non-functional requirements describe how well a system must behave, as opposed to what it must do. Functional requirements say the system processes an order; non-functional requirements say it does so within two seconds, for five thousand concurrent users, with a four-hour recovery objective.
Solutions rarely fail on features. They fail on the things nobody wrote down — the report that takes eleven minutes, the integration that collapses at month-end volume, the system nobody can restore because recovery was never specified or tested.
Ten categories. Work through all of them; delete what genuinely does not apply rather than skipping it silently.
The difference between an NFR that protects you and one that does not is whether it can be failed.
| Not an NFR | An NFR |
|---|---|
| The system must be fast | 95th percentile page load under 2s at 500 concurrent users |
| Highly available | 99.9% monthly uptime excluding agreed maintenance; degraded read-only mode acceptable during failover |
| Secure | All data encrypted at rest (AES-256) and in transit (TLS 1.2+); access via SSO with MFA for privileged roles |
| Must scale | Sustain 3× current peak volume with no architectural change; linear cost increase acceptable to 2× |
| Quick to recover | RTO 4 hours, RPO 15 minutes, verified by annual failover test |
Each right-hand entry can be measured, tested and failed. Each left-hand entry can be claimed by anyone about anything.
Architects should not invent NFR targets, because the numbers encode business decisions about acceptable loss. The productive question is not "what availability do you want?" — the answer is always 100% — but "what happens if this is down for an hour on a Tuesday morning, and what would you pay to avoid that?"
That reframing produces real numbers. It also surfaces the cases where the business will happily accept four hours of downtime for a system the technical team assumed needed five nines, which saves considerable money.
NFRs are cheap to specify before design and expensive to retrofit after. Availability targets drive infrastructure topology. Recovery objectives drive backup and replication design. Performance targets drive data model and caching decisions. Discovering the target after build means rework or acceptance of a system that will not meet it.
Set them at concept or high-level design, revisit at detailed design when more is known, and verify before go-live. An NFR never tested is an assumption, not a requirement.
Where an NFR is not met, that belongs in the architecture review as a recorded risk, not as a footnote.
The Architecture Review Kit includes an NFR assessment template that turns quality expectations into measurable, testable targets — and feeds the scorecard and report.
