Requirements for the Hotel System

A hotel management system touches many domains — reservations, housekeeping, billing, room service, loyalty programs, channel management. Without clear requirements, you'll either design too little (missing key workflows like check-out billing) or too much (implementing a full channel manager when the interviewer wanted room management).

In an interview, spending 3-5 minutes on requirements shows discipline. It also sets the boundary — you and the interviewer agree on what's in scope before you draw a single class.

Let's define what our hotel management system must do:

1. FR1: Room Inventory Management — The system shall maintain an inventory of rooms, each with a unique room number, room type (Single, Double, Deluxe, Suite), and a base price per night.

2. FR2: Room Status Tracking — Each room shall have a status that transitions through a defined lifecycle: Available → Reserved → Occupied → Under Maintenance → Available. Invalid transitions (e.g., Available → Occupied without a reservation) shall be rejected.

3. FR3: Guest Registration — The system shall allow registering guests with their personal information (name, email, phone, identification).

4. FR4: Room Search — The system shall allow searching for available rooms by room type and date range. A room is available for a date range only if it has no overlapping reservations.

5. FR5: Reservation Management — The system shall allow creating, confirming, and cancelling reservations. A reservation links a guest to a specific room for a check-in date and check-out date.

6. FR6: Check-In Processing — The system shall process guest check-in by verifying the reservation, transitioning the room status to Occupied, and issuing a room key card.

7. FR7: Check-Out Processing — The system shall process guest check-out by generating a bill, transitioning the room status to Under Maintenance (for housekeeping), deactivating the room key, and finalizing the reservation.

8. FR8: Bill Generation — Upon check-out, the system shall generate a bill based on the number of nights stayed, the pricing strategy in effect, and any additional charges (room service, minibar, etc.).

9. FR9: Pluggable Pricing — The system shall support multiple pricing strategies (standard rate, seasonal pricing, weekend pricing) that can be configured without modifying existing code.

10. FR10: Room Key Management — The system shall issue electronic key cards at check-in and deactivate them at check-out. A key grants access to a specific room for a specific guest.

11. FR11: Housekeeping Transition — After a guest checks out, the room transitions to Under Maintenance. Once housekeeping marks the room as clean, it transitions back to Available.

Beyond functionality, the system should exhibit these qualities:

1. NFR1: Extensibility — Adding a new room type (e.g., Presidential Suite) or a new pricing strategy (e.g., LengthOfStayPricing) should require creating a new class, not modifying existing ones. This follows the Open/Closed Principle (Fundamentals S6).

2. NFR2: State Integrity — Room status transitions must be validated. The system must reject invalid transitions (e.g., checking into a room that's under maintenance) to prevent data corruption.

3. NFR3: Testability — Each component (room state machine, pricing calculation, reservation logic) should be testable in isolation without setting up the entire hotel.

4. NFR4: Separation of Concerns — Pricing logic, room state management, reservation management, and billing should live in separate classes. No god class that handles everything.

In Scope:

• Room inventory with multiple types (Single, Double, Deluxe, Suite)
• Full reservation lifecycle (create → confirm → check-in → check-out → cancel)
• Room state machine (Available, Reserved, Occupied, Under Maintenance)
• Billing with pluggable pricing strategies
• Room key issuance and deactivation
• Guest registration

Out of Scope:

• Online booking portals / OTAs — we model the hotel's internal PMS, not Booking.com integration
• Payment processing — we calculate the bill amount but don't process credit cards
• Room service ordering — we allow adding charges to a bill, but don't model food/service items
• Multi-property management — we design for a single hotel
• Loyalty/rewards programs — a valid extension, but not in our core scope
• Floor plans / room adjacency — we track room type and number, not physical layout
• Concurrent booking — we'll note it as an edge case, but don't implement synchronization

Every requirement should map to at least one class or method in our final design. Here's a preview of how these requirements will drive our class diagram:

Requirement	Drives Which Class/Component
FR1 (Room Inventory)	Room class with roomType, roomNumber, pricePerNight
FR2 (Room Status)	RoomStatus enum + State Pattern in Room
FR3 (Guest Registration)	Guest class
FR4 (Room Search)	Hotel.searchAvailableRooms() method
FR5 (Reservations)	Reservation class with ReservationStatus enum
FR6 (Check-In)	Hotel.checkIn() + RoomKey creation
FR7 (Check-Out)	Hotel.checkOut() + Bill generation
FR8 (Billing)	Bill class with calculateTotal()
FR9 (Pricing)	PricingStrategy interface + implementations
FR10 (Key Management)	RoomKey class
FR11 (Housekeeping)	Room state transition: OCCUPIED → UNDER_MAINTENANCE → AVAILABLE

Notice that every requirement has a home. If a requirement can't be traced to a class, either the requirement is out of scope or the design is incomplete.

In a real interview, clarify these questions before designing:

• "Should I model the full reservation lifecycle, or just room assignment?"
• "Is multi-room booking in scope — can a guest reserve multiple rooms in one reservation?"
• "Do we need to handle walk-in guests (no reservation), or only pre-booked?"
• "Should pricing vary by season, or is a flat rate per room type sufficient?"
• "Is housekeeping an explicit workflow, or does the room just become available after checkout?"

For our design, we've answered all of these in the requirements above. In an interview, the interviewer's answers would shape a slightly different design — and that's expected. The skill is knowing which questions to ask, not memorizing one specific answer.