Document
Justin Kelly, Robert Kirkwood and Kalan Fry
With our powers combined! We are CAPTIAN C++ Plannert
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 logic-
based 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.
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:
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. A Impressive GUI
2. Timer Display
3. Score Display
4. User interaction done by Num pad.
Page | 5
Use Case Diagram and STDs
Case Diagram
Case Descriptions
Primary Cases
ID STD TITLE
STD1 Starting Interface
STD2 Registration Interface
STD3 Game Engine
Page | 6
Non-functional requirements: NFR-1
-Impressive GUI
-User interaction VIA Numpad.
Page | 7
Secondary Cases:
Page | 8
Resulting Events: Application is closed.
Alternative Scenarios: Start game (STD 1.2)
Non-functional requirements: See STD1. See STD1.
Page | 9
Alternative Scenarios: N/A
Non-functional requirements: See STD3. See STD3.
Page | 10
Non-functional 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.”
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.
Page | 14
Test Plan
Our Test plan consists of the following parts as defined by IEEE 829 format.
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. Program’s activation
2. User interactivity
3. The Programs Ability to function
4. Basic gameplay elements
Page | 15
5. Graceful closing
Features to be Tested
1. Ability to click buttons.
2. The ability for the buttons (Backend Variables) to store data.
3. The ability to the resist data.
4. The ability for the program to only count proper clicks.
5. The ability for the program to display Icons
6. The ability to leave the program.
Approach
This is our step by step
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.
• 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.
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.
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.
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