Software Change Request (SCR) - Template

Create a tempate for a Software Change Request

Below is a Software Change Request (SCR) Template that captures all necessary details for requesting, tracking, and managing a software change. This template is adaptable to various project needs and tools like IBM ClearQuest.

Software Change Request (SCR) Template

1. Change Request Information

FieldDescription
SCR IDUnique identifier (e.g., generated by tracking tool)
Date SubmittedDate the change request is submitted
Submitted ByName, role, and contact information of requester
Change TitleShort, descriptive title of the change
Affected ComponentsList of affected components (software modules, documents)
Version/Release AffectedVersion or release where change is required

2. Description of Change

FieldDescription
Change DescriptionDetailed description of the requested change
Reason for ChangeExplanation of why the change is necessary (e.g., bug fix, enhancement)
PriorityPriority level (High, Medium, Low)
Type of ChangeIndicate whether it is a defect, enhancement, performance improvement, etc.
Requested By (Client/Stakeholder)Name and contact details of any external stakeholder involved
Date RequiredTarget date for completion (if applicable)

3. Impact Analysis

FieldDescription
Technical ImpactSummary of how the change will impact existing codebase, system architecture, etc.
Resources RequiredIndicate personnel, tools, licenses, and any special resources needed
Schedule ImpactEstimated time required for implementation and potential delays
Risk AssessmentOutline of risks introduced by the change and potential mitigation strategies
Cost EstimateEstimate of additional costs involved with implementing the change
Affected DocumentationList any documents or manuals that need updates due to the change

4. Change Control Board (CCB) Review

FieldDescription
Initial CCB Review DateDate when CCB first reviewed the SCR
CCB DecisionApproved, Rejected, Deferred
Comments from CCBAny feedback or conditions from the CCB
Final CCB Review DateDate when the final CCB decision was made

5. Implementation Plan

FieldDescription
Assigned Developer/TeamDeveloper or team responsible for the implementation
Proposed Solution/ApproachBrief explanation of how the change will be implemented
Start DateExpected start date of implementation
Estimated Completion DateExpected end date for implementation
DependenciesList of any dependencies that may affect the change (e.g., other teams, tools)

6. Testing Plan

FieldDescription
Unit Testing RequiredYes/No - Define whether unit testing is required and the plan for it
Integration Testing RequiredYes/No - Define integration testing requirements
Regression Testing RequiredYes/No - Specify if regression testing is necessary
User Acceptance Testing (UAT)Yes/No - Outline the UAT plan, if applicable
Test Cases and ProceduresReference or attach any specific test cases and testing procedures

7. Build and Release

FieldDescription
Build Completed DateDate the change was incorporated into the main build
Build Verification Testing (BVT)Results of the build verification test
Release DateDate the change was released into the production environment
Release Notes UpdatedYes/No - Ensure release notes are updated with relevant details
Deployment MethodSpecify how the change was deployed (e.g., automated, manual)

8. Post-Implementation

FieldDescription
Post-Release Monitoring PlanIndicate if and how the change will be monitored post-release
Issues Found Post-ReleaseYes/No - If yes, provide a summary of issues and fixes
End-User FeedbackAny feedback from the user community or stakeholders after release
SCCR Closed DateDate when the change request was officially closed
Lessons LearnedDocument any lessons or recommendations for future change requests

9. Approval Signatures

RoleName/SignatureDate
Configuration Manager
Project Manager
CCB Chairperson
Quality Assurance

Change Request History

DateAction TakenBy WhomNotes

This template provides a structured, traceable method to document and manage software changes, ensuring that every step from request to implementation and post-release is tracked. You can customize this template based on the specific needs of your project or organization.

Comments

Post a Comment

Popular posts from this blog

Software Configuration Management - Procedure

Provide a procedures document for planning a release, processing of software change requests, IBM Clear Quest and Clear Case tools, a Software Change Control Board, and the requirements, design, implementation, testing, peer review, change commitment, build and formal verification Here is a general outline for a procedures document that addresses planning a release, processing software change requests, using IBM ClearQuest and ClearCase tools, and conducting Software Change Control Board (SCCB) activities within the software development lifecycle. This template will include sections for requirements, design, implementation, testing, peer review, change commitment, build, and formal verification. Software Release and Change Management Procedures 1. Purpose Define the purpose of this document, such as managing software release planning and processing software changes. This includes coordinating tasks among stakeholders, using tools like IBM ClearQuest and ClearCase for tracking changes, ...
Read more

Project Process Documentation Required for CMMI-DEV Level 3 Assessment

List the various process documents that a CMMI assessor would expect to see for process area Technical Solution. A CMMI assessor evaluating the Technical Solution process area would typically expect to see the following key process documents or work products to demonstrate that requirements are being effectively transformed into designed and implemented product solutions: 1. Alternative Solution Analysis and Selection Criteria: This includes a list of alternative solutions evaluated, the criteria for selection, and the analysis methods used to support selection decisions. Work products might include: ○ Evaluation reports of alternative solutions and new technologies ○ Criteria used for selecting final solutions ○ Records of analyses or trade studies conducted for alternative solutions​​. 2. Product Component Requirements and Design Allocations: Documentation specifying how requirements are allocated to product components, as well as any derived requirements or constraints ...
Read more