SUP.10 变更请求管理"过程的目的是确保变更请求被管理、跟踪和实施。
在什么场景下需要应用SUP.10来进行变更管理呢？
举个例子来说明变更请求的各种情况，如下图所示：
客户发布了"客户需求规约"基线
产品需求工程师基于"客户需求规约"基线，开发并发布了"产品需求规约"基线
开发工程师基于"产品需求规约"基线，开发并发布了"产品设计和实现"基线
场景1：当已建立基线的"客户需求规约"发生变更时，需要应用SUP.10：
场景2：测试工程师在实施测试活动时，发现了缺陷（注：按"SUP.9 问题解决管理"处理缺陷），开发工程师在解决缺陷的过程中，发现有必要变更已建立基线的产品需求规约。此时需要触发"SUP.10 变更请求管理"过程来请求变更“产品需求规约”。
场景3：当由于例如"设计重构“的原因，对已建立基线的"产品设计"进行变更。
变更请求管理策略：
a需覆盖变更请求影响的各个学科(如：软件、电路）、各个领域（如：应用层软件、底层软件）
b需覆盖变更请求影响的各相关方，如客户、供应商、内部相关方等
c需定义变更请求在各学科、各领域、各相关方之间的传递和管理
d需定义变更请求的"状态模型"
e需定义活动的目标，如响应时间
f需定义变更请求批准在组织结构层级上的指导，如变更请求的影响到达XX成本时，需要项目经理批准，而当变更请求的影响到达XX成本时，需要部门总监批准
e可以根据项目所处的不同阶段（如：A样件、B样件），定义变更请求处理的不同要求
f需定义确保"变更请求"与"变更请求影响的工作产品及基线"之间的双向追溯性的机制
[SUP.10.RL.1] If the strategy does not include all aspects above, the indicator BP1 must not be rated F.
老杨解读：如果策略中没有包括上述的各点，则BP1的打分不能是F。
[SUP.10.RL.2] If the strategy does not address interfaces between multisite organizations/projects, subprojects, and/or groups in case of correspondingly complex projects, the indicator BP1 must not be rated higher than P.
老杨解读：如果在项目结构相对复杂的场景下，策略中没有处理处于不同地点的组织/项目、子项目和/或组之间的接口，则BP1的打分不能高于P。
[SUP.10.RC.1] If the strategy does not include goals according to e) above, the indicator BP1 should be downrated.
老杨解读：如果策略中没有包括活动的目标（上述的e），则应降低BP1的打分。
[SUP.10.RC.2] If change request handling is actually different over project life cycle phases but not consistent with the defined strategy, the indicator BP1 should be downrated.
老杨解读：如果在项目的不同阶段，变更请求的处理是不同的，但与已定义的策略不一致，则应减低BP1的打分。
[SUP.10.RC.3] If the use of a strategy is obvious by the implementation in a tool but not explicitly documented this should not be used to downrate the indicator BP1 to N or P.
老杨解读：如果是使用工具来处理变更请求，但没有明确的文档化的策略，不能基于此来降低BP1的打分至N或P。
(2) 变更请求的批准
<ASPICE模型要求>
SUP.10.BP5: 变更实施前获得批准 / Approve change requests before implementation
基于分析结果和资源可用性，对变更请求进行优先级排序，并根据策略批准
Change requests are prioritized based on analysis results and availability of resources before implementation and approved according to the strategy.
通常由CCB(Change Control Board)来批准变更请求，CCB是由变更请求影响的所有相关方的代表组成，并具有批准的授权。
[SUP.10.RL.3] If not all relevant disciplines or stakeholders are represented in the actual CCB the indicator BP5 must not be rated F.
老杨解读：如果CCB中没有包括所有相关的学科或相关方，则BP5的打分不能为F。
[SUP.10.RC.4] If it is apparent that decisions are not taken or not taken in time by the CCB without justification, the indicator BP5 should be downrated.
老杨解读：如果CCB没有及时对变更请求做决定，并缺少正当理由，则应减低BP5的打分。
(3) 影响分析和变更确认
<ASPICE模型要求>
SUP.10.BP4: 分析和评估变更请求 / Analyze and assess change requests
根据策略，分析变更请求，包括它们对受影响的工作产品和其它变更请求的依赖。评估变更请求的影响，并建立确认实施的标准。
SUP.10.BP6: 评审变更请求的实现 / Review the implementation of change requests
变更请求在关闭前进行评审，以确保满足已定义的确认标准，并已应用所有相关过程。
[SUP.10.RL.4] If the analysis does not adequately address potential side effects due to specific risks and complexity of the potential changes the indicator BP4 must not be rated F.
老杨解读：如果不能对由于特定风险和潜在变化的复杂性而产生的潜在副作用进行分析，则BP4的打分不能为F。
[SUP.10.RC.5] If the technical content of the change request or in case of alterntives the decision for one alternative is not properly documented the indicator BP4 should be downrated.
老杨解读：如果没有正确记录变更请求的技术内容或备选方案的决策，则应降低BP4的打分。
[SUP.10.RL.5] If the review of implemented changes fails to detect that relevant processes are not applied; the indicator BP6 shall be downrated.
老杨解读：如果对已实施的变更的评审未能检测到相关过程未被应用，则应降低BP6的打分。
[SUP.10.RC.6] If the confirmation of a successful implementation of change requests is not based on documented criteria the indicator BP6 should be downrated.
老杨解读：如果对成功执行变更请求的确认不以文档化的准则为依据，则应降低BP6的打分。
(4) 变更请求的状态模型和工作流
<ASPICE模型要求>
SUP.10.BP3:记录变更请求的状态 / Record the status of change requests
状态模型的状态被分配给每个变更请求以便于跟踪
SUP.10.BP7: 跟踪变更请求至关闭 / Track change requests to closure
跟踪变更请求至关闭，并给变更发起者提供反馈。
[SUP.10.RL.6] If the strategy does not include the definition of a status model, workflow, criteria for status changes, stakeholders and their authorization, the indicator BP1 shall be downrated.
老杨解读：如果策略中没有包括状态模型的定义、工作流、状态迁移条件、相关方及其授权，则应降低BP1的打分。
[SUP.10.RL.7] If the status model and workflow does not fit to the actual way of working or is not applied correspondingly, the indicator BP3 must not be rated higher than P.
老杨解读：如果状态模型及工作流没有被恰当的应用或与实际不符，则BP3的打分不能高于P。
[SUP.10.RC.7] If closed CRs do not reflect a final state, the indicator BP7 should be downrated.
老杨解读：如果已关闭的变更请求不能反映出最终状态，则应降低BP7的打分。
示例场景：状态模型中定义了“已解决(Solved)”和“已关闭(Closed)”两个状态。但实际项目中无法进入“已关闭(Closed)”状态
