Table of Contents
Introduction 2
Purpose of the system 2
Scope of the system 2
Major constraints 2
Definitions, acronyms, and abbreviations 2
Analysis Model 3
Use case 3
Use case model 3
Use case scenarios 4
Constraints 11
Assumptions and dependencies 12
Functional requirements 18
Requirements traceability matrix 19
Refinements 19
Appendix 19
Introduction
Purpose of the system
The purpose of our system is to allow from one to three players to play a game of Alien War. This will involve one user playing against the computer or multiple players playing against each other.
Scope of the system
Our system will consist of a video game developed with a graphical window interface. The system will be configured to allow one player to play against the computer. The option will also be made available for up to three players to play the game on multiple computers. There are three possible identifications for the players: the Earth, the Kranglons, and the Romulats.
In a one player game, the player is the Earth and the computer plays one of the alien vessels. In multiple player games, the players identifications will be determined by random selection. The alien spaceships and the Earth are divided into four sections. The alien players will determine which of these four sections represent their bridge, aft section, fore section, and the hold. The Earth player will determine which area will house the ground based lasers. In addition to ground based lasers, the Earth will have access to an undetectable satellite for alternative fire power.
The alien spaceships have 10,000 alien power units (APU) to allocate between their shields and their photon torpedoes. The Earth has 6,300 earth power units (EPU) to allocate between shields, satellite fire power, and ground based lasers. (1 EPU = 1 2/3 APU) The satellite EPU's must equal 1/10 the number given to the ground based lasers.
The game play begins when the first player selects their target. The destination of the shot (the section of the ship or Earth) and number of APU's or EPU's allocated must be determined. The target returns information to the enemy as to whether their shot was a hit or a miss. The alien firepower is accurate 50% of the time it fires at another alien ship and 25% accurate when firing against the Earth. The Earth's ground based lasers are 25% accurate when firing at the aliens. The satellite lasers are 50% accurate when firing. If the shot is a hit, the target's shields are diminished by a random percentage of the firepower allocated by the attacker.
The game continues in this manner until a player's shields have been reduced to zero. The player without shields remains active in the game until the enemy has determined the location of their hold. It will only take one APU to destroy the hold. The player may send a message of surrender at this time. The other players may accept the surrender or continue to fire on the ship and destroy it. (One additional hit will result in the ship blowing up.) Play continues until one player remains.
Major constraints
This system must work on Windows XP Pro. The system must have a graphical window interface. The final product must be submitted on May 3, 2004. The system must allow for a maximum of three players over multiple computers.
Definitions, acronyms, and abbreviations
EPU – Earth Power Unit – determined to be the unit of power available to the Earth for battle purposes
APU – Alien Power Unit – determined to be the unit of power available to the Alien Spaceships for battle purposes
Kranglons – one of the warring Alien races
Romulats – one of the warring Alien races
Peeps - players
Analysis Model
2.1 Use case
2.1.1 Use case model
2.1.2 Use case scenarios
Use case: Initialization |
ID: UC1 |
Actors: Player |
Preconditions: |
Flow of Events:
<initializeEarth> <initializeAlienShip(s)> |
Alternative Flow:
|
Postconditions:
|
Extension use case: Earth |
ID: UC2 |
Actors: Player |
Preconditions:
|
Flow of Events:
|
|
Postconditions:
|
Extension use case: Network |
ID: UC3 |
Actors: Player |
Preconditions:
|
Flow of Events:
|
Secondary Scenarios:
|
Postconditions: 1. Connection Established. |
Extension use case: Alien |
ID: UC4 |
Actors: Player |
Preconditions:
|
Flow of Events:
|
Postconditions:
|
Use case: Round Results |
ID: UC5 |
Actors: Player |
Preconditions:
|
Flow of Events:
|
Postconditions:
|
Use case: Game Results |
ID: UC6 |
Actors: Player |
Preconditions:
|
Flow of Events:
|
Postconditions:
|
Use case: StatsScreen |
ID: UC7 |
Actors: Player |
Preconditions:
|
Flow of Events:
|
Postconditions: |
Use case: MovConfig |
ID: UC8 |
Actors: Player |
Preconditions:
|
Flow of Events:
|
Postconditions: 1. The Player has decided all the elements necessary to make their move in the Battle. |
Use case: Battle |
ID: UC9 |
Actors: Player |
Preconditions: 1. The Player has selected the necessary options in UC8 to make their move. |
Flow of Events:
|
Postconditions:
|
2.2 Analysis class diagram
2.3 Interaction diagrams
The Sequence Diagrams for the Use Cases can be found below.
UC3
UC5
UC6
UC7
UC8
UC9
2.4 Functional requirements
RF1 The Alien War System shall provide a means of entertainment for users in a graphical user environment.
RF2 The Alien War System shall automatically initialize any combatant objects (Earth and/or Alien spaceships) that are not initialized by a human player.
RF3 The Alien War System shall display a startup menu with a choice for number of players.
RF4 The Alien War System shall display interactive initialization screens for all combatants initialized by human players.
RF5 The Alien War System shall display statistical information during game play for each player.
RF6 The Alien War System shall display round results after each player takes a turn.
RF7 The Alien War System shall control any non-human player during game play.
RF8 The Alien War System shall display game results when there is only one combatant left during game play.
RF9 The Alien War System shall allow all users the ability to leave the game at any time during game play.
RF10 The Alien War System shall allow all users the ability to make strategic moves when setting up for a round of Battle.
2.5 Requirements traceability matrix
|
UC1 |
UC2 |
UC3 |
UC4 |
UC5 |
UC6 |
UC7 |
UC8 |
UC9 |
---|---|---|---|---|---|---|---|---|---|
RF1 |
|
|
|
|
|
|
|
|
x |
RF2 |
|
|
|
x |
|
|
|
|
|
RF3 |
x |
|
|
|
|
|
|
|
|
RF4 |
|
x |
x |
|
|
|
|
|
|
RF5 |
|
|
|
|
|
|
x |
|
|
RF6 |
|
|
|
|
x |
|
|
|
|
RF7 |
|
|
|
|
|
|
|
x |
|
RF8 |
|
|
|
|
|
x |
|
|
|
RF9 |
x |
|
|
|
|
|
|
|
|
RF10 |
|
|
|
|
|
|
|
x |
|
3. Refinements
Networking has been added into the use case diagram.
Alternate Use Case #3, which accounted for errors of satellite power initialization, has been removed. Use Case #2 has been altered to automatically configure the remaining power options once the Player selects the ground laser power units.
Use Case #2 has been altered to add for the possibility of Earth being AI.
Use Case #4 has been modified to include the possibility that the one player does not want to be an alien.
The amount of shields to be diminished upon a successful attack has been changed to a random amount to allow for better odds of someone winning the game before their firepower is depleted.
The major constraints were altered to a final product being delivered as opposed to a prototype.
4. Appendix
Group Projects, Fries, Dr. T., February 2004.
Project Report – System Requirements Specification, Fries, T., February 2004.
System Requirements Specification, February 2004.
Project Report – Analysis Model, Fries, T., March 2004.