KiloKiloFoxtrot FINAL

C++ Design Document

Justin Kelly, Robert Kirkwood and Kalan Fry With our powers combined! We are CAPTIAN C++ Plannert

Team Kilo Kilo Foxtrot Wei Shi 12/12/2007

Page | 1

Introduction The Objective of your Product To implement a fun and challenging logic game called Sudoku 1514 based around the popular logicbased placement puzzle Sudoku. This game is to be released by GDIII (Game Dev III Incorporated). This product is to be used as a recruitment tool for a Logic Game Competition in 2010. The game is interactive and engaging to inspire users to join the Logic Game Competition, as well as to advertise and boost of image. The project is created for web distribution.

Document Content Overview Introduction .................................................................................................................................................. 2 The Objective of your Product .................................................................................................................. 2 Document Content Overview ................................................................................................................... 2 Description of the System ............................................................................................................................. 4 Assumptions.................................................................................................................................................. 4 Requirements................................................................................................................................................ 4 Use Case Diagram and STDs .......................................................................................................................... 6 Case Diagram ........................................................................................................................................... 6 Case Descriptions ...................................................................................................................................... 6 Primary Cases ........................................................................................................................................ 6 Secondary Cases: .................................................................................................................................. 8 Class Diagram .......................................................................................................................................... 12 Sequence Diagram .................................................................................................................................. 13 References .................................................................................................................................................. 14 Traceability.................................................................................................................................................. 14 Traceability from requirements to Case Study Description.................................................................... 14 Traceability from use cases to requirements and assumptions ............................................................. 14 Traceability from use case description to use case diagram (UCD)........................................................ 14 Traceability from sequence diagrams SD to use case description.......................................................... 14 Traceability from class diagram to sequence diagram ........................................................................... 14 Test Plan ...................................................................................................................................................... 15 Test Plan Identifier (TPI).......................................................................................................................... 15 References .............................................................................................................................................. 15 Page | 2

Introduction ............................................................................................................................................ 15 Test Items................................................................................................................................................ 15 Software Risk Issues ................................................................................................................................ 16 Features to be Tested ............................................................................................................................. 16 Features not to be Tested ....................................................................................................................... 16 Approach ................................................................................................................................................. 16 Item Pass/Fail Criteria ............................................................................................................................. 16 Entry & Exit Criteria................................................................................................................................. 17 Suspension Criteria and Resumption Requirements .............................................................................. 17 Test Deliverables ..................................................................................................................................... 17 Remaining Test Tasks .............................................................................................................................. 17 Environmental Needs.............................................................................................................................. 17 Staffing and Training Needs .................................................................................................................... 17 Responsibilities ....................................................................................................................................... 17 Planning Risks and Contingencies ........................................................................................................... 17 Approvals ................................................................................................................................................ 18

Page | 3

Description of the System The System is a Windows Based MFC executable. As a result its native environment is solely windows. It is expected and tested to perform on Algonquin College lab. The system is a MFC based GUI created from buttons. The system works on a click response mechanism (action triggers a response) – in our case a mouse to button click. Upon clicking the user is enabled to insert a number into a Sudoku square, this is done by hitting a key on the num pad changing the number (image) of that square. Depending on the game type the player then alternates between the other players in play. The users continue until the puzzle is complete. Upon completion of the puzzle the winning player is rewarded with a congratulatory message. If the players time is under the time from the cut-off time (a global variable that is updated from a master server), the player is given a second message asking them to sign up for the tournament at a directed website.

Assumptions • • • • • •

All users of this product own computers/devices that run windows executables. The Sudoku being played is the standard 9 grid version with no deviation. Users of this game have strong working knowledge of the game. No distribution is needed for multiplayer play. When the Player Errors on a Two or single player game then he is allowed to continue. To facilitate single player as a recruitment tool in non tournament/non group play, the addition and tracking of player speed and the rewarding of points based on speed is allowed.

Requirements Requirements are the Functional: Requirements needed to run / complete project goals, their absence results in project failure; and non functional: requirements that assist the project goals but their absence does not result in project failure. Functional: 1. Must be called Sudoku 1514 2. Must Allow Single or Multiple Players to Play. a. LAN up to 3 players b. Must adhere to the rules and regulations of the client/server model found in Sudoku 3004 visualization components. c. Alternating turns. i. Must Limit to 30 seconds ii. Allowed Placement up to 3 digits. 3. Must have player registration using Unique Names 4. Must not allow users to hold an already used Unique Name. 5. Must stop more than 3 users from joining a single game. Page | 4

6. New users/players to Instances exceeding 3 players in play, Must be allowed/forced to spectate. 7. A waiting List holds the spectators. a. Must allow the player to watch the game in play. b. Must not allow the player to play from the waiting list. 8. All players must be allowed to leave the game at any time. 9. Must allow the placement and removal of digits on the board. 10. Must check for wins 11. Must Track Scoring a. Must Give -100 Points for every incorrect number placement i. On incorrect placement number must be removed and player score updated. b. +100 points is rewarded per correct placement of a digit, done in a turn. c. +150 points is added to the player for each row, column or 3x3 box complete by a placement. d. Score must be used in the determination of a winner 12. Game is finished when the puzzle is completed. a. Upon competition the user with the greater score will be named the winner. b. In Single Player Games the player is tracked by score and speed to puzzle completion. The user is rewarded score based on time, and is checked against a master server. i. Upon being swift the player is rewarded with an invite to future tournaments. Non-Functional: 1. 2. 3. 4.

A Impressive GUI Timer Display Score Display User interaction done by Num pad.

Page | 5

Use Case Diagram and STDs Case Diagram

Case Descriptions Primary Cases ID STD1 STD2 STD3

STD TITLE Starting Interface Registration Interface Game Engine

STD1: Starting Interface Description: The interface that prompts the user how to start. Actors: User, System Pre-condition: The user must initiate (run) the application. Triggering Event: Automatic from start-up, run from the system. Sequence: Application begins, interface loads. Uses secondary conditions 1.1, 1.2, 1.3 Post Condition: Game initiates the Registration Interface. Resulting Events: Jump to STD2 (Registration Interface). Alternative Scenarios: User quits the application.

Requirements

FR1, NFR1

N/A

Page | 6

Non-functional requirements: -Impressive GUI -User interaction VIA Numpad.

NFR-1

STD2: Registration Interface Description: The interface allowing the user to register multiple players. Actors: User, System Pre-condition: Must have initiated the starting interface (STD1). Triggering Event: Players are to be registered and named here. Sequence: Players are registered by name, type (CPU or human) and by the total number of players available. Uses secondary conditions 2.1, 2.2 Post Condition: Players are registered. Resulting Events: Jump to STD3 (Game Engine). Alternative Scenarios: N/A Non-functional requirements: -Impressive GUI

Requirements

STD3: Game Engine Description: The actual game of Sudoku that multiple people take turns to play, until the board is clear and there is a winner. Actors: User, System Pre-condition: Must have registered all players (STD2). Triggering Event: Players take turns clearing the grid. Sequence: Each player takes turns adding the numbers 1-9 to the Sudoku grid, under the time and turn guidelines. They switch and gather points until the board is clear and a winner is named. Uses secondary conditions: 3.1 to 3.7. Post Condition: Game is completed. Resulting Events: Players may set up the board to play again. Alternative Scenarios: Players may also quit the game. Non-functional requirements: -Impressive GUI -Timer Display -Score Display -User interaction VIA Numpad.

Requirements

FR2, FR3, FR4, FR5, FR6, NFR1

NFR-1

FR2, FR5-12, NFR1-4

NFR1-4

Page | 7

Secondary Cases: Part of Primary Case: STD 1 STD 1 STD 1 STD 2 STD 2 STD 3 STD 3 STD 3 STD 3 STD 3 STD 3 STD 3

ID 1.1 1.2 1.3 2.1 2.2 3.1 3.2 3.3 3.4 3.5 3.6 3.7

STD Title. Application Launched. User Starts the Game. User Quits the Game. Choosing Human/CPU. Players named and registered. Initiate Sudoku Game. Game Cycle. Player Turn Finished. Check board completion. Players remaining. Game completion. Resetting the game.

STD1.1: Application Launched. Description: The user launches the program from the PC. Actors: User Pre-condition: N/A Triggering Event: Program launches. Sequence: Program initiates. Post Condition: Application is launched. Resulting Events: Starting interface launches. Alternative Scenarios: N/A Non-functional requirements: See STD1.

Requirements

STD1.2: User Starts the Game Description: The player starts the game from the starting interface. Actors: User Pre-condition: Program is launched (STD 1.1) Triggering Event: Click to start the game. Sequence: Launch the registration interface. Post Condition: Brings up registration interface. Resulting Events: Registration interface launches. Alternative Scenarios: Quit game (STD 1.3) Non-functional requirements: See STD1.

Requirements

STD1.3: User Quits the Game Description: The player quits the game from the starting interface. Actors: User Pre-condition: Program is launched (STD 1.3) Triggering Event: Click to exit the game. Sequence: Closes the program. Post Condition: Application is closed.

Requirements

See STD1.

See STD1.

See STD1.

See STD1.

See STD1.

Page | 8

Resulting Events: Application is closed. Alternative Scenarios: Start game (STD 1.2) Non-functional requirements: See STD1.

See STD1.

STD2.1: Choosing Human or CPU. Description: The player chooses either human or CPU players. Actors: User Pre-condition: Registration screen is initiated. Triggering Event: Human/CPU players are set. Sequence: Choose single/multiplayer game. Post Condition: Set game type. Resulting Events: Human/CPU players are set. Alternative Scenarios: Naming, Registering Players. Non-functional requirements: See STD2.

Requirements

STD2.2: Register Players. Description: Type player names using the keyboard. Actors: User Pre-condition: Registration screen is initiated. Triggering Event: Players are given unique names. Sequence: Players are registered. Post Condition: Players must be registered. Resulting Events: The game engine initiates. Alternative Scenarios: Setting player types, number of players. Non-functional requirements: See STD2.

Requirements

STD3.1: Initiate Game Engine. Description: All GUI and gameplay elements are loaded into play. Actors: System Pre-condition: All players are properly registered. Triggering Event: User registers players correctly. Sequence: All elements of the game are loaded into play. Post Condition: Everything in the game board must be loaded. Resulting Events: The game begins play. Alternative Scenarios: N/A Non-functional requirements: See STD3.

Requirements

STD3.2: Player Turns Description: Determine turn of next player. Actors: System Pre-condition: Player must have finished a turn (or the game just started). Triggering Event: Start game, finish a turn. Sequence: Game switches player turns. Post Condition: Must have switched to the next player. Resulting Events: The game continues under a different player.

Requirements

See STD2.

See STD2.

See STD2.

See STD2.

See STD3.

See STD3.

See STD3.

Page | 9

Alternative Scenarios: N/A Non-functional requirements: See STD3.

See STD3.

STD3.3: Calculate scores. Description: Update scores of all the players. Actors: System Pre-condition: Player must have finished a turn. Triggering Event: Start game, finish a turn. Sequence: Game updates the player scores. Post Condition: Scores must be properly updated. Resulting Events: The game has updated all scores. Alternative Scenarios: N/A Non-functional requirements: See STD3.

Requirements

STD3.4: Check game board. Description: Return yes/no if the Sudoku board is finished. Actors: System Pre-condition: Have the scores been recently updated? Triggering Event: Checks and returns status of the board. Sequence: If the board is complete, end the game. Post Condition: Have checked the board at least once per pass. Resulting Events: The game is either finished or not. Alternative Scenarios: Game finished or not? Non-functional requirements: See STD3.

Requirements

STD3.5: Players remaining. Description: Checks to see if there are one or more players remaining. Actors: System Pre-condition: Has anyone left the game? Triggering Event: Changes the remaining player to a CPU. Sequence: Change or add a CPU if less than two players available. Post Condition: Have at least two players in-game, human or CPU. Resulting Events: The game has two players. Alternative Scenarios: N/A Non-functional requirements: See STD3.

Requirements

STD3.6: Game Completed. Description: Checks to see if the board is completed. Actors: System Pre-condition: Has the board status been checked? (STD3.4) Triggering Event: Declare the game finished. Sequence: Indicate the game is over, declare a winner, ask player if they wish to play again. Post Condition: Have a finished board. Resulting Events: Game is over and either begins anew or ends. Alternative Scenarios: The game is not finished, jump to STD3.2.

Requirements

See STD3.

See STD3.

See STD3.

See STD3.

See STD3.

See STD3.

See STD3.

Page | 10

Non-functional requirements: See STD3.

See STD3.

STD3.7: Reset the Game. Description: Starts the game over. Actors: User Pre-condition: Has the reset button been pressed? Triggering Event: Reset the game. Sequence: Re-initialize the Game Engine and reset all scores (see STD3.1) Post Condition: Reset button was pressed. Resulting Events: Game is reset. Alternative Scenarios: N/A Non-functional requirements: See STD3.

Requirements

See STD3.

See STD3.

Page | 11

Class Diagram

Page | 12

Sequence Diagram

Page | 13

References The only thing in this project that is not of our creation are the images in the Project brochure.

Traceability The term traceability in this document is defined as “The ability to link requirements back to stakeholders' rationales and forward to corresponding design artifacts, code, and test cases.”

Traceability from requirements to Case Study Description The traceability from requirements to case study description should be apparent as all statements of demands or designs have been recorded as functional requirements to project completion. As a result there is full traceability between our chosen requirements and the case study description. Example: 2.2.5.1 requires scoring to be awarded in the sum of +100 for correct digit placement. 11.b (“100 points is rewarded per correct placement of a digit, done in a turn.“) is our implication of that requirement from the case study description.

Traceability from use cases to requirements and assumptions Passing along the because our use cased are built from our requirements which are built by the requirements in our case study description. We believe there is a high level of traceability here.

Traceability from use case description to use case diagram (UCD) The Case diagram seeks to expand on the core issues by showing an overview of all major interaction. Our case description as derived from them. Our case description then go into detail about the interaction and data being passed/created.

Traceability from sequence diagrams SD to use case description Our Sequence diagram displays the requirements of the project in a different light. Instead of raw words that look and sound the same like in the requirements and use cases, a sequence diagram seeks to show the flow of data between the user interface and system. It shows our virtual implementation of the project.

Traceability from class diagram to sequence diagram Our Class diagram is our classes that we have created to implement the project. As a result the traceability to the requirements and to all the other levels of the document are high. The Sequence diagram is no exception as the class diagram takes into consideration heavily the levels of interactions and from that builds how the data is to be passed.

Page | 14

Test Plan Our Test plan consists of the following parts as defined by IEEE 829 format. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

Test Plan Identifier (TPI). References Introduction Test Items Software Risk Issues Features to be Tested Features not to be Tested Approach Item Pass/Fail Criteria Entry & Exit Criteria Suspension Criteria and Resumption Requirements Test Deliverables Remaining Test Tasks Environmental Needs Staffing and Training Needs Responsibilities Planning Risks and Contingencies Approvals

Test Plan Identifier (TPI). Final Test for Sudoku 1514 - Final Build [12/12/2007 8:00:00 AM]

References • •

Sudoku1514V2.0.pdf This(document);

Introduction This propose of this test plan is provide a mid level demonstration and walkthrough for final presentation in GAM1513 FALL 2007.

Test Items This a high level overview of things we wish to test within the scope 1. 2. 3. 4.

Program’s activation User interactivity The Programs Ability to function Basic gameplay elements Page | 15

5. Graceful closing

Software Risk Issues Risks and areas of test in regards to overall program functionality. 1. 2. 3. 4. 5.

Test to ensure success on Target computer Test that its suitable for web distribution Ensure Localizations issues don’t exists Test for potential health and safety issues Ensure that the Japanese background is not culturally offensive.

Features to be Tested 1. 2. 3. 4. 5. 6.

Ability to click buttons. The ability for the buttons (Backend Variables) to store data. The ability to the resist data. The ability for the program to only count proper clicks. The ability for the program to display Icons The ability to leave the program.

Features not to be Tested 1. Anything deriving from multiplayer LAN support

Approach This is our step by step 1. 2. 3. 4.

5.

6. 7. 8. 9.

Install/move program to demo (testing) computer Start the program First start testing the ability for the user to interact with the program If Game is at a state programmed to disallow placement of wrong digits a. Place the level in the hands of a testing team and ask for 100 play iterations. b. Record speed of play, Scores and at any time if a player cannot click. If the game is at a state where it’s programmed to allow placement of wrong digits. a. Start by clicking every other button for player one while alternating every middle button for player two. (E.g. Player One: B1,B3,B5 - Player two: B2,B4,B6). b. If there is no player two, click all buttons in sequence from left to right as the first player. Having established the buttons are functional reset the play board and attempt to play a game. Note the ease of play and the ability to place numbers and the icon smooth change. Check if clicks are being counted from anything but button clicks. If applicable test for submission of wrong data like the F key or F2 Key.

Item Pass/Fail Criteria Page | 16

If the item fails to fulfill the requirements outlined at the start of the document then it is a fail. A pass is awarded to any item that meets or exceeds the above requirements.

Entry & Exit Criteria The Criteria as this test is doubling as a demo and not a true Test Plan, is merely the request of the stakeholder on the day that is to be presented. The exit criteria will be decided the judgment of the presenter (lead tester) on the satisfaction of the stakeholder and the level to which he/she has fulfilled the presentation requirements. The Number of failed items has no impact on exit criteria.

Suspension Criteria and Resumption Requirements The test will be suspended when • •

A Major defect arises (program fails to open) In the event the environment (lab) is unavailable

The test will resume when • •

The Major defect is resolved and a quick sweep proves no more are apparent. The environment (lab) available and secured.

Test Deliverables The project is being visually displayed to the stakeholder – no other deliverables are needed.

Remaining Test Tasks After this project test the only remaining testing will be for the outstanding network code (multiplayer LAN) aspects of the game.

Environmental Needs 1 (one) Computer in the Algonquin Computer T-Media labs is needed. As well as one (1) hour of time and three (3) chairs.

Staffing and Training Needs None

Responsibilities The Project leader will be responsible for any changes to the test plan. In the event of unforeseen issues or conflicts be it from nature, staffing, training or physical/financial resources he will handle those issues. Programming issues within the scope of the project can be corrected by any of the team’s programmers.

Planning Risks and Contingencies Page | 17

In the event of destruction or power loss of the lab, a laptop will be used to test the project. In the advent of total project failure, a attempt will be made to ‘persuade’ the professor.

Approvals Will be handled by group delegation in the event, which not all 3 members are present then it will be handled by the remaining 2 members. In the event of a dispute it will be handled by rock, paper, scissors done on paper best 2 of 3.

Page | 18