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 17

Requirements traceability matrix 18

Refinements 18

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.

      By default, In a one player game, the player is the Earth and the computer plays one of the alien vessels. If the one player chooses to play without the Earth, the battle will commence between the two alien races. 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



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.


Secondary Scenarios:

  1. TimedOut

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.



Use Case Changes

1. A secondary scenario was added to the MovConfig use case to allow for a timeout if the player fails to make a move within a five minute time frame.



    2.2 Design 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. The scope of the system was amended to include the possibility that the single player would opt to play without Earth.

      2. The class diagram was modified to include the Network class and various functions were added to the classes.

      3. In Use Case 1 sequence diagram, InitManager was changed to InitGUI and startup was altered as required for refined sequence diagrams.

      4. In Use Case 3 sequence diagram, NoPlayers() was changed to NumPlayer().

      5. In Use Case 2 sequence diagram, the ChooseHemi() and ChooseUnits() was omitted since it is part of the EarthInit() and should not be a separate task.

      6. In Use Case 4 sequence diagram, the ChooseHemi() and ChooseUnits() was omitted since it is part of the AlienInit() and should not be a separate task.

      7. In Use Case 5 sequence diagram, DisplayManager was added to show the GUI interface.

      8. In Use Case 6 sequence diagram, DisplayManager was added to show the GUI interface and :GameResults was changed to :Game. The p was changed to playersremaining to eliminate any possible confusion.

      9. Use Case 8 was amended to include a secondary scenario which results from a player not making a battle round selection within five minutes.

      10. In the Use Case 7 sequence diagram, the executeMove() was put into a loop so that it can account for up to three players playing the game.

      11. In the Use Case 8 sequence diagram, a DisplayManager() and PlayerManager() were added to account for the GUI interface.

      12. The class diagram was modified to include the Network class. Several operations and attributes were added to various classes in this diagram.



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.

      5. Analysis Model, March 2004.

      6. Project Report – Design Model, Fries, T., April 2004.

1