Requirements Gathering

Consider two messaging applications. Both let you send text messages. Both support image sharing. Both offer group chats. Functionally, they're identical. Yet one has 500 million users while the other struggles with a few thousand. The difference? Non-functional requirements.

One delivers messages in 100 milliseconds; the other takes 3 seconds. One stays online during traffic spikes; the other crashes whenever a celebrity tweets. One protects your data with end-to-end encryption; the other has suffered three data breaches. One works seamlessly on a 2G connection in rural India; the other demands fiber-optic internet.

Non-functional requirements (NFRs) define the quality attributes that determine whether a system is merely functional or truly excellent. They answer not 'what does the system do?' but 'how well does it do it?' — and this 'how well' often decides whether a product succeeds or fails in the market.

Non-functional requirements (NFRs), also called quality attributes, system qualities, or -ilities (because many end in 'ility' — scalability, reliability, usability), describe the properties and constraints that govern HOW the system performs its functions.

While functional requirements define the features and behaviors (the verbs of your system), non-functional requirements define the adjectives: how fast, how secure, how available, how scalable, how usable, how maintainable.

Formal Definition:

A non-functional requirement is a specification of a quality criterion that the system must satisfy, typically expressed as a measurable attribute with an acceptable range or threshold. NFRs constrain the design space by eliminating solutions that would otherwise satisfy functional requirements but fail to meet quality standards.

Notice the critical difference: functional requirements state what happens; non-functional requirements quantify how well it happens. This quantification is essential—vague NFRs like 'the system should be fast' are nearly useless. 'Response time < 200ms at p99 under 10,000 concurrent users' is actionable.

The Iceberg Metaphor:

Functional requirements are the visible tip of the system iceberg—the features users consciously interact with. Non-functional requirements are the massive underwater portion—invisible when working correctly, catastrophically apparent when they fail. Users don't praise latency of 50ms; they just expect it. But a latency spike to 5 seconds triggers complaints, churn, and viral Twitter threads.

NFRs span a wide landscape of quality attributes. Understanding this taxonomy ensures you don't overlook critical requirements. Let's explore each category in depth:

Additional NFR Categories:

The cardinal sin of NFR specification is vagueness. 'The system should be fast' is not a requirement—it's a wish. Quantification transforms wishes into verifiable specifications.

The SMART Framework for NFRs:

Apply SMART criteria to every non-functional requirement:

• Specific — Clearly defined, no ambiguity
• Measurable — Quantified with metrics and thresholds
• Achievable — Technically feasible given constraints
• Relevant — Aligned with business objectives
• Time-bound — Applies to a specific context or condition

Percentiles vs Averages:

A critical distinction in performance requirements is the difference between averages and percentiles:

• Average (mean) latency — Hides outliers. If 99% of requests take 50ms but 1% take 10 seconds, average might look acceptable at 150ms.
• Percentile latency (p50, p90, p95, p99) — Shows the experience of the Nth percentile user.
  • p50 (median): Half of users experience this or better
  • p99: 99% of users experience this or better; 1% have it worse

Why p99 matters:

Power users often generate disproportionate traffic. If your p99 is bad, your most valuable users suffer most. Additionally, in microservices architectures, p99 latencies compound. If a request touches 10 services each with 100ms p99, the overall p99 can exceed 1 second.

Here's the uncomfortable truth: you cannot optimize for all NFRs simultaneously. Improving one quality attribute often degrades another. System design is fundamentally about navigating these trade-offs intelligently.

Common NFR Trade-off Pairs:

The CAP Theorem — The Canonical NFR Trade-off:

In distributed systems, you must choose between:

• Consistency (C) — Every read receives the most recent write
• Availability (A) — Every request receives a response
• Partition Tolerance (P) — System continues operating despite network partitions

Since network partitions are inevitable in distributed systems, you effectively choose between CP (consistent but may be unavailable during partition) or AP (available but may serve stale data during partition).

Example Trade-off Decisions:

1. Banking System — Chooses CP. Account balances must be consistent; it's better to reject a transaction than allow an overdraft due to stale data.

2. Social Media Feed — Chooses AP. Showing a slightly stale feed is acceptable; being unavailable is not.

3. E-commerce Inventory — Often a hybrid. Shopping cart can be AP (eventual consistency acceptable), but final checkout must be CP (can't sell item twice).

Making Trade-off Decisions:

When NFRs conflict, use this framework:

1. Understand business criticality — Which quality matters most for the core business function?
2. Identify user impact — How does each option affect user experience?
3. Evaluate cost — What are the implementation and operational costs of each choice?
4. Consider reversibility — Can you change this decision later, or is it locked in?
5. Document explicitly — Record the trade-off decision and rationale for future reference.

The worst outcome is an implicit, undocumented trade-off that the team doesn't realize they've made until production incidents reveal it.

NFRs don't emerge from thin air—they derive from the business context, user expectations, regulatory requirements, and operational constraints. Let's explore how to systematically derive them:

Traffic and Scale Estimation:

Many NFRs require estimating traffic and data volumes. Use back-of-envelope calculations:

Example: Estimating for a Social Media Platform

• DAU (Daily Active Users): 100 million
• Actions per user per day: 20 (posts, likes, comments, views)
• Total daily actions: 2 billion
• Peak to average ratio: 3x (evening hours)
• Peak QPS: 2B / 86,400 seconds × 3 ≈ 70,000 QPS

From this:

• Performance NFR: Handle 70,000 QPS with < 200ms latency
• Scalability NFR: Auto-scale from 20K to 100K QPS within 5 minutes
• Availability NFR: 99.9% (can't afford losing 2 billion actions)

Data Storage Estimation:

• Posts per day: 10 million
• Average post size: 1 KB text + 500 KB media (averaged)
• Daily storage growth: ~5 TB
• Annual storage: ~2 PB

From this:

• Scalability NFR: Storage system scales to petabyte range
• Cost NFR: Storage cost < $X per TB (given budget constraints)

In system design interviews, NFRs are where candidates differentiate themselves. Asking about and reasoning through NFRs signals senior-level thinking.

The NFR Interview Framework:

After understanding functional requirements, systematically probe NFRs:

Demonstrating NFR Mastery in Interviews:

NFR documentation requires particular care because these requirements drive critical architectural decisions and serve as acceptance criteria for system validation.

We've explored the critical world of non-functional requirements—the quality attributes that determine whether your system is merely functional or truly excellent. Let's consolidate:

What's Next:

We now understand what the system does (functional requirements) and how well it does it (non-functional requirements). But how do we extract these requirements effectively? The next page explores the art of asking the right questions—the systematic inquiry process that separates thorough requirements gathering from superficial fact-finding.