Functional vs Non-Functional Requirements

The Split

• Functional requirements (FRs): behavior — what the system does. Testable as input→output.
• Non-functional requirements (NFRs): qualities — how well it does it, under stress, at scale, over time.

 FR:   "User uploads a video"            ← a feature; any architecture
                                            can satisfy this
 NFR:  "Upload succeeds for files up to
        10 GB on flaky mobile networks,
        resumable after interruption"    ← THIS decides the architecture:
                                            multipart upload, chunking,
                                            checksums, async transcoding

The feature is the same in both lines. Only the second line forces real design.

Why NFRs Decide Architecture

FRs rarely eliminate options — a feed can be built with almost anything. NFRs are the filter:

NFR	Eliminates	Forces
p99 read latency under 50 ms globally	Distant origin-only serving	CDN / regional caches
Strong consistency on payments	Eventually-consistent stores by default	Quorum writes / serializable transactions
10k writes/sec sustained	Single-node Postgres as sole writer	Sharding or write-optimized store
Zero data loss (RPO = 0)	Async replication alone	Sync replication, accepting write latency
Compliance: EU data stays in EU	One global shared table	Geo-partitioning

Miss an NFR and the discovery arrives as a production incident, not a failed test — because FR tests pass while qualities quietly degrade.

The Standard NFR Checklist

Interrogate every design with these; each maps to measurable targets:

Quality	Ask	Typical target form
Availability	How down is acceptable?	99.9% → 43 min/month budget
Latency	How slow breaks UX?	p50/p95/p99 per endpoint
Throughput	What load must it absorb?	QPS peak + growth
Scalability	What happens at 10x?	Horizontal path named
Consistency	What divergence is tolerable?	Per-data-type decision
Durability	What loss is unacceptable?	RPO, replication factor
Security	What is the trust boundary?	AuthN/Z model, encryption zones
Cost	What monthly spend is viable?	$/month ceiling per component

Writing Them So They’re Usable

Vague NFRs are decorative; measurable ones are architectural inputs:

 VAGUE:      "The system should be fast."
 MEASURABLE: "GET /feed returns within 200 ms at p95 for 10M DAU,
              measured from US-East and EU-West."

 VAGUE:      "Highly available."
 MEASURABLE: "99.9% monthly availability for ride-matching;
              99.99% for payment capture."

Numbers enable verification, capacity planning, and honest trade-off discussion.

Interview Framing

Opening minutes exist largely to extract NFRs: scale, latency expectations, consistency needs, availability tier. Candidates who jump to boxes without them produce architectures justified by taste. One sentence pattern works throughout: “That choice serves the NFR of X — if X relaxed to Y, we could simplify to Z.”