Requirements for the Chess Game

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

Board & Setup:

1. R1 — Standard 8×8 board: The system shall model a chess board as an 8×8 grid of cells, where each cell is identified by its row (1-8) and column (a-h).
2. R2 — Initial piece placement: The system shall initialize the board with 32 pieces in the standard starting position — 16 white pieces and 16 black pieces — each placed on its correct starting cell.

Piece Movement:

3. R3 — Six piece types with distinct movement: The system shall support six piece types — King, Queen, Rook, Bishop, Knight, and Pawn — each with its own movement rules as defined by standard chess.
4. R4 — Movement validation: The system shall validate that a piece can move to the target cell according to its movement rules, accounting for: (a) the piece can physically reach the target, (b) no friendly piece occupies the target, and (c) no piece blocks the path (except Knight, which jumps).
5. R5 — Capture: The system shall allow a piece to capture an opponent's piece by moving to its cell, removing the captured piece from the board.

Special Rules:

6. R6 — Castling: The system shall support kingside and queenside castling. Castling is permitted only when: (a) neither the King nor the involved Rook has previously moved, (b) no pieces stand between them, (c) the King is not currently in check, and (d) the King does not pass through or land on an attacked square.
7. R7 — En passant: The system shall support en passant capture. When a pawn advances two squares from its starting position and lands beside an opponent's pawn, the opponent may capture it as if it had moved only one square — but only on the very next move.
8. R8 — Pawn promotion: When a pawn reaches the opponent's back rank (row 8 for White, row 1 for Black), the system shall promote it to a Queen, Rook, Bishop, or Knight of the same color, as chosen by the player.
9. R9 — Pawn double advance: A pawn on its starting row may move forward two squares in a single move, provided both squares are unoccupied.

Check & Game Termination:

10. R10 — Check detection: The system shall detect when a player's King is under attack (in check) by any opponent piece. A player in check MUST make a move that resolves the check.
11. R11 — Self-check prevention: The system shall reject any move that would leave the moving player's own King in check. This applies to all moves, including captures and castling.
12. R12 — Checkmate detection: The system shall detect checkmate — the King is in check and no legal move can remove the check. Checkmate ends the game with the checking side winning.
13. R13 — Stalemate detection: The system shall detect stalemate — the player whose turn it is has no legal move available, but their King is NOT in check. Stalemate ends the game in a draw.

Game Flow:

14. R14 — Two-player alternating turns: The system shall enforce alternating turns between White and Black, with White always moving first.
15. R15 — Move history: The system shall maintain a complete history of all moves made during the game, supporting undo of the last move.
16. R16 — Game status tracking: The system shall track the current game status at all times: ACTIVE, CHECK, CHECKMATE, STALEMATE, RESIGNATION, or DRAW.
17. R17 — Resignation: Either player may resign at any time, ending the game with the opponent as the winner.

Beyond functionality, our design must uphold these qualities:

1. Extensibility (Open/Closed): Adding a new piece type (e.g., for fairy chess variants like the Archbishop or Chancellor) should require creating a new subclass of Piece — without modifying Board, Game, or any existing piece class. This is the Open/Closed Principle (Fundamentals S6) applied through polymorphism.

2. Testability: Each piece's movement logic must be testable in isolation. We should be able to place a Knight on an empty board and verify its valid moves without constructing an entire game. Similarly, check/checkmate detection should be testable with custom board configurations.

3. Correctness above performance: Chess move generation is not performance-critical at the LLD level (we're not building a search engine). Clean, readable, correct code is more important than bitboard optimizations. A brute-force check for all possible opponent attacks is perfectly acceptable.

4. Undo support: The move history must support undoing the last move, which means each move must store enough information to reverse it — including captured pieces, castling rights changes, and en passant state.

In Scope:

• Complete movement rules for all six standard piece types
• Castling (kingside and queenside) with all prerequisite checks
• En passant capture with the one-turn window
• Pawn promotion (to Queen, Rook, Bishop, or Knight)
• Check, checkmate, and stalemate detection
• Move history with undo capability
• Turn-based game flow between two human players

Out of Scope:

• AI/computer opponent — move evaluation, minimax, alpha-beta pruning are algorithmic concerns, not OOP modeling
• Chess clocks and time controls — timers are an infrastructure/UI layer concern
• Network play — client-server communication is system design, not LLD
• Draw by repetition or fifty-move rule — these require position hashing and move counting that adds complexity without new OOP concepts (we'll mention them as extensions)
• GUI or text-based rendering — our deliverable is the domain model, not a display layer
• Opening books or endgame tablebases — these are data-driven optimizations, not design patterns

Here's how each requirement will map to classes in our design — we'll verify this after building the class diagrams:

Requirement	Implemented By
R1 — 8×8 board	Board composes 64 Cell objects
R2 — Initial placement	Board.initialize() places pieces in starting positions
R3 — Six piece types	Piece (abstract) → King, Queen, Rook, Bishop, Knight, Pawn
R4 — Movement validation	Piece.getValidMoves(board) + Game.isMoveLegal(move)
R5 — Capture	Board.executeMove(move) removes captured piece
R6 — Castling	King.getValidMoves() + castling state tracked in Game
R7 — En passant	Pawn.getValidMoves() + en passant state in Game
R8 — Pawn promotion	Game.promotePawn(position, pieceType)
R9 — Pawn double advance	Pawn.getValidMoves() checks starting row
R10 — Check detection	Game.isInCheck(color) scans opponent attacks on King
R11 — Self-check prevention	Game.isMoveLegal(move) simulates move, checks for self-check
R12 — Checkmate	Game.isCheckmate(color) — in check + no legal moves
R13 — Stalemate	Game.isStalemate(color) — not in check + no legal moves
R14 — Alternating turns	Game.currentTurn alternates between WHITE and BLACK
R15 — Move history	MoveHistory stores Move objects (Command Pattern)
R16 — Game status	Game.status field of type GameStatus enum
R17 — Resignation	Game.resign(player) sets status to RESIGNATION

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Ask questions like:

• "Should we support all special rules — castling, en passant, promotion — or focus on basic movement first?"
• "Is undo/redo in scope, or just forward play?"
• "Are we designing a two-player local game or a networked game?"
• "Should we detect all draw conditions (stalemate, repetition, fifty-move) or just checkmate?"

Interviewers appreciate candidates who scope the problem deliberately rather than silently assuming everything is required. For a 45-minute session, you might agree to skip complex draw rules and focus on check/checkmate — then mention them as extensions.