Module 03 · Design notation · Lesson 4 of 4
From requirements to objects
A repeatable method from vague problem to small object model: clarify use cases, mine nouns and verbs, classify entities, values and services, assign responsibilities, then test against flows and a change. Worked on a parking lot.
Why it matters
Every low-level design interview, and every new feature, starts with a fuzzy description: "design a parking lot", "build the loyalty points feature". Candidates who freeze or start drawing random boxes usually lack a method, not knowledge. A repeatable sequence of steps turns the blank page into a defensible model in ten to fifteen minutes and leaves a visible trail of reasoning for the interviewer to follow.
The idea
The method has six steps. Each is quick; together they convert requirements into classes with clear responsibilities and a model you have already tested against real flows.
Worked example: a parking lot
- 1
1. Clarify the use cases and non-goals
Agree on: multiple floors; spots of three sizes (motorbike, compact, large); vehicles of three sizes; a vehicle parks in the smallest spot that fits; entry issues a ticket; exit computes a fee by duration with an hourly rate per vehicle size; payment at exit. Out of scope for now: reservations, monthly passes, electric charging. Writing the non-goals down is as important as the goals. - 2
2. Mine nouns and verbs
Nouns: lot, floor, spot, vehicle, motorbike, car, truck, ticket, fee, rate, payment, entry gate, exit gate. Verbs: park, find a spot, issue a ticket, leave, calculate fee, pay, free a spot. - 3
3. Classify the nouns
Entities with identity and lifecycle: ParkingLot, Floor, Spot, Ticket. Value objects: VehicleSize, Money, Duration, licence plate. Vehicle is arguably a value (plate and size) for this problem. Services and policies, where behaviour varies or coordinates: a SpotAllocator (which spot?), a PricingPolicy (how much?), a payment port. Gates are just entry points to use cases, not rich objects, unless hardware matters. - 4
4. Assign responsibilities
Spot knows its size and whether it is free, and can be occupied and released. Floor finds a free spot of at least a given size. ParkingLot coordinates floors and issues tickets. Ticket records the vehicle, spot and entry time and can be closed. PricingPolicy computes the fee from size and duration. Each gets one sentence; anything that needs 'and' is a candidate to split. - 5
5. Walk the main flows
Park: lot asks the allocator for a spot that fits, the spot is occupied, a ticket is issued. Leave: the ticket is closed with the exit time, pricing computes the fee, payment is taken, the spot is released. Walking it exposes questions: what if no spot fits (reject at entry), what if payment fails (spot stays occupied, ticket stays open), what if two cars are allocated the same spot at once (spot.occupy must be atomic). - 6
6. Apply a change
The interviewer adds electric spots with charging billed per kWh. The model absorbs it: a SpotFeature or EV spot type, an allocator rule preferring EV spots for EVs, and a pricing policy composed of a parking component and a charging component. If the change requires editing every class, revisit steps 3 and 4.
The resulting core model
| Class | Kind | Responsibility |
|---|---|---|
| ParkingLot | Entity, coordinator | Owns floors; parks a vehicle and issues a ticket; handles exit |
| Floor | Entity | Owns spots; finds a free spot that fits a size |
| Spot | Entity | Knows size and occupancy; occupy and release atomically |
| Ticket | Entity | Records vehicle, spot, entry and exit; closes once |
| VehicleSize, Money, Duration | Value objects | Typed values with rules (sizes ordered, money in minor units) |
| SpotAllocator | Strategy interface | Chooses a spot; nearest-first by default, swappable |
| PricingPolicy | Strategy interface | Computes the fee from size and duration; swappable per lot |
| PaymentGateway | Port | Takes payment; implemented by an adapter |
Filtering candidate classes
Not every noun becomes a class. Drop nouns that are synonyms (gate and entrance), that are attributes (colour, entry time), that are out of scope (reservation), or that represent the system itself (the "parking system"). Keep nouns that own a rule, a lifecycle or an identity. Verbs become methods on the class that has the data they need; verbs that coordinate several objects become use-case methods on a thin service or coordinator.
Trade-offs
A method like this can feel slow at the start of an interview, and it produces a modest-looking model rather than an impressive diagram. That is the point: modest models with clear responsibilities, walked through real flows and stressed by a change, are what both interviews and production reward. Skipping clarification saves two minutes and often costs the whole round.
In an interview
Make the method visible: "Let me list the use cases and what is out of scope... The core entities are lot, floor, spot and ticket; size and money are value objects; allocation and pricing vary, so they are strategies... Let me walk park and leave through these... Now, if we add EV charging, here is what changes." The interviewer can follow, steer and score every step.
Check yourself
In a parking lot design, a candidate creates classes for EntryGate, EntranceDoor, ParkingSystem, Colour, EntryTime and Reservation, though reservations were declared out of scope. Which filtering rule removes most of these?