ASPICE软件开发需求文档模板（软件开发的需求文档模板）
今天给各位分享ASPICE软件开发需求文档模板的知识，其中也会对软件开发的需求文档模板进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、工作笔记ASPICE VDA Guideline解读(19)：SUP.8 配置管理
- 2、工作笔记 ASPICE VDA Guideline解读(20)：MAN.3 项目管理
- 3、ASPICE VDA Guideline解读(18)：SUP.10 变更请求管理
工作笔记ASPICE VDA Guideline解读(19)：SUP.8 配置管理
配置管理过程的目的是建立和维护过程或项目的所有工作产品的完整性。
什么是“工作产品的完整性”呢？
下图是"SWAD(软件架构设计)"工作产品的创建和维护过程，其每一次变更（如：从Baselined 1.0 -- Baselined 2.0）是可控的，其相关联的上下游基线是明确的。这样就可以说保证了"SWAD(软件架构设计)"的完整性。
1) 配置管理策略
ASPICE模型要求
SUP.8.BP1: 制定配置管理策略 / Develop a configuration management strategy
制定配置管理策略，包括：/ Develop a configuration management strategy, including
职责 / responsibilities
工具和配置库 / tools and repositories
配置项(识别的)准则 / criteria for configuration items
命名规约 / naming conventions
访问权限 / access rights
基线准则 / criteria for baselines
合并和分支策略 / merge and branch strategy
配置项的修订历史方式 / the revision history approach for configuration items
配置管理策略包括：
a) 配置管理的范围需覆盖项目中的各学科(如：软件、硬件)、各地点、各过程(如管理过程、支持过程、工程过程等)
b) 制定整体策略，覆盖各学科、各过程及各地点等
c) 定义访问权限
d) 根据项目的复杂度定义所需的活动和工具
e) 定义配置项的识别准则及命名规约
f) 定义配置项的修订条件
g) 定义基线策略
h) 定义Variant及分支策略
i) 定义配置项变更历史的方式
[SUP.8.RL.1] If the strategy does not include all aspects above, the indicator BP1 must not be rated F.
老杨解读：如果策略中没有包括上述的各点，则BP1不能判定为F。
[SUP.8.RL.2] If there is no dedicated configuration management system defined in the strategy but the procedure is adequate for the complexity of the product to be developed this must not be used to downrate the indicator BP1.
老杨解读：如果没有专门的配置管理系统，但所建立的配置管理程序是满足产品复杂度的，则不能基于此来降低BP1的打分。
[SUP.8.RL.3] If major configuration management aspects (according to d) or e)) are missing in the strategy the indicator BP1 must not be rated higher than P.
老杨解读：如果配置管理的主要方面（如上述的d)或e)）是缺失的，则BP1的打分不能高于P
[SUP.8.RL.4] If major baselining aspects (according to g)) are missing in the strategy the indicator BP1 must not be rated higher than P.
老杨解读：如果策略中缺少主要的基线方面的考虑（上述的g)），则BP1的打分不能高于P。
[SUP.8.RL.5] If major branching and merging aspects (according to h)) are missing in the strategy the indicator BP1 must not be rated higher than P.
老杨解读：如果策略中缺少主要的分支和合并方面的考虑（上述的h)），则BP1的打分不能高于P。
[SUP.8.RC.1] If there is only an adequate generic strategy but no project specific implementation, the indicator BP1 should not be down-rated.
老杨解读：如果有一个适当的通用策略，而没有为项目定义特定的策略，那么BP1的打分不应该被降低。
(2) 基线
ASPICE模型要求
SUP.8.BP6: 建立基线 / Establish baselines
根据配置管理策略建立基线，以满足内部目的和外部交付
Establish baselines for internal purposes and for external delivery according to the configuration management strategy
SUP.8.BP8: 验证配置项的信息 / Verify the information about configured items
验证配置项及其基线的信息是否完整，并确保基线的一致性。
Verify that the information about configured items, and their baselines is complete and ensure the consistency of baselines.
基线需要：
a) 定义基线中所包括的配置项
b) 根据策略创建必要的内外部基线
c) 创建跨不同学科、地点和过程的整体基线，并保证其之间的一致性
d) 基线中应包括再现工作产品的完整和一致的配置项集合
e) 根据策略中定义的命名规范创建基线
[SUP.8.RL.6] If it is not defined for each kind of baseline which configuration items are to be controlled, the indicator BP6 must not be rated higher than P.
老杨解读：如果基线中没有识别出所有的需要被控制的配置项，则BP6的打分不能高于P。
[SUP.8.RL.7] If established baselines for different disciplines, sites, processes etc. (according to c) are not consistent or if overall baselines do not exist, the indicator BP6 shall be downrated.
老杨解读：如果创建的跨不同学科、地点和过程的整体基线(上述的c))之间是不一致的，或不存在，则应降低BP6的打分。
[SUP.8.RL.8] If content of a baseline is not verified (by e.g., a baseline or configuration management audit), the indicator BP8 shall be downrated.
老杨解读：如果基线的内容未进行验证，则应降低BP8的打分。
[SUP.8.RC.2] If the defined naming convention for baselines is not used, the indicator BP6 should be downrated.
老杨解读：如果未使用已定义的命名规范，则应降低BP6的打分。
(3) 分支与合并
ASPICE模型要求
SUP.8.BP4: 建立分支管理 / Establish branch management
根据配置管理策略建立分支管理，分支管理适用于使用同一基础进行并行开发时
Establish branch management according to the configuration management strategy where applicable for parallel developments that use the same base.
SUP.8.BP8: 验证配置项的信息 / Verify the information about configured items
验证配置项及其基线的信息是否完整，并确保基线的一致性。
Verify that the information about configured items, and their baselines is complete and ensure the consistency of baselines.
[SUP.8.RL.9] If branches are not created according to the strategy, the indicator BP4 shall be downrated.
老杨解读：如果未基于策略创建分支，则应降低BP4的打分。
[SUP.8.RL.10] If consistency and completeness of merged items or sets of items is not ensured, the indicator BP8 must not be rated F.
老杨解读：如果不能确保合并项的一致性和完全性，则BP8的打分不能是F。
(4) 配置管理基础设施
ASPICE模型要求
SUP.8.BP3: 建立配置管理系统 / Establish a configuration management system
根据配置管理策略建立配置管理系统
Establish a configuration management system according to the configuration management strategy
SUP.8.BP9: 管理配置项和基线的存储 / Manage the storage of configuration items and baselines
通过适当的调度和资源存储保证配置项和基线的完整性和可用性，对使用的CM系统归档（长期保存）和备份
Ensure the integrity and availability of configuration items and baselines through appropriate scheduling and resourcing of storage, archiving (long term storage) and backup of the used CM systems.
配置管理基础设施需要：
a) 支持策略中定义的配置管理程序，包括访问权限
b) 适合于已定义的复杂度，包括适用于多地、项目规模、多项目或多变体应用等。
c) 了解所用的IT服务(如：文件共享、工具等)属性，比如存储、归档、备份，并与项目需求进行比较。识别差异并采取纠正措施
[SUP.8.RL.11] If the established infrastructure is not able to support the procedures (according to a)) or the complexity (according to b)), the indicator BP3 shall be downrated.
老杨解读：如果已建立的基础设施不能支持配置管理程序(上述的a))，或项目复杂度(上述的b))，则应降低BP3的打分。
[SUP.8.RL.12] If there is no dedicated configuration management system in place but the established procedure is adequate for the complexity of the product to be developed this must not be used to downrate the indicator BP3.
老杨解读：如果没有专门的配置管理系统，但所建立的配置管理程序是满足产品复杂度的，则不能基于此来降低BP3的打分。
[SUP.8.RL.13] If properties of used IT services are not known, or known but in case of deviations from project requirements no corrective actions are established, the indicator BP9 shall be downrated.
老杨解读：如果IT服务的情况是未知的，或存在偏差但无纠正措施，则应降低BP9的打分。
工作笔记 ASPICE VDA Guideline解读(20)：MAN.3 项目管理
项目管理过程的目的是在项目需求和约束的背景下, 识别、建立和控制项目生成产品所必需的活动和资源。
简单来说是指：通过对项目实施所必要活动（必要活动能保证输出质量） 和 资源（人力资源、设备资源等）的管理，使项目能达成既定的项目目标，如时间目标、质量目标、成本目标等。
接下来我们来看一下VDA Guideline中的相关规则：
(1) 工作范围
ASPICE模型要求
MAN.3.BP1: 定义工作范围 / Define the scope of work
确定项目的目标、动机和边界
Identify the project's goals, motivation and boundaries.
项目的工作范围包括项目范围和产品范围；项目的内容、边界、限制、项目目标等。
[MAN.3.RL.1] If the scope of work (BP1) is a product description only, the indicator BP1 must not be rated higher than L.
老杨解读：如果工作范围仅仅是产品描述，则BP1的打分不能高于L。
[MAN.3.RC.1] If the scope of work (BP1) does not address the responsibilities of all affected parties regarding the project and product, the indicator BP1 should not be rated higher than L.
老杨解读：如果工作范围没有考虑所有项目和产品的相关方的责任划分，则BP1的打分不能高于L。
[MAN.3.RL.2] If the scope of work (BP1) is not appropriately documented at project start, the indicator BP1 must not be rated higher than L.
老杨解读：如果工作范围没有在项目开始时文档化，则BP1的打分不能高于L。
(2) 承诺
ASPICE模型要求
MAN.3.BP1: 定义工作范围 / Define the scope of work
确定项目的目标、动机和边界
Identify the project's goals, motivation and boundaries.
MAN.3.BP3: 评估项目的可行性 / Evaluate feasibility of the project
在时间、项目估计和可用资源范围内，在技术限制的范围内，评估实现项目目标的可行性。
Evaluate the feasibility of achieving the goals of the project in terms of technical feasibility within constraints with respect to time, project estimates, and available resources.
MAN.3.BP5: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources
根据项目目标、项目风险、项目理由和边界，定义、监控和调整项目工作量和资源的估计。
Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries
MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule
为活动分配资源，并安排整个项目中的每一项活动的日程安排。在项目生命周期内，项目日程安排必须持续更新。
Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.
[MAN.3.RC.2] If the commitment is not fulfilled by delaying the timeline of the project or by cancelling functionality etc., the indicators BP1 and BP3 should not be rated higher than L.
老杨解读：如果未能通过延迟项目时间或取消功能等方式履行承诺，则BP1和BP3的打分不应高于L。
[MAN.3.RL.3] If the commitment is not fulfilled by delaying the timeline of the project or by cancelling functionality etc., the indicator BP5 and BP8 must not be rated higher than L.
老杨解读：如果未能通过延迟项目时间或取消功能等方式履行承诺，则BP5和BP8的打分不应高于L。
注：与相关方达成一致后的项目交付时间延迟或功能取消是可以的。
(3) 活动定义
ASPICE模型要求
MAN.3.BP4: 定义、监控和调整项目活动 / Define, monitor and adjust project activities
根据定义的项目生命周期和预估，定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。
Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required
MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule
为活动分配资源，并安排整个项目中的每一项活动的日程安排。在项目生命周期内，项目日程安排必须持续更新。
Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.
[MAN.3.RC.3] If the activities are not described with input and output artifacts, the indicator BP4 should not be rated higher than P.
老杨解读：如果活动定义中未包括输入和输出，则BP4的打分不能高于P。
[MAN.3.RC.4] If the dependencies between activities are not identified, the indicator BP4 should not be rated higher than L.
老杨解读：如果未识别活动之间的依赖关系，则BP4的打分不能高于L。
[MAN.3.RC.5] If the work packages are too big (e.g. longer than the update cycle for the schedule), the indicator BP8 should be down-rated.
老杨解读：如果工作包的颗粒度太大（如：大于Schedule的更新周期），则BP8的打分应降低。
注：Schedule中Work Package的颗粒度需要小于项目的监控周期(如：周），如果存在特殊的Case，无法拆分，则也不能超过2个项目监控周期。
(4) 工作量和资源估计
ASPICE模型要求
MAN.3.BP5: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources
根据项目目标、项目风险、项目理由和边界，定义、监控和调整项目工作量和资源的估计。
Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries
[MAN.3.RC.6] If the estimation method used is not comprehensible, the indicator BP5 should not be rated higher than P.
老杨解读：如果使用的估计方法是不可理解的，则BP5的打分不能高于P。
[MAN.3.RC.7] If the estimates are too high level, e.g. based on high-level packages rather than on actual activities, the indicator BP5 should not be rated higher than P.
老杨解读：如果估计的颗粒度太高，如：基于高层次的工作包，而不是基于实际的活动，则BP5的打分不能高于P。
[MAN.3.RC.8] If there are not sufficient resources to cover the estimated effort, the indicator BP5 should not be rated higher than P.
老杨解读：如果缺少足够的资源来满足预计的工作量，则BP5的打分不能高于P。
[MAN.3.RC.9] If the resources are sufficient to cover the estimates but a monitoring of actual effort versus the estimates is missing, the indicator BP5 should not be rated higher than L.
老杨解读：如果有足够的资源来满足预计的工作量，但是缺少对工作量的监控，则BP5的打分不能高于L。
[MAN.3.RC.10] If the rationale for the estimates is missing, the indicator BP5 should not be rated higher than L.
老杨解读：如果缺失估计的必要理由，则BP5的打分不能高于L。
(5) 变更请求和问题解决(缺陷解决)的估计
ASPICE模型要求
MAN.3.BP2: 定义项目的生命周期 / Define project life cycle
定义项目的生命周期，与项目的范围、上下文、量级和复杂程度相适应。
Define the life cycle for the project, which is appropriate to the scope, context, magnitude and complexity of the project.
MAN.3.BP4: 定义、监控和调整项目活动 / Define, monitor and adjust project activities
根据定义的项目生命周期和预估，定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。
Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required
MAN.3.BP5: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources
根据项目目标、项目风险、项目理由和边界，定义、监控和调整项目工作量和资源的估计。
Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries
MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule
为活动分配资源，并安排整个项目中的每一项活动的日程安排。在项目生命周期内，项目日程安排必须持续更新。
Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.
[MAN.3.RC.11] If the definition of activities, effort and resource estimation, and the preparation of schedule(s) do not sufficiently reflect expectable change requests and problem resolution, the indicators BP4, BP5 and BP8 should be downrated.
老杨解读：如果在活动定义、工作量和资源估计、制定进度表等方面没有充分反映对变更请求或缺陷解决方面的考虑，则BP4, BP5, BP8的打分应降低。
[MAN.3.RC.12] If the project lifecycle does not contain phases that allow for addressing change requests and problem resolution, the indicator BP2 should be downrated.
老杨解读：如果项目生命周期中未考虑处理变更请求和缺陷解决的阶段，那么应该降低BP2的打分。
(6) 进度与跟踪
ASPICE模型要求
MAN.3.BP4: 定义、监控和调整项目活动 / Define, monitor and adjust project activities
根据定义的项目生命周期和预估，定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。
Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required
MAN.3.BP5: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources
根据项目目标、项目风险、项目理由和边界，定义、监控和调整项目工作量和资源的估计。
Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries
MAN.3.BP7: 识别、监控和调整项目的接口和承诺 / Identify, monitor and adjust project interfaces and agreed commitments
项目与其它（子）项目、组织单元和其它受影响的利益相关者的接口，需要确定并达成一致，并监督已商定的承诺。
Identify and agree interfaces of the project with other (sub-) projects, organizational units and other affected stakeholders and monitor agreed commitments.
MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule
为活动分配资源，并安排整个项目中的每一项活动的日程安排。在项目生命周期内，项目日程安排必须持续更新。
Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.
MAN.3.BP9: 确保一致性 / Ensure consistency
确保项目计划的各部分之间的一致性，包括：项目估计、人员技能、活动、日程安排、相关方之间的接口和承诺。
Ensure that estimates, skills, activities, schedules, plans, interfaces, and commitments for the project are consistent across affected parties
MAN.3.BP10: 项目评审和项目进展报告 / Review and report progress of the project
定期评审和向所有相关方报告项目状态，关于项目活动在预计的工作量和日程上的达成情况。防止发现问题再次发生。
Regularly review and report the status of the project and the fulfillment of activities against estimated effort and duration to all affected parties. Prevent recurrence of problems identified.
[MAN.3.RC.13] If action items or corrective actions are not properly tracked to closure, the corresponding indicators BP4, BP5, BP7, BP8 and/or BP10 should be downrated.
老杨解读：如果行动项或纠正措施没有恰当的跟踪直至关闭，相应的BP4, BP5, BP7及BP10的打分应降低。
[MAN.3.RL.4] If the schedule is not based on the defined activities (BP4) and estimations (BP5), the indicators BP8 and BP9 must not be rated higher than P.
老杨解读：如果Schedule没有基于已定义的活动(BP4)和估计(BP5)，则BP8和BP9的打分不能高于P。
[MAN.3.RL.5] If the schedule does not contain all of the following:
a start and end date,
duration,
degree of fulfillment (for monitoring purposes),
resources,
dependencies
the indicator BP8 must not be rated higher than L.
老杨解读：如果Schedule中没有包括：开始和结束时间、持续时间、进展完成情况、资源、依赖，则BP8的打分不能高于L。
[MAN.3.RL.6] If any of the following:
start and end date,
effort,
degree of fulfillment
is missing, the indicator BP8 must not be rated higher than P.
老杨解读：如果缺失"开始和结束时间"、"工作量"和"进展完成情况"，则BP8的打分不能高于P。
[MAN.3.RL.7] If the schedule is changed without a documented reason, or the change is not documented, the indicator BP8 shall be downrated.
老杨解读：如果Schedule发生了变更但缺少文档化的原因，或变更没有被记录，则BP8的打分应降低。
[MAN.3.RL.8] If the degree of activity fulfillment as tracked in the schedule is not up to date (at least biweekly depending on the project scope and release plan), the indicator BP8 shall be downrated.
老杨解读：如果活动的进展没有在Schedule中及时更新，则BP8的打分应降低。
[MAN.3.RL.9] If the critical path in a schedule is not determined, the indicator BP8 shall be downrated.
老杨解读：如果未确定Schedule中的关键路径，则BP8的打分应降低。
(7) 项目实际进展
ASPICE模型要求
MAN.3.BP10: 项目评审和项目进展报告 / Review and report progress of the project
定期评审和向所有相关方报告项目状态，关于项目活动在预计的工作量和日程上的达成情况。防止发现问题再次发生。
Regularly review and report the status of the project and the fulfillment of activities against estimated effort and duration to all affected parties. Prevent recurrence of problems identified.
[MAN.3.RL.10] If monitoring does not assess the correlation of actual consumption of resources, meeting of deadlines and fulfillment of activities (i.e. progress of content), the indicator BP10 must not be rated higher than P.
老杨解读：如果在项目监控时，没有考虑资源的实际消耗、最后期限的满足和活动的完成（即内容的进度）之间的相关性，则BP10的打分不能高于P。
(8) 发布管理
ASPICE模型要求
MAN.3.BP4: 定义、监控和调整项目活动 / Define, monitor and adjust project activities
根据定义的项目生命周期和预估，定义、监视和调整项目活动及其依赖关系。根据需要调整活动及其依赖关系。
Define, monitor and adjust project activities and their dependencies according to defined project life cycle and estimations. Adjust activities and their dependencies as required
MAN.3.BP7: 识别、监控和调整项目的接口和承诺 / Identify, monitor and adjust project interfaces and agreed commitments
项目与其它（子）项目、组织单元和其它受影响的利益相关者的接口，需要确定并达成一致，并监督已商定的承诺。
Identify and agree interfaces of the project with other (sub-) projects, organizational units and other affected stakeholders and monitor agreed commitments.
MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule
为活动分配资源，并安排整个项目中的每一项活动的日程安排。在项目生命周期内，项目日程安排必须持续更新。
Allocate resources to activities, and schedule each activity of the whole project. The schedule has to be kept continuously updated during lifetime of the project.
[MAN.3.RL.11] If product release recipients are not considered as stakeholders, the indicator BP7 must not be rated higher than P.
老杨解读：如果产品发布的接受者没有被考虑为相关方，则BP7的打分不能高于P。
[MAN.3.RL.12] If product release deadlines or milestones are not reflected in schedules (consider also consistency across different schedules), the indicator BP8 must not be rated higher than P.
老杨解读：如果产品发布的时间点或里程碑没有在Schedule中考虑，则BP8的打分不能高于P。
[MAN.3.RL.13] If the scope of the current and next release is not identified in detail (features and/or functions per release), the indicators BP7 and BP8 must not be rated higher than P.
老杨解读：如果当前发布及下一次发布的范围没有被详细识别(每次发布的功能点)，则BP7和BP8的打分不能高于P。
[MAN.3.RL.14] If the mid and long-term planning of the releases does not at least cover a latest release/milestone for features and/or functions, the indicators BP7 and BP8 must not be rated higher than L.
老杨解读：如果中期计划或长期计划中没有覆盖到当前发布或里程碑，则BP7和BP8的打分不能高于L。
[MAN.3.RL.15] If for the current and next release not all the expected activities are planned and tracked (without a good reason), the indicators BP4, BP7 and BP8 shall not be rated higher than L. If less than 50% of the expected activities are planned, BP4, BP7, BP8 must not be rated higher than P.
老杨解读：如果当前发布及下一次发布中的所有活动没有被完全策划（且没有合适理由），则BP4, BP7和BP8的打分不能高于L；如果少于50%的活动没有策划，则BP4, BP7和BP8的打分不能高于P。
(9) 一致性
ASPICE模型要求
MAN.3.BP9: 确保一致性 / Ensure consistency
确保项目计划的各部分之间的一致性，包括：项目估计、人员技能、活动、日程安排、相关方之间的接口和承诺。
Ensure that estimates, skills, activities, schedules, plans, interfaces, and commitments for the project are consistent across affected parties
[MAN.3.RC.14] If links between different types of planning information are not supported by tools, this should not be used to downrate the indicator BP9.
老杨解读：如果项目计划相关的不同类型的信息之间的关联性不是依赖于工具，则不能基于此降低BP9的打分。
[MAN.3.RL.15] If the correlation between different plans or between estimates and plans is too high level or weak, the indicator BP9 shall be downrated.
老杨解读：如果项目计划相关的不同类型的信息之间的关联性的层次太高，则应降低BP9的打分。
(10) 风险
ASPICE模型要求
MAN.3.BP3: 评估项目的可行性 / Evaluate feasibility of the project
在时间、项目估计和可用资源范围内，在技术限制的范围内，评估实现项目目标的可行性。
Evaluate the feasibility of achieving the goals of the project in terms of technical feasibility within constraints with respect to time, project estimates, and available resources.
MAN.3.BP5: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources
根据项目目标、项目风险、项目理由和边界，定义、监控和调整项目工作量和资源的估计。
Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries
MAN.3.BP6: 确保所需的技能，知识和经验 / Ensure required skills, knowledge, and experience
根据估计，确定项目所需的技能、知识和经验，并确保选定的个人和团队及时具备这些技能和知识。
Identify the required skills, knowledge, and experience for the project in line with the estimates and make sure the selected individuals and teams either have or acquire these in time.
[MAN.3.RC.15] If risks regarding feasibility are not considered, the indicator BP3 should be downrated.
老杨解读：如果未考虑与项目可行性相关的风险，则应降低BP3的打分。
[MAN.3.RC.16] If risks regarding estimates or resources are not considered, the indicator BP5 should be downrated.
老杨解读：如果未考虑与工作量估计及资源相关的风险，则应降低BP5的打分。
[MAN.3.RC.17] If risks regarding skills or knowledge are not considered, the indicator BP6 should be downrated.
老杨解读：如果未考虑人员技能和知识相关的风险，则应降低BP6的打分。
ASPICE VDA Guideline解读(18)：SUP.10 变更请求管理
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)”状态
ASPICE软件开发需求文档模板的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件开发的需求文档模板、ASPICE软件开发需求文档模板的信息别忘了在本站进行查找喔。
