A work item’s workflow specifies the lifecycle of the work item. Each work item type is assigned a workflow definition. Therefore, in addition to configuring a new Change Request work item type, a new Change Request work item workflow must be defined.

The creator of work item types and workflow definitions must have Jazz Project Administrator permissions. For this guideline, the RTC Eclipse client was used.

Defining a Change Request workflow

This section describes how to define in RTC a Change Request workflow. A graphical view of the workflow to be added is shown below.

This workflow was created to be used with Rational DOORS, and is recommended for Requirements Change Requests (RCR). Although optimized for DOORS, it is general enough to be used for other change requests, such as Model Change Requests, Software Change Requests, Test Change Requests, Documentation Change Requests, etc.

Open the RTC project area, and select the Process Configuration tab. Select Project Configuration > Configuration Data > Work Items > Workflows.

In the Workflows area, add a new workflow using the Add button. Enter the name of the workflow and a unique identifier. Enter a description.

RTC uses a state table instead of a statechart. Both provide equivalent definitions. The finished state table is shown below. The states and available actions are defined next. Also, set the Start Action as shown.  

All five states are defined and placed into the appropriate state group. The Show resolution field is set or cleared for each state. The Actions field is read-only and shows the actions that trigger outgoing transitions for the selected state.

All actions are defined next. Note that an Action name and Target State maps to a transition. For example the Rework action and In Progress state pair maps to the highlighted transition.

When the above transition occurs, RTC allows a resolution to optionally be set by the user (see Resolution options below), and then optionally shown (see Show resolution above).

The available Resolutions are defined next.

And the State Groups are defined.

Configuring automatic transitions for Approvals

When the change request work item is in the In Review state, the transition to Approved occurs when the Approve action is applied.

For the Change Request work item type, the application of the Approve action is automated to occur when all Approval states are set to Approved. And, when an Approval state is set to Rejected, the Rework action is automatically applied.

To automate the transitions, set the Approval Trackings as shown below.

To prevent the explicit transition to the Approved state without a completed Approval group, set the following Operation Behavior.

With this setting, when the Change Request is in the In Review state, and Approve action is applied, and then the Save is pressed, the transition is prevented and an error message is displayed. This guard enforces the proper use of Approvals.

Rationale for Reopen action

The Reopen action is included for the Rational DOORS integration, to recover from the accidental closure of an RCR work item before the changes are applied in DOORS.

The normal operation for the DOORS/RTC integration is for requirements changes to be applied in DOORS when an RCR is in the Approved state. In fact, DOORS allows the changes to be applied only when the RCR is in the Approved state. And when the changes are applied in DOORS, the RCR work item automatically transitions to the Closed state.

However, the user could instead select the Apply action in RTC, causing a transition of the RCR to the Closed state before the requirements changes have been applied in DOORS. And because DOORS can apply changes only when the RCR is in the Approved state, the Reopen action is provided to move the RCR back to the Approved state.