Educational Game System

Software Requirements Specification

Version 1.0
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

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 Aaron
and 3.2.
03/Feb/06 0.12 Incorporated Charles’ and Mindy’s Mindy, Charles,
work Thanh
03/Feb/06 0.13 Worked on sections 3.2, 3.3 and Aaron, Rizwan
3.5
03/Feb/06 0.14 Additions to sections 2, 3 Jeff, Aaron, Thanh,
Rizwan
03/Feb/06 0.15 Reformat, Appendix Thanh, Aaron, Jeff,
Rizwan, Mindy
03/Feb/06 0.16 More reformatting Thanh, Aaron, Jeff,
Rizwan, Mindy
03/Feb/06 0.17 More reformatting and proof Thanh, Aaron, Jeff,
reading Mindy, Rizwan
03/Feb/06 0.18- Group proof reading Mindy, Aaron, Jeff,
0.19 Rizwan, Thanh
03/Feb/06 0.20 Proof reading / Editing Rizwan
03/Feb/06 0.21 Proof reading / Editing Jeff
03/Feb/06 0.22 Proof reading / Editing Aaron

©Long Stretch Software Page 2

2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

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 Page 3

2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

Table of Contents
Executive Summary 3

1. Introduction 6
1.1 Purpose 6
1.2 Scope 6
1.3 Definitions, Acronyms and Abbreviations 6
1.4 References 6
1.5 Overview 6

2. Overall Description 7
2.1 Product Perspective 7
2.1.1 System Interfaces 7
2.1.2 Interfaces 7
2.1.3 Hardware Interfaces 7
2.1.4 Operations 7
2.2 User Characteristics 7
2.3 Constraints 8
2.4 Assumptions and Dependencies 8

3. Specific Requirements 9
3.1 Usability 9
3.1.1 The system will test basic computer abilities prior to beginning the game, and
provide the necessary tutorials. 9
3.1.2 The system will provide in-game tutorials and help 9
3.1.3 Maximum time from launching the game until it is playable will be 5 minutes 9
3.1.4 Familiar user interface provided for Children 9
3.1.5 Familiar user interface provided for Teachers 9
3.1.6 Long Stretch Software will work with SME’s to ensure that the system will be
usable by all parties 10
3.2 Reliability 10
3.2.1 Availability – The software will be able to run 99% of the time when launched.10
3.2.2 Expected system uptime will be 95% 10
3.2.3 Online backup will be provided by the system 10
3.2.4 The system will not be prone to errors caused by unexpected input 10
3.2.5 The system will maintian network security 10
3.2.6 System will detect and correct errors in imports and exports from Office file
formats 10
3.2.7 Time between failures will be minimized for each operating system that will
run the game (see details) 10
3.3 Performance 11
3.3.1 Degradation modes 11
3.3.2 Resource utilization 11
3.4 Supportability 11
3.4.1 The game will run on multiple computer platforms 11
©Long Stretch Software Page 4
2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

3.4.2 Portability 11
3.4.3 The system will be upgradeable. 11
3.4.4 The system will not require regular maintenance 11
3.5 Design Constraints 11
3.5.1 Software development language 11
3.5.2 Development tools 11
3.6 Online User Documentation and Help System Requirements 12
3.7 Interfaces 12
3.7.1 User Interfaces 12
3.7.2 Hardware Interfaces 12
3.7.3 Software Interfaces 12
3.8 Licensing Requirements 13
3.9 Legal, Copyright and Other Notices 13
4. Appendices 14

©Long Stretch Software Page 5

2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

1. Introduction
Long Stretch Software (LSS) provides custom software development services. We can
handle all the developmental aspects of a software project including specification,
architecture & design, implementation, testing, maintenance and training. We work with you
to help us understand your problems and needs, and then we work out the best possible
solution(s) for you. We always involve our clients in each and every aspect of the software
development process by providing prototypes and encouraging feedback. This helps ensure
that our clients are highly satisfied with the end product.
1.1 Purpose
This document is a proposal for requirement specifications 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
LSS = Long Stretch Software Incorporated
RS = Requirements Specifications
RSP = Request for Proposal
TCP/IP = Transport Communication Protocol/ Internet Protocol
FTE = Fulltime Equivalent
SME = Subject Matter Expert
Java = Sun’s Java Language: Provides multi-platform support
JRE = Sun’s Java Runtime Environment
Eclipse = An IBM IDE
IDE = Integrated Development Environment
EULA = End Users Software Agreement
IP = Intellectual Property
UCSE = UVic Center for Scholastic Entertainment
BA = Business Analyst
1.4 References
UVic Center for Scholastic Entertainment (UCSE) Education Game System: Request for
Proposal. Version 1.0.
1.5 Overview
There are two main sections in this document:
• Section 2 will provide an overview of our vision of the game including our
perspectives of the game, assumptions of user characteristics and interactions,
and some design constraints.
• Section 3 will go into detail for each requirement: usability, reliability,
performance, supportability, design constraints, documentation, and interfaces.
©Long Stretch Software Page 6
2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

2. Overall Description
2.1 Product Perspective
There are three main components of the system:
• Client game: where the player plays.
• Admin module: provide admin interface to the teachers, administrators, and
parents.
• Database backend: where all of the data such as player statistics, game states,
etc. are stored.
2.1.1 System Interfaces
The database server and the game client can interact through the LAN.
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. 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.
It will be possible to transfer the students results to a server with any standard networking
hardware.
The graphical content will be at most 256 colors at a resolution of 640x480. 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:
• Teach Math and English to grade levels 1 & 2 in an entertaining and
engaging manner.
• Provide functionality for teachers to track and evaluate student progress.
• Provide user interface and controls for the targeted audience.
• Provide difficulty levels to cater the skill level of the users.
2.2 User Characteristics
This game is targeted directly 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 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
©Long Stretch Software Page 7
2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

interest. They also tend to be very curious, and may inadvertently cause problems as a
result.

Most children probably 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 tend to be more mentally advanced and developed
than boys.

Because the game is intended for in school use, teachers will be administrating the game,
and must also be considered. 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.3 Constraints
The following constraints are specified in the RFP:
• Platform independence is necessary since each school may have a different OS.
• Because a lot of schools are using older systems this game should run on a
system with these requirements:
o Windows 95 and newer: Pentium 60, 16 MB ram, 80 MB HDD space,
Mouse, SVGA video card, 2x, or better, speed CD-ROM, DirectX compatible
sound card.
o 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
• 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, children 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.
2.4 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.
• Provide testing methods and help in developing the test cases with our test
engineers.
• Upon the completion of the development process, 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
deadlines requested in the RFP 1.0:

©Long Stretch Software Page 8

2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

January 26 Meeting to discuss RFP

January 30 RS 1.0
February 6 RS 1.1
February 16 Prototype Demo
March 2 Requirements Negotiations
March 6 RS 2.0
March 10 RS 2.1
April 3 RS 3.0
March 30 – April 6 Final Demo

3. Specific Requirements
In this section, we will specify detailed requirements for the game. Our designers and
programmers will design and build the game based on these requirements. Throughout
section 3, requirements are indicated as functional or non-functional by the symbol (F) or
(NF) respectively in the requirement heading. Our tester will work with client BA to
implement text cases based on the requirements specified here as well.
3.1 Usability
This section addresses the software usability requirements for the students and teachers
laid out in UCSE’s RFP.
3.1.1 (F) The system will test basic computer abilities prior to beginning the game, and
provide the necessary tutorials.
Basic computer abilities include mouse and keyboard input, and understanding computer
displays and feedback (alerts, menus etc). The system will provide a short test to determine
the computer skills that the student is lacking, and will then provide tutorials in required
areas.
3.1.2 (NF) 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 is not be able to help all students all the time.

3.1.3 (F) Maximum time from launching the game until it is playable will be 5 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. This will help to ensure
that children do not lose interest.
3.1.4 (NF) Familiar user interface provided for children.
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.
3.1.5 (NF) 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 links to follow as well as forward and back buttons. Queries will
be made using html-style forms and downloadable files. Responses to system queries will
©Long Stretch Software Page 9
2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

be exported to Microsoft Office (i.e. Word and Excel) formatted documents, providing a
familiar interface for data manipulation.
3.1.6 (NF) 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.2 Reliability

3.2.1 (NF) The software will be able to run 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%.
3.2.2 (NF) Expected system uptime will be 95%
The game itself will be able to run for at least 3 consecutive hours, 95% of the time. The
back-end database should be able to support up to 100 connections of the game clients,
95% of the time.
3.2.3 (NF) Online backup will be provided by the system
The software will employ mechanisms to ensure that there is no data loss if the game
crashes.
3.2.4 (F) The system will not be prone to errors caused by unexpected input
The software 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.2.5 (NF) The system will maintain network security

The software will employ appropriate network security protocols to ensure that it doesn’t
create network security problems.
3.2.6 (F) System will detect and correct errors in imports and exports from Office file
formats
The software will be able to import and export data to and from Office formats with minimal
data corruption. The software should be able to detect and resolve any data corruption
occurrence.
3.2.7 (NF) Time between failures will be minimized for each operating system that will run
the game (see details)
Mean Time Between Failures (MTBF) – MTBF is based on the average time of game
operation without any repairs or reinstallations. MTBF mainly depends on the software to be
run as well as the operating system. The MTBF for target software for various operating
systems are listed below.

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 Page 10
2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

Windows 4 Mac OS 9 4
XP/2000/ME
Mac OS X 5

3.3 Performance

3.3.1 (NF) Degradation modes

In the case of a system failure, students should not be required to repeat material that they
have already mastered. Therefore, the student’s progress will automatically be saved when
goals are completed.
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.

3.4 Supportability

3.4.1 (NF) The game will run on multiple computer platforms.

The game will be supported by a Windows 95 or higher, or a Mac OS 7.6 or higher operating
systems.
3.4.2 (NF) Data will be portable.
The game data files will be platform independent.
3.4.3 (NF) The system will be upgradeable.
The system will be upgradeable after installation. The code will follow the standard coding
convention for the Java programming language and will be easy to read and easy to
upgrade by an external party.
3.4.4 (NF) The system will not require regular maintenance.
Once installed, the game and data system will not need to be maintained at scheduled
intervals.
3.5 Design Constraints
Analyzing the first requirement elicitation log and the RFP 1.0, LSS will assume the following
design constraints.
3.5.1 (NF) 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.
• Admin module: Java on JRE 1.5 compatible.
• Database: Standard SQL.
3.5.2 (NF) Development tools
Different departments at LSS will use different development tools.
• In general, we will use Eclipse IDE for software development
©Long Stretch Software Page 11
2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

• Our build system is running on a Unix platform.

• Our tests will performed on Mac OS and Windows environments.

3.6 Online User Documentation and Help System Requirements

Online documentation will be available for the game upon completion and delivery. The
game will also come with built in help files and tutorials for game play.
3.7 Interfaces

3.7.1 (F) User Interfaces

The first screen is the login screen. It will feature a username and password string entry,
and submit and exit buttons. The user will be notified by a dialogue box in case of an
incorrect entry.

Once the user has signed on, the main menu screen will be presented. The main menu will
have three buttons: New Game; Load Game; and, Quit Game. All buttons in the preceding
and subsequent menus will have a similar style: energetic, entertaining, but also easy to
understand and use. The buttons will provide the following functionality:
• The function of any Quit Game button will be the closing of the game.
• The Load Game button will load the user to the position in the game they were
before their last sign off.
• The New Game button will open the new game menu, where the character is
selected. On this screen, there will be an image of whatever character is selected;
as well as a scrolling method to switch characters, and continue and back buttons
for progression through the menus.
Once a character is selected and continue is pressed, the user will choose his or her
difficulty level and the game will commence.

The game-play screen will have one bar along the bottom. The style of the bar is
dependent on what character was chosen by the user: one style for boys and one for girls.
There will be three basic functions along the bottom bar: character, skills, and map.
• The character function will show the player their character at that point in time.
• The skills section will show the player what their skills are at the three main
educational types: math, English, and problem solving.
• The map function will bring up a map of the game area, showing the player where
they have been before, what areas they have completed the exercises or lessons
in, and what the areas are in any direction from them.

A fourth in-game menu is accessed by pressing the ESC button. In this menu are some
basic game-play options such as text scroll speed and text size, and the Quit Game button
which exits the game, while also saving the current state of the game.
3.7.2 (NF) Hardware Interfaces
The gaming software does not require any additional or specialized hardware in order to
operate. Existing hardware such a keyboard and mouse will be the only hardware required
for input to the game.
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
©Long Stretch Software Page 12
2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

meeting the performance requirements (section 3.3)

3.8 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
need to be included in the game. In such a case, additional licensing might be required.

3.9 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. LSS 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 it legal requirements.

All software components that are part of the LSS existing software repository, and are used
in the game will remain as LSS’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.

©Long Stretch Software Page 13

2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

4. Appendices
UCSE’s_RFP1.0

©Long Stretch Software Page 14

2006
UCSE’s Educational Game System Version: 1.0
Software Requirements Specification Date: 03/02/06
LSS.Educational.Game.RS-1.0

1.0 Problem description / expression of need

There is an ever-present need for alternative teaching tools in the elementary school system. As children
are being exposed to computers at increasingly younger ages, the demand for effective and engaging
educational software will continue to increase. Unfortunately, most currently available educational games
simply cannot compete with most other forms of entertainment available to children today. These
simplistic games often fail to grasp the attention of children when compared to most commercially
available non-educational video games, movies, and television shows.

What is needed is a computer game designed to teach Grade 1 and 2 students basic math, English, and
problem-solving skills that the children will actually enjoy playing – a game so appealing that kids will
actually choose it over more conventional non-educational forms of entertainment.
2.0 Project Objectives
1. Teach grades 1 and 2 math, English and problem solving techniques
2. Expose kids to computer technology
3. Entertain and engage the attention of the students
4. Provide a way for teachers to track and evaluate student progress
5. Scaleable difficulty to fulfil the needs of individual students
6. Available for use at home
7. A user interface and controls that is simple enough for grades 1 and 2 (see constraints
for more details)
3.0 Current System(s)
There are many commercially available educational games such as the Heartsoft Reading & Math SkillSet 1.
It is doubtful that any children would choose to play games like these when faced with alternatives like the
Xbox 360, hundreds of TV channels, and multi-million dollar budget Hollywood blockbusters.
4.0 Intended users and their interaction with the system
Elementary school students in grades 1 and 2 should want to play this game. The students will find
themselves so completely entertained that they will barely notice the educational aspects of the game.

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.

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.

5.0 Known interaction with other systems within or outside the client organization
Teachers and parents will want to export relevant data for creating spreadsheets and graphs of individual
and group performance.
Compatible with office software (MS Office, Open office, etc)
6.0 Known constraints to development
Platform independence is necessary since each school may have a different OS.
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, 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
It will be necessary to test the game with children to insure it is entertaining and easy to use. Page 15
©Long Stretch Software
2006