Requirements for Tic Tac Toe

Let's define exactly what our Tic Tac Toe system needs to do. Each requirement is numbered so we can trace it directly to a class, attribute, or method in our upcoming class diagram.

1. R1: Two-Player Game — The system shall support exactly two players in a single game session. Each player is identified by a name and assigned a unique symbol (X or O).

2. R2: Game Board — The game shall be played on a square grid. The default grid size is 3×3, but the design should accommodate NxN boards (addressed in the extension tutorial).

3. R3: Cell State Tracking — Each cell on the board shall be in one of three states: empty, occupied by X, or occupied by O. Once a cell is occupied, it cannot be changed.

4. R4: Turn Alternation — Players shall take turns placing their symbol. Player X always moves first. The system must enforce strict alternation — a player cannot move twice in a row.

5. R5: Move Validation — Before placing a symbol, the system shall validate that:

   • The target cell coordinates are within the board boundaries
   • The target cell is not already occupied
   • The game is still in progress (not already won or drawn)

6. R6: Win Detection — After each move, the system shall check whether the current player has won by completing an entire row, an entire column, or either diagonal with their symbol.

7. R7: Draw Detection — If all cells are occupied and no player has won, the system shall declare the game a draw.

8. R8: Game Status — The system shall maintain and expose the current game status at all times: IN_PROGRESS, X_WINS, O_WINS, or DRAW.

9. R9: Move History — The system shall record each move (player, row, column) in order, allowing the game to be replayed or inspected after completion.

Beyond the core functionality, our design should satisfy these quality attributes:

1. Extensibility — The board size should be configurable (NxN) without modifying the win-detection or game-loop logic. Adding support for a 5×5 or 10×10 board should require changing only the board initialization, not the core algorithms.

2. Testability — Each component (Board, Game, win-detection) should be testable in isolation. The Board should be testable without a Game, and win detection should be testable with a pre-configured board state.

3. Single Responsibility — The Board class should only manage the grid state (place symbols, check occupancy). It should NOT know about players, turns, or game rules. The Game class orchestrates the rules. This separation makes each class easier to test and modify.

4. Input Flexibility — The design should accept moves as (row, column) coordinates without being tied to any specific input mechanism (console, GUI, network). The core logic should work regardless of how moves are provided.

Before we draw the class diagram, it's useful to see how each requirement maps to a design element. This traceability ensures we don't invent classes without justification or forget requirements in the implementation.

Requirement	Design Element	Justification
R1: Two players with symbols	Player class, Symbol enum	Each player has identity (name) and a fixed symbol
R2: Square grid board	Board class with 2D structure	Board encapsulates the grid and its operations
R3: Cell state tracking	Symbol enum (X, O, EMPTY)	Each cell holds a Symbol value; EMPTY is the default
R4: Turn alternation	Game class tracks currentPlayerIndex	Game enforces whose turn it is
R5: Move validation	Board.isValidMove(), Game.makeMove()	Board checks bounds and occupancy; Game checks status
R6: Win detection	Board.checkWin() or optimized counter approach	After each move, check rows, columns, diagonals
R7: Draw detection	Board.isFull() combined with no winner	All cells occupied + no winner = DRAW
R8: Game status	GameStatus enum	IN_PROGRESS, X_WINS, O_WINS, DRAW
R9: Move history	Game maintains List<Move>	Each move records player, row, column

In Scope:

• Core game logic: board, players, turns, win/draw detection
• Move validation and error handling
• Extensibility to NxN boards (covered in a dedicated tutorial)
• Move history tracking
• Complete implementations in Python and Java

Out of Scope:

• AI opponents — Minimax or alpha-beta pruning are algorithm problems, not LLD. Our design supports plugging in an AI player, but we won't implement the AI logic.
• Graphical UI — We design the domain model, not the rendering layer. A UI would call our Game.makeMove() method.
• Network multiplayer — Real-time synchronization is a System Design concern. Our model works whether both players are local or remote.
• Persistent storage — Saving/loading games to a database is infrastructure, not object design.
• Tournament/matchmaking — Managing multiple games or ranking players is out of scope.

In a real interview, spend 3–5 minutes clarifying requirements before jumping into design. Even for a well-known game like Tic Tac Toe, asking the right questions shows maturity:

• "Should we support only 3×3, or should the board size be configurable?" — This determines whether you hard-code or parameterize.
• "Is this a two-player game, or should we support AI?" — This affects the Player abstraction.
• "Do we need to track move history for undo/replay?" — This adds a data structure to your design.
• "Should the game be thread-safe for concurrent access?" — For an Easy problem, the answer is typically no, but asking demonstrates awareness.

The interviewer's answers to these questions directly shape your class diagram. Requirements are not a formality — they are the foundation every design decision stands on.