系统域工作内容

需求挖掘过程的目的是：在产品和/或服务的整个生命周期内收集、处理和跟踪不断变化的利益相关方的需要和需求，从而建立一个需求基线，作为定义所需工作产品的基础。

过程目的

1) 建立了与利益相关方的持续沟通；

2) 定义和基线化了约定的利益相关方需求；

3) 建立了变更机制，以便基于利益相关方需要的变化，评估利益相关方需求的变更并将其纳入需求基线；

4) 建立了持续监控利益相关方需要的机制；

5) 建立了机制，以确保客户可以容易地判定其要求的状态和处置结果

6) 识别了因技术或利益相关方需要的变化而引发的变更，评估相关的风险并管理其带来的影响

过程成果

备注

SYS.1.BP1:获得利益相关方需求和要求。通过直接征求客户意见并通过评审客户业务提案（相关部分）、目标运行和硬件环境以及其它影响客户需求的文档来获取并定义利益相关方的需求和要求。[成果1，4]注1：需求挖掘可能需要客户和供应商的参与。注2：约定的利益相关方需求和对变更的评估可基于可行性研究和/或成本和时间分析。注3：必须收集并记录保持每个客户需求可追溯性所需的信息。

SYS.1.BP2:理解利益相关方的期望。确保供应商和客户对每个需求有同样的理解。[成果2]注4：与客户一起评审需求和要求有助于更好的理解客户需要和期望。参见过程SUP.4 联合评审。

SYS.1.BP3:达成需求共识。获得所有相关方关于需求的明确协议，以便于开展工作。[成果2]

08-19 风险管理计划 [成果 6]

08-20 风险缓解计划 [成果6]

SYS.1.BP6: 建立客户 - 供应商查询沟通机制。给客户提供可以了解其需求变更状态和处置结果的方法，供应商能够以客户指定的语言和形式沟通包括数据在内的必要信息。[成果5]注7：任何变更在实施之前都应和客户沟通，以便评估时间、成本和功能性的影响。注8：这可包括与客户的联合会议或正式沟通，以评审其需求和要求的状态。参见过程SUP.4 联合评审。注9：供应商沟通的信息格式可包括计算机辅助设计数据和电子数据交换。

基本实践

08-19 风险管理计划 [成果 6]

08-20 风险缓解计划 [成果6]

输出工作产品

SYS.1 需求挖掘

系统需求分析过程的目的是：将已定义的利益相关方需求转换成一组系统需求，以指导系统设计。

1) 建立了一组定义的系统需求 ;

2) 对系统需求进行分类，并分析了其正确性和可验证性;

3) 分析了系统需求对运行环境的影响;

4) 定义了系统需求实施的优先级;

5) 根据需要更新了系统需求；

6) 建立了利益相关方需求和系统需求之间的一致性和双向可追溯性；

7) 从成本、进度和技术影响来评估系统需求；

8) 约定了系统需求，并与所有受影响方沟通。

SYS.2.BP6: 建立双向可追溯性。建立利益相关方需求和系统需求之间的双向可追溯性。[成果6]注7：双向可追溯性有助于覆盖率、 一致性和影响分析。

SYS.2.BP7: 确保一致性。确保利益相关方需求和系统需求之间的一致性。[成果6]注8：一致性由双向可追溯性支持，并可通过评审记录来证明。SYS.2.BP8: 沟通约定的系统需求。与所有相关方沟通约定的系统需求及对系统需求的更新。 [成果8]

13-04 沟通记录 [成果8]

13-19 评审记录 [成果6]

13-21 变更控制记录 [成果1]

13-22 追溯记录 [成果6]

17-50 验证准则 [成果2]

SYS.2 系统需求分析

系统架构设计过程的目的是: 建立系统架构设计，识别将哪些系统需求分配给哪些系统要素，并依照已定义的准则评估系统架构设计。

1) 定义了识别系统要素的系统架构设计；

2) 将系统需求分配给系统的要素；

3) 定义了每个系统要素的接口；

4) 定义了系统要素的动态行为；

5) 建立了系统需求和系统架构设计之间的一致性和双向可追溯性；

6) 约定了系统架构设计，并与所有受影响方沟通。

SYS.3.BP1: 开发系统架构设计。开发并文档化系统架构设计，该设计基于系统功能性需求和非功能性需求定义系统要素。 [成果 1]注1：系统架构设计的开发通常包括在适当的各层级上分解成要素。

SYS.3.BP2: 分配系统需求。将系统需求分配给系统架构设计的要素。[成果2]

SYS.3.BP3: 定义系统要素的接口。识别、开发并文档化每个系统要素的接口。 [成果3]

SYS.3.BP4: 描述动态行为。评估并文档化系统要素之间相互作用的动态行为。[成果4]注2: 动态行为取决于运行模式（例如:启动、关机、正常模式、标定和诊断等）。

SYS.3.BP5: 评估备选的系统架构。定义架构设计的评估准则。根据已定义的准则，评估备选的系统架构。记录被选定的系统架构的选择理由。 [成果1]注3：评估准则可以包括质量特性（模块性、可维护性、可扩展性、可扩缩性、可靠性、安全（security）可实现性、易用性）和开发-购买-重用分析的结果。

SYS.3.BP6: 建立双向可追溯性。建立系统需求和系统架构设计的要素之间的双向可追溯性。 [成果5]注4：双向可追溯性覆盖系统需求向系统架构设计的要素的分配。注5：双向可追溯性有助于覆盖率、 一致性和影响分析。

SYS.3.BP8: 沟通约定的系统架构设计。与所有相关方沟通已约定的系统架构设计及对系统架构设计的更新。[成果 6]

13-04 沟通记录 [成果 6]

13-19 评审记录 [成果5]

13-22 追溯记录 [成果5]

17-08 接口需求规范 [成果3]

SYS.3 系统架构设计

系统集成与集成测试过程的目的是: 集成系统项以产生与系统架构设计相一致的集成系统，并确保系统项得到测试，以提供集成的系统项符合系统架构设计（包括系统项之间的接口）的证据

1) 制订了与项目计划、发布计划和系统架构设计相一致的系统集成策略，以集成系统项；

2) 制订了包括回归测试策略在内的系统集成测试策略，以测试系统项之间的交互；

3) 根据系统集成测试策略，制订了系统集成测试规范，以适于提供集成的系统项符合系统架构设计（包括系统项之间的接口）的证据；

4) 根据集成策略将系统项集成为完整的集成系统；

5) 根据系统集成测试策略和发布计划，选择了系统集成测试规范中的测试用例；

6) 使用选定的测试用例测试了系统项之间的交互，并记录了系统集成测试结果；

7) 建立了系统架构设计的要素和系统集成测试规范中的测试用例之间的一致性和双向可追溯性，并建立了测试用例和测试结果之间的双向可追溯性；

8) 总结了系统集成测试结果，并与所有受影响方沟通。

SYS.4.BP1: 制订系统集成策略。制订与项目计划和发布计划相一致的系统项集成策略。基于系统架构设计识别系统项，并定义其集成顺序。[成果 1]

SYS.4.BP2: 制订包括回归测试策略在内的系统集成测试策略。遵循集成策略，制订集成系统项的测试策略。该策略包括当系统项变更时对集成的系统项实施再测试的回归测试策略。[成果 2]

SYS.4.BP3：开发系统集成测试规范。根据系统集成测试策略，开发系统集成测试规范（包括系统项的各集成步骤的测试用例）。测试规范应适于提供集成的系统项符合系统架构设计的证据。[成果 3]注1：系统要素之间的接口描述是系统集成测试用例的输入。注2：符合系统架构设计是指，定义的集成测试适于证明系统项之间的接口满足系统架构设计的规范。注3：系统集成测试用例可关注： 系统项之间的正确信号流 系统项之间信号流的时效性和时序依赖性 使用接口正确解释所有系统项的信号 系统项之间的动态交互注4：可使用仿真环境（例如：硬件在环仿真，车载网络仿真，数字原型）支持系统集成测试。

SYS.4.BP4: 集成系统项。根据系统集成策略，将系统项集成为集成系统。[成果 4]注5：系统集成可逐步集成系统项（例如：作为原型硬件的硬件要素，外设（传感器和执行器），机械和集成软件），以产生与系统架构设计相一致的系统。

SYS.4.BP5: 选择测试用例。从系统集成测试规范中选择测试用例。测试用例的选择应根据系统集成测试策略和发布计划具备足够的覆盖率。[成果 5]

SYS.4.BP6: 执行系统集成测试。使用选定的测试用例执行系统集成测试。记录集成测试结果和日志。[成果 6]注6：不符合项的处理，见SUP.9。

SYS.4.BP7: 建立双向可追溯性。建立系统架构设计要素与系统集成测试规范中的测试用例之间的双向可追溯性。建立系统集成测试规范中的测试用例与系统集成测试结果之间的双向可追溯性。[成果 7]注7：双向可追溯性有助于覆盖率、一致性和影响分析。

SYS.4.BP8: 确保一致性。确保系统架构设计要素与系统集成测试规范中的测试用例之间的一致性。[成果 7]注8：一致性由双向可追溯性支持，并可通过评审记录来证明。

SYS.4.BP9: 总结和沟通结果。总结系统集成测试结果，并与所有受影响方沟通。[成果8]注9：在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。

11-06 系统 [成果4]

13-19 评审记录 [成果7]

13-22 追溯记录 [成果7]

SYS.4 系统集成与集成测试

系统合格性测试过程的目的是：确保集成系统得到测试，以提供符合系统需求的证据，并确保系统可用于交付。

1) 制订了与项目计划和发布计划相一致的系统合格性测试策略（包括回归测试策略），以测试已集成的系统。

2) 根据系统合格性测试策略，制订了已集成系统的系统合格性测试规范，以适于提供符合系统需求的证据。

3) 根据系统合格性测试策略和发布计划，选择了系统合格性测试规范中的测试用例。

4) 使用选择的测试用例测试了已集成的系统，并记录了系统合格性测试的结果。

5) 建立了系统需求与系统合格性测试规范中测试用例之间的一致性和双向可追溯性，并建立了测试用例与测试结果之间的一致性和双向可追溯性。

6) 总结了系统合格性测试结果，并与所有受影响方沟通。

SYS.5.BP1: 制订包括回归测试策略在内的系统合格性测试策略。 制订与项目计划和发布计划相一致的系统合格性测试策略。该策略包括当系统项变更时，对已集成系统实施再测试的回归测试策略。[成果1]

SYS.5.BP2: 开发系统合格性测试规范。 根据系统合格性测试策略，开发系统合格性测试规范（包括基于验证准则的测试用例）。该规范应适于提供集成系统符合系统需求的证据。 [成果2]

SYS.5.BP3: 选择测试用例。 从系统合格性测试规范中选择测试用例。对于系统合格性测试策略和发布计划而言，所选择的测试用例应具备足够的覆盖率。 [成果3]

SYS.5.BP4: 测试已集成的系统。 使用已选择的测试用例测试已集成的系统。 记录系统合格性测试的结果和日志。 [成果4]注1：不符合项的处理，见SUP.9。

SYS.5.BP5: 建立双向可追溯性。建立系统需求与系统合格性测试规范中的测试用例之间的双向可追溯性。建立系统合格性测试规范中的测试用例与系统合格性测试结果之间的双向可追溯性。[成果5]注2：双向可追溯性有助于覆盖率、一致性和影响分析。

SYS.5.BP6: 确保一致性。确保系统需求和系统合格性测试规范中的测试用例之间的一致性。 [成果5]注3：一致性由双向可追溯性支持，并可通过评审记录来证明。

SYS.5.BP7: 总结和沟通结果。 总结系统合格性测试结果，并与所有受影响方沟通。 [成果6]注4：在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。

08-52 测试计划 [成果1]

13-04 沟通记录 [成果6]

SYS.5 系统合格性测试

系统域工作内容