The following people use the use-case storyboards:
- user-interface designers, to build a model of the user
- designers of the boundary objects participating in the
use-case storyboard, to understand the objects' roles in the use cases and
how the objects interact. They use this information to design and implement
the boundary object (i.e., to construct the user interface);
- those who design the next version of the system to
understand how the system carries out the flow of events in terms of
boundary objects. For example, a change may affect a limited number of use
cases, in which case the designers need to see the realization of their flow
- those who test to test the system's use cases;
- the manager to plan and follow up the analysis &
of Events - Storyboard
high-level textual description of the interaction between the user and the
system during the use case. This description is augmented with usability
aspects of the use case to clarify and outline the allocation of usability
requirements onto boundary classes. This description can also be augmented
with boundary classes for further clarification.
value, of type "formatted text".
diagrams (sequence and collaboration diagrams) describing how the use case
is realized in terms of collaborating boundary objects and actors.
are owned via aggregation "behaviors".
diagrams describing the boundary classes and relationships that participate
in the realization of the use case.
are owned via aggregation "types" and "relationships".
textual description that collects all usability requirements on the use-case
storyboard that need to be taken care of during user-interface prototyping
and implementation. Examples are maximum execution time (e.g., how long it
should take a trained user to execute a scenario), and maximum error rate
(e.g. how many errors a trained user is allowed to make when executing a
value, of type "short text".
to the User-Interface Prototype
further clarify a use-case storyboard, it can refer to the parts (e.g.,
windows) of the user-interface prototype corresponding to its participating
value, of type "short text".
trace dependency to the use case in the use-case model that is storyboarded.
by the system via the aggregation "trace".
Use-case storyboards are produced as soon as their corresponding use cases
are prioritized to be considered from a usability perspective. Use-case
storyboarding is done before the user interface is prototyped and implemented
(i.e., both in the requirements discipline and in the analysis & design
A user-interface designer is responsible for the integrity of the use-case
storyboard, and ensures that:
- the Flow of Events - Storyboard is readable and suits its purpose;
- the diagrams describing the use-case storyboard are readable and suit
- the Usability Requirements are readable and suit their purpose, and that
they correctly captures the usability requirements of the corresponding use
case in the use-case model;
- the trace dependency to the corresponding use case in the use-case model
- the relationships, such as communicates-associations, include- and
extend-relationships, of the corresponding use case in the use-case model
are handled correctly within the use-case storyboard.
We recommend that the user-interface designer responsible for a use-case
storyboard is also responsible for the boundary classes and relationships
employed in the use-case storyboard.
Decide whether Use Case Storyboards are useful for your project. Tailor to support project needs. This may include
including only a subset of the sub-artifacts (properties), tailoring the level
of formality in which the sub-artifacts are created and managed, and tailoring
of the individual sub-artifacts. Document tailoring decisions in the Artifact:
© 1987 - 2001 Rational Software Corporation