Requirements & Problem Analysis

5 min read

Why This Is the Most Important Step

Every system design — in an interview or in production — starts here. Not with databases, not with caching strategies, not with Kubernetes. It starts with understanding the problem. The biggest mistake engineers make is jumping to solutions in the first minute. They start drawing load balancers and message queues before they even know what the system is supposed to do, for whom, and at what scale.

Requirements analysis is the act of turning a vague, impossibly broad prompt ("design Twitter," "build a payment system") into something concrete enough to actually architect. It answers three fundamental questions:

What does the system do? — the features and capabilities (functional requirements)
How well does it do it? — the performance, availability, and quality bar (non-functional requirements)
What are we not building? — the explicit scope boundary that keeps you focused

Get this right, and every subsequent decision — your data model, your API design, your choice of database, your caching strategy — has a foundation. Get it wrong, and you'll spend 40 minutes designing a beautifully over-engineered system that solves the wrong problem.

When This Comes Up

System design interviews: The first 5–8 minutes should be spent here. Interviewers are testing whether you can drive ambiguity toward clarity. Starting to draw boxes immediately is the most common red flag.
Real-world architecture: Every design document starts with a requirements section. Product teams write PRDs (Product Requirements Documents) that map to functional requirements; SLAs and capacity plans map to non-functional requirements.
Tech lead conversations: Senior engineers are expected to push back on vague requirements, surface hidden constraints, and force prioritization before committing to a design.

How the Sub-Topics Connect

The four sub-topics below follow a natural sequence — each one builds on the previous:

1. Functional vs Non-Functional Requirements

This is the foundational split. Functional requirements are what the system does — the user-facing features like "post a tweet," "send a message," or "process a payment." They shape your API endpoints and data model. Non-functional requirements are how well it does it — availability targets (99.99%), latency budgets (p99 < 200ms), scalability needs (500M DAU), durability guarantees (zero data loss). These shape your architecture.

The key insight is that two systems can have identical features but require completely different architectures if their non-functional requirements differ. A chat app for 100 users and one for 100 million users share the same features — but the second one needs message queues, sharding, CDNs, and multi-region deployment.

This sub-topic covers how to identify both types, common examples, why non-functional requirements are the real architecture drivers, and the mistakes that come from treating them as afterthoughts.

2. Constraints & Assumptions

Every prompt leaves things unsaid. "Design Instagram" doesn't tell you whether media includes video, whether the system must comply with GDPR, or whether the team has 3 engineers or 300. Constraints are the hard limits you discover or are given — budget, team size, regulatory requirements, technical integrations. Assumptions are the educated guesses you make to fill the gaps — "I'll assume reads outnumber writes 100:1," "I'll assume media files are under 10MB."

Stating assumptions explicitly is not hedging — it's the discipline of turning an ambiguous problem into a bounded one. An assumption you don't state is an invisible architectural risk. This sub-topic also covers scope and goals — drawing a clear line around what you will and won't build, so you don't waste time designing features nobody asked for.

3. Estimation Techniques

Once you have requirements and assumptions, estimation turns them into numbers — and those numbers justify (or invalidate) your architecture. Back-of-the-envelope calculations answer questions like: How many queries per second will the system handle? How much storage do we need for 5 years? How many servers are required? How much bandwidth will we consume?

If 500M users each read 20 posts a day, that's 10 billion reads/day ≈ 115K QPS on average, perhaps 350K QPS at peak. That single number immediately tells you: a single database won't do, you need a caching layer, and you need horizontal scaling. Without the estimation, "we need caching" is an opinion; with it, it's an engineering decision backed by data.

This sub-topic includes the key reference numbers every engineer should know (latency at each layer, storage conversions), a step-by-step estimation process, and a full worked example at Twitter scale.

4. MoSCoW Prioritization

You can't build everything at once, and you shouldn't try. MoSCoW sorts requirements into four buckets: Must have (the system is broken without it), Should have (important, not a dealbreaker), Could have (nice if time allows), and Won't have (explicitly deferred). But the real power of MoSCoW isn't the feature list — it's the forced conversation about trade-offs.

In system design, you cannot simultaneously maximize consistency, availability, latency, cost, and feature count. MoSCoW forces you to decide: Is payment consistency more important than feed latency? Is 99.99% availability worth the cost over 99.9%? The senior move is applying different priorities to different parts of the same system — strong consistency for payments, eventual consistency for likes.

This sub-topic covers both feature prioritization and quality-attribute prioritization, common trade-off tensions, and how MoSCoW adapts across iterations.

Sub-Topics

#	Sub-Topic	What You'll Learn
1	Functional vs Non-Functional Requirements	The foundational split that shapes APIs vs architecture
2	Constraints & Assumptions	Turning ambiguity into a bounded, solvable problem
3	Estimation Techniques	Back-of-the-envelope math that justifies every architecture choice
4	MoSCoW Prioritization	Ranking what to build and which quality attributes to optimize