Requirements Gathering

In 1962, President Kennedy asked NASA to put a man on the moon. If NASA engineers had simply nodded and started building rockets, the mission would have failed. Instead, they asked questions—thousands of them:

How do we protect astronauts from radiation? How do we navigate without GPS? How do we land on an unknown surface? How do we bring them back?

Each question revealed constraints, risks, and sub-problems that shaped the entire Apollo program. The mission succeeded not because the initial goal was clear, but because engineers relentlessly interrogated every assumption until clarity emerged.

System design works the same way. The quality of your design is bounded by the quality of the questions you ask. A mediocre engineer accepts vague requirements and makes assumptions. An exceptional engineer interrogates every ambiguity until the problem space is fully illuminated.

Questioning is not merely a technique—it's a fundamental engineering discipline that serves multiple critical functions:

1. Revealing Hidden Requirements

Stakeholders often don't know what they need until you ask. They describe symptoms ('we need faster reports') without articulating underlying problems ('key decisions are delayed by 3 days waiting for data'). Good questions uncover root causes:

• 'Why do you need faster reports?'
• 'What decisions depend on these reports?'
• 'What happens when the decision is delayed?'

These questions might reveal that the real need isn't faster reports—it's real-time dashboards or automated alerts.

2. Exposing Assumptions

Both you and stakeholders carry assumptions that feel so obvious they go unspoken. These implicit assumptions are landmines:

• You assume the system needs 99.99% availability; they assume 99% is fine
• They assume search results appear in the order entered; you assume relevance ranking
• Everyone assumes 'user' means paying customer; marketing assumes it includes free trial users

Questions surface these conflicts before they become expensive misunderstandings.

3. Defining Boundaries

Without explicit boundaries, scope expands infinitely. Questions establish what's in and out:

• 'Should the system support offline mode?'
• 'Do we need to support users in China (Great Firewall implications)?'
• 'Should the API be public or internal only?'

Each 'no' narrows scope; each 'yes' adds complexity. Both are valuable clarity.

4. Building Shared Understanding

Requirements documents can be misinterpreted. Conversation can't. When you ask 'So if I understand correctly, a user can only belong to one organization at a time?' and the stakeholder says 'Actually, power users can belong to multiple,' you've prevented a fundamental data model error.

5. Demonstrating Due Diligence

In interviews and professional settings, asking thoughtful questions signals competence. It shows you:

• Don't make reckless assumptions
• Think beyond the obvious
• Understand the complexity of real-world systems
• Approach problems systematically

Rather than asking random questions, use a systematic framework that ensures comprehensive coverage. Here's a battle-tested approach organized into six dimensions:

Different types of questions serve different purposes. Master this toolkit to extract the right information at the right time:

Question Sequencing:

Start broad, then narrow:

1. Open-ended — 'Tell me about the current workflow' (discover the landscape)
2. Probing — 'You mentioned X is a bottleneck—can you elaborate?' (explore key areas)
3. Clarifying — 'When you say slow, what time frames are we discussing?' (remove ambiguity)
4. Hypothetical/Edge — 'What if two people submit simultaneously?' (stress-test understanding)
5. Quantifying — 'How many users, how fast, how often?' (get measurable criteria)
6. Closed-ended — 'So to confirm, the maximum file size is 10MB?' (verify understanding)

This funnel starts with exploration and ends with confirmation, ensuring both breadth and precision.

While the WHO/WHAT/WHEN/WHERE/WHY/HOW framework is universal, specific domains have recurring question patterns. Here are question sets for common system design domains:

Asking questions is not just about words—it's about human interaction. Understanding the psychology behind effective questioning makes you dramatically more effective at extracting requirements.

Handling Difficult Stakeholders:

The Over-Specifier: Says exactly how to build it ('Use React with GraphQL') → Ask 'What outcomes are you hoping that achieves?' to separate requirements from solutions.

The Under-Specifier: Says almost nothing ('Just make it good') → Use concrete examples: 'Let me walk through a scenario. A user logs in and wants to...'.

The Contradicting Stakeholder: Requirements conflict ('It must be free and generate $10M revenue') → Surface contradictions gently: 'Help me understand how we achieve both objectives.'.

The Scope Creeper: Every question adds 10 new features → Explicitly ask about priorities: 'If we could only have three of these features for launch, which ones?'.

Just as there are effective questioning patterns, there are anti-patterns that undermine requirements gathering:

In interviews, your questioning skills are under direct evaluation. You typically have 3-5 minutes at the start for requirements clarification. Make them count.

Interview Questioning Strategy:

Sample Question Sequence for 'Design a URL Shortener':

Let's apply everything we've learned. Given the following vague requirement, generate clarifying questions:

Requirement: "Build a food delivery platform like UberEats."

Your task: What questions would you ask? Think through each category (Who, What, When, Where, Why, How) and each question type. Below is an example of thorough interrogation:

We've explored the critical skill of asking the right questions—a capability that directly impacts the quality of every system you'll ever design. Let's consolidate:

What's Next:

We now know how to extract requirements through effective questioning. But not all requirements are equal—some define the core system while others are nice-to-haves. The next page explores scoping the problem: how to prioritize, bound, and focus your design effort to deliver maximum value within constraints.