Storyboarding in IBM Rational Requirements Composer

Elicit, Clarify, Complete, and Validate Requirements

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 IBM® 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. Frames are basically instances of sketches within a storyboard.


Yan (Tina) Zhuo (, Senior Product Manager, IBM

Tina is a Senior Product Manager and a member of the Rational Expertise Development and Innovation (REDI) team.

Adrian Ditchburn (, Principal consultant, IBM

Adrian Ditchburn is a principal consultant with Telelogic, now an IBM company (all Telelogic products and services are now part of the IBM Rational Software portfolio).

Vivienne Suen (, Rational IT Specialist, IBM

Vivienne Suen is an IT Specialist with IBM Rational in Canada. Her main areas of expertise are requirements definition and management, Rational Unified Process, and UML design.

Valerio Rosati (, Managing Consultant, IBM

As a member of IBM Rational Software Services, Valerio Rosati specializes in the Analysis / Design and Requirement disciplines within Software development. Valerio provides services to clients from every industry helping them realize the benefits of using the IBM Rational suite of products for their software development needs. Valerio has been working with IBM and Rational tooling for over 7 years and is IBM certified in the Rational Unified Process. Prior to joining IBM in 2005, Valerio worked as a consultant providing J2EE System Architecture, design and construction services to clients primarily in the financial sector. Valerio holds a Computer Engineering degree from the University of Toronto and is a licensed Professional Engineer in Ontario, Canada.

Anthony Kesterton (, Rational technical consultant, IBM

Anthony Kesterton is a technical consultant for IBM Rational and is based in the UK. He is the co-author of the IBM Redbook "Building SOA Solutions using the Rational SDP", and currently leads the UK Financial Services Sector IBM Software Group SOA team.

Vivianne Eriksson (, Rational IT Specialist, IBM

Vivianne Eriksson works as an IT Specialist in Rational Technical Sales where she helps customers with tools and process in the requirements area. She loves to teach Requirements Management with Use Cases. She is a Requirements Definition & Management (RD&M) Regional Mentor in Sweden. She used to be a RequisitePro and Rose customer and joined Rational 2001. Previously, she wrote software for a pacemaker company and grew a special interest in requirements. She holds an M.Sc. in computer science.

Katrina M Kolonay (, IT Specialist, IBM

Katrina M. Kolonay has been working with Rational since 1999 taking on roles in Technical Support, Technical Marketing, TechWorks and is now currently working in Technical Sales. Her primary focus is around the Architecture Management discipline.

Peter Atthem (, IT Specialist, IBM

Peter Atthem has worked in the Rational Services team as an Process Engineer at Ericsson, doing modeling activities, training and deployment of Rational Method Composer.

18 November 2008

Also available in Chinese Russian

Storyboarding software

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
Persona: Erik
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:
  • Get the necessary understanding about the product
  • Select the right fund
  • Begin using the service easily
  • Purchase the fund
  • Monitor the growth of his possessions real-time
age: 30
gender: male
occupation: consultant
education: university degree
technology used: laptop with a broadband

Usage scenario

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
numbered frame list

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:

  1. Define the problem
  2. Define the purpose of storyboarding
  3. Define the type of storyboarding
  4. Identify the development lifecycle phase
  5. Determine the level of fidelity to use
  6. Identify the stakeholder role
  7. 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

Identify constraints

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:

  1. Confirm that the original problem is resolved
  2. Confirm that the purpose of the storyboard was satisfied
  3. Get storyboard approval from the stakeholder
  4. Identify further storyboard themes
  5. Identify related storyboards
  6. Identify assumptions made
  7. Identify new constraints
  8. 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 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

  1. 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
Gordon McIntyre's persona information
  1. 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
Storyboards folder with subfolders
  1. 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
numbered frame list with descriptions
  1. 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
Part is a search box

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
sketch is catalog

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
buttons and search criteria

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
  1. 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, 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
page with text at top and button at bottom

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:

  1. Select the Create from an existing sketch option in the blank frame, as shown in Figure 9.
Figure 9. Create from an existing sketch
also has option to create from previous frame
  1. 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
  1. 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
buttons on left, catalog detail on right

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:

  1. 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).
  1. Edit this frame to illustrate that Gordon is doing a search: enter Beethoven into the quick search text, and add a descriptive callout.
callout is Gordon selects to search for Beethoven

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.

search results for Beethoven are displayed callout
Figure 13. Frame 5: A CD is selected for viewing
callout reads Gordon selects a cd

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 shows cd price with Add to Cart button

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
Gordon adds 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
line with a circle on left end and a dot on right

Frame 8: This frame is based off of frame 5, and so continues the dependency chain, with the CD showing in the shopping cart.

  1. Select Create from earlier frame.
  1. 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
list of frames has pictures and descriptions
  1. 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
shopping cart has checkout link

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
changes made to sketch reflected in frame dialog

Frame 9 is the beginning of the checkout, as shown in Figure 20.

Figure 20. Gordon enters contact, shipping, and credit card information
SHIPPING INFORMATION label highlighted in yellow

Figure 21 shows the dependency chain between frames 9, 10, 11, and 12.

Figure 21. Dependency chain
line with four circles under the frames

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
CREDIT CARD INFORMATION highlighted in yellow

Figure 23 shows the completed credit card information

Figure 23. Frame 14: Credit card information has been entered
card type, name, number, and expiration date

Frame 15: This is a standalone frame that displays the order confirmation, as shown in Figure 24.

Figure 24. Frame 15: Confirmation page
Order details displayed with Finish button

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.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Storyboarding in IBM Rational Requirements Composer