Automative SPICE 之四 过程参考模型和指标

4. 过程参考模型和指标(Level 1)

4.1.采购过程组

4.1.1. ACQ.3 Contract Agreement

合同协定的目的是与供应商进行谈判并达成一致合同/协议

ACQ.4 供应商监督

供应商监督过程的目的是针对商定的要求监控供应商的表现

ACQ.11 技术需求

技术需求过程的目的是建立收购方的技术需求。该过程涉及功能性和非功能性需求的导出，这些需求考虑了产品的生命周期部署，因此得以建立一个技术需求基准。

ACQ.12 法律及行政需求

法律及行政需求过程的目的是定义协议的授予方面，包含期望、债务、法律以及其它符合国家与国际法律的问题

ACQ.13 项目需求

项目需求过程的目的是阐述需求，以确保需求方的项目在执行时是充分规划的，进行了人员调配，是有指挥，有组织的，并且可以控制项目的任务和活动。

ACQ.14 建议书请求

建议书请求过程的目的是准备和签发必须的收购方（需求方）要求。该文档包括但不仅限于合同、项目、资金和技术需求

ACQ.15 供应商资格认定

供应商资格认定过程的目的是评估和确定潜在供应商是否有必备的资格进入提议/标书评审过程。在此过程中，将对潜在供应商的技术背景、质量体系、服务、用户支持能力等进行评估。

 

 

 

 

4.3系统工程过程组

4.3.1. SYS.1 需求引导

目的：需求引导过程的目的是收集、处理和跟踪产品和/或服务的生命周期内不断变化

的客户需求和要求，以便建立一个需求基准，该基准作为定义产品需求的依据。

过程：

1）与客户建立持续性的通信；

2）确定已同意的客户需求并把该需求作为基线；

3）基于不断变化的客户需求，建立一种可变化的机制，以评估客户需求的变化，

并将变化的客户需求合并到基准需求；

4）建立一种机制用来连续监测客户需求；

5）建立一种机制用来确保客户可以很容易地确定其要求的状态和处理情况；

6）确定由技术变化引起的改变和客户需求，并对相关的风险以及影响进行评估

活动：

SYS.1.BP1：获取客户的需求。通过直接征求客户意见并通过查看客户业务提案（如果相关），目标运营和硬件环境以及其他符合客户要求的文档来获取和定义客户需求。

注1：需求引导可能涉及客户和供应商。

注2：商定的客户的需求和对任何变更的评估可以基于可行性研究和/或成本和时间分析。

注3：必须为每个客户需求收集并记录可追溯性所需的信息。

SYS.1.BP2：了解客户的期望。确保供应商和客户以相同的方式理解每个需求。

注4：与客户一起审查需求，有助于更好地了解客户实际需要和期望。请参阅SUP.4联合审查过程。

SYS.1.BP3：同意需求。获得所有相关方的明确协议，并满足这些需求。

SYS.1.BP4：建立客户需求基线。将客户需求正式化，并将其作为项目使用和监测客户需求的基线。供应商应确定客户未说明但隐含的的需求，并在基线中描述这些需求。

SYS.1.BP5：管理客户需求变更。根据客户需求基准管理客户需求所做的所有变更，以确保技术改变和客户需求变化所带来的改进，并确保受变更影响的人能够评估影响和风险，并启动适当的变更控制和缓解措施。

注5：需求变化可能来自不同的来源头，例如技术和客户的需求变化，法律约束。

注6：可能需要一个信息管理系统来管理、存储和查阅需求，以供相关者在必要时时获得任何信息。

SYS.1.BP6：建立客户 - 供应商查询沟通机制。提供客户可以了解其需求变更状态和处置的方法，供应商可以以客户指定的语言和格式传达必要信息，包括数据。

注7：任何变更都应在实施前传达给客户，以便评估影响、时间、成本和功能。

注8：这可能包括与客户的联合会议或正式沟通，以审查其需求和需求状态;请参阅SUP.4联合审查过程。

注9：供应商传达的信息格式可能包括计算机辅助设计数据和电子数据交换。

输出文档：

08-19 Risk management plan → [OUTCOME 6]

08-20 Risk mitigation plan → [OUTCOME 6]

13-04 Communication record → [OUTCOME 1, 4]

13-19 Review record → [OUTCOME 4, 5]

13-21 Change control record → [OUTCOME 3, 4]

15-01 Analysis report → [OUTCOME 2, 3, 6]

17-03 Stakeholder Requirements → [OUTCOME 1, 2]

 

 

4.3.2 SYS.2 系统需求分析

过程目的：系统需求分析过程的目的是将客户需求转变为整套系统技术需求，并以此指导系统设计

过程结果：

1）建立一组系统需求定义；

2）对系统需求进行分类，分析以确定其正确性和可测试性；

3）评估运行环境对系统需求的影响；

4）定义系统需求实施的优先级；

5）批准系统需求，并根据需要进行更新；

6）建立客户需求和系统需求之间的一致性和双边可追溯性；

7）从成本、进度和技术变更方面评估系统需求；

8）将系统需求传递给所有相关各方。（the system requirements are communicated to

all affected parties and baselined.）

注1：可依据可行性和风险研究对系统需求分类。

注2：系统需求通常包括功能、性能、接口、设计要求和检验标准。检验标准为某个需求的检验规定了定性的和定量的标准。检验标准证实一项需求可在已同意的约束内得到验证（ Verification criteria demonstrate that a requirement can be

verified within agreed constraints）。

注3：可测试性系统需求分析包括检验标准的开发。

基本活动：

SYS.2.BP1：构建系统要求。使用客户需求和客户需求变更来确定系统所需的功能和能力。在系统需求规范中指定功能和非功能系统要求。

注1：影响功能和能力的应用参数是系统要求的一部分。

注2：对于客户需求变更，参考SUP.10

SYS.2.BP2：结构化系统需求。通过如系统需求规范来构建系统要求。

项目相关集群分组，（类似功能域？）

按项目的逻辑顺序排序，

根据项目的相关标准进行分类，

根据客户需求确定优先顺序。

注3：优先排序通常包括将功能内容分配给发布计划（根据发布计划来确定优先级的排序？）。参见SPL.2.BP1。

SYS.2.BP3：分析系统需求。分析系统需求，包括它们的相互依赖性，以确保正确性、技术可行性和可验证性，并支持风险识别。分析对成本，进度和技术的影响。

注4：对成本、进度影响的相关分析可能会调整项目估算。参见MAN.3.BP5。

NOTE 4: The analysis of impact on cost and schedule supports the adjustment of project estimates. Refer to MAN.3.BP5.

 

SYS.2.BP4：分析对操作环境的影响。相关系统与操作环境的其他元素之间的接口。分析系统需求对这些接口和操作环境的影响。 [结果3,7]

SYS.2.BP5：制定验证标准。制定每个系统需求的验证标准，从定性和定量方面，制定措施，确定验证要求。 [结果2,7]

注5：验证标准指明在约定的约束条件下验证需求，并且通常用作开发系统测试用例，或作为验证系统需求是否合格的的其他验证措施的输入。

注6：SUP.2涵盖了测试不能涵盖的验证。

SYS.2.BP6：建立双向可追溯性。在客户需求和系统需求之间建立双向可追溯性。 [结果6]

注7：从覆盖面，一致性和影响分析等方面建立双向可追溯性。

SYS.2.BP7：确保一致性。确保客户需求与系统需求之间的一致性[结果6]

注8：可以通过评审记录衡量双向可追溯性是否支持一致性。

SYS.2.BP8：传达商定的系统需求。向所有相关方传达商定的系统需求和系统需求的变更。 [结果8]

 

输出文档：

13-04 Communication record → [OUTCOME 8]

13-19 Review record → [OUTCOME 6]

13-21