Requirements for the Airline System

Let's define what our Airline Management System needs to do. We group requirements by domain area so they're easier to trace to classes later.

Airline & Flight Management

R1: The system shall allow creating airlines, each identified by a name and IATA code (e.g., "Delta", "DL").

R2: The system shall support creating flights, each associated with exactly one airline, one aircraft, a departure airport, an arrival airport, a scheduled departure time, and a scheduled arrival time.

R3: The system shall track flight status — SCHEDULED, BOARDING, DEPARTED, ARRIVED, CANCELLED, DELAYED — and allow authorized transitions between statuses.

R4: The system shall maintain a route concept connecting two airports, so multiple flights can operate on the same route.

Aircraft & Seat Management

R5: The system shall support aircraft, each identified by a model name, tail number, and total seat capacity.

R6: Each aircraft shall have a seat map with seats organized into three travel classes: ECONOMY, BUSINESS, and FIRST_CLASS.

R7: Each seat shall have a seat number (e.g., "12A"), a travel class, and an availability status (AVAILABLE, BOOKED, BLOCKED).

Passenger & Booking

R8: The system shall support passenger profiles with name, email, phone, and passport number.

R9: The system shall allow a passenger to book a seat on a specific flight by selecting an available seat in their chosen travel class.

R10: A booking shall record the passenger, the flight, the assigned seat, the fare paid, and a booking status (PENDING, CONFIRMED, CHECKED_IN, CANCELLED, COMPLETED).

R11: The system shall enforce that a seat can only be booked by one passenger per flight — no double-booking.

R12: The system shall allow booking cancellation, which releases the reserved seat back to AVAILABLE status and transitions the booking to CANCELLED.

Pricing

R13: The system shall calculate fares based on the selected travel class using a pluggable pricing strategy.

R14: Each travel class shall have its own pricing logic — Economy uses a base fare, Business applies a multiplier, First Class applies a premium surcharge — and the system must support adding new pricing strategies without modifying existing code.

Notifications

R15: The system shall notify all passengers on a flight when the flight status changes (e.g., DELAYED, CANCELLED, gate change).

R16: Notification delivery shall support multiple channels (e.g., email, SMS) and be extensible to new channels without modifying the core booking engine.

Search & Retrieval

R17: The system shall allow searching for flights by departure airport, arrival airport, and date.

R18: The system shall allow retrieving all bookings for a given passenger.

Beyond functionality, our design must satisfy:

NF1: Extensibility (Open/Closed Principle) — Adding a new travel class (e.g., Premium Economy) or a new pricing strategy should require only a new class, not modifications to BookingService or PricingStrategy consumers. This is enforced via the Strategy and Factory patterns.

NF2: Single Responsibility — Each class should have one clear reason to change. The Flight class manages schedule data; the BookingService orchestrates reservations; the PricingStrategy calculates fares. No god-class that does everything.

NF3: Testability — Each component should be testable in isolation. Pricing strategies should be unit-testable without a real flight. Notification observers should be testable without a real email service.

NF4: Correctness — Seat availability must be consistent. A cancelled booking must always release its seat. A flight status transition must follow the allowed state machine — no jumping from SCHEDULED to ARRIVED.

NF5: Loose Coupling — The booking engine should not depend on concrete notification channels. The pricing engine should not depend on specific travel class implementations. Achieved through interfaces and dependency injection (Fundamentals S13).

In Scope:

• Airlines, flights, aircraft, seat maps, and routes
• Passenger profiles and booking with seat assignment
• Multi-class pricing via Strategy Pattern
• Booking lifecycle (PENDING → CONFIRMED → CHECKED_IN → COMPLETED, with CANCELLED)
• Flight status management (SCHEDULED → BOARDING → DEPARTED → ARRIVED, with DELAYED/CANCELLED)
• Observer-based notifications on flight status changes
• Flight search by route and date

Out of Scope:

• Payment processing — We model the fare calculation, not the payment gateway integration (System Design concern)
• Global Distribution Systems (GDS) — Amadeus, Sabre, Travelport integration is infrastructure-level
• Loyalty / frequent-flyer programs — Would add a Decorator or separate subsystem; out of scope for the core booking flow
• Baggage tracking — A separate domain with its own state machine
• Crew scheduling — Complex optimization problem beyond LLD scope
• Multi-leg / connecting flights — Each booking is for a single flight segment; itinerary building is out of scope
• Overbooking algorithms — Yield management is a business analytics concern

Each requirement group directly drives our class design:

Requirement Group	Key Classes	Design Pattern
Airline & Flight (R1-R4)	Airline, Flight, Route, Airport	State (flight status)
Aircraft & Seats (R5-R7)	Aircraft, Seat, SeatClass enum, SeatStatus enum	Factory (seat creation)
Passenger & Booking (R8-R12)	Passenger, Booking, BookingStatus enum	State transitions
Pricing (R13-R14)	PricingStrategy interface, EconomyPricing, BusinessPricing, FirstClassPricing	Strategy
Notifications (R15-R16)	FlightObserver interface, EmailNotifier, SMSNotifier	Observer
Search (R17-R18)	AirlineService (facade)	—

Notice how each row maps to a distinct cluster of classes. This is the Single Responsibility Principle at the architectural level — each concern owns its own set of classes.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Here are the questions a strong candidate asks:

"Should we support multiple fare classes per seat, or is each seat fixed to one class?"
This determines whether SeatClass is an attribute of Seat or a separate entity. We chose fixed-to-seat for simplicity.

"Do we need to handle connecting flights / multi-leg itineraries?"
This dramatically increases complexity. Scoping to single-segment flights keeps the design focused.

"Should pricing be static per class, or dynamic based on demand?"
This is why we use Strategy — it supports both. Start with static multipliers, swap in dynamic algorithms later.

"Who needs to be notified on flight status changes — passengers only, or also crew and ground staff?"
This shapes the Observer hierarchy. We start with passenger notifications and design for extensibility.

"Is overbooking allowed?"
If yes, it changes seat availability logic significantly. We scope it out but note it as an extension.

These questions demonstrate domain understanding and help you avoid over-engineering or under-scoping the problem.