UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Educational Game System
Software Requirements Specification
Version 3.0
Long Stretch Software 2006
Page - 1
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Revision History
Date
Version
Description
Author
01/Feb/06
0.1
Created and divided the work
Thanh
02/Feb/06
0.11
Created content for sections 2.3 and
3.2.
Aaron
03/Feb/06
0.12
Incorporated Charles’ and Mindy’s
work
Mindy, Charles,
Thanh
03/Feb/06
03/Feb/06
0.13
0.14
Worked on sections 3.2, 3.3 and 3.5
Additions to sections 2, 3
03/Feb/06
0.15
Reformat, Appendix
03/Feb/06
0.16
More reformatting
03/Feb/06
0.17
03/Feb/06
More reformatting and proof
reading
0.18-0.19 Group proof reading
03/Feb/06
0.20
Proof reading / Editing
Aaron, Rizwan
Jeff, Aaron, Thanh,
Rizwan
Thanh, Aaron, Jeff,
Rizwan, Mindy
Thanh, Aaron, Jeff,
Rizwan, Mindy
Thanh, Aaron, Jeff,
Mindy, Rizwan
Mindy, Aaron, Jeff,
Rizwan, Thanh
Rizwan
03/Feb/06
0.21
Proof reading / Editing
Jeff
03/Feb/06
1.0
Proof reading / Editing
Aaron
08/Feb/06
1.1
Feed back from UCSE
UCSE
09/Feb/06
1.1.1
Correction and answer feed back
Whole Group
07/Mar/06
1.2
Re construct the requirements into
three modules
Thanh
08/Mar/06
1.3
Modified appendix section and
added change log and negotiation
outcomes Some editing of section 3
Aaron
08/Mar/06
1.4
Added functional requirements
Thanh
09/Mar/06
1.5
Organized (by importance) and
edited requirements
Aaron Kaspar
Added to and changed all
appendices. (Aaron)
Editing
09/Mar/06
1.5.1
Edits to document, Checking for
Long Stretch Software 2006
Page - 2
Mindy
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
requirements correctness
09/Mar/06
1.5.2
Added requirements to satisfy
Negotiation outcomes
Aaron
09/Mar/06
1.6
Added use cases and architecture
Thanh, Jeff, Rizwan,
Mindy, Charles,
Scott
09/Mar/06
1.6.1
Added and changed more
requirements
Aaron
10/Mar/06
1.6.2
Formatting in Appendices.
Comments and edits to document
Aaron
10/Mar/06
1.6.3
Checking for ambiguity. Comments
and edits to document.
Mindy
10/Mar/06
1.6.4
Edit user interface requirements.
Scott
10/Mar/06
1.6.5
Updating + adding requirements
Aaron, Mindy
10/Mar/06
1.6.8
Added appendix section B – 3
Client comments on RS 1.0. Added
prototype images.
Aaron
11/Mar/06
1.6.9
Proofread, and edited the document
for spelling and grammar mistakes
and internal conflicts and
ambiguities. Added references to
the addressed elicitation questions
and answers. Added references to
the figures in Appendix C.
Rizwan, Mindy,
Aaron, Scott.
11/Mar/06
1.7
Proofread again for spelling,
grammar, inconsistencies and dead
references.
Rizwan
11/Mar/06
1.7.1
Updated and fixed change log, TOC
and references in the document.
Aaron
11/Mar/06
1.7.2
Spelling and Grammar Checking
Mindy
11/Mar/06
2.0
Finishing touches
Aaron
02/Apr/06
2.2
Added “Game Concepts” section
Rizwan
02/Apr/06
2.3
Added new/modified prototype
screens and explanations for
example challenges + puzzles
Aaron
02/Apr/06
2.3
Added descriptions to original
Mindy
Long Stretch Software 2006
Page - 3
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
prototype screens
02/Apr/06
2.3.1
Added/modified requirements
related to puzzles/problems. Added
glossary, updated game use-cases.
Aaron
03/Apr/06
2.3.2
Added/modified functional
requirements of the game modules
Thanh, Scott, Josh,
Jeff
04/Apr/06
2.3.3
Performed partial proofreading
Rizwan
04/Apr/06
2.3.4
Finished proofreading all the newly
added content.
Rizwan
04/Apr/06
Entire
documen
t
Added the final version of RS 3.0
into ReqPro, created traceability
matrices
Mindy
06/Apr/06
2.4
Addressed outstanding issues from
RS 2.1. Editing.
Rizwan, Thanh,
Scott, Jeff
06/Apr/06
2.4.1
Added outstanding changes to logs.
Edited and updated requirements.
Changed some requirements from
FR to NFR, and updated matrices.
Editing.
Aaron
06/Apr/06
2.4.2
Added more outstanding changes to
logs. Cleared up issues from
inspection. editing
Jeff
06/Apr/06
3.0
Final touches and editing.
Aaron
Long Stretch Software 2006
Page - 4
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Executive Summary
This document is the Requirements Specification document for the UVic Center for Scholastic
Entertainment (UCSE) Educational Game Project. It provides detailed descriptions of the
software, user, and hardware interfaces of the system, and includes a detailed description of the
user interface for the system.
UCSE has chosen Long Stretch Software Developers Inc to design and implement an educational
game designed to help students in grades 1 & 2 with Math, English and Problem-Solving skills.
The intention of the game is to allow the users to practice their mathematical and English skills
in a fun and entertaining manner. It will also be a tool for teachers to evaluate the students.
Teachers of the grades 1 and 2 students will use the game to track development in individual
students and as a possible marking guide. Teachers will also export relevant data for creating
spreadsheets and graphs of individual and group performance. The game will be also be
available for home use so that parents of the students are able to see the progress of their
child(ren).
The objective of the Software Requirements Specification is to provide a summation of the
findings thus far in the development stage of the project. It will be treated as a working
document and provides a detailed outline of the system from the client's perspective.
Long Stretch Software 2006
Page - 5
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Table of Contents
Executive Summary
5
1.
Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 Glossary
1.5 References
1.6 Overview of Document
9
9
9
9
10
11
11
2.
Overall Description
2.1 Product Perspective
2.1.1 System Interfaces
2.1.2 User Interfaces
2.1.3 Hardware Interfaces
2.1.4 Operations
2.2 Game Concepts
2.2.1 Rationale
2.2.2 Characters
2.2.3 Levels and Sections
2.2.4 Game Interfaces
2.2.5 Story and Goal
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
11
11
11
11
11
12
12
12
12
13
14
14
14
15
15
3.
Specific Requirements
3.1 Game module
3.1.1 Game Use Cases
3.1.2 Functional Requirements
3.1.3 Usability requirements
3.1.4 Reliability requirements
3.1.5 Performance requirements
3.1.6 Supportability requirements
3.1.7 Design requirements
3.1.8 Documentation
3.2 Administration module
3.2.1 Administration Use Cases
3.2.2 Functional Requirements
3.2.3 Usability requirements
3.2.4 Reliability requirements
3.2.5 Performance requirements
16
16
16
21
31
31
32
32
32
33
34
34
36
37
37
37
Long Stretch Software 2006
Page - 6
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
4.
Version:
3.0
Date: 04/07/06
3.3
Database backend
3.3.1 Database Use Cases
3.3.2 Functional Requirements
3.3.3 Reliability requirements
3.3.4 Performance requirements
3.3.5 Interfaces requirements
3.4 Common requirements
3.4.1 Usability requirements
3.4.2 Design constraints
3.4.3 Hardware Interfaces
3.4.4 Software Interfaces
3.4.5 Licensing Requirements
3.4.6 Legal, Copyright and Other Notices
37
37
39
39
40
40
40
40
40
40
40
41
41
Game Architecture
4.1 Game module (see section 3.1)
4.1.1 Functions
4.1.2 Architecture
4.2 Database module (see section 3.3)
4.3 Administration module (see section 3.2)
41
41
41
41
43
43
Appendix A - Change Logs
A - 1 Requirements Added Since RS 2. 0
A - 2 Changed Requirements from RS 2.0
A - 3 Document Changes from RS 2.0
A - 4 Requirements Added Since RS 1. 0
A - 5 Changed Requirements from RS 1.0
A - 6 Document Changes from RS 1.0
44
44
46
47
48
50
50
Appendix B - Outcomes of Client Communication
B - 1 Requirements Elicitation (January 23, 2006)
B - 2 Requirements Negotiations (March 7, 2006)
B - 3 Client comments on RS 1.0
B - 4 Client Comments on - RS 2.0
52
52
53
54
56
Appendix C - Prototype Screens
C - 1 Sample Challenges
C - 2 Sample Puzzle:
C - 3 Screens for Game Module
C - 4 Screens for Administration Module
60
60
62
62
65
Appendix D Traceability Matrices
D - 1 Requirements vs. Requirements
D - 2 Requirements vs. Rationale
67
67
68
Long Stretch Software 2006
Page - 7
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
D - 3 Requirements vs. Test Cases
Long Stretch Software 2006
69
Page - 8
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
1. Introduction
Long Stretch Software (LSS) will be developing a much needed computer game designed to
teach students of Grades 1 and 2 basic Math, English and Problem-Solving skills. The name of
the game is “Elementary Quest”. The game will be entertaining yet educational and will allow
teachers to track the progress of the students. This document outlines the specific requirements
for each module of the system as understood by LSS.
1.1 Purpose
This document is a proposal for requirements specification in response to the UVic Center for
Scholastic Entertainment’s Request for Proposal posted on January 16, 2005. The LSS team is
very excited about the idea of the game and prospects of working on its development. We are
also very confident that our level of expertise and experience in the industry will match the
sophistication of the game’s requirements.
1.2 Scope
The requirements specified in this document will be used for designing all the aspects and
components of the game. The document will be updated as the requirements grow and change
over the design and development process.
1.3 Definitions, Acronyms and Abbreviations
2x CD ROM - refers to the reading speed of the CD-ROM drive.
BA - Business Analyst
DirectX - Microsoft’s application programming interface for graphics programming.
Eclipse - An IBM IDE
ESRB - Entertainment Software Rating Board
EULA - End Users License Agreement
FTE - Fulltime Equivalent
HDD - Hard Disk Drive
IDE - Integrated Development Environment
IP - Intellectual Property
Java - Sun’s Java Language: Provides multi-platform support
JRE - Sun’s Java Runtime Environment
LSS or LSSD - Long Stretch Software Developers Incorporated
Macintosh - Apple’s computer model as well as the operating system that comes along with it.
MB - Approximately 1 million bytes of storage space.
Mhz - Computer processor speed is measured in hertz; A megahertz is about 1 million hertz.
NPC – Non Playable Character.
RS - Requirements Specifications
RFP - Request for Proposal
SME - Subject Matter Expert
TCP/IP - Transport Communication Protocol/ Internet Protocol
UCSE - UVic Center for Scholastic Entertainment
VGA – Video Graphics Array. VGA graphics cards have a minimum resolution of 640 x 480
Long Stretch Software 2006
Page - 9
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
pixels.
Windows - Microsoft’s operating system.
1.4 Glossary
This glossary contains terms intended to clarify the document for the reader. Throughout the
document, glossary terms are linked back to this section. Not all words may be linked, but at
least one instance of each word should be linked in each paragraph.
Extra note: Because RequisitePro was used, and it applies its own styles to the requirements,
some links may not be visible within the requirement statements.
challenge:
A learning element of the game. Challenges will contain both instructions and a practice
question. Challenges are described in section 2.2.3.1, and examples are given in
Appendix C - 1.
game world:
The game world is a made up of a set of levels, and is the overall setting for the story of
the game. The game world will not be accessible in its entirety at the beginning of the
game; new levels will be unlocked as the player progresses. The game world is
introduced in section 2.2.
level:
A level is a large subsection of the game world, made up of a number (varies by level) of
sections. Levels are introduced and explained in section 2.2.3.
level map:
The map which displays the sections of the current level. The level map is introduced in
section 2.2.4.1.
non-playable character (NPC):
A character in the game that is controlled only by the game system. NPCs as defined
here, are not limited only to human-style characters, but could also be monsters or
objects. The player will interact with the NPCs in the game which will present the player
will challenges. NPCs are introduced in section 2.2.2.
puzzle:
A puzzle in the context of the game is a learning element, which a player must complete
to advance to new sections of the game. Puzzles are explained in section 2.2.3.1 and an
example given in Appendix C - 2.
scene:
A scene refers to what the user sees at a given point in a section, when he/she is able to
move his/her character around. That is, a scene is what the user sees when he/she is not
currently attempting a challenge or puzzle, and he/she is not looking at the map.
section:
A section of the game is a sub-division of a game level. New sections of a level are
unlocked as the player completes puzzles at the end. Sections are introduced in
document section 2.2.3.
Long Stretch Software 2006
Page - 10
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
world map:
The map which displays the levels of the game world. The world map is introduced in
section 2.2.4.1.
1.5 References
UVic Center for Scholastic Entertainment (UCSE) Education Game System: Request for
Proposal Version 1.0.
1.6 Overview of Document
There are four main sections following this introduction:
Section 2 will provide an overview of our vision of the system including our perspectives of the
game, assumptions of user characteristics and interactions, and some design constraints.
Section 3 will detail the requirements that the system will satisfy, as well as provide use-cases to
help the understanding of the system. Requirements and use-cases are organized into the
modules of the system that they apply to (see section 2.1).
2. Overall Description
2.1 Product Perspective
There are three main components of the system:
 Game module: the game which students will play and learn from.
 Administration module: administration interface for the teachers to access student
records.
 Database backend: handles the storage of all player and game statistics.
These modules are described in detail in the architecture section (section 4) of the document.
2.1.1
System Interfaces
The database server will interact with the game and administration clients through a LAN.
2.1.2 User Interfaces
The interface for the students will be entertaining and engaging. Menus will be easily accessible
throughout the game. Once the game is in playing mode, everything a player/student needs will
be clearly visible on the screen and easily accessible. Students will the find the most basic
functions of the game fun to play, from character creation to the educational exercises.
2.1.3 Hardware Interfaces
The product is required to operate on both Macintosh and Windows systems. As such, the game
should be able to adjust to one button mouse input or two button mouse input depending on the
system it’s running on.
The keyboard will also play an integral role in the student's interaction with the game. Answers
to some questions will have to be typed in, and the character movement will be accomplished
using either the mouse or the keyboard.
Long Stretch Software 2006
Page - 11
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Students’ results will be transferred to and from a server through any standard networking
hardware.
The graphical content will be at least 256 colors at a resolution of 640x480 and at most 32
million colors with a resolution of 1280x1024. This will allow for the game to be played on older
computers commonly found in elementary schools. The amount of graphical content will also be
limited to ensure that the total size of the game remains under the 80MB limit.
2.1.4
Operations
The game will provide the following minimal operations:
 It will teach Math, English and Problem Solving skills to grade levels 1 & 2 in an
entertaining and engaging manner. See section 3.1.7.2 for more details.
 It will provide functionality for teachers to track and evaluate student progress. See
section 3.2.2 for more details.
 It will provide user interface and controls for the targeted audience. See sections 3.1.3.1
and 3.1.3.2 for more details.
 It will provide difficulty levels to cater the skill level of the users. See section 3.1 for
more details.
2.2 Game Concepts
This section describes the overall concepts behind the game module of the system. The ideas
discussed here will be useful in understanding the terms used throughout the use-cases and
requirements sections of the document.
As mentioned before, the product that is being specified in this document is an educational game.
The game can be categorized as an RPG – Role Playing Game. In an RPG, the character moves
throughout the game “world” and discovers new things, encounters new challenges, interacts
with non-playable characters (NPC), thereby making it a fun and interactive experience for the
user.
2.2.1 Rationale
The rationale behind making this game an RPG is that the game must create and hold user’s
interest on a daily basis for a long period of time (around two years). The challenge of course is
to create interesting content for the RPG, as well as provide enough amount of interaction
between the user and the game.
2.2.2 Characters
The user will be able to choose a character and play the game in the character’s role. The
character will be a human child of either male or female gender. The character’s clothes,
accessories, skin color, etc. will be customizable.
Once the user has chosen a character, he/she will be able to control the character inside the game
and make it perform actions such as walking around or solving puzzles, by using the keyboard
and mouse.
Long Stretch Software 2006
Page - 12
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
The non-playable characters will typically be dragons, dinosaurs, princes and princesses since
such characters are of a great interest to the targeted user group. Also, for the purpose of this
document, ‘NPC’ also refers to objects which the player can interact with. The main character
will interact with the NPCs to learn new concepts, as well as be tested on the concepts he/she has
learned.
2.2.3 Levels and Sections
The game world will be made up of levels which will increase in difficulty. The user will
progress through the game by advancing to higher and higher levels. There will be plenty of
levels to keep the user interested in the game for at least two years. The levels will have
interesting names to arouse curiosity in users. The levels in turn will have different sections on
math, English and problem solving. Throughout each section, the character will acquire new
skills, and will be tested on those skills before finishing each section. When the user finishes the
final section in a level, he/she will advance to a new level which will have similar sections - just
more difficult, as far as educational material is concerned. However, as far as the game play and
look and feel of the game are concerned, the sections will have to be original and non-repetitious
so as not to bore the player.
2.2.3.1 Challenges (Questions) and Puzzles
Within levels and section, the main activities will be challenges, and the transition points
between sections (and levels) will be puzzles. Both concepts are introduced below.
Challenges will be the instructional and practice elements of the game. The player will
encounter challenges through interaction with the NPCs throughout the game. Challenges will
be simple, only focusing on a single topic (for example, nouns or addition). The challenge will
first provide instructions, and then pose a question to the player to allow them to practice the
concept. The questions will be both multiple-choice and text-entry based types. If the player
answers incorrectly, a hint will be given, and some possible incorrect options will be removed,
and then the player will be able to once more. When the player completes a challenge they will
advance or be rewarded with money or items.
Puzzles are intended to function as tests in the game. A player will encounter puzzles as he/she
progresses through the game. In order for the player to advance to new levels of the game, they
will need to complete a puzzle. Unlike challenges, puzzles do not provide the player with
detailed instructions or introductions to new concepts; only brief instructions on how to complete
the puzzle. This way, a puzzles functions as a test to ensure that the player is learning as he/she
advances. An example puzzle is shown in Appendix C - 2.
2.2.3.2 Progress reward
During the game play, the player will be rewarded for correctly responding to the challenges or
completing puzzles. The points (money) rewarded should correspond to the difficulty level of the
challenge or the puzzle.
With the reward points (money), the player can buy new items for his/her character or unlock
new features of the game.
Long Stretch Software 2006
Page - 13
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
The progress reward in terms of money is meant to keep the student interested in the game for a
long time. It also reinforces the adventurous characteristics of the game.
2.2.4 Game Interfaces
This section describes the look and feel of the game, as well as some of the interfaces that the
user will see (i.e. Maps).
2.2.4.1 Maps
The user will have access to two different maps: the world map and the level map. The world
map will display the levels the user has finished, as well as the levels ahead. The levels ahead
will be grayed out, meaning inaccessible to the user. The user will be able to go back to any of
the levels he/she has already finished. The level map will work in a similar fashion. It will
display all the sections on a particular level, and the sections not yet explored will be
inaccessible to the user. The user will be able to go back to any of the sections he/she has
already finished.
2.2.4.2 Setting and Scenes
The game setting will typically include green landscapes, castles and dungeons based on sections
and levels. A level will typically be a landscape or a castle, and each section will be a part of
that structure; for example, in case of a level being a landscape, the section will be a small
village. An exploration scene will be presented to the user every time the user finishes a section.
An exploration scene will have arrows to the sections showing the user to pick a certain path to
select a particular section. There maybe more than one section to advance to, after finishing a
section, or the user will also be able to go back to the section he/she just finished.
2.2.4.3 Menu and Status bar
The game will always display a status bar which will display things such as the current level, and
the section the user is in as well as the amount of money the user has earned. The user will also
have access to an option menu which will allow user to adjust sound, music and provide access
to in-built help system.
2.2.5 Story and Goal
The overall story of the game will involve the prince/princess being kidnapped by an evil
character. The main character then would go on a rescue campaign, passing hurdles and
challenges, gathering hints, defeating the enemies encountered, and rescuing the prince/princess.
The goal of the character will be to explore the game, encounter the NPC, learn new skills and
pass the challenges (educational puzzles or problems) that the NPC pose, and earn rewards.
2.3 User Characteristics
This game is targeted towards children attending Grades 1 and 2. These grades typically
correspond to ages ranging from 6 to 8 years. At this stage in school, children are expected to
Long Stretch Software 2006
Page - 14
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
have rudimentary reading and math skills. Children in this age range tend to have very short
attention spans, and great effort must be put in to maintaining their interest. They also tend to be
very curious, and may inadvertently cause problems as a result.
Most children likely have had access to computers at home, but this cannot be guaranteed, so
some children may not have the computer skills necessary to operate the game without guidance.
However, they are generally very good at following patterns and can be taught fairly easily.
Starting with ages between 6-8 years, girls and boys show very different characteristics from
each other. They will have very different interests and sources of entertainment: a factor that
cannot be ignored. Also, girls in this age range tend to be more mentally advanced and developed
than their male counterparts.
Because the game is intended for in-school use, teachers will be administrating the game, and
must also be considered in the development of the game. Teachers represent a much more varied
age range and background than children, but it can be assumed that they will have basic
computer skills, such as word and spreadsheet processing, e-mail and web browsing.
2.4 Constraints
The following constraints are specified in the RFP Version 1.0:
 Platform independence is necessary since schools may have different computer Operating
Systems.
 Because a lot of schools are using older systems this game should run on a system with
these requirements:
o Windows 95 and newer: 200 MHz processor, 64MB ram, 80 MB HDD space,
Mouse, VGA video card, 2x, or better, speed CD-ROM, DirectX compatible
sound card.
o Mac OS 7.6 and up: 200 MHz processor, 64 MB ram, 80 MB HDD space,
Mouse, VGA video card, 2x, or better, speed CD-ROM, Monitor Requires
640x480, 256 color
 It will be necessary to test the game on children to ensure that it is entertaining and easy
to use.
 The designers will coordinate with teachers, parents, child entertainers, child
psychologists and other educators in the development of the software. This is to ensure
that the subject matter and educational material is appropriate for the students. As
decided during the negotiations, the game will be rated E for “Everyone” as per standard
game ratings. As such, the developers will need to make sure that the game content
adheres to ESRB’s E rating specifications.
2.5 Assumptions and Dependencies
We assume the following responsibilities from the client during the game development process:
Dedicate an FTE business analyst to liaison with our developer team. This person must be able to
make decisions regarding changes in the requirements.
 Throughout the development process, the client will organize meetings and workshops
with the target user groups to test the software.
 In order to finish the project on time, the documentation must be reviewed and signed off
within one week of the delivery of our deliverables. The following are the deliverables
Long Stretch Software 2006
Page - 15
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
deadlines requested in the RFP 1.0:
January 26
January 30
February 6
March 2
March 6
March 10
March 16
April 3
March 30 – April 6
Meeting to discuss RFP
RS 1.0
RS 1.1
Prototype Demo
Requirements Negotiations
RS 2.0
RS 2.1
RS 3.0
Final Demo
3. Specific Requirements
In this section, we will specify detailed requirements for the educational game system. Our
designers and programmers will design and build the game based on these requirements. The
system requirements have been divided into four sections - one for each of the three modules of
the system – Game, Administration and Backend – and one for requirements common to the
whole project. Requirements are grouped by type under headings within each section (‘3.1.1
Functional Requirements,’ for example). Our testers will work with client BA to implement test
cases based on the requirements specified here as well.
In this section, each requirement will appear in the order of importance among the requirements
of the same section. However, all requirements must be satisfied unless changes are agreed upon
by both LSSD and UCSE.
In this revision of the document (3.0) we have decided to go into further detail on the
requirements for the game module. We feel that this is the most important component of the
system, and must be properly defined before the remaining parts are completed.
3.1 Game module
3.1.1 Game Use Cases
To thoroughly understand the game modules, we created a list of use cases and created
prototypes for the use cases:
Use Case 1: Modify Character
Actors: Student, the Game Module
Purpose: Because the game must be entertaining, the student must be able to make changes to
his or her own character in the game.
Description: The character stats use case can be accessed at any time during game play by the
student and the game will invoke it automatically as the character advances to the next level. The
student can then change the appearance of the character and use his/her credit to buy new items
such as outfits, armors, accessories, and toys.
Long Stretch Software 2006
Page - 16
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Primary Scenario 1.1
Actor Action
Student presses character screen button.
Version:
3.0
Date: 04/07/06
System Response
Game module displays the character
screen. See Appendix C - 3.1 .
Possible Alternative: See 1.1-3
3. Student Changes a character option
(see appendix C - 3.1 for complete list).
4. Game Module updates character image
in the display portion of the screen.
Possible Alternative: See 1.1-5.
5. Student exits character screen by
clicking on the return button.
Game Module saves changes to database
and loads previous game screen.
Alternative Scenario 1.1-3: Student buys an item
3.(a)Student selects item to purchase
with play money.
3.(b) Game Module checks for sufficient
funds.
3.(c) Game Module makes items available
to equip, and informs student of such.
Return to Step 4 in primary scenario.
Alternative Scenario 1.1-5: Student updates another character option
5.(a)Student changes another character
option.
Return to Step 4 in primary scenario.
Secondary Scenario 1.2
Actor Action
Student logs in for the first time.
System Response
Game module displays the character
screen. See figure C - 3.1.
Student changes a character option to
customize it.
4. Game Module updates character
image in the display portion of the screen.
Possible Alternative: See 1.2-5.
5. Student exits character screen by
clicking on the return button.
Long Stretch Software 2006
Page - 17
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Actor Action
Version:
3.0
Date: 04/07/06
System Response
6. Game Module saves changes to
database and loads previous game screen.
Alternative Scenario 1.2-5: Student updates another character option
5.(a)Student changes another character
option.
Return to Step 4 in secondary scenario.
Use Case 2: Explore Maps
Actors: Student, the Game Module
Purpose: For the student to explore the level map or world map.
Description: Each level will have a map contain different sections . The game world will have a
map containing the different levels of the game. The student will use the world map to access
available levels, and the student will be able to explore the level map to get to the scene to
encounter the challenges. Depending on the level map, the student can access the sections
randomly or must access the sections in a prescribed order (or some combination). The level
map will indicate the areas the student has already explored. When the character enters a
section, the game will bring the character into the scene (See Use Case 3). When all sections on
the level map are discovered, and the final puzzle has been solved, the game will unlock the next
level(s) (see 3.1.2.1.7).
Primary Scenario 2.1
Actor Action
1. Student presses world map button.
System Response
2. Game module displays the world
map screen. See Appendix C - 3.2 .
3. Student picks an available level.
Possible Alternative: See 2.1-4.
4. Game Module displays level map
for the selected level. See Primary
scenario 2.1
Alternative Scenario 2.1-4: Student clicks on unavailable section
4.(a)Game module plays error sound.
Return to Step 3 in primary scenario.
Secondary Scenario 2.2
Actor Action
1. Student presses level map button.
System Response
2. Game module displays the level map
screen. See Appendix C - 3.2 .
3. Student picks an available section.
Long Stretch Software 2006
Page - 18
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Actor Action
Version:
3.0
Date: 04/07/06
System Response
Possible Alternative: See 2.1-4.
4. Game Module displays first scene
for selected section.
Alternative Scenario 2.1-4: Student clicks on unavailable level
4.(a)Game module plays error sound.
Return to Step 3 in secondary scenario.
Use Case 3: Explore Section
Actors: Student, the Game Module
Purpose: For student to explore the current section
Description: Sections are sub-elements of the game levels, as introduced in section 2.2.3. The
visual and story themes of the scene will be related to the current level. The challenges and
puzzles in a given section will be of a similar type (e.g. English based, or math based). When
student interacts with an NPC, the game will present a challenge to the character (See Use Case
4). When the required challenges for a section have been overcome, the student will encounter a
puzzle, which they must complete to finish the section.
Primary Scenario 3.1
Actor Action
1. Student presses valid level on the
world map screen.
System Response
2. Game module displays first section of
the selected level. See Appendix C - 3.3.
Possible Alternative: See 3.1-3.
3. Student clicks on a direction heading.
4. Game Module loads appropriate
scene for the section, based on the
player’s current location.
Alternative Scenario 3.1-3: Student interacts with an NPC
4.(a)See Use Case 4
Return to Step 3 in primary scenario.
Use Case 4: Answer Challenge
Actors: Students, the game modules
Purpose: This is the main objective of the game. The student will be tested by responding to the
challenges.
Description: The challenge can be any form of question. Questions will be posed as multiplechoice or text-entry types. The degree of difficulty of the challenge should correspond to the
student level. Once the student completes a challenge, the game will bring the student back to
Long Stretch Software 2006
Page - 19
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
the current section (See Use Case 3). When the student finishes some challenges, he/she will be
rewarded with credit to buy more stuff (See Use Case 1). Student progress will be logged so that
he/she doesn’t need to redo challenges even if the game crashes.
Primary Scenario 4.1
Actor Action
1. Student encounters a challenge by
clicking on a NPC to talk to them.
System Response
2. Game module displays a challenge.
Challenge question is multiple choice or
text-entry. See examples in Appendix C
- 1.
3. Student reads the theory and answers
the question by selecting a choice from
multiple-choice question, or typing a
response.
4. Game Module records answer to be
either correct or wrong and time stamps
it.
5. Game Module informs the student of
his answer being correct or incorrect.
The student is rewarded.
Possible Alternative 4.1-6.
6. Student clicks anywhere to return to
the current scene.
7. Game Module loads the previous
scene before beginning the challenge.
Alternative Scenario 4.1-6: Student got the question wrong.
6.(a)Game Module displays a hint,
simplifies the problem (if possible – see
3.1.2.1.2) and asks the student to try
again.
6(b1) Student attempts to answer the
problem again.
Return to Step 4 in primary scenario.
Use Case 5: Complete Puzzle
Actors: Students, the game modules
Purpose: Main objective of the game. The puzzles are used to see if the student can apply what
he/she has just learned.
Description: When a student reaches the end of a section, they will be posed with a puzzle. The
puzzle incorporates the learning objectives of the particular section. No hint is given on the
theory behind the puzzle, only about how to solve the puzzle. The degree of difficulty of the
Long Stretch Software 2006
Page - 20
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
puzzle should correspond to the current level. Once the student completes the puzzle, the game
will bring the student back to the level (or world) map (See Use Case 2) where another possible
section (or level) is now unlocked. Student’s progress will be logged so that he/she doesn’t need
to redo the puzzle, if they “Give Up” (see alternate scenario 5.1-3) or even if the game crashes.
Primary Scenario 5.1
Actor Action
1. Student reaches the end of a section.
System Response
2. Game module displays the puzzle for
the current section. See Appendix C - 2.
Possible Alternative 5.1-3.
3. Student solves puzzle
4. Game Module records result in the
database (see 3.1.2.1.5).
5. Game Module congratulates student
6. Student clicks on “Continue”
7. Game Module loads level (or world)
map screen with at least one extra scene
(or level) on it unlocked (see 3.1.2.1.6 and
3.1.2.1.7)
Alternative Scenario 5.1-3: Student is unable to solve puzzle.
3(a)Student clicks on “GIVE UP” button
3.(b)Game Module records the student
giving up
3.(b)Game Module loads current section
that the student is exploring. The NPCs in
the section will present challenges useful in
understanding the knowledge required to
solve the puzzle.
The screen shots of the prototype, which associated with the above use cases can be found in
Appendix C.
3.1.2 Functional Requirements
Due to time constraints, we have decided to go into detail on the game module functional
requirements section, since this is the main component of the system and the other two subsystems’ designs will depend heavily on the design of the game system.
3.1.2.1 The game will teach the student new math and English concepts by presenting
them with challenges.
Examples of challenges for English and math are in appendix sections C - 1.1 and C - 1.2
respectively.
Long Stretch Software 2006
Page - 21
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Rationale: In section 2.0 of the RFP, the primary goal was for the game to teach the student
math and English skills. The “Challenges” in the game will accomplish this by providing the
student with instructions, then asking him/her a question based on that instruction.
Test scenario :
1) The player encounters a challenge (for example by talking to an NPC).
Output: The challenge is presented to the player on-screen.
2) The player reads the instructions and attempts to answer the challenge
question.
Output: The system will either a) congratulate and (if applicable) reward the
player for a correct answer, or b) display a hint and simplify (if applicable) the
problem if the answer is incorrect.
4) If the answer was correct, the player will continue, if not then they will try
again.
3.1.2.1.1 The game will require the student to correctly complete puzzles, in order to advance to the next
section of the game.
Rationale: These puzzles will teach the student problem solving skills as requested in section 2.0
of the RFP. The puzzles will also serve as tests of the concepts learned through challenges (see
0). An example puzzle is provided in appendix C - 2. This requirement also facilitates the
control of educational progress tracking (as requested in section 2.0 of RFP), since the student
will only advance once they can apply the concepts they’ve learned.
Test scenario :
1) The player encounters a puzzle by reaching the end of a section.
Output: The puzzle is presented to the player on-screen.
2) The player attempts to complete the puzzle.
Output: if the puzzle is successfully completed, the system advances them to a
new section of the game.
3) If the player cannot complete the puzzle they click “Give up” (see use case 5).
Output: The player is returned to the current section.
3.1.2.1.2 If a student answers a challenge incorrectly, the game will provide a hint and if applicable,
simplify the challenge.
Simplification of the challenge would only apply in the case that the question is multiple choice.
If the question required a typed answer, only a hint would be applicable. Simplification will
never remove all incorrect answers. See appendix C - 1.2 for an example of a simplified
challenge.
Rationale: This will address the client’s concern that the game not punish the students for
failures (see Appendix B - 4.8), since the students will always be able to arrive at the correct
answer. Because of the functionality addressed in 3.1.2.1.3, the system will still record the
student’s success rate. This also supports requirement 0, by helping the student to learn new
Long Stretch Software 2006
Page - 22
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
concepts by example, and to learn from their own mistakes.
Test scenario :
1) The player encounters a challenge (for example by talking to an NPC).
Output: The challenge is presented to the player on-screen.
2) The player reads the instructions and attempts to answer the challenge
question.
Output: The system will either a) congratulate and (if applicable) reward the
player for a correct answer, or b) display a hint and simplify (if applicable) the
problem if the answer is incorrect.
4) If the answer was correct, the player will continue, if not then they will try
again.
3.1.2.1.3 When student completes a challenge, the game module will record in the database the number
of attempts required for the student to complete the challenge and the final simplified version of the
challenge.
Rationale: This addresses the client’s request that the system track student progress (see RFP
section 2.0), and the data that they requested be tracked (see Appendix B - 1.10).
Test Scenario:
1) The player encounters a challenge (for example by talking to an NPC).
Output: The challenge is presented to the player on-screen.
2) The player reads the instructions and attempts to answer the challenge
question.
Output: The system will either a) congratulate and (if applicable) reward the
player for a correct answer, or b) display a hint and simplify (if applicable) the
problem if the answer is incorrect.
4) If the answer was correct, the player will continue, if not then they will try
again.
3.1.2.1.4 The game module will record in the database the total number of times a student “gives up” on
a puzzle (see use case scenario 5.1-3, and Appendix C - 2) before completing it, and a description of the
skills tested by the puzzle.
Rationale: This addresses the client’s request that the system track student progress (see section
2 of RFP and Appendix B - 1.10) including how many correct and incorrect answers they have
given. A description of the puzzle is provided, instead of “the question he had wrong with the
answer the kid inputted,” as requested, since the puzzles will be visual in nature, making it
impossible to store the actual puzzle and answer in the database and progress reports.
Test Scenario :
1) The player encounters a puzzle by reaching the end of a section.
Output: The puzzle is presented to the player on-screen.
2) The player attempts to complete the puzzle.
Output: if the puzzle is successfully completed, the system advances them to a
Long Stretch Software 2006
Page - 23
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
new section of the game.
3) If the player cannot complete the puzzle they click “Give up” (see use case 5).
Output: The player is returned to the current section, and a database record is
incremented to indicate the number of times the student has given up on that
puzzle.
3.1.2.1.5 If a student cannot complete a puzzle, and chooses to “give up”, the game will direct the
student back into the beginning of the current section, and provide relevant challenges (see 3.1.2.1.1 and
Use Case 5) to help.
Rationale: This addresses the concern that the clients raised during the prototype demo, which
was “[sic.] What happens if a student cannot solve a puzzle?”
Test Scenario :
1) The player encounters a puzzle by reaching the end of a section.
Output: The puzzle is presented to the player on-screen.
2) The player attempts to complete the puzzle.
Output: if the puzzle is successfully completed, the system advances them to a
new section of the game.
3) If the player cannot complete the puzzle they click “Give up” (see use case 5).
Output: The player is returned to the current section.
3.1.2.1.6 When a student completes the final puzzle in a section, the game will unlock another portion
(defined below) of the level and display it on the level map.
An unlocked portion of the map will depend on the design of the particular level.
Rationale: Unlocking portions of the map will allow the system to control and track student
progress (as requested in RFP section 2.0), as well as providing increasing difficulty of learning
elements (as requested during elicitation, see Appendix B - 1.3). Unlocking a variable number of
sections will allow the student to choose their own path to some extent, thereby making the game
more fun (as requested in the RFP).
Test Scenario :
1) The player encounters the puzzle in any non-final section of a level.
Output: The puzzle is presented to the player on-screen.
2) The player completes the puzzle.
Output: The system records that the student has completed the puzzle (as
described in 3.1.2.1.4). The level map is displayed with the unlocked sections
indicated.
3.1.2.1.7 When a student completes the final puzzle in a level, the game will unlock another portion
(defined below) of the world and display it on the world map.
An unlocked portion of the map will contain at most three levels, each containing learning
elements of equal difficulty.
Rationale: Unlocking portions of the map will allow the system to control and track student
Long Stretch Software 2006
Page - 24
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
progress (as requested in RFP section 2.0), as well as providing increasing difficulty of learning
elements (as requested during elicitation, see Appendix B - 1.3). Unlocking a variable number of
levels (up to three) will allow the student to choose their own path to some extent, thereby
making the game more fun (as requested in the RFP).
Test Scenario:
1) The player encounters the final puzzle in the final section of a level.
Output: The puzzle is presented to the player on-screen.
2) The player completes the puzzle.
Output: The system records that the student has completed the puzzle (as
described in 3.1.2.1.4). The world map is displayed with the unlocked levels
indicated.
3.1.2.2 The system will provide in-game tutorials and help.
The system is intended for use in classes, so the game will need to provide support for students
that need help. A single teacher will not be able to help all students all the time so the game
should include an in-game tutorial and a help document. The purpose of the in-game tutorial is to
familiarize the student with new navigation elements that appear during the game play. The
purpose of the help document is to provide instructions on how to install the game and how to
play the game.
Tutorial:
 On screen balloon box.
 Test basic computer skills as part of the tutorial.
Manual:
 Instruction Guide for Teachers and Administrators for lab environment.
 Installation Guide and User Guide for parents/home users.
3.1.2.2.1 The system will test basic computer skills as part of a starting tutorial.
As part of the creation of a new character, the user will be stepped through a lesson in basic
computer skills. It will teach the user how to use the mouse, the keyboard, and view messages
on the screen. After the character is created, the tutorial may be skipped on successive game
plays.
Rationale: As per the client's inspection of RS 1.0 (See appendix B - 3.5).
Test Scenario :
1) The player creates a new character.
Output: the system has a new account with the specified character name.
2) The game is started in the tutorial area.
Output: the system loads the tutorial scene.
3) The player completes the tutorial level.
Output: the system informs the player that they have completed the tutorial, and
the main game is loaded.
4) The player is now familiar with using the mouse and the keyboard.
Long Stretch Software 2006
Page - 25
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
3.1.2.2.2 The system will show on-screen help balloons after hovering the mouse pointer over an object
for 2 seconds.
In order to facilitate the use of the game and admin modules, every user interface object (such as
an “OK” button, ) will have an individual help balloon associated with it. A balloon will include
a description of the object and how to use it. To view a help balloon, all the user has to do is
leave the cursor over the object for 2 seconds.
Rationale: As per the client's inspection of RS 2.0 (see appendix B - 4.2).
Test Scenario :
1) The player is on the map screen and doesn't know what to do.
2) The player holds the mouse over the icon for the ‘EasyStreets’ (see appendix C
- 3.2) level for two seconds.
Output: A help bubble pops up next to the mouse. The bubble explains that
pressing the left-mouse button on that icon will take him to “EasyStreets.”
3.1.2.3 The game module must send the student game progress to the database module
each time a student completes an objective in the game.
Rationale: If the game crashes, the student should not need to restart the level. So the game has
to keep track of the game progress after each objective is completed in order to keep the student
from getting bored from encountering the same thing again.
Test scenario :
1) User encounters and completes a challenge or puzzle. Immediately after, force
quit the system.
2) User launches the game, authenticates.
Output: The game opens the scene or the map the player used in the previous
session.
3.1.2.4 The game module will authenticate the student when the game is launched.
Rationale: Because one of the requirements in the RFP is that the teachers and the parents
should be able to track individual progress, each student has to authenticate himself/herself each
time he or she starts the game.
Test scenario :
1) User launches the game
Output: System displays prompt for username and password.
2) User enters username and password.
Output: If correct combination entered, the game launches and opens the last
scene the user was in. If incorrect combination entered, the system displays an
error message and re-prompts.
3.1.2.5 The game will entertain and engage the attention of the students.
The game must provide a level of entertainment to the student to help keep him/her engaged and
Long Stretch Software 2006
Page - 26
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
focused on the game. This is one of the key requirements outlined in section 2.0 of the RFP.
3.1.2.5.1 The system will provide game music and sounds
To help provide the user with an entertaining game experience, the game will feature music and
sounds that change as the user progresses through the game.
3.1.2.5.1.1 The system will allow game music and sounds to be turned on and off
Rationale : To help keep the students game experience positive, the game will play different
music and sounds throughout the game. Since the game will be predominantly used in a
classroom environment, in-game music and sounds may become distractive to other students.
Thus there will be options on the main menu that allow the user to turn on and off the music and
sounds.
Test Scenario:
1) The user clicks the main menu button.
Output: the main menu is displayed
2a) To turn either the music and sounds off, clicks the checkboxes marked ‘Off’
that are next to the words ‘Music’ and ‘Sounds’.
Output: If the ‘Off’ checkbox for ‘Music’ is clicked, the music turns off. If the
‘Off’ checkbox for ‘Sounds’ is clicked, the sounds are turned off.
2b) To turn either the music or sounds back on, select the checkboxes marked
‘On’.
Output: If the ‘On’ checkbox for ‘Music’ is clicked, the music turns on. If the
‘On’ checkbox for ‘Sounds’ is clicked, the sounds are turned on.
3.1.2.5.1.2 The system will play different music for each level.
Rationale: To help make the game more interesting and less repetitive, the background music
will change as the user travels from level to level.
Test Scenario :
1) On the map screen, the user chooses a destination.
Output: The corresponding scene is displayed, and music is played.
2) The user finishes with the scene & clicks the map button.
Output: The map is displayed
3) The user chooses a different destination
Output: The corresponding scene is displayed, but the music is different from
the previous scene.
3.1.2.5.2 The game will allow the user to adjust the properties of his/her character.
3.1.2.5.2.1 The user can buy and sell items for his/her character.
Long Stretch Software 2006
Page - 27
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Rationale: To provide a good level of entertainment to the game users, there will be a reward
system implemented, that allows the players to use the credits they have gained from correctly
answered questions to buy new items for their characters such as clothing, accessories, hair styles
and physical appearances. This will encourage the students to try their best to answer and many
challenges as possible so that they can accessorize their characters. This will make the game
entertaining, as requested in the RFP. An example screenshot is provided in appendix C - 3.1.
Test Scenario :
1) The user selects the character customization screen.
Output: the character customization screen is displayed
2) The user clicks the ‘Buy’ button.
Output: A new screen is displayed allowing the player to scroll through items
to purchase.
3) The user chooses an item to purchase and clicks the ‘Buy’ button
Output a: If the player has sufficient credits for the item, the character
customization screen is displayed, and the new item is shown in the character’s
inventory.
Output b: If the player does not have sufficient credits for the item, a message
is displayed stating that the user does not have enough credits to purchase the
item.
4b) The user clicks ‘Ok’ on the insufficient funds message window.
Output: The screen showing items to be purchased is again displayed. Return to
3.
3.1.2.5.2.2 The user is allowed to change his/her character’s gender.
Rationale: To give the student a more personable feel to the game characters, there is an option
to select the gender of the character. This will help the game appeal to all members of the
targeted user group outlined in the RFP. An example screenshot is provided in appendix C - 3.1.
Test Scenario:
1) The user selects the character customization screen.
Output: the character customization screen is displayed
2) The user selects the gender of his/her character by clicking the checkbox
marked ‘Boy’ or ‘Girl’ that is next to the ‘Gender’ option.
Output: The characters appearance changes to reflect the selected option.
3.1.2.5.2.3 The user can change the appearance of their character
Rationale: To allow the user to customize his/her character, the colors of the character can be
adjusted. The user can change the color of his/her skin, hair, gloves, shirt, pants, footwear and
other accessories. An example screenshot is provided in appendix C - 3.1.
Long Stretch Software 2006
Page - 28
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Test Scenario :
1) The user selects the character customization screen.
Output: the character customization screen is displayed.
2) The user clicks on the arrow button under the style column, or under the color
column.
Output: The color and/or style of the item changes to reflect the newly selected
color/style.
3) The user clicks the ‘Return’ button
Output: The game returns to where it was left off. The appearance of the user’s
character is changed as specified.
3.1.2.5.3 The game module will provide in game animations.
Rationale: To help keep the user engaged in the game, the game will have allow the user to
purchase special animation sequences for characters and display special animation sequences
when he/she is rewarded..
3.1.2.5.3.1 The game will provide character animations.
Rationale: Character animations will be used to make the game characters feel more interactive
by allowing the user to purchase and use character animations. As examples, such animations
may include dancing, arm pumping and thumbs up. Animations will be acquired by similar
methods used to purchase clothing as described in section 3.1.2.5.2.1. These animations will
server to entertain the user and make the game more fun, addressing one of the major goals
outlined in RFP section 2.0.
Test Scenario:
1) The user selects the character customization screen.
Output: the character customization screen is displayed.
2) From there, the user selects the ‘Arm Pumping’ animation.
Output: The system updates the characters selected animation.
3) The user presses the character animation key
Output: The character executes the arm pumping animation.
3.1.2.5.3.2 The game will provide reward animations
Rationale: To help reward students for getting corrects answers, reward animations will be
displayed periodically as the student correctly answers challenges. Examples of such animations
may include fireworks or dancing clouds. This will entertain the user while playing the game (as
requested in section 2.0 of RFP).
Test Scenario :
Long Stretch Software 2006
Page - 29
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
1) The user correctly answers a number of challenges.
Output: After a certain number of correct answers, the system displays a reward
animation such as fireworks or dancing clouds.
3.1.2.5.4 The game will provide a monetary credit system
Rationale: To help provide a level of interest to the user, there will be a reward system in the
form of game credits that is accumulated as the user correctly answers questions. These credits
will be separate from the score that is submitted to the Administration Module. The credits are
used to upgrade the user’s character. This encourages the user to correctly answer as many
questions as possible so that they will have a better character.
Test Scenario:
1) The user answers a question correctly.
Output: the system increases the amount of credits for the character, and the
credit display is updated accordingly.
3.1.2.6 The game installation will vary(defined below) depending on whether it is a school
installation or home installation:
For the home installation, no database configuration is necessary - progress will be stored locally
on the computer running the game.
For the school installation, two database setup options are provided: (1) create a new DB from
scratch using built-in scripts, or (2) choose from a list of existing databases detected by the
install program.
In addition to the school/home installation options, the setup program will allow the user to
choose either a full installation or a minimal installation (See also Section 3.1.5.1):
The minimal installation option is geared towards computers with limited hard drive space.
Instead of copying the game audio to the hard drive, it will be streamed from the game CD
during play (requiring that the CD content be accessible either locally or via LAN).
The full installation on the other hand will install the entire content of the CD to the computer
hard drive. This will help the game load faster but will require more disk space.
Regardless of the setup type, the game will automatically configure itself using the best settings
for the detected hardware (although options are available in-game to make changes to these
settings if necessary).
Rationale:
1) RFP section 4: "Parents will use the game to track the development of their
child/children at home in the same way as teachers do at school. Parents will also
be installing the game on home computers."
2) RFP section 6: "2. Because a lot of schools are using older systems this game
should run on a system with these requirements:
- Windows 95 and newer: Pentium 60, 16 MB ram, 80 MB HDD space, Mouse,
Long Stretch Software 2006
Page - 30
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
SVGA video card, 2x, or better, speed CD-ROM, DirectX compatible sound card
- Mac OS 7.6 and up: 16 MB ram, 80 MB HDD space, Mouse, SVGA video
card, 2x, or better, speed CD-ROM, Monitor Requires 640x480, 256 color."
3) RS1.1 Comments:
- full/limited install options (section 3.2.2)
4) RS2.1 Comments:
”2.1.3 Hardware Interfaces. The graphical content will be at most 256 colors at a
resolution of 640x480.” This is not necessarily true as we don't want to limit
newer hardware to this resolution and color. It should be possible to adjust the
resolution which will allow for game play at a range of possible resolutions from
640x480 to 1280x1024. That will provide the ability to run the game on a wide
range of hardware.
Test scenario :
1) There will be two deliverables: a lab version and a home version.
2) Run either of the two versions’ installation program
Output: Given two options: full installation and partial installation.
3.1.3 Usability requirements
3.1.3.1 The system will provide a user interface similar to those found in other children’s
games.
The user interfaces for the game itself (including load screens, and in-game menus) will be
similar to those found in other children’s games. “Similar” here refers to how the menu is
accessed, its appearance and how it reacts to input. Menus will also use animations and colors to
attract and maintain attention to important items. The game interface will be tested alongside
other children’s games to ensure that the interface is usable. See Appendix C for examples of the
interface.
3.1.3.2 User interface and controls that are simple enough for grades 1 and 2
The controls and menus in the game will be basic and easy to understand. Pop-ups will explain
the use of a button, or any other user interface functions.
3.1.4 Reliability requirements
3.1.4.1 Student progress automatically saved to database when goals are completed.
In the case of a system failure, students should not be required to repeat material that they have
already learned.
3.1.4.2 The game module will be able to operate 99% of the time when launched.
There is a potential for errors relating to the state of the operating system that could prevent the
game from launching (for example not enough resources available, etc.). The chance of such an
occurrence is at most 1%.
Long Stretch Software 2006
Page - 31
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
3.1.5 Performance requirements
3.1.5.1 The game will offer two installation modes – full and partial install.
The partial installation of the game will require the game CD to function, whereas the full
installation will be standalone. This satisfies hardware requirements specified in the RFP as well
as the client’s request (see Section B - 1.6) that a full install be available.
3.1.5.2 The game will occupy at most 80MB of hard disk space for the partial install.
3.1.5.3 The game will run smoothly on a computer with minimum system requirements of
a 200 MHz processor, 64MB of RAM and 2x CD-ROM drive or greater
Note that this requirement was changed from the RFP as the result of the negotiation session
(See Appendix B - 2).
3.1.5.4 Maximum time from launching the game until it is playable will be 5 minutes, but
average time over all supported systems will be less than 2 minutes.
After the application is launched, it will take fewer than 5 minutes for the player to load their
data and begin playing the game from where they last left off, on every supported system. To
address concerns that this load time is too long (See Appendix B - 2), LSSD will ensure that the
average load time over all supported systems is less than 2 minutes. This will help to ensure that
children do not lose interest while the game is being loaded.
3.1.5.5 Expected uptime will be 97%
The game itself will be able to run for at least 3 consecutive hours, 97% of the time.
3.1.6 Supportability requirements
3.1.6.1 The game will run on multiple computer platforms (specified below).
The game will be supported by a Windows 95 or higher, or a Mac OS 7.6 or higher operating
systems.
3.1.6.2 The game will be upgradeable by the users (teachers or parents) after installation,
using install packages provided by LSSD.
Future releases will be easy to install using a standalone installation package. Types of upgrades
could include expansion packs that offer new story content and maps, or patches to resolve bugs
found once the game is in production..
3.1.6.3 The game will not require regular maintenance.
As the game will be deployed in a large scale, once installed, the game itself should not need to
be maintained at scheduled intervals. However, problems from the host computer of the game
might prevent the game from functioning properly. In such an event, maintenance is still
required.
3.1.7 Design requirements
3.1.7.1 The completed game will have an ESRB rating of ‘E’.
As discussed during Requirement Negotiations (see B - 2), to ensure that the content of the game
is appropriate for children, the game must receive an ESRB rating of ‘E’. Details about this
rating can be found at http://www.esrb.org/esrbratings_guide.asp.
Long Stretch Software 2006
Page - 32
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
3.1.7.2 In order to be entertaining, the game will engage the student in a story line.
The RFP states that the game should be entertaining. In order to entertain the student, the game
module should engage the student in a story line. The designer should work with the UCSE’s
business liaison to come up with a sound story line.
For our prototype purpose, we came up with a story line which is discussed in section 2.2 Game
Concepts.
After the child has entered a building to “explore,” they will be approached by little monsters
with a word problem or math problem depending on the world that he/she is in. In order to
eliminate the monster, the student has to answer the question correctly. If the student answers the
question correctly then they will be given money so they can buy accessories for their character.
At the end of each level the student encounters a difficult “boss monster”. In order for the
student to get to the next level of the game the student has to beat the head boss monster by
solving a difficult puzzle. As the level of difficulty gets higher, the questions are harder and the
difficulty of the puzzle increases.
If the student is unable to beat the “boss monster” by solving the puzzle then check points are
created in the level that the student was in. The student has to then restart the level at the
checkpoint and retry solving the puzzle.
The game will go up to one level of difficulty higher than what grade 2 students are taught at in
the classroom. This difficulty level will be based on the in-class curriculum.
3.1.7.3 All game content will be interesting for boys and girls.
As discussed during Requirement Negotiations (see Appendix B - 2.4), the game content will not
be specific to one gender, as to make the game interesting and fun for both boys and girls.
3.1.8 Documentation
3.1.8.1 The game will be accompanied with user guides and tutorial both as in game help
and hard copy.
Online user guide and tutorial will be available for the game upon completion and delivery. The
documentation will be part of the game and also as hard copy accompanied with the game
packages (See section 3.1.2.1.1). The game will also come with built in help files and tutorials
for game play.
3.1.8.2 The system will provide an instruction guide in both electronic and paper formats
for teachers.
The system will ship with an included guide for teachers. The guide will have instructions on
how to install the admin module, the game module, and how to use the admin module to create
and monitor student accounts.As per the client's inspection of RS 2.0 (see Appendix B - 4.3)
Long Stretch Software 2006
Page - 33
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
3.1.8.3 The system will include an instruction guide in both paper and electronic versions
for parents.
The system will ship with an included guide for parents. The guide will have instructions on
how to install the game module on a home computer and start a new game. As per the client's
inspection of RS 2.0 (see Appendix B - 4.3).
3.2 Administration module
3.2.1 Administration Use Cases
All of the functional requirements are based on the following line on the RFP: “Teachers of
grades 1 and 2 will use the game to track development in individual students and as a possible
marking guide. Teachers will also export relevant data for creating spreadsheets and graphs of
individual and group performance.”
To study the requirement for this module, we designed the following use cases:
Use Case 6: Manage student accounts (create/edit/delete)
Actors: Teachers, the administration module
Purpose: Teachers must be able to create and manage accounts for their students as specified in
the RFP.
Description: When the teacher logs into the Administration system, they are presented with a
main screen that provides options to create, edit, and/or delete student user accounts for the
game.
Primary Scenario 6.1
Actor Action
1. Teacher logs in.
System Response
2. The main administration screen is
displayed. See Appendix C - 4.1.
Possible Alternatives 6.1-3a, 6.1-3b.
3. Teacher clicks the Create button
4. A window is displayed prompting
the teacher to enter the username and
password and other information such as
first name, last name, grade level for the
student.
Possible Alternative 6.1-5c
5. Teacher types in the enter the
username and password and other
information such as first name, last name,
grade and clicks Ok
6. The student account is created,
changed, or deleted from the database.
Long Stretch Software 2006
Page - 34
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Alternative Scenario 6.1-3a: Teacher chooses to edit an existing student account.
3(a) Teacher clicks the Edit button
4(a) A window is displayed prompting
to teacher to select an existing account
from a drop down list, and enter any
changes in the space provided.
Return to Step 5 in primary scenario.
Alternative Scenario 6.1-3b: Teacher chooses to delete an existing student account.
3(b) Teacher clicks the Delete button
4(b) A window is displayed prompting
the teacher to select an existing account
from a drop down list.
5(b) Teacher clicks the Delete button
Return to Step 6 in primary scenario.
Alternative Scenario 6.1-5c: Teacher chooses to cancel the action.
5(c) Teacher clicks the Cancel button
6(c) No changes are made and the
teacher is returned to the main screen.
Use Case 7: Export Student Progress (create/edit/delete)
Actors: Teachers, the Administration module.
Purpose: Teachers must be able to export student progress for analysis.
Description: When the teacher logs into the Administration system, they are presented with a
main screen that provides options to export progress for a single student, or for all students. The
student progress info can be exported as a comma delimited text file, or as an excel spreadsheet.
The only information can be imported and exported are those that is related to the student
progress (level, score, question answered) not the game play experience elements such as
character or items.
Primary Scenario 7.1
Actor Action
1. Teacher logs in.
System Response
2. The main Administration screen is
displayed. See figure C - 4.1 .
Possible Alternative 7.1-3a
3. Teacher clicks the Single Student
button
4. A window is displayed prompting
the teacher to select a student from a
drop down list.
Long Stretch Software 2006
Page - 35
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Actor Action
Possible Alternative 7.1-5b
5. Teacher selects the student and clicks
Export
Version:
3.0
Date: 04/07/06
System Response
6. A Save As dialog appears allowing
the teacher to save the progress
information in either text or excel
format.
Alternative Scenario 7.1-3a: Teacher chooses to export the progress of all students.
3(a) Teacher clicks the All Students
button
Return to Step 6 in primary scenario.
Alternative Scenario 7.1-5b: Teacher chooses to cancel the action.
5(b) Teacher clicks the Cancel button
6(b) No progress information is saved,
and the teacher is returned to the main
screen.
For each use case, we created a prototype. You can find the screenshots from the prototypes in
Appendix C - 4.
3.2.2 Functional Requirements
After inspecting the use cases and the prototype carefully, we came up with the following
functional requirements for the Administration module.
3.2.2.1 The administration module will generate reports of student progress.
The reports generated will allow the teacher to track the student’s learning progress. The reports
will include student results for each type of problem (math, English and problem solving), as
well as the time spent playing and their current progress level (as specified on the RFP).
3.2.2.2 The administration module will export report data (3.2.2.1) to Excel documents and
comma separated text documents.
The system provides export to Excel documents so that teachers can use a familiar program, as
requested in section 5 of UCSE’s RFP. Comma separated text document exports provide
portability because they can be read by any computer, as requested in negotiation section (see
Appendix B - 2.7).
3.2.2.3 The administration module will administrate the student accounts.
In order for the teacher to manage the student profiles, the teacher will be able to administrate,
(add, delete, modify), the student accounts by using this function of the administration module.
Long Stretch Software 2006
Page - 36
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
3.2.2.4 The administration module will import student data from Excel and comma
separated files.
The teacher can import student data (game statistics, and user information) from Excel files or
comma separated text files, provided that the files are in the correct format. This satisfies a
request made by the clients during negotiations (see Appendix B - 2.7).
3.2.2.5 The administration module will provide help for each function of the module.
The system will provide support for teachers with varying amounts of computer skills; by
supplying a help module for everything they are able to do using the administration module.
3.2.2.6 The administration module will authenticate the teacher or the administrator before
they can use the module.
Before the teacher or administrator can use the module, they have to log in using a pair of
username and password. The module must check the authenticity of the username and password.
3.2.3 Usability requirements
3.2.3.1 Familiar user interface provided for teachers
The interface for queries will be similar to a web-browser, with regards to navigation and file
access. Navigation will use clickable text similar to links as well as forward and back buttons.
Responses to system queries should be able to be exported to Office (i.e. Excel) formatted
documents or comma separated text files (requirement 3.2.2.2), providing a familiar interface for
data manipulation (see section Appendix B - 2.5).
3.2.4 Reliability requirements
3.2.4.1 Expected uptime will be 95%
The admin module will be able to run for at least three consecutive hours, 95% of the time. This
should be reliable enough for the teacher interaction with the system.
3.2.5 Performance requirements
3.2.5.1 The administration module will occupy at most 80MB of hard drive space.
See the rationale in the next requirement.
3.2.5.2 The administration module will run smoothly on a system having a 200 MHz
processor and 64MB of ram, or better specifications.
The RFP did not specify the hardware requirement for the Administration module. However, we
will use the same hardware requirements used for the game, since it should be able to be run on
the same hardware. See section 3.1.5.2 and 3.1.5.3 for the game module requirement.
3.3 Database backend
3.3.1 Database Use Cases
3.3.1.1 We used a similar technique to determine the functional requirements for the
database backend: create the user cases and carefully study them. The following are the
Long Stretch Software 2006
Page - 37
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
use cases for the database backend:
Use Case 8: Store data in database
Actors: The game module, the database module
Purpose: Send information to the database so the student’s progress is stored.
Overview: This use case is invoked by the game module. The game will send results of an
interaction with a student to the database module. The database module will store these results.
Primary Scenario 1.1
Actor Action
System Response
1. Game module sends results to database.
Possible Alternative: See 1.1-2
2. Database stores results.
Alternative Scenario 1.1-2: Error occurs, results not stored.
2.(a) Database sends error message to
game module.
2.(b) Game module retries sending results.
Return to step 2 in primary scenario.
Use Case 8: Retrieve data from database
Actors: The Administration module, the database module
Purpose: Retrieve information from the database so a student’s progress can be viewed.
Overview: This use case is invoked by the admin module. The administration module will
retrieve information from the database module. The administration module will display this
information.
Primary Scenario 1.2
Actor Action
1. Administration module
information from database.
System Response
requests
Possible Alternative: See 1.2-2
2. Database sends information
administration module.
Possible Alternative: See 1.2-2(b)
3. Administration
information.
module
receives
Alternative Scenario 1.1-2: Error occurs, results not stored.
Long Stretch Software 2006
Page - 38
to
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
2.(a) Database sends error message to
administration module.
2.(b) Administration
information request.
module
retries
Return to step 2 in primary scenario.
3.3.2 Functional Requirements
3.3.2.1 The database will collect the game progress of each student.
During the time the student is playing the game, if the student data changes, for example if the
student answers a question correctly, the game module will send the changes to the database
module. The database module should be able to update the data and keep track of the changes.
See section 3.1.2.3 for more information on this requirement from the game module.
3.3.2.2 The database will authenticate the student every time he/she starts a session on
the game module.
Each time a student starts a game, he/she will need to authenticate himself/herself. The database
should store authentication information and be able to authenticate the users. See section 3.1.2.3.
3.3.2.3 The database will be able to authenticate the teacher from the Administration
module.
Similar to the game module, the Administration module will also require the teacher to
authenticate each time they log into the module. The database should store authentication
information and be able to authenticate the users. See section 3.2.2.6.
3.3.2.4 The database will answer data query from the Administration module.
The Administration module will query the database for game statistics. The database should be
able to answer those queries. See section 3.2.2.1.
3.3.2.5 The database will maintain information for a minimum of one year.
The clients requested (see Appendix B - 2.6), that information in the database be retained for one
year for access through the Administration module.
3.3.3 Reliability requirements
3.3.3.1 Expected system uptime will be 95%.
The back-end database should be able to support up to 100 connections of the game clients, 95%
of the time.
3.3.3.2 The system will not be erroneous due to unexpected input.
The database will be able to handle all sorts of input and be immune to side effects cause by
undesirable inputs (such as buffer overflow), which could potentially create security holes in the
system.
3.3.3.3 The system will maintain network security.
The software will employ appropriate network security protocols to ensure that it doesn’t create
network security problems. As per the negotiations (see Appendix B - 2.8), security is not a high
Long Stretch Software 2006
Page - 39
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
priority so only the minimal security requirements will be met for the system. This includes
firewalls and encryption for sensitive information.
3.3.4 Performance requirements
3.3.4.1 The database will be able to support up to 10000 concurrent connections from the
game modules and up to 100 concurrent connections from the Administration modules.
3.3.5 Interfaces requirements
3.3.5.1 The Administrator will be able to interface with the database module.
Apart from being able to communicate with the game module and the Administration module,
the database must have its own interface so the Administrator and manipulate data and perform
backup operations directly.
3.4 Common requirements
3.4.1 Usability requirements
3.4.1.1 Long Stretch Software will work with SME’s to ensure that the system will be usable
by all parties
We will collaborate with teachers, child psychologists and other educators, as well as children to
ensure that the system will be useable for people of all experience levels.
3.4.2 Design constraints
Analyzing the first requirement elicitation log and the RFP 1.0, LSS will assume the following
design constraints.
3.4.2.1 Software development language
LSS will use different software languages during the prototyping, design and testing phases such
as Prolog to generate test cases or ML to model some search algorithms. However, the
deliverable software will be written in:
 Client software: Java on JRE 1.5 compatible.
 Administration module: Java on JRE 1.5 compatible.
 Database: Standard SQL.
3.4.2.2 Development tools
Different departments at LSS will use different development tools.
In general, we will use Eclipse IDE for software development
 Our build system is running on a UNIX platform.
 Our tests will perform on Mac OS and Windows environments.
3.4.3 Hardware Interfaces
The gaming software does not require any additional or specialized hardware in order to operate.
Existing hardware such as keyboard and mouse will be the only hardware required for input to
the game.
3.4.4 Software Interfaces
The gaming, Administration and database components of the software will communicate
securely via a local network. All connections will be adequately encrypted, while still meeting
Long Stretch Software 2006
Page - 40
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
the performance requirements.
3.4.5 Licensing Requirements
At this point, LSS believes that there is nothing to license. However, our sound engineer will
work with your BA to see if there are any special background musicals or sound effects that are
needed.
3.4.6 Legal, Copyright and Other Notices
Upon the release of the software, an EULA must be developed by UCSE to specify legal
agreement between the user and UCSE. LSSD will not be a liable party in this EULA or in any
legal document regarding the use of the software. LSS will only by liable as a contractor to
develop the software and will fulfill its legal requirements.
All software components that are part of the LSSD existing software repository, and are used in
the game will remain as LSSD’s intellectual property (IP). LSS reserves all rights concerning the
use, distribution, and disclosure of such work. Works developed exclusively for this software
will become UCSE’s IP.
4. Game Architecture
As mentioned in section 2, there are three main components in this game system:
 The Game Module
 The Database Module
 The Administration Module
Depending on the designer constraints, the designer team will create different sub-components
for these modules. The overall architect, however, should abide by the description given in this
section.
4.1 Game module (see section 3.1)
4.1.1 Functions
The game module interacts with the user and provides the user a game play experience as
specified in the RFP and in section 3.1. It contains exploration maps, levels, puzzles and
challenges and other game elements (see section 2.2) which provide the game play experience to
the student. As part of the game play experience, it also allows the user to accessorize and select
and edit the character (see appendix C - 3.1 for example interface).
The game module will also authenticate the user. In order to accomplish this, it must retrieve the
user authentication data from the database module and validate it.
The game module will also keep track of user score and progress. It stores and retrieves this
information in the database (database module).
4.1.2 Architecture
The following figure shows a proposed architecture for the game module in a form of a class
diagram following by a brief description of the functionality of each class:
Long Stretch Software 2006
Page - 41
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
4.1.2.1 Graphics
This class is the interface to the student. It does all of the graphic rendering and handle all of the
input/output of the game.
4.1.2.2 Sound
This class will handle all of the sound and music of the game.
4.1.2.3 Game
This class is the main class in the business layer of the game module. It will contain all of the
other classes in the business layer such as Student class, Map class. It will handle all of the
interaction between the other classes to keep the game logic right through out the game
experience.
4.1.2.4 Student
This class represents the user of the game module (the student). It contains the entire traceable
attribute of the student such as the state of the character, the score, and the progress. It will
interface with the database module to save the changes.
4.1.2.5 Map
This class represents the maps of the game. For more information about the map, please see the
section about the game concepts in Section 2.
Long Stretch Software 2006
Page - 42
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
4.1.2.6 Scene
This class represents the scenes of the game. For more information about the scenes, please see
the section about the game concepts in Section 2.
4.1.2.7 Question
This class represents the questions in the game. For more information about questions, please see
the section about the game concepts in Section 2. Instance of this class will have a question and
the appropriate answers.
4.1.2.8 Puzzle
Puzzle is an another type of challenge in the game. For more information about the puzzle,
please see the section about the game concept in Section 2.
4.2 Database module (see section 3.3)
The database module stores score and progress data for the users. It provides access to this data
to the game module and the administration module.
The database module also stores users’ general information and authentication information as
entered by the teacher or administrator. It provides access to this data to the game module and
the administration module.
4.3 Administration module (see section 3.2)
The administration module authenticates the administrator. It retrieves the Administration
authentication data from the database module and validates it in order to accomplish this.
The administration module allows the administrator to add/edit/remove users from the database
(See section 4.2 Database Module).
The administration module generates scores and progress reports by retrieving data from the
database. It can also export these reports to other formats.
The administration module can import reports and can then extract and validate the data from the
reports and store it into the database.
Long Stretch Software 2006
Page - 43
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Appendix A - Change Logs
A - 1 Requirements Added Since RS 2. 0
This section lists all requirements that are new to this version of the RS, and the rationale for
their addition.
Requirement
Number
3.1.2.1
3.1.2.1.1
3.1.2.1.2
Rationale for Addition
Source
The game will require the student to
correctly complete puzzles, in order
to advance to the next section of the
game.
The game will require the student to
correctly complete puzzles, in order
to advance to the next section of the
game.
If a student answers a challenge
incorrectly, the game will provide a
hint and if applicable, simplify the
challenge.
This requirement was the
result of splitting up
requirement 3.1.2.3 in RS 2.0.
Section 2.0
of the RFP
02/04/06
This requirement was the
result of splitting up
requirement 3.1.2.3 in RS 2.0.
Section 2.0
of the RFP
02/04/06
The client does not want
students to be punished for
incorrect answers to
challenges, so challenges will
be simplified if a student is
unable to answer correctly.
This will also help the student
to grasp new concepts by
example.
The clients requested that the
game track student progress.
This requirement details the
data which will be tracked for
answers to challenges.
Inspection of
RS 2.0. See
appendix B 4.8
02/04/06
See RFP
section 2,
and
elicitation
results
(Appendix B
- 1.10)
See RFP
section 2,
and
elicitation
results
(Appendix B
- 1.10)
Prototype
demo.
02/04/06
3.1.2.1.3
When student completes a
challenge, the game module will
record in the database the number of
attempts required for the student to
complete the challenge and the final
simplified version of the challenge.
3.1.2.1.4
The game module will record in the
database the total number of times a
student “gives up” on a puzzle (see
use case scenario 5.1-3, and
Appendix C - 2) before completing
it, and a description of the skills
tested by the puzzle.
If a student cannot complete a
puzzle, and chooses to “give up”,
the game will direct the student back
into the beginning of the current
section, and provide relevant
challenges (see 3.1.2.1.1 and Use
Case 5) to help.
When a student completes the final
puzzle in a section, the game will
3.1.2.1.5
3.1.2.1.6
Date
Requirement
The clients requested that the
game track student progress.
This requirement details the
data which will be tracked for
answers to puzzles.
This addresses a concern that
the clients raised during the
prototype demo, which was
“[sic.] What happens if a
student cannot solve a
puzzle?”
The clients have requested
progress tracking and
Long Stretch Software 2006
Appendix A - 44
(dd/mm/yyyy)
03/04/06
03/04/06
03/04/06
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Requirement
Number
Version:
3.0
Date: 04/07/06
Requirement
Rationale for Addition
unlock another portion (defined
below) of the level and display it on
the level map.
difficulty levels. This
requirement formalizes how
the game module will
accomplish this between
sections.
The clients have requested
progress tracking and
difficulty levels. This
requirement formalizes how
the game module will
accomplish this between
levels.
This super-requirement was
added to explicitly address
the functions of the game that
would make it interesting and
engaging.
This requirement was added
to provide more detail about
how the game will entertain
& engage the attention of the
students
This requirement provides
more detail about the game
music and sounds (see above)
3.1.2.1.7
When a student completes the final
puzzle in a level, the game will
unlock another portion (defined
below) of the world and display it
on the world map.
3.1.2.5
The game will entertain and engage
the attention of the students.
3.1.2.5.1
The system will provide game music
and sounds
3.1.2.5.1.1
The system will allow game music
and sounds to be turned on and off
3.1.2.5.1.2
The system will play different music
for each level.
This requirement provides
more detail about the game
music and sounds (see above)
3.1.2.5.2
The game will allow the user to
adjust the properties of his/her
character.
3.1.2.5.2.1
The user can buy and sell items for
his/her character.
3.1.2.5.2.2
The user is allowed to change
his/her character’s gender.
3.1.2.5.2.3
The user can change the appearance
of their character
3.1.2.5.3
The game module will provide in
game animations.
This formally explains how
the system will address the
client request that the game
be entertaining and engaging.
To enhance entertainment and
engagement of the user as
requested by the clients
This was added to explain
how the system will appeal to
all members of the target
audience.
Again, this was added to
address how the system will
engage the users.
Again, this was added to
address how the system will
engage the users.
Long Stretch Software 2006
Source
Date
(dd/mm/yyyy)
See RFP
section 2.0
and
elicitation
result in
Appendix B
- 1.3
See RFP
section 2.0
03/04/06
See RFP
section 2
requirement
2
04/04/06
See RFP
section 2
requirement
2
See RFP
section 2
requirement
2
RFP section
2.0
04/04/06
RFP section
2.0
04/04/06
RFP
04/04/06
RFP section
2.0
04/04/06
RFP section
2.0
05/05/06
Appendix A - 45
04/04/06
04/04/06
04/04/06
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Requirement
Number
3.1.2.5.3.1
Rationale for Addition
Source
The game will provide character
animations.
Again, this was added to
address how the system will
engage the users.
Again, this was added to
address how the system will
engage the users.
The formal definition fo the
reward system indicates how
the system will keep the users
motivated and entertained.
This requirement from RS 1.0
still needed clarification. The
clients requested more
clarification in RS 1.1, but it
was not fully addressed in RS
2.0.
The clients requested
clarification of the help which
would be provided for the
students while playing the
game.
The clients requested
clarification of the help
documentation. They wanted
documentation for teachers
RFP section
2.0
05/05/06
RFP section
2.0
05/05/06
RFP section
2.0
05/05/06
B - 3.5
05/04/06
Inspection of
RS 2.0 – see
appendix B 4.2
05/04/06
RS 2.0 – See
appendix B 4.3
05/04/06
The clients requested
clarification of the help
documentation. They wanted
documentation for parents
RS 2.0 – See
appendix B 4.3
05/04/06
The clients requested that the
game be playable both at
school and at home, but
requested clarification on
how this would be achieved
since the database would not
be available at home.
See RS 2.1
feedback in
appendix
section B 4.10
06/04/06
The game will provide reward
animations
3.1.2.5.4
The game will provide a monetary
credit system
3.1.2.2.1
The system will test basic computer
skills as part of a starting tutorial.
3.1.2.2.2
The system will show on-screen
help balloons after hovering the
mouse pointer over an object for 2
seconds.
3.1.8.2
The system will provide an
instruction guide in both electronic
and paper formats for teachers.
Error! Reference source not
found.
The system will include an
instruction guide in both paper and
electronic versions for
parents.Error! Reference source
not found.
The game installation will
vary(defined below) depending on
whether it is a school installation or
home installation:
3.1.2.6
Date
Requirement
3.1.2.5.3.2
3.1.8.3
Version:
3.0
Date: 04/07/06
(dd/mm/yyyy)
A - 2 Changed Requirements from RS 2.0
This section lists all requirements that have been changed from RS 2.0, and the rationale for the
change.
Requirement’s
Number in:
RS 2.0 RS 3.0
Date:
Description of Change
Rationale for Change
Long Stretch Software 2006
Source
Appendix A - 46
(dd/mm/yy
yy)
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
3.1.2.3
3.1.2.1
.1
This requirement was removed
and split up into multiple sub
requirements
The requirement as stated in
RS2.0 was ambiguous and
was made up of 2 more
specific requirements.
As suggest by
the consultant
Irwin Kwan.
(marking of
RS 2.0)
RS 2.0
comments.
Appendix B234
RS 2.0
comments.
Appendix B234
01/04/06
Use
Case 4
Use
case 4
Clients requested text-based
questions in comments.
Use
Case 4
Use
Case 4
3.1.2.2
3.1.2.2
The use case was updated so that
the system presents multiplechoice or text entry type
question.
The use case was updated so that
if the student enters an incorrect
response, the system will
provide a hint and simplify the
problem.
This requirement was split into
several sub-requirements
As suggest by
the consultant
Irwin Kwan
RS 2.1
04/04/06
2.1.3
2.1.3
Usecas
e6
Usecas
e7
3.1.5.5
Usecas
e6
Usecas
e7
3.1.5.5
3.1.7.2
3.1.7.2
Address RS 2.1 feedback from
the clients
Address RS 2.1 feedback from
the clients
Address RS 2.1 feedback from
the clients
Address RS 2.1 feedback from
the clients
Address RS 2.1 feedback from
the clients
3.1.7.2
3.1.7.2
3.1.6.2
3.1.6.2
Changed color and resolution
requirement
Changed required student
information
Clarified what information can
be imported or exported
Increase uptime requirement
from %95 to 97%
Removed taking away money
from player for answering
wrong question.
Removed redundant information
which has already been stated in
Section 2.2 Game Concepts.
The requirement was clarified to
show exactly who would be
doing the upgrades.
RS 2.1
06/04/06
RS 2.1
06/04/06
RS 2.1
06/04/06
RS 2.1
06/04/06
Removed because of
redundancy
RS 3.0
06/04/06
Changed for clarity.
As suggest by
the consultant
Irwin Kwan
06/04/06
Clients don’t want students to
be punished for incorrect
answer. The hint and
simplification aids in the
learning process.
Increased the degree of detail
of the requirement for RS 3.0.
02/04/06
02/04/06
06/04/06
A - 3 Document Changes from RS 2.0
This section details the changes that have been made to the overall document since version 1.0.
These changes will include all those that do not relate to individual requirements (listed in the 2
sections previous), but rather the ordering of sections, formatting, added components and other
such changes.
Introduced
in Version
2.2
Section
Changed
Appendix
A
Description
Rationale for Change
Added new change logs
for the changes from RS
2.0 to 3.0. The old logs
are included in the
following sections (in
grey text) for further
reference.
New logs were added to clearly show the
changes from RS 2.0 to 3.0.
Long Stretch Software 2006
Appendix A - 47
Date
(dd/mm/yyyy)
02/04/06
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
2.2
Appendix
C
2.2
Appendix
C
2.3
1.4
2.3
Section 4
2.3
Section 3.2
2.3
1.3
2.4
3.0, 3.2
2.4
2.1
Added section ‘C - 1
Sample Challenges’ and
removed the former
‘Example Problem.’ Two
new example challenges
were added – one for
English, one for math.
Added section ‘C - 2
Sample Puzzle’ and
removed the former
‘Example Puzzle.’ The
example puzzle has also
been updated, and a
description added.
Added glossary to
document.
Removed the general
architect diagram. Add
class diagram for the
game module
Added test scenarios to
all functional
requirements of the game
module (section 3.2).
Alphabetized the
acronym list.
Added description of
which module would be
detailed and why.
Added reference to the
architecture section of the
document so the reader
can familiarize
themselves with it if they
need to.
Version:
3.0
Date: 04/07/06
Challenges are referenced frequently
throughout the document, so detailed
examples are being provided for clarity.
02/04/06
Puzzles are referenced frequently
throughout the document, so a detailed
example is being provided for clarity.
02/04/06
Referencing common concepts to the
glossary makes the document easier to
understand.
As suggest by the consultant Irwin Kwan
02/04/06
Improves formality of the requirements.
04/04/06
As suggest by the consultant Irwin Kwan
06/04/06
Improves readability and understanding
of document.
06/04/06
As suggest by the consultant Irwin Kwan
06/04/06
03/04/06
A - 4 Requirements Added Since RS 1. 0
This section lists all requirements that are new to this version of the RS, and the rationale for
their addition.
Requirement
Number
3.1.7.1
Requirement
Rationale for Addition
The completed game will have an
ESRB rating of ‘E’.
3.1.7.3
All game content will be interesting for
boys and girls.
During the requirements negotiation session, the
clients requested an ESRB rating of ‘E’ (see
Appendix B - 2.3)
During the negotiation session, the clients requested
that all content be ‘asexual’ so both boys and girls
would find it interesting.
Long Stretch Software 2006
Appendix A - 48
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
3.3.2.5
The database will maintain information
for a minimum of one year.
3.1.5.1
The game will offer two installation
modes – full and partial install.
3.1.7.2
In order to be entertaining, the game
will engage the student in a story line
3.2.2.1
The administration module will
generate reports of student progress.
The administration module will export
report data (3.2.2.1) to Excel
documents and comma separated text
documents.
3.2.2.2
3.2.2.5
3.2.5.1
3.2.5.2
3.2.2.3
3.2.2.4
3.3.2.1
3.3.2.2
3.3.2.3
3.3.2.4
The administration module will
provide help for each function of the
module.
The administration module will occupy
at most 80MB of hard drive space.
The administration module will run
smoothly on a system having a 200
MHz processor and 64MB of ram, or
better specifications.
The administration module will
administrate the student accounts.
The administration module will import
student data from Excel and comma
separated files.
The database will collect the game
progress of each student.
The database will authenticate the
student every time he/she starts a
session on the game module.
The database will be able to
authenticate the teacher from the
Administration module.
The database will answer data query
from the Administration module.
Version:
3.0
Date: 04/07/06
This requirement was added to satisfy the client’s
request that the system maintain data for one year.
This request was made during the Negotiation
session (see Appendix B - 2.6)
This addition satisfies the client request from RS1.1
(see Appendix B - 3.8) that a full install option be
available for computer systems that have enough
hard drive space.
In section 2.0 of the RFP, an objective is to
“Entertain and engage the attention of the students.”
This requirement was added to satisfy this and the
client request that information on storyline be
included in RS 2.0 (see Appendix B - 2.14)
This functionality was requested by the UCSE in
section 4.0 of the Client RFP.
Office format exports were requested in RFP
section 5.0, but were not full addressed in RS 1.0.
The request for comma separated exports was
introduced during negotiations (see Appendix B 2.7)
This addresses the concern that not all teachers will
have the same computer experience, and may need
assistance. This is outlined in section 2.3.
This addresses the size constraint given in RFP
section 6.0
This requirement was added to address the
minimum system requirements that were agreed
upon during negotiations (see Appendix B - 2.12)
The game must track individual student progress
(RFP section 4.0, elicitation Appendix B - 1.4), so
each student must have their own account. Thus, a
method is needed to add/create/delete these
accounts, which will be provided by the
administration module.
During the requirements negotiation session, the
clients asked for import functionality (see Appendix
B - 2.5).
This supports the requirement 3.1.4.1 as well as the
client comment in Appendix B - 1.12.
This supports requirement 3.2.2.6.
This supports requirement 3.2.2.1.
Long Stretch Software 2006
Appendix A - 49
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
A - 5 Changed Requirements from RS 1.0
This section lists all requirements that have been changed from RS 1.0, and the rationale for the
change.
Requirement’s Number in:
RS 1.0
RS 2.0
3.1.3
3.1.5.4
Description of Change
Rationale for Change
The requirement “Maximum time from
launching the game until it is playable will be 5
minutes.” from RS 1.0 has been altered to
included an average load time of 2 minutes
over all system.
This addresses the client’s
concerns that 5 minutes is too
long to wait. This issue was
discussed during the
Requirements Negotiations
(see Appendix B - 2.11)
This corrects an error from
version 1.0 where this
requirement was incorrectly
listed as non-functional.
“Degradation Modes” is not a
proper requirement statement
(ambiguous etc), so it was
corrected.
During negotiations on March
7, 2006, UCSE agreed to
increase the minimum system
requirements. (See B - 2.12)
3.1.2
3.1.2.1.1
The requirement “The system will provide ingame tutorials and help” was changed from
listed as non-functional to functional.
3.3.1
3.1.4.1
3.3.2
3.1.5.2
3.1.5.3
This requirement “Degradation Modes” has
been changed to “Student progress
automatically saved to database when goals are
completed.”
Changed minimum system requirements for
computers from 60MHz and 16MB of RAM to
200Mhz and 64 MB of RAM. The requirement
“Resource Utilization” from RS 1.0 has been
split into the requirements:
The game will occupy at most 80MB of hard
disk space for the partial install.
The game will run smoothly on a computer
with minimum system requirements of a 200
MHz processor, 64MB of RAM and 2x CDROM drive or greater
3.1.8.1
3.1.3.2
Changed user interface requirement to “simple
enough for grade 1 and 2 students.”
3.2.6
None
3.5.2
None
The requirement “System will detect and
correct errors in imports and exports from
Office file formats” was removed.
The “Development Tools” section from 1.0
was removed.
The requirement statement
“Resource Utilization” was not
a proper requirement statement
(ambiguous, etc.), and the
details held requirement
information, so they were split
up into two new requirements.
Original user interface
requirements were bloated and
not traceable.
This requirement was removed
because it is an unrealistic and
un-requested feature.
This information is not of
importance to the Client.
A - 6 Document Changes from RS 1.0
This section details the changes that have been made to the overall document since version 1.0.
These changes will include all those that do not relate to individual requirements (listed in the 2
sections previous), but rather the ordering of sections, formatting, added components and other
such changes.
Introduced in
Version
Section
Changed
Description
Rationale for Change
Long Stretch Software 2006
Appendix A - 50
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
1.2
Section 3
Re-organized all of section 3 into 4
sub-sections – one for each module
of the system (game, administration
and database) and one for common
elements.
IN each new subsection of Section 3,
the requirements are now organized
into sub sections based on whether
they are functional or non-functional,
instead of being differentiated by (F)
and (NF) in the requirement heading.
This also required a change to the
introduction to Section 3.
UCSE’s RFP was included for
reference in RS 1.0, but has been
removed for version 2.0.
1.2
Section 3 –
sub sections
1.3
Appendix A
UCSE’s RFP
1.0
1.5
Section 3 and
sub-sections
3.x.1
The requirements in each sub-section
of each module (Functional
Requirements for the Game Module)
have been ordered by importance.
1.5.2
Section 1
Introduction has been re-written.
1.5.3
Section 3
Added use cases to each of the
module section in section 3
1.5.3
Section 4
Added overview of the system
architecture.
1.6.5
1.6
1.6.6
Section 3 and
4
The overview was updated to cover
the new format of the document, and
the additional sections.
Add references to the subsections
and reword some of the requirements
Version:
3.0
Date: 04/07/06
When planning the architecture of the
system, the system was divided into three
separate modules. Re-organizing the
requirements to reflect this will help the
readability of the document.
This change improves the readability, and
modifiability of the requirements. It also
makes it easier to rank the requirements
by importance. Finally, it helps the
document to comply with standards.
The addition of the RFP was deemed
redundant, and removed to improve
readability and reduce complexity of the
document.
This satisfies the RS quality characteristic
that requirements be " Ranked by
Importance.“ The chosen ranking is
based on our analysis of the client’s
needs, based on the information we have
been provided, and the chosen
architecture of the system.
The old introduction was a sales pitch for
Long Stretch Software instead of an
introduction to the document.
To make it easier to understand the
requirement and make the RS more
complete.
This is a required feature of RS 2.0 and
will also improve the client’s
understanding of the system.
To help the reader to understand the
design of the document better.
Improve readability of the report.
Long Stretch Software 2006
Appendix A - 51
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Appendix B - Outcomes of Client Communication
B - 1 Requirements Elicitation (January 23, 2006)
B - 1.1 What are we working on? There’s mention of a previous system. What do you want
done with the old system?
There is no old system. The one mentioned is simply an example of what is currently available
for the kids to play with. Basically, we must create an educational game from scratch.
B - 1.2 Is it a single game system or multiple games?
This should only be a single game. In other words it should be a game that incorporates math,
English and problem solving skills. The clients mention that maybe a RPG genre of game could
not only incorporate all of the educational aspects but also be entertaining for the kids.
B - 1.3 How should the different grades be integrated in the game? Are scalability levels
mixed with grade levels?
There would be no differentiating between grade levels since the clients believe that a child
should always be challenged and not limited by grade levels. Therefore we only need lots of
difficulty levels such as very easy, easy, medium, hard, very hard and so on.
B - 1.4 How do you want to keep track of kids (assign computers/log in)?
We are going to keep track of the kids through a game log in. This way we can also save the
kids progress.
B - 1.5 What is meant by expose kids to technology (just mouse, mouse keyboard)?
“Simple” computer tasks should be able to perform by the kids. The tasks include typing on the
keyboard, mouse clicking and double clicking and possibly other very basic tasks
B - 1.6 80MB???? Flexible?
This is somewhat flexible but the quality of graphics should be sacrificed instead of the size
limit.
B - 1.7 What is problem Solving (puzzle, spatial ability, riddles)?
Problems solving should include the puzzle and riddles and some spatial ability. Spatial ability
should be very simple such as seeing shapes and putting them in the appropriate slots.
B - 1.8 What’s the math level (addition, multiplication)?
Basic addition with no numbers greater than 2 digits. While multiplication should be limited to a
5 by 5 table.
B - 1.9 What are we doing for English (definition, sentence identification)?
There’s should be no definition and only sentence identification.
B - 1.10 How is a kid evaluated?
A kid is evaluated by the number of question he has right. On the spread sheet there should be
the 3 categories with the number he has right and also the question he had wrong with the answer
the kid inputted such that the teacher may help the kid to improve.
Long Stretch Software 2006
Appendix B - 52
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
B - 1.11 How is a teacher to export data? Special format?
The teacher needs a simple way to export data. A text file with the results separated by tabs
should be sufficient. This way allows the teacher to put the results in a spreadsheet easily (we
can assume the teacher uses excel).
B - 1.12 Do the teachers need to track progress at home?
No, the kids can play the game at home but there’s no need for the teacher to track his progress.
B - 1.13 Who has access to progress report of kid?
Just the teacher as the report should be saved on the school server so that the teacher can easily
access the data from his/her personal computer.
B - 1.14 If this is a co ordinate effort with teachers, parents etc… Are you providing them,
providing feedback from them, should we find them?
On the client team there are some representatives which we may ask questions to clarify any
matters that might show up.
B - 1.15 What networking is required?
This is a single player game which is networked at school for the teacher to access the progress
report.
B - 1.16 Entertainment Factor?
Want to keep the kids amused for the duration of their “lab classes” which is approximately an
hour.
B - 2 Requirements Negotiations (March 7, 2006)
B - 2.1 We are choosing to go into detail with the Game module for RS 3.0. Is this ok?
‘detailed game module = yes’
B - 2.2 Can you give an approximate minimum # of game play hours required for each
grade level? [Or can you supply the approximate number of hours students will play each
week?]
‘1-10 hours / week play time’
B - 2.3 What is this game rated?
‘rating: e for everyone’
B - 2.4 As educators, do you think content should be different for boys/girls? Should we
just shoot for something in the middle?
‘asexual game content, boy/girl characters’
B - 2.5 From client comment “can they import old information “
‘importing stays’
Long Stretch Software 2006
Appendix B - 53
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
B - 2.6 Online backup will be provided by the system. How critical is this information? How
far back the backup should go? Maybe one academic year?
‘information available back one year, importing/exporting available’
B - 2.7 In addition to Office formats, what export format would you like for student reports?
‘comma separated data’
B - 2.8 The system will maintain network security. Will SSL all the communication be
sufficient for this requirement?
‘security is low priority’
B - 2.9 Data will be portable. Can we just put the data into a standard SQL data base? All
SQL databases engine should be able to access the data.
‘SQL is a go’
B - 2.10 Do you require a website for the game?
‘We would be interested in a website, but would not want to pay extra for it’
B - 2.11 The Maximum time from launching the game until it is playable will be 5 minutes.
Should this be ok?
‘2 min average load, 5 min max’
B - 2.12 Can we up the minimum system requirements for the game?
‘up system requirements to 200 Mhz, 64 MB ram MIN’
B - 2.13 Any suggestions for the name of the game?
"Elementary Quest"
B - 2.14 Do you want to see as "Storyline" section in the next RS?
‘plot/story section in RS 2’
B - 2.15 Any name changes for the game will have to be finalized by RS 3.0, okay?
‘name changes finalized by RS3.0’
B - 3 Client comments on RS 1.0
This section includes USCE’s comments on the RS 1.0 document. The section in which the
comment appears is shown after each heading ‘B – 3.x’ and the text commented on is included in
bold. UCSE’s comments are preceded by a bullet ‘•’ and have this styling.
B - 3.1 : 2.1.2 User Interfaces
The interface for the students will be entertaining and engaging. The function of the buttons
will be easy to understand and simple to use. Menus will be interactive and easily accessible
throughout the game.
• What functions? What buttons? Menus are always interactive
Long Stretch Software 2006
Appendix B - 54
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
B - 3.2 : 2.1.3 Operations
The game will provide the following minimal operations:
Teach Math and English to grade levels 1 & 2 in an entertaining and
engaging manner.
• Problem solving skill as well?
B - 3.3 : 1.4 User Characteristics
…
Because the game is intended for in school use, teachers will be administrating the game, and
must also be considered. Teachers represent a …
• Considered? How?
B - 3.4 : 1.5 Assumptions and Dependencies
We assume the following responsibilities from the client during the game development process:
Provide testing methods and help in developing the test cases with our test engineers.
• We will provide professionals to assist you in developing your test cases but we
will not be providing you with test cases.
Upon the completion of the development process, organize meetings and workshops
with the target user groups to test the software.
• Throughout entire development process.
B - 3.5 : 3.1.1 The system will test basic computer abilities prior to beginning the game,
and provide the necessary tutorials.
• Weird but if kept to a minimum, ok. What will be the extent of tests?
B - 3.6 : 3.2.6 (F) System will detect and correct errors in imports and exports from Office
file formats
• Import from office files? Why?
B - 3.7 : 3.2.7 (NF) Time between failures will be minimized for each operating system that
will run the game (see details)
Windows OS
MTBF in
years
Mac OS
MTBF in
years
Windows
95/98
1
Mac OS 7.6
2
Windows 98
SE
2
Mac OS 8
3
Long Stretch Software 2006
Appendix B - 55
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Windows
XP/2000/ME
4
Version:
3.0
Date: 04/07/06
Mac OS 9
4
Mac OS X
5
• What is the rationale behind this? Where did the numbers come from?
B - 3.8 : 3.3.2 (NF) Resource utilization
The game will occupy at most 80mb of hard drive space. It will also be kept simple enough to
run smoothly on a system having no more then a 60 Mhz processor and 16MB of ram. Some of
the game content will require access to a 2x CD-ROM drive.
• Game should run at same speed independent of system specifications.
• 60 MHz is SLOWEST processor being used.
• What game content? Full install option, where no cd-rom access necessary?
B - 3.9 : 3.1.5 (NF) Software development language
…
However, the deliverable software will be written in:
Client software: Java on JRE 1.5 compatible.
Administration module: Java on JRE 1.5 compatible.
• Java will probably be to slow on a 60 MHz processor. We recommend using C.
B - 3.10 : 3.7.1 (F) User Interfaces
……
The main menu will have three buttons: New Game; Load Game; and, Quit Game.
……
Once a character is selected and continue is pressed, the user will choose his or her difficulty
level and the game will commence.
• No options? Audio, video, control, etc.
• Only on new game. choose grade 1 or 2.
B - 3.11 : 3.7.3 (NF) Software Interfaces
The gaming, administration and database components of the software will communicate securely
via a local network. All connections will be adequately encrypted, while still meeting the
performance requirements (section 3.3)
• Encryption is not necessary. Security is NOT an issue
B - 4 Client Comments on - RS 2.0
This section includes USCE’s comments on the RS 2.0 document. The section in which the
comment appears is shown after each heading ‘B – 4.x’ and the text commented on is included in
Long Stretch Software 2006
Appendix B - 56
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
bold. UCSE’s comments are preceded by a bullet ‘•’ and have this styling.
• Overall the system looks good but there are a few things that need to be addressed.
B - 4.1 : 2.1.3 Hardware Interfaces
The graphical content will be at most 256 colors at a resolution of 640x480.
• This is not necessarily true as we don't want to limit newer hardware to this
resolution and color. It should be possible to adjust the resolution which will allow
for game play at a range of possible resolutions from 640x480 to 1280x1024. That
will provide the ability the game to run on a wide range of hardware.
B - 4.2 : 3.1.2.2 "The system will provide in-game tutorials and help."
• This is a great functionality that will make the teachers’ job much easier as while
a student is waiting for the teacher to come help him/her, he/she can be looking up
the help screen that will further give them hints on how to solve the puzzle or task
they are working on. It will further develop the children's skills to solve problems
by their selves.
B - 4.3 "The purpose of the help document is to provide instructions on how to install the
game and how to play the game."
• The kids won't necessarily have use for a manual on how to install the game or a
help file with instructions as their reading abilities are limited (easier for them to
grasp pictures and animations) and it is unlikely that they will install the game by
themselves even at home. That would be more of a help file for teachers or parents
probably.
B - 4.4 : Use Case 6
Manage student accounts (create/edit/delete)
• This use case only mentions the teacher inputting username/password for the
student, but that wouldn't necessarily be sufficient information. We would like at
least the students name and current grade to be also stored as it will need to appear
on any Results or Progress Reports for the student. Also the username/password
authentication scheme isn't really preferable for 1-2 grade students.
B - 4.5 Use Case 7
Export Student Progress (create/edit/delete)
• This use case doesn't provide sufficient information on what form the progress
Long Stretch Software 2006
Appendix B - 57
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
reports will have. It is clear that they will be some sort of table but there is no
indication whether they will be broken down per skills sections
Math/Writing/Reading etc. or by map, quiz, monster defeated? This is very
important for us as it defeats the purpose of the game if we do not have a very clear
breakdown of the progress of each student in the various subjects.
B - 4.6 "The administration module will import student data from Excel and comma
separated files."
• Will this module also allow for students characters to be exported/imported?
B - 4.7 : 3.1.5.5 Expected uptime will be 95%
The game itself will be able to run for at least 3 consecutive hours, 95% of the time.
• This still seems low to me, does this include idle time, if so not unacceptable. What
if the game gets left on in labs?
B - 4.8 : 3.1.7.2 In order to be entertaining, the game will engage the student in a story
line.
“If the student answers the question correctly then they will be given money so they can buy
accessories for their character. If the question is answered incorrectly, the monster takes away
money from the student “
• I don’t think it is appropriate to take away money, we want to reward progress not
punish based on lack of performance.
B - 4.9 : 3.1.6.3 The game will not require regular maintenance.
• The above doesn't discuss DB maintenance
B - 4.10 : 3.3.2.2 The database will authenticate the student every time they start a session
on the game module.
Each time a student starts a game, he/she will need to authenticate him or herself. The database
should store authentication information and be able to authenticate the users. See section 3.1.2.3.
• Authentication should be very simple, something like a name or initials (or even
choose his unique character from all available ones on the screen). No
username/password fields that will confuse and further complicate the game. That
will be only applicable when the game is connected over the network to the
database, and even in that case the student should have the option of Free-Play
where his/her statistics aren't recorded.
• Students at home cannot access database at school so how will the system handle
Long Stretch Software 2006
Appendix B - 58
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
saving the users’ game data on their personal computers?
B - 4.11 : Use Case 4
“The challenge can be any form of questions. For example, for testing Math skill, the student
should be asked to solve multiple choice Math problems. “
• We prefer a mixture of multiple choice and text answers for all types of questions.
Long Stretch Software 2006
Appendix B - 59
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Appendix C - Prototype Screens
C - 1 Sample Challenges
Two examples follow; one math based, the other English based.
C - 1.1 A sample math challenge:
This prototype screenshot shows a sample math challenge. The player encounters the challenge
by interacting with the bank teller named ‘Josh the Loan Shark.’ As can be seen, instruction is
first provided about how to add, and then a question is posed. If the student answers the question
correctly they are rewarded with the $7 and can continue, if not then they are given a hint and
asked to try again (see example in C - 1.2). Other math challenges in the game will be presented
in a similar manner, just with different content, and in different context (i.e. not always in a bank,
or regarding money).
Long Stretch Software 2006
Appendix C - 60
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
C - 1.2 A sample English challenge:
This prototype screenshot displays a sample English challenge. The player has encountered the
challenge by interacting with the NPC named ‘Mindy’ who has lost her cat and needs help. As
with the math challenge, the player first receives instructions, then is asked a question. If the
student can correctly identify the verbs, then they will advance and try to help Mindy. In this
example, the player was unable to identify the verbs on his first try, so a hint was given, and the
black words have been eliminated as options.
Long Stretch Software 2006
Appendix C - 61
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
C - 2 Sample Puzzle:
In this example puzzle, the player is trying to gain access to ‘The Old Mill’ which will lead to
another section of the current level. In this puzzle, the player clicks two squares to flip them
over. The bottom side of each square shows either a digit or some number of circles; if the
number of circles matches the digit, the squares are removed, if not they flip back over. This
tests the player’s ability to count and recognize digits, as well as developing their spatial
memory.
As can be seen, no instructions are given on the counting/recognition that the player must
accomplish, but they are given a brief explanation of how to complete the puzzle. The levels
will be designed such that they will always provide the necessary knowledge before
encountering the puzzles. If a student can’t complete a puzzle, they will be directed back in the
current section, and will interact with more NPCs who will give the player more help with the
puzzle.
C - 3 Screens for Game Module
The Game Module contains three main types of screens. When the game is started the user has
the option of creating a new character or continuing with an existing character. Once a character
has been chosen or created they will be then presented with the world map where they will
choose their level from those available to them. Once the user has chosen the level he/she
Long Stretch Software 2006
Appendix C - 62
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
wishes to play in, the level will be loaded and he/she can begin playing. The following screen
shots explain these screens in more detail.
C - 3.1 Character Creation/Customization
The user needs to create a character before he/she can play the game for the first time. Once a
character has been created, the user has the option of customizing the individuality of the
character. Characteristics that can be changes include skin color, hair style and color, gender and
clothing/accessories options.
The user may alter the appearance of their character throughout the game. He/she can also
purchase extra items and accessories using money which is earned by answering challenges. In
section “Your Items” the user can view and use the items he/she has purchased.
In this example the user has selected the gender to be male. The user can then select hairstyles,
clothing, accessories, etc. pertaining to a male. The colors the user has selected are displayed in
boxes next to the corresponding characteristic. Also, the user has purchased some sunglasses,
which have been equipped form the “Your Items” section. Once the user is finished modifying
the character they can then return to the menu by clicking on the “Return to Main Menu” button.
C - 3.2 World Map
The world map is a gateway into the different levels that the user can explore. In the example
that follows, the player has only a few levels available, but more will become unlocked as they
Long Stretch Software 2006
Appendix C - 63
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
progress.
In this prototype example, the user is viewing the Map Screen from inside the EasyStreets
(development name) level. The map clearly shows the current location and the available levels.
In this example, the player can access the three towns in green, but not the one in blue (yet).
C - 3.3 Exploration Scene
The exploration scene allows the user to move about the current section of the level he/she is
exploring. The following example illustrates what options the user will encounter.
Long Stretch Software 2006
Appendix C - 64
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
In this prototype example, the user is exploring the EasyStreets (development name) level. The
use can move about the scene by click on the blue arrows. If the user wishes to return to the
map, he/she can click on the map button in the top right hand corner of the screen. Also the use
can access the options menu (see C2342342) using the menu button. The bottom left corner of
the screen shows the amount of money that the user has collected and the level that the user is in.
C - 4 Screens for Administration Module
The Administration module allows teachers to manage student user accounts and view progress
reports of the students. This meets the requirements outlined in section 3.2.2.
C - 4.1 Main Administration Screen
Long Stretch Software 2006
Appendix C - 65
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
In this prototype screen shot, the administrator has the option of doing one of two things at a
time: Managing student accounts and Exporting Student progress data. In the option for “Student
Account Management” the administrator can create, edit or delete a student profile. Student
profiles include user name and passwords for the student. See section 3.2.2.3 for more details. In
the option for “Export Student Progress”, the administrator can view the progress of a single
student or all students, by exporting the data into a readable format such as an Excel file. See
section 3.2.2.4 for more details.
Long Stretch Software 2006
Appendix C - 66
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
Appendix D Traceability Matrices
The figures in this section give an indication of the relationships between the requirements,
rationale statements and test scenarios in this document.
D - 1 Requirements vs. Requirements
This matrix shows the relationships between the functional requirement statements from section
3.1 and the sub-requirements.
Long Stretch Software 2006
Appendix D - 67
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
D - 2 Requirements vs. Rationale
This matrix shows the relationships between the major functional requirements in section 3.1 and
the rationale statements.
Long Stretch Software 2006
Appendix D - 68
UCSE’s Educational Game System
Software Requirements Specification
LSS.Educational.Game.RS-3.0
Version:
3.0
Date: 04/07/06
D - 3 Requirements vs. Test Cases
This figure shows the relationships between the functional requirements in section 3.1 and the
test cases developed for them.
Long Stretch Software 2006
Appendix D - 69