Spice4Cars

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.

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, , benefits, etc.

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

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 .

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"

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

arrow_forward "The role of traceability in risk control"

arrow_forward "The true benefit of traceability "

The implementation of the change requests is confirmed before closure by relevant stakeholders.

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"

Definition of criteria to be included in the analysis of a change

Identifies:

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

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

Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, 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
SYS.5 System Verification
VAL.1 Validation

SUP.10 Change Request Management

Imagine You Enjoy Improvement