IBM Rational DOORS getting started

A tutorial for IBM Rational DOORS and IBM Rational DOORS Web Access


Practices that effectively manage requirements have a positive impact on the success of systems and product development. IBM® Rational® DOORS® and IBM® Rational® DOORS® Web Access are designed to help you capture, trace, analyze, and manage changes to requirements in a collaborative manner. They also help you comply with industry standards.

This tutorial covers the benefits of using IBM Rational Doors in the requirements process. Each section of the tutorial describes how to use Doors to:

To gain the most from this tutorial, complete the exercises in order.

Set up a sample project to use in this tutorial

The sample data included is for use in this tutorial only. Do not deploy it in a production environment. Using the following steps, download the sample project archive AMR_tutorial.dpa (see the Download section), and install it to a sandbox area of your Rational DOORS database:

  1. Log in to DOORS as a project manager, a database manager, or a custom user who can create projects, as shown in Figure 1.
Figure 1. Log in to Rational DOORS with an account that can create projects
IBM Rational DOORS login window
IBM Rational DOORS login window
  1. If you see the Welcome screen, close it.
  2. From the Rational DOORS database explorer, create a sandbox folder by right-clicking the database in the left pane of the database explorer, and clicking File > New folder as shown in Figure 2. The folder will eventually store the AMR_tutorial.dpa project.
Figure 2. Create a new folder using the database explorer
Create new folder from the database explorer
Create new folder from the database explorer
  1. In the "New Folder – DOORS" window, name the folder Sandbox – Tutorial and click OK as shown in Figure 3. The new folder is created. You might need to press F5 to refresh the project so that the folder appears, as shown in Figure 4.
Figure 3. Enter information in the New Folder - DOORS window
The 'New Folder - DOORS' window of Rational DOORS
  1. Click to select the Sandbox – Tutorial folder as shown in Figure 4.
Figure 4. Select the Sandbox - Tutorial folder
'sandbox – tutorial' folder is selected
'sandbox – tutorial' folder is selected
  1. Click File > Restore > Project
  2. Browse to the archive file, AMR_tutorial.dpa, and click OK as shown in Figure 5.
Figure 5. Navigate to the project
'Restore Project – DOORS' window
'Restore Project – DOORS' window
  1. In the "Restore Project – DOORS" window, notice the name field, as shown in Figure 6. Project names must be unique throughout the Rational DOORS database. You might need to change the name of the sample to keep the name unique in the database.
Figure 6. Restore the “Automated Meter Reader - sample 1” project
'Restore Project – DOORS' window
'Restore Project – DOORS' window
  1. Click OK. The sample project is restored and can be used in this tutorial.

Manage requirements collaboratively, intuitively, and at scale

To manage requirements successfully, start by documenting them so that they are easy to interpret and navigate. In Rational DOORS, requirements are organized hierarchically, in a familiar document-style list, and with each requirement shown in context.

A navigation tree reveals the structure of the information set. A tabular view of the requirements helps you view and assign additional information to them, using an unlimited number of attributes.

DOORS is designed to manage all sizes of requirement documents. Multiple concurrent users can access the requirements database and can work on sets of requirements without conflicts.

Capture requirements information

Requirements describe what users want from a product or service.

The example in this tutorial is of a company that wants to build an automated meter reader (AMR). The company develops a solution to read water meters and provide service in an electronically automated and cost-effective manner. The AMR is intended to help water providers lower the cost of operations by more accurately measuring water usage and quickly gathering data.

To start developing requirements for this example, make a list of the information that is needed from the meter. The list can include these requirements:

  • The AMR should meet various performance objectives in areas of reliability, data analysis, conservation, and accuracy of data.
  • The AMR should be able to operate in the chosen market environments and should comply with any necessary standards and regulations, specific to each country.
  • The AMR should enable data to be collected by using various mechanisms, including wireless transfer to the central office and data collection through the use of hand-held devices.

Explore the file structure used by Rational DOORS database explorer

The database explorer is displayed when you log in. Use the database explorer to navigate through the projects, folders, and modules in the database, as shown in Figure 7.

Figure 7. The database explorer
The database explorer window
The database explorer window

Note the hierarchical structured: the database is at the top level, followed by the projects and folders, as shown in Figure 8.

The database can contain several projects. A project defines a work area and provides a way to organize or partition information. A project might not represent an actual project.

Folders are useful for organizing and managing content. All users can create folders.

Figure 8. Database structure
Database root, projects, folders, and modules
Database root, projects, folders, and modules


  1. Click Start > All Programs > IBM Rational > IBM Rational DOORS 9.5. DOORS opens and you are prompted for a user name and password.
  2. Type the user name and the password that your administrator provided, being sure to use correct capitalization. User names and passwords are case-sensitive.
  3. Click OK. If you see the Welcome screen, close it.
  4. The Rational DOORS Database Explorer is displayed showing the area of the database you have access to.

Open the Requirements folder in the sample project

  1. In the Navigation pane on the left, under the database, several projects and folders are listed. Find and expand the Automated Meter Reader- sample 1 project. The project might be in the Sandbox – Tutorial folder.
  2. Click the 01 Requirements folder. In the Content pane, three folders and four formal modules are shown.
  3. Optional: To quickly navigate to a folder that you often use, save it as a favorite. From the main menu, click Favorites > Add to favorites. You can switch between your favorite locations by selecting from the list on the Favorites tool bar. favorites tool bar.

Get familiar with how requirements are specified in DOORS formal modules

In DOORS databases information is stored in formal modules, as shown in Figure 9. For example, the manufacturing company building the Automated Meter Reader might create a project. The information for the AMR project might be stored in the following modules:

  • A "Vision" module, which describes the desired goals for the project, possibly highlighting why the project should be built and the benefits it will provide. (This module is not part of the provided sample data.)
  • A "Stakeholder requirements specification" module, which highlights the features that the stakeholders want in the AMR. This document supports the vision, and is an agreement between the stakeholders and the engineers of what to build.
  • A "Systems Requirements specification" module, which defines what a future system must do. This document explains how the stakeholder requirements will be realized.
  • A "Hazards and Risks" module, which describes the items that must be mitigated during project development.

In addition, the company might use other modules to detail the hierarchical levels of the requirements project.

Figure 9. Content in a formal module
Views, menus, object ID, module areas labeled
Views, menus, object ID, module areas labeled

A module looks like a rich text document, where information is hierarchically organized in sections and subsections. It also looks like a spreadsheet, in that attributes can be shown in columns.

Information in modules is individually managed so that each artifact can have specific attribute values, links, and history.

You can harvest information from other sources and import it to Rational DOORS. You can create a module, add information to a module, or exchange information between tools. When you work with modules, you can use one of three edit modes, as shown in Table 1.

Table 1. Module edit modes
Edit modeDescription
Read-only You can view the module, but you cannot edit it.
Exclusive You can edit the module, but other users can only view it.
Shareable You and other users can edit the module at the same time.

The status bar at the bottom of the module window indicates the edit mode that you are currently using. After you open a module, you can change its edit mode.

Open the Stakeholder requirements formal module and try edit modes

  1. Double-click Automated Meter Reader Stakeholder requirements. The module opens in a new window.

    Examine the bottom of the open module window and confirm you opened the module in exclusive edit mode. This mode does not prevent others from opening the same module in read-only mode, but it does prevent them from editing the content of this module. Alternately, you can open this module as read-only or shareable edit by right-clicking on the module in the database explorer and selecting one of those options. You can also switch the edit mode of an open module by selecting Edit > Edit Mode > Read-Only.
  2. Scroll up and down the module. The module uses rich text, tables, and images.
  3. Scroll left and right. The content section of the module shows three columns of information: ID, Stakeholder requirements for AMR system, and Status. The ID is a system-assigned value that is unique for every object within a module. Color coding is enabled so that you can quickly identify each requirement's status:
    • Green indicates approved.
    • Orange indicates postponed.
    • Blue indicates in progress.
    • Red indicates rejected.
    • Gray indicates obsolete.
    You control which information is shown and how it is shown, and you can save that information in views. You can use views to quickly switch perspectives of the data. For more information about views, see the section Change the perspective of the data.

Explore objects and attributes that capture requirement information

A formal module is composed of a collection of information, including headings, subheadings, information, and requirements. Information in each module is captured in objects.

An object is composed of the main content, such as the heading or the requirement, as well as other peripheral information, such as who created the object or the release it is planned for. All this information is stored in attributes.

Each object has a set of default attributes, such as Object Text, Created By, and Modified On. You can create your own attributes to store other information, such as priority and status.

Within a module, the objects are organized with numbered headings in a hierarchical structure. This structure makes the module read like a specification document.

The heading numbers work in the same way that automatic heading numbers work in a word processor, such as Microsoft Word. The numbers enable you to see the structure of the information in the module, and they automatically change if you change the structure of the information, for example, if you insert or delete objects.

The main column is displayed in the standard view of the module. Unlike other columns, which contain only one attribute, the main column can display two attributes, Object Heading and Object Text. The following table describes the main column attributes.

Table 2. Attributes of the main column in a module view
Attributes in the main columnDescription
Object Heading
This attribute is shown in bold, and has a heading number that is automatically generated by Rational DOORS.
For an example, see Figure 9. The object with IDAMR-SR 15 is a heading, because that object's Object Heading attribute is populated with Systems Requirements.
Object Text This attribute is shown in normal font.
For an example, see Figure 9. The object with ID AMR – SR 3 is a heading, because that object's Object Text attribute is populated with The control computer shall be capable ….

When a module is open, you can use the Module Explorer pane to quickly navigate the structure of the module. Expand or collapse the hierarchical sections represented in the module explorer by clicking on the plus (+) and minus (-) signs. Click on any object in the module explorer pane, to navigate to that object in your module.

Navigate the module by using the module explorer

  1. In the module explorer, note that the module has three main sections: 1. Introduction, 2. Stakeholder Requirements, and 3. Specific Description. Each section is further divided into subsections. Organizing information hierarchically is a best practice that helps structure the document and its content.
  2. From the module explorer, click the "2.4 Environment" section. In the module, notice the thin line above and below the object. The lines indicate which object is the current object.

Search for an object by its ID

  1. From the menu, click Edit > Find. The find and replace utility enables you to search for text in the module, replace text with different text, or find an object based on its ID.
  2. Find the object that has the ID 139. Click the Go To tab and for the number, enter 139.
  3. Click Go To and then close the window. The 139 object is selected.

Edit the main column of an object

  1. Double-click the requirement object with the ID 139. The requirement enters edit mode, and a cursor is placed at the beginning of the object.
  2. Move the cursor by using your mouse or the arrow keys, and revise the phrase previous 2 reading to be previous 3 readings.

Edit the attribute value of an object

  1. Double-click the Status column for an object, and from the list, select In Process.
  2. Click away from the cell for the change to take effect. The color of the main column is updated to reflect the status.

Create a new requirement

  1. Select the requirement with the ID 139.
  2. Create a new object at the same level as the current object by clicking the One Object at this level icon One Object at this level icon on the object toolbar.
  3. Even though the object appears to be a heading, as soon as you start typing, it will change to plain text. Type The human reader shall be able to locate the handheld unit.

Create a new section in the module

A new stakeholder is identified: Marketing and Research. In section 2, Stakeholder Requirements, add a new section:

  1. Click section 2. Stakeholder Requirements.
  2. Create an object that is one level below the current object by clicking the New object below icon New object below iconon the object toolbar.
    Note: If you start typing after you click the icon, the heading number disappears and the object is no longer a heading. Because you are creating a heading, click the Edit Object Heading icon Edit Object Heading icon on the object toolbar.
  3. For the section heading, type Marketing and Research. The subsequent sections are renumbered as needed.

Change the perspective of the data with module views

Different people need to see different information. Consider the following examples:

  • Managers are interested in scheduling and cost information.
  • Engineers are interested in technical design information.

You can create different views of modules for different users. Each view contains a subset of the objects or attributes that are in the module.

Figure 10. Use views to quickly switch perspectives of your data
Management and engineering views of same data
Management and engineering views of same data

Figure 10 shows two views of the design module for the Automated Meter Reader project.

  • The Management view shows the priority and cost attributes; this view shows only the high priority items.
  • The Engineering view contains all of the items and shows the design attribute.

In views, you can see the exact information that you need. You can filter out the data that you do not want to see. You can filter out objects, attributes, or both. Views can be saved, and toggling between them always reveals the latest information.

Switch views

You can quickly switch perspectives of the data by switching views.

  1. Look at the View toolbar, and notice that the current view is 1 Stakeholder Default View. This view represents three columns, the ID, Main, and Status. One thing to notice in this view is the color-coding to match the status of requirements.
  2. From the View toolbar, use the drop-down list to select view 00 All Attributes. This view hides the module explorer, and displays a number of attributes and their values in columns. Notice that the main column is no longer color-coded.
  3. The topic of traceability is discussed in a following section. However, it is worth noting that traceability views can reveal a lot of information about your project. From the View toolbar, use the drop-down list to select view 5 Multi Column Trace View. Notice the column headings: ID, Stakeholder requirements for AMR system, System Req, Subsystem req. Here you will see a traceability view, displaying relationships across different levels of requirements. Scroll up and down the view and notice that some stakeholder requirements are not linked downstream. What is the reason for this? Is it because the requirements are not approved yet? Could it be that these requirements have been dropped?

Create a view

You can add a column to display the Status attribute. You save this as a new view named 5b Multi Column Trace View, as shown in the following steps. This view will help you see the status of the requirement and the linked information.

  1. In the 5 Multi Column Trace View, click the Insert buttoninsert button from the Column toolbar.
  2. In the New Column window, select Attribute: Status.
    Note: The "New Column – DOORS" window allows you to select which attribute to display in a column, as shown in Figure 11.
Figure 11. Select which attribute to display in a column
New Column window showing attribute option.
New Column window showing attribute option.
  1. Leave the other options as default. Click Insert and Close. The new column appears as the last column.
  2. Drag the column to where you want it, probably after the main column.
  3. From the view menu, select View > Save. Name this view 5b Multi Column Trace View.

Modify the main column to display color based on an attribute value

  1. While in the 5b Multi Column Trace View, click the heading of column Stakeholder Requirements of AMR system; the main column heading.
  2. Click edit column properties edit column properties icon from the column toolbar.
  3. From the "Edit Column" window, confirm you selected the right column.
    Note: The "Edit Column" windows provides a number of options for what the column should display. Notice that there is one column for object heading and object text combined, as shown in Figure 12.
Figure 12. One column for the object heading and object text combined.
'Edit Column' window
  1. For Text Color, select By attribute: Status
    The "New Column – DOORS" window allows the column text color, and background color, to depend on an attribute value, as shown in Figure 13.
Figure 13. Column text color, and background color, can depend on an attribute value.
Edit column window options for text color
  1. Click OK.
  2. Notice the main column content reflects the value of the Status attribute.

Remove a column

Since the main column was modified to reflect the value of attribute Status, the column is no longer needed.

  1. While in the 5b Multi Column Trace View, click on the heading of column Status.
  2. Click Remove buttonremove button from the Column toolbar.

Update an existing view

  1. Save view 5b Multi Column Trace View to reflect the changes by clicking on View > Save As > OK
  2. Click Confirm to update the existing view.

Analyze linked data

  1. Look at requirement with ID 85. Hint: Use the Find tool. Why is this requirement not linked to subsequent levels of requirements?
    Answer: The color of the main column reveals that the requirement status is Obsoleted.
  2. Look at requirement with ID 69. This is a requirement with its Status attribute value set to rejected (as indicated by its color) but work has continued for several levels. The next step is to collaborate with the team to determine why it was rejected.

Collaborate through discussions

Discussions are a way for reviewers to exchange feedback about the content of a module or an object within the module.

In Rational DOORS you can maintain ongoing discussions about objects and modules instead of setting up linked review documents or adding new text attributes to the module under review,. The discussions are presented as part of the properties of the object or module.

You can create, view, and modify discussions about modules and about objects in modules.

Start a discussion thread

Requirement object 69 has been linked to substantial work. Examine the discussion to see if the team is still working on this requirement.

  1. From the main menu, click Discussions > New Object Discussion
  2. In the "New Discussion" window:
    • For the Summary field type: stakeholder Req. Rejected
    • For the Comment field type:Please assure that work on this requirement has stopped at all levels, as shown in Figure 14.
Figure 14. The “New Discussion” window displaying object 69
Summary line and comment field
Summary line and comment field
  1. Click Save.

Show the discussion thread in a column

Add a new column to show the discussion threads.

  1. From the Column toolbar, click the Insert icon insert icon .
  2. In the "New Column" window, in the Content section, click Discussions, and then click Browse, as shown in Figure 15.
Figure 15. Discussions displayed in a column
New column – DOORS window
  1. Click Display all discussions and all comment and click OK, as shown in Figure 16. The Discussion column is based on a DXL script, which runs and is always current
Figure 16. Browse DXL – DOORS windowBr
Selecting a DXL script for the discussion column
Selecting a DXL script for the discussion column
  1. Click Insert and Close.
  2. Locate object 69. Confirm the comments are in the newly added column.

Implement traceability across requirements, designs, and tests

The ability to trace requirements is essential if you want to demonstrate conformance and compliance. Traceability also enables you to analyze the impact requirement changes. To create traceability, you can link two requirements in Rational DOORS with a drag-and-drop action as described in the following section. To navigate between linked objects, click the link indicator, then click the link that you want to follow, and view the linked artifact, as described in the section Navigate between linked objects.

When you use a filter, you can quickly identify requirements that do not have links. Requirements without links might indicate unsatisfied requirements. In addition, you can configure views so that you can trace across multiple requirement documents as well as across use cases, models and designs, tests, and work items that are managed in other tools.

Create traceability

In DOORS, you can link related information, both within Rational, and to external sources and tools. This ability makes DOORS especially useful as an analytic and decision making tool.

Links provide traceability. You can check that what you are building satisfies your user requirements. For example, you can link a user requirement to the design features that fulfill that requirement. You can also link the design features to the verification tests for the feature, even if the test case is stored in IBM® Rational® Jazz™ Team Server and created by IBM® Rational® Quality Manager.

You can follow links in both directions. For example, if a test fails, you can discover which requirements are affected, by tracing the links from the test to the design features. You can also trace from the design features to the requirements.

Links are helpful for managing change. You can quickly trace how a change to one piece of data impacts the rest of your system.

Figure 17. Transverse linked information
Link indicators can be used to transverse links
Link indicators can be used to transverse links

Imagine that the engineering department tells you that they cannot deliver the solar-powered battery you were expecting. You can trace the links from the battery object back to the requirements that depend on it, and forward to the other features of the AMR that depend on having a solar-powered battery. You can quickly see the full impact of not having a solar-powered battery. You can make an informed decision about whether to use a conventional battery or whether to invest more money, time, and resources to help deliver a solar-powered battery.

Create traceability between different requirements levels

As an example, Stakeholder Requirement 38 must be linked with system requirement 44. Use the following steps to link the two:

  1. Make sure you are in the Automated Meter Reader Stakeholder Requirements module.
  2. Arrange the Stakeholder Requirement module window so that it occupies the left half of the screen. To make more room on the screen, hide the module explorer by clicking View > Module explorer.
  3. From the database explorer, open the module Automated Meter Reader System Requirements.
  4. Arrange the System Requirement module window so that it occupies the right half of the screen. To make more room on the screen, hide the module explorer by clicking View > Module explorer.
  5. In the Stakeholder Requirement module, find the requirement that has the ID 38.
  6. In the System Requirement module, find the requirement that has the ID 44.
  7. Drag-and-drop System Requirement 44 to Stakeholder Requirement 38. System Requirement 44 become pinks, to indicate that it is a link start. When you drop System requirement 44 over Stakeholder Requirement 38, you are presented with several options.
  8. Select Make Link From Start. At the end of the main column of Stakeholder Requirement 38, an orange arrow icon that points to the left is shown: orange arrow pointing left. That icon indicates the incoming link from System Requirement 44. System Requirement 44 is marked with a red arrow icon that points to the right red arrow pointing right. That icon indicates an outgoing link.

Navigate between linked objects

You can use the link indicators to navigate through linked information.

  1. Right-click the link indicator of System Requirement object 44. That requirement is linked to two requirements: Stakeholder Requirements 38 and 66.
  2. Follow the links to navigate between the linked information.

View traceability

The traceability that is captured in a module, across modules, and even across tools can be shown in columns in Rational DOORS. When you view traceability, you can identify scope creep or dropped requirements, monitor compliance to standards, and analyze end-to-end traceability.

Figure 18. Traceability and compliance across levels of requirements
View shows gaps in traceability across modules
View shows gaps in traceability across modules

Use saved views and you can quickly and consistently switch perspectives of the latest data.

Explore traceability views

Now that you know how to create views, take another look at the traceability views that are in the modules.

Manage changes and analyze their impact on requirements, designs, tests

You must manage change because it can impact your projects, potentially resulting in increased demands on resources, time, and budget. DOORS integrates with Rational change management tools to provide a change control process that can be tailored to the needs of your organization.

Requirement changes can impact related requirements, designs, and tests. Rational DOORS provides automatic notification of such changes by graphically indicating the links to changed objects that require investigation. By monitoring those notifications, you can reduce the chances of missing potentially impacted objects.

Track changes with the help of change bars and hover help

Rational DOORS tracks the changes that are made to the database; it records the history of changes to the database. For example, when you edit the attributes of an object, both the old value and the new value are recorded.

You can see who made changes and when they made them. You can look at the history of a module, an object, or the user sessions for a module.

DOORS also provides change bars that show changes at a glance.

The color of the change bar, the symbol on the bar, and the hover help indicate the status of an object.

Table 3. Change bar icons and descriptions
Change barExample hover helpDescription
new object iconnew object tool tip You created the object during the current session and have not saved the changes.
unsaved changes iconunsaved changes tooltip You edited the object during the current session and have not saved the changes.
last modified iconlast modified tooltip Since the last baseline of the module was created, someone changed the object and saved the changes.
baselined iconbaselined tooltip The object has not been changed since the module was last baselined.
deleted icondeleted tooltip Either the object was deleted before the last baseline of the module was created, or the history has not been loaded.
deleted after last baseline icondeleted after last baseline tooltip The object was deleted after the module was last baselined and history has been loaded

You can control which edits are tracked by change bars and recorded in the database history. If you do not want to know when a user edits a particular attribute, you can turn off change bars for that attribute.

Use baselines to capture a snapshot of a module

A baseline is a read-only version of a module. A baseline captures and preserves a moment in time.

When you create a baseline of a module, you create a copy of the module that nobody can edit.

Get familiar with the module history contained in the baseline

The baseline includes the following history about the module:

  • All of the attribute definitions and types that were created, deleted, or edited since the most recent baseline of the module.
  • All of the objects that were created, deleted, or edited since the most recent baseline of the module.
  • Every module session (every time the module has been opened) since it was first created.

Change the history of an object

  1. In the Automated Meter Reader Stakeholder Requirements module, go to object 139. Double-click the unsaved change symbol. The object properties open in the History tab.
  2. Select the last entry in the list. The entry notes the change that you made earlier.
  3. Toggle [V] View change with redline markup.
  4. Explore the history of this object to understand how it was modified since it was created. Note that the main content was edited, the object was moved, and an attribute value was updated.
  5. Save the module. The unsaved change indicator changes to yellow

Check modules for suspect links

Changes to objects in Rational DOORS can affect the validity of data in linked objects. When objects link to each other, if one of the linked objects is changed, the object that links to the changed object is marked as having suspect links. You can check modules for suspect links and show information about changes that caused links to be marked as suspect, as shown in Figure 19. The following steps show how to create a suspect link.

Create a suspect link

  1. In the Automated Meter Reader System Requirements module, switch the view to 6. Stakeholder Suspect Changes. That view has a column that shows suspect links, which are suspect because the other side of the linked object has changed. The view also has a column that explains the changes that caused the suspect links.
  2. Go to object 44.
  3. Use the link indicator to navigate to Stakeholder Requirement 38.
  4. In Stakeholder Requirement 38, change the text in the main column from without human intervention to automatically.
  5. Save the Stakeholder Requirements module.
  6. Return to the System Requirements module and observe that the change is reflected in the Change in Stakeholder Req. To Be Cleared column.
Figure 19. Suspect link indicators and information
Link indicator plus hint at source of problem
Link indicator plus hint at source of problem

Clear a suspect link

  1. In the Automated Meter Reader System Requirements module, click Analysis > Suspect links >Clear.
  2. From the Clear Suspect Links window, click the Out-links tab.
  3. Select Target Object, and from the corresponding list, select AMR-STK-38 as shown in Figure 20.
  4. Click Details.
  5. Click [V] View change as redlining. Note which change caused the suspicion.
  6. Click OK, and then click Clear.
  7. If other changes caused the object to be suspect, clear those changes.
  8. When you are finished, click Close.
Figure 20. Clearing suspect links
Drill down on suspect links to get more info
Drill down on suspect links to get more info

Integrate DOORS with other products and tools with OSLC

Requirements drive design, development, and testing. Therefore, a requirements management tool must link requirements to other tools that are used during the systems and software engineering lifecycle. Rational DOORS can integrate with many other systems and software engineering tools that are provided by IBM and third parties.

IBM's integration strategy is to support Open Services for Lifecycle Collaboration (OSLC). Rational DOORS adopts this strategy by using OSLC to provide integration to design, quality management, portfolio management, and change management tools. Rational DOORS is a core, integrated product in the Rational solution for systems and software engineering (SSE), which provides tools and practices for systems engineering and embedded software development.

For example, the integration between Rational DOORS and Rational Quality Manager improves the traceability between requirements and test projects and is a key part of the quality assurance process. When those products are integrated, requirements, and quality and test teams can collaborate in-context to ensure that all requirements are tested.

The integration provides several benefits to requirements and test teams:

  • Teams can ensure that all requirements are tested
  • Teams can ensure that all tests are based on requirements
  • Teams can monitor requirement changes by identifying and clearing suspicions
  • Teams can assess the impact of change
  • Teams can assess the project by using the Statement of Quality and Traceability reports

Eventually, the delivery team benefits from this effort by using the validated requirements and the tests written against them to validate system behavior and verify compliance as early as possible in the lifecycle of the project.

Another example is the integration between Rational DOORS and IBM® Rational® Rhapsody®.

Requirements definition is a critical part of the development lifecycle, but it is common for system-level requirements to be inconsistent and incomplete. Poorly expressed or misunderstood requirements can be clarified by modeling in tools such as Rational Rhapsody.

In Rhapsody, you can analyze and validate requirements, rapidly design by using prototypes, and deliver more consistent applications by using the Systems Modeling Language (SysML) and the Unified Modeling Language (UML). A Rational Rhapsody model specifies and plans the system that you are going to build.

By visualizing requirements in Rational Rhapsody, you gain a better understanding of the intended system behavior. With a finished model, you have an executable specification. The outcome of modeling the system behavior is a set of requirements that were validated through model execution. That validation avoids costly specification errors later in the development process.

Model-based systems engineering complements traditional requirements analysis techniques in these ways:

  • Organizes requirements into functional groups, or use cases
  • Identifies system functions and explores the dynamic behavior of the system by using sequence diagrams and model execution
  • Allocates system operations to decomposed architectures

By linking requirements to model elements, you can see which requirements are incorporated into the design.

You can integrate Rational Rhapsody with Rational DOORS through Design Manager, which uses Open Services for Lifecycle Collaboration (OSLC) to directly link requirements to model elements.

Alternatively, Rational Rhapsody and Rational DOORS can be integrated through the Rational Rhapsody Gateway.

Collaborate with stakeholders using Rational DOORS Web Access

IBM Rational DOORS Web Access gives distributed stakeholders visibility into requirements and enables them to trace the relationships between requirements. It also offers a secure online environment for hosting requirements discussions. With Rational DOORS Web Access, business users, developers, quality-assurance professionals, testers, marketers, and suppliers can review and discuss requirements that were authored by others without individual participants having to install extra software. All stakeholders can stay up-to-date with the latest project requirements and linked artifacts across the project and around the world.

Stakeholders can view requirements

By using a web browser, stakeholders across your organization can immediately access the latest project requirements and traceability relationships.

Navigate the Rational DOORS database by using the Rational DOORS Web Access cascading directory tree. When you open a module or document, the database navigation tree collapses to allow a full view of information in the center pane.

Use the breadcrumbs to track where you are in the broader database. The breadcrumbs also provide a path back to the hierarchy.

Arrange and manipulate the viewing panes and dynamically explore specific sections of large documents.

By using of the views that are defined in Rational DOORS, you have the flexibility to review requirements, other artifacts, and their attributes. As you switch between views, the information is dynamically updated based on the associated characteristics.

As requirements are highlighted in the center pane, Rational DOORS Web Access instantly updates the attributes of the requirement in the adjoining pane.

When you search through the document for a specific requirement, you receive results directly from the Rational DOORS database.

In Rational DOORS Web Access, you can view multiple documents or multiple sections of the same document in panes that you can organize. The flexible layout shows rich text, graphics, tables, and OLE objects.

Traceability is another key feature of DOORS Web Access. You can select from both incoming and outgoing links to explore the relationships that are associated with specific objects, and you can open multiple documents or multiple sections of the same document concurrently.

Start Rational DOORS Web Access and navigate to a requirement module

  1. Log in to Rational DOORS Web Access with a username and password provided by your administrator.
  2. In the database explorer, click Automated Meter Reader – sample 1 > 01 Requirements.
  3. Double-click Automated Meter Reader Stakeholder Requirements to open that module.

Explore the content of the module

Change the perspective of the data by switching views. Only the objects and attribute values that you have access to are shown.

Comment on an artifact

  1. Click Go To and find Artifact 69. The selected artifact is highlighted in gray. In the first column of the view, note the discussions indicator.
Figure 21. Discussion indicators for objects
Discussion indicators for objects
Discussion indicators for objects
  1. In the right pane, click Discussions. Review the discussion and comment.
  2. To reply to the comment, expand the comment; then click New Comment.
Figure 22. Reply to a comment by clicking “New Comment”
'New comment' button

In the New Comment window, add the comment and then close the window. The comment is now reflected in the discussion.

Stakeholders can discuss requirements

While requirements evolve, the relevant team members must discuss the requirements, clarify their understanding of them, and suggest improvements or changes to them. Through discussions, users of Rational DOORS Web Access can communicate and collaborate with each other and with Rational DOORS desktop client users. Multiple discussion topics can be opened against each requirement and the owner can close or re-open a discussion topic at any time. You can create, view, and modify discussions about modules and about objects in modules.

In the discussion pane, users can submit comments about a topic. As team members contribute, speech bubble icons indicate which requirements are being discussed. Each comment is marked with the name of the contributor and the date and time of the comment.

Stakeholders can collaborate across the supply chain

Rational DOORS offers a number of ways to exchange data. Some of them include:

  • Microsoft Word import and export
  • Comma-separated value (CSV)
  • Requirements Interchange Format (ReqIF)

Because Rational DOORS supports the OMG standard ReqIF, you can exchange requirements information between teams that are not on the same server, are using different tools; or are part of different organizations.

Figure 23. Initial database shared with two suppliers
Initial database shared with two suppliers
Initial database shared with two suppliers

ReqIF supports the distribution of requirements with an expectation to bring updates back to the original location. Such information can be one or more modules, with varying levels of exchange control. You can use views to control which data is exported.

You can also lock objects or attributes depending on your intent to share them. For example, you might not use locks for an export in one direction, where you have no expectation of the data returning. You might lock all shared data when you are sharing information for reference purposes; for example, to link to shared information. You can also lock only certain attributes or objects. You might lock only certain objects when you are working in a distributed environment and want feedback.

In the example in Figure 23, data was shared from the initial database to two suppliers. Each supplier was given a ReqIF package; each package might represent different access rights or views of the data. Each of the suppliers modified a few sections of the exchanged data and sent it back to the initial database owner. The initial database then merged the changes, showing the latest updates from both of the suppliers.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=IBM Rational DOORS getting started