Functional vs Non-Functional Requirements

Introduction

Every successful HLD starts with requirements — not with Redis or Kubernetes. Functional requirements describe what the system must do: users can post tweets, drivers accept rides, merchants receive payouts. Non-functional requirements (NFRs) describe how well it must do it: 99.99% availability, p99 read latency under 200 ms, GDPR compliance, $0.01 cost per transaction.

Interviewers deliberately leave requirements vague to test whether you ask clarifying questions. Candidates who immediately draw boxes score lower than those who spend five minutes scoping users, read/write ratio, consistency expectations, and retention policies.

This lesson teaches a repeatable checklist for extracting FRs and NFRs, translating them into architectural drivers, and documenting assumptions when the interviewer says "assume whatever you need."

Understanding the topic

Key concepts

• Functional: features, user stories, API operations, business rules, edge cases.
• Non-functional: scalability, latency, availability, durability, security, compliance, operability.
• Architectural drivers are NFRs that force specific decisions (strong consistency → SQL + sync replication).
• Constraints: budget, team size, timeline, existing tech stack, regulatory jurisdiction.
• Out-of-scope items are as important as in-scope — prevents over-engineering.
• Assumptions should be stated aloud: 'I'll assume 10M DAU, 80/20 read/write, eventual consistency for likes.'

flowchart LR
  FR[Functional] --> Features
  NFR[Non-Functional] --> Scale
  NFR --> Latency
  NFR --> Availability

Internal architecture

Architecture overview

flowchart LR
  FR[Functional] --> Features
  NFR[Non-Functional] --> Scale
  NFR --> Latency
  NFR --> Availability

Step-by-step explanation

1. List actors (user, admin, third-party webhook) and primary use cases (create, read, search, pay).
2. For each use case, note peak frequency, payload size, and consistency needs.
3. Prioritize NFRs: which one fails the business if unmet (payment correctness > feed ordering).
4. Map top NFRs to mechanisms: cache for latency, replication for availability, sharding for write scale.
5. Identify compliance and security NFRs early — they constrain data residency and encryption.
6. Write a one-paragraph scope statement the interviewer can confirm or correct.

Informative example

Capture requirements as structured YAML consumed by a design doc or interview template — keeps FR/NFR visible while you draw architecture:

product: url-shortener
functional:
  - shorten long URL to 7-char slug
  - redirect slug to original URL
  - optional custom alias for premium users
  - analytics: click count per slug
non_functional:
  read_qps_peak: 100000
  write_qps_peak: 1000
  read_latency_p99_ms: 50
  availability_sla: "99.99%"
  retention_years: 5
  consistency: strong for create; eventual for analytics
constraints:
  - no duplicate slugs globally
  - GDPR: delete user data on request
assumptions:
  - 100:1 read/write ratio
  - average original URL length 100 bytes

Read this aloud in interviews. Numbers turn vague 'high scale' into concrete cache, DB, and CDN choices.

Real-world use

Real-world use cases

• E-commerce: checkout correctness (FR) vs flash-sale peak QPS (NFR).
• Healthcare: HIPAA audit trails (NFR) vs appointment booking (FR).
• OTT: 4K streaming bandwidth (NFR) vs catalog search (FR).
• Fintech: PCI-DSS and idempotent payments (NFR) vs wallet transfer (FR).

Best practices

• Use the acronym SCALE or RELIABLE to probe NFR categories systematically.
• Quantify whenever possible — 'fast' becomes 'p99 < 100 ms for reads.'
• Separate MVP FRs from 'nice to have' to avoid scope creep in 45 minutes.
• Link each major component to an NFR it satisfies (CDN → latency, Kafka → decoupling).
• Revisit requirements after capacity estimation — numbers may invalidate earlier choices.
• Document trade-offs when NFRs conflict (strong consistency vs global low latency).

Common mistakes

• Assuming unlimited budget or infinite engineering headcount.
• Ignoring delete/export requirements until compliance questions appear.
• Treating all features as equally consistent — likes don't need bank-grade ACID.
• Skipping mobile vs web client differences (offline mode, push notifications).
• Not confirming whether the system is greenfield or must integrate with legacy ERP.

Advanced interview questions

Summary

FRs define behavior; NFRs define quality attributes and drive architecture. Always clarify scope, scale, and consistency before drawing components. State assumptions explicitly and invite correction. Map each major architectural choice back to a requirement. Capacity numbers belong in the requirements phase, not as an afterthought. Good requirements prevent wrong technology choices early.