Official Purpose Statement: "The purpose of the Change Request Management Process is to ensure that change requests are managed, tracked and controlled."
SUP.10 is the gatekeeper for every change to a baselined work product. Without it, baselines are meaningless - anyone can change a baselined SRS, SAD, or source file without review, breaking the traceability chain and invalidating previously approved test results. SUP.10 ensures that changes are deliberate, approved, and traceable.
📋 Learning Objectives
- Operate a complete CR lifecycle from initiation through implementation to closure
- Perform and document impact analysis before approving a CR
- Link CRs to affected CIs, work products, and re-verification requirements
- Distinguish SUP.10 (change requests to baselined WPs) from SUP.9 (problem/defect reports)
CR Lifecycle - Complete State Machine
| State | Responsible Role | Required Actions | Exit Criteria |
|---|---|---|---|
| New | Initiator (any team member, customer, or OEM) | CR submitted with: description of change, motivation/rationale, affected CI/WP, initiator, submission date | CR accepted into tracking system with unique CR-ID |
| Under Analysis | Assigned Engineer + affected process owners | Impact analysis: which CIs are affected, which BPs must be re-executed, which test cases must be re-run, effort estimate, safety impact assessment (ASIL change?), cost/schedule impact | Impact analysis document completed and attached to CR |
| Approved / Rejected | Change Control Board (CCB) or authorized role | CCB reviews impact analysis and business justification. Approves: assigns to engineer, sets target release. Rejects: documents reason. Defers: moves to a future release with justification. | CR disposition recorded with CCB minutes or approval record |
| In Implementation | Assigned Engineer | Change implemented in affected CIs. CM updated (commit references CR-ID in message). Affected work products updated (e.g., SRS section updated, traceability matrix updated). | All identified affected CIs modified; verification scope documented |
| In Verification | Test/Review team | Re-test of affected requirements per impact analysis scope. Review of updated work products. Regression test execution for integration-level impact. Traceability matrix updated. | Re-test results recorded; all affected TCs pass; review of updated WPs documented |
| Closed | QA or CR owner | All verification steps completed and evidenced. Baseline updated to include the change (new baseline or increment). CR closure date recorded. | CR status = Closed; evidence of verification linked to CR record |
Impact Analysis - What It Must Cover
Impact analysis is the critical value-add of SUP.10. Without it, changes are made blindly. A compliant impact analysis for a CR must address:
- Affected CIs: Which source files, documents, ARXML configurations, test cases, and calibration files need to change?
- Traceability impact: Does this change break any existing requirement-to-test trace link? Does it create new requirements that need new test cases?
- Test re-verification scope: Which SWE.4, SWE.5, and SWE.6 test cases must be re-executed? (This prevents "we made a change and assumed the old tests still apply")
- Safety impact: Does the change affect an ASIL-rated requirement or safety mechanism? If so, functional safety impact assessment required.
- AUTOSAR configuration impact: Does the change require ARXML updates, code regeneration, or BSW reconfiguration? Are all affected configurations in scope?
- Effort and schedule: Estimated work hours and earliest possible integration into a release.
🔍 The Missing Re-verification Finding
The most common SUP.10 gap: CR implemented, code committed, baseline updated - but the impact analysis was not followed up. Test cases identified as needing re-run were never actually re-executed, or re-run results were not recorded. Assessors will pick a CR from the tracker, read the impact analysis, then check whether the identified re-verification steps were actually performed and documented. If not - it is a Major Finding on SUP.10 and potentially on SWE.6 BP5 (regression testing) simultaneously.
SUP.10 vs. SUP.9 - The Distinction
| Process | Trigger | Focus | When Needed |
|---|---|---|---|
| SUP.9 - Problem Resolution | A defect, failure, or anomaly is detected | Defect investigation, root cause analysis, fix implementation | SWE.4 test failure, SWE.6 test failure, field defect, customer complaint |
| SUP.10 - Change Request Management | A deliberate change to a baselined WP is desired | Change control, impact analysis, approval, traceability update | New feature request, requirement change, architecture evolution, calibration update |
In practice, a defect fix (SUP.9) that modifies a baselined work product will also trigger a CR (SUP.10) for the baseline update. Both processes are involved. The SUP.9 tracks "what was wrong and how was it fixed." The SUP.10 tracks "what work products changed and what re-verification was needed."
✅ SUP.10 CL2 Readiness Checklist
- ✅ CR tracking system in use (Jira, PTC Integrity, IBM RTC, or equivalent) with defined CR workflow states
- ✅ Every change to a baselined WP initiates a CR - no undocumented hotfixes
- ✅ Every CR has a completed impact analysis before approval
- ✅ CCB or equivalent approval role defined and active - CRs not self-approved by the implementer
- ✅ Re-verification scope per CR documented and re-test results linked to the CR
- ✅ CR closure requires evidence of re-verification - not just "done" status from the developer
- ✅ Git commit messages reference CR-ID (e.g., "[CR-0042] Fix sensor debounce logic per impact analysis")