Requirements for the Traffic Signal

Let's define what our Traffic Signal Control System needs to do. Each requirement is specific enough to drive at least one class, method, or design decision.

Signal States and Transitions:

1. R1: Each vehicular signal head shall support exactly three states: Red, Yellow (amber), and Green. The signal must be in exactly one state at any given time.
2. R2: State transitions shall follow the fixed cycle: Green → Yellow → Red → Green. No state may be skipped (e.g., Green → Red is forbidden — Yellow must always intervene).
3. R3: Each state shall have a configurable duration in seconds. Typical defaults: Green = 30s, Yellow = 5s, Red = 35s (includes all-red clearance). Durations must be settable per signal head.
4. R4: Transitions between states shall be triggered by timer expiration — when the configured duration for the current state elapses, the signal transitions to the next state automatically.

Intersection Coordination:

5. R5: An intersection shall manage multiple signal heads — one per approach direction. A standard four-way intersection has four signal heads (North, South, East, West).
6. R6: Signal heads shall be grouped into phases. A phase defines which approaches receive green simultaneously. For a standard four-way intersection: Phase A = North + South green, Phase B = East + West green.
7. R7: The intersection controller shall cycle through phases sequentially. Within each phase, the controller sets the active approaches to green, waits for the green duration, transitions through yellow, then all-red clearance, before activating the next phase.
8. R8 (Safety Invariant): Conflicting phases shall never have green signals simultaneously. At no point shall North-South and East-West both show green — this represents a collision-critical failure. The design must enforce this invariant structurally, not just by convention.

Pedestrian Signals:

9. R9: Each crosswalk shall have a pedestrian signal displaying one of three states: Walk, Flashing Don't Walk (countdown), and Steady Don't Walk.
10. R10: Pedestrian signals shall be synchronized with their parallel vehicular phase. When North-South vehicles get green, the North-South crosswalks show Walk. When the vehicular phase transitions to yellow, pedestrian signals transition to Flashing Don't Walk. On red, they show Steady Don't Walk.
11. R11: A pedestrian button press shall register a crossing request. The request is served when the parallel phase next becomes active — it does not interrupt the current phase.

Emergency Vehicle Preemption:

12. R12: The system shall support emergency vehicle preemption (EVP). When an emergency signal is received for a specific approach direction, the controller shall override the normal cycle.
13. R13: During EVP, the emergency approach shall receive green, and all conflicting approaches shall be held on red. If a conflicting approach is currently green, it shall transition through yellow → red before the emergency green activates (preserving the safety invariant).
14. R14: When the emergency signal is cleared, the controller shall resume normal phase cycling from the point it was interrupted.

Beyond functionality, the system must satisfy:

1. NF1 — Safety First: The safety invariant (R8) must be enforced at the architectural level. It should be impossible to put conflicting approaches in green through any sequence of API calls. This is not a "nice to have" — in real traffic engineering, this is a life-or-death requirement.

2. NF2 — Extensibility: Adding a new signal type (e.g., turning arrows, flashing yellow for low-traffic hours, transit priority) should not require modifying existing state classes. New states can be added by implementing the state interface — following the Open/Closed Principle (Fundamentals S6).

3. NF3 — Configurability: Signal durations, phase groupings, and intersection layout must be configurable — not hardcoded. Different intersections have different timing needs.

4. NF4 — Testability: Each component (individual signal head, phase controller, emergency preemption) must be testable in isolation. State transitions should be deterministic and verifiable.

5. NF5 — Thread Safety: If the system is used in a simulation or real-time context with concurrent timer threads and emergency interrupts, state transitions must be atomic and consistent.

In Scope:

• Vehicular signal head state management (Red, Yellow, Green)
• Pedestrian signal state management (Walk, Flashing Don't Walk, Steady Don't Walk)
• Timer-based phase cycling within a single intersection
• Phase configuration (which approaches are grouped together)
• Emergency vehicle preemption and resume
• Configurable timing per signal state
• Observer-based synchronization between vehicular and pedestrian signals

Out of Scope:

• Network coordination between intersections — "green wave" optimization across a corridor is a system-design concern, not object-level design
• Vehicle detection hardware — loop detectors, cameras, radar sensors are hardware interfaces
• Adaptive timing algorithms (SCATS, SCOOT, InSync) — these are complex optimization systems; our base design uses fixed-time cycling with an extensibility hook
• Database persistence — signal configurations in our design are in-memory objects
• REST API / UI — no web endpoints or graphical display
• GPS-based preemption detection — we model the preemption as a method call; how it's triggered is external

Every requirement maps to concrete design elements we'll build in the following tutorials:

Requirement	Design Element
R1 (three signal states)	SignalState enum and TrafficSignalState interface
R2 (fixed cycle)	State transition logic in each concrete state class
R3 (configurable duration)	TimingConfig class with per-state durations
R4 (timer-triggered transitions)	Timer mechanism in TrafficSignal or IntersectionController
R5-R6 (phases and approaches)	SignalPhase class grouping signal heads, Direction enum
R7 (phase cycling)	IntersectionController.cyclePhases() method
R8 (safety invariant)	Enforced by IntersectionController — only one phase active at a time
R9-R10 (pedestrian signals)	PedestrianSignal class, Observer on vehicular signal changes
R11 (pedestrian button)	PedestrianSignal.requestCrossing() queues request for next parallel phase
R12-R14 (emergency preemption)	EmergencyPreemptionHandler or dedicated method on controller

This traceability ensures we're not inventing classes out of thin air and not leaving requirements unaddressed.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Here are the questions an interviewer expects you to ask for a traffic signal problem:

• "How many approaches does the intersection have?" — Clarifies whether it's a simple 4-way or a complex multi-leg intersection. Start with 4-way, note extensibility.
• "Are we handling pedestrian signals?" — Shows you're thinking beyond the obvious vehicular signals.
• "Should we support emergency vehicle preemption?" — Demonstrates awareness of real-world traffic engineering.
• "Is this fixed-time or actuated (sensor-driven)?" — Shows domain knowledge. Most interviewers expect fixed-time with a note that actuated could be added via Strategy Pattern.
• "Do we need to coordinate with neighboring intersections?" — Scopes the problem. The answer is almost always "no" in LLD interviews — that's system design territory.
• "Should all-red clearance be modeled?" — A subtle but important safety detail. Including it shows depth.

Asking these questions demonstrates you understand the domain and aren't just drawing generic state diagrams.