IBM® Rational® Requirements Composer enables you to storyboard your software system before you begin development. To understand this concept, consider the following.
"Picture the scene..."
How often do you start a tale of fame and fortune, comedy, or tragedy with this phrase? What follows is some description that relates the story that you want to tell. In software development, you also have a story to tell. You are building or modifying software systems, in ways that are yet to be decided, or yet to be understood.
"Actually, I cannot picture the scene..."
Many times, however, you do not have that story firmly embedded in your mind. You do not understand the story, the background, what happened before, and what happens next. Even if you understand exactly what you are trying to explain, no one else has exactly the same picture in mind. Storyboarding is a technique that you can use to capture and explain the story to those around you: translating the ideas you might have in your head into something concrete that everyone can understand.
Storyboarding is not new. Software developers have recently borrowed the concepts and techniques from the film industry, because this field is the best-known example of the use of storyboards. From a software development perspective, a storyboard is defined as "...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'" [IBM® Rational Unified Process® (RUP®), 2008]
This definition covers the use of storyboards as a method of capturing the way that a solution behaves, as though you have already solved the problem. A storyboard is also a way to explore the context of a system, and to explore possible options to solve the problem that a system is designed to solve.The task of building up storyboards is called storyboarding. "Storyboarding is a technique for capturing logical and conceptual description of system functionality for a specific scenario". [RUP, 2008]
A storyboard typically shows the user interface drawn in a way that shows how the system will operate for a particular purpose. Usually, a storyboard is a sequence of frames, where each frame has a description of the actions that lead to the next frame. However, you are not trying to design a user interface: you are trying to illustrate the user experience. A film storyboard captures the flow of the scene, camera angles, and the characters, while a software storyboard captures the main intent of the software in a particular context.
Benefits of storyboarding
Storyboarding can help you reduce project risks, and save time and money.
Customers do not always know what exactly they want. You will often hear them say something like, "Iâll know it when I see it." Storyboarding can help you resolve requirement uncertainties early in the development process. You can use these uncertainties in requirements definition to determine when storyboarding will be useful, and gain agreement on what the system should do by visualizing the requirements with storyboards.
Storyboarding helps you elicit, clarify, complete, and validate requirements. Storyboarding encourages stakeholder participation, and allows you to explore technical solution alternatives without coding. You can use storyboards for interactive requirements and use case review sessions with stakeholders. These sessions help you find what is missing, what is wrong, what is unnecessary, and what is desired.
Storyboards can also be leveraged by designers, developers, testers, architect, and UI Designers.
What goes in a storyboard
This section describes various components involved in creating a storyboard.
A persona describes a fictional person, who is a user of a system. It represents the archetype of a user based on the knowledge of real users. The goal is to bring the users to life by developing personas with names, personalities, motivations, and so on. You typically create several personas for a system. A persona is an instance of actor, and it can be associated with multiple storyboards.
The purposes of describing a persona are:
- To ensure that you explore all of the needs of your user base
- To act as a stand-in for a user, helping to guide your decisions about functionality and design
- To keep your storyboard focused on a very specific user context and user goal
An example of a persona is shown in Table 1.
Table 1. Persona details
Erik is a media consultant who works long hours, and he has started to earn so much money that his bank account has started to grow.|
Erik does not have any fund investments. However, he is very interested in putting his extra money somewhere that will earn interest, and is passively thinking where. He has made some minor stock purchases online, but mainly lost what little he invested. Erik does not know anything about investing in funds.
Erik is an early adopter regarding technology. He likes to try out new solutions and online services, and in general does not have any anxieties or problems using them. Erik is a bank customer and has used Netbank for several years. He pays his bills with it, and is aware about the vast array of services there.
For the online fund service to be useful to him, Erik must be able to:
|education: university degree|
|technology used: laptop with a broadband|
A usage scenario describes how a persona interacts with a system to perform a specific task. It is driven by the user needs, and the user's motivation for doing the task. It can be a summary of what the persona does in a storyboard before you create it. If you do use-case driven development, a usage scenario is typically an instance of a complete use case scenario, or a portion of the use case scenario.
A storyboard is a logical and conceptual description of system functionality for a specific scenario, including the interaction required between the system users and the system.
In Rational Requirements Composer, a storyboard is represented as 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. In essence, a storyboard is a sequence of frames that elaborates the user experience. It includes a frame list, timeline viewer, and frames, as shown in Figure 1. Frames are basically instances of sketches within a storyboard.
Figure 1. Storyboard components
Discover and clarify requirements with storyboarding
Storyboarding can take place as early as the Inception phase to identify what capabilities (goals) the stakeholder wishes to obtain. At this phase in the development, the system (whether it includes hardware or just software) does not exist. Alternatively, storyboarding could take place later in the development, and you would use it to clarify how something (user) may interact with the item being developed (user interface). Therefore, the purposes for storyboarding will be different at various phases in the development.
Before storyboarding takes place, it is essential that the problem to be solved is clearly identified. Once the problem has been identified, then the purpose of the storyboard can be defined. The purpose should clearly "bound" the area under investigation, so that it provides the scope for the storyboarding. Within this bounding, any constraints that may be applicable for the storyboard should be identified.
Following the completion of a storyboard, you should verify that the purpose of the storyboard has been resolved. It is essential that the stakeholders involved in storyboarding take ownership of the developed storyboard, in effect approving the storyboard and validating that it correctly expresses their thoughts. To enable such ownership, it is essential that the storyboard is developed using terms that they understand.
The end state of the item under investigation should be documented, and any further potentially related storyboards should also be identified (maybe because of dependencies). A list of assumptions made during the storyboarding process should be gathered (the list can later be verified as being correct), plus any constraints discovered during the storyboarding.
You should generate requirements from the results of the storyboard (with traceability back to the specific element within the storyboard), and agreed upon with the stakeholder. Next, place these requirements within the appropriate requirements set from which the need for the storyboard first emerged.A typical template for creating a storyboard would include the pre- and post-conditions as detailed in the following sections.
Preconditions do the following:
- Define the problem
- Define the purpose of storyboarding
- Define the type of storyboarding
- Identify the development lifecycle phase
- Determine the level of fidelity to use
- Identify the stakeholder role
- Identify constraints
Define the problem
It is important to fully understand the problem to be addressed. If storyboarding is being employed during the Inception phase, it is likely that the problem being addressed is to identify what capabilities the stakeholder will obtain. This may be initiated from original stakeholder needs. If storyboarding is taking place later in the development lifecycle, then it is more likely that the problem being addressed will involve the identification of some feature or behavior of something under development. The following are examples of problem statements:
- Inception phase: The retail shopper statement of need, such as I wish to shop for items from retail outlets without leaving my home.
- Elaboration phase: Implementation-centric need, such as How can the music enthusiast confirm whether he will enjoy the item he is purchasing?
Define the purpose of storyboarding
The storyboard to be developed should focus on the problem identified; however, the problem being resolved may need a number of stakeholder viewpoints to be considered. Therefore, it may be that you have to create several storyboards to fully address the problem under investigation. Stakeholders and analysts must understand the boundary of the storyboard. This is best accomplished by clearly stating the purpose for the specific storyboard. Following are two examples of purpose definitions:
- Inception phase: To identify how a classical music enthusiast may wish to purchase music from retail outlets whilst remaining at home
- Elaboration phase: To identify the location, appearance, and occurrence of the Sample play function within the on-line market GUI
Define the type of storyboarding
There are fundamentally two types of storyboard: requirements discovery storyboards or requirements clarification storyboards. These two types cover any situation where storyboarding may be needed (for example, capability discovery, use-case development, user interfacing, requirements clarifying, and prototyping). Following are two examples of storyboarding types:
- Inception phase: Capability requirements discovery
- Elaboration phase: Prototyping requirements clarification
Identify the development lifecycle phase
Clearly, there is a relationship between the type of storyboard you use and the phase of the development lifecycle. During the Inception phase, it is likely that requirements are being discovered. In the Elaboration phase, there may need to be a further understanding and clarification of the requirements.
Determine the level of fidelity to be used
When planning to use storyboarding, you should determine the level of fidelity (that is, how accurately must the storyboard reflect the theme under investigation). It is likely that you can use a low level of fidelity when storyboarding during the Inception phase, because it is unlikely that you will know what the end product will be.
When you storyboard during the Elaboration phase, it is likely that you will have considerable knowledge of what the end product will be and will appear like. Therefore, a higher level of fidelity will be important to accurately reflect this appearance and enable the requirements clarification requirements.
Identify the stakeholder role
You should identify the role of the stakeholder who you will question during storyboarding, particularly when there will be multiple storyboards. Following are two examples of appropriate roles in different phases
- Inception phase: Retail shopper
- Elaboration phase: Music enthusiast
Before the storyboard begins, it is essential that you identify any constraints applicable for the storyboard. This will ensure that the development remains within any limiting circumstances (such as legal constraints or domain standards). Following are two examples of constraints:
- Inception phase: An audit trail of the order and purchase process must be available for inspection
- Elaboration phase: The GUI should conform to standard Microsoft® Windows® conventions
Following the completion of the storyboard it is essential that you confirm the validity of the developed storyboard and identify any further follow-on work:
- Confirm that the original problem is resolved
- Confirm that the purpose of the storyboard was satisfied
- Get storyboard approval from the stakeholder
- Identify further storyboard themes
- Identify related storyboards
- Identify assumptions made
- Identify new constraints
- Identify the source of requirements within the storyboard
Confirm that the original problem is resolved
Has the storyboard fully resolved the original problem identified? Answers to this question can be Yes, Partially, or No.
Confirm that the purpose of the storyboard was satisfied
Was the purpose of conducting the storyboard satisfied? This should be a Yes or No question.
Get storyboard approval from the stakeholder
Has the stakeholder involved with the storyboard taken ownership for the storyboard yet? Possible answers to this question could be Yes, Under Review, or No.
Identify further storyboard themes
During the development of the storyboard, were other storyboard themes identified? What were those themes, and what stakeholder roles would be involved? Following are two examples of themes identified in different phases:
- Inception phase: How the retailers may keep track of deliveries
- Elaboration phase: The location, appearance, and occurrence of the album art feature
Identify related storyboards
Identify where other storyboards have been or are planned to be developed. This is typical in a sequence of actions, each fully discovered via separate storyboards.
Identify assumptions made
Identify any assumptions that were made during the storyboard development. These assumptions will require follow-up action to confirm whether they are correct. An example of an assumption would be that the solution is only valid with UK legal jurisdiction.
Identify new constraints
Identify any constraints discovered during the storyboard development and not already defined in the pre-conditions
Identify the source of requirements within the storyboard
For any requirements in the storyboard, identify their source.
How to create a low-fidelity storyboard using Rational Requirements Composer
This section describes how you can create a simple low-fidelity storyboard using 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 you (as an analyst) 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 this storyboard example, your persona, Gordon MacIntyre, searches for and purchases a Beethoven CD.
Perform the following steps to create your storyboard.
Define your persona and organize your storyboard
- 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 that 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. This example uses a native rich text document to document our persona:
Figure 2: Persona example
- Get organized! This is particularly important if you are planning to do a lot of storyboards. Take advantage of the subfolders available in Rational Requirements Composer to manage and group common artifacts, as shown in Figure 2.
Because personas, parts, and sketches can be used on multiple storyboards, it is best to store these in one central place, separate from the storyboards themselves. For example, have a folder for parts, a folder for sketches, a folder for personas, and a set of folders to group related storyboards. Meaningful names and titles will also help to keep you organized.
Figure 3 : Example folder structure
- Create your frame list. Each frame in the list has a title and a description, as shown in Figure 4. 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.
The frame list is the outline of a storyboard (analogous to use case steps), that helps you 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 you nail down the step-by-step outline before delving into the details of each frame or sketch.
Figure 4 : Refined frame list
- At this stage, each item in the list has an empty frame associated with it. 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 Rational Requirements Composer, a user interface sketch is a mock-up of a software productâs graphical user interface at any one point in the application's operation. [Rational Requirements Composer Version 1.0, Help]
In Rational 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, sketches, and frames
Figure 5 shows a graphical representation of the relationship between a part and a sketch. A part can be used by zero to many sketches, and a sketch can contain zero many parts.
Figure 5. Relationship between a part and a sketch
Figure 6 shows a graphical representation of the relationship between a sketch and a frame. A sketch can be used to create from zero to many frames, and a frame can be created from zero to one sketch.
Figure 6. Relationship between a sketch and a frame
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, there are parts for the common sidebar menu, page header, shopping cart, and CD listing item, as shown in Figure 7.
Figure 7. Parts
Walk through the example storyboard
The example storyboard that you will walk through has 16 frames, but is built off of five sketches.
Refer to the Rational Requirements Composer Help for detailed instructions on:
- Task: Creating a user interface sketch part
- Task: Creating a user interface sketch
- Start populating your frames. Frame content can come from one of three places:
- UI elements can be directly drawn into the frame.
- 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.
- 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.
Start building frames: welcome and search
Frame 1: The Welcome page is a frame that was drawn directly into the storyboard, as shown in Figure 8. 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, so everything that you do is part of this storyboard and not available for reuse in other storyboards.
Figure 8. Frame 1: Welcome page
Frame 2: This frame is an example of a frame that inherits from a sketch. At this point in your 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, as shown in Figure 9.
Figure 9. Create from an existing sketch
- Find your sketch in the list and click OK. The frame is now populated with an instance of the sketch, which 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, some data was added to the shopping cart area, as shown in Figure 10. In the original sketch, this area is labeled but not populated so that it can be reused appropriately in any storyboard frame.
Figure 10. Populated frame
Frame 3: In frame 3, Gordon has entered
Beethoven as the search criteria. Because this is still the same screen, you 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 of the frame 2 customizations on it (namely, the populated shopping cart).
- Edit this frame to illustrate that Gordon is doing a search: enter
Beethoveninto the quick search text, and add a descriptive callout.
Figure 11. Frame 3: Entering search criteria
Frames 4 and 5: In frames 4 and 5, the system returns the search results and Gordon picks a CD to view. In these two frames, you continue building the dependency chain that started at frame 2 (by choosing Create from the previous frame). Simply edit frame 4 to display the search results, and frame 5 to indicate that Gordon is picking a CD to view, as shown in Figures 12 and 13.
Figure 12. Frame 4: Search results are displayed
Figure 13. Frame 5: A CD is selected for viewing
More frames: product details and shopping cart
Frames 6 and 7: At this point in the story, you 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, as shown in Figure 14. This is because it is a reusable part that is being shared on both sketches. .
Figure 14. Frame 6: View details of a CD
Frame 7 shows Gordon adding this CD to his cart, as shown in Figure 15, and is based off of frame 6.
Figure 15. Frame 7: Add CD to cart
Note that this has created a new dependency chain between frames 6 and 7, as shown in Figure 16.
Figure 16 : Dependency chain between frames 6 and 7
Frame 8: This frame is based off of frame 5, and so continues the dependency chain, with the CD showing in the shopping cart.
- Select Create from earlier frame.
- From the Select a Frame dialog, select the frame from which you want the current frame to inherit its contents, as shown in Figure 17.
Figure 17. Create from an earlier frame
- In frame 8, have the system return to the catalog search results, and Gordon decides to complete his purchase by checking out, as shown in Figure 18.
Figure 18. Frame 8: catalog results with shopping cart
Final frames: check out and pay
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, as shown in Figure 19.
Figure 19. Create from an existing sketch
Frame 9 is the beginning of the checkout, as shown in Figure 20.
Figure 20. Gordon enters contact, shipping, and credit card information
Figure 21 shows the dependency chain between frames 9, 10, 11, and 12.
Figure 21. Dependency chain
Frames 13 and 14: These frames represent an additional dialogue where Gordon enters his credit card information, as shown in 22.
Figure 22. Frame 13: Entering credit card information
Figure 23 shows the completed credit card information
Figure 23. Frame 14: Credit card information has been entered
Frame 15: This is a standalone frame that displays the order confirmation, as shown in Figure 24.
Figure 24. Frame 15: Confirmation page
Frame 16: The end of the story
Ready to storyboard
The fundamental purpose of storyboarding is to take someone's vision of carrying out an activity, and communicate that vision to developers who can create that vision.
Storyboarding is a technique, within requirements definition, that is used to both discover and to clarify requirements. This technique can be used at many points within a development lifecycle, and is equally relevant for systems development as it is for software development.
IBM Rational Requirements Composer is a requirements definition product that allows you to effectively leverage the storyboarding technique to drive better requirements and deliver better products.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
- Subscribe to the developerWorks Rational zone newsletter. Keep up with developerWorks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
- Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download the trial version of IBM Rational Requirements Composer.
- Download trial versions of IBM Rational software.
- Join the developerWorks Community in forums, blogs, podcasts, wikis, and more.
- Join the Rational Requirements Composer forum on developerWorks.