Requirements for the Restaurant System

Let's define what our restaurant management system needs to do. Each requirement is specific enough to drive at least one class or method in the final design.

Table Management:

1. R1 — Table Tracking: The system shall maintain a set of tables, each with a unique ID, seating capacity, and current status.
2. R2 — Table States: Each table shall have exactly one status at any time: Available, Reserved, Occupied, or BeingCleaned. Transitions between states are governed by specific events (seating a guest, completing payment, finishing cleaning).
3. R3 — Reservation Support: The system shall allow creating reservations for a future time slot, specifying guest name, party size, and contact information. A reservation assigns a specific table.
4. R4 — Walk-In Seating: The system shall support seating walk-in guests at any Available table whose capacity meets or exceeds the party size.

Order Management:

5. R5 — Order Creation: A waiter shall be able to create an order for an occupied table. An order contains one or more order items, each referencing a menu item with an optional quantity and special instructions.
6. R6 — Order Lifecycle: Each order shall progress through defined statuses: Placed → InPreparation → Ready → Served → Completed. An order may also be Cancelled before it reaches InPreparation.
7. R7 — Order Modification: A waiter shall be able to add or remove items from an order while its status is Placed (before the kitchen starts preparation). Modifications after InPreparation are not allowed.
8. R8 — Order Cancellation: A waiter shall be able to cancel an order only when its status is Placed. Once the kitchen begins preparation, cancellation is no longer permitted.

Menu:

9. R9 — Menu Management: The system shall maintain a menu of items, each with a name, description, price, category (Appetizer, MainCourse, Dessert, Beverage, Side), and availability flag.
10. R10 — Item Availability: An unavailable menu item cannot be added to an order. The system shall reject such attempts with a clear error.

Kitchen Display:

11. R11 — Kitchen Notification: When an order is placed or modified, the Kitchen Display System shall be notified automatically. The kitchen staff should not need to poll for updates.
12. R12 — Order Ready Notification: When the kitchen marks an order as Ready, the assigned waiter shall be notified.

Billing & Payment:

13. R13 — Bill Generation: The system shall generate a bill for an order, calculating subtotal (sum of item prices × quantities), tax (configurable percentage), and optional tip.
14. R14 — Payment Processing: The system shall accept payment via Cash, CreditCard, or DebitCard. Once payment is received, the order transitions to Completed.

Staff:

15. R15 — Staff Roles: The system shall model at least three staff roles — Waiter (takes orders, serves food), Chef (prepares orders), and Host (manages seating and reservations). Each staff member has a name and unique ID.

Beyond functionality, the design should satisfy:

1. Extensibility: Adding a new table state (e.g., OutOfService for maintenance), a new order status (e.g., PartiallyServed for courses), or a new payment method should not require modifying existing classes. The design must honor the Open/Closed Principle (Fundamentals S6).
2. Loose Coupling: The kitchen display and waiter notification systems must be decoupled from the order logic. The Order class should not know about the kitchen display implementation — it should only emit events.
3. Testability: Each component (table state machine, order lifecycle, billing calculation) must be testable in isolation without requiring the full restaurant context.
4. Consistency: A table cannot be freed while its order is still in progress. The two state machines (Table and Order) must enforce this invariant.
5. Auditability: Every order and payment should record a timestamp for tracking and reporting.

In Scope:

• Table lifecycle management (4 states with valid transitions)
• Order creation, modification, cancellation, and lifecycle
• Menu with categories and availability
• Kitchen Display System as an Observer of order events
• Bill generation with tax and tip
• Payment processing (cash, card)
• Staff role modeling (Waiter, Chef, Host)

Out of Scope:

• Database persistence — we model in-memory objects, not schemas
• REST API / network layer — this is LLD, not system design
• Inventory / supply chain — we don't track ingredient stock levels
• Customer loyalty / rewards — adds complexity without teaching new patterns
• Multi-location management — we design for a single restaurant
• Table splitting / merging — physically rearranging tables is out of scope
• Course-based serving — we treat each order as a single batch (not appetizer → main → dessert waves)
• Delivery / takeout — for dine-in only; see DP25 (Food Delivery) for delivery logistics

Every requirement will map to specific classes and methods. Here's a preview of how requirements drive the design:

Requirement	Design Element
R1 (Table Tracking)	Table class with id, capacity, status
R2 (Table States)	TableState interface + 4 concrete state classes
R3 (Reservations)	Reservation class with guest_name, party_size, time_slot
R5 (Order Creation)	Order class, OrderItem class, Waiter.place_order()
R6 (Order Lifecycle)	OrderStatus enum with 6 values
R7-R8 (Modify/Cancel)	Command Pattern: AddItemCommand, RemoveItemCommand, CancelOrderCommand
R9-R10 (Menu)	MenuItem class, Menu class with availability checks
R11-R12 (Notifications)	Observer Pattern: OrderObserver interface, KitchenDisplay, WaiterNotifier
R13-R14 (Billing)	Bill class, Payment class, PaymentMethod enum
R15 (Staff)	Staff abstract class → Waiter, Chef, Host

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

In a real interview, spend 3–5 minutes clarifying requirements before drawing any diagram. Ask questions like:

• "Should we support reservations, or only walk-in seating?"
• "Can orders be modified after the kitchen starts preparing?"
• "Do we need to model course-based serving (appetizer first, then main course), or is a single-batch order sufficient?"
• "Is bill splitting in scope?"
• "How many staff roles should we model?"

These questions show the interviewer you think before you draw. They also shrink the problem to a manageable scope — a 45-minute interview can't cover everything, so scoping is a design skill in itself.