 |
| This artifact is a logical and conceptual description of system functionality for a specific scenario, including the interaction required between the system users and the system. A Storyboard "tells a specific story". |
|
Purpose
|
The following people use Storyboards:
-
system analysts, to explore, clarify, and capture the behavioral interaction envisioned by the user as part
of requirements elicitation.
-
user-interface designers, to design the user interface and to build a prototype of the user interface;
-
designers of the classes that provide the user interface functionality; They use this information to
understand the system's interactions with the user, so they can properly design the classes that will implement the
user interface;
-
those who design the next version of the system to understand how the system carries out the flow of events;
-
those who test to test the system's features;
-
the manager to plan and follow up the analysis & design work.
It is important to remember that the main purpose of Storyboards is to understand overall flow and interactions, not to
prototype or test the look and feel of the user interface. The Storyboard should not cover user-interface widgets and
other user-interface concerns (those should be covered by the User-Interface Prototype).
|
Relationships
| Roles | Responsible:
| Modified By:
|
| Input To | Mandatory:
| Optional:
| External:
|
Main Description
The Storyboards support requirements elicitation by providing important feedback mechanisms for discovering unknown or
unclear requirements.
|
Properties
| Optional |  |
| Planned |  |
Key Considerations
| A Storyboard may be defined for each Use Case, thereby supporting a use-case-driven approach to software
engineering, as well as providing an excellent means to validate the user's (actor's) expectations of these use cases and
their role in the use-case flows of events. |
Tailoring
| Representation Options |
Storyboards may be expressed using visual or textual representations, or a combination of both.
Decide whether Storyboards are useful for your project. The contents of the Storyboards should be tailored to
support project needs.
Storyboards are often considered as transient work products, and may be left unmaintained once the behavioral
requirements are understood and the project is up to speed prototyping or implementing the user interface. However, in
some cases it might be of value to maintain the Storyboards through a number of iterations, for example if there are
complex requirements posed on the user interface which take time (over several iterations) to be understood. Also,
Storyboards, coupled with the actual user interface, are a useful input to end-user documentation.
|
More Information
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|
