Requirements Management

Manage Change

As the project progresses, there will be further changes and/or refinements that affect the approved requirements and/or create new requirements. Changes may be generated by the identification of new required functionalities, errors or defects in the current implementation, and high priority requests to enhance existing functionalities. Each potential change should be analyzed to determine associated feasibility, costs, and benefits. An analysis of the impact of making the change should identify any associated changes to project schedules, costs, or other existing requirements.

Request Attribute

Description

Unique ID

A unique identifier for the chanqe request.

Date Created

Date that the chanqe request was first captured.

Requestor

Name of the person or orqanizational dr/ision where the request oriqinated.

Requestor Contact Info

Phone, e-mail contact information for Requestor.

Chanqe Description

Statement of what needs to be changed and why.

Analysis

Analysis of what application functionalities/features and what existing requirements will be affected bvthe implementation ofthe requested chanqe.

Scope

Identify the system modules or components that will be changed from their current state.

Impact

List any impacts to business processes, user experience, other integrated applications, etc . to be considered for implementing this change

Benefits/Costs

Includes a mini- 'business case' for the chanqe: identify any cost-related risks.

Status

Reflects the current state of the change. Examples: proposed, approved, deleted/rejected, analysis, development, testing, implemented.

Assessment of Effort

Estimated resource time needed to complete the change and implement: identify any resource-related risks, scheduling conflicts.

Approver

Identified business staff responsible for approving changes that impact the requirement.

Approve Date

Date that approval was qiven for developing the chanqe.

Assiqned T o

The person responsible for completinq/executinq the change.

Due Date

T arqet date for the implementation ofthe deliverable associated with the chanqe.

QA Methodology

Specification ofthe how this change will be tested (eg., demo, analysis, inspection, walkthrough. QAtest scripts, etc ).

QAApproval Date

Date that the chanqe passed QA inspection/testinq.

Release Number

Application Release number tarqeted for the implementation of this chanqe.

Dependencies

Indentification of system elements or requirements that maybe impacted by this change.

Notes

Text field available for analyst, reviewer, approver, etc. notes related to this chanqe.

Subsystem(s)

Applications, systems where this requirement will be implemented.

Description of Attributes Collected For Managing Changes


Change requests are often captured separately from the project requirements. Identifying the requirements that will be affected by the change is critical to maintaining correct and current requirements for the project. Change requests should include details to justify enhancements or identify the necessity for the associated work. In effect, each request must include a mini-business case to justify the change. The Description of Attributes Collected for Managing Changes table at right lists some suggested change request attributes. As with the captured requirements attributes, change attributes should be determined to incorporate applicable project scope and needs.

Managing the change involves capturing the change, gaining stakeholder approval, modifying existing project plans, process or other diagrams/models, and requirements to include the change, executing the change, performing QA on the change, and, finally, implementing it. This process will impact existing requirements and create new project (or application) requirements. The changes to your baseline requirements should be identified using the unique change request ID number as the requirement (or modified requirement) 'Source'.
When a requirement is 'Approved', it becomes a baseline requirement. This 'Approved' status remains in effect until and unless it is changed. For example, a change request is approved for implementation that will modify our existing 'Approved' requirement. Now the existing baseline requirement will be replaced using an updated version of the requirement that incorporates the approved change. This updated version of the requirement is the new baseline, the currently 'Approved' requirement. The previously approved requirement is retired. Other project deliverables that are dependent on the requirement, including quality assurance tests and user documentation, will also need to be updated for the approved revision.


A simplified process that might be used for managing changes is illustrated in the Change Management Process diagram at right. Information about the change, including scope, feasibility, costs, benefits, and impacts to existing requirements and technical architecture, will be needed for the approver review. Specific designees will be responsible for approving changes.

Once a change request has been approved, the change will be incorporated into the current project work schedule, budget, and requirements repository. For new requirements, attributes will be captured in the requirements repository. For changes to existing approved requirements, the original requirement(s) should be replaced with the altered requirement(s). The original requirement(s) should be marked with an inactive status and retained for historical analysis purposes.