NFRs: The "Ilities

The Invisible Foundation

Functional requirements define what the system does — "user clicks button, order is placed." Non-Functional Requirements (NFRs) define how the system behaves under real-world conditions. They are the difference between a system that works in a demo and a system that works at 2am on Black Friday with 10x normal traffic.

The Big 5 NFRs:

1. Availability: Will it be up when users need it? Measured in "nines" of uptime (99.9%, 99.99%, etc.). Availability is a function of how quickly you can detect and recover from failures, not just how rarely they occur.
2. Latency: How fast does it respond? Always measure at the tail — p95 or p99 — not the average. The average hides the worst user experiences. A system with 50ms average latency but 5,000ms p99 latency is a broken system.
3. Scalability: Can it handle 10x growth without a rewrite? Scalability is about the shape of your growth curve — does cost and complexity grow linearly with traffic, or exponentially?
4. Durability: If the power cuts, do we lose data? Durability is about persistence guarantees. A message queue that drops messages on restart has low durability. A database with synchronous replication has high durability.
5. Consistency: Do all users see the same data at the same time? This is the core tension in distributed systems — the CAP theorem states you cannot have perfect consistency and perfect availability simultaneously during a network partition.

The Staff Insight:
Stakeholders rarely ask for NFRs explicitly. They assume the system will be fast, always available, and never lose data. It is your duty to surface these requirements by asking business-impact questions: "If the system is down for one hour during peak traffic, what is the revenue impact?" That answer tells you exactly how much to invest in availability infrastructure.