Introduction

Rational DOORS and Rational Team Concert (RTC) support formal change management for the coordination and control of changes made to an existing technical solution. When DOORS and RTC are used together, a requirements change handling process can be fully implemented.

In early stages of a project, requirements and development artifacts will be updated without a formal change management process. For example, in DOORS, requirements modules may be created, attributes and views may be configured, and link modules may be defined. At some point, more rigor is needed around the process of requirements change.

This guideline describes the user interactions for a typical scenario for handling a requirement change request using DOORS and RTC.

Hierarchy of Change Requests

A system change request (SysCR) describes the need for a project-level or system-level change, and will commonly spawn multiple domain specific change requests, including requirements change requests (RCR).

The above graphic shows six work items in RTC, including a parent SysCR of work item type Enhancement. The SysCR has five child work items, each of work item type Change Request. A basic naming convention is used to differentiate the change domains. Only RCR is a common acronym.

The lifecycle of the Change Request work items is defined in RTC, and is illustrated below.

User scenario for handling a Requirements Change Request

In this example, a request for a change to the system comes from a Stakeholder. The Project Manager the SysCR, and creates one child requirements change request (RCR).

The RCR is worked by a Requirements Engineer and the proposed changes are submitted for review. At this point, the proposed changes are not visible by other DOORS users. After review of the changes, the RCR is approved or rejected in RTC. If approved, a DOORS manager applies the RCR in DOORS, at which point the changes become visible to the other users.

DOORS and RTC share status and data using the Open Services for Lifecycle Collaboration (OSLC) specifications for Change Management and Requirements Management. See www.open-services.net for information about OSLC.

Step 1: System change request from stakeholder

The Enhancement’s fields are updated, and the work item is saved, leaving it in the New state.

Step 2: Enhancement requests triaging

The Project Manager assesses the requested system change, and decides a change to the requirements is needed. An RCR is created and assigned to the Requirements Engineer. The RCR work item’s approval state is maintained in RTC, along with, but independent of the work item state.

The Project Manager starts work on the SysCR, putting the work item into the In Progress state.

The Project Manager creates the RCR work item, and assigns it to a Requirements Engineer. RTC will notify the Requirements Engineer that she has a newly assigned work item.

The Project Manager makes the RCR work item a child of the SysCR work item.

The Reviewers are set up, by creating one Approval with at least one Approver. An RTC Approval is a list of one or more required reviewers. A work item can have more than one Approval, but DOORS uses only the first.

Note in the above graphic, that the Approval is in the Pending state, while the work item is in the Created state, two independent states.

Step 3: Proposed modifications to requirements

The Requirements Engineer starts work on the RCR work item, and then edits the DOORS requirements for that RCR.

The Requirements Engineer opens the DOORS module, logs in to the CCM server (RTC), and chooses the work item to make modifications against. DOORS presents the list of all work items of type Change Request that are in the In Progress state, and owned by the person logged into the CCM server (Susan the Requirements Engineer in this example).

The requirements changes are made in one or more DOORS modules that are under configuration control, and saved. When saved, a link is automatically created from the RCR work item to the requirement changes and history as tracked by DOORS.

Selecting the link shows the Requirements Change Details.

Step 4: Submit requirements changes for review

The proposed changes are now associated with the RCR. The Requirements Engineer sends the RCR to review, and the reviewers are notified.

The RCR work item, in RTC, automatically changes to the In Review state.

Alternatively, the RCR can be sent to review directly in RTC by selecting Send to Review on the RCR work item.

The proposed changes are now ready for review, and the reviewers are automatically notified. One way to achieve notification, is to use an RTC query to show all work items of type Change Request that are in the In Review state and pending approval by the current user.

Step 5: Review Changes

The Reviewer reviews the changes that have been proposed for the RCR, and either approves or rejects the changes.

The Reviewer opens in Read Only mode the DOORS module(s) related to the RCR under review.

The Reviewer starts reviewing in DOORS the proposed changes by selecting Change Management > Requirements Change management > Review.

The reviewer is presented with a list of RCRs that are in the In Review state and that have been sent to review (see step 4), and then filtered to show only those applicable to the DOORS module under change control. For this list, DOORS does not consider the RCR's owner or the approval list. The reviewer selects the RCR and selects OK.

The review is presented with a review of proposed changes.

The reviewer uses RTC to approve or reject the proposed changes. In this example, the reviewer selects Approved.

The reviewer saves the work item, and the RCR work item automatically changes to the Approved state.

RTC sends notifications to the work item subscribers.

Step 6: Apply Changes

At this point, the changes are still not visible to all DOORS users. Only a DOORS user with Database Manager or Project Manager permission can apply the changes associated with the approved RCR. Once the changes are applied, they become visible to the other users.

With the DOORS module open in Read Only mode, the manager applies the changes by selecting Change Mangement > Requirements Change Request > Apply.

The appropriate RCR is selected and Apply is selected.

The changes are now visible to all.

The RCR work item is automatically closed.

Step 7: Update original Change Request

In this example, the original SysCR has just one child work item.

Now that all child change requests are closed, the Project Manager can resolve and close the SysCR work item.