All Roadmaps›🏛️ System Design›Phase 1›Requirements Gathering & Scope Definition

Requirements Gathering & Scope Definition

0/4 in this phase0/45 across the roadmap

📖 Concept

The #1 mistake in system design interviews is jumping into the solution before understanding the problem. Requirements gathering is the most critical first step in any system design — both in interviews and in real-world engineering.

Two Types of Requirements

Functional Requirements (FR)

What the system must do:

  • "Users can send messages to other users"
  • "The system must support group chats up to 500 members"
  • "Messages should be delivered in order"

Non-Functional Requirements (NFR)

How the system must behave:

NFR Description Example
Scalability Handle growing load 1M concurrent users
Availability Uptime guarantee 99.99% (52 min downtime/year)
Latency Response speed < 200ms for 99th percentile
Consistency Data correctness Strong consistency for payments
Durability Data survival No message loss, ever

The RESHADED Framework

A structured way to cover all NFR dimensions:

  • Requirements (functional)
  • Estimation (scale numbers)
  • Storage schema
  • High-level design
  • API design
  • Detailed design
  • Evaluation (trade-offs)
  • Distinctive features (unique selling points)

Why This Matters

In a 45-minute interview, spending 5-8 minutes on requirements is not wasted time — it's the most valuable investment. It shows the interviewer you think before you code, you can identify ambiguity, and you design for real constraints rather than imaginary ones.

Interview tip: Always ask "What's our expected scale?" and "What's more important — consistency or availability?" These two questions alone can change your entire design.

💻 Code Example

codeTap to expand ⛶
1// ============================================
2// Requirements Gathering — Structured Approach
3// ============================================
4

5// Example: Design a URL Shortener (like bit.ly)
6// This shows how to document requirements before designing
7

8// ---------- Step 1: Clarifying Questions ----------
9const clarifyingQuestions = [
10  "How many URLs will be shortened per day?",         // → Scale
11  "How long should shortened URLs be valid?",          // → Data retention
12  "Should users be able to customize short URLs?",     // → Feature scope
13  "Do we need click analytics?",                       // → Feature scope
14  "What's the expected read:write ratio?",             // → Access pattern
15  "Should links be deletable/editable?",               // → Mutability
16  "Do we need user accounts or anonymous access?",     // → Auth scope
17];
18

19// ---------- Step 2: Functional Requirements ----------
20const functionalRequirements = {
21  core: [
22    "Given a long URL, generate a unique short URL",
23    "When user accesses short URL, redirect to original long URL",
24    "Short URLs should expire after a configurable TTL (default: 5 years)",
25  ],
26  extended: [
27    "Users can create custom short URLs (e.g., bit.ly/my-link)",
28    "Track click analytics: count, referrer, geo-location",
29    "API access for programmatic URL shortening",
30  ],
31  outOfScope: [
32    "User registration and authentication (for MVP)",
33    "URL content previews / screenshots",
34    "Malware/phishing detection",
35  ],
36};
37

38// ---------- Step 3: Non-Functional Requirements ----------
39const nonFunctionalRequirements = {
40  scale: {
41    newURLsPerDay: 100_000_000,    // 100M writes/day
42    urlRedirectsPerDay: 10_000_000_000, // 10B reads/day → 100:1 read:write
43    totalURLsStored: "100 billion over 5 years",
44  },
45  performance: {
46    writeLatency: "< 500ms p99",
47    readLatency: "< 50ms p99",     // Redirects must be FAST
48    availability: "99.99%",        // 52 minutes downtime per year
49  },
50  constraints: {
51    urlLength: "7-8 characters",   // Short enough to share easily
52    characterSet: "a-z, A-Z, 0-9", // 62 possible characters
53    uniqueness: "No two long URLs should produce the same short URL",
54  },
55};
56

57// ---------- Step 4: Back-of-Envelope Math ----------
58const estimation = {
59  storage: {
60    avgURLSize: 500,               // bytes per URL record
61    urlsIn5Years: 100_000_000 * 365 * 5, // ≈ 182.5 billion
62    totalStorage: "182.5B * 500 bytes ≈ 91 TB",
63  },
64  bandwidth: {
65    incomingWrite: "100M * 500 bytes / 86400 ≈ 580 KB/s",
66    outgoingRead: "10B * 500 bytes / 86400 ≈ 58 MB/s",
67  },
68  qps: {
69    writes: "100M / 86400 ≈ 1,160 writes/sec",
70    reads: "10B / 86400 ≈ 115,740 reads/sec",
71    peakReads: "115,740 * 3 ≈ 347,000 reads/sec (3x peak factor)",
72  },
73};
74

75// ---------- Step 5: Key Decisions Document ----------
76const keyDecisions = {
77  consistency: "Eventual consistency is acceptable for analytics; " +
78    "strong consistency needed for URL creation (no duplicate short URLs)",
79  caching: "Heavy read load (100:1 ratio) → aggressive caching with Redis/Memcached",
80  database: "NoSQL (Cassandra/DynamoDB) for horizontal scaling of simple key-value lookups",
81  encoding: "Base62 encoding of auto-increment ID or MD5 hash truncation",
82};
83

84// This structured approach gives you a CLEAR foundation
85// before drawing a single architecture diagram
86console.log("Requirements documented. Ready to design!");
87console.log("Estimated QPS:", estimation.qps);
88console.log("Key tradeoff:", keyDecisions.consistency);

🏋️ Practice Exercise

  1. Chat Application Requirements: Write down all functional and non-functional requirements for WhatsApp. Include scale estimates (how many messages/day, users, message size limits).

  2. Ambiguity Detection: Given just "Design Twitter," list at least 10 clarifying questions you'd ask before starting the design. Categorize them into functional scope, scale, and constraints.

  3. NFR Prioritization: For an online banking system, rank these NFRs: latency, consistency, availability, scalability. Justify each ranking with a concrete scenario.

  4. Scope Creep Exercise: You're asked to design a "simple file storage service." Write the MVP requirements, then list 5 features that are tempting to include but should be explicitly marked as out-of-scope for V1.

  5. Requirements to Architecture: Given these requirements — "500K daily active users, 50ms read latency, 99.9% availability, eventual consistency acceptable" — what architectural components would you immediately select? Explain each choice.

⚠️ Common Mistakes

  • Jumping into drawing architecture diagrams before understanding what the system needs to do — the #1 interview killer. Spend 5-8 minutes on requirements first.

  • Treating all non-functional requirements as equally important — in reality, there are always trade-offs (CAP theorem). Ask the interviewer which NFR matters most.

  • Not establishing scale numbers early — designing for 100 users vs. 100 million users leads to completely different architectures. Always ask for expected scale.

  • Ignoring edge cases in requirements — what happens when a URL expires? What if two users create the same custom short URL simultaneously? Surface these during requirements.

  • Making the scope too large — trying to design every feature of YouTube in 45 minutes is impossible. Explicitly define what's in scope and what's not.

💼 Interview Questions

🎤 Mock Interview

Practice a live interview for Requirements Gathering & Scope Definition

← PreviousClient-Server ArchitectureNext →Back-of-Envelope Estimation