Linked Knowledge Nuggets: arrow_forward "When and how to use supporting processes?"
personAuthor: 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.
# PROCESS PURPOSE
The purpose is to ensure that change requests are recorded, analyzed, tracked, approved, and implemented.
# PROCESS OUTCOMES
O1
The requests for changes are recorded and identified.
O2
The change requests are analyzed, dependencies and relationships to other change requests are identified, and the impact is estimated.
O3
The change requests are approved before implementation and prioritized accordingly.
O4
Bidirectional traceability is established between the change requests and the affected work products.
O5
The implementation of change requests is confirmed.
O6
The change requests are tracked to closure and the status of the change requests is communicated to all affected parties.
# BASE PRACTICES
BP1
Identify and record the change requests. (
O1 )
The scope for application of change requests is identified. Each change request is uniquely identified, described, and recorded, including the initiator and reason of the change request. A status is assigned to each change request to facilitate tracking. Note 1: Change requests may be used for changes related to, e.g., product, process, methods. Note 2: Example values for the change request status are “open”, “under investigation”, “implemented”, etc. Note 3: The change request handling may differ across the product life cycle, e.g., during prototype construction and series development.
BP2
Analyze and assess the change requests. (
O2 )
The change requests are analyzed by relevant parties according to the analysis criteria. The work products affected by the change requests and dependencies on other change requests are determined. The impact of the change requests is assessed. Note 4: Examples for analysis criteria are: resource requirements, scheduling issues, (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"
personAuthor: 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.
BP3
Approve the change requests before implementation. (
O3 )
The change requests are prioritized and approved for implementation based on the analysis results and the availability of resources. Note 5: A Change Control Board (CCB) is an example mechanism used to approve change requests. Note 6: Prioritization of change requests may be done by allocation to (Release = A product delivered to a customer, including a defined set of functionalities and properties.).
BP4
Establish bidirectional traceability. (
O4 )
Establish bidirectional traceability between the change requests and the work products affected by the change requests. In case that the change requests are initiated by problems, establish bidirectional traceability between the change requests and the corresponding problem reports.
Linked Knowledge Nuggets: arrow_forward "Change Requests and affected work items"
personAuthor: 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?"
personAuthor: 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"
personAuthor: 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
"
personAuthor: 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.
BP5
Confirm the implementation of the change requests. (
O5 )
The implementation of the change requests is confirmed before closure by relevant stakeholders.
BP6
Track the change requests to closure. (
O6 )
The change requests are tracked to closure. The status of the 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"
personAuthor: 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
# OUTPUT INFORMATION ITEMS
18-57
Change analysis criteria (
O2 )
Definition of criteria to be included in the analysis of a changeIdentifies:
Resource requirements
Timing needs, for example to a (Project = Endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources requirements.) schedule
(Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) and opportunities
Used by these processes:
SUP.10 Change Request Management
13-16
Change request (
O1, O2, O3, O5, O6 )
Request to change scope or impacts on planned activities or outcomes.Identifies:
Scope and purpose of the change activities
Originator of the change
Impacted operation environment
Process performance
Environment of usage for the process outcome
Infrastructure or resources
Documentation needs
Includes:
Impacted outcomes and achievements
Process objectives
(Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) for implementation of a change
Limitations to be considered
Criteria to verify the fulfillment of the implementation
Used by these processes:
ACQ.4 Supplier Monitoring
MAN.3 Project Management
PIM.3 Process Improvement
SUP.10 Change Request Management
13-51
Consistency evidence (
O4 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SUP.10
Change Request Management
