Change Request (CMMI)

In this topic, you can learn how to fill in the details of a change request work item. A team can use the change request work item to track a proposed change to some part of the product. You can create a change request whenever a change is proposed to any work product that is under change control. For more information, see Managing Change (CMMI).

For information about how to create this type of work item, see Work Items and Workflow (CMMI).

Required Permissions

To view a change request, you must be a member of the Readers group or your View work items in this node must be set to Allow. To modify a change request, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow. For more information, see Managing Permissions.

Defining a Change Request

The work item form for a change request stores data in the fields and tabs that are the following illustration shows:

When you define a change request, you must define the Title. You can leave all other fields blank or accept their default values.

To define a single change request

1. In the top section of the work item form, specify one or more of the following types of information:

   • In Title (Required), type a short description.

     Good titles indicate the area of the product that is affected and how it is affected. At any time, you can update the text to more accurately define the change and the areas of work that are affected

   • In the Assigned To list, choose the name of the team member who is responsible for addressing the change request.

     Note

     You can assign work items only to members of the Contributors group.

     If you leave the change request unassigned, it is automatically assigned to you.

   • In the State list, leave the default value, Proposed.

     By default, the value of the Reason field is New. For more information about this field and how you can use it to track workflow, see Changing the State of a Change Request later in this topic.

   • In the Priority list, choose the level of importance for the change request on a scale of 1 (most important) to 4 (least important).

     By default, this value is 2.

   • In the Triage list, choose the triage substate.

     This field identifies the level of triage that has been decided for any change request that is in the Proposed state. Valid values are Pending (default), More Info, Info Received, and Triaged.

   • In the Blocked list, choose Yes if an issue is preventing the team from implementing the change request.

   • In the Area and Iteration lists, choose the appropriate area and iteration.

     Note

     Your project administrator defined the Area and Iteration tree hierarchies so that team members can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

2. On the DETAILS tab, provide as much detail as you want to describe exactly what the team must change.

   Provide as much detail as possible in the change request to ensure that a developer can implement it and a tester can test it. Your team can use this information to create work items for tasks and test cases. For more information, see Task (CMMI) and Test Case.

3. On the JUSTIFICATION tab, provide as much detail as you want to describe the value to the customer or the product that the change request implements.

4. On the ANALYSIS tab, choose each text box, and provide details for the impact that the change request will have on the following areas:

   • Impact on architecture

   • Impact on user experience

   • Impact on test

   • Impact on design/development

   • Impact on technical publications

   You can indicate the specific areas that are affected, in addition to the costs to implement the change.

5. On the OTHER tab, specify the following types of information:

   • In the Original Estimate box, type a number that represents the hours of work that the change request will take to implement.

     Note

     In general, you define the following field later in the development cycle and not when you first define the change request.

   • In the Integrated in list, choose the build name or number in which the change request is integrated by the development team.

6. On the ALL LINKS tabs, link the change request to one or more other work items, such as requirements or tasks.

7. On the ATTACHMENTS tab, you can attach specifications, images, or other files that provide more details about the change request to be implemented.

   For more information, see the following sections later in this topic:

   • Linking a Change Request to a Requirement, Task, or Other Work Item

   • Adding Details, Attachments, or Hyperlinks to a Change Request

8. Choose Save Work Item.

   Note

   After you save the change request, the identifier appears in the title under the work item toolbar.

Linking a Change Request to a Requirement, Task, or Other Work Item

By creating relationships between change requests and other work items, you can plan projects more effectively, track dependencies more accurately, view hierarchical relationships more clearly, and find relevant information more quickly. From the work item form for a change request, you can create a work item that is automatically linked to the change request, or you can create links to existing work items.

You use the Links tab to create specific types of links to specific types of work items. For more information, see Linking Work Items [CMMI].

To create and link a task, bug, requirement, or other work item to a change request

1. Open the work item form for the change request, choose the All Links tab, and then choose New.

   The Add new Linked Work Item dialog box opens.

   

2. In the Link Type list, choose the type of link that you want to create based on the type of work item to which you are linking.

   • To link to a task or a bug, create a Child link.

   • To link to a requirement, a risk, or an issue, create an Affected By link.

   • To link to a test case, create a Tested By link.

   • To link to any other type of work item, create a Related or other type of link that represents the relationship that you want to track.

3. In the Work Item Type list, choose the type of work item that you want to create.

4. In Title, type a short but specific description of the proposed change.

5. (Optional) In Comment, type additional information.

6. Choose OK.

   A work item form for the type of work item that you specified opens with the information that you have provided.

7. Specify the remaining fields as described in the following topics:

   • Requirement (CMMI)

   • Task (CMMI)

   • Bug (CMMI)

   • Test Case (CMMI)

   • Issue (CMMI)

   • Risk (CMMI)

   • Review (CMMI)

8. Choose Save Work Item.

To link several existing work items to a change request

1. Open the work item form for the change request, choose the All Links tab, and then choose Link to.

   The Add Link to Change Request dialog box opens.

   

2. In the Link Type list, choose the type of link that you want to create based on the type of work item to which you are linking.

   • To link to a task or a bug, create a Child link.

   • To link to a requirement, risk, or an issue, create an Affected By link.

   • To link to a test case, create a Tested By link.

   • To link to any other type of work item, create a Related or other type of link that represents the relationship that you want to track.

3. Perform one of the following actions:

   • In Work item IDs, type the IDs of the work items that you want to find. Separate IDs by commas or spaces.

   • Choose Browse to specify work items from a list.

     The Choose linked work items dialog box appears.

     

     In the Saved query list, choose a query that contains the work items that you want to add. For example, you can choose Open Work Items, Active Bugs, or Active Tasks.

     Choose Find, select the check box next to each work item that you want to link to the change request, and then choose OK.

   • (Optional) Type a description for the items to which you are linking.

4. Choose OK.

   For more information, see Find Work Items to Link or Import.

5. Choose Save Work Item.

   Note

   Both the change request and work items to which you linked are updated.

Adding Details, Attachments, or Hyperlinks to a Change Request

As more information becomes available, you can add it to a change request in the following ways:

• Type information in the text boxes on the Details, Justification, or Analysis tab.

• Attach a file.

  For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

• Add a hyperlink to a Web site or to a file that is stored on a server or Web site.

To add details to a change request

1. Choose the Details, Justification, or Analysis tab, and type information in the boxes.

   You can format information to provide emphasis or capture a bulleted list.

   Note

   Every time that a team member updates the work item, its history shows the date of the change, the name of the team member who made the change, and the fields that changed.

   For more information, see Change Request Field Reference (CMMI) and Requirement Field Reference (CMMI).

2. Choose Save Work Item.

To add an attachment to a change request

1. On the Attachments tab, perform one of the following actions:

   • Drag a file into the attachment area.

   • Choose or press CTRL-V to paste a file that you have copied.

   • Choose Add, choose Browse, and, in the Attachment dialog box, type or browse to the name of the file that you want to attach.

     (Optional) In the Comment box, type additional information about the attachment. To close the Attachment dialog box, choose OK.

2. Choose Save Work Item.

To add a hyperlink to a change request

1. On the All Links tab, choose Link to.

   

2. In the Link Type list, choose Hyperlink.

3. In the Address box, perform one of the following actions:

   • If the target is a Web site, type the URL or copy it from your Internet browser, and paste it into the Address box.

   • If the target is a server location, type its UNC address.

4. (Optional) In the Comment box, type additional information about the hyperlink.

5. Choose OK.

6. Choose Save Work Item.

Changing the State of a Change Request

The triage team or product planning meeting can review these work items to analyze, accept, and reject proposed changes. When a change request is accepted, the team can generate tasks to implement the change. After the team implements the change, the team eventually closes the change request.

For more information about the data fields that you can use to track work item states, see Tracking Status and Assignments [CMMI].

You can use the following states to track the progress of change requests:

• Proposed

• Active

• Resolved

• Closed

Any team member can change the state of a change request.

By default, each change request is in the Proposed state when you create the work item. When a team accepts a change request for the current iteration, the work item moves to the Active state, and the team analyzes it to determine its implementation details and create tasks. When the tasks are complete and system tests show that the team has successfully implemented the change request, a team member moves it to the Resolved state. Finally, when the team validates a change request, a team member moves it to the Closed state.

To change the state of a change request

1. Open the change request.

2. In the State list, choose Active, Resolved, or Closed.

   • If you change the state from Proposed to Active, the Reason field automatically changes to Accepted.

   • If you change the state from Active to Resolved, the Reason field automatically changes to Code Complete and System Test Passed.

   • If you change the state from Resolved to Closed, the Reason field changes to Validation Test Passed.

3. Choose Save Work Item.

Typical workflow progression: A team member creates a change request in the Proposed state with the default reason, New. A team member changes the state of the change request from Proposed to Active with the default reason, Accepted. A team member changes the state of the change request from Active to Resolved when it is code complete and system tests have passed. A team member changes the state of the change request from Resolved to Closed when the team has validated that it successfully meets customer expectations. Atypical transitions: A team member changes the state of the change request from Proposed to Closed with the default reason, Rejected. A team member changes the state of the change request from Active to Proposed with the default reason, Investigation Complete. A team member changes the state of the change request from Active to Closed after the team determines that the change request is out of scope or not relevant. A team member changes the state of the change request from Resolved to Active after the changed code fails a validation test. A team member changes the state of the change request from Closed to Active after the team determines that the work item was closed in error or is now in scope.

Change Request State Diagram

Proposed (New)

A team member can create a change request work item when the team finds a bug or another event identifies a necessary change in a work product that is under change control.

The following data fields are automatically captured when a team member creates a change request:

• Created By: Name of the team member who created the change request.

• Created Date: Date and time when the change request was created, as recorded by the server clock.

From Proposed to Active

Change requests describe changes to the product or a baseline. A change control board must review, investigate, and accept or reject each change that the team proposes.

A team member can move a change request from the Proposed state to the Active state for the reasons in the following table:

The following data fields are captured when a team member changes the state of a change request to Active:

• Activated By: Name of the team member who activated the change request.

• Activated Date: Date and time when the change request was activated, as recorded by the server clock.

• State Change Date: Date and time when the state of the change request was changed.

From Proposed to Closed

A team member can close a change request that is in the Proposed state because of the reason in the following table:

The following data fields are captured when a team member closes a change request:

• Closed By: Name of the team member who closed the change request.

• Closed Date: Date and time when the change request was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the change request was changed.

Active

The team should implement only those change requests that are in the Active state. For active change requests, team members should create tasks for writing code, testing, and documenting the change. When all tasks are complete, a member of the team moves the change request to the Resolved state. You can also close a change request if the team abandons it or determine that it is out of scope.

From Active to Resolved

A team member can resolve an active change request for the reason in the following table:

The following data fields are captured when a team member resolves an active change request:

• Resolved By: Name of the team member who resolved the change request.

• Resolved Date: Date and time when the change request was resolved, as recorded by the server clock.

• State Change Date: Date and time when the state of the change request was changed.

From Active to Closed

A team member can close an active change request because of one of the reasons in the following table:

The following data fields are captured when a team member closes an active change request:

• Closed By: Name of the team member who closed the change request.

• Closed Date: Date and time when the change request was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the change request was changed.

From Active to Proposed

When the change request was activated as Investigate, you change its state to Proposed after the team completes its investigation. The following data fields are captured when you change the state of an active change request to Proposed:

• Changed By: Name of the team member who changed the state of the change request.

• State Change Date: Date and time when the state of the change request was changed.

Resolved

After a team implements a change request, the lead developer sets the state of the request to Resolved and assigns it to a tester so that testing can start.

A resolved change request has been implemented and passes system tests. However, the team must validate resolved change requests with the customer to ensure that the team has implemented the request according to customer expectations. If validation tests pass, the team closes the change request. Otherwise, it is reactivated for further work.

From Resolved to Closed

A team member can close a resolved change request for the reason in the following table:

The following data fields are automatically captured when a team member closes a resolved change request:

• Closed By: Name of the team member who closed the change request.

• Closed Date: Date and time when the change request was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the change request was changed.

From Resolved to Active

A team member can reactivate a resolved change request for the reason in the following table:

The following data is automatically captured when a team member reactivates a resolved change request:

• Activated By: Name of the team member who reactivated the change request.

• Activated Date: Date and time when the change request was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the change request was changed.

Closed

The team should no longer work on a closed change request. A change request is closed either when the change control board has rejected it or when the team has successfully implemented, verified, and validated the request.

A member of the team, usually a business analyst or program manager, can reactivate a closed change request if it comes back into scope.

From Closed to Active

A team member can reactivate a closed change request for the reason in the following table:

• The following data is automatically captured when a team member reactivates a closed change request:

• Activated By: Name of the team member who reactivated the change request.

• Activated Date: Date and time when the change request was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the change request was changed.

See Also

Concepts

Change Request Field Reference (CMMI)

Work Item Field Reference for Visual Studio ALM

Other Resources

Work Items and Workflow (CMMI)