Non-functional requirements (NFRs) describe how a system behaves — performance, security, availability, usability — rather than what it does. Skipped NFRs are why systems that demo beautifully collapse under real load.
The discipline is writing NFRs as measurable targets, not vague wishes. "Fast" means nothing; "95th percentile response under 400ms at 200 RPS" means everything.
The core NFR checklist
Walk through these categories before design, and record a measurable target for each that matters.
- Performance: latency, throughput, concurrency.
- Availability: uptime target, RTO, RPO, SLAs.
- Security: authentication, authorization, encryption, audit.
- Scalability: what load must the system absorb, and how?
- Compliance: GDPR, HIPAA, PCI-DSS — know your regulators.
If an NFR cannot be measured and tested, it will be silently ignored during delivery.
Making NFRs testable
Turn each NFR into a test: load tests for performance, fault-injection drills for resilience, security scans in CI for vulnerabilities. NFRs are not documents — they are a test suite.
Prioritize explicitly
You cannot have perfect everything. Rank NFRs with stakeholders and record the trade-offs. A system that tries to maximize every NFR is one that meets none of them well.
Non-functional requirements FAQ
When should NFRs be defined?
During discovery and design, before the architecture is locked. Retro-fitting an NFR like "must survive a regional outage" is far more expensive later.
Who owns NFRs?
Everyone, but the solution architect owns their definition and traceability. Business stakeholders set targets; engineering validates them.
