Requirements Gathering in System Design

A team was asked to build a feature called “Smart Notifications.” They spent weeks designing it. It was fast. It scaled well. It looked impressive.

When it launched, users barely used it. Why?

Because no one had clearly defined what problem it was supposed to solve. The system was well designed, but the requirements were never clear.

This happens more often than system failures.

Why Requirements Are Important Than Architecture

You can design the best system in the world. But if the requirements are wrong, the system will fail.

System design always starts with understanding:

• what needs to be built
• how well it needs to work
• what limits exist

Good requirements make system design easier.
Bad requirements make system design impossible.

Functional vs Non-Functional Requirements

These two sound technical, but the idea is simple.

Functional Requirements

Functional requirements describe what the system does.

For example:

• A user can sign up.
• A user can send a message.
• A user can download a certificate.

If it describes an action, it is functional.

Non-Functional Requirements

Non-functional requirements describe how well the system must perform.

For example:

• The system should respond quickly.
• The system should be available most of the time.
• The system should protect user data.

These don’t add features, but they shape the design. In interviews, many candidates list features and stop.
Strong candidates talk about both.

SLOs, SLAs, and Constraints

Let’s simplify these ideas.

SLO (Service Level Objective)

An SLO is an internal goal.

For example:

“95% of requests should respond within 200 ms.”

It helps teams know if the system is healthy.

SLA (Service Level Agreement)

An SLA is a promise to users or customers.

For example:

“We guarantee 99.9% uptime.”

If you break it, there may be penalties. In interviews, mentioning SLAs shows you understand real systems, not just theory.

Constraints Shape Everything

Constraints are non-negotiable limits.

Common constraints include:

• budget
• latency
• legal or compliance rules
• team size

You don’t design around constraints later. You design because of them.

MVP vs v1 vs v2

This is where many systems go wrong.

Teams try to build everything in one version.

MVP (Minimum Viable Product)

The MVP solves the core problem only.

It proves that users actually want the product.

No extra features.
No perfect scaling.
Just enough to learn.

Version 1 (v1)

v1 improves stability and usability.

It adds:

• basic monitoring
• better performance
• essential edge cases

This is when system design starts to matter more.

Version 2 (v2)

v2 focuses on scale and optimization.

This is where you add:

• advanced caching
• background processing
• stronger reliability

In interviews, clearly separating MVP, v1, and v2 shows maturity.

Turning Vague Ideas into Clear Requirements

Interviewers often give vague problems.

For example:

“Design a system for online certificates.”

That’s not enough.

A strong candidate asks:

• Who uses it?
• How often?
• How fast should it be?
• How important is security?

This is how vague ideas become clear specs.

AI to Improve Requirement Gathering

AI is very useful at this stage.

You can use it to:

• list missing requirements
• identify constraints
• suggest edge cases

But AI should expand, not decide. You still choose what matters.

AI-Assisted Requirement Flow

• First, state your assumptions.
• Then ask AI to suggest requirements.
• Then filter and prioritize them.
• Finally, restate the final requirements in your own words.

This keeps your thinking clear and interview-safe.

What Interviewers Want to See

They want to see that you:

• don’t rush into design
• ask the right questions
• understand tradeoffs
• define scope clearly

A clear requirement discussion often matters more than the final architecture.

Key Takeaways

Good system design starts before drawing diagrams.

If you learn to gather requirements properly:

• designs become simpler
• mistakes reduce
• interviews become easier