Checklist: Scenario
This checklist provides guidance to ensure the quality and correctness of scenarios.
Relationships
Main Description
Scenarios may not visit  all states in all the participant objects nor activate all transitions, but they provide an order-dependent view of how the set of objects is expected to behave under some set of conditions with a specific ordering of external and internal stimuli.
Check Items
Does the sequence diagram have a mission statement?
Preconditions describe the starting point for the scenario execution and the assumptions being made. Post-conditions are things that are true after the end of the scenario, such as object states and values of variables. The pre- and post-conditions should be visible on the diagram; this is often done with a comment in the upper left- or right-hand corner of the diagram.
Does each use case have at least three scenarios?
A common use for a scenario is to describe a specific system-actor interaction performed while executing a use case. There should be no less than three such scenarios, although one or two dozen is more common. More than 50 might result in decomposing the use cases into smaller pieces.
Does each scenario have at least three messages?
Scenarios may be highly complex but some people err on the side of making the scenarios so trivial that they add no value. For example, a sequence diagram that shows a single message "TurnOn()" adds no value. In this case, either go into more detail about what turning on the system means or add this an a first step in a more complex scenario that initializes the system.
Does the scenario show a proper sequence of messages?
Are all sequence diagram operators not nested more than three deep?
UML 2.0 added sequence diagram operators. While they significantly improve the rigor of the diagrams, they are easily and often overused.
Do messages show parameter and return values?
To understand the specific scenario, it is often necessary to know the data being passed in or out of the services invoked by the messages.
Does the lifeline decomposition show the scenario at a deeper level of detail?
Lifeline decomposition is an addition in UML 2 that allows a scenario to be viewed at different levels of abstraction. Lifeline decomposition should be used to show how the internal parts of the element represented by the lifeline collaborate in the same scenario.
Is the ENV lifeline used to glue together scenarios at different levels of abstraction?
Since lifeline decomposition shows the same scenario at different levels of detail, there must be a means by which messages shown at the higher level enter into the lower level decomposed lifeline. This is done by creating the sequence diagram for the decomposed lifeline and using the ENV (environment) lifeline. Messages entering the lifeline in the higher-level scenario exit the ENV lifeline at the lower level. Messages leaving the lifeline in the higher-level scenario enter the ENV lifeline at the lower level.
Are Execution Occurrences used infrequently?
Execution occurrences are rectangles placed on the line to show the execution resulting from reception of an incoming message. These only make sense in strictly sequential flows but normally different lifelines may execute in different threads. Generally, the use of execution occurrences should be avoided.
Do the scenarios contain relevant quality of service constraints?
Messages, sets of messages, lifelines, and other elements should have quality of service constraints added as appropriate.
Is time used as an actor?
Time should be depicted as a messages-to-self on some lifeline. Time is not an executable element and is therefore not an actor. Occasionally, when using less capable tools to capture highly detailed design scenarios, you may use a timer as a lifeline and use it to initiate time-events. However, this should never be done in a scenario in the use case or PIM models.