Use Case Description

Instructions for Use Case Description

Name

Name of the use case EXACTLY as it appears on the use case diagram. Remember the name should be a verb or verb phrase with the first letter of each word in the name capitalized.

ID

The integer value assigned to the use case.

Requirement Number

The number of the functional requirement in section III of the SRS that this use case satisfies. This section provides traceability between the functional requirements and the individual use cases.

Description

Brief description of the general purpose of this use case.

Primary Actor

List the person or thing that starts or triggers the execution of the use case.

Secondary Actor(s)

List other persons or things who have an interest in the use case. For example, in the video rental system a secondary actor for entry of a new video was the video distributor's on-line database, which the video rental store's system queries to get information about a new video whose bar-code has been scanned in.

Preconditions

The necessary conditions that have to be met before the use case can be performed. When writing a precondition, you are making a simple assertion statement about the current state of the world when this use case opens. The mistake in writing preconditions is writing something that is often, but not always, true. Example of a pre-condition: "The customer has an account" or "The customer is already logged in."

Postconditions

The state of the system after the use case is performed. These statements state what interests are satisfied after a successful conclusion of the use case. For example, a value delivered to the actor.

Trigger

Specifies the event that gets the use case started. It precedes the first step of the normal scenario. Examples: "Customer inserts card" and "Customer calls in complaint." Do not confuse this with the precondition, which is a condition on the state(s) of the actor(s) and they system, before the triggering event.

Normal Scenario

Each path of execution through the use case is defined as a scenario. For every use case you will define a normal scenario which is the path that a user is mostly likely to follow. This normal scenario does not contain exceptions or alternative paths of execution. This normal scenario cannot be executed unless the pre-conditions are satisfied and needs to satisfy all requirements of post-conditions. Instructions for formatting this normal scenario are provided in the lecture on use case descriptions. The steps are numbered sequentially starting at 1. The first step should correspond to the triggering event.

Extensions

Extensions can be failures, exceptions, or alternative ways of accomplishing the primary scenario's goal. The extensions section will have multiple parts, one for each of the branches off the main scenario. Each of the branches will have one or more steps. Some banches will terminate the use case, and some will jump back into the main scenario. The numbering of the extensions should convey the step where the extension branches off from the main scenario, e.g., a branch that occurs as an alternative to step 5 would be numbered 5a, 5b, etc. Steps within an extensions are numbered also, e.g., 5a.1, 5a.2, etc.

For more instructions see the lecture notes on use case descriptions, and the examples.

Instructions for Actor Description

Name

Name of the actor exactly as it appears on the use case diagram. It must be a noun or noun phrase with the first letter of the name capitalized.

Alternate Name(s)

Alternative names this actor may be referred to in the application domain. Providing these names helps the readers to understand this document.

Input Data

List of the inputs to the system that this actor provides. This section must contain a list of the use cases with which this actor interacts (has a line on the use case diagram) and provides input. For each use case, list the inputs this actor provides.

Output Data

List of the outputs from the system that this actor receives. This section must contain a list of the use cases with which this actor interacts (has a line on the use case diagram) and receives output. For each use case, list the outputs this actor receives. Remember that every screen displayed to a user is an output, even if it only to acknowledge completion of an action.

Description

Brief description of the general purpose or role of this actor.

Comments

Any additional information that aid in the understanding of this actor.

Grading Criteria

1. Correctness
   1. Use Case Description
      1. Name does not match use case diagram
      2. ID does not match use case diagram
      3. Requirement number does not match functional requirement in Section III of the SRS.
      4. Description missing, incomplete, incorrect, or ambiguous.
      5. Pre-condition missing, incomplete, incorrect, or ambiguous.
      6. Post-condition - missing, incomplete, incorrect, or ambiguous.
      7. Trigger - missing, incomplete, incorrect, or ambiguous.
      8. Normal scenario - missing, incomplete, incorrect, or ambiguous.
         1. Scenario steps out of order
         2. An extension included in the normal scenario.
         3. Not underlying reused use cases.
         4. Steps written too granular (keystroke level)
         5. Steps written too broad (for example, rent video)
         6. Use of proper phrasing (for example, check whether vs. validate)
      9. Extensions - missing, incomplete, incorrect, or ambiguous.
         1. Extension steps out of order
         2. Extension numbering incorrect
         3. A normal scenario step included in the extension.
         4. Not underlying reused use cases.
         5. Extension written too granular (keystroke level)
         6. Extension written too broad (for example, rent video)
   2. Actor Description
      1. Name does not match use case diagram
      2. Actors missing or incorrect
      3. Obvious alternate names missing
      4. Input/Output data missing
      5. Input/Output data incorrect
      6. Description missing, incomplete, incorrect, or ambiguous.
2. Format
   1. Not written in required format as provided in instructions
      1. Not in the table format provided.
      2. Normal scenario steps not written in the specified format (for example, subject-verb-direct object)
      3. Extensions not written in the specified format (for example, missing colon)
   2. Misspelled words