Requirements for the Car Rental System

Let's define what our Car Rental System needs to do. Each requirement is specific enough to drive a class or method in our design.

Vehicle & Fleet Management:

1. R1: Register vehicles in the fleet. The system shall support adding vehicles with attributes including license plate, make, model, year, mileage, transmission type, and vehicle category (Sedan, SUV, Truck, Luxury, Van). Each vehicle belongs to exactly one branch at any given time.
2. R2: Track vehicle status. Each vehicle shall have a status: Available, Reserved, Rented, or Under Maintenance. Only vehicles with status Available can be reserved. The system shall enforce these transitions.
3. R3: Support multiple vehicle categories. The system shall support at least five vehicle categories — Sedan, SUV, Truck, Luxury, and Van — each with a different base daily rate and distinct attributes (e.g., cargo capacity for Trucks, passenger count for Vans).

Branch & Location Management:

4. R4: Support multiple rental branches. The system shall manage multiple branch locations. Each branch has a name, address, and its own vehicle inventory. A vehicle is physically present at one branch at a time.
5. R5: Allow one-way rentals. A customer shall be able to pick up a vehicle at one branch and return it to a different branch. When a vehicle is returned to a different branch, it is automatically reassigned to that branch's inventory.

Customer Management:

6. R6: Register customers. The system shall support customer registration with name, email, phone number, driver's license number, and an address.
7. R7: Maintain rental history. The system shall track all past and active reservations for each customer.

Reservation & Rental Workflow:

8. R8: Create a reservation. A customer shall be able to reserve a vehicle by specifying: vehicle category (or specific vehicle), pickup branch, drop-off branch, pickup date/time, and expected return date/time. The reservation locks the vehicle so no other customer can reserve it.
9. R9: Pick up a reserved vehicle. When a customer arrives to pick up a reserved vehicle, the system shall transition the reservation from Reserved to Active and mark the vehicle as Rented.
10. R10: Return a vehicle. When a customer returns a vehicle, the system shall calculate the final charges (including late fees if applicable), transition the reservation to Completed, and mark the vehicle as Available at the drop-off branch.
11. R11: Cancel a reservation. A customer shall be able to cancel a reservation before the pickup time. The vehicle is released back to Available status.

Pricing:

12. R12: Calculate rental cost based on duration and vehicle type. The base cost is determined by the vehicle category's daily rate multiplied by the number of rental days. Partial days count as full days.
13. R13: Support dynamic pricing strategies. The system shall support multiple pricing strategies — standard daily rate, weekly discount rate (for rentals of 7+ days), and seasonal/surge pricing — selectable at the branch or reservation level without modifying existing pricing code.
14. R14: Charge late return fees. If a vehicle is returned after the expected return date, the system shall apply a per-day late fee on top of the base rental cost.

Insurance & Add-Ons:

15. R15: Offer insurance packages. The system shall support optional insurance add-ons: Collision Damage Waiver (CDW), Liability Insurance, and Personal Accident Insurance. Each has a per-day cost that adds to the rental total.
16. R16: Offer equipment add-ons. The system shall support optional equipment: GPS Navigation, Child Seat, and Roadside Assistance. Each has a per-day or flat fee.
17. R17: Stack multiple add-ons. A customer can select any combination of insurance and equipment add-ons for a single reservation. The total cost is the base rental cost plus all selected add-on costs.

Beyond functionality, our design must support:

1. Extensibility (Open/Closed Principle): Adding a new vehicle category (e.g., Electric), a new pricing strategy (e.g., holiday pricing), or a new insurance product should require adding a new class — not modifying existing vehicle, pricing, or insurance code. This is why we'll use the Factory Pattern for vehicle creation, the Strategy Pattern for pricing, and the Decorator Pattern for add-ons.
2. Testability: Each component — pricing calculation, reservation lifecycle, vehicle availability search, add-on cost layering — should be testable in isolation. No god-class that handles everything.
3. Data Consistency: A vehicle cannot be double-booked. If a customer reserves a vehicle, no other customer can reserve that same vehicle for overlapping dates. Vehicle status transitions must be enforced (e.g., you cannot rent a vehicle that is Under Maintenance).
4. Separation of Concerns: Reservation logic should not know about pricing algorithms. Pricing should not know about insurance details. Add-on decoration should not modify the core Reservation class. Each subsystem has a clear responsibility boundary.

In Scope:

• Vehicle fleet management with multiple categories and per-branch inventory
• Multi-branch support with one-way rental (different pickup and drop-off locations)
• Customer registration and rental history tracking
• Full reservation lifecycle: Reserve → Pick Up → Return (or Cancel)
• Dynamic pricing with multiple swappable strategies
• Insurance and equipment add-ons with stackable cost calculation
• Late return fee calculation
• Vehicle status management (Available, Reserved, Rented, Under Maintenance)

Out of Scope:

• Database persistence — we model in-memory objects (persistence is a system-design concern)
• REST API endpoints — we design the domain layer, not the transport layer
• Payment gateway integration — we calculate charges but don't process credit cards
• GPS tracking or real-time vehicle location — we track which branch a vehicle belongs to, not its GPS coordinates
• Loyalty programs or promotional discounts — extensible via Strategy Pattern but not modeled in this iteration
• Vehicle maintenance scheduling — we support the Under Maintenance status but don't model repair workflows
• Authentication/authorization — we model user roles but not login/session management
• Fuel management — we don't model fuel levels or refueling charges

Every requirement will map directly to our design. Here's a preview of how requirements drive classes:

Requirement	Drives Which Class/Pattern
R1 (Register vehicles)	Vehicle hierarchy, VehicleCategory enum
R2 (Vehicle status)	VehicleStatus enum, status transition logic in Vehicle
R3 (Vehicle categories)	Sedan, SUV, Truck, Luxury, Van subclasses, VehicleFactory
R4 (Multiple branches)	Branch class with vehicle inventory
R5 (One-way rentals)	Reservation.dropOffBranch, vehicle reassignment on return
R6-R7 (Customer management)	Customer class with rental history
R8 (Create reservation)	Reservation class, RentalService.createReservation()
R9 (Pick up)	RentalService.pickUpVehicle(), status transition
R10 (Return vehicle)	RentalService.returnVehicle(), cost calculation, branch reassignment
R11 (Cancel reservation)	RentalService.cancelReservation(), status transition
R12-R14 (Pricing)	PricingStrategy interface, DailyPricing, WeeklyDiscountPricing, SeasonalPricing
R15-R17 (Insurance & add-ons)	RentalAddOn decorator hierarchy, InsuranceAddOn, EquipmentAddOn

We'll trace these mappings precisely in the Class Diagram tutorial.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Ask questions like:

• "Should the system support one-way rentals (pick up at location A, return at location B)?" — This significantly affects the data model. Without it, each vehicle is permanently assigned to one branch. With it, you need dynamic branch reassignment on return.
• "How should pricing work — flat daily rate, or do we need weekly/seasonal pricing?" — This determines whether you need a Strategy Pattern for pricing or a simple calculation.
• "What insurance and add-on options are required?" — If add-ons are stackable and optional, the Decorator Pattern is the right fit. If they're fixed bundles, simpler modeling works.
• "Can a customer reserve a specific vehicle, or only a vehicle category?" — Reserving by category means the system picks a specific vehicle at pickup time. Reserving a specific vehicle locks it immediately. Both approaches are valid — the choice affects reservation logic.
• "What happens if a vehicle isn't returned on time?" — This scopes whether you need late fee calculation and overdue notification logic.

These questions show the interviewer that you think about design trade-offs and edge cases before coding — exactly what senior engineers do.