WorkProductDescriptor
Work Product (Artifact): Storyboard |
|
 |
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 is a frame-by-frame depiction of a usage scenario, where each frame has a description of the actions that lead to the next frame. It contains an in-depth walkthrough of a linear story represented as graphical frames on a timeline with sample data. |
|
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 formulate test cases based upon a clear understanding of the usage scenarios;
-
the manager to plan 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, especially at the early development lifecyle.
|
Relationships
Fulfilled Slots |
|
Roles | Responsible:
| Modified By:
|
Input To | Mandatory:
| Optional:
| External:
|
Main Description
Storyboards support requirements elicitation by enabling stakeholders to discover and clarify unknown or unclear requirements, and to provide feedbacks. |
Properties
Optional |  |
Planned |  |
Key Considerations
One or multiple storyboards may be defined for a 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
Impact of not having | Without storyboards, the requirements may be less clear than with storyboards. |
Reasons for not needing |
Storyboards are an optional technique for requirements elicitation and validation. They are used when they add
value.
|
Representation Options |
Storyboards may be formal or informal, executable or non-executable, low fidelity or high-fidelity prototypes.
The format the storyboard takes is not the issue. What is important to keep in mind is the purpose of the storyboard
(to understand the user's expectations of the behavior system), and what skills are required to produce the storyboard
(a storyboard requires requirements elicitation skills, not user interface design skills).
Storyboards can be produced on whiteboards, as powerpoint slides, or can be created in a requirements definition tool.
|
More Information
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|