Arcade Game Maker Pedagogical Product Line: Requirements Model
| Revision Control Table | ||||
| Version Number | Date Revised | D-Delete, M-Modify |
Description of Change | Person Responsible |
| 1.0 | 7/03 | A | Created document | JDMcGregor |
| 2.0 | 6/04 | M | Responded to review comments | JDMcGregor |
| 3.0 | 4/05 | M | Edited document | KERiley |
Overview
This is the requirements document for the Arcade Game Maker (AGM) product line. Its purpose is to provide the specifications for the products that will be built as part of the product line.
Identification
The AGM product line will produce a series of arcade games. Each game is a one-player game in which the player controls, to some degree, the moving objects. The objective is to score points by hitting stationary obstacles. The games range from low obstacle count to high and will be available on a variety of platforms.
Document Map
The AGM product line is described in a series of documents that are related as shown in the following figure. This interactive map shows the order in which the documents should be read for the first time. After readers are familiar with the documents, they can go directly to the information needed.
Document Map
Concepts
For definitions of basic concepts, see Arcade Game Maker Pedagogical Product Line: Acronym List/Glossary.
Reusable Components
This document establishes the high-level context for work in the product line. In a product line, components are designed to be reusable within the product line's context. That is, no attempt is made to make a component "as general as possible." Each design decision is made with regard to the extent of the products in the product line. The architecture further refines the context defined in this document.
Readership
This document is intended to provide some level of information to all stakeholders in the AGM framework. Managers will find information to support product planning. Product line analysts will find information to support commonality and variability analysis. Product developers will find the rationale for each product's membership in the product line.
Use Case Model
The following figure provides an overview of the use cases for the AGM product line.
Use Case Diagram
| Use Cases |
| AGM001 - Play selected game |
| AGM002 - Exit game |
| AGM003 - Save game (change case) |
| AGM004 - Save score (change case) |
| AGM005 - Check previous best score (change case) |
| AGM006 - Play Brickles |
| AGM007 - Play Pong |
| AGM008 - Play Bowling |
| AGM009 - Initialization |
| AGM010 - Animation loop |
| AGM011 - Install game |
| AGM012 - Uninstall game |
Additional use case details are located at the end of this page.
Domain Model
Before specific requirements were identified, a domain analysis (see following figure) was conducted to identify essential concepts. These concepts form the basic vocabulary that describes the use cases and the commonality and variability analysis.
Domain Model in UML
Commonality and Variability Analysis
Overview
In a product line, the commonality and variability analysis covers a set of products rather than a single one. In this section, we document what is common among products in the AGM product line.
Definitions
Sprite. From some of the earliest days of computer-based games, the elements that players see and interact with on screen have been referred to as Sprites.
Rule. Game play and operation is governed by rules. For example, a game may have a rule that a moving sprite that strikes a stationary sprite obeys the laws of classical mechanics. Games also have rules about scoring.
Commonalities
- Every game will have a set of Sprites.
- Every game has a set of rules.
- All the games involve motion.
Variations
Rules. This is the biggest variation amongst games. Some of the rules relate to basic physical laws (e.g., gravity or elastic collisions) and may be applicable to multiple games. Other rules relate to the specifics of a game and can be used in all implementations of that game, but they don't apply to other games.
Motion initiation. In some games, motion is inherent in the operation of the game. It happens periodically and is driven by time. In other games, the player selects and initiates motion. It is driven by the player's actions.
Parameters of Variation
Parameters are defined at several levels to provide the maximum variation among products. The set of Sprites that make up a game can be varied to enhance or change the game. In Brickles, for example, different types of bricks can be defined to exhibit different types of behavior during a collision.
Issues
- What is the scope within which a variation is constant?
- Should parameterized units be saved as assets, or should they always be built up for each product?
Scenarios
- The developer is assigned to build a new product that incorporates a previously implemented game. Many assets will be available.
- The developer is assigned to build a new product that incorporates a game that has not been implemented before. Some assets are available because some of the physical rules are the same as in other previously implemented games. Scoring rules will have to be constructed from scratch.
Feature Model
The figures in this section present the results of the feature-oriented domain analysis (FODA) for the arcade game domain.
Top-Level of Feature Analysis
Continuation of Feature Analysis
Feature Analysis of the Services Feature
Nonfunctional Requirements
This section describes requirements that do not lend themselves to use cases.
System Operational Requirements
Performance
The action of the game must be fast enough to seem continuous to the user. There should be no blurring of the graphics. Research in human computer interface has shown that such fast action requires a refresh every tenth of a second.
Display Quality
The colors chosen for the games must be such that one element's color does not impair the user's view of another element. No provision will be made for color blindness since the games seldom have similarly shaped game pieces that differ only by color.
System Development Requirements
Evolvability
The assets used in the first increment will be the basis for the products in the next two increments. For the second increment, one programmer must be able to modify first increment assets in less than a week and the architecture in less than two weeks.
Maintainability
Some of the core assets will age as new environments are being deployed. Assets must be maintained with the components with which they interact. For a new release of the environment, one experienced systems programmer must be able to integrate the assets in three days.
Attached Processes1
Building the Requirements Model
AGM will use the requirements modeling technique defined by Chastek and colleagues [Chastek 01] and shown in the following figure. Since this technique is for a product line, each activity refers to all AGM products.
Building a Requirements Model
Modifying the Requirements Model
The requirements model will evolve over time as requirements are added, deleted, modified from a change case to a current requirement, or modified to change the scope of the requirement. Each time a requirement is added or deleted, the person making the change must check the model for consistency, correctness, and completeness as shown in the next figure.
Process Flow for Adding or Deleting a Requirement
References and Further Reading
For details about the references cited in this document, see Arcade Game Maker Pedagogical Product Line: Bibliography.
Use Cases
Play Selected Game
Use Case ID: AGM001
Use Case Level: Abstract
Scenario
Actor: GamePlayer or GameInstaller
Preconditions: AGM011: Install game has completed successfully.
Detailed Description
Trigger: Actor selects game executable and initiates execution.
Actor System Response Selects PLAY from the menu Initializes the game and displays the gameboard Left-clicks to begin play Starts game action Left-clicks or uses keyboard to enter commands Responds to the command in the expected manner Responds to Won/Lost/Tied dialog box with left-click Returns the gameboard to its initialized, ready-to-play state Postconditions: Actor has won/lost/tied and the game is ready to play again.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| At any time, may select EXIT from the menu | See AGM002: Exit game |
Extensions
List:
| Actor | System Response |
| See AGM006: Play Brickles | |
| See AGM007: Play Pong | |
| See AGM008: Play Bowling | |
Exceptions
List:
| Actor | System Response |
| N/A | N/A |
Concurrent Uses: N/A
Related Use Cases: AGM002: Exit game
External Supporting Information
Requirement Originator: Domain analyst
Rationale for Requirement: Main purpose of the program
Additional Relevant Requirements: N/A
Decision Support
Frequency: On demand
Criticality: High
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM002
Use Case Level: System end-to-end
Scenario
Actor: GamePlayer or GameInstaller
Preconditions: Game system is running.
Detailed Description
Trigger:
Actor System Response Selects EXIT from system menu Prompts actor to save or exit the game Saves game Saves the game and exits the program Postconditions: Game system is terminated.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| Cancels the EXIT action | Returns to suspended action |
No. 2:
| Actor | System Response |
| May initiate EXIT by left-clicking the upper right-hand corner of the game window | Prompts actor to save or exit the game |
| Saves game | Saves the game and exits the program |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| N/A | N/A |
Concurrent Uses: N/A
Related Use Cases: AGM001: Play selected game
External Supporting Information
Requirement Originator: Product planning
Rationale for Requirement: Usual action for an interactive program
Additional Relevant Requirements: N/A
Decision Support
Frequency: Low - only once per game start-up
Criticality: Low
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM003
Use Case Level: System end-to-end
Scenario
Actor: GamePlayer or GameInstaller
Preconditions: Game executable is running, and a game has been started.
Detailed Description
Trigger:
Actor System Response Selects the SAVE option in the system menu Allows the actor to specify a filename Writes game data to the file Returns to the game's pre-SAVE status Postconditions: Current state of the game has been written to the specified file OR action has been cancelled.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| Selects the EXIT menu option | See AGM002: Exit game |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| Selects the SAVE option in the system menu | Prompts the actor to specify a filename |
| Raises exception because the disk is full | |
| Selects a different disk | Attempts to save again |
| Identifies an existing file with the same name as specified in the Save dialog | |
| Raises ExistingFileException | |
| Chooses a different name OR Agrees to overwrite the existing file |
Writes the file |
Concurrent Uses: N/A
Related Use Cases: AGM002: Exit game
External Supporting Information
Requirement Originator: Product planning
Rationale for Requirement: Convenience feature for users
Additional Relevant Requirements: N/A
Decision Support
Frequency: On demand
Criticality: Medium
Risk: Medium - other files might be corrupted.
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM004
Use Case Level: System end-to-end
Scenario
Actor: GamePlayer
Preconditions: Game system is running and a game is in progress
Detailed Description
Trigger:
Actor System Response Selects SAVE SCORE from system menu Prompts actor to specify a filename If the file does not exist, creates new file Writes score to the file Returns to the game's pre-SAVE status Postconditions: File has been written, or action has been cancelled
Alternative Courses of Action
No. 1:
| Actor | System Response |
| Selects SAVE SCORE from system menu | Prompts actor to specify a filename |
| If the file exists, overwrites existing
score Else creates new file and writes score |
|
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| Selects the SAVE SCORE option in the system menu | Prompts actor to specify a filename |
| Raises exception because the disk is full | |
| Selects a different disk, if available | Attempts to save again |
Concurrent Uses: N/A
Related Use Cases: AGM005: Check previous best score (change case)
External Supporting Information
Requirement Originator: John D. McGregor
Rationale for Requirement: To motivate the user
Additional Relevant Requirements: N/A
Decision Support
Frequency: On demand
Criticality: Medium
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Check Previous Best Score (Change Case)
Use Case ID: AGM005
Use Case Level: System end-to-end
Scenario
Actor: GamePlayer
Preconditions: Game system is running.
Detailed Description
Trigger:
Actor System Response Selects Check Previous Best Score Prompts actor to specify a filename Reads the file and returns score in a dialog box Selects OK on dialog box to continue Returns to state before select Postconditions: Stored score has been shown to actor.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| N/A | N/A |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| Selects Check Previous Best Score | Prompts actor to specify a filename |
| Finds that file does not exist | |
| Selects OK on dialog box to continue | Returns to state before select |
Concurrent Uses: N/A
Related Use Cases: AGM004: Save score
External Supporting Information
Requirement Originator: Product planning
Rationale for Requirement: Motivating feature
Additional Relevant Requirements: N/A
Decision Support
Frequency: On demand
Criticality: Medium
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM006
Use Case Level: System end-to-end
Scenario
Actor: GamePlayer or GameInstaller
Preconditions: AGM011: Install game has completed successfully.
Detailed Description
Trigger:
Actor System Response Selects PLAY from the menu Initializes the game and displays the gameboard Left-clicks to begin play Starts game action Left-clicks or uses the keyboard to enter commands Moves the paddle horizontally to follow the mouse track
After each movement of the puck, system checks for a collision with another object.
If puck collides with the ceiling, it is reflected back into the playing area.
If the puck collides with a wall, it is reflected back into the playing area.
If the puck collides with the floor, it ceases to exist. If the maximum number of pucks has not been reached, requests and provides a new puck. If the maximum has been reached, the Lost dialog is presented.
If the puck collides with a brick, defines action by the type of brick. When the puck collides with the last brick, the Won dialog is presented.Responds to Won/Lost dialog box with left-click Returns the gameboard to its initialized, ready-to-play state Postconditions: Game has been played
Alternative Courses of Action
No. 1:
| Actor | System Response |
| N/A | N/A |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| N/A | N/A |
Concurrent Uses: N/A
Related Use Cases: N/A
External Supporting Information
Requirement Originator: Product planning
Rationale for Requirement: Main action for one of the products
Additional Relevant Requirements: N/A
Decision Support
Frequency: On demand
Criticality: High
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM007
Use Case Level: System end-to-end
Scenario
Actor: GamePlayer or GameInstaller
Preconditions: AGM011: Install game has completed successfully.
Detailed Description
Trigger:
Actor System Response Selects PLAY from the menu Initializes the game and displays the gameboard Left-clicks to begin play Starts game action Postconditions: Game has been played.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| N/A | N/A |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| N/A | N/A |
Concurrent Uses: N/A
Related Use Cases: N/A
External Supporting Information
Requirement Originator: Product planner
Rationale for Requirement: Main action of one of the products
Additional Relevant Requirements: N/A
Decision Support
Frequency: On demand
Criticality: High
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM008
Use Case Level: System end-to-end
Scenario
Actor: GamePlayer or GameInstaller
Preconditions: AGM011: Install game has completed successfully.
Detailed Description
Trigger:
Actor System Response Selects PLAY from the menu Initializes the game and displays the gameboard Left-click to begin play Starts game action Repeat the following for 10 frames plus a bonus throw Positions the mouse and left-clicks to send ball down alley Moves the ball down the alley using a randomly selected algorithm. If collisions result when the ball reaches the pins, moves pins as determined by the physics of the collision. Counts number of pins knocked down Positions the mouse and left-clicks to send ball down alley Moves the ball down the alley using a randomly selected algorithm. If collisions result when the ball reaches the pins, moves pins as determined by the physics of the collision Computes score Postconditions: Game has been played.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| N/A | N/A |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| N/A | N/A |
Concurrent Uses: N/A
Related Use Cases: N/A
External Supporting Information
Requirement Originator: Product planning
Rationale for Requirement: Main action of one of the products
Additional Relevant Requirements: N/A
Decision Support
Frequency: On demand
Criticality: High
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM009
Use Case Level: Function sub-use case
Scenario
Actor: N/A
Preconditions: AGM006: Play Brickles, AGM007: Play Pong, or AGM008: Play Bowling has begun operation.
Detailed Description
Trigger:
Actor System Response Creates the standard instances of the required classes Enters the READY state Postconditions: Game is ready to operate.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| N/A | N/A |
Extensions
List:
| Actor | System Response |
| Selects Load Game from the menu | Presents a file chooser box |
| Opens the file that is indicated | |
| Reads and constructs the game objects |
Exceptions
List:
| Actor | System Response |
| Runs out of memory while creating objects | |
| Displays the Error dialog box | |
| Destroys objects already created |
Concurrent Uses: N/A
Related Use Cases: N/A
External Supporting Information
Requirement Originator: System engineer
Rationale for Requirement: Natural module within the program
Additional Relevant Requirements: N/A
Decision Support
Frequency: Once per game start-up
Criticality: High
Risk: Medium
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM010
Use Case Level: Functional sub-use case
Scenario
Actor: N/A
Preconditions: AGM009: Initialization has operated successfully and the user has left-clicked.
Detailed Description
Trigger:
Actor System Response Generates periodic signals and sends them to the game Moves all objects one step according to their movement algorithm Checks for collisions and executes the collision algorithms of the objects Postconditions: Game is completed.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| Holds down the left mouse button | Pauses the movement of the game |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| N/A | N/A |
Concurrent Uses: N/A
Related Use Cases: N/A
External Supporting Information
Requirement Originator: System engineer
Rationale for Requirement: Main action sequence in a game (standard in all products)
Additional Relevant Requirements: N/A
Decision Support
Frequency: Once for every playing of the game
Criticality: High
Risk: Medium
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM011
Use Case Level: System end-to-end
Scenario
Actor: GameInstaller
Preconditions: N/A
Detailed Description
Trigger:
Actor System Response Selects the installer executable to execute Presents a file chooser to allow selection of a directory in which to place the game files Selects a directory Places game files in the directory Postconditions: Game is installed.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| N/A | N/A |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| Finds insufficient space to which to write files | |
| Displays the Out of Space dialog box | |
| Left-clicks on OK button | Exits the program |
Concurrent Uses: N/A
Related Use Cases: AGM012: Uninstall Game
External Supporting Information
Requirement Originator: Product planning
Rationale for Requirement: Necessary to get game operational
Additional Relevant Requirements: N/A
Decision Support
Frequency: Very seldom
Criticality: High
Risk: Low
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Use Case ID: AGM012
Use Case Level: System end-to-end
Scenario
Actor: GameInstaller
Preconditions: AGM011: Install game completed successfully.
Detailed Description
Trigger:
Actor System Response Selects UNINSTALL from the system menu Presents a file chooser to the actor Selects directory where game is stored Erases files in the directory Presents the Uninstall Completed dialog box Selects the OK button in the dialog box Closes dialog box Postconditions: All disk space taken up by the game is reclaimed.
Alternative Courses of Action
No. 1:
| Actor | System Response |
| N/A | N/A |
Extensions
List:
| Actor | System Response |
| N/A | N/A |
Exceptions
List:
| Actor | System Response |
| N/A | N/A |
Concurrent Uses: N/A
Related Use Cases: AGM011: Install game
External Supporting Information
Requirement Originator: Product planning
Rationale for Requirement: Feature of the product
Additional Relevant Requirements: N/A
Decision Support
Frequency: Very seldom
Criticality: Low - can be done manually
Risk: Medium - might erase the wrong files
Modification History
Use Case Recorder: John D. McGregor
Initiation Date: Monday, April 04, 2005, at 1:38 PM
Last Modified: Tuesday, July 25, 2006, at 12:16 PM by Barbara White
Appendix B: Actor Profiles
GamePlayer
Abstract: No
Description: Usual, frequent user of game
Skill Level: Medium
| Actor's Perspective on Use Cases | |||
| Use Case | Importance2 | Personality3 | Relative Frequency4 |
| AGM001: Play selected game | Primary | Initiator | High |
| AGM002: Exit game | Secondary | Initiator | Low |
| AGM003: Save game (change case) | Secondary | Initiator | Medium |
| AGM004: Save score (change case) | Secondary | Initiator | Low |
| AGM005: Check previous best score (change case) | Secondary | Initiator | Low |
| AGM006: Play Brickles | Secondary | Initiator | High |
| AGM007: Play Pong | Secondary | Initiator | High |
| AGM008: Play Bowling | Secondary | Initiator | High |
GameInstaller
Abstract: No
Description: Installer of game, infrequent user
Skill Level: High
| Actor's Perspective on Use Cases | |||
| Use Case | Importance2 | Personality3 | Relative Frequency4 |
| AGM002: Exit game | Secondary | Initiator | Low |
| AGM003: Save game (change case) | Secondary | Initiator | Low |
| AGM004: Save score (change case) | Secondary | Initiator | Low |
| AGM005: Check previous best score (change case) | Secondary | Initiator | Low |
| AGM006: Play Brickles | Secondary | Initiator | Low |
| AGM007: Play Pong | Secondary | Initiator | Low |
| AGM008: Play Bowling | Secondary | Initiator | Low |
| AGM011: Install game | Primary | Initiator | Low |
| AGM012: Uninstall game | Primary | Initiator | Low |
| Rank is primary or secondary.
Personality is initiator, server, receiver, or facilitator. Relative Frequency is high, medium, or low. |
|||
1 This section is the
"attached process" described by Clements and Northrop [Clements 02]. For the product line
requirements model, this process defines how the requirements model is
initially built. The process focuses mainly on modifying the requirements model
of the product line to represent one particular product.
2
Importance is primary or secondary.
3 Personality is initiator,
server, receiver, or facilitator.
4 Relative Frequency is high,
medium, or low.
