02 — Requirements Gathering

Requirements gathering is the foundation of every well-designed system. Before you draw a single architecture diagram, you must understand what the system should do and how well it should do it.

Analogy: Requirements are like the recipe for a dish. If the recipe says “bake until golden,” but doesn’t specify temperature or time, the cake will fail. Requirements must be precise.

Teams often skip or rush requirements gathering, leading to:

• Building features nobody needs
• Systems that don’t meet performance expectations
• Costly rework and architecture changes
• Unclear success criteria — “is it done?”

flowchart TB
    Req["Requirements Gathering"] --> Func["Functional Requirements<br/>What the system does"]
    Req --> NonFunc["Non-Functional Requirements<br/>How well the system does it"]

    Func --> F1["User-facing features"]
    Func --> F2["APIs & interfaces"]
    Func --> F3["Business logic"]
    Func --> F4["Data processing"]

    NonFunc --> N1["Performance<br/>Latency, Throughput"]
    NonFunc --> N2["Scalability<br/>Users, Data Volume"]
    NonFunc --> N3["Availability<br/>Uptime, Fault Tolerance"]
    NonFunc --> N4["Security<br/>Auth, Encryption"]
    NonFunc --> N5["Maintainability<br/>Code, Operations"]

    style Req fill:#7c3aed,color:#fff
    style Func fill:#3b82f6,color:#fff
    style NonFunc fill:#059669,color:#fff

Functional requirements describe what the system must do. They are actions, behaviors, and features.

Template for documenting:

Feature: User Registration
- As a: New visitor
- I want to: Create an account with email and password
- So that: I can access personalized features
- Acceptance: Email verification sent within 30 seconds

NFRs describe how well the system performs — the quality attributes.

flowchart TB
    DAU["Daily Active Users<br/>e.g., 10M users"] --> Traffic["Traffic Estimation<br/>Requests per day"]
    Traffic --> Storage["Storage Estimation<br/>Data per user × users"]
    Traffic --> Bandwidth["Bandwidth Estimation<br/>Data in/out per second"]
    Storage --> DB_Size["Database Size<br/>+ Index overhead<br/>+ Backup space"]
    Bandwidth --> Network["Network Capacity<br/>Peak throughput"]

    DAU --> Concurrent["Concurrent Users<br/>DAU × concurrent ratio"]
    Concurrent --> Server_Count["Server Count<br/>Requests per server"]

    style DAU fill:#f59e0b,color:#fff
    style Traffic fill:#3b82f6,color:#fff
    style Server_Count fill:#059669,color:#fff

1. What’s the difference between functional and non-functional requirements?
2. How do you estimate the number of servers needed for 10M DAU?
3. What questions do you ask stakeholders during requirements gathering?
4. How do you prioritize conflicting requirements (e.g., low cost vs high availability)?
5. Give an example of a non-functional requirement that changed your architecture choice.

• Functional requirements = what the system does (features, APIs)
• Non-functional requirements = how well it does it (speed, scale, reliability)
• Get requirements in writing before starting architecture — assumptions cause failures
• Capacity estimation converts requirements into concrete numbers (servers, storage, bandwidth)
• Always ask “why” — understand the goal, not just the feature request
• Prioritize: Availability vs Consistency vs Cost vs Speed — you can’t have all four