Non-Functional Requirements

Definition

Non-functional requirements (NFRs) describe how a system behaves rather than what it does. Where functional requirements specify features (the user can place an order), NFRs specify qualities (the order is confirmed within 500ms at the 99th percentile, with 99.95% availability, and PCI-DSS compliant data handling). NFRs are sometimes called quality attributes, system qualities, or "the -ilities" — reliability, scalability, maintainability, observability, accessibility, security, portability.

Why They Matter

Most large IT failures I have audited were not failures of functionality. They were failures of NFRs — systems that worked in demo and fell over under real load, that passed UAT and failed accessibility audit, that shipped on time and were breached three months later. Construction has its analogue: a building that meets every architectural drawing but fails its acoustic, thermal, or commissioning tests.

Common Categories

• Performance and latency
• Scalability and capacity
• Availability and reliability
• Security and privacy
• Accessibility (e.g., WCAG 2.2 AA)
• Maintainability and observability
• Compliance and regulatory
• Usability

Real-World IT Example

A national retailer launched a checkout redesign that met every functional acceptance criterion. On the first Black Friday, the system collapsed at 1.4× normal load. The post-incident review found that the team had captured one NFR ("the system must be fast") without numbers behind it. The rebuild defined explicit latency, throughput, and degradation targets and survived the following peak season without incident.

Real-World Construction Example

NFRs translate cleanly to building performance criteria: thermal U-values, acoustic insulation indices, fire ratings, vibration tolerances. On a $310M concert hall, the acoustic NFRs were measured by independent specialists at 14 stages of construction; one early failure triggered a £180k redesign of a wall buildup that would otherwise have cost millions to correct after fit-out.

Common Mistakes

• Stating NFRs without numbers. "Fast", "secure", "available" mean nothing without thresholds.
• Treating them as a backlog item rather than cross-cutting constraints.
• Defining them late. NFRs drive architecture; late NFRs trigger expensive rework.
• No testing strategy. An untested NFR is wishful thinking.
• Ignoring trade-offs. Optimising security may slow performance; the team must own the choice.

Expert Tips

• Capture NFRs as measurable, testable statements with explicit thresholds and percentile.
• Tie NFRs to architecture decision records so the connection between requirement and design is traceable.
• Build NFR validation into CI/CD pipelines wherever possible.
• Review NFRs at the kickoff meeting and at every major milestone.
• Include NFR ownership in the RACI; without an owner, NFRs drift.

Practical Lessons Learned

• The cost of fixing a missed NFR rises exponentially with discovery time — load capacity discovered in production costs 50–100× what it would have cost in architecture.
• Stakeholder workshops always over-discuss functional features and under-discuss NFRs. Force the agenda.
• Accessibility is the most-cited and least-funded NFR. Funding it early is cheaper and morally correct.

Key Takeaways

• NFRs describe how a system behaves; functional requirements describe what it does.
• Most large-system failures are NFR failures, not feature failures.
• State NFRs with numbers, thresholds, percentiles, and test strategies.
• NFRs drive architecture and must be defined early.
• The same discipline applies to physical building performance criteria.

Related Encyclopedia Entries

• Quality Management
• Definition of Done
• Technical Debt
• DevOps
• Continuous Integration
• Risk Management

Related Research Articles, Case Studies & Tools

• Project Controls Academy
• NFR Specification Templates
• Learning Tracks: Quality & Architecture
• Books on Software Architecture
• Black Friday NFR rebuild case study
• Cost of late-discovered NFR failures