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).

In this topic	Related topics
Defining a Change Request Linking a Change Request to a Requirement, Task, or Other Work Item Adding Details, Attachments, or Hyperlinks to a Change Request Changing the State of a Change Request	Process Guidance Managing Change (CMMI) Workbooks Triage Workbook (CMMI) Field Reference Titles, IDs, Description, and History (CMMI) Assignments, Workflow, and Planning (CMMI) Areas and Iterations Change Request Fields (CMMI) Linking Work Items (CMMI) Attachments

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, click the name of the team member who is responsible for addressing the change request.

     Observação

     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 Area and Iteration lists, click the appropriate area and iteration.

     Observação

     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.

   • In the Priority list, click 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, click 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, click Yes if an issue is preventing the team from implementing the change request.

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 (Agile).

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, click 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.

     Observação

     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, click 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. Click Save Work Item.

   Observação

   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, click the All Links tab, and then click New.

   The Add new Linked Work Item dialog box opens.

   

2. In the Link Type list, click 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, click 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. Click 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. Click Save Work Item.

To link several existing work items to a change request

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

   The Add Link to Change Request dialog box opens.

   

2. In the Link Type list, click 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.

   • Click Browse to specify work items from a list.

     The Choose linked work items dialog box appears.

     

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

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

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

4. Click OK.

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

5. Click Save Work Item.

   Observação

   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. Click the Details, Justification, or Analysis tab, and type information in the boxes.

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

   Observação

   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 Fields (CMMI) and Titles, IDs, Description, and History (CMMI).

2. Click 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.

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

   • Click Add, click 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, click OK.

2. Click Save Work Item.

To add a hyperlink to a change request

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

   

2. In the Link Type list, click 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. Click OK.

6. Click 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 Assignments, Workflow, and Planning (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, click 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. Click 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:

Reason	When to use	Additional actions to take
Accepted	When the change control board approves the change request for the team to implement in the current iteration.	Assign the change request to the team member who will implement it.
Investigate	When the change control board determines that the impact of the request must be investigated before the board will accept it.	Return the change request to the Proposed state when the investigation is complete.

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:

Reason	When to use	Additional actions to take
Rejected	When the change control board determines that the team cannot implement the request or the customer does not need it.	None.

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:

Reason	When to use	Additional actions to take
Code Complete and System Tested	When the team has checked in code to implement a change request and all system tests have passed.	Assign the change request to the team member who will test it.

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:

Reason	When to use	Additional actions to take
Abandoned	When the change request is no longer considered necessary to implement.	None.
Out of Scope	When the team has insufficient resources or another issue is blocking the team's ability to implement the change request for the current iteration.	Update the Iteration field to specify in which iteration the team might implement the change request. If the change request is deferred to the next release of the software, leave the Iteration field blank, but describe in detail why the change request was deferred and when the team should implement it.

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:

Reason	When to use	Additional actions to take
Validation Test Passed	When the change request has passed all validation tests.	Assign the change request to the product owner.

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:

Reason	When to use	Additional actions to take
Validation Test Failed	When the validation test or tests indicate that one or more customer expectations have not been met.	The tester creates bugs for the test failures and assigns the change request to the lead developer, who determines how to address the problems.

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:

Reason	When to use	Additional actions to take
Closed in error	When a team member accidentally closed a change request.	Make sure that the implementation tasks, test cases, and details for the change request are well defined and sufficient to support its development.

• 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 Fields (CMMI)

Other Resources

Work Items and Workflow (CMMI)