## 1.1 Purpose

The purpose of Qheadache is to provide a stand-alone computerized puzzle game that enables users to solve a specific block-moving “headache.” The software offers an interactive board for moving blocks, supports undo and redo of actions, tracks and displays elapsed time and move counts, records player scores, displays score windows, and allows saving and loading games.

## 1.2 Scope

- Product identification: Qheadache — a stand-alone desktop game application.

- What the product will do:
  - Provide a graphical user interface (menus, graphics, optional sounds) for playing a block-based puzzle on a rectangular board.
  - Allow block selection, movement under geometric constraints, and end-of-game detection when the large square reaches the bottom of the board.
  - Support undo and redo of the last 1,000 movements.
  - Track and display player statistics: elapsed play time and number of movements.
  - Record up to 10 player results (name, movement count, time), display a statistics window, and allow erasing statistics.
  - Support saving/loading games (including current and prior block positions, move count, and elapsed time).
  - Provide standard menus: Game (Open/Save/Save As/Exit), Action (Undo/Redo), Statistics (Display/Erase), and Help (About).

- Application, benefits, objectives, goals:
  - Application domain: a simple computer game for anyone able to operate a computer (beginner level from age 8 through adults), requiring no special qualifications.
  - Objectives and goals: enable users to solve the specific puzzle (“headache”) by manipulating blocks to reach the winning configuration; provide accessible gameplay, progress tracking, and result persistence.
  - Benefits: entertainment, ease of use, progress measurement (time and moves), replayability through undo/redo, visibility of performance via a scoreboard, and the ability to resume play via save/load.

- Consistency with higher-level specifications: [N/A]

### 1.3.1 Product perspective

Qheadache is a single-user, stand-alone desktop game application. It is not an element of a larger system. It interacts with the host operating system primarily through the graphical user interface subsystem and local file system for save/load and statistics storage. The software depends on the Qt graphical library and is expected to run on operating systems supported by Qt, with portability to Windows required. No network or cloud services are involved.

#### System interfaces
- Local file system
  - Purpose: Persist and retrieve game state and player statistics.
  - Functionality supported: Open saved game; Save game; Save game as; Read/write statistics; Error handling on file write/read failures (e.g., wrong permissions, disk full).
  - Interface description: Local files on the host system; specific file formats/message contents are [N/A].

#### User interfaces
- Main window with:
  - Game board for block manipulation.
  - Menu bar with Game (Open, Save, Save As, Exit), Action (Undo, Redo), Statistics (Display, Erase), and Help (About).
- Interaction modalities:
  - Mouse: point, click, drag for selection/movement.
  - Keyboard: required for general input; specific shortcuts [N/A].
- Presentation:
  - Menus, graphics, optional sounds.
  - Minimum effective display resolution: 800×600 pixels.

#### Hardware interfaces
- Input devices: Mouse and keyboard (or compatible pointing/typing devices).
- Display: Graphical display supporting at least 800×600 resolution.
- Audio: Sound output optional; not required for gameplay.
- Configuration specifics (ports/protocols/instruction sets): [N/A].

#### Software interfaces
- Qt graphical library
  - Name: Qt
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Provides GUI (menus, graphics), event handling, and cross-platform portability.
  - Interface definition (APIs/messages/formats): [N/A]
- Operating system/platform
  - Required platforms: Any operating system supported by Qt; portability to Windows OS is required.
  - Version constraints: [N/A]
  - Purpose: Windowing, input devices, file I/O.
  - Interface definition/reference: [N/A]
- Interfaces with other application systems: [N/A]

#### Communications interfaces
- Network protocols/interfaces: [N/A]

#### Memory constraints
- Primary and secondary memory characteristics/limits: [N/A]

#### Operations
- Modes of operation: User-initiated, fully interactive gameplay; no unattended operations.
- Interactive periods: Continuous during gameplay sessions.
- Data processing support:
  - Automatic tracking of time elapsed and number of block movements.
  - Manual file operations via menu: Open, Save, Save As.
  - Statistics management: Append/update top 10 results; ability to erase all statistics.
- Backup and recovery:
  - User-controlled save; prompt to save on Exit if there are unsaved changes.
  - No automated backup or recovery beyond file open/save.

#### Site adaptation requirements
- Site-specific data/initialization: [N/A]
- Installation-specific modifications: [N/A]

#### Interfaces with services
- SaaS/cloud/external service interactions: [N/A]

### 1.3.2 Product functions

- Puzzle interaction and gameplay
  - Present a board with fixed-size blocks that the player selects, moves, and deselects under movement constraints.
  - Enforce non-overlap and in-bounds rules during movement.
  - Detect game completion when the large square block reaches the bottom of the board and freeze play statistics.

- Edit history
  - Provide undo and redo of recent movements via menu commands.
  - Update the displayed board state to reflect undone/redone moves.

- Time and move tracking
  - Continuously count and display elapsed play time.
  - Count and display the number of block movements.

- Statistics and scoring
  - On game completion, allow the player to enter a name and record their statistics (name, move count, elapsed time).
  - Maintain a statistics file containing up to 10 player records, replacing the worst record when full.
  - Display a statistics window listing recorded player results.
  - Allow the user to erase all recorded statistics.
  - Display error messages if statistics updates fail (e.g., insufficient permissions or disk full).

- File operations
  - Open a previously saved game from file and restore board state and player statistics.
  - Save the current game state to file, including block positions, move history, move count, and elapsed time.
  - Save As to a new file through a file-selection dialog.
  - Exit the application, prompting to save if there are unsaved changes.

- User interface and menus
  - Provide a main window containing the board and a menu bar.
  - Offer menu commands for Game (open, save, save as, exit), Action (undo, redo), Statistics (display, erase), and Help (About).
  - Display an About window with product information.

Representative user scenarios
- Play to completion: A player moves blocks until the win condition is met; time and moves are tracked; a finish window is shown; the player may record their name and view the statistics list.
- Manage progress: A player performs moves and uses undo/redo to correct mistakes; the board updates accordingly; time and move counts continue to update.
- Review and maintain results: A player opens the statistics window from the menu to review recorded results or erases all records.
- Save and resume later: A player saves the current game and later opens it to resume with the same board configuration, move history, and statistics.
- Exit safely: A player exits; if there are unsaved changes, the application offers to save before closing.

Functional relationships (textual)
- Gameplay drives time and move tracking; both feed into end-of-game processing.
- End-of-game processing feeds statistics recording, which updates the statistics file and the statistics window.
- File operations persist and restore gameplay state, including the move history that supports undo/redo.

### 1.3.3 User characteristics

- Intended users: Anyone who wants to play a simple game and knows how to operate a computer, from beginning-level players (approximately age 8) to advanced adult players.
- Educational level: No qualification is necessary.
- Prior experience: No prior gaming experience is required; users may range from novice to advanced.
- Technical expertise: Basic computer literacy sufficient to use a mouse and keyboard, select menu items, and type a name.
- Accessibility/disabilities: Sound is not required to play. Other disability-related user characteristics are [N/A].

### 1.3.4 Limitations

The following items constrain the supplier’s options as stated in the original SRS:

- a) Regulatory requirements and policies: [N/A]
- b) Hardware limitations:
  - Requires a keyboard and a mouse.
  - Requires a graphical display with a minimum resolution of 800×600.
  - Audio hardware is optional; sound is not required to play.
  - Board rendering constraints: display unit x must be between 50 and 100 pixels; board size is 5x (height) by 4x (width).
- c) Interfaces to other applications:
  - Stand-alone application; no communications interfaces are specified.
  - Dependency on the Qt graphical library; must run with all operating systems that Qt supports.
- d) Parallel operation:
  - Only one user per machine.
- e) Audit functions: [N/A]
- f) Control functions: [N/A]
- g) Higher-order language requirements: [N/A]
- h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK): [N/A]
- i) Quality requirements (e.g., reliability):
  - Portability: must be portable to the Windows OS and run on all operating systems that Qt supports.
- j) Criticality of the application: [N/A]
- k) Safety and security considerations: [N/A]
- l) Physical/mental considerations:
  - No qualification is necessary; users need only know how to operate a computer.
  - Intended for players starting at approximately age 8 and up.
  - Requires the ability to use a keyboard and mouse.
- m) Limitations sourced from other systems, including real-time requirements from the controlled system through interfaces: [N/A]

## 1.4 Definitions

- Qheadache: The product name; a stand-alone computerized puzzle game implemented with the Qt graphical library.

- Board: The rectangular game area where blocks are moved; height 5x and width 4x, black background, with yellow blocks and a separation margin of 0.1x between blocks.

- x (unit): The base graphical unit used to size the board and blocks; constrained to 50–100 pixels.

- Block: A movable piece on the board. The set comprises:
  - Four square blocks with side x,
  - Four rectangular blocks with height 2x and width x,
  - One rectangular block with height x and width 2x,
  - One square block with side 2x (the great square).

- Great square: The 2x by 2x square block; moving it to the bottom of the board ends the game.

- Movement (block movement): A single action that changes a block’s position while respecting constraints (no overlap, stays within the board, minimum clearance 0.05x). Each movement increments the movement count; Undo and Redo also count as movements.

- Game state: The internal interaction mode of the game, including:
  - Block selection: A state in which a block can be selected.
  - Block movement (also called “Block deplacement”): A state in which the selected block follows mouse movement under movement constraints.

- Player statistics: The per-game metrics recorded during play: number of block movements since start and elapsed time since start.

- Game statistics: The collection of up to 10 player statistics entries maintained by the game.

- Statistic file: The persistent storage that holds game statistics. When full (10 entries), saving a new entry erases the entry with the greatest number of block movements.

- Score: The association of a player name with time and number of movements recorded for a completed game.

- Statistic Window: A window showing up to 10 lines, each containing a player name, number of block movements, and time to solve the puzzle, read from the statistic file.

- Finish Window with Statistics: An end-of-game dialog containing “You win! Enter your name:”, a 20-character edit box, and an OK button; on confirmation, it saves the player statistics to the statistic file and then displays the Statistic Window.

- Simple Finish Window: An end-of-game dialog containing “You win!” and an OK button; on confirmation, it closes and then displays the Statistic Window.

- Undo: An action that cancels the last movement, restoring previous block positions; unavailable if there has been no previous movement. Counts as a movement.

- Redo: An action that reapplies the last movement that was undone; available only immediately after an Undo. Counts as a movement.

- Open game: Loads a previously saved game from a file selected by the user and restores the board and player statistics from that file.

- Save game: Writes the current game state to the previously used save file (if any), including current block positions, the last 10,000 previous positions, movement count, and elapsed time.

- Save game as: Prompts the user to choose a file and saves the current game state, including current block positions, previous positions, movement count, and elapsed time.

- Time passed to play: The elapsed time since the start of the current game, counted and displayed by the product.

# 2 References

No external standards, publications, or documents are referenced elsewhere in this SRS.

## Compliance

- [N/A]

## Guidance

- [N/A]

## 3.1 Functions

This section defines the software’s functional behavior as inputs are accepted and processed, outputs are generated, and states are transitioned.

### 3.1.1 Gameplay actions

- Board presentation and parameters
  - Parameters and effects
    - The board is a rectangular zone; height = 5x, width = 4x; x ∈ [50 px, 100 px].
    - Block inventory and sizes: four square blocks (x by x); four rectangular blocks (2x by x); one block (x by 2x); one square block (2x by 2x).
    - Spacing: blocks separated by 0.1x; minimum clearance enforced at 0.05x during movement.
    - Colors: board is black; blocks are yellow.
  - Relationship of outputs to inputs
    - These parameters determine initial rendering and all subsequent redraws of the board and blocks.

- Block selection and deselection
  - Inputs and validity checks
    - Selection: left-click down on a block within the board.
    - Deselection: left-click up on the currently selected block.
    - Validity: clicks outside blocks have no effect; deselection requires a selected block.
  - Exact sequence of operations
    - On selection: game state becomes “Block deplacement” (movement state).
    - On deselection: game state becomes “Block selection”.
  - Outputs
    - None specified beyond maintaining current display.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

- Block movement
  - Inputs and validity checks
    - Mouse movement while in “Block movement” state.
    - Validity: movement is constrained so the selected block does not overlap other blocks, does not exit the board, and maintains ≥ 0.05x clearance to others.
  - Exact sequence of operations
    - Selected block follows the mouse within the constraints above.
  - Outputs
    - None specified beyond the updated board drawing reflecting the block’s new position.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: Movement is constrained; no error message is produced.

- Undo action
  - Inputs and validity checks
    - Menu selection “Undo”; only enabled when a previous movement exists and within the last thousand actions.
  - Exact sequence of operations
    - Display block positions as they were before the last movement; this counts as a movement.
  - Outputs
    - New game board display.
  - Abnormal situations
    - Overflow: Undo beyond the last thousand actions is unavailable (menu disabled).
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: If no previous movement exists, action unavailable.

- Redo action
  - Inputs and validity checks
    - Menu selection “Redo”; only enabled when the previous action was “Undo”.
  - Exact sequence of operations
    - Display block positions as they were before the last movement was canceled; this counts as a movement.
  - Outputs
    - New game board display.
  - Abnormal situations
    - Overflow: Redo beyond available canceled movements is unavailable (menu disabled).
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: If previous action was not “Undo”, action unavailable.

### 3.1.2 End-of-game management

- End-of-game detection
  - Inputs and validity checks
    - The large (2x by 2x) square is moved to the bottom of the board.
  - Exact sequence of operations
    - Freeze all player statistics.
    - If the number of block movements of the current player is lower than the highest number recorded in the statistics file, display the “Finish Window with Statistics”; otherwise display the “Simple Finish Window”.
  - Outputs
    - One of the finish windows (see below).
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

- Finish Window with Statistics
  - Inputs and validity checks
    - Triggered at game end per rule above.
    - Player may enter a name (max 20 characters) and click “OK”.
  - Exact sequence of operations
    - On “OK”, record player statistics (name, block movement number, time used) to the statistics file (see statistics update).
    - Close finish window; display Statistics Window.
  - Outputs
    - Updated statistics file (on success); Statistics Window displayed.
  - Abnormal situations
    - Overflow: Top-10 policy applies in statistics update (see below).
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: On write failure (wrong permissions or disk full), display an error message.

- Simple Finish Window
  - Inputs and validity checks
    - Triggered at game end when not eligible for the statistics entry window.
  - Exact sequence of operations
    - On “OK”, close the window; display Statistics Window.
  - Outputs
    - Statistics Window displayed.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

### 3.1.3 Statistics management

- Player statistics tracking (during play)
  - Inputs and validity checks
    - Each block movement.
  - Exact sequence of operations
    - Increment number of block movements by 1.
    - Record time delta between this movement and the previously recorded time.
  - Outputs
    - None (internal state updated).
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

- Game statistics update (top-10)
  - Inputs and validity checks
    - Completion of “Finish Window with Statistics” by the player.
  - Exact sequence of operations
    - Append new player statistics (name, movement count, time).
    - If 10 player statistics are already recorded, erase the entry with the greatest number of block movements.
  - Outputs
    - Updated statistics file (or error message on failure).
  - Abnormal situations
    - Overflow: When at capacity (10 entries), the worst entry (greatest movements) is removed.
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: On write failure (wrong permissions or disk full), display an error message.

- Statistics erasing
  - Inputs and validity checks
    - Menu selection “Erase”.
  - Exact sequence of operations
    - Erase all data stored in the statistics file.
  - Outputs
    - None on success; error message otherwise.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: On failure (wrong permissions or disk full), display an error message.

- Statistics Window (display)
  - Inputs and validity checks
    - Triggered by end of game or menu selection “Display”.
  - Exact sequence of operations
    - Read statistics file; display a 10-line list showing player name, number of block movements, and time used.
  - Outputs
    - Statistics Window rendered.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

### 3.1.4 File management

- Open game
  - Inputs and validity checks
    - Menu selection “Open game…”.
    - User selects a file previously saved by the game.
  - Exact sequence of operations
    - Open dialog; on user selection, load all game data (current block positions, player statistics) from file.
  - Outputs
    - Board re-drawn per file data; player statistics set per file.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

- Save game
  - Inputs and validity checks
    - Menu selection “Save Game…”.
  - Exact sequence of operations
    - If the game was never saved, perform “Save game as…”.
    - Otherwise, save: current positions of blocks; last 10000 previous positions; number of previous movements; time used by the user.
  - Outputs
    - None specified.
  - Abnormal situations
    - Overflow: Only the last 10000 previous positions are saved.
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

- Save game as
  - Inputs and validity checks
    - Menu selection “Save Game As…”.
  - Exact sequence of operations
    - Open dialog; user chooses a file; save: current positions of blocks; previous positions; number of previous movements; time used by the user.
  - Outputs
    - None specified.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

- Exit
  - Inputs and validity checks
    - Menu selection “Exit”.
  - Exact sequence of operations
    - If the game is not saved, prompt the player to save: choices “Yes” or “No”.
    - If “Yes”: perform “Save”; close main window.
    - If “No”: close main window.
  - Outputs
    - None specified.
  - Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults/failures: [N/A]
    - Error handling/recovery: [N/A]

### 3.1.5 Menus and about

- Game menu
  - Inputs and validity checks
    - Menu selections: “Open game…”, “Save Game…”, “Save Game As…”, “Exit”.
  - Exact sequence of operations
    - Invoke corresponding functions defined above.
  - Outputs
    - Menu closes; subsequent outputs per invoked function.
  - Abnormal situations
    - As per invoked function.

- Action menu
  - Inputs and validity checks
    - Menu selections: “Undo”, “Redo”.
    - Validity: items are unavailable when their associated actions are unavailable.
  - Exact sequence of operations
    - Invoke “Undo” or “Redo”.
  - Outputs
    - Menu closes; board updated.
  - Abnormal situations
    - As per Undo/Redo.

- Statistics menu
  - Inputs and validity checks
    - Menu selections: “Display”, “Erase”.
  - Exact sequence of operations
    - “Display” shows the Statistics Window; “Erase” erases statistics (with error handling on failure).
  - Outputs
    - As above.

- Help menu (About)
  - Inputs and validity checks
    - Menu selection “About”.
  - Exact sequence of operations
    - Display window with text: “Qheadache 1.0 by Jean‑Philippe Brossat jp_brossat@yahoo.fr”.
  - Outputs
    - About window rendered.

### 3.1.6 Responses to abnormal situations (global)

- Overflow
  - Undo/Redo: limited to the last thousand actions; beyond this, actions are unavailable.
  - Save content: only the last 10000 previous positions are saved.
  - Statistics capacity: when already at 10 entries, the entry with the greatest number of block movements is erased upon adding a new one.
  - Other numeric/data overflows: [N/A]
- Communication facilities
  - [N/A]
- Hardware faults and failures
  - [N/A]
- Error handling and recovery
  - Statistics write/erase failures (wrong permissions or disk full): display an error message.
  - Other error conditions: [N/A]

### 3.1.7 Relationship of outputs to inputs and formulas

- Input/output sequences
  - Movement-related inputs (select, move, undo, redo) result in an updated board display.
  - End-of-game input (large square at bottom) results in a finish window, then the Statistics Window.
  - File “Open” input results in board redraw and player statistics set from file.
  - Menu selections dispatch to the corresponding functions and windows as described.
- Formulas and update rules
  - Movement count increments by 1 per block movement.
  - Time is accumulated as the sum of recorded time differences between consecutive movements.

## 3.2 Performance requirements

- Static numerical requirements (Capacity)
  - Simultaneous users: There shall be only one user per machine.
  - Terminals/displays: One local display terminal per instance with a minimum resolution of 800×600 pixels.
  - Undo/redo history: The system shall maintain an undo/redo history for at least 1,000 user actions.
  - Saved-game history depth: A saved game shall include up to 10,000 previous block positions in addition to current positions.
  - Statistics capacity: The game statistics store shall hold up to 10 player entries; each player name shall be limited to 20 characters; each entry shall include number of block movements and elapsed time.
  - Game board data volume: The system shall manage positions for 10 movable blocks on the board.

- Dynamic numerical requirements
  - [N/A]

## 3.3 Usability requirements

- Contexts of use and user profile
  - Users include anyone who wants to play a simple game and can operate a computer; beginning level players may be age 8 and above.
  - No qualification is necessary.
  - Standard input devices: keyboard and mouse (or equivalent pointing/typing devices).
  - Minimum display resolution: 800x600.

- Effectiveness
  - The interface uses menus, graphics, and sounds (sound is not required to play).
  - The system displays the elapsed play time and the number of user actions.
  - Clear game feedback is provided via windows (e.g., Finish Window, Simple Finish Window, Statistic Window, About Window).
  - Movement constraints prevent invalid actions: blocks cannot overlap, cannot leave the game zone, and must respect minimum spacing.
  - Undo and Redo support are provided for up to the last 1000 movements.
  - Measurable effectiveness targets: [N/A]

- Efficiency
  - Menu-driven commands are organized into Game, Action, Statistics, and Help menus, with specified items and order.
  - Menu items are disabled when the associated action is unavailable (e.g., Undo/Redo).
  - Standard dialogs are used for Open, Save, and Save As to reduce user effort.
  - Immediate visual feedback after actions (e.g., new board display after Undo/Redo; window display on relevant events).
  - Measurable efficiency targets: [N/A]

- Satisfaction
  - The game provides a simple, menu-based interface with graphical feedback suitable for beginning users (age 8+).
  - Optional sound; play is not dependent on audio.
  - Measurable satisfaction criteria: [N/A]

- Error prevention and recovery
  - Invalid moves are prevented through board and block constraints.
  - Undo/Redo allow recovery from user errors, up to the last 1000 actions.
  - Exit behavior prompts to save when there are unsaved changes.
  - File operation failures (e.g., wrong permissions, disk full) result in an error message.
  - Menu options are disabled when an action is not available, preventing erroneous invocation.

- Avoidance of harm (including data loss)
  - Prompt on exit prevents unintended loss of unsaved game progress.
  - Statistics file updates report failures to avoid silent data loss.
  - Other harm avoidance requirements: [N/A]

- Accessibility
  - Sound is not required to play, allowing use without audio output.
  - Additional accessibility requirements (e.g., for visual, motor, or cognitive accessibility): [N/A]

## 3.5 Logical database requirements

This section specifies the logical requirements for persistent information managed by the product. In this context, “database” refers to the game’s persistent storage files:
- Statistics file: stores game statistics for up to 10 players.
- Saved game files: store the state of an in-progress game, including history needed for undo/redo.

a) Types of information used by various functions
- Player statistics (used by: End of the game, Finish Window with Statistics, Statistics Window display, Statistics erasing)
  - Player name (up to 20 characters)
  - Number of block movements since the start (non-negative integer)
  - Time used to solve the game (non-negative duration)
- Game statistics collection (used by: End of the game, Finish Window with Statistics, Statistics Window display)
  - Up to 10 player statistics entries
- Saved game state (used by: Open game, Save game, Save game as, Exit)
  - Current positions of all blocks on the board
  - Previous positions of the blocks (history sufficient to support undo/redo; Save Game specifies up to 10000 previous positions)
  - Number of previous movements
  - Time passed in the current game

b) Frequency of use
- Player statistics (in-memory update): on each block movement.
- Statistics file (persistent update): at end of game when the player confirms the Finish Window with Statistics and the score qualifies for recording; read on Statistics Window display; overwritten/cleared on Statistics erasing.
- Saved game files: written when Save game or Save game as is invoked; read when Open game is invoked; may be written on Exit if the user chooses to save.

c) Accessing capabilities
- Statistics file:
  - Read all entries to display statistics.
  - Determine the entry with the greatest number of block movements to decide whether a new score qualifies and which entry to remove when at capacity.
  - Insert a new player statistics entry (or replace the worst when already at 10 entries).
  - Erase all statistics on user request.
- Saved game files:
  - Write the full game state (current positions, previous positions/history, movement count, elapsed time).
  - Read and restore the full game state.
  - Overwrite an existing saved game file when saving to the same filename.

d) Data entities and their relationships
- PlayerStatistics
  - Attributes: Name (≤20 chars), MovementCount, ElapsedTime
- GameStatistics
  - Composition: 0..10 PlayerStatistics entries
  - Relationship: GameStatistics contains PlayerStatistics; replacement policy removes the entry with the greatest MovementCount when at capacity and a new qualifying score is added
- Block
  - Attributes: Type (square x×x, rectangle 2x×x or x×2x, square 2x×2x), Position on board
- BoardState
  - Attributes: Board dimensions (5x by 4x), Margins, Block collection with positions
  - Relationship: BoardState contains Blocks
- MoveHistory
  - Attributes: Ordered list of previous positions of all blocks (up to 10000 previous positions when saved)
  - Relationship: MoveHistory is associated with BoardState and supports Undo/Redo
- SavedGame
  - Composition: BoardState, MoveHistory, MovementCount, ElapsedTime

e) Integrity constraints
- Statistics:
  - Name length must be ≤ 20 characters.
  - GameStatistics must contain at most 10 PlayerStatistics entries.
  - When adding a new entry and 10 entries already exist, the entry with the greatest MovementCount is removed before inserting the new one.
  - MovementCount and ElapsedTime are non-negative.
- Saved game:
  - Block positions must represent a valid board state (no overlap between blocks, all blocks within the 5x by 4x board, minimum separations per gameplay rules).
  - MoveHistory length persists sufficient history to meet undo/redo requirements; Save Game specifies up to 10000 previous positions.
  - MovementCount and ElapsedTime in saved files are consistent with the restored state.
- Error handling:
  - On failed updates due to issues such as permissions or disk full, an error message is displayed; no partial/invalid updates to statistics should be considered successful.

f) Security
- [N/A]

g) Data retention requirements
- Statistics are retained in the statistics file across game sessions and remain until the user erases them via the Statistics erasing function or the file is otherwise deleted.
- Saved game files persist until overwritten by a subsequent save or deleted by the user outside the application.

## 3.6 Design constraints

- Technology and platform
  - The product uses the Qt graphical library.
  - It must run on all operating systems that Qt supports.
  - The software must be portable to the Windows OS.
  - The product runs as a stand-alone application (no communications interfaces required).

- Hardware and I/O
  - Requires a keyboard and a mouse for input; other devices are allowable if they provide equivalent pointing and typing functions.
  - Requires a graphical display with a minimum resolution of 800×600.

- User interface and layout
  - The interface uses menus, graphics, and sounds; sound is not required to play.
  - The main window shall provide a board and a menu bar.
  - Board and block visuals/layout:
    - Board is a rectangular zone, 5x in height and 4x in width; x is between 50 and 100 pixels.
    - Blocks are separated by a margin of 0.1x; a minimum clearance of 0.05x is enforced between blocks during movement.
    - Block set: four square blocks (x by x), four rectangular blocks (2x by x), one block (x by 2x), and one square block (2x by 2x).
    - Board color is black; blocks are yellow.

- Data persistence and files
  - Game state and statistics are stored in local files.
  - The statistics file holds up to 10 player statistics; player name input is limited to 20 characters.
  - Saving must persist: current positions of the blocks, their last 10000 previous positions, the number of previous movements, and the time used to play (as specified for “Save Game”).
  - On file update failures (e.g., wrong permissions or disk full), an error message must be displayed.

- Operational constraints
  - There can be only one user per machine.

- External standards and regulatory requirements
  - [N/A]

## 3.7 Software system attributes

- Reliability: [N/A]
- Availability: [N/A]
- Security: [N/A]
- Maintainability: [N/A]
- Portability:
  - The software must be portable to the Windows operating system.
  - The product uses the Qt graphical library and must run with all operating systems that Qt supports.
  - The runtime environment must provide a graphical display with at least 800x600 resolution; sound is not required to play.

## 3.8 Supporting information

- Sample inputs/outputs and related studies
  - Inputs used by the software:
    - Mouse interactions: left-click down on a block (selection), left-click up on a selected block (deselection), mouse movement during block movement.
    - Menu selections for actions such as Undo, Redo, Open game, Save game, Save game as, Exit, Display statistics, Erase statistics, and About.
    - File selection via dialog boxes for opening/saving games.
    - Text input in the Finish Window with Statistics: player name entered via an edit box limited to 20 characters.
  - Outputs produced by the software:
    - Finish Window with Statistics: displays “You win! Enter your name:” with an OK button; upon confirmation, statistics are recorded and the statistics window is displayed.
    - Simple Finish Window: displays “You win!” with an OK button; upon confirmation, the statistics window is displayed.
    - About Window: displays “Qheadache 1.0 by Jean‑Philippe Brossat jp_brossat@yahoo.fr”.
    - Error messages on statistics file update failures (e.g., wrong permissions or disk full).
    - Updated board display after Undo/Redo and block movements.
  - Data items saved/loaded (no file format specified):
    - Saved game: current positions of blocks, previous positions (up to the last 10000 for Save; “previous positions” for Save As), number of previous movements, and time spent by the user.
    - Statistics file: up to 10 player records, each containing player name, number of block movements, and time used to solve the puzzle; when full, the record with the greatest number of block movements is erased upon adding a new record.
  - Cost analysis studies: [N/A]
  - User surveys: [N/A]

- Supporting/background information for readers
  - Product nature: stand‑alone computerized game with menus, graphics, and sounds; sound is not required to play.
  - Platform and interfaces: uses the Qt graphical library; must run on operating systems supported by Qt; requires keyboard and mouse; minimum display resolution 800×600.
  - Users: anyone able to operate a computer; beginning level from age 8 upward; no qualifications necessary.
  - High-level capabilities: Undo/Redo of actions, time tracking, move counting, score recording and display, game save/load, statistics display and erasure.

- Problem to be solved by the software
  - The game presents a rectangular board (height 5x, width 4x; x between 50 and 100 pixels) containing blocks separated by a 0.1x margin:
    - Four square blocks of side x.
    - Four rectangular blocks of size 2x by x.
    - One rectangular block of size x by 2x.
    - One square “great square” block of side 2x.
  - The user moves blocks without overlap and without exiting the board; the goal is to move the great square to the bottom of the board, at which point the game ends and player statistics are frozen.

- Special packaging instructions (code/media for security, export, initial loading, or other requirements)
  - [N/A]

- Requirement status of the supporting information in this subsection
  - [N/A]

## 4.1 Functions

This section outlines the planned verification methods and approaches for the software functions. The items below mirror the functional requirements to the extent they appear in the original SRS. For each function group, verification is organized by: a) input validity checks; b) exact sequence of operations; c) responses to abnormal situations (overflow; communication facilities; hardware faults and failures; error handling and recovery); d) effect of parameters; and e) relationship of outputs to inputs (I/O sequences; conversions). When a required verification item is not specified by the original SRS, it is marked [N/A].

General verification methods to be applied across all functions:
- Requirements inspection and traceability review: confirm each test case traces to a stated requirement.
- Unit tests: logic for state transitions, counters, timekeeping, file read/write, and menu enable/disable.
- Integration tests: UI event handling with game state, statistics file I/O, undo/redo stack behavior.
- System tests and demonstrations: end-to-end scenarios from start to finish, including save/load and statistics workflows.
- Negative tests: invalid inputs, disabled actions, and file system failures where specified.
- Cross-platform smoke tests on at least one OS supported by Qt; display at 800×600 or higher; verification that sound is not required to play.

1) External interfaces and main window (original: 3.1 External Interfaces; 3.1.1 User Interfaces; 3.1.1.2 Main window)
- a) Validity checks:
  - Verify application accepts input from mouse and keyboard; confirm alternate pointing devices perform cursor movement and selection equivalently.
  - Verify UI renders at ≥800×600; confirm main window contains both a board and a menu bar.
- b) Sequence:
  - Start application → main window shows board and menu bar.
- c) Abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: [N/A]
- d) Parameters:
  - Verify application runs without sound; confirm no blocking dialogs or errors due to missing sound capability.
- e) Outputs vs inputs:
  - Selecting menus triggers corresponding actions as specified; verify About dialog text matches requirement.

2) Board presentation and block actions (original: 3.2.1 Actions; 3.2.1.1–3.2.1.4)
- a) Validity checks:
  - Board geometry: with unit x in [50, 100] px, validate board size = 5x by 4x; margins 0.1x between blocks; min proximity 0.05x enforced during movement; colors: board black, blocks yellow.
  - Block inventory: verify 4 square blocks (x×x), 4 rectangles (2x×x), 1 rectangle (x×2x), 1 square (2x×2x).
  - Selection accepts only left-click-down on a block; selection outside blocks does not change state.
  - Movement constrained: no overlap, no exit from board; min 0.05x spacing enforced.
- b) Sequence:
  - Left-click-down on a block → state becomes “Block movement” → mouse moves → block follows the mouse under constraints → left-click-up on selected block → state becomes “Block selection”.
- c) Abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: movement attempts causing overlap or boundary violation are rejected; verify block remains at last valid position and no state corruption occurs; selection attempts on empty board area have no effect.
- d) Parameters:
  - Verify multiple values of x (min, mid, max) scale board, blocks, margins correctly, including rounding behavior at pixel boundaries.
- e) Outputs vs inputs:
  - For a given mouse path during “Block movement,” observed block trajectory equals constrained path; after deselection, board redraw reflects final valid block positions.

3) Undo and redo (original: 3.2.1.5–3.2.1.6; 2.2.1)
- a) Validity checks:
  - Undo/Redo menu entries enabled only when available (Undo requires ≥1 previous movement; Redo requires the previous action was Undo).
  - Depth: user can undo/redo the last 1000 actions.
- b) Sequence:
  - Perform N movements → select Undo once → board shows positions from immediately before last movement; repeat Undo up to 1000 times; then Redo available in sequence until latest state is restored.
- c) Abnormal situations:
  - Overflow: after >1000 movements, verify only the last 1000 are undoable and no error occurs; attempting additional Undos beyond available history leaves state unchanged and the menu disabled.
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: verify Redo is unavailable unless directly preceded by Undo; selecting a disabled menu item has no effect.
- d) Parameters:
  - History depth parameter is fixed by requirement; verify persistence handling during Save/Load per file management (see item 5).
- e) Outputs vs inputs:
  - Each Undo/Redo produces the board display corresponding to the expected prior/subsequent snapshot; Undo/Redo count as movements for statistics per requirement.

4) End of game (original: 3.2.2.1–3.2.2.3)
- a) Validity checks:
  - Detect end condition when the great 2x×2x square is moved to the bottom of the board; verify detection only when fully at bottom within constraints.
  - Upon game end, freeze all player statistics.
- b) Sequence:
  - End detected → choose window: if current movement count is lower than the highest movement count in statistics file, show “Finish Window with Statistics”; otherwise show “Simple Finish Window.”
  - For Finish with Statistics: user enters name (≤20 chars) → clicks OK → record stats → close finish window → display statistics window.
  - For Simple Finish: user clicks OK → close finish window → display statistics window.
- c) Abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: verify no multiple end-of-game triggers; verify finish windows do not accept further moves.
- d) Parameters:
  - Name input limited to 20 characters; verify input control enforces limit.
- e) Outputs vs inputs:
  - Correct window variant displayed based on comparison with file contents; recorded stats equal frozen in-game stats; statistics window opens after finish window closes.

5) Statistics management and display (original: 3.2.3.1–3.2.3.4; 2.2.2–2.2.5)
- a) Validity checks:
  - On each movement, movement counter increments by 1; time accumulator records elapsed time since last record.
  - Game statistics composed of at most 10 player entries; when adding a new entry to a full file, remove the entry with the greatest movement count.
  - Erase operation removes all statistics.
  - Statistics window shows 10-line list (or fewer if fewer entries), each line with name, movement count, and time.
- b) Sequence:
  - Movement occurs → update counters; End with statistics → write entry → optionally prune worst entry → display statistics window; Erase via menu → clear file → subsequent display shows empty list.
- c) Abnormal situations:
  - Overflow: verify movement count and time accumulation remain within data type limits during long sessions; [N/A] if limits not specified.
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: on file update failure (wrong permissions, disk full), an error message is displayed; verify no partial writes corrupt existing file; verify user is informed.
- d) Parameters:
  - Time measurement resolution and format are not specified; [N/A]
- e) Outputs vs inputs:
  - After k movements, displayed movement count equals k; time displayed equals cumulative elapsed time; statistics window reflects exact file contents; after Erase, display shows no entries.

6) File management (original: 3.2.4.1–3.2.4.4)
- a) Validity checks:
  - Open: dialog opens; selecting a valid save file loads current positions, last 10000 previous positions, movement count, and elapsed time.
  - Save: if never saved, behaves as Save As; otherwise writes current positions, last 10000 previous positions, movement count, and time to the previously chosen file.
  - Save As: dialog opens; chosen file receives the current positions, previous positions, movement count, and time.
  - Exit: if game not saved, prompt Yes/No; Yes triggers Save then closes; No closes without saving.
- b) Sequence:
  - Invoke menu item → system dialog (Open/Save As) → file operation → board redraw and statistics set (for Open) or no UI change (for Save/Save As) → Exit logic follows prompt branch.
- c) Abnormal situations:
  - Overflow: verify storing/updating last 10000 previous positions does not exceed allocated structures; behavior when more than 10000 positions exist is implementation-defined; [N/A]
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: on write failure (permissions/disk full), show error message as specified; read/format errors on Open are not specified; [N/A]
- d) Parameters:
  - Undo/redo storage depth for saving previous positions is 10000; verify persistence matches specification even if interactive undo/redo depth is 1000.
- e) Outputs vs inputs:
  - After Open, board and statistics match exactly the loaded file data; after Save/Save As, subsequent Open reproduces the same state; Exit behaves per user choice.

7) Menu bar functions (original: 3.2.5.1–3.2.5.4)
- a) Validity checks:
  - Verify menu structure and ordering:
    - Game: Open game…, Save Game…, Save Game As…, Exit.
    - Action: Undo, Redo; disabled when unavailable.
    - Statistics: Display, Erase.
    - Help: About.
- b) Sequence:
  - Selecting a menu item invokes the mapped action exactly as referenced in the requirements.
- c) Abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: selecting disabled items has no effect; menus close after selection.
- d) Parameters:
  - [N/A]
- e) Outputs vs inputs:
  - For each selection, verify the specific action’s observable effects occur (e.g., dialogs open, board updates, statistics display), and the menu closes.

8) Performance and single-user constraint affecting functions (original: 3.3 Performance Requirements)
- a) Validity checks:
  - Verify only one player session per machine instance; no multi-user concurrency implied by requirements.
- b) Sequence:
  - [N/A]
- c) Abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: [N/A]
- d) Parameters:
  - [N/A]
- e) Outputs vs inputs:
  - [N/A]

9) Portability affecting functional verification (original: 3.4 Software System Attributes)
- a) Validity checks:
  - Run-time verification on a Windows OS; verify functional parity with a Qt-supported OS per requirement to run where Qt supports; scope limited by SRS to portability to Windows.
- b) Sequence:
  - [N/A]
- c) Abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults/failures: [N/A]
  - Error handling/recovery: [N/A]
- d) Parameters:
  - [N/A]
- e) Outputs vs inputs:
  - [N/A]

## 4.2 Performance requirements

This section defines the verification activities to demonstrate compliance with the software performance requirements.

- Number of simultaneous users to be supported: exactly one user per machine
  - Verification method:
    - Design/implementation review: Confirm the application is a stand-alone desktop program with no networking or multi-terminal features and relies on a single local keyboard/mouse and display.
    - Dynamic test: On a single machine, attempt concurrent operation by two users (e.g., launch multiple instances and/or access via a second OS session/remote desktop). Observe whether the software provides any mechanism to support concurrent multi-user interaction.
  - Acceptance criteria:
    - The software provides no capability for concurrent multi-user interaction on a single machine.
    - Only one human operator can interact with the running application at a time via the local input devices; no secondary terminals or remote clients are supported.
  - Evidence to collect:
    - Review record of build/configuration showing no networking or multi-terminal capabilities.
    - Test log with steps, observations, and screenshots demonstrating lack of concurrent multi-user operation.

- Transaction/response time limits: [N/A]
- Throughput under normal and peak load: [N/A]
- Data volume/capacity limits (e.g., amount and type of information to be handled): [N/A]
- Resource utilization limits (CPU, memory, storage, I/O): [N/A]
- Startup/shutdown time limits: [N/A]
- Availability/reliability performance targets: [N/A]

## 4.3 Usability requirements

- Basic operability by novice users (no qualifications; beginning players from age 8)
  - Verification method: Task-based usability test with representative novice users (including beginning-level players age 8+). Core tasks: start game, select/move/deselect blocks, undo/redo, save, open, finish game and enter name, view/erase statistics, exit.
  - Evidence: Observed task completion without assistance and defect/issue log.

- Menu structure and discoverability (names, order, availability)
  - Scope: Game, Action, Statistics, Help menus; item order; disabling of Undo/Redo when unavailable.
  - Verification method: UI inspection against specified item names and order; functional test that each menu item invokes the specified action; verify disabled state logic for Undo/Redo.
  - Evidence: Checklist and screenshots.

- Dialogs and windows content correctness and clarity
  - Scope: Finish Window with Statistics, Simple Finish Window, Statistics Window, About window.
  - Verification method: UI inspection of exact texts, controls, and behaviors by invoking end-of-game scenarios and menu selections.
  - Evidence: Screenshots and pass/fail checklist per window.

- Visibility and usability at minimum display configuration
  - Scope: 800×600 screen; board and menu visibility; board sizing rules; colors (black board, yellow blocks); spacing constraints during movement.
  - Verification method: Run-time visual inspection at 800×600; measure board and block dimensions per x constraints; observe block movement respecting spacing and bounds.
  - Evidence: Measurements, screenshots, and observation notes.

- Input device usability and independence from sound
  - Scope: Keyboard for text entry (e.g., player name), mouse for selection/movement; playability without sound.
  - Verification method: Functional tests performing all interactions with standard keyboard and mouse; repeat key scenarios with system audio muted to confirm no dependency on audio cues.
  - Evidence: Test logs and observation notes.

- Error messaging visibility for file/statistics operations
  - Scope: Error messages on statistics update failures (permissions, disk full); unsaved-changes prompt on Exit.
  - Verification method: Fault injection (e.g., remove write permissions, fill disk), attempt save/statistics operations, attempt Exit with unsaved changes; verify required messages and flows are presented.
  - Evidence: Screenshots and test logs.

- Statistics visibility and comprehension
  - Scope: Statistics window shows up to 10 entries; each line includes player name, movement count, and time; shown after game end and on menu request.
  - Verification method: Populate statistics via gameplay and via Finish Window with Statistics; open Statistics window via menu and post-game; verify format and contents.
  - Evidence: Screenshots and checklist.

- Measurable effectiveness criteria
  - [N/A]

- Measurable efficiency criteria (e.g., time on task)
  - [N/A]

- Measurable satisfaction criteria (e.g., user ratings)
  - [N/A]

- Avoidance of harm in context of use
  - [N/A]

## 4.5 Logical database requirements

This section defines the verification approaches and methods for the software’s logical data persisted in files, aligned with the information items a)–g). The product uses file-based storage only: a statistics file holding up to 10 player statistics, and saved-game files holding current and historical block positions plus player statistics.

- a) Types of information used by various functions
  - Covered data
    - Statistics file: player name (entered via a 20-character edit box), number of block movements, elapsed time used to solve the game.
    - Saved-game file: current positions of all blocks, their last 10000 previous positions, number of previous movements, elapsed time.
  - Verification methods
    - Requirements/design review to confirm the above fields are the only persisted data.
    - Unit tests for serialization/deserialization of:
      - Statistics entries: name (≤20 chars), movement count, elapsed time.
      - Saved-game content: positions (current + up to 10000 history), movement count, elapsed time.
    - System tests:
      - Finish game → confirm statistics written; open Statistics Window to verify values displayed match the just-finished session.
      - Save game → Open game → verify board state and player statistics match the saved session.

- b) Frequency of use
  - Events causing persistence
    - Statistics written when the Finish Window with Statistics is confirmed by the player.
    - Statistics erased via menu selection.
    - Game saved via “Save Game …”, “Save Game As …”, or upon Exit when user chooses to save.
    - Game opened via “Open game …”.
  - Verification methods
    - Scenario-based system tests for each event to confirm exactly one corresponding file operation occurs.
    - Negative tests to confirm no statistics are written if the Finish Window with Statistics is not confirmed. 
    - Repeated operations (e.g., multiple saves in sequence) to verify consistent behavior.

- c) Accessing capabilities
  - Required capabilities
    - Read statistics from file for display in the Statistics Window (10-line list).
    - Append/replace statistics on game completion (subject to capacity rule).
    - Erase all statistics via menu.
    - Read/write saved games via dialogs; re-draw board and set player statistics on open.
    - Display error messages on file update failures (e.g., wrong permissions, disk full).
  - Verification methods
    - Integration tests exercising read, write, and erase through the UI menus and dialogs.
    - Fault-injection tests:
      - Attempt write in read-only directory → verify error message.
      - Simulate disk full during write → verify error message.
    - Usability checks that dialogs appear as specified and operations complete.

- d) Data entities and their relationships
  - Entities/relationships
    - Statistics: a collection (max 10) of player statistics entries used by the Statistics Window.
    - Saved game: a single file encapsulating board state, movement history (up to 10000 prior positions), and player statistics.
    - Relationship: Finishing a game and confirming the Finish Window with Statistics appends/updates the statistics file; the Statistics Window displays entries read from that file.
  - Verification methods
    - End-to-end test: finish a game with valid data → confirm the new entry appears in the Statistics Window.
    - Save, then open the same file → confirm board re-draw matches saved state and player statistics are restored.
    - Cross-check that the Statistics Window reads from persistent storage (modify stats file externally to a known state, if supported by test harness, and verify UI reflects it). [N/A] if external modification is not supported.

- e) Integrity constraints
  - Constraints to verify
    - Player name length limited to 20 characters (via edit box).
    - Statistics file holds at most 10 entries; when full, the entry with the greatest number of block movements is erased upon adding a new one.
    - Movement count and elapsed time are non-negative and consistent with in-game counters.
    - Saved-game includes up to 10000 previous positions.
  - Verification methods
    - Boundary tests:
      - Name lengths: 0, 1, 20, and >20 via UI to confirm >20 cannot be entered/saved.
      - Statistics capacity: populate 10 entries; add an 11th with a lower movement count; verify deletion of the entry with the greatest movement count.
      - Ties in “greatest number of block movements”: expected behavior is unspecified. [N/A]
      - Saved-game history size: create sessions with various movement counts (including >10000); save; reopen; verify that no more than 10000 previous positions are persisted. Behavior of undo/redo after load is unspecified. [N/A]
    - Consistency checks: compare movement count and elapsed time in files vs. UI displays after load.

- f) Security
  - Relevant requirements
    - On failures such as wrong permissions or disk full, an error message is displayed.
    - No authentication, authorization, or encryption requirements are specified. [N/A]
  - Verification methods
    - Fault-injection tests for permission errors and disk-full conditions to verify error messages are shown and no partial/invalid files are left behind (as observable via subsequent loads).
    - Security controls (access control, encryption, integrity signatures) are not applicable. [N/A]

- g) Data retention requirements
  - Retention behavior
    - Statistics persist across runs until erased by the user or displaced when capacity (10) is exceeded (removing the entry with greatest movements).
    - Saved games persist until overwritten or deleted by the user outside the application. No time-based retention is specified. [N/A]
  - Verification methods
    - Restart application after creating statistics and saved games → verify data persists and is readable.
    - Capacity behavior test (as in e) to verify displacement rule.
    - No verification for time-based archival/purge as it is not specified. [N/A]

## 4.6 Design constraints

The following verification methods will be used to confirm compliance with the design constraints defined in Requirements 3.6 (as derived from the original SRS).

- Use of Qt graphical library (orig. 2.1.3)
  - Architecture and code review to confirm use of Qt APIs for UI.
  - Build inspection to ensure binaries link against Qt libraries.
  - Runtime dependency check to verify Qt libraries are loaded.

- Supported operating systems and portability (orig. 2.1.3, 3.4)
  - Portability/build certification on each operating system supported by Qt that is in the project’s test matrix.
  - Smoke tests on each OS: application launches, main window renders, basic input works (menu navigation, block selection/movement).
  - Windows-specific build and run verification to confirm portability to Windows OS.

- Stand-alone operation / no communications interfaces (orig. 2.1.1, 2.1.4, 3.1.3)
  - Functional tests with all network interfaces disabled; confirm full gameplay is possible.
  - Static analysis/code review to verify no networking APIs are referenced.
  - Runtime monitoring to confirm no network sockets are opened.

- Input devices: keyboard and mouse; allowance for similar devices (orig. 2.1.2, 3.1)
  - Functional tests using a standard keyboard and mouse for all UI operations (menus, entering name, block selection/movement).
  - Compatibility test with an alternative pointing device that provides cursor movement and clicking to confirm equivalent operation.

- Display constraints: minimum 800×600 resolution (orig. 2.1.2, 3.1)
  - Execution on a display set to 800×600 to confirm that all UI elements are visible and usable without clipping.
  - Visual inspection to ensure layout remains usable at the minimum resolution.

- UI composition: menus, graphics, sounds; sound not required (orig. 2.1.1, 3.1)
  - UI inspection to verify presence of menus and graphical interface.
  - Functional gameplay test with system audio disabled/unavailable to confirm playability without sound.

- Board visuals and geometry (orig. 3.2.1.1)
  - UI inspection to confirm board is black and blocks are yellow.
  - Measurement-based UI test (pixel-based or scaled-unit check) to confirm:
    - Board aspect (height 5x, width 4x; x in [50, 100] pixels).
    - Block sizes and margins match specified multiples of x.

- “About” window content (orig. 3.2.5.4.3)
  - UI inspection to verify the About dialog displays the exact specified text.

## 4.7 Software system attributes

This subsection identifies the verification approaches and methods to qualify the software against the Software System Attributes defined in the Requirements section (3.7).

- Reliability
  - [N/A]

- Availability
  - [N/A]

- Security
  - [N/A]

- Maintainability
  - [N/A]

- Portability
  - Requirements basis:
    - 3.4 Software System Attributes: “The software must be portable to the Windows OS.”
    - 2.1.3 Software Interfaces: “The product uses the Qt graphical library. It must run with all the operating systems that Qt supports.”
  - Verification methods:
    - Build verification:
      - Confirm the product compiles and links using the Qt toolchain for the target OS without source changes or conditional host-dependent code beyond what Qt requires.
    - Installation verification:
      - Install the built artifacts on the target OS and verify all runtime dependencies are satisfied.
    - Execution and environment checks:
      - Launch the application and reach the main window.
      - Verify correct operation with a keyboard and mouse and on a graphical display with at least 800×600 resolution.
      - Verify the application operates when sound output is unavailable, as sound is not required to play.
    - Functional smoke/regression on target OS:
      - Board rendering and block interaction: select, move (respecting boundaries and spacing), deselect.
      - Undo/Redo up to the specified depth; verify enable/disable states in menus.
      - End-of-game handling and display of the appropriate finish window variants.
      - Statistics: live counting of moves and time; display window; erase operation; error handling for file I/O failures.
      - File management: Open, Save, Save As; confirm that saved games reload with board state, history, move count, and elapsed time preserved.
      - Menu bar operations: Game, Action, Statistics, Help (About).
    - Cross-OS portability via Qt (as applicable):
      - For each operating system supported by the targeted Qt version, repeat the build, installation, execution checks, and a representative functional smoke test to confirm the application runs without modification.
    - Data compatibility:
      - On each tested OS, create save files and verify they can be reopened on the same OS build. If cross-OS portability is in scope via Qt support, optionally confirm that save files created on one OS can be opened on another.
    - Evidence:
      - Build logs, installation logs, test execution logs, and pass/fail summaries; screenshots of the main and About windows; defect reports and resolutions (if any).
  - Acceptance criteria:
    - Application builds and installs on Windows OS (and on each Qt-supported OS in scope) without source changes.
    - Application launches and all exercised functions above pass on the target OS.
    - No OS-specific crashes or missing-dependency errors occur.
    - UI renders correctly at 800×600 or higher; keyboard and mouse input function as specified.
    - Operation is not blocked by absence of sound output.

## 5.1 Assumptions and dependencies

- Availability of the Qt graphical library on the target platform and use of an operating system supported by Qt.
- A graphical desktop environment is available with a display resolution of at least 800×600 pixels.
- Standard input devices are available: a keyboard and a mouse, or equivalent pointing and typing devices that provide the same functions.
- A color display is available (the board and blocks use distinct colors); absence of a sound device does not affect gameplay or compliance.
- The operating system provides reliable timers/clock services to measure elapsed play time.
- Local persistent storage (file system) is available with sufficient free space and appropriate permissions to create, read, write, and delete the statistics file and saved-game files.
- Only one user/session will use the game on a machine at a time; concurrent access to the statistics file is not expected.
- Sufficient system memory is available to support undo/redo history (up to the specified limits) and to store prior block positions for saved games.
- No network connectivity or external services are required for any functionality described.
- Alternative pointing/input devices, if used, generate interactions equivalent to mouse and keyboard operations as assumed by the UI.

## 5.2 Acronyms and abbreviations

- SRS — Software Requirements Specification
- OS — Operating System
- Qt — Cross-platform application framework/library used by the product
- OK — Button label indicating user acknowledgement or confirmation