Rational Requirements Composer Project Sizing Recommendations

This article provides information about IBM Rational Requirements Composer (RRC) 4.x project sizing in terms of number of artifacts in projects.

Sizing guidelines for Rational DOORS Next Generation have appeared as part of the Performance Datasheets And Sizing Guidelines since the 4.x release of Rational Requirements Composer. Also see the RDNG migration guide for equivalent guidance for the 6.x release.

Artifact numbers, Queries and Performance

Data being displayed in the RRC application is fetched using SPARQL queries. These queries are requested by the RRC application and are executed on the Jazz Team Server (JTS). RRC takes care of working with the result set.

The scope of any query in RRC is a project. This optimizes time and resource consumption. However, if all the data is placed in one project, this scoping has very little effect. The resource consumption and processing time of queries is directly proportional to the size of the project it is being run against. The size depends on the number of requirement artifacts like heading, text, images, tables, modules, folders, etc.

Keeping this in mind, having the right partition of data into multiple projects and folders in the repository is important to get optimal performance out of Rational Requirements Composer.

Project Size

A good size for a project, module, and folder would be:

50,000 artifacts per project
Artifacts per project should not exceed 50,000 and these include folders, modules, module artifacts and collections. In case there are a high number of images, tables which in turn increase size of artifacts, consider a lower artifact number per project.

4000 artifacts per module and folder
This also helps to improve readability. As a best practice start with creating a folder structure in the project and avoid adding too many artifacts directly in the root folder.

There are other artifact types that need consideration, number of links within project and cross project that could increase as well (based on the above project, module and folder size limits an average of 4 links-per-requirement is considered good).

Identifying Project Size

You can periodically monitor the number of artifacts/resources in the repository/project. The quickest way to identify that the number of artifacts in the repository is based on the artifact ID of the most recently created artifact. However, since the ID is unique across the entire repository, it would not give you the right information if you looking for number of artifacts within the project.

To identify the number of artifacts within a specific project you can run a SPARQL query. SPARQL queries can be executed on the RRC built-in administration panel https://<server>:<port>/rm/rmadmin, Under Debug > SPARQL Query

In the query window, set the custom SPARQL query scope to the project and check pre-count. Run the following query

PREFIX dc: <http://purl.org/dc/terms/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rm: <http://www.ibm.com/xmlns/rdm/rdf/>
PREFIX rmTypes: <http://www.ibm.com/xmlns/rdm/types/>
PREFIX rrmReview: <http://www.ibm.com/xmlns/rrm/reviews/1.0/>
PREFIX nav: <http://com.ibm.rdm/navigation#>
PREFIX jfs: <http://jazz.net/xmlns/foundation/1.0/>
SELECT (count (distinct *) as ?count)
WHERE {
?resource rdf:type rm:Artifact
}LIMIT 1

Under the results column you would see 1/xxxxx where xxxxx is the number of resources in the project the query is being run against. Following is a snapshot of the results



This includes artifacts, artifacts in modules, modules, collections, and folders. If the number is above 50,000, it would be a first indication for you to start with a new project area.

To determine the number of links replace rm:Artifact with rm:Link in the above query.

Repository Limit

There is no theoretical limit on the number of artifacts that can be created in projects/modules. The largest current tested limit is 315,000 artifacts in a repository. These artifacts were spread across 75 projects.

The test data used for these sizing tests represents an extremely large repository compared to most customer environments. We chose this data size to test the limits of the RRC application with unusually large data volume. The data shape details are shown in the table below.

For details on the results of the scalability and performance tests conducted in an RRC-only deployment, with record of hardware/topology used along with the data volume tested against, see the following Sizing and Tuning Guides:

• Rational Requirement Management 4.0.1 Sizing and Tuning Guide
• Rational Requirement Management 5.0 Sizing and Tuning Guide

Also see

• DOORS Next Generation 4.0.1 Performance report which was based on a data volume of 200,000 artifacts spread across 10 projects with 22 modules in each project.
• DOORS Next Generation 5.0.1 Performance report based on similar data sizes

Topology Selection

Consider the enterprise topology where the Jazz Team Server (JTS) and the RRC application resides in their own JVM.

Look up the Recommended Topologies described in the deployment wiki

Related topics: RDNG Migration guide Sizing Guidelines, Performance Datasheets And Sizing Guidelines

External links:

• IBM

Additional contributors: BenSilverman, PaulStrachan, StefDijk

Questions and comments:

• What other performance information would you like to see here?
• Do you have performance scenarios to share?
• Do you have scenarios that are not addressed in documentation?
• Where are you having problems in performance?

Warning: Can't find topic Deployment.PerformanceDatasheetReaderComments