Play the Brickles Game

Use Case ID:

{This field contains a document control number and will be tracked by the project. It is used to identify the owning team and the level of the use case. The use case id will be assigned by the project manager and the steering committee.}

Use Case Level S System end-to-end

{This field describes the scope of the functionality contained in the use case. It is later used to create a use case hierarchy structue. The level will be determined by the development team.}

Scenario:

{This field describes as completely as possible this particular use by providing additional information not contained in the following sub-sections..}

Actor: GamePlayer

{This field describes the role of the person or system performing this use.}

Pre-Conditions: The Brickles game is installed.

{This field describes how the system has been used in preparation for running this use case. It lists any previous requirements of the system related to this use case.}

Detailed Description:

{This field provides a detailed description of the use by providing additional information not contained in he following sub-sections. Each sub-section is explained below and should be completed as thoroughly as possible. Please do not repeat information contained within the sub-sections here in this description.}

Trigger:

{This field describes and lists what actions the user performs to initiate the use case and exactly how the system responds. Include any additional uses that would normally be invoked by this particular use.}

The user initiates an action by

Selecting the Brickles executible from the game directory.

The system responds by

Displaying the GameBoard in its initial condition.

Displaying a Puck at the designated starting point.

Starting the animation.

Post-conditions:

The GamePlayer will have won the game, lost the game, or exited prior to completion.The GamePlayer will have won the game, lost the game, or exited prior to completing the game.

{This field describes the state of the system following the successful completion of this use. Any additional affects on other systems or actors may also be described.}

The GamePlayer will have won the game, lost the game, or exited prior to completing the game.

Alternative Courses of Action:

{This field presents other Scenarios that are related to the main scenario listed above, but that differ in very small ways.}

Extensions:

{This field presents variations to this use case that could “specialize” it.}

Exceptions:

{This field describes all error conditions that can arise during the execution of this use case.}

The system aborts due to lack of memory.

Concurrent Uses: The Game is contained within a window. Other applications can run concurrently in their own independent windows.

{This field lists any other uses that can occur concurrently with the uses listed in this use case.}

The Game is contained in a window. Any other application can run in any other window.

Related Use Cases: There are a number of included use cases.

{This field contains references to use cases describing uses that are usually performed just before or just after the current use.}

There are a number of included use cases

External Supporting Information

Requirement Originator:

{This field contains the contact information for the person(s) who originated this particular use of the system. Please include the name, job title or description of work performed, address, telephone number, email address, and connection to this project for all persons listed.}

The owner of the product line.

Rational For Requirement:

Playing the Brickles Game is the fundamental requirement for the BricklesGame product.

{This field contains the rational given by the requirement originator as to why this particular requirement should be included in the system.}

Playing the Brickles game is one of the three major requirements in the product line.

Additional Relevant Requirements:

None{This field contains references to any other requirements documents or additional sources. If an industry standard document is related to or originates this requirement, that document will be listed here.}

None

Decision Support

Frequency:

High - This use case will be initiated every time the product is started.

{How often will this use of the system occur? Usually stated in terms of number of times per application execution, but can be stated in terms of number of times per hour of execution for always available systems. This field is combined with the criticality field to determine the number of tests that will be used to test the functionality. It may also be used in certain design decisions.}

Every time the product is used, this use case will be initiated.

Criticality:

High – If this use case fails the product is not useful.

{How necessary is this use to the successful functioning of the program from a user’s perspective. Its absence may not cause the system to crash, but it may prevent the user from accomplishing their goal. This field is used to assist in determining the extent to which the use will be tested.}

High – This use is the top-level requirement for one product. If it is not satisfied, there is no product.

Risk:

{The project risk associated with providing this use. This is used in project planning. Often riskier uses will be implemented early to provide sufficient recovery time.}

Low – This game has been implemented many times.

Modification History

Use Case Recorder: John D. McGregor

{This field is automatically filled in with the name of the person who is recording this use case. It can be deleted if incorrect and manually entered.}

Initiation Date: Monday, September 23, 2002

{This field is automatically filled in with the exact date and time this use case was initially recorded.}

Last Modified: XXX, XXX 00, 0000, at 0:00 AM by Melissa L. Major

{This field is automatically filled in with the last modified date and time and the persons name who made the modification.}