Guideline: Scenario
This guideline provides counsel on how to represent and use scenarios.
Relationships
Main Description

The best representation for a scenario is:

  • Sequence diagram, if the primary focus is on the sequence of messages and the interaction of multiple object roles
  • Timing diagram, if the primary focus is on the timing of events and when the object roles involved change states with respect to each other

Sequence diagrams are usually the best representation for most scenarios. Scenarios should contain:

  • A comment that describes:
    1. the use case the scenario describes
    2. the name of the scenario
    3. the purpose of the scenario
    4. an overview of the message flow
    5. pre- conditions
    6. post- conditions
  • At least 3 messages
  • Parameters on messages (operations or event receptions) and return values
  • Quality of service constraints
  • Textual comment describing why the scenario is unfolding as it is unfolding

When the same message flow exists for a set of values (e.g. fault conditions resulting in exactly the same behavior) then the scenario should describe the equivalent class for the scenario - that is, it should enumerate the list of values for which the scenario is valid, within a constraint.

When constructing a set of scenarios for a use case, each transition path in the use case state machine should be represented in at least once scenario. To come up with the minimal spanning set of scenarios, keep adding scenarios until all requirements bound to that use case are represented within at least one scenario. You may choose to add more scenarios if desired, but the minimal spanning set must be captured.