Educational-Game+RS-3.0

8/15/2019 Educational-Game+RS-3.0

1/69

UCSE’s Educational Game System Version: 3.0

Software Requirements Specification ate: 0!"0#"0$

%SS.Educational.Game.RS&3.0

Educational Game SystemSoftware Requirements Specification

Version 3.0

©%on' Stretc( Software )00$ *a'e & +


2/69




Revision Historyate Version escription ,ut(or

0+"-e"0$ 0.+ Created and di/ided t(e wor 1(an(

0)"-e"0$ 0.++ Created content for sections ).3 and3.).

,aron

03"-e"0$ 0.+) 2ncorporated C(arles’ and indy’swor

indy4 C(arles41(an(

03"-e"0$ 0.+3 5ored on sections 3.)4 3.3 and 3.6 ,aron4 Ri7wan

03"-e"0$ 0.+! ,dditions to sections )4 3 8eff4 ,aron4 1(an(4Ri7wan

03"-e"0$ 0.+6 Reformat4 ,ppendi9 1(an(4 ,aron4 8eff4

Ri7wan4 indy03"-e"0$ 0.+$ ore reformattin' 1(an(4 ,aron4 8eff4

Ri7wan4 indy

03"-e"0$ 0.+# ore reformattin' and proofreadin'

1(an(4 ,aron4 8eff4indy4 Ri7wan

03"-e"0$ 0.+&0.+; Group proof readin' indy4 ,aron4 8eff4Ri7wan4 1(an(

03"-e"0$ 0.)0 *roof readin' " Editin' Ri7wan

03"-e"0$ 0.)+ *roof readin' " Editin' 8eff

03"-e"0$ +.0 *roof readin' " Editin' ,aron

0"-e"0$ +.+ -eed ac from UCSE UCSE

0;"-e"0$ +.+.+ Correction and answer feed ac 5(ole Group

0#"ar"0$ +.) Re construct t(e requirements intot(ree modules

1(an(

0"ar"0$ +.3 odified appendi9 section andadded c(an'e lo' and ne'otiationoutcomes Some editin' of section 3

,aron

0"ar"0$ +.! ,dded functional requirements 1(an(

0;"ar"0$ +.6

Editin'

,aron ?aspar

0;"ar"0$ +.6.+ Edits to document4 C(ecin' for indy

©%on' Stretc( Software )00$ *a'e & )


3/69




requirements correctness

0;"ar"0$ +.6.) ,dded requirements to satisfy @e'otiation outcomes

,aron

0;"ar"0$ +.$ ,dded use cases and arc(itecture 1(an(4 8eff4 Ri7wan4indy4 C(arles4 Scott

0;"ar"0$ +.$.+ ,dded and c(an'ed morerequirements

,aron

+0"ar"0$ +.$.) -ormattin' in ,ppendices.Comments and edits to document

,aron

+0"ar"0$ +.$.3 C(ecin' for ami'uity. Commentsand edits to document.

indy

+0"ar"0$ +.$.! Edit user interface requirements. Scott

+0"ar"0$ +.$.6 Updatin' A addin' requirements ,aron4 indy

+0"ar"0$ +.$. ,dded appendi9 section B 3Client comments on RS +.0. ,dded prototype ima'es.

,aron

++"ar"0$ +.$.; *roofread4 and edited t(e documentfor spellin' and 'rammar mistaesand internal conflicts andami'uities. ,dded references tot(e addressed elicitation questions

and answers. ,dded references tot(e fi'ures in ,ppendi9 C.

Ri7wan4 indy4,aron4 Scott.

++"ar"0$ +.# *roofread a'ain for spellin'4'rammar4 inconsistencies and deadreferences.

Ri7wan

++"ar"0$ +.#.+ Updated and fi9ed c(an'e lo'4 1


4/69




0)",pr"0$ ).3.+ ,dded"modified requirementsrelated to pu77les"prolems. ,dded'lossary4 updated 'ame use&cases.

,aron

03",pr"0$ ).3.) ,dded"modified functionalrequirements of t(e 'ame modules

1(an(4 Scott4 8os(48eff

0!",pr"0$ ).3.3 *erformed partial proofreadin' Ri7wan

0!",pr"0$ ).3.! -inis(ed proofreadin' all t(e newlyadded content.

Ri7wan

0!",pr"0$ Entiredocument

,dded t(e final /ersion of RS 3.0into Req*ro4 created traceailitymatrices

indy

0$",pr"0$ ).! ,ddressed outstandin' issues from

RS ).+. Editin'.

Ri7wan4 1(an(4

Scott4 8eff 0$",pr"0$ ).!.+ ,dded outstandin' c(an'es to lo's.

Edited and updated requirements.C(an'ed some requirements from-R to @-R4 and updated matrices.Editin'.

,aron

0$",pr"0$ ).!.) ,dded more outstandin' c(an'es tolo's. Cleared up issues frominspection. editin'

8eff

0$",pr"0$ 3.0 -inal touc(es and editin'. ,aron

©%on' Stretc( Software )00$ *a'e & !


5/69




Executive Summary

1(is document is t(e Requirements Specification document for t(e UVic Center for Sc(olasticEntertainment =UCSE> Educational Game *roFect. 2t pro/ides detailed descriptions of t(e

software4 user4 and (ardware interfaces of t(e system4 and includes a detailed description of t(euser interface for t(e system.UCSE (as c(osen %on' Stretc( Software e/elopers 2nc to desi'n and implement an educational'ame desi'ned to (elp students in 'rades + ) wit( at(4 En'lis( and *rolem&Sol/in' sills.1(e intention of t(e 'ame is to allow t(e users to practice t(eir mat(ematical and En'lis( sillsin a fun and entertainin' manner. 2t will also e a tool for teac(ers to e/aluate t(e students.1eac(ers of t(e 'rades + and ) students will use t(e 'ame to trac de/elopment in indi/idualstudents and as a possile marin' 'uide. 1eac(ers will also e9port rele/ant data for creatin'spreads(eets and 'rap(s of indi/idual and 'roup performance. 1(e 'ame will e also e a/ailalefor (ome use so t(at parents of t(e students are ale to see t(e pro'ress of t(eir c(ild=ren>.1(e oFecti/e of t(e Software Requirements Specification is to pro/ide a summation of t(e

findin's t(us far in t(e de/elopment sta'e of t(e proFect. 2t will e treated as a worin'document and pro/ides a detailed outline of t(e system from t(e clientHs perspecti/e.

©%on' Stretc( Software )00$ *a'e & 6


6/69




Table of ontents

E9ecuti/e Summary

+. 2ntroduction

+.+ *urpose+.) Scope+.3 efinitions4 ,cronyms and ,re/iations+.! Glossary+.6 References+.$


7/69




3.).6 *erformance requirements 3#3.3 ataase acend

3.3.+ ataase Use Cases 3#3.3.) -unctional Requirements 3;

3.3.3 Reliaility requirements 3;3.3.! *erformance requirements !03.3.6 2nterfaces requirements !0

3.! Common requirements3.!.+ Usaility requirements !03.!.) esi'n constraints !03.!.3 Iardware 2nterfaces !03.!.! Software 2nterfaces !03.!.6 %icensin' Requirements !+3.!.$ %e'al4 Copyri'(t and

!.+.+ -unctions !+!.+.) ,rc(itecture !+

!.) ataase module =see section 3.3>!.3 ,dministration module =see section 3.)>

,ppendi9 , & C(an'e %o's

, & + Requirements ,dded Since RS ). 0, & ) C(an'ed Requirements from RS ).0, & 3 ocument C(an'es from RS ).0

, & ! Requirements ,dded Since RS +. 0, & 6 C(an'ed Requirements from RS +.0, & $ ocument C(an'es from RS +.0

,ppendi9 B & B & ) Requirements @e'otiations =arc( #4 )00$>B & 3 Client comments on RS +.0B & ! Client Comments on & RS ).0

,ppendi9 C & *rototype Screens

C & + Sample C(allen'esC & ) Sample *u77le:C & 3 Screens for Game oduleC & ! Screens for ,dministration odule

,ppendi9 1raceaility atrices

& + Requirements /s. Requirements

©%on' Stretc( Software )00$ *a'e & #


8/69




& ) Requirements /s. Rationale & 3 Requirements /s. 1est Cases

©%on' Stretc( Software )00$ *a'e &


9/69




1. Introduction

%on' Stretc( Software =%SS> will e de/elopin' a muc( needed computer 'ame desi'ned to

teac( students of Grades + and ) asic at(4 En'lis( and *rolem&Sol/in' sills. 1(e name oft(e 'ame is DElementary Juest. 1(e 'ame will e entertainin' yet educational and will allowteac(ers to trac t(e pro'ress of t(e students. 1(is document outlines t(e specific requirementsfor eac( module of t(e system as understood y %SS.

1.1 Purpose

1(is document is a proposal for requirements specification in response to t(e UVic Center forSc(olastic Entertainment’s Request for *roposal posted on 8anuary +$4 )006. 1(e %SS team is/ery e9cited aout t(e idea of t(e 'ame and prospects of worin' on its de/elopment. 5e arealso /ery confident t(at our le/el of e9pertise and e9perience in t(e industry will matc( t(esop(istication of t(e 'ame’s requirements.

1.2 Scope

1(e requirements specified in t(is document will e used for desi'nin' all t(e aspects andcomponents of t(e 'ame. 1(e document will e updated as t(e requirements 'row and c(an'eo/er t(e desi'n and de/elopment process.

1.3 Definitions, Acronyms and Abbreviations

)9 C R


10/69




pi9els.5indows & icrosoft’s operatin' system.

1.4 !ossary

1(is 'lossary contains terms intended to clarify t(e document for t(e reader. 1(rou'(out t(edocument4 'lossary terms are lined ac to t(is section. @ot all words may e lined4 ut atleast one instance of eac( word s(ould e lined in eac( para'rap(.

E9tra note: Because Requisite*ro was used4 and it applies its own styles to t(e requirements4some lins may not e /isile wit(in t(e requirement statements.

challenge:

, learnin' element of t(e 'ame. C(allen'es will contain ot( instructions and a practice

question. C(allen'es are descried in section ).).3.+4 and e9amples are 'i/en in,ppendi9 C.+. game world:

1(e 'ame world is a made up of a set of le/els4 and is t(e o/erall settin' for t(e story oft(e 'ame. 1(e 'ame world will not e accessile in its entirety at t(e e'innin' of t(e'ameL new le/els will e unloced as t(e player pro'resses. 1(e 'ame world isintroduced in section ).).

level:

, le/el is a lar'e susection of t(e 'ame world4 made up of a numer =/aries y le/el> ofsections. %e/els are introduced and e9plained in section ).).3.

level map:

1(e map w(ic( displays t(e sections of t(e current le/el. 1(e le/el map is introduced insection ).).!.+.non-playable character (NPC):

, c(aracter in t(e 'ame t(at is controlled only y t(e 'ame system. @*Cs as defined(ere4 are not limited only to (uman&style c(aracters4 ut could also e monsters oroFects. 1(e player will interact wit( t(e @*Cs in t(e 'ame w(ic( will present t(e player will c(allen'es. @*Cs are introduced in section ).).).

puzzle:

, pu77le in t(e conte9t of t(e 'ame is a learnin' element4 w(ic( a player must completeto ad/ance to new sections of t(e 'ame. *u77les are e9plained in section ).).3.+ and ane9ample 'i/en in ,ppendi9 C.).

scene: , scene refers to w(at t(e user sees at a 'i/en point in a section4 w(en (e"s(e is ale tomo/e (is"(er c(aracter around. 1(at is4 a scene is w(at t(e user sees w(en (e"s(e is notcurrently attemptin' a c(allen'e or pu77le4 and (e"s(e is not looin' at t(e map.

section:

, section of t(e 'ame is a su&di/ision of a 'ame le/el. @ew sections of a le/el areunloced as t(e player completes pu77les at t(e end. Sections are introduced indocument section ).).3.

©%on' Stretc( Software )00$ *a'e & +0


11/69




world map:

1(e map w(ic( displays t(e le/els of t(e 'ame world. 1(e world map is introduced insection ).).!.+.

1." #eferences

UVic Center for Sc(olastic Entertainment =UCSE> Education Game System: Request for*roposal Version +.0.

1.$ %vervie& of Document

1(ere are four main sections followin' t(is introduction:Section ) will pro/ide an o/er/iew of our /ision of t(e system includin' our perspecti/es of t(e'ame4 assumptions of user c(aracteristics and interactions4 and some desi'n constraints.Section 3 will detail t(e requirements t(at t(e system will satisfy4 as well as pro/ide use&cases to(elp t(e understandin' of t(e system. Requirements and use&cases are or'ani7ed into t(e

modules of t(e system t(at t(ey apply to =see section ).+>.

2. %vera!! Description

2.1 Product Perspective

1(ere are t(ree main components of t(e system:

• Game module: t(e 'ame w(ic( students will play and learn from.

• ,dministration module: administration interface for t(e teac(ers to access student

records.

• ataase acend: (andles t(e stora'e of all player and 'ame statistics.

1(ese modules are descried in detail in t(e arc(itecture section =section !> of t(e document.

2.1.1 System Interfaces

1(e dataase ser/er will interact wit( t(e 'ame and administration clients t(rou'( a %,@.

2.1.2 User Interfaces

1(e interface for t(e students will e entertainin' and en'a'in'. enus will e easily accessilet(rou'(out t(e 'ame.


12/69




Students’ results will e transferred to and from a ser/er t(rou'( any standard networin'(ardware.

1(e 'rap(ical content will e at least )6$ colors at a resolution of $!09!0 and at most 3)million colors wit( a resolution of +)09+0)!. 1(is will allow for t(e 'ame to e played on older computers commonly found in elementary sc(ools. 1(e amount of 'rap(ical content will also elimited to ensure t(at t(e total si7e of t(e 'ame remains under t(e 0B limit.

2.1.4 Operations

1(e 'ame will pro/ide t(e followin' minimal operations:

• 2t will teac( at(4 En'lis( and *rolem Sol/in' sills to 'rade le/els + ) in an

entertainin' and en'a'in' manner. See section 3.+.#.) for more details.

• 2t will pro/ide functionality for teac(ers to trac and e/aluate student pro'ress. See

section 3.).) for more details.

• 2t will pro/ide user interface and controls for t(e tar'eted audience. See sections 3.+.3.+and 3.+.3.) for more details.

• 2t will pro/ide difficulty le/els to cater t(e sill le/el of t(e users. See section 3.+ for

more details.

2.2 ame 'oncepts

1(is section descries t(e o/erall concepts e(ind t(e 'ame module of t(e system. 1(e ideasdiscussed (ere will e useful in understandin' t(e terms used t(rou'(out t(e use&cases andrequirements sections of t(e document.

,s mentioned efore4 t(e product t(at is ein' specified in t(is document is an educational 'ame.1(e 'ame can e cate'ori7ed as an R*G Role *layin' Game. 2n an R*G4 t(e c(aracter mo/est(rou'(out t(e 'ame Dworld and disco/ers new t(in's4 encounters new c(allen'es4 interactswit( non&playale c(aracters =@*C>4 t(erey main' it a fun and interacti/e e9perience for t(euser.

2.2.1 Rationale

1(e rationale e(ind main' t(is 'ame an R*G is t(at t(e 'ame must create and (old user’sinterest on a daily asis for a lon' period of time =around two years>. 1(e c(allen'e of course isto create interestin' content for t(e R*G4 as well as pro/ide enou'( amount of interaction etween t(e user and t(e 'ame.

2.2.2 Characters

1(e user will e ale to c(oose a c(aracter and play t(e 'ame in t(e c(aracter’s role. 1(ec(aracter will e a (uman c(ild of eit(er male or female 'ender. 1(e c(aracter’s clot(es4accessories4 sin color4 etc. will e customi7ale.


13/69




1(e non&playale c(aracters will typically e dra'ons4 dinosaurs4 princes and princesses sincesuc( c(aracters are of a 'reat interest to t(e tar'eted user 'roup. ,lso4 for t(e purpose of t(isdocument4 M@*C’ also refers to oFects w(ic( t(e player can interact wit(. 1(e main c(aracter

will interact wit( t(e @*Cs to learn new concepts4 as well as e tested on t(e concepts (e"s(e (aslearned.

2.2.3 Leels and Sections

1(e 'ame world will e made up of le/els w(ic( will increase in difficulty. 1(e user will pro'ress t(rou'( t(e 'ame y ad/ancin' to (i'(er and (i'(er le/els. 1(ere will e plenty ofle/els to eep t(e user interested in t(e 'ame for at least two years. 1(e le/els will (a/einterestin' names to arouse curiosity in users. 1(e le/els in turn will (a/e different sections onmat(4 En'lis( and prolem sol/in'. 1(rou'(out eac( section4 t(e c(aracter will acquire newsills4 and will e tested on t(ose sills efore finis(in' eac( section. 5(en t(e user finis(es t(efinal section in a le/el4 (e"s(e will ad/ance to a new le/el w(ic( will (a/e similar sections & Fust

more difficult4 as far as educational material is concerned. Iowe/er4 as far as t(e 'ame play andloo and feel of t(e 'ame are concerned4 t(e sections will (a/e to e ori'inal and non&repetitiousso as not to ore t(e player.

2.2.3.1 Challenges (Questions) and Puzzles

5it(in le/els and section4 t(e main acti/ities will e c(allen'es4 and t(e transition points etween sections =and le/els> will e pu77les. Bot( concepts are introduced elow.

C(allen'es will e t(e instructional and practice elements of t(e 'ame. 1(e player willencounter c(allen'es t(rou'( interaction wit( t(e @*Cs t(rou'(out t(e 'ame. C(allen'es will e simple4 only focusin' on a sin'le topic =for e9ample4 nouns or addition>. 1(e c(allen'e willfirst pro/ide instructions4 and t(en pose a question to t(e player to allow t(em to practice t(e

concept. 1(e questions will e ot( multiple&c(oice and te9t&entry ased types. 2f t(e playeranswers incorrectly4 a (int will e 'i/en4 and some possile incorrect options will e remo/ed4and t(en t(e player will e ale to once more. 5(en t(e player completes a c(allen'e t(ey willad/ance or e rewarded wit( money or items.

*u77les are intended to function as tests in t(e 'ame. , player will encounter pu77les as (e"s(e pro'resses t(rou'( t(e 'ame. 2n order for t(e player to ad/ance to new le/els of t(e 'ame4 t(eywill need to complete a pu77le. Unlie c(allen'es4 pu77les do not pro/ide t(e player wit(detailed instructions or introductions to new conceptsL only rief instructions on (ow to completet(e pu77le. 1(is way4 a pu77les functions as a test to ensure t(at t(e player is learnin' as (e"s(ead/ances. ,n e9ample pu77le is s(own in ,ppendi9 C.).

2.2.3.2 Progress reward

urin' t(e 'ame play4 t(e player will e rewarded for correctly respondin' to t(e c(allen'es orcompletin' pu77les. 1(e points =money> rewarded s(ould correspond to t(e difficulty le/el of t(ec(allen'e or t(e pu77le.

5it( t(e reward points =money>4 t(e player can uy new items for (is"(er c(aracter or unlocnew features of t(e 'ame.

©%on' Stretc( Software )00$ *a'e & +3


14/69




1(e pro'ress reward in terms of money is meant to eep t(e student interested in t(e 'ame for alon' time. 2t also reinforces t(e ad/enturous c(aracteristics of t(e 'ame.

2.2.4 !ame Interfaces

1(is section descries t(e loo and feel of t(e 'ame4 as well as some of t(e interfaces t(at t(euser will see =i.e. aps>.

2.2.4.1 Maps

1(e user will (a/e access to two different maps: t(e world map and t(e le/el map. 1(e worldmap will display t(e le/els t(e user (as finis(ed4 as well as t(e le/els a(ead. 1(e le/els a(eadwill e 'rayed out4 meanin' inaccessile to t(e user. 1(e user will e ale to 'o ac to any oft(e le/els (e"s(e (as already finis(ed. 1(e le/el map will wor in a similar fas(ion. 2t willdisplay all t(e sections on a particular le/el4 and t(e sections not yet e9plored will e

inaccessile to t(e user. 1(e user will e ale to 'o ac to any of t(e sections (e"s(e (asalready finis(ed.

2.2.4.2 Setting and Scenes

1(e 'ame settin' will typically include 'reen landscapes4 castles and dun'eons ased on sectionsand le/els. , le/el will typically e a landscape or a castle4 and eac( section will e a part of t(atstructureL for e9ample4 in case of a le/el ein' a landscape4 t(e section will e a small /illa'e.,n e9ploration scene will e presented to t(e user e/ery time t(e user finis(es a section. ,ne9ploration scene will (a/e arrows to t(e sections s(owin' t(e user to pic a certain pat( toselect a particular section. 1(ere maye more t(an one section to ad/ance to4 after finis(in' a

section4 or t(e user will also e ale to 'o ac to t(e section (e"s(e Fust finis(ed.2.2.4.3 Menu and Status bar

1(e 'ame will always display a status ar w(ic( will display t(in's suc( as t(e current le/el4 andt(e section t(e user is in as well as t(e amount of money t(e user (as earned. 1(e user will also(a/e access to an option menu w(ic( will allow user to adFust sound4 music and pro/ide accessto in&uilt (elp system.

2.2." Story and !oal

1(e o/erall story of t(e 'ame will in/ol/e t(e prince"princess ein' idnapped y an e/ilc(aracter. 1(e main c(aracter t(en would 'o on a rescue campai'n4 passin' (urdles andc(allen'es4 'at(erin' (ints4 defeatin' t(e enemies encountered4 and rescuin' t(e prince"princess.

1(e 'oal of t(e c(aracter will e to e9plore t(e 'ame4 encounter t(e @*C4 learn new sills and pass t(e c(allen'es =educational pu77les or prolems> t(at t(e @*C pose4 and earn rewards.

2.3 (ser ')aracteristics

1(is 'ame is tar'eted towards c(ildren attendin' Grades + and ). 1(ese 'rades typicallycorrespond to a'es ran'in' from $ to years. ,t t(is sta'e in sc(ool4 c(ildren are e9pected to

©%on' Stretc( Software )00$ *a'e & +!


15/69




(a/e rudimentary readin' and mat( sills. C(ildren in t(is a'e ran'e tend to (a/e /ery s(ortattention spans4 and 'reat effort must e put in to maintainin' t(eir interest. 1(ey also tend to e/ery curious4 and may inad/ertently cause prolems as a result.

ost c(ildren liely (a/e (ad access to computers at (ome4 ut t(is cannot e 'uaranteed4 sosome c(ildren may not (a/e t(e computer sills necessary to operate t(e 'ame wit(out 'uidance.Iowe/er4 t(ey are 'enerally /ery 'ood at followin' patterns and can e tau'(t fairly easily.Startin' wit( a'es etween $& years4 'irls and oys s(ow /ery different c(aracteristics fromeac( ot(er. 1(ey will (a/e /ery different interests and sources of entertainment: a factor t(atcannot e i'nored. ,lso4 'irls in t(is a'e ran'e tend to e more mentally ad/anced and de/elopedt(an t(eir male counterparts.Because t(e 'ame is intended for in&sc(ool use4 teac(ers will e administratin' t(e 'ame4 andmust also e considered in t(e de/elopment of t(e 'ame. 1eac(ers represent a muc( more /arieda'e ran'e and ac'round t(an c(ildren4 ut it can e assumed t(at t(ey will (a/e asiccomputer sills4 suc( as word and spreads(eet processin'4 e&mail and we rowsin'.

2.4 'onstraints

1(e followin' constraints are specified in t(e R-* Version +.0:

• *latform independence is necessary since sc(ools may (a/e different computer


16/69




wit(in one wee of t(e deli/ery of our deli/erales. 1(e followin' are t(e deli/eralesdeadlines requested in t(e R-* +.0:

8anuary )$ eetin' to discuss R-*

8anuary 30 RS +.0-eruary $ RS +.+arc( ) *rototype emo

arc( $ Requirements @e'otiationsarc( +0 RS ).0

arc( +$ RS ).+,pril 3 RS 3.0

arc( 30 ,pril $ -inal emo

3. Specific #e*uirements

2n t(is section4 we will specify detailed requirements for t(e educational 'ame system. .


17/69




suc( as outfits4 armors4 accessories4 and toys.

*rimary Scenario +.+

,ctor ,ction System Response

Student presses c(aracter screen utton.

Game module displays t(e c(aracterscreen. See ,ppendi9 C.3.+ .

*ossile ,lternati/e: See +.+&3

%. Student C(an'es a c(aracter option=see appendi9 C.3.+ for complete list>.

&. Game odule updates c(aracter ima'ein t(e display portion of t(e screen.

*ossile ,lternati/e: See +.+&6.

5. Student e9its c(aracter screen y

clicin' on t(e return utton. Game odule sa/es c(an'es to dataaseand loads pre/ious 'ame screen.

,lternati/e Scenario +.+&3: Student uys an item

%.'a(Student selects item to purc(asewit( play money.

%.')( Game odule c(ecs for sufficientfunds.

%.'c( Game odule maes items a/ailaleto equip4 and informs student of suc(.

Return to Step ! in primary scenario.

,lternati/e Scenario +.+&6: Student updates anot(er c(aracter option

5.'a(Student c(an'es anot(er c(aracteroption.


Secondary Scenario +.)


Student lo's in for t(e first time.

Game module displays t(e c(aracter

screen. See fi'ure C.3.+.Student c(an'es a c(aracter option tocustomi7e it.

&. Game odule updates c(aracterima'e in t(e display portion of t(e screen.

*ossile ,lternati/e: See +.)&6.

5. Student e9its c(aracter screen y

©%on' Stretc( Software )00$ *a'e & +#


18/69





clicin' on t(e return utton.

6. Game odule sa/es c(an'es todataase and loads pre/ious 'ame screen.

,lternati/e Scenario +.)&6: Student updates anot(er c(aracter option

5.'a(Student c(an'es anot(er c(aracteroption.

Return to Step ! in secondary scenario.

Use ase *: E9plore aps"ctors: Student4 t(e Game odule#urpose: -or t(e student to e9plore t(e le/el map or world map.$escription: Eac( le/el will (a/e a map contain different sections . 1(e 'ame world will (a/e amap containin' t(e different le/els of t(e 'ame. 1(e student will use t(e world map to accessa/ailale le/els4 and t(e student will e ale to e9plore t(e le/el map to 'et to t(e scene toencounter t(e c(allen'es. ependin' on t(e le/el map4 t(e student can access t(e sectionsrandomly or must access t(e sections in a prescried order =or some comination>. 1(e le/elmap will indicate t(e areas t(e student (as already e9plored. 5(en t(e c(aracter enters asection4 t(e 'ame will rin' t(e c(aracter into t(e scene =See Use Case 3>. 5(en all sections ont(e le/el map are disco/ered4 and t(e final pu77le (as een sol/ed4 t(e 'ame will unloc t(e ne9tle/el=s> =see 3.+.).+.#>.

*rimary Scenario ).+


+. Student presses world map utton.

*. Game module displays t(e worldmap screen. See ,ppendi9 C.3.) .

%. Student pics an a/ailale le/el.

*ossile ,lternati/e: See ).+&!.

&. Game odule displays le/el map for t(e selected le/el. See *rimary scenario).+

"+ternati,e Scenario *.!-&: Student clics on una/ailale section

&.'a(Game module plays error sound.

Return to Step 3 in primary scenario.

Secondary Scenario ).)


+. Student presses le/el map utton.

*. Game module displays t(e le/el mapscreen. See ,ppendi9 C.3.) .

©%on' Stretc( Software )00$ *a'e & +


19/69





%. Student pics an a/ailale section.

*ossile ,lternati/e: See ).+&!.

&. Game odule displays first scenefor selected section.

"+ternati,e Scenario *.!-&: Student clics on una/ailale le/el

&.'a(Game module plays error sound.

Return to Step 3 in secondary scenario.

Use ase %: E9plore Section"ctors: Student4 t(e Game odule#urpose: -or student to e9plore t(e current section

$escription: Sections are su&elements of t(e 'ame le/els4 as introduced in section ).).3. 1(e/isual and story t(emes of t(e scene will e related to t(e current le/el. 1(e c(allen'es and pu77les in a 'i/en section will e of a similar type =e.'. En'lis( ased4 or mat( ased>. 5(enstudent interacts wit( an @*C4 t(e 'ame will present a c(allen'e to t(e c(aracter =See Use Case!>. 5(en t(e required c(allen'es for a section (a/e een o/ercome4 t(e student will encounter a pu77le4 w(ic( t(ey must complete to finis( t(e section.

*rimary Scenario 3.+


+. Student presses /alid le/el on t(eworld map screen.

*. Game module displays first section of t(e selected le/el. See ,ppendi9 C.3.3.

*ossile ,lternati/e: See 3.+&3.

%. Student clics on a direction (eadin'.

&. Game odule loads appropriatescene for t(e section4 ased on t(e player’s current location.

"+ternati,e Scenario %.!-%: Student interacts wit( an @*C

&.'a(See Use Case !


Use ase &: ,nswer C(allen'e"ctors: Students4 t(e 'ame modules#urpose: 1(is is t(e main oFecti/e of t(e 'ame. 1(e student will e tested y respondin' to t(ec(allen'es.$escription: 1(e c(allen'e can e any form of question. Juestions will e posed as multiple&c(oice or te9t&entry types. 1(e de'ree of difficulty of t(e c(allen'e s(ould correspond to t(e

©%on' Stretc( Software )00$ *a'e & +;


20/69




student le/el. and ass t(e student to trya'ain.

6')!( Student attempts to answer t(e prolem a'ain.


Use ase 5: Complete *u77le"ctors: Students4 t(e 'ame modules#urpose: ain oFecti/e of t(e 'ame. 1(e pu77les are used to see if t(e student can apply w(at(e"s(e (as Fust learned.$escription: 5(en a student reac(es t(e end of a section4 t(ey will e posed wit( a pu77le. 1(e pu77le incorporates t(e learnin' oFecti/es of t(e particular section. @o (int is 'i/en on t(e

©%on' Stretc( Software )00$ *a'e & )0


21/69




t(eory e(ind t(e pu77le4 only aout (ow to sol/e t(e pu77le. 1(e de'ree of difficulty of t(e pu77le s(ould correspond to t(e current le/el. map =See Use Case )> w(ere anot(er possilesection =or le/el> is now unloced. Student’s pro'ress will e lo''ed so t(at (e"s(e doesn’t need

to redo t(e pu77le4 if t(ey DGi/e Up =see alternate scenario 6.+&3> or e/en if t(e 'ame cras(es.

*rimary Scenario 6.+


+. Student reac(es t(e end of a section.

*. Game module displays t(e pu77le fort(e current section. See ,ppendi9 C.).

*ossile ,lternati/e 6.+&3.

%. Student sol/es pu77le

&. Game odule records result in t(edataase =see 3.+.).+.6>.

5. Game odule con'ratulates student

6. Student clics on DContinue

7. Game odule loads le/el =or world>map screen wit( at least one e9tra scene=or le/el> on it unloced =see 3.+.).+.$ and3.+.).+.#>

,lternati/e Scenario 6.+&3: Student is unale to sol/e pu77le.

%'a(Student clics on DG2VE U* utton

%.')(Game odule records t(e student

'i/in' up%.')(Game odule loads current sectiont(at t(e student is e9plorin'. 1(e @*Cs int(e section will present c(allen'es useful inunderstandin' t(e nowled'e required tosol/e t(e pu77le.

1(e screen s(ots of t(e prototype4 w(ic( associated wit( t(e ao/e use cases can e found in,ppendi9 C.

3.1.2 #$nctional Re%$irements

ue to time constraints4 we (a/e decided to 'o into detail on t(e 'ame module functionalrequirements section4 since t(is is t(e main component of t(e system and t(e ot(er two su&systems’ desi'ns will depend (ea/ily on t(e desi'n of t(e 'ame system.

3.1.2.1 he ga!e will teach the student new !ath and "nglish concepts b#presenting the! with challenges.

E9amples of c(allen'es for En'lis( and mat( are in appendi9 sections C.+.+ and C.+.) respecti/ely.

©%on' Stretc( Software )00$ *a'e & )+


22/69




Rationale: 2n section ).0 of t(e R-*4 t(e primary 'oal was for t(e 'ame to teac( t(e student mat(and En'lis( sills. 1(e DC(allen'es in t(e 'ame will accomplis( t(is y pro/idin' t(e studentwit( instructions4 t(en asin' (im"(er a question ased on t(at instruction.

1est scenario :+> 1(e player encounters a c(allen'e =for e9ample y talin' to an @*C>.


23/69




answer. Because of t(e functionality addressed in 3.+.).+.34 t(e system will still record t(estudent’s success rate. 1(is also supports requirement 4 y (elpin' t(e student to learn newconcepts y e9ample4 and to learn from t(eir own mistaes.

1est scenario :+> 1(e player encounters a c(allen'e =for e9ample y talin' to an @*C>.

1(e player reads t(e instructions and attempts to answer t(e c(allen'equestion.

con'ratulate and =if applicale> reward t(e player for a correct answer4 or > display a (int and simplify =if applicale> t(e prolem if t(e answer is incorrect.

!> 2f t(e answer was correct4 t(e player will continue4 if not t(en t(ey will trya'ain.

3.+.).+.! 1(e 'ame module will record in t(e dataase t(e total numer of times a student D'i/esup on a pu77le =see use case scenario 6.+&34 and ,ppendi9 C.)> efore completin' it4 and a description of t(e sills tested y t(e pu77le.

Rationale: 1(is addresses t(e client’s request t(at t(e system trac student pro'ress =see section

) of R-* and ,ppendi9 B.+.+0> includin' (ow many correct and incorrect answers t(ey (a/e'i/en. , description of t(e pu77le is pro/ided4 instead of Dt(e question (e (ad wron' wit( t(eanswer t(e id inputted4 as requested4 since t(e pu77les will e /isual in nature4 main' itimpossile to store t(e actual pu77le and answer in t(e dataase and pro'ress reports.

1est Scenario :+> 1(e player encounters a pu77le y reac(in' t(e end of a section.


24/69




)> 1(e player attempts to complete t(e pu77le. 1(e player encounters a pu77le y reac(in' t(e end of a section. 1(e player attempts to complete t(e pu77le.

of t(e le/el and display it on t(e le/el map.

,n unloced portion of t(e map will depend on t(e desi'n of t(e particular le/el.Rationale: Unlocin' portions of t(e map will allow t(e system to control and trac student pro'ress =as requested in R-* section ).0>4 as well as pro/idin' increasin' difficulty of learnin'elements =as requested durin' elicitation4 see ,ppendi9 B.+.3>. Unlocin' a /ariale numer ofsections will allow t(e student to c(oose t(eir own pat( to some e9tent4 t(erey main' t(e 'amemore fun =as requested in t(e R-*>.1est Scenario :

+> 1(e player encounters t(e pu77le in any non-fina+ section of a le/el. 1(e player completes t(e pu77le.

. 1(e le/el map is displayed wit( t(e unloced sectionsindicated.

3.+.).+.# 5(en a student completes t(e final pu77le in a le/el4 t(e 'ame will unloc anot(er portion =defined elow> of t(e world and display it on t(e world map.

,n unloced portion of t(e map will contain at most t(ree le/els4 eac( containin' learnin'elements of equal difficulty.

©%on' Stretc( Software )00$ *a'e & )!


25/69




Rationale: Unlocin' portions of t(e map will allow t(e system to control and trac student pro'ress =as requested in R-* section ).0>4 as well as pro/idin' increasin' difficulty of learnin'elements =as requested durin' elicitation4 see ,ppendi9 B.+.3>. Unlocin' a /ariale numer of

le/els =up to t(ree> will allow t(e student to c(oose t(eir own pat( to some e9tent4 t(ereymain' t(e 'ame more fun =as requested in t(e R-*>.

1est Scenario:+> 1(e player encounters t(e final pu77le in t(e final section of a le/el. 1(e player completes t(e pu77le.

. 1(e world map is displayed wit( t(e unloced le/elsindicated.

3.1.2.2 he s#ste! will pro$ide in%ga!e tutorials and help.

1(e system is intended for use in classes4 so t(e 'ame will need to pro/ide support for studentst(at need (elp. , sin'le teac(er will not e ale to (elp all students all t(e time so t(e 'ames(ould include an in&'ame tutorial and a (elp document. 1(e purpose of t(e in&'ame tutorial is tofamiliari7e t(e student wit( new na/i'ation elements t(at appear durin' t(e 'ame play. 1(e purpose of t(e (elp document is to pro/ide instructions on (ow to install t(e 'ame and (ow to play t(e 'ame.

1utorial:

•


26/69




!> 1(e player is now familiar wit( usin' t(e mouse and t(e eyoard.

3.+.).).) 1(e system will s(ow on&screen (elp alloons after (o/erin' t(e mouse pointer o/er an

oFect for ) seconds.2n order to facilitate t(e use of t(e 'ame and admin modules4 e/ery user interface oFect =suc( asan D


27/69




3.1.2.' he ga!e will entertain and engage the attention o the students.

1(e 'ame must pro/ide a le/el of entertainment to t(e student to (elp eep (im"(er en'a'ed and

focused on t(e 'ame. 1(is is one of t(e ey requirements outlined in section ).0 of t(e R-*.

3.+.).6.+ 1(e system will pro/ide 'ame music and sounds

1o (elp pro/ide t(e user wit( an entertainin' 'ame e9perience4 t(e 'ame will feature music andsounds t(at c(an'e as t(e user pro'resses t(rou'( t(e 'ame.

3.1.2.5.1.1 The system will allow game music and sounds to be turned on and off

Rationale : 1o (elp eep t(e students 'ame e9perience positi/e4 t(e 'ame will play differentmusic and sounds t(rou'(out t(e 'ame. Since t(e 'ame will e predominantly used in aclassroom en/ironment4 in&'ame music and sounds may ecome distracti/e to ot(er students.

1(us t(ere will e options on t(e main menu t(at allow t(e user to turn on and off t(e music andsounds.

1est Scenario:+> 1(e user clics t(e main menu utton. 1o turn eit(er t(e music and sounds off4 clics t(e c(eco9es mared M


28/69




3.+.).6.) 1(e 'ame will allow t(e user to adFust t(e properties of (is"(er c(aracter.

3.1.2.5.2.1 The user can buy and sell items for his/her character.

Rationale: 1o pro/ide a 'ood le/el of entertainment to t(e 'ame users4 t(ere will e a rewardsystem implemented4 t(at allows t(e players to use t(e credits t(ey (a/e 'ained from correctlyanswered questions to uy new items for t(eir c(aracters suc( as clot(in'4 accessories4 (air stylesand p(ysical appearances. 1(is will encoura'e t(e students to try t(eir est to answer and manyc(allen'es as possile so t(at t(ey can accessori7e t(eir c(aracters. 1(is will mae t(e 'ameentertainin'4 as requested in t(e R-*. ,n e9ample screens(ot is pro/ided in appendi9 C.3.+.

1est Scenario :+> 1(e user selects t(e c(aracter customi7ation screen.

1(e user clics t(e MBuy’ utton.

1(e user c(ooses an item to purc(ase and clics t(e MBuy’ utton


29/69




Rationale: 1o allow t(e user to customi7e (is"(er c(aracter4 t(e colors of t(e c(aracter can eadFusted. 1(e user can c(an'e t(e color of (is"(er sin4 (air4 'lo/es4 s(irt4 pants4 footwear andot(er accessories. ,n e9ample screens(ot is pro/ided in appendi9 C.3.+.

1est Scenario :+> 1(e user selects t(e c(aracter customi7ation screen. 1(e user clics on t(e arrow utton under t(e style column4 or under t(e colorcolumn.

1(e user clics t(e MReturn’ utton


30/69




requested in section ).0 of R-*>.

1est Scenario :+> 1(e user correctly answers a numer of c(allen'es.

create a new B from

scratc( usin' uilt&in scripts4 or =)> c(oose from a list of e9istin' dataases detected y t(einstall pro'ram.

2n addition to t(e sc(ool"(ome installation options4 t(e setup pro'ram will allow t(e user toc(oose eit(er a full installation or a minimal installation =See also Section 3.+.6.+>:1(e minimal installation option is 'eared towards computers wit( limited (ard dri/e space.2nstead of copyin' t(e 'ame audio to t(e (ard dri/e4 it will e streamed from t(e 'ame Cdurin' play =requirin' t(at t(e C content e accessile eit(er locally or /ia %,@>.1(e full installation on t(e ot(er (and will install t(e entire content of t(e C to t(e computer(ard dri/e. 1(is will (elp t(e 'ame load faster ut will require more dis space.

Re'ardless of t(e setup type4 t(e 'ame will automatically confi'ure itself usin' t(e est settin'sfor t(e detected (ardware =alt(ou'( options are a/ailale in&'ame to mae c(an'es to t(esesettin's if necessary>.

Rationale:+> R-* section !: Q*arents will use t(e 'ame to trac t(e de/elopment of t(eir

c(ild"c(ildren at (ome in t(e same way as teac(ers do at sc(ool. *arents will also e installin' t(e 'ame on (ome computers.Q



31/69




)> R-* section $: Q). Because a lot of sc(ools are usin' older systems t(is 'ames(ould run on a system wit( t(ese requirements:

& 5indows ;6 and newer: *entium $04 +$ B ram4 0 B I space4 ouse4

SVG, /ideo card4 )94 or etter4 speed C&R


32/69




occurrence is at most +.

3.1." 'erformance re%$irements

3.1.'.1 he ga!e will oer two installation !odes / ull and partial install.

1(e partial installation of t(e 'ame will require t(e 'ame C to function4 w(ereas t(e fullinstallation will e standalone. 1(is satisfies (ardware requirements specified in t(e R-* as wellas t(e client’s request =see Section B.+.$> t(at a full install e a/ailale.

3.1.'.2 he ga!e will occup# at !ost 0M o hard dis space or the partial install.

3.1.'.3 he ga!e will run s!oothl# on a co!puter with !ini!u! s#ste!

reuire!ents o a 2 M5z processor6 4M o 78M and 29 C:%7;M dri$e or greater

@ote t(at t(is requirement was c(an'ed from t(e R-* as t(e result of t(e ne'otiation session=See ,ppendi9 B.)>.

3.1.'.4 Ma9i!u! ti!e ro! launching the ga!e until it is pla#able will be ' !inutes6

but a$erage ti!e o$er all supported s#ste!s will be less than 2 !inutes.

,fter t(e application is launc(ed4 it will tae fewer t(an 6 minutes for t(e player to load t(eirdata and e'in playin' t(e 'ame from w(ere t(ey last left off4 on e/ery supported system. 1oaddress concerns t(at t(is load time is too lon' =See ,ppendi9 B.)>4 %SS will ensure t(at t(ea/era'e load time o/er all supported systems is less t(an ) minutes. 1(is will (elp to ensure t(atc(ildren do not lose interest w(ile t(e 'ame is ein' loaded.

3.1.'.' "9pected upti!e will be -


33/69




ratin' can e found at (ttp:""www.esr.or'"esrratin's'uide.asp.

3.1.


34/69




3.1.0.3 he s#ste! will include an instruction guide in both paper and electronic$ersions or parents.

1(e system will s(ip wit( an included 'uide for parents. 1(e 'uide will (a/e instructions on(ow to install t(e 'ame module on a (ome computer and start a new 'ame. ,s per t(e clientHs

inspection of RS ).0 =see ,ppendi9 B.!.3>.

3.2 Administration modu!e

3.2.1 -dministration Use Cases

,ll of t(e functional requirements are ased on t(e followin' line on t(e R-*: D1eac(ers of'rades + and ) will use t(e 'ame to trac de/elopment in indi/idual students and as a possilemarin' 'uide. 1eac(ers will also e9port rele/ant data for creatin' spreads(eets and 'rap(s ofindi/idual and 'roup performance.

1o study t(e requirement for t(is module4 we desi'ned t(e followin' use cases:

Use ase 6: ana'e student accounts =create"edit"delete>"ctors: 1eac(ers4 t(e administration module#urpose: 1eac(ers must e ale to create and mana'e accounts for t(eir students as specified int(e R-*.$escription: 5(en t(e teac(er lo's into t(e ,dministration system4 t(ey are presented wit( amain screen t(at pro/ides options to create4 edit4 and"or delete student user accounts for t(e'ame.

*rimary Scenario $.+

,ctor ,ction System Response!. 1eac(er lo's in.

*. 1(e main administration screen isdisplayed. See ,ppendi9 C.!.+.

*ossile ,lternati/es $.+&3a4 $.+&3.

%. 1eac(er clics t(e Create utton

&. , window is displayed promptin't(e teac(er to enter t(e username and password and ot(er information suc( asfirst name4 last name4 'rade le/el for t(estudent.

*ossile ,lternati/e $.+&6c

5. 1eac(er types in t(e enter t(eusername and password and ot(erinformation suc( as first name4 last name4'rade and clics


35/69




,lternati/e Scenario $.+&3a: 1eac(er c(ooses to edit an e9istin' student account.

%'a( 1eac(er clics t(e Edit utton

&'a( , window is displayed promptin'to teac(er to select an e9istin' accountfrom a drop down list4 and enter anyc(an'es in t(e space pro/ided.


,lternati/e Scenario $.+&3: 1eac(er c(ooses to delete an e9istin' student account.

%')( 1eac(er clics t(e elete utton

&')( , window is displayed promptin't(e teac(er to select an e9istin' accountfrom a drop down list.

5')( 1eac(er clics t(e elete utton

Return to Step $ in primary scenario.

,lternati/e Scenario $.+&6c: 1eac(er c(ooses to cancel t(e action.

5'c( 1eac(er clics t(e Cancel utton

6'c( @o c(an'es are made and t(eteac(er is returned to t(e main screen.

Use ase 7: E9port Student *ro'ress =create"edit"delete>"ctors: 1eac(ers4 t(e ,dministration module.

#urpose: 1eac(ers must e ale to e9port student pro'ress for analysis.$escription: 5(en t(e teac(er lo's into t(e ,dministration system4 t(ey are presented wit( amain screen t(at pro/ides options to e9port pro'ress for a sin'le student4 or for all students. 1(estudent pro'ress info can e e9ported as a comma delimited te9t file4 or as an e9cel spreads(eet.1(e only information can e imported and e9ported are t(ose t(at is related to t(e student pro'ress =le/el4 score4 question answered> not t(e 'ame play e9perience elements suc( asc(aracter or items.

*rimary Scenario #.+


!. 1eac(er lo's in.

*. 1(e main ,dministration screen isdisplayed. See fi'ure C.!.+ .

*ossile ,lternati/e #.+&3a

%. 1eac(er clics t(e Sin'le Student utton

&. , window is displayed promptin't(e teac(er to select a student from adrop down list.



36/69





*ossile ,lternati/e #.+&6

5. 1eac(er selects t(e student and clicsE9port

6. , Sa/e ,s dialo' appears allowin't(e teac(er to sa/e t(e pro'ressinformation in eit(er te9t or e9celformat.

,lternati/e Scenario #.+&3a: 1eac(er c(ooses to e9port t(e pro'ress of all students.

%'a( 1eac(er clics t(e ,ll Students utton

Return to Step $ in primary scenario.

,lternati/e Scenario #.+&6: 1eac(er c(ooses to cancel t(e action.

5')( 1eac(er clics t(e Cancel utton

6')( @o pro'ress information is sa/ed4and t(e teac(er is returned to t(e mainscreen.

-or eac( use case4 we created a prototype. Tou can find t(e screens(ots from t(e prototypes in,ppendi9 C.!.


,fter inspectin' t(e use cases and t(e prototype carefully4 we came up wit( t(e followin'

functional requirements for t(e ,dministration module.

3.2.2.1 he ad!inistration !odule will generate reports o student progress.

1(e reports 'enerated will allow t(e teac(er to trac t(e student’s learnin' pro'ress. 1(e reportswill include student results for eac( type of prolem =mat(4 En'lis( and prolem sol/in'>4 aswell as t(e time spent playin' and t(eir current pro'ress le/el =as specified on t(e R-*>.

3.2.2.2 he ad!inistration !odule will e9port report data (3.2.2.1) to "9cel

docu!ents and co!!a separated te9t docu!ents.

1(e system pro/ides e9port to E9cel documents so t(at teac(ers can use a familiar pro'ram4 asrequested in section 6 of UCSE’s R-*. Comma separated te9t document e9ports pro/ide

portaility ecause t(ey can e read y any computer4 as requested in ne'otiation section =see,ppendi9 B.).#>.

3.2.2.3 he ad!inistration !odule will ad!inistrate the student accounts.

2n order for t(e teac(er to mana'e t(e student profiles4 t(e teac(er will e ale to administrate4=add4 delete4 modify>4 t(e student accounts y usin' t(is function of t(e administration module.

©%on' Stretc( Software )00$ *a'e & 3$


37/69




3.2.2.4 he ad!inistration !odule will i!port student data ro! "9cel and co!!aseparated iles.

1(e teac(er can import student data ='ame statistics4 and user information> from E9cel files orcomma separated te9t files4 pro/ided t(at t(e files are in t(e correct format. 1(is satisfies a

request made y t(e clients durin' ne'otiations =see ,ppendi9 B.).#>.

3.2.2.' he ad!inistration !odule will pro$ide help or each unction o the !odule.

1(e system will pro/ide support for teac(ers wit( /aryin' amounts of computer sillsL ysupplyin' a (elp module for e/eryt(in' t(ey are ale to do usin' t(e administration module.

3.2.2. he ad!inistration !odule will authenticate the teacher or the ad!inistratorbeore the# can use the !odule.

Before t(e teac(er or administrator can use t(e module4 t(ey (a/e to lo' in usin' a pair ofusername and password. 1(e module must c(ec t(e aut(enticity of t(e username and password.

3.2.3 Usa&ility re%$irements

3.2.3.1 @a!iliar user interace pro$ided or teachers

1(e interface for queries will e similar to a we&rowser4 wit( re'ards to na/i'ation and fileaccess. @a/i'ation will use clicale te9t similar to lins as well as forward and ac uttons.Responses to system queries s(ould e ale to e e9ported to formatteddocuments or comma separated te9t files =requirement 3.).).)>4 pro/idin' a familiar interface for data manipulation =see section ,ppendi9 B.).6>.

3.2.4 Relia&ility re%$irements

3.2.4.1 "9pected upti!e will be -'

1(e admin module will e ale to run for at least t(ree consecuti/e (ours4 ;6 of t(e time. 1(iss(ould e reliale enou'( for t(e teac(er interaction wit( t(e system.

3.2." 'erformance re%$irements

3.2.'.1 he ad!inistration !odule will occup# at !ost 0M o hard dri$e space.

See t(e rationale in t(e ne9t requirement.

3.2.'.2 he ad!inistration !odule will run s!oothl# on a s#ste! ha$ing a 2 M5z

processor and 4M o ra!6 or better speciications.

1(e R-* did not specify t(e (ardware requirement for t(e ,dministration module. Iowe/er4 wewill use t(e same (ardware requirements used for t(e 'ame4 since it s(ould e ale to e run on

t(e same (ardware. See section 3.+.6.) and 3.+.6.3 for t(e 'ame module requirement.

©%on' Stretc( Software )00$ *a'e & 3#


38/69




3.3 Database bac+end

3.3.1 *ata&ase Use Cases

3.3.1.1 Ae used a si!ilar techniue to deter!ine the unctional reuire!ents or the

database bacend* create the user cases and careull# stud# the!. he ollowing are theuse cases or the database bacend*

Use ase : Store data in dataase"ctors: 1(e 'ame module4 t(e dataase module#urpose: Send information to t(e dataase so t(e student’s pro'ress is stored. ataase sends error messa'e to'ame module.

).=> Game module retries sendin' results.

Return to step ) in primary scenario.

Use ase : Retrie/e data from dataase"ctors: 1(e ,dministration module4 t(e dataase module#urpose: Retrie/e information from t(e dataase so a student’s pro'ress can e /iewed.O,er,iew: 1(is use case is in/oed y t(e admin module. 1(e administration module willretrie/e information from t(e dataase module. 1(e administration module will display t(isinformation.

*rimary Scenario +.)

Actor Action System esponse

+. ,dministration module requestsinformation from dataase.

*ossile ,lternati/e: See +.)&)

). ataase sends information toadministration module.

*ossile ,lternati/e: See +.)&)=>



39/69




Actor Action System esponse

3. ,dministration module recei/esinformation.

"+ternati,e Scenario !.!-*: Error occurs4 results not stored.

).=a> ataase sends error messa'e toadministration module.

).=> ,dministration module retriesinformation request.

Return to step ) in primary scenario.


3.3.2.1 he database will collect the ga!e progress o each student.

urin' t(e time t(e student is playin' t(e 'ame4 if t(e student data c(an'es4 for e9ample if t(estudent answers a question correctly4 t(e 'ame module will send t(e c(an'es to t(e dataasemodule. 1(e dataase module s(ould e ale to update t(e data and eep trac of t(e c(an'es.See section 3.+.).3 for more information on t(is requirement from t(e 'ame module.

3.3.2.2 he database will authenticate the student e$er# ti!e heBshe starts a session

on the ga!e !odule.

Eac( time a student starts a 'ame4 (e"s(e will need to aut(enticate (imself"(erself. 1(e dataases(ould store aut(entication information and e ale to aut(enticate t(e users. See section 3.+.).3.

3.3.2.3 he database will be able to authenticate the teacher ro! the 8d!inistration

!odule.Similar to t(e 'ame module4 t(e ,dministration module will also require t(e teac(er toaut(enticate eac( time t(ey lo' into t(e module. 1(e dataase s(ould store aut(enticationinformation and e ale to aut(enticate t(e users. See section 3.).).$.

3.3.2.4 he database will answer data uer# ro! the 8d!inistration !odule.

1(e ,dministration module will query t(e dataase for 'ame statistics. 1(e dataase s(ould eale to answer t(ose queries. See section 3.).).+.

3.3.2.' he database will !aintain inor!ation or a !ini!u! o one #ear.

1(e clients requested =see ,ppendi9 B.).$>4 t(at information in t(e dataase e retained for oneyear for access t(rou'( t(e ,dministration module.

3.3.3 Relia&ility re%$irements

3.3.3.1 "9pected s#ste! upti!e will be -'.

1(e ac&end dataase s(ould e ale to support up to +00 connections of t(e 'ame clients4 ;6of t(e time.

3.3.3.2 he s#ste! will not be erroneous due to une9pected input.

1(e dataase will e ale to (andle all sorts of input and e immune to side effects cause y

©%on' Stretc( Software )00$ *a'e & 3;


40/69




undesirale inputs =suc( as uffer o/erflow>4 w(ic( could potentially create security (oles in t(esystem.

3.3.3.3 he s#ste! will !aintain networ securit#.

1(e software will employ appropriate networ security protocols to ensure t(at it doesn’t createnetwor security prolems. ,s per t(e ne'otiations =see ,ppendi9 B.).>4 security is not a (i'( priority so only t(e minimal security requirements will e met for t(e system. 1(is includesfirewalls and encryption for sensiti/e information.

3.3.4 'erformance re%$irements

3.3.4.1 he database will be able to support up to 1 concurrent connections ro!the ga!e !odules and up to 1 concurrent connections ro! the 8d!inistration !odules.

3.3." Interfaces re%$irements

3.3.'.1 he 8d!inistrator will be able to interace with the database !odule.

,part from ein' ale to communicate wit( t(e 'ame module and t(e ,dministration module4t(e dataase must (a/e its own interface so t(e ,dministrator and manipulate data and perform acup operations directly.

3.4 'ommon re*uirements

3.4.1 Usa&ility re%$irements

3.4.1.1 =ong Stretch Sotware will wor with SM"+s to ensure that the s#ste! will beusable b# all parties

5e will collaorate wit( teac(ers4 c(ild psyc(olo'ists and ot(er educators4 as well as c(ildren toensure t(at t(e system will e useale for people of all e9perience le/els.

3.4.2 *esi+n constraints

,naly7in' t(e first requirement elicitation lo' and t(e R-* +.04 %SS will assume t(e followin'desi'n constraints.

3.4.2.1 Sotware de$elop!ent language

%SS will use different software lan'ua'es durin' t(e prototypin'4 desi'n and testin' p(ases suc(as *rolo' to 'enerate test cases or % to model some searc( al'orit(ms. Iowe/er4 t(edeli/erale software will e written in:

• Client software: 8a/a on 8RE +.6 compatile.

• ,dministration module: 8a/a on 8RE +.6 compatile.

• ataase: Standard SJ%.

3.4.2.2 :e$elop!ent toolsifferent departments at %SS will use different de/elopment tools.2n 'eneral4 we will use Eclipse 2E for software de/elopment

•


41/69




E9istin' (ardware suc( as eyoard and mouse will e t(e only (ardware required for input tot(e 'ame.

3.4.4 Software Interfaces

1(e 'amin'4 ,dministration and dataase components of t(e software will communicatesecurely /ia a local networ. ,ll connections will e adequately encrypted4 w(ile still meetin't(e performance requirements.

3.4." Licensin+ Re%$irements

,t t(is point4 %SS elie/es t(at t(ere is not(in' to license. Iowe/er4 our sound en'ineer willwor wit( your B, to see if t(ere are any special ac'round musicals or sound effects t(at areneeded.

3.4.( Le+al Copyri+ht and Other /otices

Upon t(e release of t(e software4 an EU%, must e de/eloped y UCSE to specify le'ala'reement etween t(e user and UCSE. %SS will not e a liale party in t(is EU%, or in any

le'al document re'ardin' t(e use of t(e software. %SS will only y liale as a contractor tode/elop t(e software and will fulfill its le'al requirements.

,ll software components t(at are part of t(e %SS e9istin' software repository4 and are used int(e 'ame will remain as %SS’s intellectual property =2*>. %SS reser/es all ri'(ts concernin' t(euse4 distriution4 and disclosure of suc( wor. 5ors de/eloped e9clusi/ely for t(is softwarewill ecome UCSE’s 2*.

4. ame Arc)itecture

,s mentioned in section )4 t(ere are t(ree main components in t(is 'ame system:

• 1(e Game odule

•1(e ataase odule

• 1(e ,dministration odule

ependin' on t(e desi'ner constraints4 t(e desi'ner team will create different su&componentsfor t(ese modules. 1(e o/erall arc(itect4 (owe/er4 s(ould aide y t(e description 'i/en in t(issection.

4.1 ame modu!e see section 3.1-

4.1.1 #$nctions

1(e 'ame module interacts wit( t(e user and pro/ides t(e user a 'ame play e9perience as

specified in t(e R-* and in section 3.+. 2t contains e9ploration maps4 le/els4 pu77les andc(allen'es and ot(er 'ame elements =see section ).)> w(ic( pro/ide t(e 'ame play e9perience tot(e student. ,s part of t(e 'ame play e9perience4 it also allows t(e user to accessori7e and selectand edit t(e c(aracter =see appendi9 C.3.+ for e9ample interface>.

1(e 'ame module will also aut(enticate t(e user. 2n order to accomplis( t(is4 it must retrie/e t(euser aut(entication data from t(e dataase module and /alidate it.

©%on' Stretc( Software )00$ *a'e & !+


42/69




1(e 'ame module will also eep trac of user score and pro'ress. 2t stores and retrie/es t(isinformation in t(e dataase =dataase module>.

4.1.2 -rchitect$re

1(e followin' fi'ure s(ows a proposed arc(itecture for t(e 'ame module in a form of a classdia'ram followin' y a rief description of t(e functionality of eac( class:

4.1.2.1 raphics

1(is class is t(e interface to t(e student. 2t does all of t(e 'rap(ic renderin' and (andle all of t(einput"output of t(e 'ame.

4.1.2.2 Sound

1(is class will (andle all of t(e sound and music of t(e 'ame.

4.1.2.3 a!e

1(is class is t(e main class in t(e usiness layer of t(e 'ame module. 2t will contain all of t(eot(er classes in t(e usiness layer suc( as Student class4 ap class. 2t will (andle all of t(einteraction etween t(e ot(er classes to eep t(e 'ame lo'ic ri'(t t(rou'( out t(e 'amee9perience.

4.1.2.4 Student

1(is class represents t(e user of t(e 'ame module =t(e student>. 2t contains t(e entire traceale

©%on' Stretc( Software )00$ *a'e & !)


43/69




attriute of t(e student suc( as t(e state of t(e c(aracter4 t(e score4 and t(e pro'ress. 2t willinterface wit( t(e dataase module to sa/e t(e c(an'es.

4.1.2.' Map

1(is class represents t(e maps of t(e 'ame. -or more information aout t(e map4 please see t(esection aout t(e 'ame concepts in Section ).

4.1.2. Scene

1(is class represents t(e scenes of t(e 'ame. -or more information aout t(e scenes4 please seet(e section aout t(e 'ame concepts in Section ).

4.1.2.< Question

1(is class represents t(e questions in t(e 'ame. -or more information aout questions4 please seet(e section aout t(e 'ame concepts in Section ). 2nstance of t(is class will (a/e a question andt(e appropriate answers.

4.1.2.0 Puzzle

*u77le is an anot(er type of c(allen'e in t(e 'ame. -or more information aout t(e pu77le4 please see t(e section aout t(e 'ame concept in Section ).

4.2 Database modu!e see section 3.3-

1(e dataase module stores score and pro'ress data for t(e users. 2t pro/ides access to t(is datato t(e 'ame module and t(e administration module.

1(e dataase module also stores users’ 'eneral information and aut(entication information asentered y t(e teac(er or administrator. 2t pro/ides access to t(is data to t(e 'ame module and t(eadministration module.

4.3 Administration modu!e see section 3.2-

1(e administration module aut(enticates t(e administrator. 2t retrie/es t(e ,dministrationaut(entication data from t(e dataase module and /alidates it in order to accomplis( t(is.

1(e administration module allows t(e administrator to add"edit"remo/e users from t(e dataase=See section !.) ataase odule>.

1(e administration module 'enerates scores and pro'ress reports y retrie/in' data from t(edataase. 2t can also e9port t(ese reports to ot(er formats.

1(e administration module can import reports and can t(en e9tract and /alidate t(e data from t(ereports and store it into t(e dataase.

©%on' Stretc( Software )00$ *a'e & !3


44/69




Appendix A ')an/e 0o/s

A.1 #e*uirements Added Since #S 2.

1(is section lists all requirements t(at are new to t(is /ersion of t(e RS4 and t(e rationale fort(eir addition.

Re/uirement

0um)erRe/uirement Rationa+e for "ddition Source

$ate

=dd"mm"yyyy>

3.+.).+ 1(e 'ame will require t(e student to

correctly complete pu77les4 in order

to ad/ance to t(e ne9t section of t(e

'ame.

1(is requirement was t(e

result of splittin' up

requirement 3.+.).3 in RS ).0.

Section ).0

of t(e R-*

0)"0!"0$

3.+.).+.+ SUBREJS+ 1(e 'ame will require

t(e student to correctly complete

pu77les4 in order to ad/ance to t(e

ne9t section of t(e 'ame.

1(is requirement was t(e

result of splittin' up

requirement 3.+.).3 in RS ).0.

Section ).0

of t(e R-*

0)"0!"0$

3.+.).+.) SUBREJS3 2f a student answers a

c(allen'e incorrectly4 t(e 'ame will

pro/ide a (int and if applicale4

simplify t(e c(allen'e.

1(e client does not want

students to e punis(ed for

incorrect answers to

c(allen'es4 so c(allen'es will

e simplified if a student is

unale to answer correctly.

1(is will also (elp t(e student

to 'rasp new concepts y

e9ample.

2nspection of

RS ).0. See

appendi9

B.!.

0)"0!"0$

3.+.).+.3 SUBREJS) 5(en student

completes a c(allen'e4 t(e 'ame

module will record in t(e dataaset(e numer of attempts required for

t(e student to complete t(e

c(allen'e and t(e final simplified

/ersion of t(e c(allen'e.

1(e clients requested t(at t(e

'ame trac student pro'ress.

1(is requirement details t(edata w(ic( will e traced for

answers to c(allen'es.

See R-*

section )4

andelicitation

results

=,ppendi9

B.+.+0>

0)"0!"0$

3.+.).+.! SUBREJS! 1(e 'ame module will

record in t(e dataase t(e total

numer of times a student D'i/es

up on a pu77le =see use case

scenario 6.+&34 and ,ppendi9 C.)>

efore completin' it4 and a

description of t(e sills tested y t(e

pu77le.

1(e clients requested t(at t(e

'ame trac student pro'ress.

1(is requirement details t(e

data w(ic( will e traced for

answers to pu77les.

See R-*

section )4

and

elicitation

results

=,ppendi9

B.+.+0>

03"0!"0$

3.+.).+.6 SUBREJS6 2f a student cannotcomplete a pu77le4 and c(ooses to

D'i/e up4 t(e 'ame will direct t(e

student ac into t(e e'innin' of

t(e current section4 and pro/ide

rele/ant c(allen'es =see 3.+.).+.+

and Use Case 6> to (elp.

1(is addresses a concern t(att(e clients raised durin' t(e

prototype demo4 w(ic( was

DNsic.O 5(at (appens if a

student cannot sol/e a

pu77leP

*rototypedemo.

03"0!"0$

3.+.).+.$ SUBREJS$ 5(en a student 1(e clients (a/e requested 03"0!"0$

©%on' Stretc( Software )00$ ,ppendi9 , & !!


45/69




Re/uirement

0um)erRe/uirement Rationa+e for "ddition Source

$ate

=dd"mm"yyyy>

pro'ress tracin' and

difficulty le/els. 1(is

requirement formali7es (owt(e 'ame module will

accomplis( t(is etween

sections.

3.+.).+.# SUBREJS# 5(en a student

completes t(e final pu77le in a le/el4

t(e 'ame will unloc anot(er

portion =defined elow> of t(e world

and display it on t(e world map.

1(e clients (a/e requested

pro'ress tracin' and

difficulty le/els. 1(is

requirement formali7es (ow

t(e 'ame module will

accomplis( t(is etween

le/els.

See R-*

section ).0

and

elicitation

result in

,ppendi9

B.+.3

03"0!"0$

3.+.).6 1(e 'ame will entertain and en'a'e

t(e attention of t(e students.

1(is super&requirement was

added to e9plicitly address

t(e functions of t(e 'ame t(atwould mae it interestin' and

en'a'in'.

See R-*

section ).0

0!"0!"0$

3.+.).6.+ 1(e system will pro/ide 'ame music

and sounds

1(is requirement was added

to pro/ide more detail aout

(ow t(e 'ame will entertain

en'a'e t(e attention of t(e

students

See R-*

section )

requirement

)

0!"0!"0$

3.+.).6.+.+ 1(e system will allow 'ame music

and sounds to e turned on and off

1(is requirement pro/ides

more detail aout t(e 'ame

music and sounds =see ao/e>

See R-*

section )

requirement

)

0!"0!"0$

3.+.).6.+.) 1(e system will play different music

for eac( le/el.

1(is requirement pro/ides

more detail aout t(e 'ame

music and sounds =see ao/e>

See R-*

section )

requirement

)

0!"0!"0$

3.+.).6.) 1(e 'ame will allow t(e user to

adFust t(e properties of (is"(er

c(aracter.

1(is formally e9plains (ow

t(e system will address t(e

client request t(at t(e 'ame

e entertainin' and en'a'in'.

R-* section

).0

0!"0!"0$

3.+.).6.).+ 1(e user can uy and sell items for

(is"(er c(aracter.

1o en(ance entertainment and

en'a'ement of t(e user as

requested y t(e clients

R-* section

).0

0!"0!"0$

3.+.).6.).) 1(e user is allowed to c(an'e

(is"(er c(aracter’s 'ender.

1(is was added to e9plain

(ow t(e system will appeal to

all memers of t(e tar'etaudience.

R-* 0!"0!"0$

3.+.).6.).3 1(e user can c(an'e t(e appearance

of t(eir c(aracter

,'ain4 t(is was added to

address (ow t(e system will

en'a'e t(e users.

R-* section

).0

0!"0!"0$

3.+.).6.3 1(e 'ame module will pro/ide in

'ame animations.

,'ain4 t(is was added to

address (ow t(e system will

en'a'e t(e users.

R-* section

).0

06"06"0$

©%on' Stretc( Software )00$ ,ppendi9 , & !6


46/69


47/69




specific requirements. =marin' of

RS ).0>

Use

Case !

Use

case !

1(e use case was updated so t(at

t(e system presents multiple&c(oice or te9t entry type

question.

Clients requested te9t&ased

questions in comments.

RS ).0

comments.,ppendi9 B&

)3!

0)"0!"0$

Use

Case !

Use

Case !

1(e use case was updated so t(at

if t(e student enters an incorrect

response4 t(e system will

pro/ide a (int and simplify t(e

prolem.

Clients don’t want students to

e punis(ed for incorrect

answer. 1(e (int and

simplification aids in t(e

learnin' process.

RS ).0

comments.

,ppendi9 B&

)3!

0)"0!"0$

3.+.).) 3.+.).) 1(is requirement was split into

se/eral su&requirements

2ncreased t(e de'ree of detail

of t(e requirement for RS 3.0.

,s su''est y

t(e consultant

2rwin ?wan

0!"0!"0$

).+.3 ).+.3 C(an'ed color and resolution

requirement

,ddress RS ).+ feedac from

t(e clients

RS ).+ 0$"0!"0$

Usecas

e $

Usecas

e $

C(an'ed required student

information


t(e clients

RS ).+ 0$"0!"0$

Usecas

e #

Usecas

e #

Clarified w(at information can

e imported or e9ported


t(e clients

RS ).+ 0$"0!"0$

3.+.6.6 3.+.6.6 2ncrease uptime requirement

from ;6 to ;#


t(e clients

RS ).+ 0$"0!"0$

3.+.#.) 3.+.#.) Remo/ed tain' away money

from player for answerin'

wron' question.


t(e clients

RS ).+ 0$"0!"0$

3.+.#.) 3.+.#.) Remo/ed redundant information

w(ic( (as already een stated in

Section ).) Game Concepts.

Remo/ed ecause of

redundancy

RS 3.0 0$"0!"0$

3.+.$.) 3.+.$.) 1(e requirement was clarified tos(ow e9actly w(o would e

doin' t(e up'rades.

C(an'ed for clarity. ,s su''est yt(e consultant

2rwin ?wan

0$"0!"0$

A.3 Document ')an/es from #S 2.

1(is section details t(e c(an'es t(at (a/e een made to t(e o/erall document since /ersion +.0.1(ese c(an'es will include all t(ose t(at do not relate to indi/idual requirements =listed in t(e )sections pre/ious>4 ut rat(er t(e orderin' of sections4 formattin'4 added components and ot(ersuc( c(an'es.4ntroduced

in ersion

Section

2anged$escription Rationa+e for 2ange

$ate

'ddmm(

).) ,ppendi9,

,dded new c(an'e lo'sfor t(e c(an'es from RS

).0 to 3.0. 1(e old lo's

are included in t(e

followin' sections =in

'rey te9t> for furt(er

reference.

@ew lo's were added to clearly s(ow t(ec(an'es from RS ).0 to 3.0.

0)"0!"0$

).) ,ppendi9 ,dded section MC.+ C(allen'es are referenced frequently 0)"0!"0$

©%on' Stretc( Software )00$ ,ppendi9 , & !#


48/69




Sample C(allen'es’ and

remo/ed t(e former

ME9ample *rolem.’ 1wo

new e9ample c(allen'es

were added one forEn'lis(4 one for mat(.

t(rou'(out t(e document4 so detailed

e9amples are ein' pro/ided for clarity.

).) ,ppendi9

C

,dded section MC.)

Sample *u77le’ and

remo/ed t(e former

ME9ample *u77le.’ 1(e

e9ample pu77le (as also

een updated4 and a

description added.

*u77les are referenced frequently

t(rou'(out t(e document4 so a detailed

e9ample is ein' pro/ided for clarity.

0)"0!"0$

).3 +.! ,dded 'lossary to

document.

Referencin' common concepts to t(e

'lossary maes t(e document easier to

understand.

0)"0!"0$

).3 Section ! Remo/ed t(e 'eneral

arc(itect dia'ram. ,ddclass dia'ram for t(e

'ame module

,s su''est y t(e consultant 2rwin ?wan 03"0!"0$

).3 Section 3.) ,dded test scenarios to

all functional

requirements of t(e 'ame

module =section 3.)>.

2mpro/es formality of t(e requirements. 0!"0!"0$

).3 +.3 ,lp(aeti7ed t(e

acronym list.

,s su''est y t(e consultant 2rwin ?wan 0$"0!"0$

).! 3.04 3.) ,dded description of

w(ic( module would e

detailed and w(y.

2mpro/es readaility and understandin'

of document.

0$"0!"0$

).! ).+ ,dded reference to t(e

arc(itecture section of t(e

document so t(e reader

can familiari7e

t(emsel/es wit( it if t(ey

need to.

,s su''est y t(e consultant 2rwin ?wan 0$"0!"0$

A.4 #e*uirements Added Since #S 1.

1(is section lists all requirements t(at are new to t(is /ersion of t(e RS4 and t(e rationale fort(eir addition.

Requirement

@umer

Requirement Rationale for ,ddition

3.+.#.+ 1(e completed 'ame will (a/e an

ESRB ratin' of ME’.

urin' t(e requirements ne'otiation session4 t(e

clients requested an ESRB ratin' of ME’ =see

,ppendi9 B.).3>

3.+.#.3 ,ll 'ame content will e interestin' for

oys and 'irls.

urin' t(e ne'otiation session4 t(e clients requested

t(at all content e Mase9ual’ so ot( oys and 'irls

would find it interestin'.

3.3.).6 -R,2@+0 1(e dataase will 1(is requirement was added to satisfy t(e client’s

©%on' Stretc( Software )00$ ,ppendi9 , & !


49/69




request t(at t(e system maintain data for one year.

1(is request was made durin' t(e @e'otiation

session =see ,ppendi9 B.).$>

3.+.6.+ 1(e 'ame will offer two installation

modes full and partial install.

1(is addition satisfies t(e client request from RS+.+

=see ,ppendi9 B.3.> t(at a full install option ea/ailale for computer systems t(at (a/e enou'(

(ard dri/e space.

3.+.#.) 2n order to e entertainin'4 t(e 'ame

will en'a'e t(e student in a story line

2n section ).0 of t(e R-*4 an oFecti/e is to

DEntertain and en'a'e t(e attention of t(e students.

1(is requirement was added to satisfy t(is and t(e

client request t(at information on storyline e

included in RS ).0 =see ,ppendi9 B.).+!>

3.).).+ -R,2@+ 1(e administration

module will 'enerate reports of student

pro'ress.

1(is functionality was requested y t(e UCSE in

section !.0 of t(e Client R-*.

3.).).) -R,2@) 1(e administration

module will e9port report data =3.).).+>

to E9cel documents and commaseparated te9t documents.

3.).).6 -R,2@6 1(e administration

module will pro/ide (elp for eac(

function of t(e module.

1(is addresses t(e concern t(at not all teac(ers will

(a/e t(e same computer e9perience4 and may need

assistance. 1(is is outlined in section ).3.

3.).6.+ 1(e administration module will occupy

at most 0B of (ard dri/e space.

1(is addresses t(e si7e constraint 'i/en in R-*

section $.0

3.).6.) 1(e administration module will run

smoot(ly on a system (a/in' a )00

I7 processor and $!B of ram4 or

etter specifications.

1(is requirement was added to address t(e

minimum system requirements t(at were a'reed

upon durin' ne'otiations =see ,ppendi9 B.).+)>

3.).).3 -R,2@3 1(e administration

module will administrate t(e studentaccounts.

1(e 'ame must trac indi/idual student pro'ress

=R-* section !.04 elicitation ,ppendi9 B.+.!>4 soeac( student must (a/e t(eir own account. 1(us4 a

met(od is needed to add"create"delete t(ese

accounts4 w(ic( will e pro/ided y t(e

administration module.

3.).).! -R,2@! 1(e administration

module will import student data from

E9cel and comma separated files.

urin' t(e requirements ne'otiation session4 t(e

clients ased for import functionality =see ,ppendi9

B.).6>.

3.3.).+ -R,1,B,SE+ 1(e dataase will

collect t(e 'ame pro'ress of eac(

student.

1(is supports t(e requirement 3.+.!.+ as well as t(e

client comment in ,ppendi9 B.+.+).

3.3.).) -R,2@# 1(e dataase will

aut(enticate t(e student e/ery time

(e"s(e starts a session on t(e 'amemodule.

3.3.).3 -R,2@ 1(e dataase will e ale

to aut(enticate t(e teac(er from t(e

,dministration module.

1(is supports requirement 3.).).$.

3.3.).! -R,2@; 1(e dataase will answer

data query from t(e ,dministration

module.

1(is supports requirement 3.).).+.

©%on' Stretc( Software )00$ ,ppendi9 , & !;


50/69




A." ')an/ed #e*uirements from #S 1.

1(is section lists all requirements t(at (a/e een c(an'ed from RS +.04 and t(e rationale for t(e

c(an'e.

Requirement’s @umer in:escription of C(an'e Rationale for C(an'e

RS +.0 RS ).0

3.+.3 3.+.6.! 1(e requirement Da9imum time from

launc(in' t(e 'ame until it is playale will e 6

minutes. from RS +.0 (as een altered to

included an a/era'e load time of ) minutes

o/er all system.

1(is addresses t(e client’s

concerns t(at 6 minutes is too

lon' to wait. 1(is issue was

discussed durin' t(e

Requirements @e'otiations

=see ,ppendi9 B.).++>

3.+.) 3.+.).+.+ 1(e requirement D1(e system will pro/ide in&

'ame tutorials and (elp was c(an'ed from

listed as non&functional to functional.

1(is corrects an error from

/ersion +.0 w(ere t(is

requirement was incorrectly

listed as non&functional.

3.3.+ 3.+.!.+ 1(is requirement De'radation odes (as

een c(an'ed to DStudent pro'ress

automatically sa/ed to dataase w(en 'oals are

completed.

De'radation odes is not a

proper requirement statement

=ami'uous etc>4 so it was

corrected.

3.3.) 3.+.6.)

3.+.6.3

C(an'ed minimum system requirements for

computers from $0I7 and +$B of R, to

)00(7 and $! B of R,. 1(e requirement

DResource Utili7ation from RS +.0 (as een

split into t(e requirements:

1(e 'ame will occupy at most 0B of (ard

dis space for t(e partial install.

1(e 'ame will run smoot(ly on a computerwit( minimum system requirements of a )00

I7 processor4 $!B of R, and )9 C&

R

1(e requirement statement

DResource Utili7ation was not

a proper requirement statement=ami'uous4 etc.>4 and t(e

details (eld requirement

information4 so t(ey were split

up into two new requirements.

3.+..+ 3.+.3.) C(an'ed user interface requirement to Dsimple

enou'( for 'rade + and ) students.

4 ut rat(er t(e orderin' of sections4 formattin'4 added components and ot(ersuc( c(an'es.2ntroduced in Section escription Rationale for C(an'e

©%on' Stretc( Software )00$ ,ppendi9 , & 60


51/69




Version C(an'ed

+.) Section 3 Re&or'ani7ed all of section 3 into !

su&sections one for eac( module

of t(e system ='ame4 administration

and dataase> and one for commonelements.

5(en plannin' t(e arc(itecture of t(e

system4 t(e system was di/ided into t(ree

separate modules. Re&or'ani7in' t(e

requirements to reflect t(is will (elp t(ereadaility of t(e document.

+.) Section 3

su sections

2@ eac( new susection of Section 34

t(e requirements are now or'ani7ed

into su sections ased on w(et(er

t(ey are functional or non&functional4

instead of ein' differentiated y =->

and =@-> in t(e requirement (eadin'.

1(is also required a c(an'e to t(e

introduction to Section 3.

1(is c(an'e impro/es t(e readaility4 and

modifiaility of t(e requirements. 2t also

maes it easier to ran t(e requirements

y importance. -inally4 it (elps t(e

document to comply wit( standards.

+.3 ,ppendi9 ,

UCSE’s R-*

+.0

UCSE’s R-* was included for

reference in RS +.04 ut (as een

remo/ed for /ersion ).0.

1(e addition of t(e R-* was deemed

redundant4 and remo/ed to impro/e

readaility and reduce comple9ity of t

Educational-Game+RS-3.0

Documents

Transcript of Educational-Game+RS-3.0