Work Product: Storyboard
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
RolesResponsible: Modified By:
Input ToMandatory:
  • None
Optional: External:
  • None
Output From
Main Description

The Storyboards support requirements elicitation by providing important feedback mechanisms for discovering unknown or unclear requirements.

Properties
Optional
PlannedYes
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
Guidelines