This tool mentor describes creating a simple low-fidelity storyboard using IBM Rational Requirements Composer.
Low-fidelity storyboards are typically used for UI sketching as a way to help clarify and support requirements. They
are not meant to represent the actual GUI design. The Rational Requirements Composer has powerful storyboarding
capabilities that allow analysts to quickly create storyboards and link them to other requirements artifacts.
In this example, a storyboard is being developed for an online CD shopping application. Unlike use cases, which
describe a complete usage of the system by an actor, a storyboard focuses on a very specific story of a persona
performing a single discrete action. In our storyboard example, our persona, Gordon MacIntyre, searches for and
purchases a Beethoven CD.
Define Persona
Define your persona, if you are using one. Personas can be useful for keeping your storyboards focused on a very
specific user context and user goal. Remember that storyboards are meant to complement your use cases, and are not a
replacement for them! Instead, a storyboard can be thought of as an instantiation of a use case flow – they illustrate
this flow in the context of the persona you have identified. Storyboards are a powerful technique to help describe
information that is best communicated graphically (such as usability, user experience, user interface standards and
other requirements).
If you are not using use cases to document functional requirements, then storyboards become even more important for
identifying user context and scenarios.
Rational Requirements Composer supports the creation and editing of rich text documents. In this example, we have used
a native rich text document to document our persona:
Figure 1: Persona example
Get Organized
This is particularly important if you are planning to do a lot of storyboards. Take advantage of the subfolders to
Requirements Composer to manage and group common artifacts. Because personas, parts and sketches can be used on
multiple storyboards, it is best to have one central place for storing these, separate from the storyboards themselves.
For example, have a folder for parts, a folder for sketches, a folder for persona, and a set of folders to group
related storyboards. Meaningful names and titles will also help to keep you organized.

Figure 2 : Example folder structure
Create Frame List.
The frame list is the outline of a storyboard (analogous to use case steps), that helps us to visualize a feature, a
particular use case scenario, or a portion of the scenario. Remember that storyboards do not have branching or looping
logic; instead they are a straight-line path through one specific execution of the target system. Starting with the
frame list keeps the storyboard organized and helps to nail down the step-by-step outline before delving into the
details of each frame/sketch. Each frame in the list has a title and a description – a good description helps to flesh
out the usage scenario. At the very least, write down the title for each frame, and provide a few lines or bullet
points of additional description for any frames that are complex or still unclear. Spend enough time defining and
refining the frame list before you start developing the individual frames – it is best to get the story straight in
plan text before adding the images.

Figure 3 : Refined frame list
Draw Frames
At this stage, each item in the list has an empty frame associated with it. At this point, you can start drawing the
individual frames directly in the storyboard. The other approach to take is to start creating a catalog of sketches and
parts that can be reused in multiple frames and in multiple storyboards.
In Requirements Composer, a user interface sketch is mock-up of a software product’s graphical user interface
at any one point in the application's operation. [Rational Requirements Composer v1.0, Help]
In Requirements Composer, a user interface sketch part is a reusable set of user interface elements. You can use a
part to populate sketches, screen flows, and storyboards. Parts can contain a single element, such as a menu, or it
can include many elements that are aggregated in a container element, such as a panel or group. Reuse parts in
multiple user interface sketches, screen flows, and storyboard frames to create persistent user interface elements.
[Rational Requirements Composer v1.0, Help]
Parts can be extracted from frames or sketches at any time – even after the storyboard has been constructed. Therefore
it is important to keep your parts and sketches well-organized. The main advantage is reuse and change management – it
is far simpler to modify a single part and have that be automatically updated in all sketches and frames that use that
part, than to have to re-draw these UI elements in potentially dozens of storyboard frames.
In this example, we have created parts for the common sidebar menu, page header, shopping cart, and CD listing item:
Figure 4 : Parts
The example storyboard we will walk through has 16 frames, but is built off of 5 sketches.
Refer to the Requirements Composer Help for detailed instructions on:
Populate Frames
Start populating your frames. Frame content can come from one of three places:
1) UI elements can be directly drawn into the frame.
2) A frame can inherit content from a sketch. Inheritance means that the frame is based on an existing sketch, and if
that sketch changes, then the frame will automatically be updated.
3) A frame can inherit content from a previous or an earlier frame. This creates a dependency chain in your storyboard,
which helps to identify common frames.
Frame 1
The welcome page is a frame that was drawn directly into the storyboard. To create a standalone frame that is not based
on a sketch, double-click any frame at the bottom of the frame list and it will open in the editor. Remember that this
is the frame editor, and everything you do is part of this storyboard and not available for reuse in other storyboards.
Figure 5 : Frame 1 - Welcome Page
Frame 2
This frame is an example of a frame that inherits from a sketch. At this point in our storyboard, Gordon (our persona)
has navigated to the CD catalog page. Frame 2 shows the initial view of the CD catalog screen and was built from the CD
catalog sketch. To create this frame, do the following:
Select the “Create from an existing sketch” option in the blank frame.
Figure 6 : Creating from an existing sketch
Find your sketch in the list and click “OK”. The frame is now populated with an instance of the sketch, that can be
edited without affecting the original sketch.
Edit the frame to add additional information and data as needed to help tell the story. In this example, we added some
data to the shopping cart area. In the original sketch, this area is labeled but not populated so that it can be reused
appropriately in any storyboard frame.
Figure 7 : Populated frame
Frame 3
Gordon has entered “Beethoven” as the search criteria. Because this is still the same screen, we can base this frame
off of its predecessor and simply edit the data to describe this step of the story.
Select the “Create from the previous frame” option in the blank frame. Note that because it is created from frame 2
(NOT from the original sketch), it has all the frame 2 customizations on it (namely, the populated shopping cart).
Edit this frame to illustrate that Gordon is doing a search – enter “Beethoven” into the quick search text, and add a
descriptive callout.
Figure 8: Frame 3 – entering search criteria
Frames 4 and 5
The system returns the search results and Gordon picks a CD to view. In these two frames, we continue building the
dependency chain that started at frame 2 (by choosing “Create from the previous frame”) and simply edit frame 4 to
display the search results, and frame 5 to indicate that Gordon is picking a CD to view.
Figure 9 : Frame 4 - search results are displayed
Figure 10 : Frame 5- a CD is selected for viewing
Frames 6 and 7
At this point in the story, we are displaying the details of a specific CD. Frame 6, then, is based off of a different
sketch called “CD Details”. Although this sketch is different, you may notice that the sidebar menu looks exactly the
same. This is because it is a reusable part that is being shared on both sketches. Frame 7 shows Gordon adding this CD
to his cart, and is based off of frame 6. You’ll notice that this has created a new dependency chain between frames 6
and 7.
Figure 11 : Frame 6 - view details of a CD
Figure 12: Frame 7 - Add CD to cart
Figure 13 : Dependency chain between frames 6 and 7
Frame 8
We have the system return to the catalog search results, and Gordon decides to complete his purchase by checking out.
This frame is based off of frame 5, and so continues the dependency chain, with the CD showing in the shopping cart.
Figure 14: Create from an earlier frame
Figure 15 : Frame 8
Frames 9 – 12
At this point, a new dialogue begins for the checkout procedure. Frames 9-12 show Gordon entering his personal,
shipping, and contact information and are all based off a common sketch.
Figure 16: Create from existing sketch
Figure 17: Frame 9, where the checkout process begins
Figure 18: Dependency chain between frames 9-12
Frames 13 and 14
These frames represent an additional dialogue where Gordon enters his credit card information.
Figure 19: Frame 13 - entering credit card information
Figure 20: Frame 14 - credit card information has been entered
Frame 15
This is a standalone frame showing the order confirmation.
Figure 21: Frame 15 - confirmation page
Frame 16
End of Story
|