Requirements for the Parking Lot

Before drawing a single UML diagram or writing a single line of code, we need to know exactly what we're building.

Skipping requirements is the most common mistake in LLD interviews. Candidates jump straight to drawing classes — and inevitably either design too much (adding features nobody asked for) or too little (missing critical functionality that the interviewer expected). Both outcomes lose points.

Good requirements do three things:

1. Define scope — they draw a clear boundary around what's in and what's out
2. Drive design decisions — every class, attribute, and method in the final design should trace back to a specific requirement
3. Enable testing — requirements tell you what "correct" looks like, so you can verify your design works

In an interview, spend the first 3-5 minutes asking clarifying questions and writing down requirements. This shows the interviewer that you think systematically, not impulsively.

Functional requirements define what the system does. Each requirement below is specific, testable, and will directly influence our class design.

FR1: Multi-Floor Structure
The parking lot shall support multiple floors. Each floor is identified by a floor number and has a fixed number of parking spots. The system must be able to add or query floors.

FR2: Multiple Spot Types
Each floor shall contain parking spots of three types: Compact, Regular, and Large. The type determines which vehicles can park there.

FR3: Vehicle Type Support
The system shall support three vehicle types: Motorcycle, Car, and Truck. Each vehicle is uniquely identified by a license plate number.

FR4: Vehicle-Spot Compatibility
Spot assignment shall follow type compatibility rules:

• A Motorcycle can park in any spot (Compact, Regular, or Large)
• A Car can park in a Regular or Large spot
• A Truck can only park in a Large spot

This ensures efficient space utilization — a motorcycle doesn't waste a large spot unless no compact spots are available.

FR5: Ticket Generation on Entry
When a vehicle enters the parking lot, the system shall generate a parking ticket containing: a unique ticket ID, the vehicle's license plate, the assigned spot, and the entry timestamp.

FR6: Fee Calculation on Exit
When a vehicle exits, the system shall calculate the parking fee based on the duration (entry time to exit time) and the active pricing strategy.

FR7: Pluggable Pricing Strategy
The system shall support multiple pricing models (e.g., hourly pricing, flat-rate pricing). The pricing strategy must be swappable at runtime without modifying the ParkingLot class.

FR8: Spot Allocation
When a vehicle arrives, the system shall find the first available spot that matches the vehicle's type compatibility. If no compatible spot is available on any floor, the system shall reject the vehicle.

FR9: Spot Release on Exit
When a vehicle exits, the spot it occupied shall be marked as available for new vehicles.

FR10: Capacity Tracking
The system shall track the number of available spots per type per floor, and report overall availability.

Non-functional requirements define how well the system does it — quality attributes that don't describe features but constrain the design.

NFR1: Single Responsibility
Each class shall have a single, well-defined responsibility. The ParkingLot class manages floors, not pricing. The PricingStrategy calculates fees, not spot allocation. This aligns with the Single Responsibility Principle (Fundamentals S6).

NFR2: Extensibility (Open/Closed Principle)
Adding a new vehicle type (e.g., Electric Vehicle), a new spot type (e.g., EV Charging), or a new pricing model shall NOT require modifying existing classes — only adding new ones. This aligns with the Open/Closed Principle (Fundamentals S6).

NFR3: Type Safety
Vehicle types and spot types shall be represented as enums (not raw strings) to prevent invalid values and enable compile-time safety. This follows the enum best practice from Fundamentals S3.

NFR4: Testability
Each component shall be testable in isolation. The pricing strategy can be tested without a ParkingLot. Spot allocation can be tested without actual vehicles. This is achieved through dependency injection (Fundamentals S13).

In Scope:

• Multi-floor parking lot with typed spots
• Vehicle hierarchy (Motorcycle, Car, Truck)
• Ticket generation and fee calculation
• Pluggable pricing strategies
• Spot allocation and release
• Capacity tracking per floor

Out of Scope:

• Payment processing — we calculate fees but don't integrate with payment gateways. In a real system, payment would be a separate service; in LLD, we care about the fee calculation class design, not the payment infrastructure.
• Entry/exit gates — physical hardware like barriers, sensors, and cameras are infrastructure concerns, not object design concerns.
• Reservation system — pre-booking a spot is a valid extension but adds complexity beyond our "Easy" scope.
• Real-time display boards — showing available spots on LED displays is a frontend/hardware concern.
• Multi-lot management — our design handles a single parking lot. Managing multiple lots across a city is a system-level concern.
• Database persistence — our objects live in memory. Persistence is an infrastructure concern.

In an interview, explicitly stating what's out of scope is as important as what's in scope. It shows you can prioritize and manage complexity.

Every requirement should map to something in our design. Here's a preview of how our requirements will drive the class structure:

Requirement	Drives This Design Element
FR1: Multi-Floor	ParkingLot class with List<Floor> (Composition)
FR2: Spot Types	SpotType enum (COMPACT, REGULAR, LARGE)
FR3: Vehicle Types	Vehicle abstract class → Car, Truck, Motorcycle (Inheritance)
FR4: Compatibility	VehicleType ↔ SpotType compatibility logic
FR5: Ticket Generation	ParkingTicket class with entry timestamp
FR6: Fee Calculation	PricingStrategy.calculateFee() method
FR7: Pluggable Pricing	PricingStrategy interface + Strategy Pattern
FR8: Spot Allocation	Floor.findAvailableSpot(VehicleType) method
FR9: Spot Release	ParkingSpot.unpark() method
FR10: Capacity	Floor.getAvailableSpotCount() method

This traceability is not optional — it's how you verify that your design is complete and nothing is missing. In the Class Diagram tutorial, we'll reference these requirement numbers when justifying each class.

In a real interview, spend 3-5 minutes on requirements before touching the whiteboard. Ask questions like:

• "Should the system support multiple floors, or is it a single-level lot?" — This determines whether you need a Floor class.
• "What vehicle types should we support?" — This determines your Vehicle hierarchy.
• "Should pricing be fixed or configurable?" — This tells you whether you need Strategy Pattern.
• "Is concurrent access a concern — multiple vehicles entering simultaneously?" — This affects thread safety (not in scope for Easy, but shows you think about it).
• "Should we support reservations?" — This scopes the problem. If the interviewer says no, don't design it.

These questions demonstrate design maturity. Junior candidates start drawing boxes immediately. Senior candidates clarify requirements, make scope explicit, and then design. The interviewer is evaluating your process as much as your solution.