Create a checklist for Software Change Requests

Here is a comprehensive Software Change Request (SCR) Checklist to ensure that all aspects of the change request process are covered, from submission to closure.

Software Change Request (SCR) Checklist

1. Change Request Submission

•  Change Title: Descriptive name of the requested change.
•  Requester Information: Name, role, and contact information of the person submitting the request.
•  Date Submitted: Date the SCR was officially submitted.
•  Affected Components: List all software components, documents, or systems affected by the change.
•  Change Description: Clear and concise description of the change being requested.
•  Reason for Change: Explanation of why the change is necessary (e.g., defect fix, enhancement, performance improvement).
•  Priority Level: Assigned priority (e.g., high, medium, low) based on urgency.
•  Impact Assessment: Preliminary analysis of the potential impact on the system, including any dependencies.
•  Approvals Required: Initial signatures or digital approval from the requester’s supervisor or project manager.

2. Initial Review and Approval by Software Change Control Board (SCCB)

•  SCCB Review Meeting Scheduled: Ensure the SCR has been scheduled for review at the next SCCB meeting.
•  Feasibility Assessment: SCCB evaluates the feasibility of implementing the change.
•  SCCB Approval/Reject Decision: Decision to proceed, defer, or reject the request.
•  If Rejected: Document the reason for rejection.
•  If Deferred: Set the next review date and reason for deferral.
•  If Approved: Move forward to impact analysis and planning.
•  Assigned Owner: Assign the owner responsible for managing the SCR implementation.

3. Impact Analysis

•  Technical Impact: Assessment of how the change will affect system architecture, codebase, performance, and security.
•  Schedule Impact: Estimated time required to implement the change and any potential delays to the project timeline.
•  Resource Requirements: Identification of necessary resources (developers, testers, etc.) and additional tools or licenses.
•  Cost Estimation: Estimated cost of implementing the change.
•  Risk Assessment: Identification of risks, including possible negative effects on existing functionality or integration issues.
•  Testing Requirements: Outline of required testing, including unit, system, regression, and acceptance testing.
•  Update SCCB: Submit impact analysis for final review and approval from the SCCB.

4. Development and Testing

•  Implementation Plan: Detailed steps for making the change, including design modifications and code changes.
•  Version Control: Ensure a new branch has been created in the version control system (e.g., IBM ClearCase) to isolate the changes.
•  Unit Testing: Developer performs unit testing to verify that the change functions as intended.
•  Code Review: Ensure that the change undergoes peer or team review for code quality and correctness.
•  Integration Testing: Validate that the change integrates properly with the overall system.
•  Regression Testing: Conduct regression tests to confirm that no existing functionality is broken.
•  Test Results Logged: Record test results in the SCR system (e.g., IBM ClearQuest) for SCCB review.

5. Pre-Release and Build Verification

•  Build Readiness: Ensure all changes are merged into the main build and are ready for formal build and release testing.
•  Build Verification Test (BVT): Execute BVT to confirm that the build is stable and the changes do not introduce any critical issues.
•  Final Testing: Execute system and acceptance testing based on defined test cases.
•  Acceptance Criteria Met: Verify that the change meets all functional and performance requirements.
•  Test Reports: Test results are documented and linked to the SCR in ClearQuest.
•  Final SCCB Approval for Release: The SCCB reviews the completed SCR, test reports, and BVT results before approving the release.

6. Release and Post-Release Activities

•  Release Notes Created: Ensure that release notes are updated to include details of the change.
•  Final Build Released: Software change is deployed to the production environment.
•  Post-Release Monitoring: Monitor the software for any issues that may arise post-deployment.
•  User Feedback: Gather feedback from end users, if applicable.
•  Close SCR: Update the status in ClearQuest to Closed once all post-release activities are complete and no further action is required.
•  Post-Implementation Review: Conduct a final review of the change to identify any lessons learned or improvements for future change control processes.

Sign-Off

•  Configuration Manager: Signature and date.
•  Project Manager: Signature and date.
•  SCCB Chairperson: Signature and date (for final closure).

This checklist ensures a comprehensive approach to managing software change requests, providing a controlled and traceable path from the initial submission to final release and closure.