Artifact: Storyboard
|
| A Storyboard 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". |
|---|---|
| Role: | System Analyst |
| Optionality/Occurrence: | Optional. Produced in early Elaboration, during requirements elicitation. |
| Templates and Reports: |
|
| Examples: |
|
| UML Representation: | Not applicable. |
| More Information: |
|
|
|
| Input to Activities:
| Output from Activities:
|
Purpose
The following people use the 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 interfactions 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.
A Storyboard may be defined for each Use Case, thereby supporting a use-case-driven approach for 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 if events.
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
(that's the purpose of the User-Interface Prototype). The
Storyboard should not cover user-interface widgets and other user-interface
concerns (those should be covered by the User-Interface Prototype).
Properties
Storyboards may be expressed using visual or textual representations, or a combination of both. For specific examples, see Guidelines: Storyboard.
Timing
Storyboards are produced in early Elaboration, during requirements elicitation.
Storyboards are produced as soon as the flows they describe are ready to be considered from a usability perspective. They may be produced at the same time or subsequent to other requirements artifacts
Responsibility
The System Analyst role is responsible for the integrity of the Storyboard, and ensures that:
- The Storyboard is readable and suits its purpose;
- The Storyboard correctly captures the expected behavior of the system.
- The associated usability requirements are readable and suit their purpose, and that they correctly capture the usability requirements of the system;
For guidelines on developing the Storyboards, see Guidelines: Storyboard.
Tailoring
Decide whether Storyboards are useful for your project. The contents of the Storyboards should be tailored to support project needs. This may include developing only a subset of the properties, as well as tailoring the level of formality with which these properties are created and managed.
Storyboards are often considered as transient artifacts, 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.
