Clarifying Requirements - Learning Module

Loading content...

0/246

Scoping the Problem

The Art of Defining Boundaries

After asking essential questions, you've gathered a wealth of information about the problem. But raw information isn't a design specification—it's chaos waiting to overwhelm your solution. The next critical step is scoping: explicitly defining what your design will and will not include.

Scoping is where engineering judgment becomes visible. It's easy to try to design everything; it's harder—and more valuable—to design the right things. In a time-constrained interview, scoping separates candidates who deliver focused, complete solutions from those who deliver sprawling, incomplete ones.

What You Will Learn

By the end of this page, you will understand how to transform gathered requirements into a bounded design scope. You'll learn techniques for identifying what's 'in scope' versus 'out of scope,' how to communicate scoping decisions, and how to handle scope negotiations with interviewers. This skill prevents wasted effort and demonstrates professional engineering judgment.

Why Scoping Matters

Consider a deceptively simple prompt: "Design a parking lot system."

A parking lot system could include:

Vehicle entry and exit tracking
Multiple vehicle types with different space requirements
Payment processing with cash, card, mobile, and subscriptions
Real-time availability displays
Advance reservation system
Automated license plate recognition
Electric vehicle charging integration
Multi-location management
Analytics and reporting dashboards
Customer loyalty programs
Integration with navigation apps
Handicap accessibility management
Valet parking modules
Lost ticket handling
Security camera integration

Attempting to design all of this in a 45-minute interview is impossible. Yet many candidates try, resulting in a shallow sketch of many features rather than a deep design of essential ones.

Scoping solves this problem by explicitly defining boundaries.

Benefits of Explicit Scoping

•Focus: Concentrate design effort on what matters most, enabling depth over breadth.
•Clarity: Both you and the interviewer know exactly what you're solving, preventing miscommunication.
•Time Management: Avoid rabbit holes by acknowledging complexity without designing for it.
•Demonstrable Judgment: Show that you can prioritize—a critical skill for senior engineers.
•Quality Over Quantity: A well-designed core is more impressive than a sketched-out universe.

The Scope Creep Trap

Without explicit scoping, interviews often drift. The interviewer mentions an edge case, you start solving it, which leads to another consideration, which leads to another... Suddenly you've spent 15 minutes on payment dispute resolution when you haven't even defined your core classes. Scoping prevents this drift.

The Scoping Process

Effective scoping follows a systematic process. After gathering requirements through clarifying questions, apply this framework to define your design boundaries:

The Scoping Framework

•Identify the Core Problem — What is the essential functionality that defines this system? Strip away enhancements to find the nucleus.
•Enumerate Candidate Features — List all features mentioned or implied. This creates your decision space.
•Classify by Priority — Categorize each feature as Core (must-have), Important (should-have if time), or Deferrable (nice-to-have).
•Define Explicit Boundaries — State what's in scope and what's out of scope, with brief justifications.
•Confirm with Interviewer — Present your scoping decisions and get agreement before proceeding.

Feature Classification Matrix
Category	Criteria	Treatment	Example
Core	System cannot function without it	Full design depth; complete implementation	Vehicle entry/exit tracking
Important	Significantly enhances value; commonly expected	Design interface; partial implementation	Payment processing abstraction
Deferrable	Enhancement; not essential for MVP	Acknowledge; design extensibility point	Reservation system
Out of Scope	Tangential; requires separate design effort	Explicitly exclude; mention if time permits	Multi-location management

Identifying the Core Problem

Every LLD problem has a nucleus—the essential functionality around which everything else orbits. Identifying this core prevents you from getting lost in peripheral concerns.

The Core Identification Technique:

Ask yourself: "If I removed everything except one capability, what would remain for this to still be called a [parking lot / elevator / library]?"

Example: Parking Lot Core

•Essential: Park vehicles and retrieve them later
•Track which spots are occupied
•Match vehicles to appropriate spots (size)
•Record entry and exit
•Not Core: Payment, reservations, loyalty programs

Example: Elevator Core

•Essential: Transport people between floors
•Accept floor requests (call button, floor button)
•Move elevator to requested floors
•Open/close doors at appropriate times
•Not Core: VIP priority, energy optimization, music

The Newspaper Test

Imagine explaining your system in one sentence to a newspaper reporter. What would you say? 'A system that parks and retrieves vehicles.' 'A system that moves people between floors.' This one sentence is your core. Everything else is elaboration.

Common Core Problems in LLD Interviews:

Core Problems Across Common LLD Scenarios
System	Core Problem	Core Entities
Parking Lot	Managing vehicle-to-spot assignments over time	Vehicle, ParkingSpot, Ticket
Elevator	Efficiently moving between floors on requests	Elevator, Floor, Request
Library	Managing book loans and returns over time	Book, Member, Loan
Chess	Validating and executing moves on a board	Board, Piece, Move, Player
Hotel Booking	Matching guests to available rooms for date ranges	Room, Reservation, Guest
Ride-Sharing	Matching riders with nearby drivers for trips	Rider, Driver, Trip, Location

Feature Classification Strategies

Once you've identified the core, classify remaining features. This isn't arbitrary—use systematic criteria to justify your decisions.

Classification Criteria:

Feature Classification Criteria

•Dependency: Does the core depend on this feature? If the core works without it, it's not core.
•Complexity Budget: Given time constraints, can you design this deeply? If not, it's deferrable.
•Pattern Demonstration: Does this feature let you showcase important design patterns? Promotes to 'Important.'
•Interviewer Interest: Did the interviewer emphasize this? Weights toward 'Important.'
•Design Orthogonality: Is this a separate system masquerading as a feature? If so, it's 'Out of Scope.'

Example: Classifying Parking Lot Features

Parking Lot Feature Classification
Feature	Classification	Reasoning
Vehicle entry/exit	Core	Without this, it's not a parking system
Spot allocation by size	Core	Fundamental to correct parking logic
Ticket generation	Core	Required to link entry to exit
Payment processing	Important	Expected; good for Strategy pattern demonstration
Multiple vehicle types	Important	Demonstrates polymorphism; commonly asked
Real-time availability	Important	Commonly requested; affects Observer pattern
Advance reservations	Deferrable	Separate subsystem; mention extensibility
Mobile payment integration	Deferrable	Payment abstraction handles this; implementation detail
License plate recognition	Out of Scope	Hardware integration; separate system
Analytics dashboard	Out of Scope	Reporting system; entirely different design

Pattern Demonstration Value

Features that allow you to demonstrate design patterns deserve promotion in priority. Payment processing (Strategy), vehicle types (inheritance/polymorphism), availability tracking (Observer)—these features have pedagogical value beyond their functional value.

Communicating Scope Decisions

Having classified features internally, you must communicate scope to the interviewer. This is a critical moment—it demonstrates judgment and ensures alignment before you invest design effort.

The Scope Statement Structure:

Scope Statement Components

•Core Scope Declaration: 'For this design, I'll focus on...'
•Important Features Acknowledgment: 'I'll also include interfaces/abstractions for...'
•Explicit Exclusions: 'I'm intentionally excluding X because...'
•Extensibility Mention: 'The design will allow future addition of...'
•Confirmation Request: 'Does this scope align with what you're looking for?'

Example Scope Statement:

Scope Statement Example

Candidate Statement

"Based on our discussion, here's my proposed scope for this design:
 
CORE SCOPE:
- Vehicle entry and exit tracking
- Spot allocation based on vehicle size (motorcycle, car, bus)
- Ticket generation linking entry to payment
- Multi-level parking lot structure
 
INCLUDED BUT LESS DEEP:
- Payment processing abstraction (Strategy pattern, multiple payment types)
- Real-time availability tracking
- Multiple entrance/exit management
 
EXPLICITLY OUT OF SCOPE (for time):
- Advance reservation system (though I'll design for extensibility)  
- License plate recognition integration
- Mobile app integration
- Analytics and reporting
 
I'm proposing this scope because it lets me demonstrate:
- Strong object-oriented design with SOLID principles
- Multiple design patterns (Strategy, Factory, Observer)
- Thread-safety considerations if needed
- Clean separation of concerns
 
Does this align with what you'd like to see?"

The Power of 'Explicitly Out of Scope'

When you explicitly state what's out of scope, you demonstrate awareness of complexity without being consumed by it. You're saying: 'I see this, I understand its importance, and I'm making a deliberate choice to defer it.' This is senior engineering behavior.

Handling Scope Negotiations

Your proposed scope isn't always accepted verbatim. Interviewers may push back, request additions, or suggest different priorities. This is normal—and how you handle it matters.

Common Negotiation Scenarios:

Scope Negotiation Scenarios

•Interviewer wants to add a feature: 'Can you also include the reservation system?'
•Interviewer wants to remove a feature: 'Let's skip payment for now.'
•Interviewer wants different depth: 'I'd like to see more detail on the scheduling algorithm.'
•Interviewer has a specific pattern in mind: 'Make sure your design handles this scenario...'

Response Strategies:

Scope Negotiation Responses
Scenario	Response Strategy	Example Response
Add feature	Accept gracefully; acknowledge trade-off	'Absolutely, I'll include reservations. That may mean less depth on payment—is that okay?'
Remove feature	Accept; clarify what to do with freed time	'Got it, I'll skip payment. Should I go deeper on spot allocation algorithms instead?'
Different depth	Adjust plan; confirm new focus	'Understood—I'll focus more on the scheduling. Should I still show the full class structure first?'
Specific scenario	Integrate into scope; note it explicitly	'That's a great edge case—I'll make sure my design handles it. I'll call it out when I reach that part.'

Scope Changes Are Signals

When an interviewer modifies your scope, pay attention. They're telling you what they want to evaluate. If they ask for reservations, they likely want to see how you handle booking conflicts. If they emphasize scheduling, they want to assess algorithmic thinking. Adapt your design focus accordingly.

Designing for Extensibility at Scope Boundaries

When you exclude a feature from scope, don't pretend it doesn't exist. Instead, design extensibility points—places in your design where future features could plug in without restructuring.

This serves multiple purposes:

Shows you understand the larger problem
Demonstrates OCP (Open-Closed Principle) application
Proves you can balance immediate delivery with future flexibility
Gives interviewers confidence in your design's longevity

Extensibility Point Techniques

•Interfaces for Future Implementations: 'I'm not implementing LicensePlateScanner, but my EntryGate takes an IVehicleIdentifier interface.'
•Abstract Factory Preparation: 'Adding a new vehicle type only requires creating a new VehicleFactory implementation.'
•Event Hooks: 'When a vehicle exits, I fire an ExitEvent—a reservation system could subscribe to this.'
•Configuration Injection: 'Pricing strategies are injected; adding surge pricing is a matter of a new strategy class.'
•Placeholder Abstractions: 'My design has a ReservationService interface with a NullImplementation for now.'

Extensibility Point Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Current scope: Simple ticket-based entry
// Future scope: Reservation system (out of scope, but extensible)
 
// Extensibility Point: Abstract spot allocation
interface SpotAllocationStrategy {
    allocateSpot(vehicle: Vehicle, lot: ParkingLot): ParkingSpot | null;
    deallocateSpot(spot: ParkingSpot): void;
}
 
// Current Implementation: First-available strategy
class FirstAvailableStrategy implements SpotAllocationStrategy {
    allocateSpot(vehicle: Vehicle, lot: ParkingLot): ParkingSpot | null {
        // Find first available spot matching vehicle size
        return lot.getAvailableSpots()
            .find(spot => spot.canFit(vehicle)) ?? null;
    }
    
    deallocateSpot(spot: ParkingSpot): void {
        spot.markAvailable();
    }
}
 
// EXTENSIBILITY: Future ReservationAwareStrategy would:
// 1. Implement same interface
// 2. Check reservation status before allocation
// 3. Reserve specific spots for upcoming reservations
// No changes to ParkingLot or other classes needed!
 
// The ParkingLot uses the strategy via injection:
class ParkingLot {
    constructor(private allocationStrategy: SpotAllocationStrategy) {}
    
    parkVehicle(vehicle: Vehicle): Ticket | null {
        const spot = this.allocationStrategy.allocateSpot(vehicle, this);
        if (!spot) return null;
        return new Ticket(vehicle, spot, new Date());
    }
}

Extensibility Commentary

When presenting your design, briefly mention extensibility points: 'Notice that I've used a SpotAllocationStrategy here. While I'm implementing simple first-available logic, a reservation system would simply provide a different strategy implementation—no changes to ParkingLot needed.' This shows strategic thinking without consuming design time.

Scope Anti-Patterns to Avoid

Understanding what not to do is as valuable as knowing best practices. These common scoping anti-patterns undermine otherwise solid designs:

Scoping Anti-Patterns

•The Kitchen Sink: Trying to include everything mentioned. Results in shallow designs of many features, none thorough.
•Scope Avoidance: Not explicitly stating scope at all. Leads to ambiguity and potential misalignment with interviewer expectations.
•Fixed Mindset Scoping: Refusing to adjust scope when the interviewer suggests changes. Appears inflexible and uncooperative.
•Dismissive Exclusions: 'I'm not going to do reservations, it's not important.' Arrogant; doesn't acknowledge value.
•Fake Extensibility: Claiming design is extensible without demonstrating how. Empty assertions without proof.
•Scope Creep Capitulation: Agreeing to every addition without trade-off discussion. Shows inability to negotiate or prioritize.
•Underground Scope: Including undisclosed features that consume design time. Surprises interviewer; wastes effort.

Poor Scope Communication

•'I'll just design all of it.'
•'I'm not sure what to include.'
•'Reservations? Sure, I'll add that too, and analytics, and...'
•'I don't think payment matters.'
•'My design can do anything.'

Strong Scope Communication

•'Given time, I'll focus on core + payment.'
•'Here's my proposed scope: core X, Y, Z.'
•'Adding reservations means less depth on payment—trade-off okay?'
•'I'm deferring payment to focus on core, but here's the strategy interface.'
•'Here's how I'd extend for reservations via this interface.'

Scope Is Not Fixed Forever

Your initial scope is a proposal, not a contract. If you finish core design early, you can say: 'I have time remaining—should I dive deeper into payment, or would you like to see reservations?' This demonstrates adaptability while maintaining structure.

Scope Examples Across Problem Types

Let's see scoping applied to different LLD problem types, demonstrating how problem nature influences scope decisions:

Elevator System Scoping:

Core Scope (deep design):

Elevator state management (idle, moving up/down, doors open/closed)
Request handling (external hall calls, internal floor buttons)
Elevator scheduling (choosing which elevator handles which request)
Multi-elevator coordination

Important (interfaces + partial):

Scheduling algorithms (FCFS, SCAN, LOOK—show Strategy pattern, implement one)
Emergency handling (fire mode, power outage)

Deferrable (mention extensibility):

VIP priority floors
Energy optimization algorithms
Predictive positioning based on historical patterns

Out of Scope:

Physical motor control simulation
Door sensor integration
Voice announcement system

Justification: Elevator systems are fundamentally about state management and scheduling algorithms. The core value is demonstrating State pattern for elevator states and Strategy pattern for scheduling. Emergency handling shows robustness thinking.

Summary: Mastering Problem Scoping

Scoping transforms chaotic requirements into actionable design specifications. It's the bridge between understanding a problem and solving it effectively.

Key Takeaways

•Scoping enables depth over breadth — A focused design of core features beats a shallow sketch of everything.
•Identify the core problem — Strip away enhancements to find the essential functionality.
•Classify features systematically — Core, Important, Deferrable, Out of Scope—with clear criteria.
•Communicate scope explicitly — State what's in, what's out, and why—then confirm.
•Handle negotiations gracefully — Accept scope changes while discussing trade-offs.
•Design extensibility at boundaries — Excluded features should have clear extension points.
•Avoid anti-patterns — Kitchen sink, dismissive exclusions, fake extensibility all undermine credibility.

What's Next:

With essential questions asked and scope defined, you have a solid foundation. But foundations aren't complete without documentation. The next page covers documenting assumptions—how to capture the implicit decisions you're making, communicate them clearly, and protect your design from 'but you should have known' criticism.

Page Complete

You now understand how to scope LLD problems effectively. Scoping isn't about doing less—it's about doing the right things well. Every feature you exclude is a decision you can defend; every feature you include is a commitment you can fulfill. Next, we'll learn to document the assumptions that fill gaps in your requirements.