IBM Rational Requirements Composer (RRC)

What is RRC?

Rational Requirements Composer is a repository for storing the requirements to which a software program is developed. It is a member of the CLM suite. Very IBM Rational Requirements Composer RRC 1often, software must meet the requirements of a wide range of stakeholders. The various requirements must be carefully organised and prioritised so that the most important requirements are implemented first, requirements do not conflict and requirements are not lost or forgotten. RRC provides a powerful platform to accomplish these goals and is a considerable improvement on managing requirements by individual documents and email – enabling quicker and more cost effective IT project delivery. IBM RRC also integrates with the rest of the CLM suite so that its requirements can be linked directly to the stories and code managed in Rational Team Concert (RTC). In this way, elements of code can be traced all the way back to the requirements.

What RRC does

Rational Requirements Composer allows a team of users to create IBM Rational Requirements Composer RRC 3requirements for a software project, and manage and review them together. RRC allows requirements to be stored together with all supporting material, such as diagrams. It provides a means of grouping the requirements, and recording comments, changes and approvals. It provides a mechanism for reviewing and approving requirements and integrates with downstream products, mainly Rational Team Concert (RTC), so developers can use approved requirements as the basis for planning and executing software development. RRC keeps track of the history of each requirement, so it can be traced back to its origins, and the integration with RTC extends this traceability so that stories and work items in RTC can also be traced back to their related requirements.


The main benefits of Rational Requirements Composer are as follows:

IBM Rational Requirements Composer RRC 3

  • Requirements are stored in one place, preventing the creation of several versions of the same requirement. If a requirement is changed, all stakeholders can see the change and comment on it.
  • Reviews can be structured and tracked so as to make sure that everybody who needs to review and approve a requirement does so.
  • Requirements can be grouped into logical sets that can form the basis of a release of software. The requirements in a group can be reviewed together and passed as a group to RTC for implementation.
  • Integration with development: RRC integrates with RTC, which handles project management and development in the CLM suite. It is possible to create a project which spans RRC and RTC. Requirements in RRC can thus be linked to stories (or tasks if using formal – waterfall – methods). The stories or tasks are implemented in code and thus code can be traced back to the requirements.
  • Integration with testing: RRC and RTC both integrate with Rational Quality Manager (RQM). RQM stores tests and these tests can be linked to RRC requirements, making it easy to ensure that every piece of functionality in a release has been tested (i.e. test coverage is complete).


Rational Requirements Composer includes the following features:

  • RRC is part of the IBM Rational Collaborative Lifecycle Management (CLM) suite and is built on the Jazz platform.IBM Rational Requirements Composer RRC 4
  • Requirements are stored as ‘artifacts’. An artifact may be a requirement of various different forms. The most basic is text, but an artifact may also take the form of a sketch (of a user interface), flow diagram or storyboard, amongst others.
  • Artifacts may be linked to each other to express hierarchical or other relationships. This makes it easy to find all the related artifacts of an artifact which, for example, is being changed.
  • Roles / permissions: different users can be granted different permissions at both the level of the entire RRC application and also at the level of each project. This ensures that only the appropriate people may access and/or modify requirements.
  • Requirements may be imported from outside sources such as spreadsheets and CSV files. This facilitates moving from a spreadsheet-based requirements system to RRC.
  • Requirements may be exported to a CSV file, or as a document or report.