Requirements Gathering

In 2007, Steve Jobs unveiled the iPhone—a device that would revolutionize mobile computing. But here's what most people don't realize: the first iPhone had no App Store, no copy-paste, no video recording, no MMS, and no multitasking. It couldn't even send picture messages.

These weren't oversights. They were deliberate scoping decisions. Apple chose to launch with a focused set of capabilities done exceptionally well rather than a sprawling feature set done poorly. Each iPhone iteration expanded scope strategically, always prioritizing quality over quantity.

This discipline—strategic scoping—separates successful systems from failed ones. Unlimited scope leads to unlimited timelines, overwhelmed teams, and systems that do everything poorly and nothing well. Proper scoping focuses effort where it matters most.

In system design, what you choose NOT to build is as important as what you build.

Scoping is the discipline of defining what a system will and will not do—establishing clear boundaries around features, users, scale, and quality attributes. It transforms an infinite problem space into a tractable design challenge.

Why Scoping Is Critical:

1. Time and Resources Are Finite

Every project has constraints: deadlines, budgets, team sizes, technical limitations. Scoping ensures you invest limited resources in the highest-value features rather than spreading thin across everything.

2. Focus Enables Quality

A team that tries to build everything builds nothing well. Apple's iPhone team wasn't incapable of building copy-paste—they chose to perfect core phone, music, and internet experiences first. The result was a revolutionary product rather than a mediocre one.

3. Reduces Complexity

Every feature adds complexity—not just in implementation, but in testing, maintenance, documentation, support, and interaction with other features. Aggressive scoping keeps complexity manageable.

4. Enables Faster Feedback

Smaller scope means faster delivery, which means faster user feedback, which means you can iterate based on real data rather than assumptions. The lean startup principle of 'build, measure, learn' requires tight scope.

5. Clarifies Success Criteria

A well-scoped project has clear success criteria. Did we build the three must-have features? Do they meet the performance requirements? An unbounded project has fuzzy success—'we built a lot of stuff, we think it's good.'

The Scoping Mindset:

Effective scoping requires a mindset shift:

❌ Not: 'How can we do everything?' ✅ But: 'What's the essential core that delivers maximum value?'

❌ Not: 'We should include this just in case' ✅ But: 'Is this essential for MVP? If not, defer it.'

❌ Not: 'Users might want this someday' ✅ But: 'Do enough users need this now to justify the cost?'

Scoping is not about saying 'no' for its own sake—it's about saying 'yes' to the right things by saying 'not now' to lesser priorities.

Scope isn't just about features. There are multiple dimensions along which you can bound a system design. Understanding each dimension helps you scope systematically:

Multi-Dimensional Scoping:

Real scoping decisions often span multiple dimensions. Consider this example:

'Design a ride-sharing application'

• Feature Scope: Rider booking & driver matching (core). Defer: carpooling, scheduled rides, package delivery.
• User Scope: Focus on urban riders & independent drivers. Defer: corporate accounts, fleet management.
• Geographic Scope: Single city launch. Defer: multi-city, international.
• Scale Scope: Support 100K concurrent users. Defer: million-scale optimization.
• Platform Scope: Mobile apps (iOS + Android). Defer: web portal, driver tablets.

Each dimension is an independent lever. You might have broad feature scope but narrow geographic scope, or vice versa.

When you have more requirements than you can deliver, you need systematic frameworks to decide what's in scope. Here are the most effective prioritization methods:

Beyond feature prioritization, scoping requires drawing clear boundaries around your system—defining what's inside your design versus what's external.

The Context Diagram Approach:

A context diagram visualizes your system as a black box with external entities that interact with it. Everything inside the box is your scope; everything outside is external.

            ┌─────────────────┐
            │  External       │
            │  Systems        │
            └────────┬────────┘
                     │ API calls
                     ▼
┌──────────┐    ┌─────────────────────────────┐    ┌───────────┐
│  Web     │───▶│                             │◀───│  Mobile   │
│  Client  │    │     YOUR SYSTEM             │    │  App      │
└──────────┘    │     (In Scope)              │    └───────────┘
                │                             │
                │  • User Management          │
                │  • Core Business Logic      │
                │  • Data Storage             │
                │  • API Layer                │
                │                             │
                └──────────────┬──────────────┘
                               │
                               ▼
                        ┌──────────────┐
                        │  Database    │
                        │  (In/Out?)   │
                        └──────────────┘

Boundary Questions:

Explicit Boundary Documentation:

In interviews, scoping is not just expected—it's evaluated. Interviewers deliberately give broad prompts ('Design Twitter') to test whether candidates impose sensible boundaries.

The Interview Scoping Protocol:

Example Scoping Statement:

Why Interviewers Value Scoping:

Scope creep is the gradual expansion of scope during a project—and it's the silent killer of engineering efforts. Managing it requires vigilance, process, and communication.

How Scope Creep Happens:

Scope Creep Prevention Strategies:

The Scope Change Conversation:

When a stakeholder requests a scope addition, use this script:

1. Acknowledge: 'That's a good idea. I can see why that would be valuable.'
2. Impact: 'Adding this will take approximately X effort and delay delivery by Y.'
3. Trade-off: 'We could include it if we remove Z from scope, or if we extend the timeline.'
4. Decision: 'Which would you prefer: trade something out, extend timeline, or defer to the next phase?'

This makes the cost visible and puts the decision in the stakeholder's hands.

Scope decisions are only effective if they're clearly communicated and understood by all stakeholders. Ambiguous communication leads to misaligned expectations—the root of most project conflicts.

The Scope Communication Package:

Communication Best Practices:

Let's apply scoping skills to a real scenario:

Scenario: You're the tech lead for a startup building a 'Venmo for freelancers'—a payment platform where businesses can pay freelancers. You have 4 engineers and 4 months to MVP.

Raw Requirements (from stakeholders):

1. Businesses can onboard and add payment methods
2. Freelancers can onboard and add bank accounts
3. Businesses can invite freelancers to their 'team'
4. Businesses can send payments to freelancers
5. Freelancers receive instant notifications
6. Multi-currency support (USD, EUR, GBP)
7. Scheduled/recurring payments
8. Invoice generation
9. Tax document generation (1099s)
10. Mobile apps (iOS + Android)
11. Integration with QuickBooks
12. Dispute resolution system
13. Real-time payment tracking
14. Analytics dashboard for businesses
15. Referral program

Exercise: Apply prioritization and produce a scope summary.

We've explored the critical skill of scoping—the discipline of defining boundaries, prioritizing requirements, and focusing effort for maximum impact. Let's consolidate:

Module Complete:

You've now completed the Requirements Gathering module. You understand:

• Functional requirements — What the system does
• Non-functional requirements — How well it does it
• Questioning techniques — How to extract complete requirements
• Scoping discipline — How to prioritize and bound the problem

These four skills form the foundation of every system design. No architecture decision, no technology choice, no scaling strategy makes sense without first understanding what you're building, for whom, at what quality, within what constraints.

The next module will build on this foundation, exploring Back-of-the-Envelope Estimation—how to quantify the scale and workload your system must handle.