SUP.10 Change Request Management

Linked Knowledge Nuggets:
arrow_forward "Change Request Management"

person Author: Process Fellows
SUP.10 – Change Request Management handles the lifecycle of change requests from identification through analysis, approval, and tracking to closure. It ensures full traceability and control across all affected disciplines and domains.

• school PF_SUP.10_Change Request Management_Extract.pdf
  Short Overview of the SUP.10 Change Request Management Process covering base practices, some examples and a comparion between Automotive SPICE® version 3.1 and 4.0

arrow_forward "When and How to use supporting processes"

person Author: Process Fellows
Supporting processes like SUP.9 (Problem Resolution) or SUP.10 (Change Request Management) are often misunderstood as “back-office.” But they’re vital for delivering quality. Make sure your teams know when to invoke them — and how to record their outcomes. A 2-minute log of a problem review can save hours of debugging.

• O1 Requests for changes are recorded and identified.
• O2 Change requests are analyzed, dependencies and relationships to other change requests are identified, and the impact is estimated.
• O3 Change requests are approved before implementation and prioritized accordingly.
• O4 Bidirectional traceability is established between change requests and affected work products.
• O5 Implementation of change requests is confirmed.
• O6 Change requests are tracked to closure and status of change requests is communicated to affected parties.

BP2 Analyze and assess change requests. ( O2 )

Change requests are analyzed by relevant parties according to analysis criteria. Work products affected by the change request and dependencies to other change requests are determined. The impact of the change requests is assessed.
NOTE 4: Examples for analysis criteria are: resource requirements, scheduling issues, risks (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.), benefits, etc.

Linked Knowledge Nuggets:
arrow_forward "Change Requests and affected work items"

person Author: Process Fellows
Traceability between a change request and the affected work item can be established through proper analysis of the change request. The reverse traceability — from an affected work item back to the originating change request — is typically established through a change comment in the version history. This comment should include the change request ID to ensure proper linkage.

BP4 Establish bidirectional traceability. ( O4 )

Establish bidirectional traceability between change requests and work products affected by the change requests. In case that the change request is initiated by a problem, establish bidirectional traceability between change requests and the corresponding problem reports.

Linked Knowledge Nuggets:
arrow_forward "Change Requests and affected work items"

person Author: Process Fellows
Traceability between a change request and the affected work item can be established through proper analysis of the change request. The reverse traceability — from an affected work item back to the originating change request — is typically established through a change comment in the version history. This comment should include the change request ID to ensure proper linkage.

arrow_forward "Consistency vs. Traceability – What’s the Difference?"

person Author: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.

arrow_forward "The role of traceability in risk control"

person Author: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.

arrow_forward "The true benefit of traceability "

person Author: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized. Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments. In the aftermath, the effort increases noticeably and the risk of gaps is high. If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure. It also enables proof of complete coverage of the derived elements and allows the complete consistency check.

BP6 Track change requests to closure. ( O6 )

Change requests are tracked to closure. The status of change requests is communicated to all affected parties.
NOTE 7: Examples for informing affected parties can be daily standup meetings or tool-supported workflows.

Linked Knowledge Nuggets:
arrow_forward "ALM-based dashboard for monitoring Change Requests"

person Author: Process Fellows
Defining an ALM (Application Lifecycle Management) dashboard for tracking change requests involves identifying the right metrics, data sources, and visualizations to support transparency, traceability, and decision-making. The main steps are:

• Define stakeholders for tracking and reporting
• Identify stakeholders information needs, i.e. key metrics
• Define data sources
• Design dashboard layout
• Set up alerts and filters
• Regularly review dashboard usage and feedback
• Adjust metrics and visualization to match evolving stakeholder needs