Requirements analysis in LLD - Scalability & System Analysis

Scalability Analysis - Requirements analysis

Growth Table: What Changes at Each Scale

Users	Data Volume	Traffic	System Complexity	Requirements Focus
100 users	Small (MBs)	Low (few requests/sec)	Simple	Basic functionality, correctness
10,000 users	Medium (GBs)	Moderate (hundreds req/sec)	Moderate	Performance, reliability, usability
1,000,000 users	Large (TBs)	High (thousands req/sec)	Complex	Scalability, fault tolerance, security
100,000,000 users	Very Large (PBs)	Very High (millions req/sec)	Very Complex	Global distribution, data partitioning, disaster recovery

First Bottleneck: What Breaks First and Why

At small scale, unclear or incomplete requirements cause delays and rework.

At medium scale, performance bottlenecks appear if requirements miss load expectations.

At large scale, missing scalability and fault tolerance requirements cause system failures.

At very large scale, lack of clear data partitioning and disaster recovery requirements leads to outages.

Scaling Solutions: How to Adapt Requirements Analysis

• Start with clear, detailed functional and non-functional requirements.
• Use iterative refinement: gather feedback and update requirements regularly.
• Include scalability, reliability, and security early in requirements.
• Plan for data growth and traffic spikes in requirements.
• Use modeling and prototyping to validate requirements before implementation.
• Engage stakeholders continuously to avoid misunderstandings.

Back-of-Envelope Cost Analysis

Requests per second grow from a few at 100 users to millions at 100M users.

Data storage needs grow from megabytes to petabytes.

Network bandwidth and processing power requirements increase accordingly.

Early requirements must estimate expected load to avoid costly redesigns.

Interview Tip: Structuring a Scalability Discussion on Requirements Analysis

1. Clarify the system scope and user base size.

2. Identify key functional and non-functional requirements.

3. Discuss how requirements evolve with scale.

4. Highlight potential bottlenecks caused by missing or vague requirements.

5. Suggest iterative and stakeholder-driven approaches to refine requirements.

Self-Check Question

Your system requirements specify support for 1000 requests per second. Traffic grows 10x. What do you do first?

Answer: Revisit and update requirements to include higher load expectations, then plan system design changes accordingly.

Key Result

Clear, evolving requirements are critical to scaling systems smoothly; missing or vague requirements cause early bottlenecks and costly redesigns.

Practice

1. What is the main purpose of requirements analysis in system design?

easy

A. To deploy the system to users

B. To write the system code

C. To test the system performance

D. To define what the system must do

Solution

1. Step 1: Understand the role of requirements analysis

   Requirements analysis focuses on understanding and defining the system's needs and functions.

2. Step 2: Differentiate from other phases

   Writing code, testing, and deployment happen after requirements are clear.

3. Final Answer:

   To define what the system must do -> Option D

4. Quick Check:

   Requirements analysis = Define system needs [OK]

Hint: Requirements analysis = What system must do [OK]

Common Mistakes:

• Confusing requirements analysis with coding
• Thinking testing is part of requirements
• Mixing deployment with requirements gathering

2. Which of the following is a correct step in requirements analysis?

easy

A. Writing deployment scripts

B. Compiling source code

C. Gathering user needs

D. Running system tests

Solution

1. Step 1: Identify key activities in requirements analysis

   Gathering user needs is essential to understand what the system should do.

2. Step 2: Exclude unrelated activities

   Deployment scripts, compiling code, and testing happen after requirements are set.

3. Final Answer:

   Gathering user needs -> Option C

4. Quick Check:

   Requirements analysis = Gather needs [OK]

Hint: Gather user needs first in requirements analysis [OK]

Common Mistakes:

• Mixing coding or deployment with requirements
• Ignoring user input during analysis
• Confusing testing with requirements gathering

3. Given these requirements:
- System must handle 1000 users simultaneously
- Data must be encrypted
- Users can reset passwords
Which requirement type is "Data must be encrypted"?

medium

A. Non-functional requirement

B. Functional requirement

C. Business requirement

D. User interface requirement

Solution

1. Step 1: Classify the requirement "Data must be encrypted"

   This describes a quality or constraint on the system, not a specific function.

2. Step 2: Understand requirement types

   Functional requirements describe actions; non-functional describe qualities like security.

3. Final Answer:

   Non-functional requirement -> Option A

4. Quick Check:

   Encryption = Non-functional requirement [OK]

Hint: Security needs are non-functional requirements [OK]

Common Mistakes:

• Confusing security with functional features
• Mixing business goals with technical details
• Assuming all requirements are functional

4. A requirements document states: "Users must login with username and password." Later, it says: "Users can login using email and password." What is the main issue here?

medium

A. Performance bottleneck

B. Ambiguous requirements

C. Security vulnerability

D. Scalability problem

Solution

1. Step 1: Identify conflicting statements

   The document gives two different login methods without clarifying which is correct.

2. Step 2: Understand impact of ambiguity

   Ambiguous requirements confuse developers and cause design errors.

3. Final Answer:

   Ambiguous requirements -> Option B

4. Quick Check:

   Conflicting login info = Ambiguity [OK]

Hint: Conflicting info means ambiguous requirements [OK]

Common Mistakes:

• Assuming security or performance issues without evidence
• Ignoring requirement conflicts
• Thinking scalability relates to login methods

5. You are designing a messaging app. Which of these is the best way to gather requirements to ensure scalability and user satisfaction?

hard

A. Interview users, analyze competitors, and document clear functional and non-functional needs

B. Start coding immediately based on your assumptions

C. Only focus on UI design without backend planning

D. Ignore user feedback and add features later

Solution

1. Step 1: Identify best practices in requirements gathering

   Interviewing users and analyzing competitors helps understand real needs and market standards.

2. Step 2: Emphasize clear documentation of all requirements

   Clear functional and non-functional requirements guide scalable and user-friendly design.

3. Final Answer:

   Interview users, analyze competitors, and document clear functional and non-functional needs -> Option A

4. Quick Check:

   User research + clear docs = good requirements [OK]

Hint: Gather user input and document clearly before coding [OK]

Common Mistakes:

• Skipping user research
• Starting development without clear requirements
• Ignoring backend needs for scalability