Software Requirements Specification - Knights vs. Zombies

Knights vs.
Zombies Search this site
The newest in Tower Software Requirements Specification

Defense Games!
Individual Page -
Amanda COP4331C, Spring, 2013
Individual Page -
Version Date Who Comment
Anthony
Individual Page - v0.0 08/15/00 G. H. Walton Template
Dan
Individual Page - v.1.0 01/22/13 Anthony Bolton KvZ Information
Jacob
Individual Page - v.1.1 01/29/13 Anthony Bolton Deliverables 1
Kevin
update
Individual Page -
v.1.2 02/03/13 Anthony Bolton Deliverables 1
Nick
update 2
Concept of
Operations
Detailed Design Team Name: KvZ
High-level Design
Outside Credits Team Members:
Project Legacy
Project Management
Plan Anthony Bolton --> Email --> Web Page
Coding Standards Amanda Dale --> Email --> Web Page
PERT Jacob Osterhout --> Email --> Web Page
TDEF Nick Roberts --> Email --> Web Page
Software Kevin Samms --> Email --> Web Page
Requirements Dan Zuber --> Email --> Web Page
Specification
Test Plan
Test-Results
Sitemap
Contents of this Document
Introduction
Software to be Produced
Reference Documents
Applicable Standards
Definitions, Acronyms, and Abbreviations
Product Overview
Assumptions
Stakeholders
Event Table
Use Case Diagram
Use Case Descriptions
Specific Requirements
Functional Requirements
Interface Requirements
Physical Environment Requirements
Users and Human Factors Requirements
Documentation Requirements
Data Requirements
Resource Requirements
Security Requirements
Quality Assurance Requirements
Supporting Material
SECTION 1: Introduction
Software to be Produced:
Knights versus Zombies is a Java-based tower defense game for Windows and Mac that will allow players to take the role of a king of a mythical medieval kingdom
as he defends his land from an evil wizard and his endless horde of zombies. Players will be able to assemble their own army of knights to fight the zombie hordes,
purchase upgrades for them, and arrange them defensively to protect their base, all while simultaneously working their way to the wizard's lair. Additionally, the
user will have a choice of two game modes: an Infinite Mode in which players will be forced to survive one wave with an infinite number of zombies for as long as
they can and a Story Mode in which players will fight their way through several levels in order to reach the wizard's lair.
Reference Documents:
Concept of Operations
Project Plan
Applicable Standards:
JVM version 6 or above
PC or Android device
Definitions, Acronyms, and Abbreviations:
KvZ Knights vs. Zombies, the project name

GUI Graphical User Interface
UI User Interface
JRE Java Runtime Environment
JVM Java Virtual Machine
Sprites Game Characters or their pictures
Textures Pictures used for game elements: characters,
land, objects, etc.
UCD Use Case Diagrams
UML Unified Modeling Language
SECTION 2: Product Overview
Assumptions:
The user’s platform runs with JRE 6 or above
The user has either a Windows (version XP or later) or a Mac OS (version 10.6.8 or greater)
Runs on a PC newer than 2005
Runs on an Android 2.2 or later
PC has a keyboard and trackpad (or mouse)
Android has a touchscreen
Stakeholders:
The current stakeholders in our project are:
Our six team members - our team is concerned with the reception of our product and in its ability to grant us good grades in the class.
The end users who will be playing our game.
If our game is launched on any particular market, there are regulatory boards that will be involved in the rating of the game based on its content, such as the
ESRB (the Entertainment Software Rating Board) in the United States, and PEGI (Pan-European Game Information) in Europe. Additionally, Apple has
certain policies to simply launch on their Apple Store, as well as Google on the Android market/Google Play services.
Event Table:
Load and Run program Load GUI and initialize variables Variables in initialized state
Start Game
Home Click on a game start Sense mouse location and clicks GUI data set
Screen option
Resume Click on resume game Search for save game file and load Variables loaded with previous game data
Saved Game option
Resume Fail Click on resume game File not found or corrupt; inform user; resume option GUI data set
option grayed out
New Game Click on new game Change game state to begin new game State data set; variables for new game
initialized
View High Click on view high scores Change game state to view high scores High scores data loaded
Scores option
Game Mode Click on game mode Change game state to show available options State data set; variables initialized
Options options
Infinite Click on infinite attack Change game state to infinite attack and begin game Variables set for current game mode;
Attack mode option Initialize sound files
Story Mode Click on story mode Change game state to story mode Variables set for current game mode;
option Initialize sound files
Levels Click on story mode Level data set for transition to next game state Variable set for current game mode; Level
option data updated for each level completed
End Game Use end game option Game stopped; present player with option to save and Variables maintaining current data; code
during game quit or quit only execution stopped
Save Game Click on save game option Disk checked for adequate space; Save file created and Variables copied to save file
within end game option game data stored
Save Game Click on save game option Disk check returns failure or file cannot be created or Variables initialized; Data not saved
Fail within end game option written; Player notified of failure; Game terminated
Failure Player is running program Program or environment fails Variable in unknown state
during
execution
Use Case Diagram:
Use Case Descriptions:
Load and Start Game

This is where the user loads the game that is stored on their device and prepares to play.
Home Screen
The welcome screen for the game. Here the player will be presented with options to direct their gaming experience.
Resume Saved Game
One of the options on the home screen. The player can choose to resume a game that was previously saved. There is only one saved
game.
New Game
One of the options on the home screen. The player can choose to start a new game from the beginning.
View High Scores
One of the options on the home screen. The player can choose to view the highest scores achieved.
Game mode options
A required functionality of a new game. Before a new game is started, the player must choose whether they want to play the game in
one of the available modes.
Infinite Attack Mode
One of the modes of play that can be chosen by the player. In this mode the player is confronted by waves of enemies that do not stop
until the player has either chosen to end the game or the player eventually loses.
Story Mode
One of the modes of play that can be chosen by the player. In this mode the player must complete a series of levels in order to beat the
the game. At each level the player is presented with a story that describes the motivation for completing each level.
Levels
The levels within the story mode option. Each level presents its own scenery and challenges.
End Game
An optional functionality that allows the player end the game normally. An abrupt end to the game will only result in the user having to
start a new from the beginning. End game gives the player the option to save the game.
Save Game
An optional functionality that allows the player to save the state of a game for the purpose of later returning to that point in the game
and continue play.
SECTION 3: Specific Requirements
3.1 Functional Requirements:
No: F-1
Statement: The program shall have a GUI
Source: For user interaction
Dependency: none
Conflicts: none
Supporting Materials: none
Evaluation Method: All user interaction will occur through
the GUI
Revision History: Amanda Dale, February 4th 2013,
Requirement F-1
No: F-2
Statement: The program shall have at least two game
modes
Source: Common addition to all Tower Defense games
Dependency: F-1
Conflicts: none
Supporting Materials: Reference the use case diagram
Evaluation Method: Refer to the Test Plan for evaluation
methods
Revision History: Kevin Samms, February 4th 2013,
Requirement F-2
Amanda Dale, February 4th, 2013
No: F-3
Statement: The program shall have a variety of enemies
Source: To upgrade the user experience
Dependency: F-1, F-2
Conflicts: none
Supporting Materials: Reference: Weekly Activity Log -
Nicholas Roberts <insert link to Nick's website - coming
soon!>
methods
Requirement F-3
Amanda Dale, February 4th 2013
No: F-4
Statement: The program shall have a method of saving the
game
Source: Continuation of games
Dependency: No dependencies, minor task
Conflicts: none
Supporting Materials: Reference the use case diagram
methods
Requirement F-4
No: F-5
Statement: The program shall have a method for keeping
track of high scores for different modes
Source: To track achievements
Dependency: Game state management
Conflicts: none
Supporting Materials: Reference the Concept of
Operations
methods
Requirement F-5
The software must respond only to valid user actions as determined by the program design and ignore any invalid actions.
The software must proceed according to the general path set forth in the Use Case diagram.
In the event of a user modified save file or a corrupt save file the system must respond by preventing the file to be used as input data to the program.
The software language includes parameters that serve to limit the actions of characters in the game environment and prevent the software from crashing.
The input and output consists of a user choosing to resume a game or save a game respectively. Fundamentally the sequences are as follows:
The player chooses to end the game and the game changes state to the options screen where the software will store the current game state at the
player’s request.
The player starts the game and, upon the player’s request, the game will open a saved game and resume play at the point where the player last
stopped and saved the game.
3.2 Interface Requirements:
No: I-1
Statement: The program shall have a main menu
Source: To choose game options: New Game, Save
Game, Highscores, Settings
Dependency: none
Conflicts: none
Supporting Materials: Functional Requirements
methods
Requirement I-1
No: I-2
Statement: The program shall have a Game Mode menu
Source: The user can choose which game mode to begin
Dependency: none
Conflicts: none
Supporting Materials: Functional Requirements, I-2
methods
Requirement I-2
No: I-3
Statement: The program shall have a High Scores screen
Source: To view the high scores (survival times) attained
Dependency: I-1
Conflicts: none
Supporting Materials: Functional Requirements, UCD, I-1
methods
Requirement I-3
No: I-4
Statement: The program shall have multiple level GUIs
Source: To enhance user experience
Dependency: Game Mode
Conflicts: none
Supporting Materials: Functional Requirements
methods
Requirement I-4
No initial input is required - the game loads the main menu as soon as the game is begun. The user will select to load a saved game or start a new game.
Output is a save file that contains user game data for resuming the game at a later time. The file is optional since the user may choose to not load their game.
The saved game data is overwritten every time the user saves the game and is automatically saved after every Story Mode level.
The saved game data will be in the form of booleans, strings, and integers to save game state and user data such as user name and any numerical data
required to resume a previous game.
The integers, strings, and booleans have no decimal accuracy. They are recorded as-is with no truncation or modifications necessary.
The single save file will be output and input upon user request at game end and start respectively (except after each Story Mode level when the game is saved
automatically). Each data item will be read as-is and no provisions are made for security or integrity of the data. If the file or any data item is corrupt then the
save file cannot be used. If any data item is outside of allowed range then the save file cannot be used.
3.3 Physical Environment Requirements:
No: PE-1
Statement: The system will run on any personal computer
with specs meeting or beyond the following: 1.5ghz CPU,
512MB RAM, 500MB Free Hard Drive Space, and a 64MB
GPU.
Source: Works on most common PCs
Dependency: none
Conflicts: none
Evaluation Method: Will test on multiple PC versions
Requirement PE-1
No: PE-2
Statement: The PC running the system must have a
keyboard and mouse
Source: For GUI interactions
Dependency: none
Conflicts: none
Supporting Materials: Event table
methods
Requirement PE-2
The software requires that the machine has the Java Runtime Environment installed with the most current version which at the time of development is 1.7*.
Equipment that must run our software include Personal Computers (PC), and if time permits we may extend our implementation to allow our software to run on
Android Devices. The equipment running the software has a wide range of realistic physical locations - any place that is a safe area to run computer hardware.
3.4 Users and Human Factors Requirements:
No: UHF-1
Statement: Users should have some skill in manipulating
computer applications
Source: In order to gain the full experience of the game
Dependency: none
Conflicts: none
Evaluation Method: none
Requirement UHF-1
No: UHF-2
Statement: Users have at least minimal experience with
strategy games
Dependency: none
Conflicts: none
Requirement UHF-2
No: UHF-3
Statement: Users should have skill with necessary
hardware (mouse and keyboard - and touchscreens for
Android)
Dependency: none
Conflicts: none
Requirement UHF-3
No: UHF-4
Statement: Users should have at least low-vision
Dependency: none
Conflicts: none
Requirement UHF-4
The system will support different types of users including children, teenagers, the instructor for this course, and the TA's for this course.
The skill level of each user is expected to be fairly low. A user manual and in-game tutorial level will be included to allow users to learn how to use the system.
A moderate font size will be used to prevent eye strain. Additionally, vibrant screen flashes will be kept to a minimum to accommodate those prone to epileptic
seizures.
The system will prevent tampering of save files by encrypting them.
3.5 Documentation Requirements:
No: D-1
Statement: A full user's manual will be available on the
game website
Source: To help users understand the game
Dependency: none
Conflicts: none
Supporting Materials: < link to user manual on web site -
coming soon! >
Evaluation Method: We will have 'test' users read the
manual and criticize its clarity
Requirement D-1
No: D-2
Statement: A short description of each mode will be
available in the active system
Source: To help users understand the game
Dependency: Interface Requirements
Conflicts: none
Evaluation Method: We will have 'test' users read the
descriptions and criticize their clarity
Requirement D-2
No: D-3
Statement: All source code will contain internal comments
Source: To aid with further development and maintenance
Dependency: none
Conflicts: none
Evaluation Method: An outside developer will be asked to
check the code for documentation/code consistency
Requirement D-3
A small user’s manual and quickstart guide in PDF form that the user can print out at their leisure.
The user should understand how to open and read a PDF document in order to access game instructions. An in-game manual may or may not be provided.
3.6 Data Requirements:
No: DA-1
Statement: The game will read in level information from
files with .txt file extensions
Source: It is important to save/maintain the level data
somehow
Dependency: F-4
Conflicts: none
Supporting Materials: Source code
Evaluation Method: If the "Continue Game" option is
successful when selected, the game has indeed read in the
level information from the proper files
Revision History: Anthony Bolton, February 5th 2013,
Requirement DA-1
Sample algorithm for reading from a text file:
while (loadScanner.hasNext()) {
for(int y = 0; y < Screen.room.block.length; y++) {
for(int x = 0; x < Screen.room.block[0].length; x++) {
Screen.room.block[y][x].groundID = loadScanner.nextInt();
for(int y = 0; y < Screen.room.block.length; y++) {
for(int x = 0; x < Screen.room.block[0].length; x++) {
Screen.room.block[y][x].airID = loadScanner.nextInt();
Screen.myWavesRemaining = loadScanner.nextInt();
No: DA-2
Statement: The game will load the sprites into the game
from picture files with .png extensions.
Source: In order to have a more interesting game, pictures
must be loaded and displayed.
Dependency: F-1
Conflicts: none
Evaluation Method: If the player sees images of characters
and other visuals, the loading of sprites was successful.
Requirement DA-2
Sample algorithm for loading a tower character sprite:
g.drawImage(new ImageIcon("res/knights/tower"+towerId+".png").getImage()…)
No: DA-3
Statement: The game will load the background music for
specific levels these files will be in .mp3 format for usability
on most systems.
Source: In order to have a more interesting game,music
must be loaded and projected during gameplay.
Dependency: F-1
Conflicts: none
Evaluation Method: If the player hears background music
that will continue to loop for the duration of the level, music
insertion was successful.
Revision History: Jacob Osterhout, February 5th 2013,
Requirement DA-3
The game will save the player's game data by outputting various integers, booleans, and strings to a .txt file that can later be read-in by the game. This save
file will be encrypted using a simple Caesar cipher.
3.7 Resource Requirements:
No: R-1
Statement: The system requires JRE 1.7 or greater to run
Dependency: none
Conflicts: none
Requirement R-1
No: R-2
Statement: The system requires JVM 7 or greater to run
Source: none
Dependency: none
Conflicts: none
Requirement R-2
No: R-3
Statement: The system requires an accessible file system
for saving games
Dependency: none
Conflicts: none
Supporting Materials: Interface Requirements, Functional
Requirements
Requirement R-3
This game program will not require support personnel and the users are not required to possess any particular skill set in order to use the software. Users may
develop an online support forum but this will not be provided with the software.
No hardware tools or software tools will be required.
A device running JVM version 7 will be supported.
3.8 Security Requirements:
No: S-1
Statement: The game will encrypt the save file so that a
player cannot edit their own saved game
and prevent cheating/data corruption
Dependency: none
Conflicts: none
Supporting Materials: Source code, Data Requirements
Requirement S-1
Currently, only one user’s saved game will have saved data, so there is no need to isolate data.
The task of isolating this program from others on a system will be left to the operating system and the user. The user should place the program in a separate
folder and run it from there. The operating system will manage the game's resources.
The player will have the option to save the current state of the game, so the system will be backed up on an event-driven basis.
There is no direct need for backup copies and no protection against data loss. If the user wants security or data protection they will have to make those
provisions at their discretion.
3.9 Quality Assurance Requirements:
No: QA-1
Statement: The game will not freeze up or close
prematurely in more than 2% of game plays
Source: none
Dependency: QA-2
Conflicts: none
Evaluation Method: We will have a test player play under
normal circumstances for 75 games, and the game will not
freeze up or close prematurely in more than 1% of game
plays
Requirement QA-1
No: QA-2
Statement: Pressing unexpected keys shall not interfere
with game operation
Source: none
Dependency: none
Conflicts: none
Supporting Materials: QA-1
Evaluation Method: During the 75 test games mentioned in
QA-1, the tester will press unexpected keys at random
times of their choosing to ensure it does not interfere with
game operation.
Requirement QA-2
No: QA-3
Statement: Game shall always be available for use
Dependency: none
Conflicts: none
Requirement QA-3
No: QA-4
Statement: Save feature will work 99% of the time
Source: none
Dependency: Functional Requirements
Conflicts: none
Evaluation Method: A tester will test the save feature 100
times in 100 games.
Requirement QA-4
SECTION 4: Supporting Material
Concept of Operations
Project Management Plan
Test Plan
Project Templates found here http://www.eecs.ucf.edu/courses/eel5881/ProjectTemplates.html
Template created by G. Walton (GWalton@mail.ucf.edu) on August 30, 1999 and last modified on August 15, 2000.
This page last modified by Anthony Bolton (anthonyrvbolton@knights.ucf.edu) on February 5, 2013.
Comments
You do not have permission to add comments.
Sign in | Recent Site Activity | Report Abuse | Print Page | Powered By Google Sites

Software Requirements Specification - Knights vs. Zombies

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirements Specification - Knights vs. Zombies

Uploaded by

Copyright:

Available Formats

Knights vs.

Zombies Search this site

The newest in Tower Software Requirements Specification

Definitions, Acronyms, and Abbreviations

Definitions, Acronyms, and Abbreviations:

KvZ Knights vs. Zombies, the project name

SECTION 2: Product Overview

The current stakeholders in our project are:

Use Case Diagram:

Use Case Descriptions:

Load and Start Game

SECTION 3: Specific Requirements

3.1 Functional Requirements:

3.2 Interface Requirements:

3.3 Physical Environment Requirements:

3.4 Users and Human Factors Requirements:

3.5 Documentation Requirements:

3.6 Data Requirements:

Sample algorithm for reading from a text file:

for(int y = 0; y < Screen.room.block.length; y++) {

for(int x = 0; x < Screen.room.block[0].length; x++) {

for(int y = 0; y < Screen.room.block.length; y++) {

for(int x = 0; x < Screen.room.block[0].length; x++) {

Sample algorithm for loading a tower character sprite:

3.7 Resource Requirements:

3.8 Security Requirements:

3.9 Quality Assurance Requirements:

SECTION 4: Supporting Material

You do not have permission to add comments.

You might also like