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
|Item||Observation||Impact or Risk||Recommendation||Priority|
|1||No Linking schema enforcement||No 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|
|2||Configuration of shareable editing mode is out of control||Causes long load times for modules and incorrectly configured access control||Provide mentoring in how to configure shareable edits so that the strategy for the revised data structure can be more robust.||High|
|3||Old baseline sets have been created but not used or closed||Baselining strategy is lacking control, which could lead to problems with the integrity of your audit trail||Clear old baseline sets that are no longer required.|
Provide mentoring in the proper use of baseline sets.
|4||Duplicate modules, folders, and many deleted items in the structure.||Risk of updating wrong documents||Clear duplicates and purge deleted items. Combine projects where possible.||High|
|5||Backups are not currently performed||Increases probability of |
|Back up the database on the server, archive projects as a backup, too.||High|
|6||Some modules contain large numbers of deleted objects||Can affect module load and save times||Implement a policy of purging deleted objects immediately after creating a baseline.||Medium|
|7||Database access control strategy is poor||Users who have RMCDA access at the root could delete critical data||Develop a comprehensive and robust access control strategy that protects data integrity without stifling adoption of the tool.||Medium|
|8||Attributes 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.
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
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
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.
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
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.
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
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
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.
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.
- Browse the Rational DOORS developerWorks page for links to technical articles and many related resources, and explore the Rational DOORS Information Center, which includes the documentation for installation and use.
Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Follow developerWorks on Twitter.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Explore Rational self-paced and instructor-led online courses, which range from introductory to advanced levels. The courses are available for purchase, although some "Getting Started" courses are free.
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.