What is Requirements Gathering in System Design

When solving a System Design problem, many beginners immediately start discussing databases, microservices, caching, and load balancers.

However, experienced engineers follow a different approach.

Before designing any architecture, they first understand what needs to be built.

This process is called Requirements Gathering.

Requirements gathering helps engineers identify business goals, user needs, system constraints, and expected scale before making technical decisions.

A well-designed system starts with clear requirements. Without them, even a technically strong architecture can solve the wrong problem.

Why Requirements Gathering Matters

Consider the following interview question:

Design a Notification System

Many candidates immediately start drawing components such as:

• Databases

• Message Queues

• Cache Layers

• Notification Services

This approach often leads to incorrect assumptions.

Before discussing architecture, you should first understand:

• What types of notifications are supported?

• Who receives notifications?

• How many users will use the system?

• Is real-time delivery required?

• What are the business objectives?

The answers to these questions directly influence the final architecture.

Types of Requirements

In System Design, requirements are usually divided into two categories:

1. Functional Requirements

2. Non-Functional Requirements

Goal of Requirements Gathering

The goal is to collect enough information to make informed design decisions.

By the end of this phase, you should clearly understand:

• The problem being solved

• Target users

• Core features

• Expected scale

• Business constraints

• Technical constraints

• Success metrics

Once these details are clear, architecture design becomes significantly easier.

Step-by-Step Requirements Gathering Framework

Step 1: Understand the Problem

Start by understanding the business problem.

Ask questions such as:

• What problem are we solving?

• Who are the users?

• What is the primary goal of the system?

• Why does this system exist?

This helps define the scope of the discussion.

Step 2: Identify Functional Requirements

Functional requirements describe what the system should do.

For a chat application, functional requirements may include:

• Send messages

• Receive messages

• Create groups

• Share media files

Focus on the most important features first.

Additional features can be discussed later.

Step 3: Identify Non-Functional Requirements

Non-functional requirements describe how the system should behave.

Examples include:

• Low latency

• High availability

• Reliability

• Scalability

• Security

• Durability

Example:

For a stock trading platform, low latency may be critical.

For a video streaming platform, scalability may be more important.

These requirements strongly influence architecture decisions.

Step 4: Estimate Scale

Estimate the expected size of the system.

Questions may include:

• How many users are expected?

• Daily Active Users (DAU)?

• Requests per second?

• How much data will be stored?

• Expected growth rate?

Scale determines:

• Database choices

• Caching strategies

• Load balancing requirements

• Infrastructure size

Step 5: Identify Constraints

Every system operates within certain limitations.

Examples include:

• Budget restrictions

• Technology constraints

• Compliance requirements

• Development timelines

• Regulatory requirements

Understanding constraints helps avoid unrealistic designs.

Step 6: Define Success Metrics

Understand how success will be measured.

Examples include:

• Response time under 200 ms

• 99.99% availability

• Less than 0.1% failed requests

• Support 10 million users

Success metrics help evaluate whether the design meets business expectations.

Step 7: Define Out-of-Scope Features

Not every feature needs to be included in the initial design.

Clearly identify features that are excluded.

For example, when designing a chat application:

In Scope

• One-to-one messaging

• Group messaging

Out of Scope

• Voice calls

• Video calls

• Screen sharing

Defining scope prevents unnecessary complexity.

Common Questions to Ask

Users

• Who will use the system?

• How many users are expected?

Features

• What are the core features?

• Which features are optional?

• What is out of scope?

Scale

• Expected traffic volume?

• Expected storage requirements?

Performance

• Is low latency important?

• Is real-time communication required?

Reliability

• How much downtime is acceptable?

• Can data loss occur?

Security

• Is authentication required?

• Is sensitive user data involved?

Real Example

Problem: Design WhatsApp

Requirements gathering may produce the following information:

Functional Requirements

• Send messages

• Receive messages

• Create groups

• Share media

Non-Functional Requirements

• Low latency

• High availability

• Reliable message delivery

Scale

• Millions of active users

• Billions of messages per day

Out of Scope

• Video calling

• Status updates

After gathering these requirements, you can confidently move to architecture design.

Common Mistakes

Avoid these mistakes:

• Jumping directly into architecture

• Making assumptions without clarification

• Ignoring scale requirements

• Ignoring business constraints

• Focusing on technology before understanding the problem

• Trying to design everything at once