## 1.1 Purpose

The purpose of Qheadache is to provide a standalone block-sliding puzzle game in which users solve a specific “headache” by moving blocks on a board. The software enables gameplay with undo/redo, counts and displays time and move totals, records player scores associated with names, displays score lists, and supports saving/loading games and managing statistics.

This SRS establishes the requirements for Qheadache and is intended for its analysts, programmers, and testers.

## 1.2 Scope

This SRS defines the Qheadache software product, a stand-alone, menu-driven puzzle game application built with the Qt graphical library.

- Product identification
  - Qheadache Game Application (stand-alone GUI software).

- What the product will do
  - Present a graphical puzzle board where the user selects and moves blocks within defined constraints, without overlap and within the board boundary.
  - Detect game completion when the large square reaches the bottom of the board and display the appropriate finish window.
  - Track and display elapsed play time and the number of user actions (block movements).
  - Provide Undo and Redo of the last 1,000 actions.
  - Manage player statistics: record player name, move count, and time; maintain up to 10 records; display statistics; allow erasing all statistics; report errors if saving fails.
  - Support file operations: open a previously saved game; save/save as the current game, including current block positions and their history (up to 10,000 previous positions), move count, and elapsed time; prompt to save on exit if needed.
  - Offer a menu bar (Game, Action, Statistics, Help) and an About window; operate with keyboard and mouse; use graphics and optional sound.

- Application, benefits, objectives, and goals
  - Application domain: casual, single-user block-sliding puzzle for users with basic computer skills (beginning at age 8 through adult).
  - Objectives and goals:
    - Provide an easy-to-use, portable, stand-alone puzzle game with minimal hardware needs (keyboard, mouse, display ≥ 800×600).
    - Enable users to measure and compare their performance (time and move count) across plays via on-screen statistics.
    - Support reliable undo/redo and the ability to pause and resume via save/open.
    - Run on operating systems supported by Qt; portability to Windows is required.
  - Benefits:
    - Entertainment and practice in problem-solving.
    - Persistent tracking of personal performance over time.

- Consistency with higher-level specifications
  - [N/A] No higher-level system specifications are referenced.

### 1.3.1 Product perspective

Qheadache is a stand-alone desktop game application. It does not form part of a larger system. It interacts directly with the end user via a graphical user interface and relies on the operating system and the Qt graphical library for windowing, input, rendering, and file I/O.

Relationship to other products
- Stand-alone application; no dependencies on or integrations with other application systems are required beyond the operating system and the Qt graphical library.
- No shared databases or data exchanges with external systems are defined.

Larger system context
- The product is not an element of a larger system. [N/A]

Interfaces with a larger system
- [N/A]

#### System interfaces
- Operating system services
  - Purpose: Provide windowing, event/message handling, and file system access required for user interaction and save/open features.
  - Functionality supported: GUI display, keyboard/mouse input handling, file dialogs and file I/O for game save/open.
  - Interface description: Standard OS windowing and file I/O services as exposed via the Qt framework. Specific OS APIs, message formats, and protocols are not specified in this SRS. [N/A]

#### User interfaces
- General
  - Graphical user interface with menus, graphics, and optional sounds.
  - Single main window containing:
    - Game board (block-movement play area).
    - Menu bar with Game, Action, Statistics, and Help menus.
  - Additional windows:
    - Finish Window with Statistics (name entry and OK).
    - Simple Finish Window (OK).
    - Statistics Window (list of up to 10 player records).
    - About Window.
- Interaction characteristics
  - Input devices: mouse (point, click, drag), keyboard for typing player names.
  - Menu items enable/disable according to action availability (e.g., Undo/Redo).
- UI style guide
  - [N/A]

#### Hardware interfaces
- Input devices
  - Keyboard and mouse required; other pointing/input devices acceptable if they provide equivalent cursor movement and text entry.
- Display
  - Graphical display with minimum resolution of 800×600.
- Audio
  - Sound output optional; not required to play.
- Configuration characteristics
  - Specific ports, buses, or instruction sets are not defined in this SRS. [N/A]

#### Software interfaces
- Qt graphical library
  - Name: Qt graphical library
  - Mnemonic: [N/A]
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: Provides cross-platform GUI, windowing, input, rendering, and access to OS services (e.g., file dialogs) used by Qheadache.
  - Interface definition: Standard Qt APIs; detailed interface definitions are documented by Qt. [N/A]
- Operating systems
  - Platforms: Must run on operating systems supported by Qt; portability to Windows OS is required.
  - Interface definition: Standard OS services accessed via Qt abstractions. Detailed OS interface specifications are not provided here. [N/A]
- Other application systems
  - None. No interfaces to external business or application systems are defined.

#### Communications interfaces
- No network or interprocess communications are required. [N/A]

#### Memory constraints
- No primary or secondary memory limits are specified. [N/A]

#### Operations
- Modes of operation
  - User-initiated, interactive gameplay mode; single-user per machine.
- Periods of operation
  - Entirely interactive; no unattended or background processing is specified.
- Data processing support functions
  - Save game, Save As, Open game, Exit with prompt to save if unsaved changes exist.
- Backup and recovery operations
  - [N/A]

#### Site adaptation requirements
- No site-specific data, initialization sequences, or deployment adaptations are specified. [N/A]

#### Interfaces with services
- No interactions with external services (e.g., cloud or SaaS) are specified. [N/A]

### 1.3.2 Product functions

The product provides the following major functions:

- Puzzle play
  - Present a rectangular board populated with predefined blocks.
  - Allow users to select, move, and deselect blocks subject to spacing, boundary, and non-overlap rules.
  - Detect game completion when the large square block is moved to the bottom of the board; freeze player statistics and display the appropriate finish window.

- Action history management
  - Undo and redo recent block movements (availability governed by prior actions; undo/redo are treated as movements).

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

- Scores and statistics
  - On game completion, capture player name with the recorded time and move count when qualifying.
  - Maintain up to 10 player statistics (name, move count, elapsed time), replacing the worst record when full.
  - Display the statistics window listing stored records.
  - Erase all stored statistics on request.
  - Notify the user if statistics cannot be updated due to issues such as insufficient permissions or disk space.

- File operations
  - Open a previously saved game to restore the board and player statistics.
  - Save the current game, including the board state and sufficient action history to support undo/redo requirements.
  - Save the current game under a new file name.
  - Exit the application, prompting to save if there are unsaved changes.

- Menus and help
  - Provide a menu bar with Game (Open, Save, Save As, Exit), Action (Undo, Redo), Statistics (Display, Erase), and Help (About) options.
  - Display an About window with product and author information.

Representative user scenarios:

- Solve the puzzle: Move blocks under the defined constraints, using undo/redo as needed, until the win condition is met.
- Record and review results: Upon winning, enter a name (when eligible), then view the statistics window; optionally erase all statistics.
- Manage games: Save progress, open a saved game, or exit with an option to save unsaved work.

### 1.3.3 User characteristics

- Intended user groups: Anyone who wants to play a simple game.
- Age range: Beginning level players from age 8 through adults.
- Educational level: No qualification is necessary.
- Experience with games: Suitable for beginners through advanced players.
- Technical expertise: Users know how to operate a computer, use a mouse and keyboard, select menu items, and type a name.
- Disabilities and accessibility: [N/A]
  - Note: Sound is not required to play.

### 1.3.4 Limitations

- Regulatory requirements and policies: [N/A]
- Hardware limitations:
  - Requires a keyboard and a mouse (or equivalent pointing/typing devices).
  - Requires a graphical display with a minimum resolution of 800×600.
  - Sound is optional; the game must function without sound.
  - Only one user per machine.
- Interfaces to other applications:
  - Depends on the Qt graphical library; must run on operating systems supported by Qt.
  - Stand-alone application; communications interfaces are not applicable.
  - Uses the local file system for saving/loading games and statistics; operation may be limited by file permissions or disk space.
- Parallel operation: Single-user only; no concurrent multi-user operation specified.
- Audit functions: [N/A]
- Control functions: [N/A]
- Higher-order language requirements: [N/A]
- Signal handshake protocols (e.g., XON–XOFF, ACK–NACK): [N/A]
- Quality requirements:
  - Portability: Must be portable to the Windows OS and run on operating systems supported by Qt.
  - Reliability/availability targets: [N/A]
- Criticality of the application: [N/A]
- Safety and security considerations: [N/A]
- Physical/mental considerations: No qualification is necessary; users include beginners from age 8 through adults.
- Limitations sourced from other systems (including real-time requirements through interfaces): [N/A]

## 1.4 Definitions

- Board: The rectangular game area where the user moves blocks; height 5x, width 4x, black background.

- x (measurement unit): The base size unit for the board and blocks; 50–100 pixels inclusive.

- Blocks: Yellow pieces placed on the board, consisting of four x-by-x squares, four 2x-by-x rectangles, one x-by-2x rectangle, and one 2x-by-2x square.

- Great square: The 2x-by-2x square block referenced in end-of-game detection.

- Margin (0.1x): The fixed separation between blocks while placed on the board.

- Minimum clearance (0.05x): The minimum distance a moving block must maintain from other blocks.

- Game state: Named modes of operation used by the game logic, including “Block selection” and “Block movement” (also referred to as “Block deplacement”).

- Block selection: The state entered when the user presses the left mouse button down on a block.

- Block deselection: The action of releasing the left mouse button on a selected block; returns the game to the “Block selection” state.

- Block movement (Block deplacement): The state during which the selected block follows mouse movement without overlapping other blocks, without leaving the board, and while maintaining at least 0.05x clearance.

- Undo action: Cancels the last movement; counts as a movement; unavailable if no previous movement exists.

- Redo action: Reapplies the last movement that was undone; counts as a movement; unavailable unless the previous action was an Undo.

- End of the game: Occurs when the great square is moved to the bottom of the board; player statistics are frozen; a finish window is then displayed based on recorded statistics.

- Finish Window with Statistics: A window shown on game completion (subject to statistics criteria) containing the text “You win ! Enter your name :”, a 20-character edit box, and an OK button; on OK, the player’s statistics are recorded and the Statistic Window is displayed.

- Simple Finish Window: A window shown on game completion containing “You win !” and an OK button; on OK, the window closes and the Statistic Window is displayed.

- Player statistics: The number of block movements since the start and the time since the start, recorded during play.

- Game statistics: Up to 10 player statistics stored by the game; when full, the entry with the greatest number of block movements is replaced by a new qualifying result.

- Statistic file: The persistent storage for game statistics; updated on completion via the Finish Window with Statistics; errors (e.g., permissions, disk full) result in an error message; can be erased via menu.

- Statistic Window: A window that displays up to 10 lines read from the statistic file; each line shows player name, number of block movements, and time to solve the puzzle.

- Open game: Loads a previously saved game from a selected file, restoring the board and player statistics from that file.

- Save game: Saves the current game; if the game was never saved, behaves like Save game as; otherwise saves to the existing file the current positions of the blocks, their last 10,000 previous positions, the number of previous movements, and the time passed.

- Save game as: Saves the current game to a user-selected file, including current block positions, previous positions, number of previous movements, and time passed.

- About Window: A window displaying the text “Qheadache 1.0 by Jean‑Philippe Brossat jp_brossat@yahoo.fr”.

- Score: The recorded time and number of counts (actions) of a play associated with the user’s name.

- Score windows: A window that displays all the player’s scores.

# 2 References

## Compliance
[N/A]

## Guidance
[N/A]

## 3.1 Functions

### 3.1.1 Game board setup and geometry
- Inputs:
  - Application start.
- Validity checks on inputs:
  - The unit x must be within 50 ≤ x ≤ 100 pixels.
- Exact sequence of operations:
  - Initialize a rectangular board of height 5x and width 4x, black background.
  - Place blocks (yellow) with 0.1x margins initially:
    - Four square blocks of size x by x.
    - Four rectangular blocks of size 2x by x.
    - One block of size x by 2x.
    - One square block of size 2x by 2x.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - The unit x defines all block sizes and minimum separations; visual spacing and collision constraints scale with x.
- Relationship of outputs to inputs:
  - Input/output sequences: On initialization, the board and blocks are rendered once to the display.
  - Formulas for conversion: Block dimensions and separations are computed as multiples of x; minimum separation while moving is 0.05x; inter-block margins are 0.1x.

### 3.1.2 Block selection
- Inputs:
  - Left-click down on a block.
- Validity checks on inputs:
  - Pointer location must intersect a block to select it.
- Exact sequence of operations:
  - On left-click down intersecting a block, set the game state to “Block movement”.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Selection changes internal state; no visual output is required beyond potential highlight/selection (not specified).
  - Formulas for conversion: [N/A]

### 3.1.3 Block deselection
- Inputs:
  - Left-click up on a selected block.
- Validity checks on inputs:
  - A block must currently be selected.
- Exact sequence of operations:
  - On left-click up, set the game state to “Block selection”.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Internal state updated; no explicit output specified.
  - Formulas for conversion: [N/A]

### 3.1.4 Block movement
- Inputs:
  - Mouse movement while in “Block movement” state.
- Validity checks on inputs:
  - Movement must keep the selected block within the board.
  - Movement must avoid overlap with other blocks.
  - The selected block must maintain at least 0.05x distance from other blocks.
- Exact sequence of operations:
  - Track mouse delta while pressed; attempt to translate the selected block by the same delta.
  - Constrain translation to avoid leaving the board, overlapping other blocks, or violating the 0.05x minimum separation.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: Movement is clamped to the nearest allowed position within constraints.
- Effect of parameters:
  - x determines the board size, block sizes, and separation thresholds.
- Relationship of outputs to inputs:
  - Input/output sequences: For each accepted mouse movement, redraw the board to reflect the block’s new position.
  - Formulas for conversion: New block position = constrained(mouse-driven position) where constraints enforce board bounds and ≥0.05x separation.

### 3.1.5 Undo action
- Inputs:
  - Menu selection “Undo”.
- Validity checks on inputs:
  - “Undo” is unavailable if there is no previous movement.
- Exact sequence of operations:
  - Restore block positions to the state prior to the last movement.
  - Count the undo as a movement.
  - Update undo/redo availability accordingly.
- Responses to abnormal situations:
  - Overflow: Undo history depth is limited to the last 1000 actions; older actions are not available for undo.
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: If no undoable action exists, keep menu item disabled.
- Effect of parameters:
  - Undo history depth = 1000 actions.
- Relationship of outputs to inputs:
  - Input/output sequences: Menu selection → state restore → board redraw.
  - Formulas for conversion: [N/A]

### 3.1.6 Redo action
- Inputs:
  - Menu selection “Redo”.
- Validity checks on inputs:
  - “Redo” is unavailable if the previous action was not an “Undo”.
- Exact sequence of operations:
  - Restore block positions to the state before the last undo (i.e., reapply the undone movement).
  - Count the redo as a movement.
- Responses to abnormal situations:
  - Overflow: Redo history depth is limited to the last 1000 actions; older actions are not available for redo.
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: If redo is not applicable, keep menu item disabled.
- Effect of parameters:
  - Redo history depth = 1000 actions.
- Relationship of outputs to inputs:
  - Input/output sequences: Menu selection → state restore → board redraw.
  - Formulas for conversion: [N/A]

### 3.1.7 End of the game detection and handling
- Inputs:
  - The 2x by 2x “great square” is moved to the bottom of the board.
- Validity checks on inputs:
  - Confirm the “great square” occupies the bottom position that defines the solved state.
- Exact sequence of operations:
  - Freeze player statistics (movement count and elapsed time).
  - If the current player’s number of movements is lower than the highest movement count recorded in the statistics file, display the “Finish Window with Statistics”; otherwise, display the “Simple Finish Window”.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Solved position detected → display appropriate finish window.
  - Formulas for conversion: Comparison is based on movement counts.

### 3.1.8 Finish Window with Statistics
- Inputs:
  - End-of-game event; user input of name (up to 20 characters); user clicks “OK”.
- Validity checks on inputs:
  - Name length ≤ 20 characters.
- Exact sequence of operations:
  - On “OK”, record the player’s statistics (name, movement count, elapsed time) into the statistics file per game statistics rules.
  - Close the finish window and display the Statistics Window.
- Responses to abnormal situations:
  - Overflow: If statistics file already holds 10 entries, remove the entry with the greatest number of block movements before adding the new one.
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: If the statistics file cannot be updated (e.g., wrong permissions or disk full), display an error message.
- Effect of parameters:
  - Statistics capacity = 10 entries; name field capacity = 20 characters.
- Relationship of outputs to inputs:
  - Input/output sequences: Name entry + “OK” → stats file update → close window → open Statistics Window.
  - Formulas for conversion: [N/A]

### 3.1.9 Simple Finish Window
- Inputs:
  - End-of-game event; user clicks “OK”.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - On “OK”, close the window and display the Statistics Window.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: “OK” → close window → open Statistics Window.
  - Formulas for conversion: [N/A]

### 3.1.10 Player statistics tracking
- Inputs:
  - Each block movement event.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - Increment movement count by 1.
  - Record elapsed time since the previous timestamp.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - Timing granularity and accumulation are based on recorded deltas between movements.
- Relationship of outputs to inputs:
  - Input/output sequences: Movement → update counters → no immediate UI output required.
  - Formulas for conversion:
    - movement_count = movement_count + 1
    - elapsed_time = elapsed_time + (t_event − t_prev)

### 3.1.11 Game statistics management (file)
- Inputs:
  - Completed “Finish Window with Statistics”.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - Append the player’s statistics to the statistics file, or if already at 10 entries, remove the entry with the greatest movement count and then append.
- Responses to abnormal situations:
  - Overflow: Capacity limited to 10 entries; handle by removing the worst (greatest movement count) before insert.
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: On failure to update (e.g., permissions, disk full), display an error message.
- Effect of parameters:
  - Capacity = 10 entries.
- Relationship of outputs to inputs:
  - Input/output sequences: Record request → file update (or error message).
  - Formulas for conversion: [N/A]

### 3.1.12 Statistics erasing
- Inputs:
  - Menu selection “Erase” under Statistics menu.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - Erase all data stored in the statistics file.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: On failure to update (e.g., permissions, disk full), display an error message.
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Menu selection → file clear (or error message).
  - Formulas for conversion: [N/A]

### 3.1.13 Statistics display
- Inputs:
  - End of game or menu selection “Display”.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - Read statistics file.
  - Display Statistics Window containing a list of up to 10 lines: player name, number of movements, elapsed time (as stored).
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - List capacity is 10 lines.
- Relationship of outputs to inputs:
  - Input/output sequences: Trigger → read → render list.
  - Formulas for conversion: [N/A]

### 3.1.14 File management: Open game
- Inputs:
  - Menu selection “Open game...”; user selection of a saved game file.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - Open a file-chooser dialog; user selects a file.
  - Load game state: current block positions, prior positions, movement count, elapsed time.
  - Apply loaded state.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Menu selection → dialog → load → board redraw and statistics set from file.
  - Formulas for conversion: [N/A]

### 3.1.15 File management: Save game
- Inputs:
  - Menu selection “Save game...”.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - If the game was never saved, perform “Save game as...”.
  - Otherwise, write to the previously chosen file:
    - Current positions of blocks.
    - Up to the last 10,000 previous positions.
    - Number of movements.
    - Elapsed time.
- Responses to abnormal situations:
  - Overflow: Persisted history limited to 10,000 previous positions.
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - History size persisted = 10,000 positions.
- Relationship of outputs to inputs:
  - Input/output sequences: Menu selection → write file.
  - Formulas for conversion: [N/A]

### 3.1.16 File management: Save game as
- Inputs:
  - Menu selection “Save game as...”; user selects target file.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - Open a file-chooser dialog; on selection, save:
    - Current positions of blocks.
    - Previous positions.
    - Number of movements.
    - Elapsed time.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Menu selection → dialog → write file.
  - Formulas for conversion: [N/A]

### 3.1.17 File management: Exit
- Inputs:
  - Menu selection “Exit”.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - If the game is not saved, display a dialog asking whether to save.
    - If “Yes”, perform “Save” then close the main window.
    - If “No”, close the main window without saving.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Menu selection → optional save prompt → terminate.
  - Formulas for conversion: [N/A]

### 3.1.18 Menu bar behavior
- Inputs:
  - Menu selections: Game (Open, Save, Save As, Exit), Action (Undo, Redo), Statistics (Display, Erase), Help (About).
- Validity checks on inputs:
  - Disable “Undo” when no previous movement.
  - Disable “Redo” when the previous action was not an “Undo”.
- Exact sequence of operations:
  - Invoke the corresponding function as specified in sections 3.1.14–3.1.17, 3.1.5–3.1.6, 3.1.13, 3.1.12, and 3.1.19.
  - Hide the menu after selection.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: Unavailable actions remain disabled.
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Selection → action execution → UI updates as defined by the invoked function.
  - Formulas for conversion: [N/A]

### 3.1.19 Help: About
- Inputs:
  - Menu selection “About”.
- Validity checks on inputs:
  - [N/A]
- Exact sequence of operations:
  - Display “About Window” containing the text: “Qheadache 1.0 by Jean‑Philippe Brossat jp_brossat@yahoo.fr”.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication facilities: [N/A]
  - Hardware faults and failures: [N/A]
  - Error handling and recovery: [N/A]
- Effect of parameters:
  - [N/A]
- Relationship of outputs to inputs:
  - Input/output sequences: Selection → show window.
  - Formulas for conversion: [N/A]

## 3.2 Performance requirements

Static numerical requirements (capacity):
- Simultaneous users supported per machine: 1.
- Minimum display resolution: 800×600 pixels.
- Statistics capacity: up to 10 player statistics records stored.
- Maximum player name length per statistics entry: 20 characters.

Dynamic numerical requirements:
- [N/A]

## 3.3 Usability requirements

This section consolidates usability and quality-in-use requirements derived from the original SRS. Where measurable criteria are not specified in the source, items are marked [N/A].

- Contexts of use
  - Users: general public with basic computer operation skills; suitable from age 8 through adult; no qualification is necessary.
  - Operating environment: single user per machine; keyboard and mouse input; graphical display of at least 800×600; Qt-supported operating systems.
  - Interface style: stand-alone application using menus, graphics, and optional sounds (sound is not required to play).

- Effectiveness (task success)
  - The game shall allow users to solve the puzzle by moving blocks on a board until the 2×2 block reaches the bottom of the board; when achieved, the game ends and player statistics are frozen.
  - The system shall prevent illegal actions during block manipulation: blocks shall not overlap; blocks shall not exit the board; a minimum spacing of 0.05x between blocks shall be enforced.
  - The board and blocks shall be visually distinguishable (board is black; blocks are yellow) to support clear recognition of state.
  - Measurable criteria: prevention of overlap and out-of-bounds moves at all times; end-of-game detection when the 2×2 block reaches the bottom of the board.

- Efficiency (resource and time use)
  - The system shall provide error recovery via Undo/Redo for the last 1000 movements.
  - The system shall support direct manipulation: select a block with left-click down; move it by mouse movement; deselect with left-click up.
  - The system shall provide continuous feedback during play by counting and displaying elapsed time and the number of user actions.
  - Menu items for actions shall be disabled when the associated action is unavailable to reduce unnecessary attempts.
  - Measurable criteria: Undo/Redo depth = 1000 movements; elapsed time and move count are visible during gameplay; unavailable actions are not selectable from menus.

- Error prevention, feedback, and recovery (avoidance of harm)
  - On exit with unsaved changes, the system shall prompt the user to save (Yes/No); selecting Yes performs Save before exit.
  - On file operations (save/update/statistics) failure due to conditions such as insufficient permissions or disk full, the system shall display an error message.
  - Menu interactions shall trigger the corresponding action and close the menu, providing immediate feedback on user selection.
  - Measurable criteria: presence of save prompt on unsaved exit; error message displayed on file/statistics write failures.

- Satisfaction
  - [N/A]

- Accessibility and inclusivity
  - Sound is not required to play the game, allowing use without audio output.
  - Other accessibility criteria (e.g., keyboard-only operation, color-blind safe palette, text size options) are [N/A].

## 3.5 Logical database requirements

This product persists data in local files. For the purposes of these requirements, “database” refers to these persistent files:
- Statistics file containing up to 10 player statistics.
- Saved-game files containing the current game state and history necessary to resume play.

a) Types of information used by various functions
- Player statistics (used by end-of-game and statistics functions):
  - Player name (entered via an edit box that can contain 20 characters).
  - Number of block movements used to solve the game.
  - Time used by the player to solve the game.
- Game statistics collection:
  - Up to 10 player statistics stored in the statistics file.
- Saved game data (used by open/save functions):
  - Current positions of the blocks.
  - Previous positions of the blocks (for Save: the last 10,000 previous positions; for Save As: previous positions).
  - Number of previous movements.
  - Time passed by the user to solve the headache.
- Function use of the data:
  - End-of-game recording writes a player statistic to the statistics file.
  - Statistics window reads and displays the statistics file.
  - Statistics erasing clears the statistics file.
  - Open reads a saved-game file and sets the board and player statistics accordingly.
  - Save/Save As write the saved-game data to a file.

b) Frequency of use
- Player statistics are updated in memory on each block movement; they are written to the statistics file when the player finishes the game and confirms via the finish window.
- Statistics display reads occur at the end of the game or on user menu selection.
- Statistics erase writes occur on user menu selection.
- Open, Save, and Save As reads/writes occur on user menu selection; Save may also be triggered from Exit if the game is unsaved.

c) Accessing capabilities
- Read operations:
  - Load saved-game files on “Open.”
  - Display statistics on end-of-game or upon “Statistics > Display.”
- Write operations:
  - Persist saved-game files on “Save” or “Save As,” and when the user chooses to save on Exit.
  - Append/insert a player statistic on end-of-game via “Finish Window with Statistics,” updating the statistics file.
  - Clear the statistics file on “Statistics > Erase.”
- Error handling for access failures:
  - If a file operation fails (e.g., wrong permissions or disk full), an error message is displayed.

d) Data entities and their relationships
- PlayerStatistic:
  - Attributes: name (≤ 20 characters), number of block movements, time used to solve the game.
- GameStatistics:
  - A collection of up to 10 PlayerStatistic entries stored in the statistics file.
  - Relationship: GameStatistics contains multiple PlayerStatistic entries (maximum 10).
- SavedGame:
  - Attributes: current positions of the blocks; previous positions of the blocks (as specified by the invoked save action); number of previous movements; time passed by the user.
  - Relationship: a SavedGame contains the positions for all blocks on the board and their history.
- The GameStatistics (statistics file) and SavedGame (saved-game files) are independent datasets.

e) Integrity constraints
- Player name length must not exceed 20 characters (as per the finish window input control).
- Statistics file must contain no more than 10 PlayerStatistic entries; if already at 10, the entry with the greatest number of block movements is erased before inserting the new one.
- On “Open,” the player statistics set in the running game must be those read from the saved-game file.
- Saved-game data must be sufficient to redraw the board according to the file data and resume play (i.e., include current positions, previous positions as defined by the save action used, number of previous movements, and elapsed time).
- Persisted positions and histories must represent a valid game state as defined by the board and movement rules.

f) Security
- Access to files relies on operating system file permissions. If access is denied due to permissions, an error message is displayed.
- [N/A] for authentication, encryption, or other security controls.

g) Data retention requirements
- Statistics file entries persist indefinitely until explicitly erased by the user or replaced due to the 10-entry limit rule.
- Saved-game files persist until overwritten by a subsequent save or deleted by the user.
- No archival or expiration requirements are specified.

## 3.6 Design constraints

- External standards: [N/A]
- Regulatory requirements: [N/A]

- Technology and platform constraints:
  - The product must use the Qt graphical library.
  - The product must run on all operating systems supported by Qt.
  - The software must be portable to the Windows operating system.

- Architectural constraints:
  - The product must run as a stand-alone application.
  - No communications interfaces are required; the game operates offline.

- Hardware and I/O constraints:
  - The system requires a keyboard and a mouse; other pointing/input devices are acceptable if they provide functions equivalent to a mouse and keyboard.
  - A graphical display with a minimum resolution of 800×600 is required.
  - Sound is optional; the game must be fully playable without audio output.

- User interface constraints:
  - The user interface must employ menus, graphics, and sounds.

- Operational constraints:
  - There can be only one user per machine (no multi-user/concurrent sessions).

- Data storage constraints:
  - Game statistics must be stored in a local statistics file; file operations must handle failures such as insufficient permissions or disk full.

## 3.7 Software system attributes

- Reliability
  - When updating the statistics file, if the update fails (e.g., wrong permissions or disk full), an error message shall be displayed. This applies to recording player statistics and erasing statistics.
  - Sound is not required to play the game; lack of sound capability shall not prevent gameplay.

- Availability
  - The system provides save and open game capabilities to allow resuming play later.
  - On exit, if the current game is not saved, the user is prompted to save. Selecting “Yes” saves the game and exits; selecting “No” exits without saving.

- Security
  - [N/A]

- Maintainability
  - [N/A]

- Portability
  - The product uses the Qt graphical library and must run on all operating systems that Qt supports.
  - The software must be portable to the Windows OS.
  - Platform constraints: requires a graphical display of at least 800×600 resolution; requires keyboard and mouse (other pointing devices are allowable if they provide equivalent functions).

## 3.8 Supporting information

- a) Sample input/output formats and related items
  - Inputs
    - Mouse: left-click down on a block (selection); left-click up on a selected block (deselection); mouse movement during the “Block movement” state.
    - Menu selections: Game (“Open game…”, “Save Game…”, “Save Game As…”, “Exit”); Action (“Undo”, “Redo”); Statistics (“Display”, “Erase”); Help (“About”).
    - Text input: Finish Window with Statistics edit box (up to 20 characters for player name).
  - Outputs
    - Board redraw after moves/undo/redo.
    - Finish Window with Statistics: text “You win ! Enter your name : ”, an edit box (20 characters), and an “OK” button.
    - Simple Finish Window: text “You win !” and an “OK” button.
    - Statistic Window: listbox of 10 lines; each line shows player name, number of block movements, and time; values read from the statistics file.
    - About Window: text “Qheadache 1.0 by Jean‑Philippe Brossat jp_brossat@yahoo.fr”.
    - Error messages if updating the statistics file fails (e.g., wrong permissions or disk full).
  - Saved game content (file data)
    - Current positions of blocks; previous positions (up to the last 10000 in “Save Game”); number of previous movements; time used by the player.

- b) Supporting/background information
  - Product perspective: stand-alone application using the Qt graphical library; runs on operating systems supported by Qt; requires keyboard and mouse; minimum display resolution 800×600; sound is not required; only one user per machine; portable to the Windows OS.
  - User characteristics: anyone able to operate a computer; beginners from age 8; no qualification necessary.
  - Board layout and constraints: board size 5x by 4x where x ∈ [50, 100] pixels; block margins 0.1x; minimum proximity between blocks 0.05x; blocks inventory (four x-by-x squares; four 2x-by-x rectangles; one x-by-2x rectangle; one 2x-by-2x square); board color black, blocks yellow.

- c) Problem to be solved by the software
  - Provide an interactive sliding-block puzzle in which the player moves blocks within a constrained 5x-by-4x board without overlaps or leaving the game zone, with the objective of moving the large square (“great square”) to the bottom of the board to finish the game.
  - Track and display player statistics: number of block movements since the start and elapsed time.
  - Provide undo and redo of movements and manage persistence of game state and statistics; display appropriate finish and statistics windows at game end.

- d) Special packaging instructions for code and media
  - [N/A]

Whether the supporting information above is to be considered part of the requirements: [N/A]

## 4.1 Functions

This section defines the verification methods and test approaches to qualify the software functions. The items below are organized in parallel with the functional groupings and details specified in the requirements, addressing input validity, operation sequences, abnormal situations, effects of parameters, and input/output relationships.

- Actions (board, selection, movement, undo, redo)
  - Verification methods
    - Inspection: UI layout conformance (board dimensions, colors).
    - Unit tests: movement constraints, history stack behavior.
    - System/functional tests: mouse interaction flows, undo/redo behavior.
  - a) Input validity
    - Verify left-click down selects only a block under the cursor; no selection outside board.
    - Verify mouse movement is recognized only during “Block movement” state; ignore otherwise.
    - Verify left-click up only deselects if a block is selected.
    - Verify menu selections for Undo/Redo are accepted only when available; when unavailable, items are disabled per spec.
  - b) Exact sequence of operations
    - Test sequence: select (left-click down) -> state becomes “Block movement” -> move (mouse move) -> release (left-click up) -> state becomes “Block selection”.
    - Confirm selected block follows cursor without overlapping blocks, without leaving board, and maintains ≥0.05x clearance to others; margin between blocks remains 0.1x as specified.
  - c) Abnormal situations
    - Overflow: Verify undo/redo history supports at least the last 1000 actions (2.2.1), and that attempts to go beyond available history are prevented (menu disabled).
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: Verify Undo is unavailable when no prior movement exists; verify Redo is unavailable if previous action was not an Undo.
  - d) Effect of parameters
    - Verify x is enforced such that 50 px ≤ x ≤ 100 px; at boundary values, board height = 5x and width = 4x; square and rectangular block sizes scale accordingly.
  - e) Relationship of outputs to inputs
    - Input/output sequences: Mouse inputs yield immediate visual updates of block position; selection/deselection produces state changes; Undo/Redo redraws board to prior/next positions.
    - Conversions/formulas: Not applicable beyond geometric constraints and state transitions; verified by position and spacing checks derived from x and margins.

- End of game management (end condition and finish windows)
  - Verification methods
    - System tests: trigger end condition; window flow verification.
    - Inspection: window contents, texts, and controls.
  - a) Input validity
    - Verify end-of-game is detected only when the great square reaches the bottom of the board.
  - b) Exact sequence of operations
    - On end condition, freeze player statistics, then branch:
      - If current player’s movement count is lower than the highest number recorded in the statistics file, display “Finish Window with Statistics”; otherwise display “Simple Finish Window”.
  - c) Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: If saving statistics fails (permissions/disk full), verify error message is displayed (per statistics management).
  - d) Effect of parameters
    - Verify name Edit Box allows up to 20 characters.
  - e) Relationship of outputs to inputs
    - Finish with Statistics: On clicking OK, write player name, movement count, and time to statistics file; close finish window; then display Statistic Window.
    - Simple Finish: On clicking OK, close finish window; then display Statistic Window.

- Statistics management (player statistics, game statistics, erase, display)
  - Verification methods
    - Unit tests: counters and time calculation.
    - System tests: file content updates, eviction policy, UI display.
    - Fault-injection tests: write failures (permissions/disk full).
  - a) Input validity
    - Increment statistics only on a valid block movement.
  - b) Exact sequence of operations
    - Player statistics: On movement, increment movement count by 1; record time difference since last recorded time.
    - Game statistics update: After Finish with Statistics and OK, append player stats; if 10 entries already exist, delete the entry with the greatest number of block movements.
    - Statistics erasing: On menu “Erase”, delete stored statistics data.
    - Statistics display: On end-of-game or menu “Display”, show Statistic Window.
  - c) Abnormal situations
    - Overflow: Verify list is capped at 10 entries; oldest/greatest-by-moves entry is removed per “greatest number of block movements” rule.
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: On file update failure (permissions/disk full), verify error message is shown for both updating and erasing operations.
  - d) Effect of parameters
    - Verify time is accumulated as the sum of recorded time deltas; verify movement count includes Undo/Redo as “considered like a movement” per action definitions.
  - e) Relationship of outputs to inputs
    - Input/output sequences: Movement input updates on-screen counters (if displayed) and internal statistics; completing Finish with Statistics updates persistent file; Statistic Window shows up to 10 lines, each with player name, movement count, and time read from the file.
    - Formulas: Movement count = previous count + 1 per movement; Time = previous time + delta between movements.

- File management (open, save, save as, exit)
  - Verification methods
    - System tests: file dialogs, serialization/deserialization, exit prompts.
    - Inspection: fields written/read.
    - Fault-injection tests: save without prior filename; unsaved changes on exit.
  - a) Input validity
    - Open: Accept only a user-selected file; [N/A] for invalid file content behavior (not specified).
    - Save: If game never saved, behavior identical to Save As.
  - b) Exact sequence of operations
    - Open: Show file dialog; on selection, load current positions, prior positions, movement count, and time; redraw board; set player statistics from file.
    - Save: If already saved, write current positions, last 10000 previous positions, number of previous movements, and time to the same file.
    - Save As: Show file dialog; on selection, write current positions, previous positions, number of previous movements, and time to the chosen file.
    - Exit: If the game is not saved, prompt Yes/No; on Yes, perform Save then close main window; on No, close main window.
  - c) Abnormal situations
    - Overflow: Verify handling of history length when saving (write last 10000 positions as specified for Save).
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: On save/update failure (permissions/disk full), verify error message is displayed (per statistics error handling where applicable); [N/A] for Open invalid/corrupt data handling.
  - d) Effect of parameters
    - Verify Save vs Save As behavior depends on presence/absence of an existing target filename.
  - e) Relationship of outputs to inputs
    - Input/output sequences: Menu selections lead to dialogs and subsequent file read/write; confirmed by updated in-memory state and redraw; Exit selection leads to conditional save and window closure.
    - Formulas: [N/A]

- Menu bar (Game, Action, Statistics, Help)
  - Verification methods
    - System tests: menu presence, order, enablement, and action routing.
    - Inspection: About text content.
  - a) Input validity
    - Verify menus contain exactly the specified items in the stated order; verify Undo/Redo are disabled when unavailable.
  - b) Exact sequence of operations
    - Game menu routes to Open, Save, Save As, Exit; Action menu routes to Undo/Redo; Statistics menu routes to Display/Erase; Help menu shows About Window.
  - c) Abnormal situations
    - Overflow: [N/A]
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
    - Error handling and recovery: Covered by the target actions (e.g., statistics/file errors).
  - d) Effect of parameters
    - [N/A]
  - e) Relationship of outputs to inputs
    - Menu selection causes menu to disappear and corresponding action to perform; About Window displays text: “Qheadache 1.0 by Jean‑Philippe Brossat jp_brossat@yahoo.fr”.

- External interface aspects directly tied to functions
  - Verification methods
    - System tests: input via mouse/keyboard and alternative pointing devices; screen resolution checks.
  - a) Input validity
    - Verify mouse and keyboard inputs drive all required actions; verify alternative pointing devices produce equivalent events for selection and typing names.
  - b) Exact sequence of operations
    - Verify inputs map to functional sequences as described above.
  - c) Abnormal situations
    - Communication facilities: [N/A]
    - Hardware faults and failures: [N/A]
  - d) Effect of parameters
    - Verify operation at a minimum screen resolution of 800×600; sound not required to play.
  - e) Relationship of outputs to inputs
    - Confirm that inputs via alternate devices result in the same UI responses as mouse/keyboard.

Notes and gaps for verification planning
- Open/corrupt file handling behavior, communications failures, and hardware fault responses are not specified: [N/A].
- Timing display/update cadence is not specified; verification will focus on recorded deltas and final accumulated time as defined.

## 4.2 Performance requirements

This section defines the verification approaches and methods for the performance requirements identified in section 3.2.

- PR-1: Number of simultaneous users supported per machine = 1
  - Verification method:
    - Requirements/design inspection to confirm absence of multi-user, networking, or multi-terminal features.
    - System test of a single running instance to confirm only one active player session and one controllable game board exist at any time.
  - Test design:
    - Launch the application and start a game; verify the UI presents exactly one game board and no workflow to add/switch concurrent users or sessions.
    - Review menus and dialogs (Open/Save/Statistics/Help) to confirm no multi-user or multi-session capabilities are offered.
    - Confirm no configuration items or communications interfaces are present that would enable remote or concurrent users.
  - Acceptance criteria:
    - Within a single running instance, there is at most one active player session and one game board.
    - No networking or multi-user login/session features exist.
    - Pass/fail is binary; all above conditions must hold.

- Static capacity: number of terminals supported
  - [N/A]

- Static capacity: amount and type of information to be handled
  - [N/A]

- Dynamic performance (throughput, latency, peak/normal workload limits)
  - [N/A]

## 4.3 Usability requirements

This subsection defines how the usability-related aspects stated or implied in the original SRS will be verified. Where measurable effectiveness, efficiency, satisfaction, or avoidance-of-harm criteria are not specified in the original SRS, the corresponding verification thresholds are noted as [N/A].

- Context of use and user profile
  - Basis: Users include beginners starting at age 8 up to advanced adult players (3.1.1.1); no qualification is necessary (2.3).
  - Verification method: Task-based formative/usability sessions with first-time users representative of the stated profile executing core tasks (start game, select/move/deselect blocks, use Undo/Redo, finish a game, view statistics, save/load, exit).
  - Metrics/criteria: Effectiveness (task completion) and learnability without prior training: [N/A]. Efficiency (task time/steps): [N/A]. Satisfaction: [N/A].

- Interface conformance and discoverability
  - Basis: Main window contains a board and a menu bar (3.1.1.2); UI uses menus, graphics, and sounds (2.1.1; 3.1); sound is not required to play (3.1).
  - Verification method: UI inspection and functional demonstration to confirm presence and visibility of required elements at 800×600 resolution and operation with mouse/keyboard; confirm game is fully operable with sound muted/disabled.

- Menu structure, labeling, and availability states
  - Basis: Game menu contents and order (3.2.5.1); Action menu with Undo/Redo and disabled states when unavailable (3.2.5.2; 3.2.1.5; 3.2.1.6); Statistics menu contents (3.2.5.3); Help menu About (3.2.5.4).
  - Verification method: UI inspection against specified labels and order; scenario-based tests to confirm enable/disable logic (e.g., Undo disabled when no prior movement; Redo disabled unless the previous action was Undo); confirm menu selections invoke the specified functions.

- Dialogs and window content clarity
  - Basis: Finish Window with Statistics content, behavior, and flow (3.2.2.2); Simple Finish Window (3.2.2.3); Statistic Window composition (3.2.3.4); About Window text (3.2.5.4.3).
  - Verification method: UI inspection for exact texts, controls, and field limits (e.g., name edit box length); functional checks for specified navigation/closures and subsequent window displays.

- Interaction behavior and visual feedback
  - Basis: Block selection/deselection/movement interactions, constraints, colors, and spacing (3.2.1.1–3.2.1.4).
  - Verification method: Manual interaction tests to confirm:
    - Selection via left-click down; deselection via left-click up.
    - Movement tracks mouse within the board, without overlap, respecting minimum margins.
    - Board background black; blocks yellow; board and block dimensions within specified bounds at supported resolutions.

- Error prevention and user protection (avoidance of harm)
  - Basis: Exit behavior prompts to save when unsaved (3.2.4.4); disabling actions when unavailable (3.2.5.2; 3.2.1.5; 3.2.1.6).
  - Verification method: Scenario-based tests ensuring unsaved work prompt appears on Exit and that irreversible actions are not performed without the specified prompt; confirm unavailable actions cannot be invoked via UI.

- Input devices and accessibility of basic operations
  - Basis: Operation with mouse and keyboard; allowance for other pointing/input devices with equivalent functions (3.1; 2.1.2).
  - Verification method: Functional tests using mouse and keyboard; optional spot checks with an alternative pointing device providing cursor movement and typing to ensure basic operation.

- Effectiveness criteria
  - Basis: [N/A]
  - Verification threshold: [N/A]

- Efficiency criteria
  - Basis: [N/A]
  - Verification threshold: [N/A]

- Satisfaction criteria
  - Basis: [N/A]
  - Verification threshold: [N/A]

## 4.5 Logical database requirements

This section verifies the logical data storage used by the software (statistics file and saved-game files). Verification activities are aligned to the items specified under 3.5 Logical database requirements.

- a) Types of information used by various functions
  - Player statistics (see 3.2.3.1, 3.2.3.2, 3.2.3.4; 3.2.2.2):
    - Verify that, upon Finish Window with Statistics completion, the following are recorded: player name (up to 20 characters per 3.2.2.2), number of block movements, and time since start.
    - Methods: functional tests driving a win that triggers 3.2.2.2; boundary input for name length (20 chars); confirm Statistic Window displays the recorded values (3.2.3.4) and that file update succeeds or produces an error message as specified (3.2.3.2.4).
  - Saved game state (see 3.2.4.1, 3.2.4.2, 3.2.4.3):
    - Verify that Save Game writes: current block positions, the last 10000 previous positions, movement count, and elapsed time (3.2.4.2).
    - Verify that Save Game As writes: current block positions, previous positions, movement count, and elapsed time (3.2.4.3).
    - Methods: round-trip tests (save → open) to assert exact restoration of all persisted fields; for Save Game, perform >10000 moves before saving and confirm only the last 10000 previous positions are available after open.

- b) Frequency of use
  - [N/A]

- c) Accessing capabilities
  - Read/write of statistics (see 3.2.3.2, 3.2.3.4):
    - Methods: trigger recording via 3.2.2.2 and verify statistics are subsequently displayed from file (3.2.3.4). Inject file write failures (e.g., simulate wrong permissions or disk full) and verify error message is displayed (3.2.3.2.4).
  - Read/write/erase of saved games and statistics (see 3.2.4.1–3.2.4.4; 3.2.3.3):
    - Methods: verify Open Game redraws board and restores player statistics exactly as in the file (3.2.4.1.4); verify Save/Save As write specified content (3.2.4.2–3.2.4.3); verify Exit flow saves when “Yes” is chosen and does not save when “No” is chosen (3.2.4.4); verify Erase removes all statistics and subsequent display reflects emptiness (3.2.3.3, 3.2.3.4).

- d) Data entities and their relationships
  - Game Statistics contains up to 10 Player Statistics (see 3.2.3.2, 3.2.3.4):
    - Methods: populate 10 entries, then add a new qualifying statistic via 3.2.2.2 and verify the file still contains 10 entries and that the entry with the greatest number of block movements was erased per 3.2.3.2.3; verify the Statistic Window shows exactly what is in the statistics file (3.2.3.4).
  - Saved game entity contains board state and player stats snapshot (see 3.2.4.1–3.2.4.3):
    - Methods: round-trip verification that all saved entities reload consistently and drive UI/state accordingly (board redraw, movement count, time).

- e) Integrity constraints
  - Name length limit (20 characters) in Finish Window with Statistics (see 3.2.2.2):
    - Methods: boundary tests on input field capacity; confirm recorded name does not exceed 20 characters.
  - Statistics cap and replacement policy (max 10; remove greatest movement count when full) (see 3.2.3.2.3):
    - Methods: controlled dataset tests to assert correct removal and that total entries never exceed 10.
  - Board and block validity after reload (see 3.2.1.1, 3.2.1.4.3):
    - Methods: after Open Game, assert all blocks remain within the 4x by 5x board, maintain minimum margins (0.1x) and separations (≥0.05x), and do not overlap or exit the game zone.
  - Undo/redo history persistence per save mode (see 3.2.4.2, 3.2.4.3):
    - Methods: for Save Game, confirm exactly the last 10000 previous positions are available after open; for Save Game As, confirm previous positions are restored as written by the action.
  - Non-negativity and consistency:
    - Methods: assert movement counts are non-negative integers and time values are consistent with recorded gameplay durations upon reload and in statistics.

- f) Security
  - [N/A]

- g) Data retention requirements
  - Persistence across sessions:
    - Methods: verify statistics recorded via 3.2.2.2 persist after application exit and relaunch, until explicitly erased (3.2.3.3); verify saved games persist across sessions and reload correctly via Open Game (3.2.4.1–3.2.4.3).
  - User-controlled retention on exit (see 3.2.4.4):
    - Methods: if “Yes” to save, confirm data are retained; if “No,” confirm no new persistence occurs.

## 4.6 Design constraints

The following verification methods qualify conformance to the design constraints defined in the requirements.

- Dependency on Qt graphical library
  - Method: Design/code inspection of build scripts and source to confirm UI and windowing use Qt; dependency scan of binaries to confirm Qt linkage only for UI.
  - Acceptance criteria: Build configuration references Qt; no non-Qt UI frameworks required; runtime binaries link to Qt as expected.

- Cross-operating-system portability (must run on all operating systems supported by Qt)
  - Method: For each target OS in the project-supported list [N/A], perform clean install, launch, and smoke/regression runs covering startup, main window rendering, board interaction, menus, file open/save, and exit.
  - Acceptance criteria: Application installs and runs without modification; all smoke/regression tests pass on every listed OS.

- Windows OS portability
  - Method: Build with Windows toolchain; install and execute the same smoke/regression suite on supported Windows versions [N/A].
  - Acceptance criteria: Successful build and installation; all tests pass on Windows; no Windows-specific defects blocking normal operation.

- Stand-alone application (no communications interfaces required)
  - Method: Execute on a network-isolated machine; monitor process for network/socket activity during full gameplay and file operations.
  - Acceptance criteria: No network connections attempted; full functionality available offline.

- Minimum display resolution (≥ 800×600)
  - Method: Run on a system constrained to 800×600 resolution; verify that the main window (board and menu bar) fully renders and all controls are accessible without clipping or hidden elements.
  - Acceptance criteria: All required UI elements are visible and usable at 800×600; no overlap or truncation that blocks required actions.

- Required input devices (keyboard and mouse)
  - Method: Functional tests covering mouse-based selection/movement of blocks and keyboard entry where applicable (e.g., player name entry); optionally validate a generic pointing device behaves as a mouse when available [N/A].
  - Acceptance criteria: All specified interactions work with a mouse and keyboard; no reliance on other input devices.

- Optional sound (not required to play)
  - Method: Run on a system without sound hardware or with audio disabled; execute full gameplay and file operations.
  - Acceptance criteria: No errors or degraded functionality in the absence of sound; game remains fully playable.

## 4.7 Software system attributes

- Reliability
  - [N/A]

- Availability
  - [N/A]

- Security
  - [N/A]

- Maintainability
  - [N/A]

- Portability
  - Verification objectives
    - Verify the product runs on Windows OS as required.
    - Verify the product runs on all operating systems supported by Qt, as stated for software interfaces.
    - Verify the UI is implemented with the Qt graphical library.
  - Methods
    - Platform test execution
      - Build the application with the specified Qt toolchain.
      - For each target operating system (Windows, and each OS supported by Qt at release), install and launch the application, then execute the full functional regression suite covering:
        - Main window display and board rendering.
        - Block selection, movement, undo/redo.
        - End-of-game handling and statistics windows.
        - File operations (open, save, save as, exit prompts).
        - Menus (Game, Action, Statistics, Help).
      - Acceptance: 100% of test cases pass on each target OS with no OS-specific critical defects or crashes.
    - Build and dependency verification
      - Review build scripts and binaries to confirm linkage against Qt graphical library and absence of alternate GUI frameworks.
      - Acceptance: Build logs show Qt usage; binaries/packaging include required Qt components; no non-Qt GUI framework is referenced.
    - Code inspection (portability focus)
      - Inspect source to confirm OS interactions for UI are via Qt APIs; any platform-conditional code, if present, does not preclude execution on Qt-supported OSes.
      - Acceptance: No blocking platform-specific assumptions are present; identified conditionals do not restrict supported OS set.
  - Evidence
    - Platform test reports per OS, including pass/fail summary.
    - Build logs and bill of materials showing Qt dependencies.
    - Code review records focusing on portability concerns.

## 5.1 Assumptions and dependencies

- Availability of a compatible Qt graphical library at build and runtime; changes in Qt support or APIs may affect supported platforms and UI behavior.
- Target operating systems are those supported by Qt; availability of at least one such OS (including Windows) on deployment hardware is assumed.
- The deployment environment provides a graphical display capable of at least 800×600 resolution for proper UI layout.
- A keyboard and a mouse (or equivalent pointing/typing devices that expose standard events via the OS/Qt) are available to the user.
- The application runs as a stand-alone desktop program without requiring network connectivity or external services.
- The host system provides a writable file system with sufficient permissions and free space to store save files and a statistics file; failures (e.g., disk full, denied permissions) are possible and affect behaviors specified for save/statistics features.
- A consistent, accessible system time source is available to measure elapsed playtime; significant clock adjustments could affect time-based statistics.
- Sufficient memory and storage are available to maintain undo/redo history (up to 1000 actions) in memory and to persist up to 10,000 prior positions in saved games.
- Only one user/session will use the application per machine at a time; concurrent access to the statistics or save files from multiple processes/users is not expected.
- Presence of sound hardware/drivers is optional; if unavailable, functionality degrades gracefully without affecting core gameplay.

## 5.2 Acronyms and abbreviations

- SRS: Software Requirements Specification
- OS: Operating System
- Qt: Cross-platform graphical application framework/library used by the product
- OK: Confirmation/acceptance button label indicating user acknowledgment