Requirements Analysis - Hotel Booking System | OneNoughtOne

0/246

System Design (LLD)Case Studies

Hotel Booking System

LevelAdvanced

Duration120 mins

TopicCase Studies

1 / 6

Requirements Analysis

The Hotel Booking System Challenge

Among Low-Level Design problems, the Hotel Booking System stands as one of the most instructive and challenging case studies. It combines the complexity of temporal data management with intricate business rules, multi-stakeholder workflows, and real-world constraints that push the boundaries of object-oriented design.

Unlike simpler systems where state is relatively static, a hotel booking system deals with time-sensitive inventory—rooms that exist in a perpetual state of availability, pending, reserved, occupied, and back again. This temporal dimension introduces complexities that many engineers underestimate until they're deep in implementation.

What You Will Learn

By the end of this page, you will understand how to systematically analyze requirements for a hotel booking system—identifying functional needs, non-functional constraints, stakeholder perspectives, and the subtle complexities that separate amateur designs from production-ready architectures. This foundational analysis will inform every design decision in subsequent pages.

Problem Domain Understanding

Before diving into requirements, we must deeply understand the problem domain. A hotel booking system operates at the intersection of hospitality management, inventory control, and e-commerce—each bringing distinct challenges.

The Fundamental Challenge:

A hotel sells perishable inventory. Unlike physical goods that can be stored indefinitely, a hotel room on January 15th that goes unsold is revenue lost forever—it cannot be "stored" for later sale. This creates intense pressure on:

Maximizing occupancy — Every empty room represents unrealized revenue
Optimizing pricing — Dynamic pricing based on demand, seasonality, and events
Managing overbooking — Strategic overbooking to compensate for cancellations without displacing guests
Handling modifications — Guests change dates, room types, and party sizes constantly

The Perishability Insight

Understanding that hotel inventory is perishable fundamentally shapes design decisions. Unlike an e-commerce system where a product either exists or doesn't, every room exists in a temporal context—available on specific dates, for specific durations. This makes room quantity tracking a multi-dimensional problem rather than simple counting.

Key Domain Concepts:

Before we can design, we must internalize the language of the domain:

Room Inventory: Rooms categorized by type (single, double, suite, etc.) with varying capacities, amenities, and prices
Availability: Whether a specific room type can accommodate a reservation for given dates
Reservation: A commitment to hold room(s) for a guest for specified dates
Booking: A confirmed reservation, typically after payment or guarantee
Rate Plan: Pricing structure that varies by room type, dates, guest type, and business rules
Occupancy: The ratio of occupied rooms to total available rooms
RevPAR: Revenue Per Available Room—a key metric combining occupancy and pricing
Overbooking: Accepting more reservations than physical capacity, hedging against no-shows and cancellations

Hotel Domain vs. Traditional Inventory Systems
Aspect	Traditional Inventory	Hotel Inventory
Nature	Physical items, persistent	Time-bounded, perishable
Quantity	Single count (in stock or not)	Multi-dimensional (per date, per room type)
Pricing	Relatively static	Highly dynamic (demand, season, events)
Allocation	FIFO/LIFO/specific unit	Date-based, flexible assignment
Overbooking	Generally not applicable	Strategic business practice
Modifications	Order changes	Date changes, room type changes, extensions

Stakeholder Analysis

A robust requirements analysis identifies all stakeholders and their distinct needs. Each stakeholder interacts with the system differently, and failing to account for any perspective leads to incomplete designs.

Primary Stakeholders:

Guest (End User)

•Search and browse — Find available rooms for desired dates and preferences
•Book rooms — Complete reservation with payment or guarantee
•Modify reservations — Change dates, room types, or party size
•Cancel reservations — Request cancellation with refund processing
•View booking history — Access past and upcoming reservations
•Loyalty integration — Earn/redeem points, access member benefits

Hotel Staff (Operations)

•Front desk operations — Check-in, check-out, room assignments
•Reservation management — Create, modify, cancel on behalf of guests
•Walk-in handling — Accommodate guests without prior reservation
•Overbooking resolution — Relocate guests when necessary
•Special requests — Handle late check-out, early check-in, accessibility needs
•Reporting — View occupancy, upcoming arrivals, revenue metrics

Revenue Manager (Strategic)

•Rate management — Set and adjust room rates dynamically
•Inventory control — Manage room allocations across channels
•Demand forecasting — Analyze booking patterns and predict occupancy
•Competitive positioning — Adjust pricing relative to market
•Promotion management — Create and manage special offers
•Performance analysis — Track RevPAR, ADR, occupancy trends

Hotel Administrator (Configuration)

•Room configuration — Define room types, capacities, amenities
•Policy management — Set cancellation policies, check-in/out times
•Staff management — Manage user accounts and permissions
•Channel integration — Configure OTA connections
•Property settings — Manage hotel information, images, descriptions

Stakeholder Conflicts

Stakeholders often have conflicting interests. Guests want flexibility (free cancellations); Revenue Managers want commitment (non-refundable rates). Front desk wants simple operations; Administrators want policy enforcement. Your design must accommodate these tensions through configuration and business rules, not hard-coded assumptions.

Functional Requirements Deep Dive

Functional requirements define what the system must do. For a hotel booking system, these span multiple complex workflows. Let's analyze each requirement category exhaustively.

3.1 Search and Availability

The search functionality is deceptively complex. A seemingly simple query—"Find available rooms for 2 guests, March 15-18"—triggers multi-dimensional logic:

Core Search Requirements:

Date-based availability — Check room availability across the entire requested stay
Capacity matching — Filter rooms that accommodate the party size
Room type filtering — Apply preferences (suite, ocean view, smoking, etc.)
Rate calculation — Compute total price including dynamic rates per night
Inventory allocation — Consider already-reserved, blocked, and out-of-order rooms
Overbooking thresholds — Apply configurable overbooking limits per room type

SearchQuery Conceptual Model
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// Conceptual search query structure
interface SearchQuery {
    // Temporal parameters
    checkInDate: Date;
    checkOutDate: Date;
    
    // Guest parameters
    adults: number;
    children: number;
    childAges?: number[];
    
    // Room preferences
    roomTypePreference?: RoomType[];
    amenityRequirements?: Amenity[];
    accessibilityNeeds?: AccessibilityFeature[];
    
    // Pricing context
    ratePlanCode?: string;
    promotionCode?: string;
    loyaltyTier?: LoyaltyTier;
    
    // Sorting/filtering
    sortBy?: 'price' | 'roomType' | 'rating';
    priceRange?: { min: number; max: number };
}
 
interface SearchResult {
    roomType: RoomType;
    availableCount: number;
    rates: NightlyRate[];
    totalPrice: Money;
    cancellationPolicy: CancellationPolicy;
    promotionsApplied: Promotion[];
}

The Continuous Availability Problem

A room must be available for ALL nights of a stay, not just some. If a guest wants March 15-18, the room must be available on the 15th, 16th, AND 17th nights. A common mistake is checking each night independently without ensuring continuous availability—leading to impossible reservations.

3.2 Reservation Lifecycle

Reservations transition through well-defined states. Understanding this lifecycle is critical for correct implementation:

Reservation States:

Pending — Reservation initiated but not confirmed (payment pending)
Confirmed — Payment received or guarantee accepted; room held
Checked-In — Guest has arrived and taken possession of room
Checked-Out — Guest has departed; room released for cleaning
Cancelled — Reservation cancelled before check-in
No-Show — Guest did not arrive on check-in date
Modified — Reservation details changed (creates history record)

Converting Mermaid diagram...

3.3 Complex Modification Scenarios

Modifications to existing reservations trigger cascading logic:

Date Modifications:

Extension — Adding nights to the end (if available)
Early departure — Shortening stay (refund calculation)
Date shift — Moving entire stay to new dates (availability + repricing)
Split stay — Breaking one reservation into multiple (often disallowed)

Room Modifications:

Upgrade — Moving to better room type (pricing implications)
Downgrade — Moving to lesser room type (refund logic)
Additional rooms — Adding rooms to existing reservation
Room removal — Reducing room count (partial cancellation logic)

Guest Modifications:

Add/remove guests — Affects capacity validation, extra person charges
Primary guest change — Transfer reservation to different person
Contact updates — Email, phone changes

Modification Complexity Matrix
Modification Type	Availability Check	Repricing Required	Policy Applied	History Record
Extend Stay	Yes (new nights)	Yes (new nights at current rates)	No	Yes
Shorten Stay	No	Yes (refund calculation)	Cancellation policy may apply	Yes
Date Shift	Yes (entire new range)	Yes (complete repricing)	Depends on policy	Yes
Room Upgrade	Yes (new room type)	Yes (rate difference)	No	Yes
Room Downgrade	Yes (new room type)	Yes (refund possible)	Depends on policy	Yes
Add Guests	No (capacity check only)	Maybe (extra person charges)	No	Yes

Cancellation Policy Requirements

Cancellation policies are among the most business-critical and complex aspects of hotel booking systems. They directly impact revenue, guest satisfaction, and operational planning.

Policy Dimensions:

Cancellation policies vary across multiple dimensions, and your system must handle all combinations:

Time-based tiers — Different penalties based on when cancellation occurs (e.g., free if 72+ hours before, 50% if 24-72 hours, 100% if <24 hours)
Rate plan linkage — Non-refundable rates vs. flexible rates
Booking source — Different policies for direct bookings vs. OTAs
Guest loyalty — Elite members may get more favorable terms
Season-based — Stricter policies during peak periods
Special circumstances — Group bookings, events, long stays

CancellationPolicy Model
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// Cancellation policy structure
interface CancellationPolicy {
    id: string;
    name: string;  // e.g., "24-Hour Flexible", "Non-Refundable"
    tiers: CancellationTier[];
    applicableRatePlans: string[];
    seasonalOverrides?: SeasonalPolicyOverride[];
}
 
interface CancellationTier {
    // Hours before check-in when this tier applies
    hoursBeforeCheckin: number;  
    // Penalty as percentage of total (0-100)
    penaltyPercentage: number;
    // Or fixed amount penalty
    fixedPenalty?: Money;
    // Nights charged as penalty
    nightsCharged?: number;
}
 
// Example: Standard Flexible Policy
const flexiblePolicy: CancellationPolicy = {
    id: "FLEX-001",
    name: "24-Hour Flexible",
    tiers: [
        { hoursBeforeCheckin: 24, penaltyPercentage: 0 },   // Free cancellation
        { hoursBeforeCheckin: 0, penaltyPercentage: 100 }   // Full charge
    ],
    applicableRatePlans: ["RACK", "BAR", "AAA", "CORP"]
};
 
// Example: Non-Refundable Policy
const nonRefundablePolicy: CancellationPolicy = {
    id: "NR-001",
    name: "Non-Refundable",
    tiers: [
        { hoursBeforeCheckin: Infinity, penaltyPercentage: 100 }  // Always 100%
    ],
    applicableRatePlans: ["ADVANCE", "PACKAGE", "PROMO"]
};

Refund Calculation Subtleties

Refund calculations must account for: partial payments already received, different rates on different nights (weekend vs. weekday), taxes calculated on the cancelled portion, loyalty points earned that must be reversed, and promotional discounts that may need recalculation. Never assume refund = total - penalty; the reality is more nuanced.

Non-Functional Requirements

Non-functional requirements define how the system must perform. For a hotel booking system, these are equally important as functional requirements and heavily influence architectural decisions.

Performance Requirements

•Search response time — Availability search must return results in <500ms for 90th percentile
•Booking confirmation — Reservation completion must finalize in <2 seconds including payment
•Concurrent users — Support 10,000+ simultaneous users searching and booking
•Inventory updates — Real-time inventory updates across all channels within 5 seconds
•Report generation — Dashboard metrics computed within 10 seconds for daily data

Reliability Requirements

•Uptime — 99.9% availability (8.76 hours max downtime/year)
•Data consistency — No double-booking of physical rooms ever
•Transaction integrity — All booking operations must be atomic (complete fully or not at all)
•Disaster recovery — RPO <1 hour, RTO <4 hours for complete recovery
•Graceful degradation — Core booking functionality available even if auxiliary services fail

Security Requirements

•PCI DSS compliance — For credit card handling and storage
•Data encryption — TLS in transit, AES-256 at rest for sensitive data
•Authentication — Multi-factor for staff, secure session management for guests
•Authorization — Role-based access control with principle of least privilege
•Audit logging — Complete trail of all booking and modification activities
•Privacy compliance — GDPR, CCPA compliance for guest data handling

Scalability Requirements

•Multi-property — Support hotel chains with 100+ properties
•Room inventory — Handle properties from 50 to 5,000+ rooms
•Historical data — Maintain 7+ years of booking history for analysis
•Peak handling — 10x normal load during flash sales or events
•Geographic distribution — Support global deployments with regional data residency

The Double-Booking Problem

The absolute #1 reliability requirement: NEVER double-book a physical room. Two guests should never arrive expecting the same room on the same night. This requires careful concurrency handling, exactly-once semantics for booking confirmations, and robust distributed locking if applicable. Design violations here have immediate, visible business consequences.

Edge Cases and Special Scenarios

Production systems encounter countless edge cases. Anticipating these during requirements analysis prevents painful redesigns later. Here are critical scenarios your design must handle:

Critical Edge Cases
Scenario	Complexity	Handling Strategy
Same-day booking	Medium	Check current time vs. hotel's check-in cutoff; different availability logic
Multi-room booking	High	Atomic allocation of all rooms or none; partial availability handling
Cross-midnight check-in	Medium	Define clear cutoff times; late arrival notes; next-day date handling
Extended stay modification	High	Check availability for new nights; maintain room continuity preference
Rate change during stay	Medium	Rate lock policies; daily rate granularity vs. blended rate
Overbooking walk	High	Guest relocation process; compensation calculation; partner hotel integration
Room type unavailable	Medium	Upgrade/downgrade logic; rate adjustment; guest notification
Payment failure post-confirm	High	Reservation hold period; retry logic; eventual cancellation
Group block partial release	High	Block management; individual pickup tracking; cutoff date logic
Connecting rooms	Medium	Room relationship mapping; availability as unit; split booking handling

Temporal Edge Cases

Time-related edge cases deserve special attention:

Timezone Considerations:

The hotel operates in its local timezone, but guests book from anywhere
Cancellation deadline calculations must use hotel time, not guest time
Day boundaries for rate calculation follow hotel time
System must handle daylight saving transitions gracefully

Date Boundary Cases:

What happens if a guest wants to check in at 11pm but check-in closes at 10pm?
How do you handle a 28+ night stay that spans rate season boundaries?
What if rates for future dates haven't been loaded yet?
How do you handle leap years in availability calculations?

The 80/20 of Edge Cases

While dozens of edge cases exist, focus your initial design on the most impactful ones. A robust design handles the common 80% elegantly and provides extension points for the remaining 20%. Don't let edge case complexity paralyze your core design, but do document them for future implementation.

External Integration Requirements

A hotel booking system doesn't operate in isolation. It must integrate with numerous external systems, each bringing interface requirements and constraints.

Distribution Channels

•OTAs — Booking.com, Expedia, Hotels.com APIs
•GDS — Amadeus, Sabre, Travelport for corporate/travel agent bookings
•Metasearch — Google Hotels, TripAdvisor, Kayak pricing feeds
•Brand website — Direct booking engine integration
•Mobile apps — iOS/Android native booking experiences

Payment & Operations

•Payment gateways — Stripe, Adyen, PayPal for payment processing
•PMS integration — Property Management System for front-desk operations
•CRM systems — Guest profiles, preferences, loyalty data
•Revenue management — Dynamic pricing engines (IDeaS, Duetto)
•Communication — Email/SMS services for confirmations

Integration Design Principle

Design your core domain objects to be integration-agnostic. The Room, Reservation, and Guest entities shouldn't know whether data comes from Booking.com or your direct website. Use adapters and anti-corruption layers to translate between external formats and your clean domain model. This makes adding new channels trivial.

Summary and Requirements Checklist

We've conducted a thorough requirements analysis for the Hotel Booking System. Let's consolidate our findings into a structured checklist that will guide design decisions:

Core Functional Requirements

•Availability search — Multi-dimensional search across dates, guest count, room types, amenities
•Reservation management — Full CRUD with state machine for booking lifecycle
•Pricing engine — Dynamic pricing with multiple rate plans, promotions, and taxes
•Cancellation handling — Time-based policies, refund calculations, inventory release
•Modification support — Date changes, room changes, guest changes with validation
•Multi-channel support — Unified inventory across direct and OTA channels

Design Considerations Identified

•Temporal complexity — Inventory is date-bounded; availability is multi-dimensional
•State management — Reservation lifecycle requires formal state machine
•Business rule complexity — Pricing, cancellation, and modification rules are highly configurable
•Concurrency criticality — Double-booking prevention is non-negotiable
•Integration points — System must play well with OTAs, payment, and operations systems
•Extensibility needs — New room types, policies, and channels should be additive

What's Next:

With a solid understanding of requirements, we're ready to identify and design the core entities that will form our domain model. The next page will systematically extract and define Hotel, Room, Reservation, Guest, and supporting entities—establishing the building blocks for our object-oriented design.

Page Complete

You now have comprehensive requirements for a Hotel Booking System. This analysis reveals that hotel booking is far more complex than it appears—involving temporal inventory, intricate business rules, multiple stakeholders, and critical reliability constraints. The design we build must respect these realities.