Gathering Requirements Effectively

Why This Step Matters More Than You Think

The first 5 minutes of a system design interview are the most important. Before you draw a single box on that whiteboard, you need to understand what you’re actually building.

We’ve seen this happen countless times: An interviewer says “Design Twitter,” and a candidate immediately starts drawing databases, caches, and feed microservices. But here’s the thing — Twitter for 100 users is completely different from Twitter for 500 million users. Twitter with only text is different from Twitter with images, videos, and live streaming.

Many candidates rush past requirements. They think asking clarifying questions wastes time. It doesn’t. Senior engineers ask questions. Junior engineers assume. The interviewer is explicitly testing whether you can understand a vague problem and ask intelligent questions to narrow it down.

Think of it this way: you wouldn’t start building a house without knowing whether it needs 2 bedrooms or 10, whether it’s beachfront or inland, whether it needs to withstand hurricanes. Same principle.

Functional Requirements: What Users Actually Do

Functional requirements are the features — what the system needs to do. This is where most engineers start, but they often miss critical details.

The User Journey Approach

Instead of asking “what features does the system have?” think about how users actually interact with it:

Example: Designing a URL Shortener

Walk through the user journey:

1. User visits the web app and enters a long URL
2. System returns a short code
3. User shares the short link
4. When someone clicks the short link, they’re redirected to the original URL
5. User can see statistics (click count, referrer data)

Now you’re thinking about the actual flow, not just abstract features.

Key Questions to Ask

• Who are the users? (End users? Admin users? Both?)
• What are the core features? (Just redirects, or include analytics?)
• What’s the input/output format? (JSON? Form data?)
• What are the nice-to-haves vs must-haves? (Custom short codes? Expiration dates?)
• Are there specific use cases? (Marketing campaigns? Internal link sharing?)

Pro tip: Have the interviewer prioritize. If they say everything is critical, gently push back: “If we could only ship three features, which would they be?” Real products prioritize ruthlessly, and good interviewers respect that thinking.

Non-Functional Requirements: The Questions Most Candidates Skip

This is where senior candidates separate from the rest. While everyone’s sketching functional requirements, you’re asking about scale, consistency, and availability.

Non-functional requirements describe how the system should behave under specific conditions. They’re often more important than features.

The SCALDS Framework

Use this acronym to remember the key non-functional requirement categories:

Category	Key Questions
Scale	How many users? Daily active users? Requests per second? How much data over time?
Consistency	Do all users need to see the same data immediately? Can there be temporary inconsistency?
Availability	What’s the acceptable downtime? 99.9% uptime? 99.99%?
Latency	How fast should the system respond? 100ms? 1 second?
Durability	Can we ever lose data? What’s acceptable data loss?
Security	Do we need encryption? Authentication? Rate limiting against abuse?

Why This Matters (A Real Example)

Design a chat application. Seems straightforward, right? But the non-functional requirements completely change the architecture:

Version A: Eventual Consistency, Moderate Availability

• Messages can take a few seconds to sync across devices
• 99.9% uptime is acceptable
• Can tolerate occasional data loss if user’s app crashes

This could run on a simpler architecture with a single database and basic replication.

Version B: Strong Consistency, High Availability

• Messages must be delivered reliably in order
• 99.99% uptime (less than 1 hour downtime per year)
• Zero acceptable data loss

This needs distributed consensus, multiple replicas, and careful orchestration.

Same feature set. Completely different architecture.

How to Ask Without Annoying the Interviewer

You’re walking a fine line: ask too few questions and you miss critical details. Ask too many and you seem indecisive. Here’s the approach that works:

Be Specific, Not Vague

Bad: “How big is this?”

Better: “Should we design for millions of users or thousands?”

Vague questions waste time. Specific questions show you’ve thought about the problem and you’re trying to narrow down the scope.

Ask About Trade-offs

Good: “How important is consistency vs availability? If we had to choose, which would you prioritize?”

This shows you understand that every system makes trade-offs. It also gives you permission to design with those trade-offs in mind.

Confirm Your Understanding

After the interviewer answers: “So if I understand correctly, we’re designing for 100 million daily active users, and consistency is less important than availability — is that right?”

Repeating back confirms you understood and gives the interviewer a chance to correct misconceptions early.

Prioritizing Requirements: The MoSCoW Method

Not all requirements are equally important. Use the MoSCoW method to categorize:

• Must Have: Core features required for the system to function (user login, post creation for a social network)
• Should Have: Important features that add significant value but the system works without them (analytics dashboard)
• Could Have: Nice features if time permits (advanced filtering, AI recommendations)
• Won’t Have: Explicitly out of scope for this design (mobile app, desktop client)

This conversation with the interviewer might sound like:

“So the core features are posting, following, and the feed, right? Analytics is nice-to-have but not essential. And we’re not designing the mobile app — that’s a separate project. Is that correct?”

This shows you’re thinking about scope and priorities, not just trying to design everything.

Document Requirements Before You Design

Here’s a habit that separates good candidates from great ones: write the requirements on the whiteboard before you start designing.

This accomplishes three things:

1. Shows discipline. You’re not jumping straight to solutions.
2. Creates a reference. When you’re deep in the design and the interviewer challenges you, you can point back to the original requirements.
3. Confirms alignment. The interviewer sees what you think you heard and can correct you if needed.

A simple format:

FUNCTIONAL REQUIREMENTS:
- Users can post messages up to 280 characters
- Users can follow/unfollow other users
- Users can view their feed (posts from followed users)
- System should rank feed by recency and engagement

NON-FUNCTIONAL REQUIREMENTS:
- Scale: 300M DAU, 200 requests/second average
- Latency: Feed should load in under 500ms
- Availability: 99.9% uptime
- Consistency: Feed updates within 1-2 seconds

Takes 2 minutes. Saves you 10 minutes of confusion later.

Real-World Requirement Examples

Let’s walk through how you’d approach requirements for three different systems:

Example 1: Design a URL Shortener

Your questions might be:

• “Should we support custom short codes, or only auto-generated ones?” (Feature scope)
• “How long should short URLs live — forever or do they expire?” (Data retention)
• “Do we need to track click analytics?” (Feature vs nice-to-have)
• “How many short URLs created per second?” (Scale)
• “How important is latency for redirects?” (Performance target)

Possible answer summary: Support millions of URL shortenings per day, auto-generated codes, URLs live forever, basic analytics optional, redirects must be under 100ms.

Example 2: Design a Chat Application

Your questions might be:

• “Is this one-on-one messaging or group chat?” (Feature scope)
• “How important is message ordering? Do messages have to arrive in the exact order sent?” (Consistency)
• “What if someone is offline? Should we queue messages?” (Behavior)
• “Do we need to support file sharing?” (Feature scope)
• “How many messages per second?” (Scale)
• “How long can a message take to deliver?” (Latency)

Possible answer summary: One-on-one and group, messages must be ordered, offline users get messages when they reconnect, 100K messages per second peak, deliver within 1 second.

Example 3: Design a Video Streaming Service

Your questions might be:

• “Do we need to support live streaming or just on-demand?” (Feature scope)
• “What video quality options?” (This affects storage and bandwidth)
• “How many concurrent viewers?” (Scale)
• “What’s acceptable latency for live streams?” (200ms is great, 5 seconds is still live)
• “Can we buffer and show lower quality if bandwidth is low?” (Adaptive bitrate)
• “How long to retain videos?” (Storage planning)

Possible answer summary: On-demand with 720p/1080p options, 10 million concurrent viewers, adaptive bitrate streaming, videos archived indefinitely.

Did You Know?

Real product requirements rarely come from interviewers. You’ll hear things like “Design something like Uber” or “Build a notification system.” The vagueness is intentional — it’s testing whether you can ask good questions. In real jobs, product managers, customers, and stakeholders give you requirements. In interviews, you have to extract them.

Common Mistakes in Requirement Gathering

Mistake 1: Assuming too much

You design a system supporting millions of users when the problem was for a startup with 10,000. Now your architecture is over-engineered.

Mistake 2: Missing non-functional requirements

You nail the features but never ask about latency, consistency, or availability. Your high-level design might violate those unstated requirements.

Mistake 3: Asking too many questions

The interviewer says “Design a payment system” and you ask 30 clarifying questions. At some point, you need to make reasonable assumptions and move forward.

Mistake 4: Not confirming your understanding

You ask a question, get an answer, but never confirm you understood correctly. Misalignment compounds as you design.

Key Takeaways

• Spend the first 5 minutes asking clarifying questions — this is not wasted time
• Functional requirements are what the system does; non-functional requirements are how well it does them
• Use SCALDS to remember key non-functional categories: Scale, Consistency, Availability, Latency, Durability, Security
• Ask specific questions about trade-offs and priorities
• Write requirements on the whiteboard before designing
• Confirm your understanding of the interviewer’s answers
• Use MoSCoW prioritization to distinguish must-haves from nice-to-haves

Practice Exercise

For each of these systems, write out the functional and non-functional requirements you’d ask about:

1. Design an Instagram-like photo sharing app

   • What questions would you ask?
   • What would be your must-have vs could-have features?

2. Design a search engine for internal company documents

   • What’s the scale?
   • How important is search quality vs speed?

3. Design a real-time stock price ticker

   • How many stocks to track?
   • What latency is acceptable?
   • How accurate must the prices be?

Write out at least 5 specific questions for each before looking at the next section.

Next: Estimating Scale and Constraints

Now that you’ve gathered requirements, the next critical step is putting numbers on the problem. How many requests per second? How much storage? How much bandwidth? These “back-of-the-envelope” calculations separate engineers who can think about scale from those who design abstractly. Let’s learn the estimation framework that works.