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



  1. Introduction

    1. 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.

    2. 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.

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

    4. 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

  2. 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:

  1. This use case begins when the Player runs the "Alien War" program.

  2. The system begins the process of loading needed information to run the program.

  3. The system loads modules needed to display the graphical user interface.

  4. The system constructs all event handlers and adds them to the system.

  5. The system loads all image and sound files.

  6. The system displays graphical user interface.

  7. The system displays startup screen and menu which includes option for number of players (limit 3 players).

  8. Player chooses number of players.

  9. If one player is chosen

    1. Player plays as the Earth by default, unless Player opts to play an alien.

  10. Else Players are randomly assigned roles by the system.

<initializeEarth>

<initializeAlienShip(s)>

Alternative Flow:

  1. The Player can leave the system at anytime once the menu has been displayed.

Postconditions:

  1. The application is initialized, players have been chosen, and game is ready to be played.




Extension use case: Earth

ID: UC2

Actors:

Player

Preconditions:

  1. The number of players has been chosen.

Flow of Events:

  1. This use case starts after number of players has been chosen.

  2. The system displays an Earth Initialization screen.

  3. The system will display which player was chosen to play the Earth.

  4. The Player determines which hemisphere to place the Earth's ground based lasers.

  5. The Player enters values for ground based laser power units.

  6. The System determines the shield power units and satellite laser power units based on the given ground based laser power units.

  7. The Player confirms selections.


Postconditions:

  1. The Earth and its components have been initialized.



Extension use case: Network

ID: UC3

Actors:

Player

Preconditions:

  1. Game has been initialized.

Flow of Events:

  1. This use case begins after the game has been initialized.

  2. If one Player is chosen

    1. The System will establish a local host connection.

  3. Else, If Player chooses to be Host

    1. The System will establish a host connection.

    2. The System will listen for additional connections.

    3. The System will send acknowledgements of connections as required.

  4. Else, If Player chooses to be Client

    1. The System will request a host ID.

    2. The System will request a port number.

    3. The Player will input the requested information.

    4. The System will verify input and test the connection.

    5. The System will establish the connection.

    6. The System will receive the acknowledgement from the host.

Secondary Scenarios:

  1. invalidHostID

  2. invalidPortNo

  3. LostConnection

Postconditions:

1. Connection Established.


Extension use case: Alien

ID: UC4

Actors:

Player

Preconditions:

  1. The number of players has been chosen.

Flow of Events:

  1. This use case starts after number of players has been chosen.

  2. If one player is chosen and player is not an alien

    1. The system will carefully choose the values for the power units using sophisticated AI.

  3. Else

    1. For each player chosen to be an alien spaceship

      1. The system displays an Alien Initialization Screen.

      2. The Player selects which sections of the spaceship will be designated as bridge, aft, fore, and the hold.

      3. The Player will allocate power units to the spaceships shields and firepower.

      4. The Player confirms selections.

Postconditions:

  1. The Alien spaceship(s) have been initialized.



Use case: Round Results

ID: UC5

Actors:

Player

Preconditions:

  1. Each Player has had a chance to attack.

Flow of Events:

  1. This use case begins after each Player has had a chance to attack another Player.

  2. The system displays a screen showing game play statistics during that particular round of game play.

Postconditions:

  1. New round begins.



Use case: Game Results

ID: UC6

Actors:

Player

Preconditions:

  1. One Player remains.

Flow of Events:

  1. This use case begins when only one Player is left.

  2. The system displays a screen congratulating the winner.

  3. The system displays a screen with all Players scores.

  4. The system displays "Game Over."

  5. The system displays production credits.

Postconditions:

  1. Game Over.



Use case: StatsScreen

ID: UC7

Actors:

Player

Preconditions:

  1. Game has been initialized.

Flow of Events:

  1. The use case begins when a Player makes a move.

  2. The system displays whether or not the move resulted in a hit or a miss.

  3. The system displays the number of power units available for the given Player.


Postconditions:


Use case: MovConfig

ID: UC8

Actors:

Player

Preconditions:

  1. The Player is still part of the game and has power units remaining to use.

  2. The Player is not the only player remaining in the game.

Flow of Events:

  1. The use case begins when it is a player's turn to make a move.

  2. If the Player is human

    2.1 The Player selects their target.

    2.2 The Player determines the amount of firepower to allocate to the shot.

    2.3 The Player determines which area of the target it will direct its shot toward.

  3. Else, the system will use AI to determine the move for its designated Alien spaceship.

  4. The system records the information obtained about the requested move.


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:

  1. The system implements the move requested by the Player in use case 8.

  2. The system makes the determination about whether the shot was a hit or a miss using the predetermined random percentage.

  3. If the system determines the move was a hit

    3.1 The system calculates the decrease in the shield power for the Player who has been hit.

  4. The system records the information until each player has attacked and the Round ends.

Postconditions:

  1. The RoundResults have access to the record of whether the shot was a hit or a miss.

  2. If the shot was a hit, the RoundResults have access to the amount of damage done to the shield to display to the Player who has been hit.


    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

      1. Networking has been added into the use case diagram.

      2. 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.

      3. Use Case #2 has been altered to add for the possibility of Earth being AI.

      4. Use Case #4 has been modified to include the possibility that the one player does not want to be an alien.

      5. 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.

      6. The major constraints were altered to a final product being delivered as opposed to a prototype.


4. Appendix

      1. Group Projects, Fries, Dr. T., February 2004.

      2. Project Report – System Requirements Specification, Fries, T., February 2004.

      3. System Requirements Specification, February 2004.

      4. Project Report – Analysis Model, Fries, T., March 2004.

18