Non-Functional Requirements (NFR) Specification
A document that defines the quality attributes and constraints of a system — performance, scalability, availability, security, usability, and other characteristics that describe how the system should behave rather than what it should do.
Purpose
NFRs define the quality bar for the system and drive architectural decisions. Without explicit NFRs, teams make implicit assumptions that may not align with stakeholder expectations, leading to costly rework or service failures.
When to Use
Define NFRs during discovery and refine them in alpha. They should be agreed before major architectural decisions are made, as they significantly influence technology and design choices.
How to Build
Start by identifying the quality attribute categories relevant to your system: performance, scalability, availability, security, usability, maintainability, portability, and compliance.
For each category, define specific, measurable requirements. Avoid vague statements like 'the system should be fast' — instead specify 'page load time must be under 2 seconds at the 95th percentile under normal load'.
Define the measurement method for each NFR: how will you verify it is met? What tools, tests, or monitoring will be used? This makes NFRs testable.
Prioritise NFRs — not all can be equally important. Use MoSCoW or a priority scale. Document trade-offs between competing NFRs (e.g., security vs usability).
Include the rationale for each NFR — why is this level of performance/availability/security required? Link to business requirements or user research.
Tips
- Make every NFR measurable and testable — if you cannot measure it, you cannot verify it.
- Include load profiles: what does normal load look like? What about peak? What about failure scenarios?
- Reference industry benchmarks and government standards (e.g., GDS performance targets).
- Review NFRs with operations teams early — they will live with the consequences.
- Revisit NFRs as the project progresses — initial estimates may need adjustment based on alpha findings.
Common Mistakes
- Writing vague, unmeasurable NFRs like 'the system should be highly available'.
- Not prioritising NFRs, implying all are equally critical.
- Defining NFRs in isolation without considering trade-offs between them.
- Setting unrealistic targets without understanding the cost implications.
- Not reviewing NFRs with the people who will operate and maintain the system.
Government Context
In UK government, NFRs should reference the GDS Service Standard (particularly point 14 on performance), WCAG 2.2 AA for accessibility, NCSC security guidelines, and the Service Manual's guidance on uptime. Government services typically require 99.9% availability during business hours. The Accessibility Regulations 2018 make WCAG 2.2 AA compliance a legal requirement for public sector websites.