Requirements for the Elevator System

Let's define exactly what our Elevator System must do. Each requirement is specific enough to drive a design decision — a class, method, or relationship in our class diagram.

R1: The building has N floors and M elevator cars.
The system must support a configurable number of floors (e.g., 20) and elevators (e.g., 4). Each elevator operates independently but is coordinated by a central dispatcher.

R2: Users can make hall calls (external requests) from any floor.
On each floor, there are UP and DOWN buttons (except the ground floor which has only UP, and the top floor which has only DOWN). A hall call specifies the floor and the desired direction.

R3: Users can make cabin calls (internal requests) from inside an elevator.
Once inside the elevator, a passenger presses a destination floor button on the control panel. This request is assigned exclusively to that elevator.

R4: The system dispatches hall calls to the optimal elevator.
When a hall call arrives, the dispatcher selects which elevator should service it based on the current scheduling algorithm. Factors include: elevator position, current direction, and number of pending requests.

R5: Each elevator moves between floors, stopping to pick up and drop off passengers.
The elevator travels one floor at a time. At each floor, it checks whether it should stop (to serve a pending request) or continue. When it stops, the doors open, passengers enter/exit, the doors close, and the elevator resumes.

R6: Each elevator has a direction state: UP, DOWN, or IDLE.
An elevator going UP only serves requests above its current floor (in the current sweep). When all upward requests are served, it either reverses direction or becomes idle.

R7: The scheduling algorithm is interchangeable.
The system supports multiple scheduling algorithms — FCFS (First Come First Served), SCAN (elevator algorithm), and LOOK (optimized SCAN). The algorithm can be swapped without modifying the elevator or dispatcher classes.

R8: Each elevator has a door that opens and closes at stops.
The door transitions through states: CLOSED → OPENING → OPEN → CLOSING → CLOSED. The elevator cannot move while the door is open.

R9: Each floor has a display panel showing the current position and direction of each elevator.
Floor displays update in real time as elevators move. This is a notification-based update — displays observe elevator state changes.

R10: The system prevents duplicate requests.
If floor 7 UP is already in the queue, pressing the UP button on floor 7 again does not add a duplicate request.

Beyond functionality, our design must satisfy these quality attributes:

NF1: Extensibility (Open/Closed Principle)
Adding a new scheduling algorithm (e.g., Nearest-Car, Destination-Dispatch) must not require modifying existing elevator or dispatcher classes. The Strategy Pattern enables this — new algorithms implement the SchedulingStrategy interface.

NF2: Testability
Each component must be testable in isolation. An elevator can be tested without a real dispatcher. A scheduling algorithm can be tested without real elevators — just pass in a list of requests and verify the order.

NF3: Thread Safety (Discussion)
In a real system, hall calls arrive concurrently from multiple floors and must be handled safely. We'll discuss thread-safe considerations but won't make concurrency the primary focus — this is a Medium design problem, not a concurrency problem like DP33–DP36.

NF4: Fairness
No floor should be starved indefinitely. The scheduling algorithm must guarantee that every request is eventually served, even if the elevator is busy with closer requests.

NF5: Efficiency
The scheduler should minimize total travel distance and average wait time. This is the primary metric for comparing FCFS, SCAN, and LOOK algorithms.

In Scope:

• Elevator car modeling (position, direction, door state, request queue)
• Hall call and cabin call handling
• Multi-elevator dispatch (assigning hall calls to the best car)
• Three scheduling algorithms: FCFS, SCAN, LOOK
• Floor display panels (Observer pattern)
• State management for elevator direction and door
• Complete Python and Java implementations

Out of Scope:

• Weight/capacity limits — requires hardware sensors, not core to LLD
• Emergency stop, fire mode, maintenance mode — important in real systems but not the focus of an interview-length design
• Physical motor control, acceleration/deceleration physics
• Database persistence, REST APIs, distributed systems
• UI rendering — we model the display data, not the UI framework
• VIP/express elevators — interesting extension but beyond base scope

Every requirement must map to at least one class or method. Here's a preview of how our requirements will drive the class diagram:

Requirement	Design Element
R1: N floors, M elevators	ElevatorSystem composes Elevator[] and Floor[]
R2: Hall calls	HallCall class, Floor.requestUp() / requestDown()
R3: Cabin calls	CabinCall class, ElevatorPanel.pressFloor(int)
R4: Dispatch to optimal elevator	Dispatcher class with SchedulingStrategy
R5: Move and stop	Elevator.move(), Elevator.shouldStop()
R6: Direction state	Direction enum (UP, DOWN, IDLE) on Elevator
R7: Interchangeable algorithm	SchedulingStrategy interface, FCFSStrategy, SCANStrategy, LOOKStrategy
R8: Door state	Door class with DoorStatus enum
R9: Floor display	FloorDisplay observes Elevator state changes
R10: No duplicates	Dispatcher.isDuplicate() check before adding request

This traceability is crucial — every class in our design exists because a requirement demands it. No class is invented without justification.

In a real interview, spend 3–5 minutes clarifying requirements before jumping into design. For the Elevator System, ask questions like:

• "How many elevators and floors should I design for?" — This determines if you need a dispatcher or can assume a single elevator.
• "Should I handle both hall calls and cabin calls?" — Some interviewers simplify to one type.
• "Is scheduling algorithm choice in scope?" — If YES, it signals they want Strategy Pattern and algorithm comparison.
• "Should I model the door mechanism?" — If YES, it signals they want State Pattern for door states.
• "Is concurrency in scope?" — For a 45-minute LLD round, usually not the primary focus.

Notice how each answer shapes the design: a single elevator needs no dispatcher, no hall calls means no direction optimization, and no algorithm choice means no Strategy Pattern. Clarify scope BEFORE designing.