Introduction

Storyboards can be used to explore, understand and reason about the behavioral requirements of the system, especially how the users will interact with the system. Storyboards are a long-standing practice in film and television - that's where the software community "borrowed" the technique from. Storyboards are meant to make textual scenarios more "real" by using pictorial means to specify the requirements They are not intended to be a first draft of the user interface, but are intended to just represent the user's interactions with the system.

In this guideline we describe some recommendations for representing the Storyboard. For more information on Storyboards, see Guideline: Storyboarding.

Representing Storyboards

Storyboards may be formal or informal, executable or non-executable, low fidelity (hand-drawn pictures) or high-fidelity prototypes (interactive HTML pages). 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 may be expressed using visual or textual representations, or a combination of both.

Some examples of ways in which the Storyboards can be visualized include the following:

• Paper sketches or pictures
• Bitmaps from a drawing tool
• Index cards
• Powerpoint slides
• Screen shots (if a user-interface, or prototype of the user interface exists)
  Note: Storyboards expressed in terms of actual screen shots can be a useful input to the end-user documentation.

No matter what representation is selected, it is important to consider the following for each of the user-interface elements:

• Actions the user can take, or requests the user can make on the system.
• Information that is present to, or entered by, the user.