# 1 Introduction
[NULL]

## 1.1 Purpose
Qheadache is a stand-alone computerized board game whose purpose is to let users solve a specific block-moving “headache” puzzle via a graphical interface. The software enables gameplay by allowing block selection and movement, supports undo and redo of recent actions, tracks and displays elapsed play time and number of actions, and records and presents player scores.

## 1.2 Scope
Qheadache is a stand-alone desktop game application that provides a graphical interface for solving a specific block-moving puzzle.

Within scope, the software will:
- Present a 4x5 board with predefined blocks and allow the user to select and move blocks subject to spacing and boundary constraints, with the objective of moving the large square block to the bottom of the board to finish the game.
- Track and display player statistics during play, including elapsed time and number of moves.
- Manage end-of-game behavior by freezing statistics and displaying a finish window, optionally prompting for the player’s name when recording a qualifying score.
- Record, store, and display game statistics (up to 10 player records) and allow the user to erase all statistics.
- Provide undo/redo for movements, and support opening, saving, and saving-as of game state (including positions and history) via a menu-driven UI.
- Offer standard menus (Game, Action, Statistics, Help) and an About window; operate with graphics and optional sound (sound not required).

Application, benefits, objectives, and goals:
- Application: a simple puzzle game playable by users with basic computer skills (beginning at approximately age 8), operated with keyboard and mouse on a system with at least 800x600 resolution.
- Benefits: entertainment and replayability; visibility into personal performance via time and move counts; comparison via a displayed list of stored scores; ability to resume saved games.
- Objectives and goals: deliver accessible gameplay with accurate timing and move counting, reliable save/load and statistics persistence, and responsive undo/redo; run as a portable Qt-based application on operating systems supported by Qt, including Windows.

No higher-level system specification is referenced; this scope is consistent with the Introduction and General Description provided in this SRS.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
Qheadache is a stand-alone desktop game application. It is not an element of a larger system. It operates locally on a user’s machine, interacting with input devices, a graphical display, the operating system’s file system, and the Qt graphical library. No external systems, networks, or services are required.

#### System interfaces
- None. The product does not interface with any larger system or external subsystem beyond the host operating system and local hardware. [N/A]

#### User interfaces
- Graphical user interface using menus, graphics, and sounds.
- Main window includes:
  - Board: a rectangular zone (height 5x, width 4x; x between 50 and 100 pixels) with blocks arranged and moved by the user; board is black and blocks are yellow; minimum spacing and non-overlap enforced.
  - Menu bar: Game (Open, Save, Save As, Exit), Action (Undo, Redo), Statistics (Display, Erase), Help (About).
- Interaction:
  - Mouse-based block selection (left-click down), movement (mouse move), and deselection (left-click up).
  - Undo/Redo of movements (up to the last thousand actions); availability depends on context.
- Windows/dialogs:
  - Finish windows (with or without statistics input).
  - Statistics window (list of up to 10 entries).
  - File dialogs for Open/Save/Save As.
  - Exit confirmation dialog when unsaved.
  - About window.

#### Hardware interfaces
- Input: keyboard and mouse; other pointing devices allowed if they provide equivalent cursor movement and typing capabilities.
- Display: graphical display with at least 800×600 resolution.
- Sound: used by the product but not required to play the game.

#### 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 the GUI framework and cross-platform support required by the product; the product must run on all operating systems that Qt supports.
- Operating system and file system
  - Platforms: must run on operating systems supported by Qt; the software must be portable to Windows OS.
  - Purpose: file I/O for saved games and statistics; error handling for conditions such as wrong permissions or disk full.
  - Interface definition: standard file dialogs and file read/write of game state and statistics; specific formats not defined. [N/A]

#### Communications interfaces
- Not applicable; no network or communications interfaces are required.

#### Memory constraints
- Not applicable.

#### Operations
- Mode: user-initiated, interactive operation; single user per machine.
- Interactive operations:
  - Play session with block selection/movement; end-of-game detection when the great square reaches the bottom of the board.
  - Undo/Redo movements.
  - Statistics management: recording number of movements and elapsed time.
  - File operations: Open, Save, Save As; Exit with optional save prompt.
  - Statistics display and erase; About display.
- Unattended operations: none specified. [N/A]
- Backup and recovery:
  - Persistence via Save/Save As of current state (current and previous block positions, number of movements, elapsed time).
  - Open restores a previously saved state.
  - Error reporting on file update failures (e.g., permissions, disk full).

#### Site adaptation requirements
- Not applicable.

#### Interfaces with services
- Not applicable. [N/A]

### 1.3.2 Product functions
The product is a stand-alone puzzle game that lets a user solve a block-moving puzzle while tracking and recording play statistics. Major functions are organized as follows:

- Gameplay
  - Display the game board with predefined blocks and layout.
  - Select, move, and release blocks with constraints that prevent overlap and exiting the board.
  - Detect game completion when the large square block reaches the bottom of the board.
  - Maintain an undo/redo history of recent moves (at least 1,000 actions), with availability governed by prior actions.

- Play telemetry
  - Count and display elapsed play time.
  - Count and display number of moves.
  - Treat undo/redo as movements for counting purposes.

- End-of-game flow
  - Freeze play statistics upon completion.
  - If the score qualifies for the statistics list, prompt the user to enter a name and record the score; otherwise, show a simple finish message.
  - Display the statistics window after finishing.

- Statistics management
  - Maintain a statistics file with up to 10 recorded entries (player name, move count, elapsed time).
  - Display the statistics window listing the recorded entries.
  - Erase all recorded statistics on user request.
  - Report errors if statistics file updates fail (e.g., permissions, disk full).

- File management
  - Open a previously saved game.
  - Save the current game, including current block positions, a history of previous positions, move count, and elapsed time.
  - Save As to a user-selected file.
  - Prompt to save on exit if there are unsaved changes.

- User interface and help
  - Main window containing the game board and a menu bar.
  - Menus:
    - Game: Open, Save, Save As, Exit.
    - Action: Undo, Redo (enabled/disabled based on availability).
    - Statistics: Display, Erase.
    - Help: About.
  - About window displaying product information.

Representative use cases:
- Start and play a puzzle: move blocks within constraints; time and moves are tracked; completion is detected automatically.
- Correct mistakes: undo and redo recent moves within the available history.
- Finish and record a score: upon qualifying, enter a name; view the updated statistics list.
- Review or clear statistics: display current top entries; erase all statistics if desired.
- Save progress and resume later: save the current state and reopen it in a future session; confirm save on exit when needed.

### 1.3.3 User characteristics
- General audience: Anyone who wants to play a simple game; beginning level players starting at age 8 up to adults.
- Technical expertise: Users must know how to operate a computer and use a keyboard and mouse. No qualification is necessary.
- Educational level: [N/A]
- Prior experience/training: No qualification is necessary.
- Disabilities and accessibility needs: [N/A]

### 1.3.4 Limitations
- a) Regulatory requirements and policies: [N/A]
- b) Hardware limitations:
  - Requires a keyboard and a mouse (or other pointing/input devices providing equivalent cursor movement and typing functions).
  - Requires a graphical display with at least 800×600 resolution.
  - The game board uses a unit x constrained to 50–100 pixels; the board size is 5x by 4x with margins, which must fit the display.
  - Sound is not required to play.
- c) Interfaces to other applications: [N/A]
- d) Parallel operation:
  - Single-user operation: there can be 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): [N/A]
- j) Criticality of the application: [N/A]
- k) Safety and security considerations: [N/A]
- l) Physical/mental considerations:
  - Users must be able to operate a computer with a keyboard and pointing device.
  - Intended for users beginning at approximately age 8; no special qualification is necessary.
- m) Limitations sourced from other systems (including real-time requirements through interfaces):
  - Platform support is constrained to operating systems supported by the Qt graphical library.
  - The software must be portable to the Windows OS.

## 1.4 Definitions
- Board: The rectangular game area where blocks can be moved. Its size is 5x (height) by 4x (width) and it has a black background.
- Block: Any movable piece on the board. Types include:
  - Square block: 1x by 1x (four pieces).
  - Rectangular block: 2x by 1x (height by width) (four pieces).
  - Wide block: 1x by 2x (one piece).
  - Great square: 2x by 2x (one piece); moving this block to the bottom of the board ends the game.
  All blocks are yellow.
- x (measurement unit): The unit used to size the board and blocks; x is between 50 and 100 pixels, inclusive.
- Margin (marge): The fixed separation between blocks on the board, equal to 0.1x.
- Minimum clearance: During movement, a selected block cannot approach other blocks closer than 0.05x.
- Selected block: A block currently chosen by the user (via left-click down) for movement.
- Block selection: The game state in which no block is moving and a block can be selected.
- Block movement (also referred to as Block deplacement): The game state in which the selected block follows mouse movement while remaining within the board and not overlapping other blocks.
- Block deselection: Returning from Block movement to Block selection (via left-click up on the selected block).
- Movement: A single completed repositioning of a block; Undo and Redo each count as a movement.
- Undo: Action that reverts the last movement; unavailable if no previous movement exists.
- Redo: Action that reapplies the last movement that was undone; available only immediately after an Undo.
- End of the game: The condition reached when the great square is moved to the bottom of the board; player statistics are then frozen.
- Player statistics: The count of block movements since the start and the elapsed time since the start of the game.
- Game statistics: The collection of up to 10 player statistics records stored by the game.
- Statistics file: The persistent storage used to save and load game statistics; if full (10 records), the record with the greatest number of block movements is erased to store a new one.
- Score: A player’s recorded result consisting of name, number of block movements, and elapsed time.
- Finish Window with Statistics: The victory dialog containing the text “You win! Enter your name:”, a name entry field (up to 20 characters), and an OK button; on confirmation, the player’s statistics are saved to the statistics file and the Statistic Window is shown.
- Simple Finish Window: The victory dialog containing “You win!” and an OK button; on confirmation, the window closes and the Statistic Window is shown.
- Statistic Window (also referred to as Score window): The window that displays up to 10 records, each showing player name, number of block movements, and elapsed time, read from the statistics file.
- Open game: Action that loads a previously saved game from a file chosen by the user.
- Save game: Action that saves the current game to the previously chosen file, including current block positions, up to the last 10,000 previous positions, movement count, and elapsed time.
- Save game as: Action that saves the current game to a user-selected file, including current and previous block positions, movement count, and elapsed time.
- Exit: Action that closes the application; if the current game is unsaved, prompts the user to save before exiting.
- Menu bar: The primary navigation containing:
  - Game menu: Open game, Save game, Save game as, Exit.
  - Action menu: Undo, Redo (each disabled when unavailable).
  - Statistics menu: Display (shows the Statistic Window), Erase (clears all statistics).
  - Help menu: About.
- About Window: Dialog showing “Qheadache 1.0 by Jean-Philippe Brossat jp_brossat@yahoo.fr”.

# 2 References
## Compliance
- [N/A]

## Guidance
- [N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
### 3.1.1 Game board setup and parameters
- Parameters and effects
  - Board is a rectangular zone sized by unit x.
  - Board height is 5x and width is 4x; x is between 50 and 100 pixels inclusive.
  - Blocks and spacing:
    - Four square blocks with side x.
    - Four rectangular blocks of height 2x and width x.
    - One rectangular block of height x and width 2x.
    - One square block with side 2x.
    - Blocks are separated by a margin of 0.1x; minimum clearance during motion is 0.05x.
  - Appearance: board is black; blocks are yellow.
- Outputs
  - Board is displayed in the main window together with the menu bar.

### 3.1.2 Pointer-based block manipulation
- States
  - Block selection state.
  - Block movement state.
- Block selection
  - Input: left-click down on a block.
  - Validity checks: the click must occur on a block.
  - Sequence of operations: set game state to Block movement.
  - Outputs: [N/A].
- Block movement
  - Input: mouse movement while in Block movement state.
  - Validity checks:
    - The selected block must not overlap other blocks.
    - The selected block must not exit the game zone.
    - The selected block must maintain at least 0.05x distance from other blocks.
  - Sequence of operations: the selected block follows the mouse pointer subject to the constraints above.
  - Outputs: [N/A].
- Block deselection
  - Input: left-click up on the selected block.
  - Sequence of operations: set game state to Block selection.
  - Outputs: [N/A].

### 3.1.3 Undo and redo
- Undo
  - Input: menu selection “Undo.”
  - Validity checks: action unavailable if there was no previous movement.
  - Sequence of operations:
    - Restore block positions to the state before the last movement.
    - Count this as a movement.
  - Outputs: board is redrawn with restored positions.
- Redo
  - Input: menu selection “Redo.”
  - Validity checks: action unavailable if the previous action was not an “Undo.”
  - Sequence of operations:
    - Restore block positions to the state before the last undo.
    - Count this as a movement.
  - Outputs: board is redrawn with restored positions.
- Capacity/overflow behavior
  - The user may undo and redo the last 1000 actions.
  - When saving, up to the last 10000 previous positions are persisted.

### 3.1.4 End-of-game detection and finish windows
- End condition
  - Input: the great square is moved to the bottom of the board.
  - Sequence of operations: freeze all player statistics.
  - Outputs and decision:
    - If the current number of block movements is lower than the highest number recorded in the statistics file, display the Finish Window with Statistics.
    - Otherwise display the Simple Finish Window.
- Finish Window with Statistics
  - Inputs: end-of-game condition reached.
  - Interface: text “You win! Enter your name:”, an edit box up to 20 characters, and an OK button.
  - Sequence of operations:
    - On OK, record player statistics per statistics management rules.
    - Close the finish window; display the statistics window.
  - Outputs: statistics window is shown.
- Simple Finish Window
  - Inputs: end-of-game condition reached.
  - Interface: text “You win!” and an OK button.
  - Sequence of operations: on OK, close the finish window; display the statistics window.
  - Outputs: statistics window is shown.

### 3.1.5 Statistics management
- Player statistics (in-memory during play)
  - Maintained values:
    - Number of block movements since the start.
    - Time since the start.
  - Triggers: on each block movement.
  - Sequence of operations:
    - Increment movement count by 1.
    - Record the time difference between the current block movement and the previously recorded time.
  - Outputs: [N/A].
- Game statistics (persistent, up to 10 entries)
  - Input: completed Finish Window with Statistics.
  - Sequence of operations:
    - Record player name, number of block movements, and time used to solve the puzzle in the statistics file.
    - If 10 player statistics are already recorded, erase the entry with the greatest number of block movements before saving the new one.
  - Outputs:
    - If update succeeds: no output.
    - If update fails (e.g., wrong permissions or disk full): display an error message.
- Erase all statistics
  - Input: menu selection “Erase.”
  - Sequence of operations: erase data stored in the statistics file.
  - Outputs:
    - If erase succeeds: no output.
    - If erase fails (e.g., wrong permissions or disk full): display an error message.
- Statistics window (read-only view)
  - Inputs: end-of-game or menu selection “Display.”
  - Sequence of operations: display a window containing a list of up to 10 lines; each line shows player name, number of block movements, and time used, read from the statistics file.
  - Outputs: [N/A].

### 3.1.6 File management
- Open game
  - Input: menu selection “Open game…”.
  - Sequence of operations:
    - Open a file selection dialog.
    - User chooses a file that contains all previously saved game data.
    - Load game state from the file.
  - Outputs:
    - Redraw the board according to file data.
    - Set the player statistics to the values in the file.
- Save game
  - Input: menu selection “Save Game…”.
  - Sequence of operations:
    - If the game was never saved in this session, perform “Save Game As…”.
    - Otherwise, save to the previously used file the internal data: current block positions, their last 10000 previous positions, number of previous movements, and time used to solve the puzzle.
  - Outputs: [N/A].
- Save game as
  - Input: menu selection “Save Game As…”.
  - Sequence of operations:
    - Open a file selection dialog.
    - User chooses a destination file.
    - Save internal data: current block positions, their previous positions, number of previous movements, and time used to solve the puzzle.
  - Outputs: [N/A].
- Exit
  - Input: menu selection “Exit.”
  - Sequence of operations:
    - If the game is not saved, display a dialog asking whether to save.
    - If “Yes” is selected, perform “Save,” then close the main window.
    - If “No” is selected, close the main window.
  - Outputs: [N/A].

### 3.1.7 Menus and availability rules
- Game menu
  - Contains: Open game…, Save Game…, Save Game As…, Exit.
  - Input: menu selection triggers the corresponding file management action.
- Action menu
  - Contains: Undo, Redo.
  - Availability: menu items are unavailable if the associated action is unavailable.
  - Input: menu selection triggers the corresponding undo or redo action.
- Statistics menu
  - Contains: Display, Erase.
  - Input: menu selection triggers the corresponding statistics function.
- Help menu
  - Contains: About.
  - Sequence of operations: display “Qheadache 1.0 by Jean-Philippe Brossat jp_brossat@yahoo.fr”.
  - Outputs: [N/A].

### 3.1.8 Validity checks on inputs
- Block selection requires a left-click down on a block.
- Block movement is constrained to prevent overlap, exiting the board, and violating the 0.05x minimum clearance.
- Undo is valid only if there is a previous movement.
- Redo is valid only immediately after an Undo.
- Statistics entry name input is limited to 20 characters.
- Menu items that cannot be performed are unavailable.

### 3.1.9 Responses to abnormal situations
- Overflow
  - Undo/redo is limited to the last 1000 actions; earlier actions cannot be undone or redone.
  - When saving, only the last 10000 previous positions are persisted.
  - Game statistics holds up to 10 entries; on insertion when full, the entry with the greatest number of movements is erased.
- Communication facilities
  - [N/A].
- Hardware faults and failures
  - [N/A].
- Error handling and recovery
  - For statistics file update or erase failures due to wrong permissions or disk full, an error message is displayed.
  - Other error handling and recovery behaviors are [N/A].

### 3.1.10 Relationship of outputs to inputs, sequences, and formulas
- Input/output sequences
  - Selection sequence: left-click down on a block → enter Block movement state → mouse movement adjusts block position under constraints → left-click up → return to Block selection state → board reflects final block positions.
  - Undo/redo sequence: menu selection → validate availability → restore prior or redone positions → redraw board.
  - End-of-game sequence: move great square to bottom → freeze stats → show appropriate finish window → if Finish Window with Statistics, on OK save stats and then show statistics window; if Simple Finish Window, on OK show statistics window.
  - File operations sequence: menu selection → file dialog as applicable → read or write game data → redraw board and set stats on open; no visual output required on save.
  - Exit sequence: menu selection → prompt if unsaved → perform save if chosen → close window.
- Formulas and conversions
  - Move count: increment by 1 per block movement event.
  - Elapsed time: sum of recorded time differences between each block movement and the previously recorded time; equivalently, current time minus start time.
  - Statistics persistence selection: if more than 10 entries would exist, remove the entry with the greatest number of block movements before adding the new one.

## 3.2 Performance requirements
- Static numerical requirements (capacity):
  - Simultaneous users: The system shall support at most 1 active user per machine at any time.
  - Undo/redo history depth: The system shall maintain up to 1000 of the most recent user actions per session for undo/redo.
  - Saved history depth: On save, the system shall persist the current positions of the blocks and the last 10000 previous positions of the blocks, along with the number of previous movements and the elapsed time.
  - Statistics storage: The system shall store up to 10 player statistics records. Each record shall include a player name (up to 20 characters), the number of block movements, and the time used to solve the game.

- Dynamic numerical requirements:
  - [N/A]

## 3.3 Usability requirements
The following usability and quality-in-use requirements are derived from the original SRS. They address the intended contexts of use, effectiveness, efficiency, satisfaction, and avoidance of harm.

- Contexts of use
  - Intended users include anyone who wants to play a simple game, beginning at age 8 and up to adults; no specific qualifications are necessary.
  - Interaction devices are a mouse and keyboard; the user interface uses menus and graphics. Sound may be present but is not required to play.
  - A graphical display with at least 800×600 resolution is required.

- Effectiveness requirements
  - The main window shall present a board and a menu bar to make core actions discoverable.
  - The system shall provide immediate visual feedback by redrawing the game board after each movement, undo, and redo.
  - When the game is finished, the system shall display a finish window (with or without statistics entry, as applicable) and then display the statistics window.
  - The statistics window shall list up to 10 entries, each showing player name, number of block movements, and time used, read from the statistics file.

- Efficiency requirements
  - The system shall count and display, during play, both elapsed time and the number of movements made by the player.
  - Undo and redo shall be available via the Action menu, enabling rapid correction of mistakes; up to the last 1000 actions shall be undoable/redoable.
  - Menu items for actions that are not currently available (e.g., Undo/Redo when inapplicable) shall be disabled to minimize ineffective user attempts.
  - Core functions (Open, Save, Save As, Exit; Undo, Redo; Statistics Display, Erase; About) shall be accessible via the menu bar in the specified order.

- Satisfaction requirements
  - [N/A]

- Avoidance of harm and risk mitigation
  - To prevent loss of work, if the current game is unsaved on Exit, the system shall prompt the user to save before closing.
  - On file update failures (e.g., wrong permissions or disk full) during statistics or game save operations, the system shall display an error message.
  - To prevent invalid game states, block movement shall be constrained to avoid overlap with other blocks, maintain the required minimum spacing, and prevent exiting the game zone.
  - Sound shall not be required to play, avoiding reliance on audio feedback.

- Learnability and operability
  - The game shall be operable by users with basic computer skills and no special qualifications.
  - Interaction shall be via standard mouse and keyboard actions (menu selections; click-and-drag for block movement), supporting recognition over recall.

- Measurable usability objectives not otherwise specified
  - Effectiveness targets (e.g., task completion rates, error rates): [N/A]
  - Efficiency targets (e.g., time-on-task beyond in-game timing, steps to complete tasks): [N/A]
  - Satisfaction targets (e.g., user ratings, comfort measures): [N/A]
  - Accessibility targets (e.g., contrast ratios, keyboard-only operation, localization): [N/A]

## 3.5 Logical database requirements
This product uses file-based persistent storage. Two logical data stores are required:
- Statistics file (game-wide “Game Statistics”).
- Saved game file (per saved play session).

a) Types of information used by various functions
- Statistics file
  - PlayerStatistic: playerName (string, up to 20 characters), movementCount (non-negative integer), elapsedTime (non-negative duration).
  - GameStatistics: collection of up to 10 PlayerStatistic entries.
  - Used by: End-of-game decision, Statistics display, Statistics update, Statistics erase.
- Saved game file
  - Board state: positions of all blocks on a rectangular board (width 4x, height 5x; x between 50 and 100 pixels), including required margins (0.1x) and minimum proximity (0.05x).
  - Block set: four 1x1 blocks; four 2x1 blocks; one 1x2 block; one 2x2 block.
  - Movement history: previous positions list (Save stores “last 10000 previous positions”; Save As stores “previous positions” as available).
  - In-game counters: movementCount, elapsedTime.
  - Used by: Open game (restore state and counters), Save, Save As.

b) Frequency of use
- Statistics file
  - Read: at end of game to decide which finish window to show; on Statistics window display.
  - Write/Update: on completion of “Finish Window with Statistics.”
  - Delete: on “Erase” from the Statistics menu.
- Saved game file
  - Read: on “Open game.”
  - Write/Update: on “Save game” and “Save game as.”
  - No automatic background operations are specified.

c) Accessing capabilities
- Statistics file
  - Read all entries for display.
  - Compute/select entry with greatest movementCount (for replacement and end-of-game comparison).
  - Insert a new PlayerStatistic; if at capacity (10), remove the entry with the greatest movementCount before inserting.
  - Delete all statistics (erase).
- Saved game file
  - Create new file (Save As), overwrite existing file (Save).
  - Read a selected file (Open) to restore the board state, movement history, and in-game counters.

d) Data entities and their relationships
- GameStatistics
  - Contains up to 10 PlayerStatistic entries.
- PlayerStatistic
  - Attributes: playerName, movementCount, elapsedTime.
- SavedGame
  - Contains one Board, a fixed set of Blocks, a MovementHistory, and a snapshot of in-game counters (movementCount, elapsedTime).
- Board
  - Has many Blocks (fixed composition: 10 blocks with specified sizes).
- MovementHistory
  - Sequence of prior board states/positions associated with the same Blocks.

e) Integrity constraints
- Statistics file
  - Max 10 PlayerStatistic entries.
  - playerName length ≤ 20 characters.
  - movementCount ≥ 0; elapsedTime ≥ 0.
  - When inserting and already at 10 entries, remove the entry with the greatest movementCount before inserting the new one.
- Saved game file
  - Block positions must be within the board (4x by 5x) and must not overlap.
  - Inter-block spacing must respect minimum proximity: blocks separated by at least 0.05x; layout respects margin 0.1x.
  - Block set and sizes are fixed as specified.
  - Movement history content represents valid prior board states; Save stores last 10000 previous positions; Save As stores previous positions (no explicit maximum stated).

f) Security
- No additional security mechanisms are specified. File access is subject to operating system permissions; if permissions are insufficient, an error message is displayed.

g) Data retention requirements
- Statistics file
  - Retained across sessions until explicitly erased by the user. When adding a new statistic at capacity (10), the entry with the greatest movementCount is removed.
- Saved game file
  - Retained across sessions until the user overwrites it via Save or deletes it outside the application. Movement history and in-game counters are persisted as specified when saving.

## 3.6 Design constraints
- External standards and regulatory requirements: [N/A]

- Technology and platform constraints:
  - The system shall use the Qt graphical library.
  - The system shall run on all operating systems supported by Qt.
  - The software shall be portable to the Windows operating system.
  - The application shall run as a stand-alone desktop application.

- Hardware and input constraints:
  - The system requires a keyboard and a mouse; other pointing/input devices are allowable only if they provide equivalent functionality (cursor movement and text entry).
  - The hardware/display must support a minimum screen resolution of 800×600.

- Communications constraints:
  - No network or external communications interfaces are required or used.

- Data storage constraints:
  - Saved games and player statistics shall be stored in files managed by the application (file-based persistence).

- User interface constraints:
  - The interface shall use menus, graphics, and sounds; sound is optional and not required to play.

- Operational constraints:
  - The system supports only one user per machine at a time.

## 3.7 Software system attributes
- Reliability: [N/A]
- Availability: [N/A]
- Security: [N/A]
- Maintainability: [N/A]
- Portability:
  - The product uses the Qt graphical library.
  - The product must run with all the operating systems that Qt supports.
  - The software must be portable to the Windows OS.

## 3.8 Supporting information
This section consolidates supporting/background information available in the original SRS and identifies items not provided.

- a) Sample input/output formats; descriptions of cost analysis studies; results of user surveys:
  - [N/A]

- b) Supporting or background information to help readers:
  - Product overview:
    - Qheadache is a standalone computerized puzzle game that uses menus, graphics, and sounds.
    - Users interact via keyboard and mouse; other similar pointing/typing devices are allowable.
    - A graphical display of at least 800×600 resolution is required; sound is not required.
    - The product uses the Qt graphical library and must run on operating systems supported by Qt.
  - Users:
    - Anyone who wants to play a simple game; beginner level from age 8 to adult; no qualification is necessary.
  - Gameplay context:
    - The game board is a rectangular area (height 5x, width 4x; 50 ≤ x ≤ 100 pixels) with yellow blocks separated by 0.1x margin on a black background.
    - Blocks include: four x-by-x squares; four 2x-by-x rectangles; one x-by-2x rectangle; one 2x-by-2x square.
    - The player selects, moves, and deselects blocks using mouse actions; movement is constrained to avoid overlap and to stay within the board with at least 0.05x spacing from other blocks.
    - The interface includes menu-driven actions (Undo/Redo, File operations, Statistics, Help) and dialogs/windows for finishing and statistics display.

- c) Description of the problems to be solved by the software:
  - Provide an interactive block-sliding puzzle in which the player wins by moving the 2x-by-2x “great square” block to the bottom of the board.
  - Track and display player statistics (move count and elapsed time), support Undo/Redo of up to 1000 actions, and manage a high-score list (up to 10 entries), including display and erasure.
  - Enable persistence of game state and statistics through open/save/save-as operations and prompt to save on exit if there are unsaved changes.

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

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

# 4 Verification
[NULL]

## 4.1 Functions
This section defines the planned verification approaches and methods for the software functions. For each function, verification will address:
- Inputs and validity checks
- Exact sequence of operations
- Responses to abnormal situations (overflow, communication facilities [N/A], hardware faults/failures [N/A], error handling and recovery)
- Effect of parameters
- Relationship of outputs to inputs (including input/output sequences and any applicable formulas)

General verification methods
- Requirements review and UI inspection against stated content, wording, and ordering.
- Unit tests for state transitions, counters, timing, and file I/O components.
- Integration and system tests for end-to-end sequences (menu actions, gameplay, finish flow, statistics).
- Boundary value and equivalence class tests for numeric bounds (e.g., x, margins, history sizes, name length, list capacities).
- Fault-injection tests for file system errors where specified (e.g., permissions, disk full).

Main window and user interface composition
- Inputs and validity checks: Launch application. Verify main window appears with a board and a menu bar. No input validity checks apply.
- Sequence: On start, main window contains: a board and a menu bar; UI uses menus, graphics, and sounds (sound not required to play).
- Abnormal responses: Screen resolutions below 800×600 and sound device absence handling are not specified; verify only that the product remains operable without sound as required; other behaviors are [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Presence of board and menu bar verified visually upon launch.

Board presentation (dimensions, blocks, colors)
- Inputs and validity checks: Internal parameter x must satisfy 50 ≤ x ≤ 100 pixels. Verify board is 5x high and 4x wide, margins between blocks are 0.1x, and blocks are instantiated with the specified counts and sizes without overlap.
- Sequence: On board render, verify layout and colors (board black, blocks yellow).
- Abnormal responses: x outside bounds handling is not specified; verification confirms only that the chosen x complies. Overflow: [N/A]. Communication/hardware: [N/A]. Error handling: [N/A].
- Effect of parameters: Vary x at its lower and upper bounds (50 and 100) to confirm proportional scaling of blocks and margins.
- Outputs vs inputs: Visual layout must match size formulas based on x and specified block inventory.

Block selection (left-click down on a block)
- Inputs and validity checks: Clicks inside a block select it; clicks outside blocks do not start movement. Verify selection occurs only on valid targets.
- Sequence: State transition from “Block selection” to “Block movement” on valid left-click down.
- Abnormal responses: Clicks on non-block areas have no effect; no other error handling specified. Overflow/communication/hardware: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: No explicit output required; verify internal state transition occurred.

Block movement (mouse move while in movement state)
- Inputs and validity checks: Mouse movement drives block movement; enforce constraints: no overlap with other blocks, cannot exit the game zone, must remain at least 0.05x from other blocks. Verify boundary adherence and collision prevention.
- Sequence: While mouse moves, selected block follows within constraints; on constraint breach attempts, block position remains at the nearest valid location.
- Abnormal responses: Attempts to violate constraints are prevented without crash; overflow/communication/hardware: [N/A].
- Effect of parameters: Verify min distance 0.05x and margins 0.1x are respected at x’s boundary values.
- Outputs vs inputs: Visual position updates correspond to mouse movement constrained by rules.

Block deselection (left-click up on selected block)
- Inputs and validity checks: Left-click release over the selected block ends movement.
- Sequence: State transition back to “Block selection.”
- Abnormal responses: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: No explicit output; verify state transition.

Undo action
- Inputs and validity checks: Menu selection “Undo” available only if there was a previous movement. Verify disabled state when not applicable.
- Sequence: On Undo, positions revert to the state before the last movement; Undo itself counts as a movement. Verify counter increment behavior and board redraw.
- Abnormal responses: Overflow: verify ability to undo up to the last 1000 actions (as required in product functions). Beyond 1000, older actions are not undoable; menu remains disabled when history exhausted. Communication/hardware: [N/A]. Error handling: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Board display reflects the prior state of blocks; movement count and any displayed metrics update accordingly.

Redo action
- Inputs and validity checks: Menu selection “Redo” available only if the previous action was an Undo. Verify disabled otherwise.
- Sequence: On Redo, positions revert to the state before the last Undo; Redo counts as a movement; board redraws.
- Abnormal responses: Overflow analogous to Undo history boundaries; communication/hardware: [N/A]. Error handling: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Board display reflects the re-applied movement; counters update accordingly.

End of game detection and finish windows
- Inputs and validity checks: Trigger when the great square is moved to the bottom of the board. Verify detection only when condition is true.
- Sequence: On end trigger, freeze player statistics; choose window:
  - If current number of block movements is lower than the highest number recorded in the statistics file, display “Finish Window with Statistics.”
  - Otherwise, display “Simple Finish Window.”
- Abnormal responses: Statistics file absence or emptiness behavior is not specified [N/A]. Communication/hardware: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Correct window displayed per comparison; stats become immutable thereafter.

Finish Window with Statistics
- Inputs and validity checks: Text field accepts up to 20 characters for player name; verify boundary at 20 characters and rejection/truncation beyond (exact handling beyond 20 not specified; acceptance limited to 20 will be verified).
- Sequence: On clicking OK, record player statistics per Game Statistics management; close finish window and display Statistics Window.
- Abnormal responses: File write failures (permissions, disk full) reported per Game Statistics management; verify error message is displayed; no partial/corrupted entry committed.
- Effect of parameters: [N/A].
- Outputs vs inputs: New entry reflects input name, movement count, and time; subsequent Statistics Window displays the updated list.

Simple Finish Window
- Inputs and validity checks: Click OK.
- Sequence: Close window; display Statistics Window.
- Abnormal responses: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Statistics Window shown; no stats file update from this window.

Player statistics (during game)
- Inputs and validity checks: A block movement event triggers updates. Verify initial values at start of game (0 movements, 0 time).
- Sequence: On each movement:
  - Increment movement count by 1 (including Undo/Redo, as they are considered movements).
  - Record time as the difference between the movement time and the previously recorded time; verify cumulative time increases monotonically.
- Abnormal responses: System clock anomalies handling not specified [N/A]. Overflow: long-duration play not specified [N/A]. Communication/hardware: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Where time and movement counts are displayed, verify values reflect recorded updates as specified.

Game statistics (persistent top 10)
- Inputs and validity checks: Triggered after Finish Window with Statistics completion.
- Sequence: Append new player statistics (name, movement count, time). If 10 entries already exist, remove the entry with the greatest number of block movements before adding the new one.
- Abnormal responses: On file update errors (permissions, disk full), display error message and leave prior statistics intact; verify no partial writes.
- Overflow: Verify capacity constraint at exactly 10 entries; tie-breaking for “greatest” not specified [N/A].
- Communication/hardware: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: After successful write, subsequent displays reflect updated list.

Statistics erasing
- Inputs and validity checks: Menu selection “Erase.”
- Sequence: Erase all statistics from the statistics file.
- Abnormal responses: On file update errors (permissions, disk full), display error message; verify that statistics remain unchanged.
- Effect of parameters: [N/A].
- Outputs vs inputs: After success, Statistics Window (on display) shows empty list; after failure, list remains as before and error is shown.

Statistics Window (display)
- Inputs and validity checks: Opened via end-of-game flow or via menu selection “Display.”
- Sequence: Read statistics file and render a listbox of 10 lines, each line containing player name, number of movements, and time.
- Abnormal responses: Behavior on missing/corrupted file not specified [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Verify content matches data persisted in the statistics file. Ordering is not specified [N/A].

File management: Open game
- Inputs and validity checks: Menu selection “Open game…”; verify a file chooser dialog appears; selected file is expected to be a valid save.
- Sequence: Load file; redraw board according to file; set player statistics to saved values.
- Abnormal responses: Behavior on invalid file/format not specified [N/A]. File-not-found handling not specified [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Visual state and counters match saved data.

File management: Save game
- Inputs and validity checks: Menu selection “Save Game…”. If the game was never saved, behavior must be identical to “Save Game As…”.
- Sequence: Persist to the previous save file (or invoke Save As if first time) the following data: current positions of blocks, their last 10000 previous positions, number of previous movements, and the time passed by the user.
- Abnormal responses: Error handling for save failures is not specified [N/A].
- Overflow: Verify persistence of history up to 10000 previous positions.
- Effect of parameters: [N/A].
- Outputs vs inputs: Subsequent Open must restore the saved state and history per specification.

File management: Save game as
- Inputs and validity checks: Menu selection “Save Game As…”.
- Sequence: Display file chooser; then save current positions, previous positions, number of previous movements, and time.
- Abnormal responses: Error handling for save failures is not specified [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Subsequent Open restores saved data.

File management: Exit
- Inputs and validity checks: Menu selection “Exit.”
- Sequence: If the game is not saved, display a dialog with choices “Yes” and “No.”
  - If “Yes”, perform Save then close the main window.
  - If “No”, close the main window without saving.
- Abnormal responses: Save failure behavior not specified [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Application exits according to selected option; if saved, subsequent Open reflects last saved state.

Menu bar: Game menu
- Inputs and validity checks: Items present in order: “Open game…”, “Save Game…”, “Save Game As…”, “Exit.”
- Sequence: Each item invokes the corresponding action as specified under File management.
- Abnormal responses: As per each action; additional menu-level handling [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Menu closes; invoked action proceeds.

Menu bar: Action menu
- Inputs and validity checks: Items present in order: “Undo”, “Redo.” Each item disabled when its action is unavailable (no previous movement; previous action not Undo).
- Sequence: Invokes Undo/Redo as specified.
- Abnormal responses: As per Undo/Redo; menu-level handling [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Menu closes; board and counters update per action.

Menu bar: Statistics menu
- Inputs and validity checks: Items present in order: “Display”, “Erase.”
- Sequence: “Display” opens Statistics Window; “Erase” erases statistics per specification.
- Abnormal responses: For “Erase”, file errors produce an error message; for “Display”, missing file behavior [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Menu closes; corresponding window/action occurs.

Menu bar: Help menu
- Inputs and validity checks: Contains “About.”
- Sequence: Selecting “About” displays an About window with the exact text: “Qheadache 1.0 by Jean-Philippe Brossat jp_brossat@yahoo.fr”
- Abnormal responses: [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Menu closes; About window displays the specified text.

Product functions: time and movement display; score record; score window
- Inputs and validity checks: During play, verify that time used and number of actions are counted and displayed; on finish with statistics, verify that score (time and movement count) is associated with entered player name; verify score window displays all players’ scores (per Statistics Window).
- Sequence: Real-time updates during movements; on finish, record and then display statistics.
- Abnormal responses: File write errors produce an error message per Game statistics; display behavior on empty set [N/A].
- Effect of parameters: [N/A].
- Outputs vs inputs: Displayed time and counts match recorded statistics; persisted entries match displayed entries.

Abnormal situation categories not applicable or unspecified
- Communication facilities: [N/A] (communication interfaces are not applicable).
- Hardware faults and failures: [N/A] (no requirements stated).
- Unspecified error handling: Where behavior is not defined (e.g., invalid save file, clock anomalies, missing statistics file), verification will record [N/A] with no pass/fail criterion derived from requirements.

## 4.2 Performance requirements
This section defines the verification methods to qualify the software against its performance (capacity) requirements. Where no numerical performance requirement exists in the SRS, this is noted as [N/A].

- Static numerical requirements verification
  - Simultaneous users: exactly one user per machine.
    - Method: Attempt to start multiple concurrent instances on the same machine; verify either single-instance enforcement or that concurrent sessions do not share or corrupt state. Review documentation to confirm single-user assumption. Pass criteria: no more than one effective user session per machine.
  - Minimum display resolution: 800×600 screen resolution required.
    - Method: Execute the application on a system constrained to 800×600; verify all UI elements (board, menus, dialogs) are fully visible and usable without clipping or scrollbars. Pass criteria: all UI accessible at 800×600.
  - Undo/Redo capacity: last 1000 actions.
    - Method: Automated test performs 1001 valid moves. Verify 1000 successive undos are possible and the 1001st undo is unavailable; then verify corresponding redo availability and limits (redo only after undo, up to 1000). Verify menu items are disabled when actions are unavailable. Pass criteria: exact 1000-action history honored for both undo and redo.
  - Statistics capacity: at most 10 player statistics retained; on overflow, entry with greatest number of block movements is erased.
    - Method: Pre-populate stats with 10 entries spanning different move counts; add an 11th entry and verify the one with the greatest move count is removed. Verify persistence across application restart. Pass criteria: exactly 10 entries retained with correct removal policy.
  - Saved history depth (“Save Game”): persist last 10000 previous positions along with current positions, move count, and elapsed time.
    - Method: Perform >10000 moves (e.g., 10050), invoke “Save Game,” then inspect serialized state (white-box/file inspection or instrumented logging) to confirm exactly 10000 previous positions are persisted. Reload the saved game and verify the persisted history is restored per specification. Pass criteria: 10000 previous positions saved and restored by “Save Game.”
  - Finish window name length: edit box accepts up to 20 characters.
    - Method: Boundary input test with 20 and 21 characters. Pass criteria: 20-character input accepted and stored; input beyond 20 characters cannot be entered.

- Dynamic numerical requirements verification
  - Response times, throughput, peak/normal workload performance: [N/A]

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
This section defines the verification approaches for the software’s logical data persistence (files used to store statistics and saved games). The items are organized in parallel with the logical database requirement items a) through g).

- a) Types of information used by various functions
  - Player statistics (3.2.3.1, 3.2.3.2, 3.2.3.4): player name (entered via a 20-character edit box), number of block movements, time used to solve the game.
    - Verification methods:
      - Functional test: Complete a game (3.2.2.1), enter a name in the “Finish Window with Statistics” (3.2.2.2), then verify the “Statistic Window” (3.2.3.4) displays the added entry with the correct name, move count, and time.
      - Inspection: After the above, inspect the software’s statistic file to confirm the recorded fields and values match those shown in the Statistic Window (field presence and value equivalence).
      - Boundary test: Enter a 20-character name and verify it is accepted and recorded; attempt to exceed 20 characters and verify the UI constraint prevents excess input per 3.2.2.2.
  - Saved game data (3.2.4.1–3.2.4.3): current positions of blocks, previous positions (for Save: last 10000 previous positions per 3.2.4.2; for Save As: previous positions per 3.2.4.3), number of previous movements, time passed.
    - Verification methods:
      - Functional test: Perform moves, Save (3.2.4.2), exit, reopen via Open (3.2.4.1); verify the board display and player statistics match the pre-save state (3.2.4.1.4).
      - Inspection/analysis: For Save (not Save As), confirm that the saved game file contains data for the current positions, the last 10000 previous positions, the number of previous movements, and the elapsed time (as specified in 3.2.4.2.3).
      - Functional test: Use Save As (3.2.4.3), reopen via Open, verify the board and statistics match.

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

- c) Accessing capabilities
  - Open game (3.2.4.1), Save game (3.2.4.2), Save game as (3.2.4.3), Exit with save prompt (3.2.4.4), display statistics (3.2.3.4), erase statistics (3.2.3.3), update statistics at finish (3.2.2.2).
    - Verification methods:
      - Functional tests: Execute each menu action per 3.2.5 (Game, Statistics menus) and verify the described processing and outputs occur (e.g., dialogs appear, windows close/open as specified).
      - Negative tests for statistics write failures (3.2.3.2.4, 3.2.3.3.4): simulate wrong permissions or disk full when updating/erasing the statistic file; verify that an error message is displayed.
      - Exit behavior (3.2.4.4): with unsaved changes, verify the save prompt; choose “Yes” and confirm the game is saved before exit; choose “No” and confirm exit without saving.

- d) Data entities and their relationships
  - Entities:
    - Statistic file (3.2.3.2): contains up to 10 player statistics (name, move count, time).
    - Saved game file (3.2.4.1–3.2.4.3): contains board positions, position history, move count, elapsed time.
  - Relationships:
    - Finish Window with Statistics updates the statistic file (3.2.2.2 → 3.2.3.2); Statistic Window reads from the statistic file (3.2.3.4).
    - Open/Save/Save As read/write saved game files and set current board and player statistics accordingly (3.2.4.1, 3.2.4.2, 3.2.4.3).
    - Verification methods:
      - Pre-populate statistic file with 10 entries, then complete a game to add a new entry; verify that the entry with the greatest number of block movements is erased per 3.2.3.2.3 and the new entry is stored.
      - After saving a game, perform Open and verify the board state and player statistics are restored (3.2.4.1.4).
      - After Finish and statistics update, verify that the Statistic Window displays entries read from the file (3.2.3.4.1).

- e) Integrity constraints
  - Maximum of 10 player statistics retained (3.2.3.2.1).
  - Replacement policy: when already at 10, erase the file entry with the greatest number of block movements before recording the new one (3.2.3.2.3).
  - Name input limited to 20 characters (3.2.2.2.1).
  - Save game (3.2.4.2): must include current positions, last 10000 previous positions, number of previous movements, and elapsed time.
  - Verification methods:
    - Boundary tests on statistics: add entries until reaching 10; add an 11th and verify the replacement rule is applied exactly as stated.
    - Boundary test on name length: verify acceptance of 20 characters and non-acceptance beyond 20 via the UI control; confirm stored value matches entered value.
    - Persistence integrity: after Save and subsequent Open, confirm that the move count and elapsed time equal the values at the time of saving; confirm board positions are identical to the saved state.
    - History size for Save: generate more than 10000 moves, Save, and inspect/analyze the saved data to confirm only the last 10000 previous positions are persisted (3.2.4.2.3).

- f) Security
  - [N/A]

- g) Data retention requirements
  - Statistic file holds 10 player statistics (3.2.3.2.1); statistics can be erased via menu (3.2.3.3); statistics are displayed at end of game or by menu (3.2.3.4).
  - Saved game data retained across sessions until overwritten by subsequent saves (3.2.4.2, 3.2.4.3).
  - Verification methods:
    - Persistence across runs: create statistics, close and reopen the application, verify the Statistic Window still displays the same entries.
    - Erase operation: invoke “Erase” (3.2.5.3), verify entries are removed; attempt to display statistics and confirm the window reflects the erased state; for write failures, verify error message per 3.2.3.3.4.
    - Save/overwrite: Save a game; Save again to the same file (3.2.4.2) and via Save As to a new file (3.2.4.3); confirm the latest saved state is what Open restores.
    - Exit behavior: verify that choosing “Yes” at the exit prompt preserves the current game state for later Open, and “No” does not alter existing saved data (3.2.4.4).

## 4.6 Design constraints
Verification of design constraints will be performed by inspection, analysis, and test activities aligned to each constraint defined in Requirements 3.6.

- Dependency on Qt graphical library
  - Method: design/code inspection of UI layer to confirm Qt API usage; build configuration review to confirm Qt is the only GUI dependency; runtime dependency check to verify Qt libraries are loaded.
  - Acceptance: build artifacts link only against Qt for GUI; application starts and renders using Qt widgets.

- Cross-platform operation on all operating systems supported by Qt
  - Method: installation and smoke/regression tests on each Qt-supported operating system [N/A: specific OS list], covering launch, UI rendering, input handling, file operations, game loop, save/load, and end-of-game flows.
  - Acceptance: all tests pass on each targeted OS; no OS-specific defects block core gameplay.

- Portability to Windows OS
  - Method: build-and-run test on supported Windows versions [N/A: specific versions], including installer execution, first-launch, full playthrough, save/load, and exit with unsaved-changes prompt.
  - Acceptance: all actions complete without errors on Windows; no Windows-specific code issues remain.

- Stand-alone application with no communications interfaces
  - Method: offline operation tests with network adapters disabled; network activity monitoring during typical and edge-case usage.
  - Acceptance: no network connections are initiated; all features function with no network available.

- Hardware/input device constraints (keyboard and mouse; other pointing devices allowable)
  - Method: functional tests using keyboard and mouse for menu selections, naming, and gameplay interactions; spot checks with common alternative pointing devices (e.g., trackpad).
  - Acceptance: full operability with keyboard and mouse; alternative pointing devices behave equivalently for cursor movement and selection.

- Display resolution constraint (minimum 800×600)
  - Method: UI conformance tests on a system configured to 800×600, verifying main window, board, menus, dialogs (save/open, finish, stats, about) fully fit and remain usable without clipping or hidden controls.
  - Acceptance: all UI elements are visible and usable at 800×600.

- Sound not required to play
  - Method: tests with audio device disabled or volume muted; verify launch, gameplay, and completion without audio resources present.
  - Acceptance: no errors or degraded functionality when audio is unavailable; optional sounds do not block gameplay.

- Single-user per machine
  - Method: review of features for absence of multi-user or concurrent session capabilities; attempt to run multiple concurrent instances and observe shared resources (e.g., stats file) for conflicts.
  - Acceptance: application behavior remains single-player; concurrent instance execution does not introduce multi-user features or data corruption.

- GUI modality (menus, graphics, sounds)
  - Method: UI review against menu structure specified (Game, Action, Statistics, Help) and presence of graphical rendering for the board and blocks; check About dialog content.
  - Acceptance: menu items and dialogs match specification; graphical board renders correctly; About content matches required text.

## 4.7 Software system attributes
This section defines the verification approaches to qualify the software system attributes and mirrors the attributes specified in Requirements section 3.7.

- Reliability
  - [N/A]

- Availability
  - [N/A]

- Security
  - [N/A]

- Maintainability
  - [N/A]

- Portability
  - Verification objective
    - Demonstrate that the software:
      - Runs on the Windows OS.
      - Runs on all operating systems supported by the Qt graphical library, as targeted by the product.
  - Methods
    - Design/code review
      - Review source to confirm use of Qt APIs for GUI and platform services and absence of non-Qt, OS-specific dependencies.
      - Review build/project configuration to ensure no hard-coded, platform-specific flags or paths that prevent cross-platform builds.
    - Build verification
      - Build the unmodified source on Windows OS.
      - Build the unmodified source on each targeted Qt-supported operating system. Target OS list: [N/A].
    - System/functional execution tests on each targeted OS (including Windows)
      - Launch and shutdown: application starts and exits cleanly.
      - Display: UI renders correctly at a minimum resolution of 800x600.
      - Input devices: keyboard and mouse operate as specified (selection, movement, menu navigation).
      - Core gameplay functions: board presentation and dimensions, block selection/deselection/movement constraints, Undo/Redo up to the specified limits, end-of-game detection and finish windows.
      - Statistics: in-game counting of moves and time, recording on completion, display and erasing of statistics, error handling for file update failures.
      - File management: open, save, save as, and exit behaviors function without modification to paths or formats across targeted OS environments.
      - Menus: availability and behavior of Game, Action, Statistics, and Help menus, including About dialog text.
      - Sound optionality: confirm that sound is not required to play.
    - Acceptance criteria
      - The software compiles without source changes and passes the above execution tests on Windows OS and on each targeted Qt-supported OS.
      - No platform-specific defects prevent feature parity or required behaviors on any targeted OS.

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
- Availability of the Qt graphical library and its supported operating systems. The product depends on Qt for menus, graphics, windows, and dialogs and is assumed to run on operating systems supported by Qt (including Windows). Changes in Qt availability or supported platforms may alter interface and portability requirements.
- Presence of a graphical desktop environment capable of displaying windows at a minimum resolution of 800x600. If this minimum cannot be met, board sizing and UI layout requirements would change.
- Availability of standard input devices: a keyboard and a pointing device (mouse or equivalent that can move a cursor and select UI elements and allow text entry). If such devices are unavailable or replaced with non-equivalent devices, interaction requirements would change.
- Sound hardware is optional. The game assumes that absence of sound hardware does not affect core gameplay; if sound becomes mandatory, interface requirements would change.
- Reliable access to a system clock/timer to measure and display elapsed play time. If time services are unreliable or unavailable, statistics and scoring requirements would be affected.
- Availability of a local file system with sufficient permissions and free space to read/write save games and a statistics file. If disk space is insufficient or permissions are restricted, persistence-related requirements (saving, loading, and statistics recording) may need to change.
- Typical memory and storage capacity sufficient to maintain undo/redo history and to save prior block positions (up to the quantities specified). If memory/storage is constrained, the limits on history depth or save content may need revision.
- Single-user, single-machine usage context. Requirements assume only one user per machine at a time; if multi-user or concurrent use is introduced, file access, statistics management, and session handling requirements would change.
- Target users can operate a computer (including using menus and typing a name up to 20 characters). If the user population or skills differ, usability and interface requirements may need adjustment.
- No network or external communications are required. If network features are introduced, communications interface and security requirements would change.

## 5.2 Acronyms and abbreviations
- SRS: Software Requirements Specification
- OS: Operating System
- Qt: Qt graphical application framework/library
- OK: Conventional confirmation button label meaning “Okay”
