|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 过程ID | SYS.1 |
| 过程名称 | 需求挖掘 |
| 过程目的 | 需求挖掘过程的目的是:在产品和/或服务的整个生命周期内收集、处理和跟踪不断变化的利益相关方的需要和需求，从而建立一个需求基线，作为定义所需工作产品的基础。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)建立了与利益相关方的持续沟通; 2)定义和基线化了约定的利益相关方需求; 3)建立了变更机制，以便基于利益相关方需要的变化，评估利益相关方需求的变更并将其纳入需求基线; 4)建立了持续监控利益相关方需要的机制; 5)建立了机制，以确保客户可以容易地判定其要求的状态和处置结果； 6)识别了因技术或利益相关方需要的变化而引发的变更，评估相关的风险并管理其带来的影响5 |
| 基本实践 | SYS.1.BP1:获得利益相关方需求和要求。 通过直接征求客户意见并通过评审客户业务提案(相关部分)，目标运行和硬件环境以及其它影响客户需求的文档来获取并定义利益相关方的需求和要求。成果1，4 注 1:需求挖掘可能需要客户和供应商的参与。 注 2:约定的利益相关方需求和对变更的评估可基于可行性研究和/或成本和时间分析。 注 3:必须收集并记录保持每个客户需求可追溯性所需的信息。 SYS.1.BP2:理解利益相关方的期望。 确保供应商和客户对每个需求有同样的理解。成果 2 注 4:与客户一起评审需求和要求有助于更好的理解客户需要和期望。参见过程 SUP.4 联合评审。 SYS.1.BP3**:**达成需求共识。 获得所有相关方关于需求的明确协议，以便于开展工作。成果2 SYS.1.BP4:建立利益相关方需求基线。 将利益相关方的需求正式化，并建立基线以便项目使用和依照利益相关方需要进行监控。供应商应确定利益相关方未说明的但对指定和预期用途有必要的需求，并将其包括在基线中。成果23 **SYS.1.BP5:**管理利益相关方的需求变更。 依照利益相关方需求基线来管理所有利益相关方需求的变更，以确保识别技术和利益相关方需要的变化而带来的改进，以及确保受变化影响的人能够评估影响和风险，并启动适当的变更控制和缓解措施。成果3.6 注 5:需求变化可有不同的来源，例如技术和利益相关方需求的变化、法律约束。 注 6:在定义约定的利益相关方需求时所获的和所需的信息可能需要信息管理系统来进行管理，存储和引用. SYS.1.BP6:建立客户_供应商查询沟通机制。 |
| 输出工作产品 | 风险管理计划、风险缓解计划 沟通记录、评审记录 变更控制记录 利益相关方需求、需求分析报告 |
|------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 过程ID | SYS.2 |
| 过程名称 | 系统需求分析 |
| 过程目的 | 系统需求分析过程的目的是:将已定义的利益相关方****需求转换成一组系统****需求，以指导系统设计。 |
| 过程成果 | 成功实施这个过程的结果如下; 1)建立了一组定义的系统需求; 2)对系统需求进行分类，并分析了其正确性和可验证性; 3)分析了系统需求对运行环境的影响; 4)定义了系统需求实施的优先级; 5)根据需要更新系统需求; 6)建立了利益相关方需求和系统需求之间的一致性和双向可追溯性; 7)从成本、进度和技术影响来评估系统需求; 8)约定了系统需求，并与所有受影响方沟通。 |
| 基本实践 | SYS.2.BP1:定义系统需求。 使用利益相关方需求及其变更，以识别系统所需的功能和能力。在系统需求规范中定义功能性和非功能性系统需求。 注 1:影响功能和能力的应用参数是系统需求的一部分。 注 2:关于利益相关方需求的变更，适用SUP.10 SYS.2.BP2:结构化系统需求。 在系统需求规范中结构化系统需求，例如: 按项目相关集群进行分组；按项目中逻辑顺序排序；基于项目相关准则进行分类；根据利益相关方需要进行优先级排序。 注 3:优先级排序通常包括将功能性内容分配给已发布的计划。 SYS.2.BP3:分析系统需求。 分析已定义的系统需求(包括它们的相互依赖关系)，以确保正确性、技术可行性和可验证性，并且支持风险识别。分析对成本、进度和技术的影响。 SYS.2.BP4:分析对运行环境的影响。 识别定义的系统和运行环境中其他要素之间的接口。分析系统需求对这些接口和运行环境的影响。 SYS.2.BP5:制订验证准则。 对每一个系统需求制订验证准则，定义定性的和定量的措施用于需求验证。 注 5:验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作系统测试用例开发或其它证明符合系统需求的验证措施的输入。 注 6:测试不能覆盖的验证由 SUP.2 覆盖。 SYS.2.BP6:建立双向可追溯性。 建立利益相关方需求和系统需求之间的双向可追溯性。 注 7:双向可追溯性有助于覆盖率， 一致性和影响分析。 SYS.2.BP7:确保一致性。 确保利益相关方需求和系统需求之间的一致性。 SYS.2.BP8:沟通约定的系统需求。 与所有相关方沟通约定的系统需求及对系统需求的更新。 |
| 输出工作产品 | 系统架构设计、沟通记录、评审记录、追溯记录、接口需求规范 |
|------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 过程ID | SYS.3 |
| 过程名称 | 系统架构设计 |
| 过程目的 | 建立系统架构，确定哪些需求分配给哪些系统元素，并根据定义的标准评估所设计的系统架构。 |
| 过程成果 | 成功实施这个过程的结果如下: 1) 已经定义了系统架构设计，并已经标识了系统元素； 2) 系统需求已经被分配给了系统元素； 3) 系统元素的每个接口已经定义； 4) 已经定义了系统的动态行为目标； 5) 在系统需求和系统架构设计之间已经建立了一致性和双向可追溯性； 6) 系统架构设计已经传达给受影响的各方并且达成了一致。 |
| 基本实践 | SYS.3.BP1:提供所有系统的设计； SYS.3.BP2:描述系统元素之间的相互关系； SYS.3.BP3: 描述系统元素与软件之间的相互关系； SYS.3.BP4: 详细说明每个必需系统元素的设计，需要考虑到以下内容：内存和容量的需求、硬件接口需求、用户接口需求、外部系统接口需求、性能需求、指令结构、安全及数据保护特性、系统参数设定、人工操作、可重用组件等; SYS.3.BP5: 系统元素与需求之间的映射关系 SYS.3.BP6: 描述系统组件运行模式（启动、停止、睡眠模式、诊断模式等） SYS.3.BP7: 描述在不同运行模式下各个系统组件之间依赖关系； SYS.3.BP8: 描述系统和系统组件的动态行为。 |
| 输出工作产品 | 沟通记录、审查记录、跟踪记录、 系统架构设计 |
|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 过程ID**** | SYS.4 |
| 过程名称 | 系统集成与集成测试 |
| 过程目的 | 系统集成与集成测试过程的目的是:集成系统项以产生与系统架构设计相一致的集成系统，并确保系统项得到测试，以提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据。 |
| 过程成果 | 成功实施这个过程的结果如下; 1) 制订了与项目计划、发布计划和系统架构设计相一致的系统集成策略，以集成系统项; 2) 制订了包括回归测试策略在内的系统集成测试策略，以测试系统项之间的交互; 3) 根据系统集成测试策略，制订了系统集成测试规范，以适于提供集成的系统项符合系统架构设计(包括系统项之间的接口)的证据; 4) 根据集成策略将系统项集成为完整的集成系统; 5) 根据系统集成测试策略和发布计划，选择了系统集成测试规范中的测试用例; 6) 使用选定的测试用例测试了系统项之间的交互，并记录了系统集成测试结果; 7) 建立了系统架构设计的要素和系统集成测试规范中的测试用例之间的一致性和双向可追溯性，并建立了测试用例和测试结果之间的双向可追溯性; 8) 总结了系统集成测试结果，并与所有受影响方沟通。 |
| 基本实践 | **SYS.4.BP1:**制订系统集成策略。 制订与项目计划和发布计划相一致的系统项集成策略。基于系统架构设计识别系统项，并定义其集成顺序。 SYS.4.BP2:制订包括回归测试策略在内的系统集成测试策略. 遵循集成策略，制订集成系统项的测试策略。该策略包括当系统项变更时对集成的系统项实施再测试的回归测试策略。 SYS.4.BP3:开发系统集成测试规范. 根据系统集成测试策略，开发系统集成测试规范(包括系统项的各集成步骤的测试用例)。测试规范应话于提供集成的系统项符合系统架构设计的证据。 注 1:系统要素之间的接口描述是系统集成测试用例的输入。 注 2:符合系统架构设计是指，定义的集成测试适于证明系统项之间的接口满足系统架构设计的规范。 注 3:系统集成测试用例可关注: 系统项之间的正确信号流 系统项之间信号流的时效性和时序依赖性 使用接口正确解释所有系统项的信号 系统项之间的动态交互 注 4:可使用仿真环境(例如:硬件在环仿真，车载网络仿真，数字原型)支持系统集成测试。 **SYS.4.BP4:**集成系统项。 根据系统集成策略，将系统项集成为集成系统 注 5:系统集成可逐步集成系统项(例如:作为原型硬件的硬件要素，外设(传感器和执行器)，机械和集成软件)，以产生与系统架构设计相一致的系统。 SYS.4.BP5:选择测试用例. 从系统集成测试规范中选择测试用例，测试用例的选择应根据系统集成测试策略和发布计划具备足够的要盖率。 SYS.4.BP6:执行系统集成测试. 使用选定的测试用例执行系统集成测试。记录华成测试结果和日志。 注 6:不符合项的处理，见SUP.9 SYS.4.BP7:建立双向可追溯性. 建立系统架构设计要素与系统集成测试规范中的测试用例之间的双向可追溯性，建立系统集成测试规范中的测试用例与系统集成测试结果之间的双向可追溯性。 注 7:双向可追溯性有助于覆盖率、一致性和影响分析。 SYS.4.BP8:确保一致性. 确保系统架构设计要素与系统集成测试规范中的测试用例之间的一致性。 注 8:一致性由双向可追溯性支持，并可通过评审记录来证明。 **SYS.4.BP9:**总结和沟通结果。 总结系统集成测试结果，并与所有受影响方沟通。 注 9:在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。 |
| 输出工作产品 | 测试规范、测试计划、系统、沟通记录、评审记录、追溯记录、测试结果 |
|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 过程ID**** | SYS.5 |
| 过程名称 | 系统合格测试 |
| 过程目的 | 系统合格性测试过程的目的是:确保集成系统得到测试，以提供符合系统需求的证据，并确保系统可用于交付。 |
| 过程成果 | 成功实施这个过程的结果如下; 1)制订了与项目计划和发布计划相一致的系统合格性测试策略(包括回归测试策略)，用以测试已集成的系统。 2) 根据系统合格性测试策略，制订了已集成系统的系统合格性测试规范以适于提供符合系统需求的证据。 3) 根据系统合格性测试策略和发布计划，选择了系统合格性测试规范中的测试用例。 4)使用选择的测试用例测试了已集成的系统，并记录了系统合格性测试的结果。 5)建立了系统需求与系统合格性测试规范中测试用例之间的一致性和双向可追溯性，并建立了测试用例与测试结果之间的一致性和双向可追溯性。 6)总结了系统合格性测试结果，并与所有受影响方沟通 |
| 基本实践 | **SYS.5.BP1:**制订包括回归测试策略在内的系统合格性测试策略。 制订与项目计划和发布计划相一致的系统合格性测试策略。该策略包括当系统项变更时，对已集成系统实施再测试的回归测试策略。 **SYS.5.BP2:**开发系统合格性测试规范。 根据系统合格性测试策略，开发系统合格性测试规范(包括基于验证准则的测试用例)。该规范应适于提供集成系统符合系统需求的证据。 **SYS.5.BP3:**选择测试用例。 从系统合格性测试规范中选择测试用例。对于系统合格性测试策略和发布计划而言，所选择的测试用例应具备足够的覆盖率。 **SYS.5.BP4:**测试已集成的系统。 使用已选择的测试用例测试已集成的系统。记录系统合格性测试的结果和日志。 注 1:不符合项的处理，见 SUP.9。 **SYS.5.BP5:**建立双向可追溯性。 建立系统需求与系统合格性测试规范中的测试用例之间的双向可追溯性。建立系统合格性测试规范中的测试用例与系统合格性测试结果之间的双向可追溯性。 注 2:双向可追溯性有助于覆盖率、一致性和影响分析。 **SYS.5.BP6:**确保一致性。 确保系统需求和系统合格性测试规范中的测试用例之间的一致性。 注 3:一致性由双向可追溯性支持，并可通过评审记录来证明。 **SYS.5.BP7:**总结和沟通结果。 总结系统合格性测试结果，并与所有受影响方沟通 注 4:在总结中提供来自测试用例执行的所有必要信息，以便其他方判断结果。 |
| 输出工作产品 | 测试规范、测试计划、沟通记录、评审记录、追溯记录、测试结 |
|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 过程ID**** | SWE.1 |
| 过程名称 | 软件需求分析 |
| 过程目的 | 软件需求分析过程的目的是：将系统需求中与软件相关的部分转化为一组软件需求。 |
| 过程成果 | 成功实施这个过程的结果如下: 1)定义了系统中分配给软件要素的软件需求及其接口; 2)将软件需求进行分类，并分析了其正确性和可验证性; 3)分析了软件需求对运行环境的影响; 4)定义了软件需求实现的优先级; 5)根据需要更新了软件需求: 6)在系统需求与软件需求之间、在系统架构设计与软件需求之间建立了一致性和双向可追溯性; 7)从成本、进度和技术影响来评估软件需求; 8)约定了软件需求，并与所有受影响方沟通。 |
| 基本实践 | **SWE.1.BP1:**定义软件需求。 使用系统需求和系统架构及其变更来识别软件所需的功能和能力。在软件需求规范中定义功能性和非功能性软件需求。 注1：影响功能和能力的应用参数是系统需求的一部分。 注2： 如果只有软件开发，系统需求和系统架构是指给定的运行环境（参见注5）。在这种情况下，应将利益相关方需求作为识别软件所需功能和能力以及识别影响软件功能和能力的应用参数的基础。 **SWE.1.BP2:**结构化软件需求。 在软件需求规范中结构化软件需求，例如: 按项目相关集群进行分组， 按项目中逻辑顺序排序， 基于项目相关准则进行分类， 根据利益相关方需要进行优先级排序。 注3： 优先级排序通常包括将软件内容分配给已计划的发布。参见SPL.2.BP1。 **SWE.1.BP3:**分析软件需求。 分析已定义的软件需求，包括其相互依赖关系，以确保正确性、技术可行性和可验证性，并支持风险识别，分析对成本、进度和技术的影响。 **SWE.1.BP4:**分析对运行环境的影响。 分析软件需求对系统要素接口及运行环境的影响。 注5： 运行环境是指软件运行所在的系统(例如：硬件、操作系统等) 。 **SWE.1.BP5:**制订验证准则。 对每个软件需求制订验证准则，定义定性的和定量的措施以用于需求验证。 注6： 验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作软件测试用例开发或其他证明符合软件需求的验证措施的输入。 注7：测试不能覆盖的验证由SUP.2覆盖。 **SWE.1.BP6:**建立双向可追溯性。 建立系统需求与软件需求之间的双向可追溯性，建立系统架构设计与软件需求之间的双向追溯性。 注8： 应通过建立同时满足项目和组织要求的方法来避免冗余。 注9：双向可追溯性有助于覆盖率、一致性和影响分析。 **SWE.1.BP7:**确保一致性。 确保系统需求与软件需求之间的一致性，确保系统架构与软件需求之间的一致性。 注10：一致性由双向可追溯性支持，并可通过评审记录来证明。 注11：如果只有软件开发，必须确保利益相关方需求与软件需求之间的一致性和双向可追溯性。 **SWE.1.BP8:**沟通约定的软件需求。 与所有相关方沟通约定的软件需求及对软件需求的更新。 |
| 输出工作产品 | 沟通记录、评审记录、追溯记录、变更控制记录、分析报告、接口需求规范、软件需求规范、验证准则 |