Tool Mentor: Create a Low Fidelity Storyboard Using IBM Rational Requirements Composer |
Create simple low-fidelity storyboards for UI sketching to clarify and support requirements.
Tool: Rational Requirements Composer
Relationships
Related Elements | Detail Use-Case Scenarios Develop Technical Vision
Main Description
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: Creating a user interface sketch part Creating a user interface sketch #### 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. Since 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
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.