Overview
Functional requirements describe what the system must do: the features, actions, and rules visible to users. For a parking lot: 'a driver can park a vehicle in a spot that fits its size', 'the system issues a ticket', 'the driver pays on exit'. Non-functional requirements describe qualities: thread safety, extensibility, performance, and scale.
In an LLD interview the first 5 minutes decide the rest: turning a vague prompt ('design a parking lot') into a short, confirmed list of requirements and explicit out-of-scope items. That list drives the entities, methods, and edge cases you design, and gives you a checklist to walk through at the end.
Before cooking, the waiter confirms what you want: which dish, how spicy, any allergies. Cooking the wrong dish perfectly is still a failure.
When to use it
- The start of every LLD interview or design task.
- When the prompt is ambiguous or huge.
- Before choosing patterns or writing classes.
Where it shows up in interviews
Recognize it when: 'Design X' with no details.
- Design a parking lot
- Design an elevator system
- Design Splitwise
Recognize it when: limited time, many features.
- Design a library system
- Design a movie ticket system
Where it is used in real software
Agile teams write 'As a <role>, I want <goal> so that <benefit>' with acceptance criteria.
Behavior-driven development (Cucumber, Given/When/Then) turns requirements into executable tests.
PRDs list goals, non-goals, and user flows before engineering design.
Key terms
- Functional requirement
- A behavior the system must support.
- Non-functional requirement
- A quality attribute: concurrency, extensibility, latency.
- Actor
- Who interacts: driver, admin, attendant, system job.
- Out of scope
- Explicitly excluded features to keep focus.
- Acceptance criteria
- Conditions that prove a requirement is met.
How it works, step by step
- 1Restate the problem
Confirm the core purpose in one sentence.
- 2Identify actors
Who uses it and what each wants.
- 3List core actions as verbs
park, pay, exit, add floor.
- 4Ask about rules and limits
Spot sizes, pricing, multiple entrances, payment types.
- 5Agree on scope and non-functional needs
Concurrency? Extensibility for new vehicle types?
Parking lot requirements
Prompt: 'Design a parking lot'
| Type | Requirement | Design impact |
|---|---|---|
| Functional | Park small, medium, large vehicles in fitting spots | Vehicle and Spot types, fit rules |
| Functional | Issue ticket on entry, compute fee on exit | Ticket, PricingStrategy |
| Functional | Multiple floors and entrances | Floor, Gate, spot allocation |
| Non-functional | Concurrent entries must not double-assign a spot | Thread-safe allocation |
| Out of scope | Online reservations, license plate cameras | Mention as extensions |
NOWType: Functional | Requirement: Park small, medium, large vehicles in fitting spots | Design impact: Vehicle and Spot types, fit rules
Five confirmed lines give a precise target and a checklist for the final walkthrough.
Implementation
// Requirements captured as an interface: the public API the design must supportexport interface ParkingLotApi { /** FR1: park a vehicle, returning a ticket, or throw if full */ park(vehicle: { plate: string; size: "S" | "M" | "L" }, gateId: string): Ticket; /** FR2: exit with a ticket, returning the fee */ exit(ticketId: string, paidAt: Date): { feeCents: number }; /** FR3: availability per size for the display board */ available(): Record<"S" | "M" | "L", number>;} type Ticket = { id: string; plate: string; spotId: string; issuedAt: Date };Complexity and performance
Of a 45-minute round.
Enough to design well.
Trade-offs
More features mean shallower design; interviewers prefer a few features designed well with clear extensions.
Ask key questions, then state reasonable assumptions to keep moving.
Variants and related techniques
Requirements expanded into step-by-step flows.
Numbers such as floors, spots, and concurrent gates.
Common mistakes
- Jumping straight into classes.
Fix: Spend a few minutes clarifying; it prevents redesign later.
- Trying to cover every feature.
Fix: Agree on a core set and list the rest as extensions.
- Ignoring non-functional requirements.
Fix: Ask about concurrency and extensibility explicitly.
Interview questions
What questions would you ask for 'design an elevator system'?
Number of elevators and floors, request types (hall calls vs car buttons), scheduling goals (minimize wait vs energy), capacity limits, emergency and maintenance modes, and whether concurrency or a simulation clock is expected.
How do you handle a feature you do not have time for?
State it as out of scope and describe where it would plug into the design (for example a ReservationService using the same spot allocator).
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Write requirements for a vending machine | Easy | Actors and actions. |
| Scope 'design a hotel booking system' in 5 minutes | Medium | Prioritization. |