Lucky Strike Software
SRS
CPE 205/206-05
Signature: _____________________________
SRS
Credits Page:
Cover Page Kamil Baranowski
Credits Kamil Baranowski
Josh Thompson
1. Introduction
1.1 Purpose Kamil Baranowski
Antony George
1.2 Scope Kamil Baranowski
Antony George
1.3 Definitions, Acronyms, and Abbreviations Kamil Baranowski
Antony George
1.4 References Antony George
1.5 Overview Kamil Baranowski
Antony George
2. Overall Description
2.1 Product Perspective Josh Thompson
Antony George
2.1.1 Concept of Operations Josh Thompson
Antony George
2.1.2 User Interface Concepts Kevin Blomseth
Josh Thompson
Antony George
2.1.3 Hardware Interfaces Josh Thompson
2.1.4 Software Interfaces Josh Thompson
2.1.5 Communications Interfaces Josh Thompson
Antony George
2.1.6 Memory Constraints Josh Thompson
Antony George
2.1.7 Operations Josh Thompson
Antony George
2.1.8 Site Adaption Requirements Kevin Blomseth
2.2 Product Functions Josh Thompson
Antony George
Kamil Baranowski
Kevin Blomseth
Janice Lin
2.3 User Characteristics Antony George
Janice Lin
2.4 Constraints Antony George
Janice Lin
2.5 Assumptions and Dependencies Kevin Blomseth
Antony George
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces Josh Thompson
3.1.2 Hardware Interfaces Josh Thompson
3.1.3 Software Interfaces Josh Thompson
3.1.4 Communications Interfaces Josh Thompson
3.2 Specific Requirements Janice Lin
Kevin Blomseth
Josh Thompson
3.3 Performance Requirements Kevin Blomseth
3.4 Design Constraints Antony George
3.5 Software System Attributes
3.5.1 Reliability Antony George
Kevin Blomseth
3.5.2 Availability Antony George
Kevin Blomseth
3.5.3 Security Antony George
Kevin Blomseth
3.5.4 Maintainability Antony George
Josh Thompson
4. Supporting Information
4.1 Table of Contents Kevin Blomseth
4.2 Appendices Janice Lin
Kamil Baranowski
1. Introduction
1.1 Purpose:
This document provides all of the customer and developer requirements for an enhanced version of the Sokoban videogame to be produced. The intended audience of the first half of this document (sections 1 and 2), the C-Requirements, is the customer. The second half of this document (sections 3 and 4), the D-Requirements, is intended for the developers of the product.
1.2 Scope:
The software product to be produced is the Sokoban videogame with customer-desired enhancements. Sokoban is a puzzle solving game, challenging both the users mental ability as well as his ability to work as part of a team.
Sokoban will take place in a 2-dimensional environment in which a user controlled robot will be able to manipulate its environment (move boxes around) in order to complete its task. Sokoban will provide additional value by allowing cooperative play over the internet and including features such as instant replay and the ability for users to create their own levels with a level editor.
1.3 Definitions, Acronyms, and
Abbreviations:
See Appendix A
1.4 References:
See Appendix B
1.5 Overview:
The remaining portions of this document cover information pertinent to the customer and developers of the Sokoban videogame (see Appendix G: Table of Contents for a list of included information).
2. Overall Description
2.1 Product Perspective:
The Sokoban videogame will be an independent self-contained application. Like other versions of the Sokoban videogame this enhanced version to be produced will provide users with an entertaining and challenging puzzle-solving strategy game. Sokoban is intended to appeal to those individuals who enjoy solving puzzles using strategy and teamwork and to those simply seeking an enjoyable way to spend some time. Features which are to be included in this version of Sokoban are a save game and load game option, a cooperative multiplayer mode over the internet, a high scores list, and a level editor so users can design their own levels, and a tutorial intended for those who are new to the Sokoban videogame. The design of Sokoban will allow for modifications and additions, as desired, in future releases.
2.1.1 Concept of Operations:
Sokoban can be in one of the following modes.
1. Setting Up User decides which mode he wants to play
2. Single Player User is engaged in the single player mode of the Sokoban videogame
3. Cooperative User is engaged in the cooperative multiplayer mode of the Sokoban videogame. Cooperative mode takes place over the internet with up to 3 other individuals.
4. Tutorial User is engaged in the built in Sokoban tutorial program designed for those unfamiliar with the game
5. Edit User is engaged in the level editor mode of the Sokoban videogame. The user can create, edit and then save custom levels in this mode.
6. High Scores User is engaged in viewing the high scores for the Sokoban videogame
2.1.2 User Interface Concepts:
Sokoban will take place in a 2-dimensional world of walls and mazes. The 2-dimesional world can be manipulated by the user via the keyboard. See Appendix C for an
illustration.
2.1.3 Hardware Interfaces:
There are no hardware interfaces.
2.1.4 Software Interfaces:
There are no software interfaces.
2.1.5 Communications
Interfaces:
TCP/IP will be used to play cooperative multiplayer mode.
2.1.6 Memory Constraints:
Sokoban will require no more than 16 MB of RAM and 5 MB of hard disk space.
2.1.7 Operations:
In addition to starting a new Sokoban game users will be able to save their game progress as well as retrieve saved game information through a load game feature. Using the built in level editor it will be possible for users to create and customize their own levels. Also with the included cooperative multiplayer mode users will be able to play Sokoban cooperatively over the internet with up to three other people. There will also be a high scores list so the users accomplishments can be recorded. Instant reply and undo move options are also available.
2.1.8 Site Adaptation
Requirements:
There are no site adaptation requirements.
2.2 Product Functions:
Below is a list of use cases that describe all possible interactions between the user and the system with the intended results of the interactions.
Use Case 1 - Single Player
Game
1. User selects "New Solo Game"
2. System displays level name and all objects included in the level, including user controlled robot, moveable crate(s), and
incinerator and begins keeping track of the elapsed time
3. User inputs the desired direction of robot movement using arrow keys
4. System outputs appropriate sound and displays updated level, showing new location of robot and new locations of any crate that was moved
5. System updates number of moves, pushes and crates incinerated (if a crate was incinerated)
6. Once all crates in the current level are incinerated the system displays level finished screen, which shows all the stats for that
level. The total score represents the cumulative score of all the levels played so far.
7. System, once player clicks continue, then displays next level, and repeats steps 2 7. The score that appears in the score field is a cumulative score for entire game so far.
Use Case 2 Instant Replay
1. During a "Solo Game" the user selects "Instant Replay"
2. System outputs appropriate sound and displays all the moves, in order (first to last), the user has made up to the point where "Instant Replay" was
selected
3. System returns to state it was in before "Instant Replay" was selected
Use Case 3 Undo Move
1. During a "Solo Game" the user selects "Undo Move"
2. System updates level so that it is in the state that it was in
before the most recent move was made
Use Case 4 Restart Level
1. During a "Solo Game" user selects "Restart"
2. System reinitializes level to starting conditions, including all stats for that level
Use Case 5 End Game
1. During a "Solo Game" user selects End Game
2. System asks user if he or she wants to end the current game
3. If user selects "Yes" system returns user to main menu screen otherwise system returns to the state it was in before "End
Game" was selected except for elapsed time, which is
current
Use Case 6 Load Game
1. User selects "Load Game" (either from main menu or solo game)
2 System asks user if he or she wants to end the current game
3. If user selects "yes," system displays a pop-up window with all possible choices available to choose from otherwise
system returns to main menu or current solo game user is engaged in.
4. User makes a selection and then selects "Load"
5. System loads the file selected
Use Case 7 Change Robot
Color
1. User selects "Change Robot Color"
2. System displays window with the possible choices of color for the robot
3. User selects desired color and clicks OK
4. System implements change of robot color
5. System returns to level with new
Use Case 8 View High Scores
1. User selects "View High Scores"
2. System displays High Scores List
Use Case 9 Go To Level
1. During a "Solo Game" user selects "Go To Level"
2. System displays a pop-up window containing a list of playable levels for user to select from
3. Users selects desired level from the list and selects "OK"
4. System loads selected level for user to play
Use Case 10 Next Level
1. User selects "Next Level"
2. System loads the next level (if there is a next level) for user to play
Use Case 11 Previous Level
1. User selects the Previous Level option
2. System loads the Previous Level (if there is a previous level) for user to play
Use Case 12 Save Game
1. During a "Solo Game" user selects "Save Game"
2. System displays a pop-up window with fifteen slots to choose from
3. User selects a slot and gives the slot a description, if the user does not give the slot a description
4. System saves game and returns to state it was in before "Save Game" was selected, except elapsed time is current
Use Case 13 - Tutorial
1. User selects "Tutorial"
2. System executes Tutorial program which teaches user how to play Sokoban
Use Case 14 Host Multiplayer
Game
1. User selects "New Multiplayer Game" from main menu
2. System displays a window with three choices, "Host a Game," "Join a Game," and "Cancel."
3. User selects "Host a Game."
4. System displays users IP address shown along with text input fields so user can enter his name and port
and a list of possible levels to play
3. User enters name and port(if needed) and selects desired level and selects "Start."
4. System opens a new window that lists all players currently connected
5. Once the desired number (up to 4) of other players has joined the user starts the game by selecting "Start Game." or user
selects cancel and window is closed
6. If user selected "Start Game" system loads selected level with the selected number of user-controlled robots and allows players
to play.
Use Case 15 Join Multiplayer
Game
1. User selects "New Multiplayer Game" from main menu
2. System displays a window with three choices, "Host a Game," "Join a Game," and "Cancel."
3. User selects "Join a Game."
4. System displays a window with text input fields so user can enter his name, the IP address to connect to and port (if necessary)
5. User enters name, IP address, and port and selects "Join."
6. System then displays "Attempting to Connect" window
7. System attempts to connect to given IP address
8. Once connected system waits for host to begin the game, if not connected system returns error message.
9. If connection was successful, game begins when host selects start game
Use Case 16 Send Chat
Message
This function only occurs during cooperative multiplayer mode.
1. User enters message to be sent into text input box and selects enter
2. System sends message to all other users
3. System updates chat text area adding a line with users name and message in the color associated with the particular user
Use Case 17 Receive Chat
Message
This function only occurs during cooperative multiplayer mode.
1. System receives message from another user
2. System updates chat text area adding a line with message sent by a user in the color associated with that particular user
Use Case 18 Level Editor
1. User selects Level Editor option from menu
2. System displays level editor (see next few use cases for more detail)
Use Case 19 Assign A Square
As A Wall (Level Editor)
1. User selects wall icon to be placed on level
2. User selects square to assign as a wall
3. System displays the square as a wall
4. Steps 2 and 3 repeated until user is satisfied with the number of walls
Use Case 20 Assign A Square
As An Incinerator (Level Editor)
1. User selects incinerator icon to be placed on level
2. User selects square to assign as an incinerator
3. System displays the square as an incinerator
4. Steps 2 and 3 repeated until user is satisfied with the number of incinerators
Use Case 21 Assign A Square
As A Crate (Level Editor)
1. User selects crate icon to be placed on level
2. User selects square to assign as a crate
3. System displays the square as a crate
4. Steps 2 and 3 repeated until user is satisfied with the number of crates
Use Case 22 Assign A Square
As A Robot Starting Point (Level Editor)
1. User selects robot icon to be placed on level
2. User selects square to assign as a robot
3. System displays the square as a robot
4. Steps 2 and 3 repeated until user is satisfied with the number of robots
Use Case 23 Assign A Square
As Empty (Level Editor)
1. User selects tile icon to be placed on level
2. User selects square to assign as a tile
3. System displays the square as a tile
4. Steps 2 and 3 repeated until user is satisfied with the number of tiles
Use Case 24 Next Level
(Multiplayer)
1. User selects Next Level
2. System asks the other user(s) if they want to go to the next level
3. If the other user(s) agree(s) to go to next level, the system loads the next level
Use Case 25 Previous Level
(Multiplayer)
1. User selects Previous Level
2. System asks the other user(s) if they want to go to the previous level
3. If the other user(s) agree(s) to go to the previous level, the system loads the previous level
Use Case 26 Go To Level
(Multiplayer)
1. User selects Go To Level
2. System asks the other user(s) if they want to go to the selected level
3. If the other user(s) agree(s) to go to the selected level, the system loads the specified level
Use Case 27 Agree To Level
Change (Multiplayer)
1. System displays window showing a level change request from another user
2. User clicks the Yes button
3. System loads next level
Use Case 28 Disagree To
Level Change (Multiplayer)
1. System displays window showing a level change request from another user
2. User clicks the No button
3. System does not load the next level
Use Case 29 Restart Level
(Multiplayer)
1. User selects Restart
2. If other user(s) agree, then System restarts the level
Use Case 30 Agree to Restart
Level (Multiplayer)
1. System displays window with restart level request
2. User(s) clicks Yes button
3. System restarts level
Use Case 31 Disagree to
Restart Level
1. System displays window with restart level request
2. User clicks No button
3. System does not restart level
Use Case 32 Undo Move
(Multiplayer)
1. User selects Undo
2. System updates the display to reflect one move undone
3. System informs the other users system of the undo
Use Case 33 Other Player
Undo Move
1. System receives Undo Move from the other user
2. System updates display to reflect other users undo move
Use Case 34 End Game
(Multiplayer)
1. User selects End Game
2. System displays window confirming End Game
3. Users selects the Yes button
4. System informs the other users system of end game
5. System ends current game and returns to the main menu
Use Case 35 Create A New
Level (Level Editor)
1. User selects New Level Template
2. System displays an empty level (all squares are tiles) from which player can create a custom level.
Use Case 36 Load A Level
(Level Editor)
1. User selects Open Level
2. System displays the open level screen
3. User chooses a level
4. System loads level from file
Use Case 37 Add A Level To
The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User clicks add
4. System displays the add level screen
5. User chooses a level
6. System adds the level to the end of the level list
Use Case 38 Add A Level To The
Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects level to insert before
4. User clicks insert
5. System displays the insert level screen
6. User chooses a level
7. System inserts the level above selected level in the list
Use Case 39 Remove A Level
From The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects level to remove
4. User clicks remove
5. System removes the selected level from the list of levels
Use Case 40 Clear All Levels
From The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User clicks Clear All
4. System removes all levels from the level list
Use Case 41 Move A Level Up
In The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects a level and clicks Move up
4. System exchanges the position of the selected level with the one above it in the list
Use Case 42 Move A Level Down In The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects a level and clicks Move down
4. System exchanges the position of the selected level with the one below it in the list
Use Case 43 Exit Level
Editor
1. User clicks the Level menu
2. System displays the Level menu
3. User selects Exit Level Editor
4. System exists the Level Editor and returns to main menu
Use Case 44 Pause Game
1. User selects "Pause Game"
2. System pauses game until user selects "Resume"
Use Case 45 Total Score
1. System keeps track of the score the user accumulates as the user plays Sokoban
in single player mode.
2. If the user accumulates a score high enough to be placed in the High Scores List, system allows user to put his name in the high
scores list after the current game is over
Use Case 46 Save Created
Level
1. User creates a custom level
2. User selects "save level"
3. System displays save level screen
4. User inputs desired save level as name
5. System saves the level
2.3 User Characteristics:
The user of this product is expected to be at least 10 years of age. The user does not have to be proficient with a computer to enjoy the Sokoban videogame.
2.4 Constraints:
Sokoban will operate on PCs running on Windows 9 or later at a minimum speed of 200 MHz. Sokoban will be implemented using the Java programming language.
2.5 Assumptions and
Dependencies:
There are no assumptions or dependencies.
3.1 External Interface
Requirements
3.1.1 User Interfaces
The Sokoban interface will be a windowed application. Functions and options will be available to the user in a drop-down menu system. As well, the most common initial
selections such as starting a new game will be available as buttons from an opening menu. The in-game screen will reside within the main window and will consist of a level map which
contains the user-controlled robot and a side panel containing pertinent information as well as quick buttons; which perform some of the more commonly used function from the menu
system. The multi-player version will contain a chat box in addition to the level map and side panel. When requesting information from the user, Sokoban will present the user with a
separate window in which the user may enter the necessary information.
3.1.2 Hardware Interfaces
None.
3.1.3 Software Interfaces
None.
3.1.4 Communication Interfaces
TCP/IP will be used for the multiplayer aspect of Sokoban. Users will be able to connect to each other over a LAN or via the Internet using the TCP/IP protocols.
3.2 Functions
Use Case 1 Single Player Game
1. User selects New Solo Game
2. System loads first level from predefined level list.
3. System resets score, moves, pushes, crates incinerated and elapsed time counters to zero.
4. System displays level, above counters, and level name to user as well as all objects included in the level - user controlled robot, moveable crates, and
incinerators.
5. Once system has loaded and displayed all of the above and is waiting for user input the time counter begins.
6. User inputs the desired direction of robot movement using arrow keys.
7. System outputs sound based on movement made (different sounds for moving, moving a crate, incinerating a crate, and completing a level)
8. System reads input and updates level accordingly, showing new location of robot, if move is possible (if move is not possible then treat as though there was no
Input provided), new location of any crate moved (if a crate is incinerated then it should no longer be visible).
9. System updates number of moves, pushes and crates incinerated counters
10. Once all crates in current level are incinerated time counter stops counting.
11. System calculates score for level (score based on algorithm provided in data dictionary under scores)
12. System displays level cleared screen, which includes total number of moves and pushes, total time taken to complete level, total score for level and total score
for game.
13. System, once player clicks "Continue" from "Level Finished" screen, then loads next level and follows above steps except score is displayed as the sum of all the
total scores accumulated on the previous level(s).
Use Case 2 Instant Replay
1. User selects Instant Replay
2. System pauses elapsed time counter
3. System resets level to its initial conditions robot and crates located at their initial locations but moves, pushes, and crates
incinerated counters remain what they were before instant replay feature was selected
4. System then displays all actions taken by robot, and makes according sound, up to the point where user selected instant replay
5. System begins counter once replay is complete and game proceeds
Use Case 3 Undo Move
1. User selects Undo Move
2. System moves robot back to its previous position and moves crate to its previous position if necessary
3. "Moves" counter is decreased by 1 as is "Pushes" counter(if necessary). If an incinerated crate is returned to the level, then
system decrements "Crates Incinerated" counter by 1
Use Case 4 Restart
1. User selects Restart
2. System reloads current level and follows Use Case 1 (starting at
step 3)
Use Case 5 End Game
1. User selects End Game
2. System asks user if he or she wants to end the game.
3. If user selects yes, system terminates current game and returns
to main menu, otherwise, system returns to current level
and allows user to continue with level. During this entire time "Time Elapsed" counter is continually counting upward.
Use Case 6 Load Game
1. User selects "Load Game" (either from main menu or solo game)
2 System asks user if he or she wants to end the current game
3. If user selects "yes," system displays all possible choices available to choose from
4. User makes a selection and then selects "Load"
5. System loads the selected
game and allows user to play from the state the game was saved
Use Case 7 Change Robot
Color
1. User selects Change Robot Color
2. System pauses time counter
2. System displays change robot color screen
3. User selects desired robot color
4. System implements the color change - the four possible colors are blue, red, yellow, and green
5. System returns to game screen from which "Change Robot
Color" was selected
6. Time counter returns to counting from paused state and game resumes
Use Case 8 View High Scores
1. User selects View High Scores
2. System loads and displays high scores screen
Use Case 9 Go To Level
1. User selects Go To Level
2. System displays Go To Level screen with a list of playable levels
3. User selects desired level from list
4. System loads desired level and follows Use Case 1 (starting at step 3 except score counter is set to the score earned up to the point where the Go To Level feature was selected).
Use Case 10 Next Level
1. User selects Next Level
2. System loads next level in the level list
3. System follows Use Case 1 (starting at step 3 except score
counter is set to the score earned up to the point where the Next Level feature
was selected).
Use Case 11 Previous Level
1. User selects Previous Level
2. System loads previous level from the level list.
3. System follows Use Case 1 (starting at step 3 except score
counter is set to the score earned up to the point where the Previous Level
feature was selected).
Use Case 12 Save Game
1. User selects Save Game
2. System displays a window with fifteen slots to choose from and a text field to enter a description in
3. User selects a slot and enters a description in the text filed and selects "Save"
6. System saves game information (all the fields) and stores the game in the slot selected with the description given as the name of
the slot. If user did not enter a description, the system asks the user if they did not want a description
7. If the user selects "Yes," system proceeds to state it was in before "Save Game" was selected otherwise if user selects "No,"
system returns user to save game screen (step 2).
Use Case 13 - Tutorial
1. User selects "Tutorial"
2. System begins Tutorial program
3. User has the ability to go to next screen or previous screen of Tutorial Program
Use Case 14 Host Multiplayer
Game
1. User selects "New Multiplayer Game" from main menu
2. System displays a window with three choices, "Host a Game," "Join a Game," and "Cancel."
3. User selects "Host a Game."
4. System displays users IP address shown along with text input fields so user can enter his name and port
and a list of possible levels to play
3. User enters name and port(if needed) and selects desired level and selects "Start."
4. System lists all players currently connected
5. Once the desired number (up to 4) of other players has joined the user starts the game by selecting "Start Game."
6. If user selected "Start Game" system loads selected level with the selected number of user-controlled robots and allows players
to play. If user selects "Cancel" system returns user to main menu.
Use Case 15 Join Multiplayer Game
1. User selects "New Multiplayer Game" from main menu
2. System displays a window with three choices, "Host a Game," "Join a Game," and "Cancel."
3. User selects "Join a Game."
4. System displays a window with text input fields so user can enter his name, the IP address to connect to and port (if necessary)
5. User enters name, IP address, and port and selects "Join."
6. System then displays "Attempting to Connect" window
7. System attempts to connect to given IP address
8. Once connected system waits for host to begin the game, if not connected system returns error message.
9. If connection was successful, game begins when host selects start game
Use Case 16 Send Chat Message
1. User enters chat message into chat input box
2. User clicks Send button or hits the enter key
3. System sends message to other user
4. System updates chat text area adding a line with users name and message
Use Case 17 Receive Chat Message
1. System receives message from other user
2. System updates chat text area adding a line with other users name and message in the color of that users color
Use Case 18 Level Editor
1. User selects Level Editor
2. System displays Level Editor main menu
Use Case 19 Assign A Square
As A Wall (Level Editor)
1. System displays level editor (empty level, all squares are tiles) with, wall, incinerator, crate, robot, and tile icons on side-bar
2. User selects wall icon to enable cursor to place wall squares on the template
3. System now displays wall icon with red border (previous icon is no longer highlighted)
4. User selects square to assign as a wall (user can drag mouse to assign multiple squares as walls)
5. System displays the square(s) as a wall
6. Steps 2 and 3 repeated until user is satisfied with the number of walls
Use Case 20 Assign A
Square As An Incinerator (Level Editor)
1. System displays level editor (empty level, all squares are tiles) with, wall, incinerator, crate, robot, and tile icons on side-bar
2. User selects incinerator icon to enable cursor to place incinerator squares on the template
3. System now displays incinerator icon with red border (previous icon is no longer highlighted)
4. User selects square to assign as an incinerator (user can drag mouse to assign multiple squares as incinerators)
5. System displays the square(s) as an incinerator
6. Steps 2 and 3 repeated until user is satisfied with the number of incinerators
Use Case 21 Assign A Square
As A Crate (Level Editor)
1. System displays level editor (empty level, all squares are tiles) with, wall, incinerator, crate, robot, and tile icons on side-bar
2. User selects crate icon to enable cursor to place incinerator squares on the template
3. System now displays crate icon with red border (previous icon is no longer highlighted)
4. User selects square to assign as a crate (user can drag mouse to assign multiple squares as crates)
5. System displays the square(s) as a crate
6. Steps 2 and 3 repeated until user is satisfied with the number of crates
Use Case 22 Assign A Square
As A Robot Starting Point (Level Editor)
1. System displays level editor (empty level, all squares are tiles) with, wall, incinerator, crate, robot and tile icons on side-bar
2. User selects robot icon to enable cursor to place robot squares on the template
3. System now displays robot icon with red border (previous icon is no longer highlighted)
4. User selects square to assign as a robot (user can drag mouse to assign multiple squares as robots)
5. System displays the square(s) as a robot
6. Steps 2 and 3 repeated until user is satisfied with the number of robots or the number of robots has reached four
Use Case 23 Assign A Square
As Empty (tile) (Level Editor)
1. System displays level editor (empty level, all squares are tiles) with, wall, incinerator, crate, robot, and tile icons on side-bar
2. Tile icon is the default icon, so it is selected by the system and highlighted in red by the system once Level Editor begins
3. User selects any icon on sidebar (wall, crate, robot, or incinerator) to be placed on the level template, system highlights that icon in red (previous icon
is no longer highlighted)
4. User selects square to assign as the selected icon (user can drag mouse to assign multiple squares as that icon)
5. System displays the square(s) as a that icon
6. Steps 2 and 3 repeated until user is satisfied with the number of objects that icon represents
7. User then selects tile icon from side-bar, system highlights that icon in red
8. User places tile icon on a square that was previously assigned as something else (drag method works here also)
9 System changes square to a tile (empty cell)
Use Case 24 Next Level
(Multiplayer)
1. User selects Next Level
2. System sends request to other users for level change
3. System waits and receives response from other user
4. If the other users agree, the system changes to next level
5. System sets all counters to zero.
6. System displays next level map with crates and robots at starting positions.
Use Case 25 Previous Level
(Multiplayer)
1. User selects Previous Level
2. System sends request to other user for level change
3. System waits and receives response from other user
4. If the other user agrees, the system changes to previous level
5. System sets all counters to zero.
6. System displays previous level map with crates and robots at starting positions.
Use Case 26 Go To Level
(Multiplayer)
1. User selects Go To Level
2. System sends request to other user for level change
3. System waits and receives response from other user
4. If the other user agrees, the system changes to specified level
5. System sets all counters to zero.
6. System displays selected level map with crates and robots at starting positions.
Use Case 27 Agree To Level
Change (Multiplayer)
1. System displays window showing a level change request from the other user (either Next Level, Previous Level, or Go to
Level)
2. User clicks the Yes button
3. System sends response to other users system and then changes to the requested level
4. System sets all counters to zero.
5. System displays map with crates and robots at starting positions.
Use Case 28 Disagree To
Level Change (Multiplayer)
1. System displays window showing a level change request from the other user (either Next Level, Previous Level, or Go to
Level)
2. User clicks the No button
3. System sends denial response to other users system
Use Case 29 Restart Level
(Multiplayer)
1. User selects Restart
2. System sends request to other users system for level restart
3. System receives response from other users
4. If other users agree, then System restarts the level
5. System resets all counters to zero.
6. System returns all boxes and robots to their starting positions.
Use Case 30 Agree to Restart
Level (Multiplayer)
1. System displays window with restart level request
2. User clicks Yes button
3. System informs other users system of response
4. System restarts level
5. System resets all counters to zero.
6. System returns all crates and robots to their starting positions.
Use Case 31 Disagree to
Restart Level
1. System displays window with restart level request
2. User clicks No button
3. System informs other users system of response
Use Case 32 Undo Move
(Multiplayer)
1. User selects Undo
2. System updates the display to reflect one move undone
3. System moves robot back to previous location
4. If crate had been moved, the system returns the crate to its previous location
5. System informs the other users system of undo
Use Case 33 Other Player
Undo Move
1. System receives Undo Move from the other user
2. System updates display to reflect other users undo move
3. System moves robot back to previous location
4. If crate had been moved, the system returns the crate to its previous location
Use Case 34 End Game
(Multiplayer)
1. User selects End Game
2. System displays window confirming End Game
3. User clicks the Yes button
4. System informs the other users system of end game
5. System closes current game and returns to the main menu (If host closes game, all other users are disconnected.)
Use Case 35 Create A New
Level (Level Editor)
1. User selects New Level
2. System displays a 25 x 25 grid of 24x24 pixel squares.
Use Case 36 Load A Level
(Level Editor)
1. User selects Open Level
2. System displays the open level screen
3. User chooses a level
4. System loads level from file
5. System displays the level in the editor
Use Case 37 Add A Level To
The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User clicks add
4. System displays the add level screen
5. User chooses a level
6. System add the level to the end of the level list
Use Case 38 Add A Level To
The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects level to insert before
4. User clicks insert
5. System displays the insert level screen
6. User chooses a level
7. System inserts the level above selected level in the list
Use Case 39 Remove A Level
From The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects level to remove
4. User clicks remove
5. System removes the selected level from the list of levels
Use Case 40 Clear All Levels
From The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User clicks Clear All
4. System removes all levels from the level list
Use Case 41 Move A Level Up
In The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects a level and clicks Move up
4. System exchanges the position of the selected level with the one above it in the list
Use Case 42 Move A Level Down In The Level List
1. User selects Organize Levels
2. System displays the organize level screen
3. User selects a level and clicks Move down
4. System exchanges the position of the selected level with the one below it in the list
Use Case 43 Exit Level
Editor
1. User clicks the Game menu
2. System displays the game menu
3. User selects Exit
4. System closes the level editor window
Use Case 44 Pause Game
1. User selects "Pause Game"
2. System pauses game, the elapsed time counter is paused and the game level area is no longer visible (blacked out),
until user selects "Resume"
Use Case 45 Total Score
1. System keeps count of cumulative score by adding scores gained on
all levels played completed.
2. If the user gains a score sufficient enough to be placed in the High Scores List
the system prompts user to enter name once user ends the current game
3. System stores high score in appropriate position in high scores list (highest score on top) with Name and score shown
Use Case 46 Save Created
Level
1. User creates a custom level
2. User selects "save level"
3. System displays save level screen
4. User inputs desired save level as name
5. System saves the level
3.3 Performance Requirements
The application will initially load in under 15 seconds.
The application will support up to four players playing on different computers.
Loading a different level will take under 15 seconds.
The application will require no more than 16 MB of RAM and 5 MB of storage space.
3.4 Design Constraints:
Sokoban is to be designed using UML and object-oriented design. It will be implemented in the Java programming language. The software will run as a Java application on any
PC with a Java 2 Runtime Environment. Sokoban will be designed so that future changes can be implemented in twenty man-hours or less.
3.5 Software System Attributes:
3.5.1 Reliability:
Sokoban will not fail more than once in every 1000 levels played.
3.5.2 Availability:
Sokoban will be available to be played on any computer that has a Java 2 Runtime Environment.
3.5.3 Security:
High scores list will not be able to be altered unless done so by system.
3.5.4 Maintainability:
· It will be possible to modify the appearance of the robot in one man-hour or less.
· It will be possible to change the appearance of the levels in one man-hour or less.
· The level editor will allow a user to modify and expand the existing set of levels.
3.5.5 Portability:
· Sokoban will be developed using the Java coding language.
· Sokoban will be playable on any operating system with the Java 2 Runtime Environment installed.
Appendix A Acronyms:
LAN Local Area Network
MB Megabytes
PC Personal Computer
RAM Random Access Memory
SPMP Software Project Management Plan
SQAP Software Quality Assurance Plan
SRS System Requirement Specification
TCP/IP Transmission Control Protocol/Internet Protocol
UI User Interface
UML Unified Modeling Language
Appendix B References:
Software Project Management Plan (SPMP) for Sokoban
Software Quality Assurance Plan (SQAP) for Sokoban
Appendix C Typical Level
This is a simple Sokoban level.
Appendix D Analysis Model:
State Transition Diagram
Appendix E Data Dictionary:
|
|
name |
Color |
|
|
alias |
none |
|
|
description |
distinguishes one robot from another |
|
|
definition |
Color = {blue, red, green, yellow} |
|
|
supplementary |
none |
|
|
|
|
|
|
name |
Crate |
|
|
alias |
none |
|
|
description |
An object that the robot can move |
|
|
definition |
Crate = (row_int) , (column_int) |
|
|
supplementary |
row and column coordinates of crates |
|
|
|
|
|
|
name |
CratesIncinerated |
|
|
alias |
boxes removed |
|
|
description |
occurs when a box is moved on top of incinerator |
|
|
definition |
crates = (int) crates 1 |
|
|
supplementary |
total number of crates is decremented by one |
|
||||
|
|
|
|
|
||||
|
|
name |
CratesRemaining |
||||||
|
|
alias |
boxes remained |
|
|
description |
The number of crates left to be incinerated by the user |
|
|
definition |
CratesRemaining = TotalCrates - CratesIncinerated |
|
|
supplementary |
none |
|
||||||
|
|
|
|
|
||||||
|
|
name |
CreatedLevel |
|
||||||
|
|
|
|
|
|
|
|
|||
|
|
alias |
none |
|
|
description |
Says if the level is a user created level or not |
|
|
definition |
CreatedLevel = boolean |
|
|
supplementary |
none |
|
|||
|
|
|
|
||||
|
|
name |
Direction |
||||
|
|
|
|
|
|
|
|
|
|
alias |
none |
|
|
description |
direction robot is facing |
|
|
definition |
Direction = {up, down , left, right} |
|
|
supplementary |
none |
|
|
|
|
|
|
name |
Incinerator |
|
|
alias |
none |
|
|
description |
objective is to bring all crates to this location |
|
|
definition |
incinerator = (row_int), (column_int) |
|
|
supplementary |
row and column coordinates of incinerator |
|
|
|
|
|
|
name |
IPAddress |
|
|
alias |
none |
|
|
description |
User needs to enter the IP address for hosting a game. |
|
|
definition |
IPAddress = (int) number1 + . + (int) number2 . + (int) number3 + . + (int) number4 |
|
|
supplementary |
The first, second, and fourth should have three digits, and the third should have 1 |
|
|
|
|
|
|
name |
LevelName |
|
|
alias |
none |
|
|
description |
Name of the level |
|
|
definition |
LevelName = String |
|
|
supplementary |
none |
|||
|
|
|
|
|
||
|
|
name |
Moves |
|
||
|
|
|
|
|
|
|
|
|
alias |
none |
|
|
description |
Total moves made by robot in current level |
|
|
definition |
Moves = (int) moves + 1 |
|
|
supplementary |
none |
|
|
|
|
|
|
name |
Pushes |
|
|
alias |
none |
|
|
description |
Total pushes made by robot in current level |
|
|
definition |
Pushes = (int) pushes + 1 |
|
|
supplementary |
none |
|
||||||
|
|
|
|
|
||||||
|
|
name |
Scores |
|
||||||
|
|
|
|
|
|
|
|
|||
|
|
alias |
none |
|
|
description |
Total Score in the current level |
|
|
definition |
Scores = (int) (Crates * 100 Moves)/Time |
|
|
supplementary |
none |
|
|||||||||
|
|
|
|
|
|||||||||
|
|
name |
RobotNumber |
|
||||||||
|
|
|
|
|
|
|
|
|||||
|
|
alias |
none |
|
|
description |
Robot number is assigned to each player |
|
|
definition |
RobotNum = int |
|
|
supplementary |
none |
||||||
|
|
|
|
|
|||||
|
|
name |
Time |
|
|||||
|
|
|
|
|
|
|
|
||
|
|
alias |
none |
|
|
description |
Total time spent on a level |
|
|
definition |
Time = (int) seconds |
|
|
supplementary |
Display time style is 00 |
|
||
|
|
|
|
|
||
|
|
name |
TotalCrates |
||
|
|
alias |
none |
|
|
description |
The number of crates contained in the level |
|
|
definition |
TotalCrates = int |
|
|
supplementary |
none |
||
|
|
|
|
|
||
|
|
name |
UserName |
|
||
|
|
alias |
none |
|
|
description |
User creates a nick name |
|
|
definition |
userName = String |
|
|
supplementary |
none |
|
|
|
|
|
|
name |
Wall |
|
|
alias |
none |
|
|
description |
An object that the robot can not move |
|
|
definition |
wall = (row_int1) , (column_int1) ; (row_int2), (column_int2) |
|
|
supplementary |
row and column coordinates for beginning and end point of a wall |
Appendix F Issues and
Tradeoffs Engineering Analysis:
Scoring
The software scoring will be based on an algorithm that computes a score using a combination of game variables. The algorithm will compute the number of crates incinerated already in the current level and multiply each crate by 100. The number of robot moves will be subtracted from that value, and then divided by time in seconds. We found this to be the most effective scoring method for our software.
Scoring by level difficulty was considered but it would give the user the advantage of creating a very simple level with a very high score, making the high scores list non-effective. Scoring by this method would only work for default levels or levels with a pre-established difficulty and not by the user.
Scoring by time would cause the user to get a high score on a very simple level. Once again making the high scores list non-effective. We felt that this provided no balance between level difficulties.
We then decided on the aforementioned algorithm, which we felt would provide the best balance between scoring based on level difficulty. It requires no input from the user during level creation.
IP Address
The software will only detect the IP address on the computer that the software program is currently running on. A user will not be able to join a random multiplayer game. To join a multiplayer game, the joining user will have to contact the host to obtain his IP address. This process will be less costly for the customer and easier to code for the developer. It will also cut down on development time for the software.
Level Organization
The Software will allow the user to store custom and/or predefined levels in any order he/she wishes. This allows the user to determine which level will be played after the current level and thereafter. No scoring will take place for custom levels because consistency for scoring among custom levels cannot be determined. Therefore custom levels will be played only for fun and do not affect the users current score.
Appendix G Table of
Contents:
Credits 1
1. Introduction 3
1.1 Purpose 3
1.2 Scope 3
1.3 Definitions, Acronyms, and Abbreviations 3
1.4 References 3
1.5 Overview 3
2. Overall Description 3
2.1 Product Perspective 3
2.1.1 Concept of Operations 4
2.1.2 User Interface Concepts 4
2.1.3 Hardware Interfaces 4
2.1.4 Software Interfaces 4
2.1.5 Communications Interfaces 5
2.1.6 Memory Constraints 5
2.1.7 Operations 5
2.1.8 Site Adaption Requirements 5
2.2 Product Functions 5
2.3 User Characteristics 10
2.4 Constraints 10
2.5 Assumptions and Dependencies 10
3. Specific Requirements 11
3.1 External Interface Requirements 11
3.1.1 User Interfaces 11
3.1.2 Hardware Interfaces 11
3.1.3 Software Interfaces 11
3.1.4 Communications Interfaces 11
3.2 Specific Requirements 11
3.3 Performance Requirements 19
3.4 Design Constraints 19
3.5 Software System Attributes 19
3.5.1 Reliability 19
3.5.2 Availability 20
3.5.3 Security 20
3.5.4 Maintainability 20
4. Appendices 21
A. Acronyms 21
B. References 22
C. Typical Level 23
D. Analysis Model 24
E. Data Dictionary 25
F. Issues and Tradeoffs 27
G. Table of Contents 28
H. FTR Review Summary Report 29
I. Quality Assurance Checklist 30
Appendix H - FTR Review Summary Report
The D-req, or section 3 of the SRS, for the Sokoban program being developed by Lucky Strike Software underwent an FTR on October 23, 2001. It was reviewed by the members of 7th Dimension Gaming. The meeting was moderated by Kevin Blomseth, and the reviewers were the individual members of 7th dimension. It was decided by the reviewers that they were going to reject the D-Req after inspecting it, leaving Lucky Strike with a need to rework a lot of the document. The following is a list of issues and response that is planned to follow.
|
Section |
Problem |
Solution |
Approval |
|
3.2 |
Lack of Description |
Section completely reworked |
|
|
3.3 |
Arbitrary Numbers |
Section rewritten after consultation with customer |
|
|
3.4 |
Issues about Database |
Section removed |
|
|
3.5 |
Minor Metrics Issue |
Corrected issue |
|
|
3.6.1 |
Reliability validity brought up |
Section changed |
|
|
3.6.3 |
Security issues need to be cleared up |
Confusing areas removed |
|
|
3.6.4 |
Lack of clarity |
Section being rewritten |
|
___________________________________________________
Signature of QA Manager of 7th Dimension Gaming
Appendix I Quality Assurance Checklist:
Content / Format
The document should conform to a standardized format such as IEEE Std
830-1998 Recommended Practice for Software Requirements Specifications.
Correctness
The document must be technically correct. The content of each section must fulfill the purpose for which it is intended. All diagrams must follow the appropriate notation.
Writing
The document must be well written. The writing must meet the standards
of the Cal Poly Writing
Proficiency Exam level 4 or greater. If you have questions about writing
style, refer to a standard style guide such as: MLA Handbook for
Writers of Research Papers.
- Is each requirement is simply stated in english?
- Is the document free of spelling errors?
- Is the writing grammatically correct?
- Does the writing use present tense, active voice with transitive verbs, and 3rd person writing?
- Does the writing avoid vague terms such as those in Dan Stearns' bad words list?
Functional Requirements
This section is the core of the document. It specifies exactly what functionality the system will provide.
Clarity
It is essential that the requirements be clear to all readers so as to
prevent ambiguity and misinterpretation.
- Are the requirements written in user language? Do the users think so?
- Are the requirements written in non-technical language that uses the vocabulary of the client problem domain?
- Are the requirements stated simply and completely so that they are unambiguous.
- Are the requirements stated clearly so there is only one interpretation?
- Do the requirements describe only EXTERNAL behavior, as seen from the user's point of view?
- Do the requirements avoid stating how the problem is to be solved or what techniques are to be used.
- Do all data and processes exist in the problem domain, not the solution domain?
- Is every noun a term from the data dictionary?
- Is every noun emphasized in some way in the document (e.g. underlining) and use the exact DD term?
- Are the requirements at a fairly consistent level? Should any requirement be specified in more detail? Should any requirement be specified in less detail?
- Are the requirements clear enough to be turned over to an independent group for implementation and still be understood?
Completeness
A correct, complete set of requirements is one that correctly and completely
states the desires and needs of the sponsor. If the requirements are incorrect,
the software may meet the requirements as stated, but will not do what the
sponsor wants it to do. If the requirements are incomplete, the software may do
only part of what the sponsor hoped it would do.
- Is each characteristic of the final product described?
- Are all the tasks the user wants to perform specified?
- Is each requirement relevant to the problem and its solution?
- Are all the inputs to the system specified including their source, accuracy, range of values, and frequency?
- Are all the outputs from the system specified including their destination, accuracy, range of values, frequency, and format?
- Does each function specify the data used in the function and data resulting from the function?
- Are all aspects of the processing specified for each function?
- Are the requirements complete in the sense that if a product satisfies every requirement, it will be acceptable?
- Do the requirements contain no implied design details?
- Do the requirements contain no implied implementation constraints?
- Do the requirements contain no implied project management constraints?
Consistency
Consistency is obtained if the requirements do not contradict each other.
Inconsistency results when one requirement contradicts another.
- Is each requirement unique? (I.e., no redundancy)
- Do all the requirements avoid conflicts with other requirements?
Traceability and Modifiability
Ultimately every aspect of the finished system should be able to be traced
back to the requirements. Therefore this document should be organized to
facilitate tracing the requirements into subsequent work products.
- Does the organization adhere to an accepted standard?
- Is the document organized in a segmented, top down manner?
- Is every requirement numbered in a manner that facilitates cross referencing and indexing?
- Can each item be traced to its origin in the problem environment?
- Are all possible changes to the requirements specified?
Verifiability
The requirements must be verifiable in two ways: do the requirements satisfy
the sponsor's needs, and does the system satisfy the requirements? In the first
case, the requirements must be compared to the sponsor's desires and needs. Do
the requirements correctly and completely specify the sponsor's desires and
needs? In the second case, once the system has been developed, it must be
compared to the requirements. Does the system meet the requirements as they are
stated?
- Are all of the requirements feasible? (I.e., possible to implement)
- For each requirement is there a process that can be executed by either a human or a machine to verify the requirement?
- Is each requirement testable or verfiable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
- Does the writing avoid vague terms such as those in Dan Stearns' bad words list?
Nonfunctional Requirements (Quality Attributes)
This section describes any attributes required of the system that don't provide a function or capability, but some other desired attribute or characteristic. Another way of saying it, is that this section specifies how much quality is required.
These requirements are subject to the same criteria as the previous section. Special attention must be given to stating the requirements in a manner that is objective and quantifiable; there must be some measurable way to assess whether the requirement has been met.
Consult this online reference as well as your textbook.
Appendices
The appendices contain technical material that is more relevant to the developer than the customer. Included here are any work products created during the analysis process.
Data Dictionary
- Are all required data from problem statement included (there is a data item for each noun in the problem statement)?
- Do the items describe only EXTERNAL data (i.e, data that is entered by or displayed to the user). No "internal" data, temporary variables should be described. "External" data is what goes in or out of system, not what is involved in intermediate calculations, or what stores data during processing?
- Do the items define only data, not processes?
- Is each item unique? (No redundant entries).
- Are the items consistent with analysis model and the functional requirements?
- Does each item have a definition that uses a standard DD notation?
- Does each item have a description in english?
- Are composite items distinguished from elemental items.
- Do composite data items show the "decomposition" into other data items?
- Do elemental data items show data type; Enumerable types should list all values, continuous and discrete types should list allowed range of values. (Examples: character A-Z, integer 1-99.)
Report Formats
Are all the report formats specified?
Analysis Model
Do all charts and diagrams follow the corresponding notation?
Engineering Analysis (Tradeoffs)
- Is a rationale provided for all significant issues? I.E., is there documentation for any significant analysis decision?
- Are acceptable trade-offs specified for competing attributes?
- Were all possible alternatives considered?.
- Did the analysis used objective and where possible, empirical, criteria?
- Are all tradeoffs documented and the results of an unbiased decision reported?
____________________________________________________
Signature of Kevin Blomseth, QA Manager of Lucky Strike Software
Document History
Document created on 10-29-01
Document revised on 11-5-01 -
Data dictionary updated, Use cases numbered, all "boxes"
changed to "crates"
Document revised on 12-3-01- SRS made consistent with other documents,
Data dictionary updated, Some Use cases expanded upon (more detail)
Document revised on 1-17-02-SRS made consistent with new customer
requirements
Document revised on 2-2-02-SRS made consistent with stage 2
implementation
Document revised on 3-7-02-SRS made consistent with stage 3
implementation