Topics

Definitions To top of page

Change Request (CR) - A formally submitted artifact that is used to track all stakeholder requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the Change Request, including all state changes along with dates and reasons for the change. This information will be available for any repeat reviews and for final closing.

Change (or Configuration) Control Board (CCB) - The board that oversees the change process consisting of representatives from all interested parties, including customers, developers, and users. In a small project, a single team member, such as the project manager or software architect, may play this role. In the Rational Unified Process, this is shown by the Change Control Manager role.

CCB Review Meeting - The function of this meeting is to review Submitted Change Requests. An initial review of the contents of the Change Request is done in the meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group. This meeting is typically held once per week. If the Change Request volume increases substantially, or as the end of a release cycle approaches, the meeting may be held as frequently as daily. Typical members of the CCB Review Meeting are the Test Manager, Development Manager and a member of the Marketing Department. Additional attendees may be deemed necessary by the members on an "as needed" basis.

Change Request Submit Form - This form is displayed when a Change Request is being Submitted for the first time. Only the fields necessary for the submitter to complete are displayed on the form.

Change Request Combined Form - This form is displayed when you are reviewing a Change Request that has already been submitted. It contains all the fields necessary to describe the Change Request.

The following outline of the Change Request process describes the states and statuses of Change Requests through their overall process, and who needs to be notified during the lifecycle of the Change Request. The general process associated with Change Requests is described in Activity: Establish Change Control Process.

Sample Activities for Managing Change Requests To top of page

The following example shows sample activities that a project might adopt for managing a Change Request (CR) throughout its lifecycle (click on items in the diagram to view descriptions):

CR closed Test Failed Verify Changes in Release Build CR Closed Confirm Duplicate or Reject Submitted More Info Update CR Submitted Reject Duplicate Verified Verify Changes in Test Build Test Failed Make Changes Resolved Reject Duplicate Verify Changes in Test Build Assigned Assign and Schedule Work Submit CR Assign and Schedule Work Opened Review CR Postponed Submitted Change Request Change Control Board Submit CR Diagram described in caption above.

Sample Change Request Management (CRM) Process Activity Descriptions:

Activity Description Responsibility
Submit CR Any stakeholder on the project can submit a Change Request (CR). The Change Request is logged into the Change Request Tracking System (e.g., Rational ClearQuest) and is placed into the CCB Review Queue, by setting the Change Request State to Submitted. Submitter
Review CR The function of this activity is to review Submitted Change Requests. An initial review of the contents of the Change Request is done in the CCB Review meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group. CCB
Confirm Duplicate or Reject If a Change Request is suspected of being a Duplicate or Rejected as an invalid request (e.g., operator error, not reproducible, the way it works, etc.), a delegate of the CCB is assigned to confirm the duplicate or rejected Change Request and to gather more information from the submitter, if necessary. CCB Delegate
Update CR If more information is needed (More Info) to evaluate a Change Request, or if a Change Request is rejected at any point in the process (e.g., confirmed as a Duplicate, Rejected, etc.), the submitter is notified and may update the Change Request with new information. The updated Change Request is then re-submitted to the CCB Review Queue for consideration of the new data. Submitter
Assign & Schedule Work Once a Change Request is Opened, the Project Manager will then assign the work to the appropriate team member - depending on the type of request (e.g., enhancement request, defect, documentation change, test defect, etc.) - and make any needed updates to the project schedule. Project Manager
Make Changes The assigned team member performs the set of activities defined within the appropriate section of the process (e.g., requirements, analysis & design, implementation, produce user-support materials, design test, etc.) to make the changes requested. These activities will include all normal review and unit test activities as described within the normal development process. The Change Request will then be marked as Resolved. Assigned Team Member
Verify Changes in Test Build After the changes are Resolved by the assigned team member (analyst, developer, tester, tech writer, etc.), the changes are placed into a test queue to be assigned to a tester and Verified in a test build of the product. Tester
Verify Changes in Release Build Once the resolved changes have been Verified in a test build of the product, the Change Request is placed into a release queue to be verified against a release build of the product, produce release notes, etc. and Close the Change Request. CCB Delegate (System Integrator)

Sample States and Transitions for a Change Request To top of page

The following example diagram shows sample states and who should be notified throughout the lifecycle of a Change Request (CR) [Click on items in the diagram to view descriptions]:

CCB Review Meeting More Info More Info Update CR Update CR Confirm Duplicate or Reject Verify Changes in Release Build Closed More Info Verified Duplicate Reject CCB Review Meeting Submit CR Submitted Test Failed Verify Changes in Test Build Resolved Make Changes Opened Assign and Schedule Work Assigned Postponed Change Request Diagram described in caption above.

Sample Change Request Management (CRM) State Descriptions:

State Definition Access Control
Submitted This state occurs as the result of 1) a new Change Request submission, 2) update of an existing Change Request or 3) consideration of a Postponed Change Request for a new release cycle. Change Request is placed in the CCB Review queue. No owner assignment takes place as a result of this action. All Users
Postponed Change Request is determined to be valid, but "out of scope" for the current release(s). Change Requests in the Postponed state will be held and reconsidered for future releases. A target release may be assigned to indicate the timeframe in which the Change Request may be Submitted to re-enter the CCB Review queue. Admin

Project Manager

Duplicate A Change Request in this state is believed to be a duplicate of another Change Request that has already been submitted. Change Requests can be put into this state by the CCB Review Admin or by the team member assigned to resolve it. When the Change Request is placed into the Duplicate state, the Change Request number it duplicates will be recorded (on the Attachments tab in ClearQuest). A submitter should initially query the Change Request database for duplicates of a Change Request before it is submitted. This will prevent several steps of the review process and therefore save a lot of time. Submitters of duplicate Change Requests should be added to the notification list of the original Change Request for future notifications regarding resolution. Admin

Project Manager

QE Manager

Development

Rejected A Change Request in this state is determined by in the CCB Review Meeting or by the assigned team member to be an invalid request or more information is needed from the submitter. If already assigned (Open), the Change Request is removed from the resolution queue and will be reviewed again. A designated authority of the CCB is assigned to confirm. No action is required from the submitter unless deemed necessary, in which case the Change Request state will be changed to More Info. The Change Request will be reviewed again in the CCB Review Meeting considering any new information. If confirmed invalid, the Change Request will be Closed by the CCB and the submitter notified. Admin

Project Manager

Development Manager

Test Manager

More Info Insufficient data exists to confirm the validity of a Reject or Duplicate Change Request. The owner automatically gets changed to the submitter who is notified to provide more data. Admin
Opened A Change Request in this state has been determined to be "in scope" for the current release and is awaiting resolution. It has been slated for resolution before an upcoming target milestone. It is defined as being in the "assignment queue". The meeting members are the sole authority for opening a Change Request into the resolution queue. If a Change Request of priority two or higher is found, it should be brought to the immediate attention of the QE or Development Manager. At that point they may decide to convene an emergency CCB Review Meeting or simply open the Change Request into the resolution queue instantly. Admin

Project Manager

Development Manager

QE Department

Assigned An Opened Change Request is then the responsibility of the Project Manager to Assign Work based on the type of Change Request and update the schedule, if appropriate. Project Manager
Resolved Signifies that the resolution of this Change Request is complete and is now ready for verification. If the submitter was a member of the QE Department, the owner automatically gets changed to the submitting QE member; otherwise, it changes to the QE Manager for manual re-assignment. Admin

Project Manager

Development Manager

QE Manager

Development Department

Test Failed A Change Request that fails testing in either a test build or a release build will be placed in this state. The owner automatically gets changed to the team member who resolved the Change Request. Admin

QE Department

Verified A Change Request in this state has been Verified in a test build and is ready to be included in a release. Admin

QE Department

Closed Change Request no longer requires attention. This is the final state a Change Request can be assigned. Only the CCB Review Admin has the authority to close a Change Request. When a Change Request is Closed, the submitter will receive an email notification with the final disposition of the Change Request. A Change Request may be Closed: 1) after its Verified resolution is validated in a release build, 2) when its Reject state is confirmed, or 3) when it is confirmed as a Duplicate of an existing Change Request. In the latter case, the submitter will be informed of the duplicate Change Request and will be added to that Change Request for future notifications (see the definitions of states "Reject" and "Duplicate" for more details). If the submitter wishes to contest a closing, the Change Request must be updated and re-Submitted for CCB review. Admin

The state 'tags' provide the basis for reporting Change Request (aging, distribution or trend) statistics.

Diagram described in caption below.

Change Request States in the context of the CM Cube.



Rational Unified Process   2003.06.13