COMP 3663 X2

COMP 3663 X2

S1:

Software Requirements Specification

OutSource Inc. (Group A)

Mallinson, Mike 100071936

Logan, Billy 100059371

Peters, Richard 100071545

Table of Contents

1COMP 3663 X2

1S1:

1Software Requirements Specification

2Table of Contents

5Introduction

61Introduction

61.1Purpose

61.2Scope

61.3Definitions, acronyms & abbreviations

61.4References

61.5Overview

72Overall description

72.1Product perspective

72.1.1System interfaces

72.1.1.1Concept of Operations

82.1.2User Interfaces

82.1.2.1Introduction Window Concept

92.1.2.2Select Difficulty Screen

102.1.2.3Create new Character Window Concept

112.1.2.4Load Character Window Concept

122.1.2.5Dungeon Window Concept

132.1.2.6Select Stats Window Concept

132.1.2.7Map Window Concept

142.1.3Hardware interfaces

142.1.4Software Interfaces

142.1.5Java Virtual Machine

142.1.6Communications Interfaces

142.1.7Memory Constraints

142.1.8Operations

152.1.9Site Adaptation Requirements

162.2Product Functions

162.2.1“Creating a Character” Use Case

162.2.2“Traveling to Adjacent Grid Location” Use Case

172.2.3 “Obtaining Item” Use Case

172.2.4 “Travel to New Location” Use Case

172.2.5“Initiate Battle” Use Case

182.2.6 “Attack” Use Case

182.2.7“Berserker” Use Case

192.2.8“Use Item” Use Case

192.2.9“Flee” Use Case

202.2.10“Defend” Use Case

202.2.11“Save” Use Case

202.2.12“Load” Use Case

202.3 User Characteristics

212.4Constraints

212.5Assumptions and Dependencies

212.6Apportioning of Requirements

212.6.1Basic Functional Requirements

242.6.2Human Interface Requirements

262.6.3Undesirable Characteristics

262.6.4Basic Non-functional Requirements

262.6.5 Cost and Time Constraints

273. Specific Requirements

273.1External interface requirements

273.1.1User interfaces

273.1.1.1Title Screen

273.1.1.2Character Creation

273.1.1.3Dungeon Window

273.1.1.4Battle Window

283.1.2Hardware Interfaces

283.1.3Software Interfaces

283.1.4Communication Interfaces

283.2Classes/Objects

283.2.1Character

283.2.1.1Face

283.2.1.2Status Points

283.2.1.3Attributes

283.2.1.4Experience

283.2.1.5Level

283.2.1.6Life Tokens

293.2.2Area

293.2.2.1Room

293.2.2.1.1Maze

293.2.2.2Door

293.2.2.3Map

293.2.3Encounter

293.2.3.1Hostile Unit

293.2.3.1.1Enemy

293.2.3.1.2Boss

293.2.4Item

293.2.4.1Room Key

303.2.4.2Boss Key

303.2.4.3Treasure Chest

303.2.4.4Gear

303.2.4.4.1Weapon

303.2.4.4.2Armor

303.2.4.5Potion

303.3Performance Requirements

303.4Design Constraints

303.5Software System Attributes

303.5.1Reliability

313.5.2Availability

313.5.3Security

313.5.4Maintainability

313.6Other Requirements

324Project Management Plan

324.1Introduction

324.1.1Project Overview

324.1.2Project Deliverables

324.1.3Evolution Of The SPMP

324.1.4Reference Materials

324.1.5Definitions And Acronyms

324.2Project Organization

324.2.1Process Model

334.2.2Organizational Structure

334.2.3Organizational Boundaries and Interfaces

334.2.4Project Responsibilities

344.3Managerial Process

344.3.1Managerial Objectives and Priorities

344.3.2Assumptions, Dependencies, and Constraints

344.3.3Risk Management

344.3.4Monitoring and Controlling Mechanisms

354.3.5Staffing Plan

354.4Technical Process

354.4.1Methods, Tools, and Techniques

354.4.2Software Documentation

354.4.3Project Support Functions

354.5Work Packages, Schedule, and Budget

354.5.1Work Packages

354.5.2Dependencies

354.5.3Resource Requirements

364.5.4Budget and Resource Allocation

364.5.5Schedule

37Appendix A – Glossary of Terms

38Appendix B – Sequence Diagrams for Use Cases

Introduction

OutSource Inc. is a PC videogame developer and designer company. Our goal is to provide customers with an enjoyable and attractive gaming experience, Conan. With over 10 years experience in the IT industry, our designers will provide a gaming experience that will keep you coming back for more.

For this product, OutSource Inc. will be partnered with Initech. We are developing a game called Conan, in which Conan the barbarian must fight his way through a dungeon to survive.

This report contains important requirements and information about the game Conan. Section 2 of this report illustrates the game menus, maps and dungeon screens. Section 3 is a listing of the technical specifications.

OutSource Inc. would like to thank Initech for allowing us to have this experience and we expect to exceed Initech’s initial expectations on the game.

Sincerely,

The OutSource Inc. Team

1 Introduction

1.1 Purpose

The purpose of this report is to provide the supplier and customer with a composed guideline concerning the Conan computer game. Section 1 will describe the basic aspects of the game while Section 2 will illustrate a basic graphical implementation providing a glimpse of the game’s appearance, the game’s functions and behavior. Section 3 is mainly for software engineers.

1.2 Scope

This component covers the customer deliverable for a Conan computer game. This will allow developers to mold the game to fulfill the requirements and present a template for the game’s layout.

1.3 Definitions, acronyms & abbreviations

See Appendix A – Glossary of Terms.

1.4 References

· Braude, E. J. (2001). Software Engineering: An Object-Oriented Perspective. John Wiley and Sons.

· Silver, D. (2006). Course Web Page: Comp 3663 X2 – Software Engineering. Retrieved January 28, 2007 from the World Wide Web: http://plato.acadiau.ca/courses/comp/dsilver/3663/

1.5 Overview

Conan is a role playing computer game devised by Initech and developed by OutSource Inc. The game will provide entertainment for gamers ages 14+ as the user will be participating in violent endeavors. The game will not be complicated and the controls will be simple making the game appealing for all gamers.

2 Overall description

2.1 Product perspective

2.1.1 System interfaces

2.1.1.1 Concept of Operations

Conan can be in any of the following states:

· Initialize – the user creates a player and starts the game.

· Dungeon: First room – the user has to reach the first room before he/she can continue, quit, save or win the game.

· If the door is locked; Conan cannot open the door without the key.

· Waiting – Conan may move and encounter enemies

· Player can quit or save the game.

· The user proceeds to the next room.

· Encounter – User begins a battle, if the user wins the battle continues. Otherwise the game is over.

2.1.2 User Interfaces

2.1.2.1 Introduction Window Concept

This is the Main menu for Conan. The user has the option to start a new game or load a saved game.

2.1.2.2 Select Difficulty Screen

Using this menu, the user chooses a difficulty. The user has the following options Easy, Medium or Hard.

2.1.2.3 Create new Character Window Concept

Using this menu, the user creates a new character.

2.1.2.4 Load Character Window Concept

Using this menu, the user loads a previously played character.

2.1.2.5 Dungeon Window Concept

This is the basic game screen. The game messages and dialog will appear at the bottom of the screen. The character attributes are in the top right corner, the inventory in the right middle and the action keys in the bottom right corner.

2.1.2.6 Select Stats Window Concept

This is the screen where the user chooses the initial attributes for his/her character.

2.1.2.7 Map Window Concept

This is the map screen showing a detailed layout of the dungeon. The map shows Conan’s position relative to the other rooms in the dungeon.

2.1.3 Hardware interfaces

A mouse and keyboard will be used.

2.1.4 Software Interfaces

Used to store data of individual areas.

2.1.5 Java Virtual Machine

Required to run the game.

2.1.6 Communications Interfaces

None, this is a single-player offline game.

2.1.7 Memory Constraints

The game is required to run on the Acadia Advantage laptops, so no more than 512MB of RAM will be used. The game content will use no more than 50 MB of hard drive space.

2.1.8 Operations

The user will be able to save and load the game.

2.1.9 Site Adaptation Requirements

None.

2.2 Product Functions

This section gives a brief explanation of the functionality of the game. Greater detail is given in Section 3.

2.2.1 “Creating a Character” Use Case

2.2.2 “Traveling to Adjacent Grid Location” Use Case

2.2.3 “Obtaining Item” Use Case

2.2.4 “Travel to New Location” Use Case

2.2.5 “Initiate Battle” Use Case

2.2.6 “Attack” Use Case

2.2.7 “Berserker” Use Case

2.2.8 “Use Item” Use Case

2.2.9 “Flee” Use Case

2.2.10 “Defend” Use Case

2.2.11 “Save” Use Case

2.2.12 “Load” Use Case

2.3 User Characteristics

This game is aimed towards young adults.

2.4 Constraints

· Deliverables must be received on time. No deliverable can be accepted before a previous deliverable has been received and approved.

· The entire project must cost no more than 35 man-days (at 8 hours/day).

· Must run on any Acadia Advantage laptop under Windows XP.

· Implemented in Java.

· Can be downloaded and installed from a web homepage.

2.5 Assumptions and Dependencies

· System assumes save files are valid and not tampered with.

· System assumes that XML room descriptions are valid.

2.6 Apportioning of Requirements

2.6.1 Basic Functional Requirements

F1- Each play of the game has a limited time frame.  The player can set this.

F2- Provides a castle with interconnected areas.

F3- There is one area from which the game begins

F4- Each area must have a name, a unique graphical image and its own set of no less than 3 environmental variables such as the number of monsters in the room, and type of monsters, the items in the room, etc.

F5- Each area has connections to one or more other areas.

F6- Areas contain monsters and items with which to interact with.

F7- Must allow the creation and maintenance of various game characters.  Each character has a unique name and image and a set of qualities such as life points, strength, defense (optional), attack rating, and attack power that can be assigned points by the player outside of battle. The system must allow the player to create these characters, define the qualities and select a character image.

F8- Must allow the main character to be designated.  The objective is to save the princess.

F9- No more than two characters can be at the same location in the room at one time

F10- When two characters meet at a position in the room they battle.

F11- Once battle is complete the main character, if s/he still exists and has the remaining qualities to do so, can move to a new location based on the player’s choice of direction. Moves deplete resources – so characters cannot simply just move for ever without having their qualities replenished in one form or another

F12- Must allow users to query for (and potentially print) a report of current character and area status by showing all quality and environmental variable values

F13- Must alert the player when main character quality values are reaching critical levels

F14- Must generate a game summary report showing overall performance through the game

F15- Must provide a method of saving and restoring the characters as a set.

F16- Should have a method of saving and restoring the current game state so that a game can be stopped and started at a later time.

F17- The above functions should be integrated as a single system that shares the appropriate data structures. Note that the use of a DBMS is possible but discouraged.

Plot Requirements

F18- “Conan: Rescue the Princess” (hereon referred to as the game). Is a fairly straightforward game largely described in the title.

F19- Conan (our main character) is sent to a run down castle to rescue a Princess.

F20- Conan must fight his way through several rooms to get to the princess, and have her follow him out again.

F21- In each room there is a key for the exit that is locked. Key disappears after use.

F22- Final Fantasy style top-down turn-based RPG.

F23- Enemies encountered randomly when a player moves, and a battle sequence is activated. The difficulty setting decides the number of enemies in a room. For each move the character makes there is a 'dice roll' and if the certain number hits the battle starts. For each move you make, the number on the 'dice' reduces by one so eventually you do get into a battle.

F24- While exploring the castle Conan will uncover chests, and other appropriate containers that will contain items.

F25- After completing 25% of the castle Conan will fight a boss, after defeating said boss the player is given some new armor and a new weapon.

F26- Before Conan rescues the princess he must fight the King of Swords. After defeating the King you receive his sword.

F27- After the King is defeated the Prince shows up and swears a vendetta (“you’ll never make it out alive”) and runs out of the castle.

F28- When Conan enters the next room on his way out (princess in tow) he encounters the captain of the guard – defeat the captain and get his armor.

F29- When the princess is with you she won’t be attacked very frequently (10% of the time) but the possibility is there. She is a healer (no offensive attacks, but able to issue potions to herself and Conan).

F30- After a battle experience is gained allowing Conan to raise his level. At the end of a battle there should be a chance to gain items as well. 1/4 chance of getting a potion and a 1/20 chance of gaining a revive token.

F31- If possible, there could be a 'boss key' in the game somewhere before the battle with the king. It could be in the first room in a less than obvious place or anywhere between the start and that chamber.

Character Requirements:

F32- Conan starts with a basic sword and armor.

F33- Conan has a simple sword attack that does damage to the enemy. He has a special berserker attack that he can use once per room. This attack hits the enemy up to 10 times in rapid succession.

F34- The game should track:

· Life Points

· Defense Rating (based on armor)

· Attack Accuracy

· Attack Power (Range of damage)

· Experience

· Level

Item Requirements

F35- Potion – restores 100% LP (One Time Use)

F36- Life Tokens – Bring you back to life if you die (beginning of the room).

F37- Keys – used to advance to the next room. (One Time Use)

F38- Swords – Three types (Basic, Master, King)

F39- Armor – Basic starting armor, master armor, Titan’s Chest (Captain of the Guards Armor), Helmet of Revive (Infinite life tokens), Ring of Agility (RARE ITEM, speeds up attack timer)

Map Requirements

F40- The castle is a series of rooms leading from the main entrance to where the princess is held. The path of rooms should be linear however the individual rooms should contain a maze.

F41- If the player enters a square that they have already passed through they may still encounter enemies.

F42- The castle could be designed in 2 parts with 2 paths one for in and one for out. It could also be that Conan has to go the same way he came in but against stronger monsters.

F43- Ideally the game should be written such that the maps can be adjusted easily. XML is a viable option to describe the rooms. It should be then possible to add levels to the game. (Optional Requirement)

F44- If possible, the map should start darkened over so the player has to explore the map. That way there is an increased chance of running into enemies while getting lost. Show a few blocks around Conan so he can navigate.

2.6.2 Human Interface Requirements

I1- Must be GUI based with efficient use of mouse point and click and menu features.

I2- Must be user friendly and encourage player/game setup and interaction by providing, at minimum:

I3- Cut and paste and document content copying where possible to reduce repetitive typing.

I4- Intelligent display and sequencing of queries and menus.

I5- User oriented error and warning messages.

I6- On-line help information.

I7- Optionally, allow certain aspects of displays and reports to be tailored (or personalized) to the individual user.

I8- Intelligent display and sequencing of queries and menus.

I9- User oriented error and warning messages.

I10- On-line help information.

I11- Optionally, allow certain aspects of displays and reports to be tailored (or personalized) to the individual user.

Movement Screen:

I12- Shows position on the grid.

I13- Shows the items in your bag, equipped items, level, life points, and experience.

Battle Screen:

I14- Shows player’s timer until next turn.

I15- On player’s turn a menu is presented giving options:

· Attack: This can be split into an attack submenu with attacks of various strength and accuracy, though a stronger attack should be less accurate.

· Defend: After rescuing the princess this will have a submenu asking whether you want Conan to defend himself, or the princess. Defend will decrease the damage done by an enemy attack by a percentage that increases as Conan levels.

· Item: Before rescuing the princess this will use the player’s entire turn, however after the princess is in tow selecting this will bring a submenu asking which character you want to be healed by the potion. The princess will administer the potion and Conan is still free to attack or defend afterward.

· Run: Flee from battle. The enemy you were facing will not regain Life Points, and will continue to roam the room

2.6.3 Undesirable Characteristics

U1- Lengthy user manual - focus on great on-line help and reference documentation as well as innovative "getting started" tutorial. Ask yourself, how would I like to learn how to use the system.

U2- Need for external components such as backup utility or DBMS that might have to be purchased by your customer (these issues can be discussed with your customer and TA).

2.6.4 Basic Non-functional Requirements

B1- Must run on any Acadia Advantage laptop under Windows XP.

B2- Is implemented in Java.

B3- Can be downloaded and installed from a web homepage.

2.6.5

Cost and Time Constraints

T1- Deliverables (by Customer and Supplier) must be received on time as per the course schedule for full marks. No deliverable can be accepted before a previous deliverable has been received and approved.

T2- The entire project must cost no more than 35 man-days (at 8 hours/day).

3. Specific Requirements

3.1 External interface requirements

3.1.1 User interfaces

The user interface in this game will be represented by multiple graphical windows. These windows include:

1) Title screen

2) Character Creation

3) Dungeon Window

4) Battle Window

3.1.1.1 Title Screen

This window shows the options to create a new character, load a previously saved character, or quit the game. Creation of a new character loads the character creation window. Loading a previously saved character loads the dungeon window. Quitting the game quits the game.

3.1.1.2 Character Creation

This window shows the options to enter the characters name, distribute the initial status points of the character to their attributes, and choose a graphical representation of the character. Clicking the create button will load the dungeon window and initialize the game.

3.1.1.3 Dungeon Window

This window will show the layout of the dungeon room, the stats of the character, the inventory of the character, the controls, and the message area. This is where the movement and exploring of the dungeon occurs. Upon the start of battle, the battle window is loaded.

3.1.1.4 Battle Window

This window will show the character and enemy graphics, the status of the character, the status of the enemy (optional), the possible actions the character may take, a message window to output the results, and the animations used to represent battle (optional). Upon victory, or defeat with life tokens remaining, the dungeon window will be loaded. Upon defeat with no life tokens remaining, the title screen will be loaded.

3.1.2 Hardware Interfaces

This game will support the use of a mouse and keyboard as input devices. The game will be developed to run on the Acadia laptop hardware.

3.1.3 Software Interfaces

This game will require the Java 1.5 runtime environment.

3.1.4 Communication Interfaces

Network connections will not be required for this game, as it is a single-player offline role playing game.

3.2 Classes/Objects

3.2.1 Character

3.2.1.1 Face

When the user creates a character, he/she will choose a face for that character.

3.2.1.2 Status Points

The created character will have a limited amount of user-chosen attributes that will characterize their player.

3.2.1.3 Attributes

Attributes are the permanent status points which each character possesses. These can be modified when the character levels up or when the character equips different armor or weapons, these stats will change.

3.2.1.4 Experience

If a character wins an encounter, they will gain a set number of experience points.

3.2.1.5 Level

The current level of the character depends on the amount of experience points earned.

3.2.1.6 Life Tokens

The amount of lives the character has. Each time the character dies he/she will lose a life token. When the amount of life tokens reaches zero, it’s game over.

3.2.2 Area

3.2.2.1 Room

A room is essentially an area containing a maze in which the character must proceed through to continue to the next room.

3.2.2.1.1 Maze

Each room is composed of a maze and each maze is different for each room.

3.2.2.2 Door

In order to proceed to the next room, the character must pass through a door. Some doors are locked and some are not. In the case where the door is locked, the character must provide a key and unlock the door. Different doors lead to different rooms.

3.2.2.3 Map

The map is an overview of the entire dungeon. It shows a graphical representation of the dungeon’s floor plan.

3.2.3 Encounter

3.2.3.1 Hostile Unit

A hostile unit the character will encounter in a room.

3.2.3.1.1 Enemy

The basic non-friendly units a character comes in contact with in a room. They become progressively more difficult as the user proceeds into the dungeon.

3.2.3.1.2 Boss

A significant encounter with a much stronger hostile unit.

3.2.4 Item

3.2.4.1 Room Key

The basic key required to open most doors

3.2.4.2 Boss Key

A special key used to open doors to rooms with bosses in them.

3.2.4.3 Treasure Chest

A chest containing items such as keys, potions or gear.

3.2.4.4 Gear

3.2.4.4.1 Weapon

An object such as a sword that increase the character’s attributes depending on the quality of the weapon. A high quality sword will increase the attributes higher than a low quality sword.

3.2.4.4.2 Armor

An object such as a vest or shield that increases the character’s attributes depending on the quality of the armor. A high quality shield will increase the attributes higher than a low quality shield.

3.2.4.5 Potion

A vial of liquid which a character can consume to restore HP (health). If a character is already at full health, the potion will not be consumed.

3.3 Performance Requirements

Upon initialization the game should load and be ready to commence the game within 30 seconds. No action in the game should take longer than 10 seconds to process.

3.4 Design Constraints

Conan must be written such that object oriented techniques are used allowing code reuse and extendibility in the case that future versions of Conan are built. Conan must utilize Java 1.5, and be able to be downloaded and played. Conan must be compatible with Windows XP.

3.5 Software System Attributes

3.5.1 Reliability

Conan should not fail more than once in 100 complete plays of the game. Whenever a problem is encountered a friendly error message should be shown.

3.5.2 Availability

Conan will be able to run on any Dell D620 laptop running Windows XP.

3.5.3 Security

There will be no password protected save files in this version of Conan.

3.5.4 Maintainability

All classes should be reusable for future versions of Conan and easily extendable.

3.6 Other Requirements

None.

4 Project Management Plan

4.1 Introduction

4.1.1 Project Overview

This project has been commissioned by Initech, Group B, to OutSource Inc, Group A. The project goal is to design and implement a role playing computer game named, “Conan: Rescue the Princess”. Initech is a well known leader for innovation in the video gaming industry and expects this project to maintain that respected image. The game revolves around the main character, Conan, who must battle his way through a castle to rescue the princess trapped inside and escape with her.

4.1.2 Project Deliverables

Please refer to Table 1: Project Schedule for deliverables and their due dates.

Deliverable

Description

Date

S1

Requirements, Specifications & Management Plan

February 4, 2007

S2

System Overview Presentation

February 27, 2007

S3

Detailed Design and Test Plan

March 8, 2007

S4

User Manual

March 20, 2007

S5

Project Demo, Game and Documentation

April 3, 2007

S6

Project Evaluation

April 9, 2007

Table 1: Project Schedule

4.1.3 Evolution Of The SPMP

This document shall be maintained on a weekly basis by the project leader, Mike Mallinson. It is subject to configuration management by means of the SCMP. It is the project leader's responsibility to submit this document as a CI, and to keep it up to date. This SPMP mainly follows the format of IEEE 1058.1-1987.

4.1.4 Reference Materials

- Braude, Eric J. SOFTWARE ENGINEERING: An Object Oriented Perspective [2001]

- Humphrey, Watts S. Introduction to Personal Software Process [2005]

- Robillard, P & Kruchten, P. Software Engineering Process with the UPEDU [2003]

4.1.5 Definitions And Acronyms

Please see the attached glossary in Appendix 1.

4.2 Project Organization

4.2.1 Process Model

An iterative development cycle will be used for this project. We will progress through the following four steps of development: requirements analysis, design, implementation and testing. Upon completion of these four steps the first project iteration will be complete. Optional features and any uncompleted desired features will be completed in future iterations.

4.2.2 Organizational Structure

The project roles are Project Manager, Lead Developer, Lead Designer, Lead Requirements Analysis, Lead Documenter, Webmaster and Lead Quality Assurance. These project roles have been distributed as shown in Figure 1: Conan: Rescue the Princess Project Organization. All documents will be closely reviewed and approved by all team members before submission.

4.2.3 Organizational Boundaries and Interfaces

The project team will interact with the course professor, Dr. Silver as well as the two teaching assistants for the course, Curtis McCarthy and Chad Schrader. Communication between OutSource Inc. and Initech will take place between the project managers, Mike Mallinson for Outsource Inc. and Andrew Marshall for Initech.

4.2.4 Project Responsibilities

The project responsibilities show who is charged with ensuring that a particular deliverable is complete on time and verifying it's quality. All team members will participate in completing each deliverable. Table 2: Project Responsibilities shows which team members is responsible for each deliverable.

Project Deliverable

Team Member Responsible

S1: Requirements, Specifications & Management Plan

Billy Logan

S2: System Overview Presentation

Mike Mallinson

S3: Detailed Design and Test Plan

Richard Peters

S4: User Manual

Billy Logan

S5: Project Demo, Game and Documentation

Richard Peters

S6: Project Evaluation

Mike Mallinson

Table 2: Project Responsibilities

4.3 Managerial Process

4.3.1 Managerial Objectives and Priorities

The main priority is to ensure that all the base requirements are completed. The next priority is to complete all deliverables by their specified due dates. The next priority is to ensure the quality of all deliverables is up to our standards. The final priority is to complete as many desirable and optional features as possible in the given time restraints.

4.3.2 Assumptions, Dependencies, and Constraints

The programming language Java has been selected for use in this project and as such we are dependent and constrained by Java.

4.3.3 Risk Management

Table 3: Risk Analysis and Retirement Plan shows currently identified risks and retirement plans as well as orders them based off likelihood and impact in the RBC column.

Risk #

Risk Title

Likelihood

(1 – 5)

Impact

(1 – 5)

RBC

Calculation

Retirement Plan

Person(s) Responsible

1

Unable to finish deliverables on schedule.

1

5

5

- Plan to finish deliverables days in advance of scheduled due date.

- Schedule time to complete each deliverable

Mike Mallinson

2

Deficient XML skills

3

3

6

- Allow time to learn XML

- Propose alternative for XML

Richard Peters

Table 3: Risk Analysis and Retirement Plan

4.3.4 Monitoring and Controlling Mechanisms

Weekly team meetings have been scheduled for Fridays from 12:30 PM until 1:30 PM. These meetings will be used for team status updates, designating new tasks and discussing any problems or risks. There is also team workshop sessions scheduled for each Tuesday evening from 6:00 PM – 7:30 PM.

4.3.5 Staffing Plan

Table 4: Staffing Plan shows the main responsibilities of each team member. This section does not limit team members to their particular responsibilities; all members are expected and will participate in each deliverable.

Team Member

Roles

Responsibilities

Richard Peters

Lead Designer

Lead Developer

- Design documentation deliverable

- Implementation deliverable

- Assigning tasks for design and implementation stages of development

Billy Logan

Lead Requirements Analysis

Lead Documenter

- Requirements analysis deliverable

- Assigning tasks for requirements analysis

- Ensuring documentation is complete

- Completion of the user manual

Mike Mallinson

Project Manager

Lead Quality Assurance

Webmaster

- Overview of team progress

- Assisting the team leader for each stage of development

- Quality assurance plan and system testing

- Creating and maintaining the team website.

Table 4: Staffing Plan

4.4 Technical Process

4.4.1 Methods, Tools, and Techniques

For this project we will be using Java 1.5 as our implementation language. We will follow the Sun coding style and use Javadoc to document our code.

4.4.2 Software Documentation

All supporting documentation will be provided including the generated Javadoc, a user manual, and copies of the requirements analysis and design documents.

4.4.3 Project Support Functions

None

4.5 Work Packages, Schedule, and Budget

4.5.1 Work Packages

Work will be divided among our team members by the project manager with assistance from the leader for each deliverable. All members will participate in each deliverable and perform the tasks assigned to them.

4.5.2 Dependencies

The progress of the project will depend on OutSource Inc completing each deliverable on schedule as well as Initech reviewing the submitted deliverables in a timely manner.

4.5.3 Resource Requirements

According to the provided outline by Initech we will require a team of three for this project. Each team member will require a Dell D620 Laptop.

4.5.4 Budget and Resource Allocation

The budget for this project allows for 35 man days at 8 hours per day. This time will be spread amongst all team members equally.

4.5.5 Schedule

Please refer to Table 1: Project Schedule for deliverable due dates.

Appendix A – Glossary of Terms

· Initech – the company which OutSource Inc. is creating the game Conan for.

· Life tokens – brings you back to life if you die. You revive at the beginning of the room.

· Game Over – the player has zero life tokens remaining. The character must restart the game to continue or load a game from a previously saved game.

· Stats – the user defined attributes that characterize their player.

· HP – Hit Points – the amount of health Conan has. 1 HP = 1 unit of health.

· Str - Strength – the amount of strength Conan has.

· Level – when a character reaches a specific limit of experience, it will level up. The number of times the character has leveled up is its level.

· Player character – the character created and controlled by the user.

· Monster – the basic enemies in the game.

· Encounter – any time Conan fights a monster, he experiences an encounter.

· Boss – An overly difficult encounter with a monster.

· Chest – treasure chest(s) which may be found in each room and may contain potions, weapons, or armor.

· Inventory – a place where Conan can hold items he finds in the dungeon.

· Map – a drawing showing the dungeon in detail.

Appendix B – Sequence Diagrams for Use Cases

· Creating a Character

· Traveling to Adjacent Grid Location

· Travel to New Location

· Obtaining Item

· Initiate Battle

· Attack

· Berserker

· Use Item

· Save Game

· Load Game

· Flee

Defend

Door is locked

Player dies

Player wins encounter

Player enters/exits room.

Player quits/ wins

Player starts game

Initialize

Waiting

Player moves

Player moves

Dungeon: First room

Waiting

Player finds dead-end

Encounter

Player doesn’t move OR

Player moves, door locked

User

:Room

:Game

1. Enter area

2. Change area

4. Display new area

3. Update

2. Enter Name

4. Choose attributes

User

: DisplayCharacter

mainCharacter

: Character

1. Create

3. Select Face

6. Click ‘Save’ Button

5b. Display

5a. Set fields

7. Click ‘Back to game’

8. Start Game

currentGame : Game

User

1. Enter room

2a. Create

5. Update

currentCharacter: Character

2. Pushes arrow(s)

3. Moves

:Game

currentRoom: Room

�

Figure � SEQ "Figure" \*Arabic �1�: Conan: Rescue the Princess Project Organization

5. Picks up item

4.Choose Item

User

: Item

currentGame

:Game

currentCharacter : Character

1.Steps on item/chest

2. Create

3. Display

7. Close

6. Item in inventory