Observations and recommendations from Rational DOORS experts

Real-world examples of inefficiencies and how to correct them

This article discusses potential inefficiencies that the IBM Professional Service consultants have encountered in evaluating the architecture choices of many customers' implementations of IBM® Rational® DOORS® requirements management software. It provides several real-world examples and explains ways to use both automated tools and manual inspections to uncover inefficiencies.


Lewis Thorne (lthorne@us.ibm.com), Senior DOORS Consultant, IBM

Lew Thorne photoLew has more than 30 years experience working in systems engineering. He has spent the last 12 years working with companies to improve their requirements management and engineering disciplines, focusing on process improvement. Lew has worked with the Rational DOORS requirements management tool for the past 13 years, providing consulting and training services on the configuration, deployment, and use of DOORS in a broad spectrum of industries. He holds a bachelor’s degree in electrical engineering and master’s degree in business administration.

Nils Palsson (nils.palsson@uk.ibm.com), DOORS Product Consultant, IBM

Nils Palsson photoNils has been working in the area of requirements management since 2005, with experience in contract-driven technical projects at companies specializing in design and development of major information, software and hardware platforms. He holds a master’s degree in computer science and engineering from Institute of Technology, Linköping University, Sweden.

Doug Ishigaki (dishigaki@us.ibm.com), Technical Project Manager, Service Asset Development Team, IBM

Doug Ishigaki photoDoug has more than 25 years of experience in IT and systems software development and consulting. Currently, he is working in the area of developing and packaging service offerings, including the Rational DOORS Check-Up service offerings. He holds a bachelor’s degree from UCLA in linguistics and computer science.

18 November 2010

Also available in Chinese

IBM® Rational® DOORS® requirements management software provides comprehensive support for recording, structuring, managing, analyzing, and tracing requirements. Its underlying platform is a database. As with all database solutions, you can design either an efficient architecture (database schema) for storing the metadata definition, as well as your production data (such as your requirements, attributes, and relationships), or you can design an inefficient architecture that could introduce problems later in your project life cycle. You might not notice performance issues early, because the amount of data stored is small. But as your database grows, these issues are likely to become apparent.

This article describes potential inefficiencies that we have encountered in evaluating the Rational DOORS architecture of many of our customers. We explain ways to use both automated tools and manual inspections to uncover inefficiencies.

Observations and recommendations

Table 1 includes selective observations from several assessments of Rational DOORS implementations by senior IBM consultants. This table includes high-level recommendations derived from an analysis of detailed test result obtained by running automated check-up tools, by performing expert analysis, and by conducting interviews with key stakeholders.

Table 1. Assessment observations and recommendations
ItemObservationImpact or RiskRecommendationPriority
1No Linking schema enforcementNo control over what links occur and in what direction, leading to incomplete or partially complete traceability reports or a faulty assessment of the impact of a change request.Use DOORS linkset enforcement to control the integrity of your linking. This is included in the revised data structure.High
2Configuration of shareable editing mode is out of controlCauses long load times for modules and incorrectly configured access controlProvide mentoring in how to configure shareable edits so that the strategy for the revised data structure can be more robust.High
3Old baseline sets have been created but not used or closedBaselining strategy is lacking control, which could lead to problems with the integrity of your audit trailClear old baseline sets that are no longer required.
Provide mentoring in the proper use of baseline sets.
4Duplicate modules, folders, and many deleted items in the structure.Risk of updating wrong documentsClear duplicates and purge deleted items. Combine projects where possible.High
5Backups are not currently performedIncreases probability of
lost data
Back up the database on the server, archive projects as a backup, too.High
6Some modules contain large numbers of deleted objectsCan affect module load and save timesImplement a policy of purging deleted objects immediately after creating a baseline.Medium
7Database access control strategy is poorUsers who have RMCDA access at the root could delete critical dataDevelop a comprehensive and robust access control strategy that protects data integrity without stifling adoption of the tool.Medium
8Attributes inconsistent (for example: same names but different types)Inconsistent views, reports.Correct variations in attribute names and types.Medium

Additional details of some of the observations are provided below.

Linking schema

An incorrect, incomplete or nonexistent linking schema or a linking schema that is not enforced could lead to inaccurate traceability reports and a faulty assessment of a change request's impact.

The example in Figure 1 shows three linksets where the corresponding linkset pairing is missing from the source module. This could result in links being created that use a different link module. Usually this would be the ‘DOORS Links' link module which should not be used.

Figure 1. DOORS linkset traceability report
Data in spreadsheet columns, error reports

Larger view of Figure 1.

This example also shows several linksets without any links. This indicates that these linksets are incorrectly set up or that there are no traceability between requirements.

These are among the other potential linking problems that could lead to performance or usability issues:

  • An exorbitant number of linksets than necessary
  • All linksets residing in a single link module
  • Links in both directions between modules
  • Duplicate link modules within the same project

Stale links are links where the object at one end of the link has been deleted but the link is still visible.

Stale links can lead to performance issues. Figure 2 shows an example of a report of such problems.

Figure 2. Analysis of stale and orphan links
Screen capture of a report in spreadsheet format

Larger view of Figure 2.

In this example, there are two modules affected by stale links: one with outgoing stale links and one with incoming stale links. If users try to navigate the stale links, they get an error message. This can be confusing and might result in unnecessary support calls. Furthermore, stale links can impact the performance of traceability reports and affect change reports, as well as provide incorrect filter results when filtering links.

Module state

Modules that are locked, deleted, or cannot be opened can lead to performance issues and might indicate other issues with the Rational DOORS database. The example in Figure 3 shows one module that can't be opened, one that is locked, and several deleted modules.

Figure 3. Analysis of module states
Report shows problems in the Status column

Larger view of Figure 3.

Modules that cannot be opened could indicate that the database is corrupted or that customized DXL triggers are active in the module. If the module can't be opened, users will not be able to carry out any work in the module. This can potentially impact work schedules. In addition, traceability reports will not include links to or from this module, resulting in incorrect reports.

If the modules are locked and no users are currently logged in, this usually indicates that Rational DOORS crashed while the modules were being accessed, resulting in the modules staying locked. Locked modules cannot be updated, and any work in those modules would be stopped.

Access rights

It is best to perform a detailed analysis of the current access control architecture across all projects, folders, modules, and objects.

When too many users have RMCDA (Read, Modify, Create, Delete, Admin) or total access at the database root (or project level), critical data could be deleted, either maliciously or accidentally. Both cases can to be addressed by implementing a more stringent access control policy.

Figure 4. Analysis of access rights
Report on DOORS users and groups access rights

Larger view of Figure 4.

In this example, several users and groups have RMCDA access to items in the database. One good practice is that no individual users should be assigned RMCDA access rights. The group called "Everyone else" has that level of access to one module. This is a serious gap in the access policies and should be corrected.

Attributes and types

The consistency of attributes and types are important to the effective use of Rational DOORS. The next example, in Figure 5, shows a detailed report on the attributes and types. You can use this to find duplicate attributes as well as attributes with the similar names but different types or settings.

Figure 5. Analysis of types and attributes
Base Types and Attributes reports

Larger view of Figure 5.

In the Base Types example, there are three different types of priority lists, all with different values. To create consistent and comparable reports and views, the possible values should be the same for types with the same names.

Database metrics

In addition to the check-up, you can collect detailed measurements on the Rational DOORS database to analyze them. Here are examples of a few measurements:

  • The number of modules and the open time for each module
  • The number objects for each module, live and soft-deleted
  • The number of incoming and outgoing links
  • The number of attributes and DXL attributes
  • Date of the last baseline measurement
  • Whether the module generates any DXL errors when opened
  • The number of views for each module and the load time for each view

Using metrics helps pin down any performance or process-related issues.

About the Rational DOORS Check-Up

If you have been using Rational DOORS requirements management software for some time now, you're probably comfortable with your day-to-day operations. But is your toolset and environment optimized for your needs? Have you deployed Rational DOORS on your own and wondered whether you designed and implemented the architecture optimally? Or are you experiencing any performance issues or performance degradation? Perhaps a DOORS Health Check-Up is in order.

The experience that IBM Software Services teams have gained on these consulting engagements has been collected into a service called the IBM Rational DOORS Check-Up. It includes a pre-scoped set of activities, guidance, tools, and deliverables for quick responses. The observations and recommendations mentioned in this article come from real situations with IBM Rational customers.

The actual service engagement includes an experienced consultant who conducts onsite interviews with key stakeholders and users, expertise analysis of your requirements management process, and examination of your Rational DOORS database (both manual and automated analyses). The consultant then analyzes the information offsite and produces a report, which details issues uncovered in the onsite examination and addresses your specific operation. If it is appropriate, the report also suggests specific actions that can improve your Rational DOORS implementation to make it more effective and assure you that you are on the right track.

We recommend scheduling this check-up to occur approximately six months to a year after the start of a Rational DOORS deployment (sometimes earlier), especially if you embarked on the deployment on your own. For more information, download the IBM Rational DOORS Check-Up data sheet.



Get products and technologies

  • Get the free trial download for Rational DOORS Web Access.
  • Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.


  • Join the Rational DOORS forum to ask questions and participate in discussions.
  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups such as the Rational Café, and wikis.


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=Observations and recommendations from Rational DOORS experts