Support agile development by using IBM Rational Requirements Composer

A step-by-step guide to defining requirements

Agile software development projects often use iterative methods in the requirement definition and design phase. By using a step-by-step example, this article elaborates on how IBM Rational Requirements Composer fits into this process.


Yang Liu (, Staff Software Engineer, IBM

author photoYang Liu is a software engineer at IBM China Software Development Lab in Shanghai, China. She works in the Shanghai Globalization Lab, and focuses on RFID technology, Web services and globalization technologies. You can reach her at

Yang Gu (, Staff Software Engineer, IBM

author photoYang Gu is a project manager from the IBM Globalization Laboratory, User Technologies, China Development Lab in Shanghai, China. She has rich experience in project management and the adoption of relative tooling.

Cheng Yu Peng (, Software Engineer, IBM

author photoPeng Cheng Yu is a software engineer in the IBM China Development Lab. Working as a test lead of several globalization projects, he has experience in agile testing, quality assurance, and test automation.

Ming Ding (, Software Engineer, IBM

author photoDing Ming is a software engineer at IBM China Development Lab in Shanghai, China. He has experience in Java Enterprise Edition development.

Jie Hu (, Staff Software Engineer, IBM

Photo of Jie HuJie Hu is a technical leader in the Globalization Development area at the IBM China Development Lab in Shanghai. He has six years experience in J2EE development.

17 December 2009

Also available in Chinese Portuguese

Agile development allows us to deliver software products rapidly and with high quality. Agile project development requires frequent and extensive communication between the development team, stakeholders, and users to capture the real customer needs and objectives.

When the team is in same location, agile methods emphasize face-to-face meetings over written documents to facilitate communication. However, when a team works in different locations, it becomes harder for remote communications to be efficient. When stakeholders are located elsewhere, the most important communications of product requirements can be very difficult. And because agile project management embraces change and iterative development methods, it requires an efficient tool to make design and communication easy and fast.

IBM® Rational® Requirements Composer software facilitates communication between stakeholders and development team about requirement definition and management. It enables stakeholders to collaborate in context to define requirements by using various visual and textual techniques to capture business objectives and elaborate software requirements.

After analyzing the barriers on requirement communications, Rational Requirements Composer provides three key features to support agile development (also see the Rational Requirements Composer on the community site).

  • Collaborate to define textual and visual requirements
    • Elicit, capture, and refine requirements by using a variety of definition techniques: text, storyboards, use-case diagrams, user interface sketches, and business process diagrams.
  • Use the rich client and the Web UI
    • Requirements authors can use the Eclipse client to create, refine, and manage requirement artifacts.
    • Requirements reviewers can use the lightweight Web UI to review and comment on artifacts, with no software installation required.

Integrate with Rational RequisitePro for traceability

As you know, agile development uses iterative methods in all phases, including defining requirements in the beginning with stakeholders. If you integrate Rational Requirements Composer with IBM® Rational® RequisitePro®, you get complete traceability and can control the full iterative requirements definition process.

Figure 1 illustrates an iterative cycle for requirement definition and design for agile projects. This section elaborates on the iterative requirement definition process in agile development (see the Resources section for a link to the Rational Requirements Center Information Center for more details).

Figure 1. Iterative requirement definition process
Diagram: iterative requirement definition cycle

Assess the business problem

In the first phase of iterative requirement definition, it is the business analyst's responsibility to collect information about the current business problem so that requirements can be developed successfully in the later phases. There are several ways to collect useful information. First, the business analyst arranges an interview with stakeholders and users of the system. Each stakeholder and user will have an idea of their own expectation or a complaint about the system. Second, the analyst collects documentation or relevant information resources about the current system. This is another way of information collection, especially for legacy systems.

Document the assessment

After assessing the business problem, the business analyst creates documents and other artifacts to describe the current system and the proposed solution. Those artifacts can have different forms, but usually include these items:

  • Documentation of the current system
  • Solution goals
  • Stakeholders' requirements and expectations
  • Issues and risks related to the solution
  • Business process sketches
  • Storyboards
  • Use case diagrams

The artifacts constitute the sources of project requirements. In Figure 1, you can see that this is the starting point of an iterative cycle, which means that this phase can be repeated iteratively if there is any change or disagreement about the requirements. The project team will also review and update the assessment iteratively to deliver the requirements baseline for the project.

Review the assessment

With assessment documented, the business analyst can ask other team members to conduct a review so that they can add their own comments to the relevant documentation. Then the analyst can discuss the comments with those members and incorporate changes into the related artifacts.

Present to stakeholders and get feedback

The project team then presents drafted artifacts to the stakeholders. These artifacts can include a requirements document, a draft user interface, user stories, and so forth. If the stakeholders think that the specified requirements are incomplete, ambiguous, or even contradictory, they can give their comments so that the project team can adjust accordingly. And that makes the iterative requirement cycle go back to the document assessment phase. You can repeat the document assessment, review assessment and presenting to stakeholders phases iteratively until the project team and stakeholders reach agreement.

Deliver the requirement baseline

When the requirement definition gets confirmation from stakeholders, the project team delivers the requirement baseline and then manages it during the project life cycle.

A step-by-step example: Fantasy Bookstore

In this section, we use an online bookstore application as example to show you how Rational Requirements Composer fits into the iterative requirements definition process.

Project description:
Fantasy Bookstore is an online bookstore application used to sell books in various categories. It supports several payment methods, remittances, Cash on Delivery (COD), credit cards.

To define the requirements of Fantasy Bookstore, you can follow the process explained previously.

Preparation steps

Set up the project

  • After installing and configuring Rational Requirements Composer server, you need to connect to a repository that connects you to a Rational Requirements Composer server where your team can create projects and store project artifacts.
  • Then you can create a project named Fantasy Bookstore , using the base project template, which includes the attributes group only.
Figure 2. Connect to the repository
New Repository window fields

Create and add users to the project

After creating the project, use the administration page to add users to the project and assign member roles. In our bookstore project, we grouped the team into three roles:

  • Administrator: Perform administration actions, such as setting up project and folders, manage user access, and so forth
  • Author: Compose project artifacts.
  • Reviewer: Review project artifacts and provide comments.
Figure 3. Manage user roles in Rational Requirements Composer
An example of roles defined for each member

1. Assess the problem and upload artifacts

The business analyst interviews the client to gather documents and information for the Fantasy Bookstore. Then the analyst imports the documents into Rational Requirements Composer.

  • In the created project, you can create folders to contain various project artifacts.
  • For the existing artifacts, such as documents and images, you can use the upload feature or just drag the file from your local folder to the Rational Requirements Composer folder view. In our project, we uploaded the document for the result of the interview with the stakeholder.
Figure 4. Upload the document to the project
Drag to upload a document

2. Document the assessment

The business analyst creates a series of documents and other artifacts to express the current system and the proposed solution.

  • Glossaries: The business analyst extracts terms from the results of the interview with the stakeholder to create project glossary entries, such as those for catalog, shopping cart, common user, VIP user, and so forth.
  • Use cases: Like other requirement analysis tools, Rational Requirements Composer provides tools and views to create use cases. Before you write use cases, create three types of actors in the bookstore project: administrator, user, VIP user. Then create seven use cases in the Fantasy Bookstore project. In the use case, you can easily add other existing artifacts in the project. The screen capture in Figure 5 shows lists all use cases in Fantasy Bookstore project.
Figure 5. Use cases
Shows seven uses cases
  • Use case diagram: In Rational Requirements Composer, you can easily compose the use case diagram by using the existing use cases and actors, or you can simply create new ones.
Figure 6. Use case diagram
Example of use case diagram
  • Sketches: An important feature in Rational Requirements Composer is that it provides a handy palette and widgets to create a draft of the user interface (called the sketch) that is easy to compose and modify. The sketches help development teams to understand the requirement and present their designs in a convenient way. It is very useful in agile development projects, especially when using iterative design and implementation methods.

    Sketches are composed of images, parts, panels, and pages.
    • Part: You can create a common part that can be used in multipage pages. In the Fantasy Bookstore project, Victor, the UI designer, creates a header part, which is the common header of all pages, as following the screen captures in Figure 7 shows.
Figure 7. Part
Example of header part
  • Panel: Multiple UI controls can compose a panel. Victor groups a text area and a button to create a sign-in panel (see Figure 8).
Figure 8. Panel
panel designed in the composer
  • Page: By combining parts and panels, you can create pages. Victor adds the header part and sig- in panel to form the sign-in page. Besides the sign-in page, Victor also creates book search pages and payment pages for other use cases (see the three examples that follow).
Figure 9. Sign-in page
page for Fantasy Bookstore
Figure 10. Search page
Screen capture of the Search page
Figure 11. Payment selection page
Payment selection page for Fantasy Bookstore
  • Screen flow: After you have created sketches, you can create screen flow documentation to indicate the flow of pages.
  • Storyboard: Storyboards present a whole user story by frames that are composed of sketches. With a storyboard, stakeholders can easily review the whole flow of the user interface and interactions. Based on the sketches, Victor creates the storyboard of a whole book shopping story. The story includes the following use cases: sign in > search a book > view book detail > add book to cart > view cart > pay for the book. The story board is composed of frames in these use cases, as Figure 12 shows. Rational Requirements Composer provides an easy way to create frames from existing sketches or previous frames. Because Fantasy Bookstore supports two payment methods, remittance and Cash on Delivery (COD), Victor creates two storyboards for these two methods.
Figure 12. Storyboard of book shopping
Storyboard example
  • Define requirements: You can create requirements from existing artifacts. For example, you can open a storyboard, right-click on the component that you want to draft a requirement for, and then select Mark As Requirement to add a requirement in Rational Requirements Composer. You can also open other artifacts, such as a use case document, and highlight text to extract a requirement, as Figure 13 illustrates.
Figure 13. Extract requirement in context
Drop-down menu

For example, in the sign-in panel, we created three requirements (see Figure 14):

  • The password should be invisible.
  • Show an error message if the user ID or password is invalid.
  • The length of the user ID is from 3 to 20 characters.
Figure 14. Sign-in requirements
Shows all requirements on the sign-in page

Review the assessments

After creating the artifacts and requirements, Victor invites other team members to review the assessment documentation and add comments. He sends a link to the project home page to team members in an e-mail message. He specifies the scope and purpose of the review. Team members log in to the project, navigate from the home page to the review documents and artifacts, and add comments. Comments can be added to any project artifact. Figure 15 shows an example, where Alice asks questions that she adds as comments on the sign-in page. Victor answers her questions by adding his replies as comments. All comments can be tracked easily.

Figure 15. Comments in reviews of the sign-in page assessment
Shows review comments and responses

Present to stakeholders and get feedback

There are two ways to present the artifacts to stakeholders:

  • Export the artifacts as Microsoft® Word documents. Stakeholders can then view these artifacts locally.
  • Present them by using the Web UI. Stakeholders can log into the Rational Requirements Composer server Web UI to review the project artifacts and can also add comments directly, as Figure 16 shows.
Figure 16. Review the assessments view in the Web UI
A screen capture of the Web UI

After reviewing the two payment storyboards, a stakeholder proposed a change: "The bookstore should support payment by credit cards." This is a change to the requirement. Therefore, the artifact author, Victor, modifies the related artifacts to incorporate this change.

  • Add a new interview result document for this change.
  • Modify glossaries by adding a term, "credit card."
  • Modify payment use cases by adding a third payment method.
  • Modify the payment sketch by adding the credit card option.
  • Add a storyboard for payment by credit card.
  • Add a requirement of payment by credit card.

Figures 17, 18, and 19 illustrate the modifications to payment sketches. Because sketches are composed from different parts and panels, it is easy to modify existing sketches for the change requirement.

Figure 17. Add payment method option
Credit card option highlighted
Figure 18. Add credit card input
Credit card information input fields
Figure 19. Add credit card information on confirmation page
Add credit card information display on page

Steps 5 to 7 can be repeated iteratively until all requirements are clarified and the user interface is confirmed with stakeholders. This can fit into agile development process easily.

Deliver and manage requirement baseline in Rational RequisitePro

With iterations from step 2 to step 4, you can define the requirement baseline of the project. To manage requirements, the business analyst adds the requirements with Rational RequisitePro. Rational Requirements Composer is designed to integrate with Rational RequisitePro to cooperate in requirements management. You can choose to create and manage requirements in a Rational RequisitePro project and then import them into a Rational Requirements Composer project for more definition and elaboration. Similarly, you can define requirements in Rational Requirements Composer and add the requirements to a Rational RequisitePro project.


The goals of agile development include rapid design and customer needs validation, which requires sufficient communication iteratively with stakeholders about requirements, even when they are at different locations. However, it becomes very difficult to communicate remotely, because it can hardly be time effective on visual designs within textual documents and can hardly be traceable or consistent. As a result, agile development will encounter a barrier when stakeholder and development teams need to communicate on requirements remote in each iteration.

This article explains how Rational Requirements Composer helps you overcome this barrier and how it facilitates remote communications about requirements. With Rational Requirements Composer, project teams can create use cases, UI sketches, and storyboards fast, and get stakeholder's feedback iteratively. These textual and visual artifacts enable efficient collaboration in the requirement definition phase. All requirements can easily be transformed to Rational RequisitePro, and then be managed throughout the project life cycle.


Sample fileFantasy_Bookstore.zip129KB



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

Zone=Rational, DevOps
ArticleTitle=Support agile development by using IBM Rational Requirements Composer