Section 2: Every Way a Game Can End - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's answers into a contract. Nine functional requirements, led by every way a game can end, because the result is the product. Five non-goals with reasons. Numbers for relay, game start, matchmaking, clock fairness, failover, availability and freshness. A per-data consistency stance, and four design choices that fall out before any arithmetic.
The clarifications are done. The interviewer leans back: "So what exactly are you committing to?" "Real-time chess, fast and fair" is not a commitment. "Priya's move leaves Omar's gateway within 50 ms of reaching hers, at p99, in-region, and she is never charged for time her move spent on the wire" is. Every line should be testable.
The Functional Contract
| # | Requirement | Notes |
|---|---|---|
| FR1 | Find a game | Quick pair (POST /seeks), or challenge a friend or open link (POST /challenges) |
| FR2 | Play a live, timed game | The server validates moves, runs both clocks, decides the result |
| FR3 | End every game correctly | Every end condition below, with the right result and rating effect |
| FR4 | Reconnect and resume | After a drop, sync with fromPly restores missing moves and current clocks |
| FR5 | Spectate | Snapshot via GET /games/{gameId}, then watch for live moves |
| FR6 | Ratings | Per pool (bullet, blitz, rapid), updated after every rated game |
| FR7 | History and PGN | Recent games per player; any game as PGN |
| FR8 | Tournaments | Create, join, withdraw; Arena and Swiss formats; live standings |
| FR9 | Fair play | Detect engine assistance and undo the rating damage it caused |
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson