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.
Domains: Requirements
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 | [Technical Specification]
Roles | Responsible: Analyst | Modified By: Analyst
Tasks | Input To: Design Performance Test Design the Solution Detail Component Model Develop Test Cases Envision the Architecture Establish Performance Test Goals Organize Requirements Outline Component Model Plan Project Analyze Target Define Test Strategy Detail the Design Develop Security Test Policy Document Architectural Decisions Identify and Outline Requirements Identify Test Ideas Plan Iteration | Output From: Detail Use-Case Scenarios Develop Technical Vision
Description
Main Description | Storyboards support requirements elicitation by enabling stakeholders to discover and clarify unknown or unclear requirements, and to provide feedbacks.
Brief Outline | TBD (persona, etc. should be included)
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
Concepts | Storyboarding
© Copyright IBM Corp. 1987, 2009. All Rights Reserved. © Copyright ABC Corp. 2009. All Rights Reserved. Includes materials licensed from IBM and Eclipse. See IBM copyright and Eclipse copyright .