View this PageEdit this PageUploads to this PageHistory of this PageHomeRecent ChangesSearchHelp Guide

Detailed Use Case Specifications

Detailed Use Case Specifications

from Jacobson, et al., The Unified Software Development Process

1. Structure the Use-Case Description

(page 155)

Use Cases are structured by describing the state transitions in a simple and precise manner.

  • Begin by stating the preconditions (start state) and postconditions (end state) of the use case.
  • Then choose a complete basic path from the start state to the end state and describe that path.
  • Return to each state and determine whether there are alternate paths that should be described. Alternatives, deviations, or exceptions may result from the following:

    • Actor may choose to take a different path through the use case.
    • A system with multiple actors may have behaviors where actions of one influences another.
    • The system may detect input errors from the actor.
    • System resources may malfunction creating an internal error condition.

Use Case Descriptions must include the following (from page 157).

  • Define the start state as a precondition

  • How and when the use case starts (i.e. the first action to perform).

  • The required order (if any) in which actions must be performed. The order should be defined by the numbered sequence.

  • How and when the use case ends.

  • A use-case description should define the possible end states as postconditions.

  • If the use case has alternative paths, the use case must include:

  • Paths of execution that are not allowed.

  • Alternative path descriptions that are inlined in the basic path description.

  • Alternative path descriptions that have been extracted from the basic path description.

  • Lastly, in regards to the elements of the system in the use case, the use case case must describe:

  • System interaction with the actors and what they exchange.

  • Usage of objects, values, and resources in the system. i.e. The use case has described the sequence of actions and has assigned values to the use-case attributes.

  • What the system does (the actions it performs) and what the actor does. This should be explicitly described to distinguish system responsibilities from actor responsibilities or else the use-case description won't be prescise enough to use as a system specification.

2. Formalize the Use-Case Description

(page 159)

Formalizing the use-case descriptions involves constructing different state diagrams. This is not needed for small sets of states but should definitely used for complex use cases to help the system analyist. These use cases and their functions include:

  • UML statechart diagrams can be used to describe the states of the use case and the transitions between those states.
  • Activity diagrams can be used to describe the transitions between the states in more detail as sequence of actions.
  • Interaction diagrams can be used to describe how an instance of a use case interacts with an instance of an actor.