系统域工作内容

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

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]

SYS.1.BP4:建立利益相关方需求基线。将利益相关方的需求正式化，并建立基线以便项目使用和依照利益相关方需要进行监控。供应商应确定利益相关方未说明的但对指定和预期用途有必要的需求，并将其包括在基线中。[成果2,3 ]

SYS.1.BP5: 管理利益相关方需求变更。依照利益相关方需求基线来管理所有利益相关方需求的变更，以确保识别技术和利益相关方需要的变化而带来的改进，以及确保受变化影响的人能够评估影响和风险，并启动适当的变更控制和缓解措施。[成果3, 6 ] 注5：需求变化可有不同的来源，例如技术和利益相关方需求的变化、法律约束。 注6：在定义约定的利益相关方需求时所获的和所需的信息可能需要信息管理系统来进行管理、存储和引用。

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

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

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

13-04 沟通记录 [成果1, 4]

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

13-21 变更控制记录 [成果3, 4]

15-01 分析报告 [成果2, 3, 6]

17-03 利益相关方需求 [成果1, 2]

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

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

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

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

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

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

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

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

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

SYS.2.BP1:定义系统需求。使用利益相关方需求及其变更，以识别系统所需的功能和能力。在系统需求规范中定义功能性和非功能性系统需求。[成果1, 5, 7] 注1：影响功能和能力的应用参数是系统需求的一部分。 注2：关于利益相关方需求的变更，适用SUP.10

SYS.2.BP2:结构化系统需求。在系统需求规范中结构化系统需求，例如：  按项目相关集群进行分组，  按项目中逻辑顺序排序，  基于项目相关准则进行分类，  根据利益相关方需要进行优先级排序。 [成果2, 4] 注3：优先级排序通常包括将功能性内容分配给已计划的发布。参见SPL.2.BP1。

SYS.2.BP3: 分析系统需求。分析已定义的系统需求（包括它们的相互依赖关系），以确保正确性、技术可行性和可验证性，并且支持风险识别。分析对成本、进度和技术的影响。[成果1, 2, 7] 注4：对成本和进度的影响分析有助于项目估算的调整。参见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 沟通记录 [成果8]

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

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

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

15-01 分析报告 [成果2, 3, 4, 7]

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

17-12 系统需求规范 [成果1, 5]

17-50 验证准则 [成果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.BP7: 确保一致性。 确保系统需求和系统架构设计间的一致性。[成果1, 2, 5, 6]
注6：一致性由双向可追溯性支持，并可通过评审记录来证明。
注 7: 系统需求通常包括系统架构需求。参见BP5。

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

04-06 系统架构设计 [成果1, 2, 3, 4, 5]

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

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

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

17-08 接口需求规范 [成果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：在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。

08-50 测试规范 [成果 3, 5]

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

11-06 系统 [成果4]

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

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

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

13-50 测试结果 [成果6, 8]

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

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-50 测试规范 [成果2, 3]

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

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

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

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

13-50 测试结果 [成果4, 6]