主要参考《Automotive-SPICE-PAM-v40.pdf》

上图是SYS各子过程在V形图的表示。

1.SYS.1.BP1: 获取所有相关方的需求

SYS.1.BP1: 获取所有相关方的需求

通过直接征求利益相关者输入、评审利益相关者商业建议书（如相关）及其他包含利益相关者需求输入的文档，并考虑目标运行和硬件环境，来获取和定义利益相关者的期望和请求。

注 1: 记录利益相关者或利益相关者需求的来源，支持利益相关者需求的一致性协议和变更分析（参见 BP2 和 BP3）。

洞察: 这条实践强调了多渠道、系统化地收集原始需求的重要性。不仅仅是直接询问，还要通过分析现有文档（如商业计划）和考虑技术环境（硬件、运行环境）来全面挖掘需求，避免遗漏关键信息。同时，对需求来源的记录是后续可追溯性和有效管理的基础。

SYS.1.BP2: 商定需求

将利益相关者的期望和请求正式化为需求。通过获得所有受影响方的明确同意，在受影响方之间就利益相关者需求集达成共同理解。

注 2: 受影响方的例子有客户、供应商、设计伙伴、合资伙伴或外包方。

注 3: 经商定的利益相关者需求可能基于可行性研究和/或成本和进度影响分析。

洞察: 本实践的核心是共识和正式化。它不仅仅要求收集需求，更要求将这些非正式的期望转化为清晰、可管理的需求声明，并获得所有关键参与者的明确认可。这避免了后期因理解偏差而导致的返工和冲突，并暗示了需求可能需要经过可行性及影响分析。

SYS.1.BP3: 分析利益相关者需求变更

根据已商定的利益相关者需求，分析对利益相关者需求所做的所有变更。评估其影响和风险，并启动适当的变更控制和缓解措施。

注 4: 需求变更可能源于不同来源，例如技术变化、利益相关者需求或法律限制。

注 5: 如有需要，请参阅 SUP.10 变更请求管理。

洞察: 这条实践强调了变更管理的严谨性。需求变更在汽车行业是常态，但必须被视为高风险事件。因此，任何变更都必须经过严格的分析（评估对现有协议的影响、潜在风险），并触发正式的变更控制流程和风险缓解措施。这确保了变更是有序、受控且经过深思熟虑的。同时，这也说明考虑系统需要系统性思维，考虑联系性，也要动态地看待系统，不能期望一劳永逸。

SYS.1.BP4: 沟通需求状态

确保所有受影响方都能了解其需求的状态和处置情况，包括变更，并能沟通必要的信息和数据。

洞察: 这条实践聚焦于沟通的及时性与透明度。所有受需求影响的团队和个人都必须能够随时了解需求的最新状态（例如，已确认、已变更、已暂停等），以及这些变更的原因和结果。这促进了整个项目团队的信息同步，确保所有决策都基于最新的需求信息，并支持双向的信息反馈。

2. SYS.2 系统需求分析 (System Requirements Analysis) 的基础实践

SYS.2.BP1: 规定系统需求

根据对需求定义的特性，使用利益相关者需求来识别并文档化系统的功能和非功能需求。

注 1: 需求的特性在 ISO IEEE 29148、ISO 26262-8:2018 或 INCOSE 需求编写指南等标准中定义。

注 2: 技术标准共享的需求特性示例是可验证性（即验证准则固有于需求文本中）、无歧义/可理解性、独立于设计和实现，以及不与其他任何需求相矛盾。

洞察: 这条实践强调了从高层级的“利益相关者需求”向低层级的“系统需求”转化的严格性与规范性。它要求在转化过程中，不仅要区分功能和非功能需求，还要确保这些系统需求符合质量标准（如可验证、无歧义、独立于设计），为后续的设计和测试打下坚实基础。

SYS.2.BP2: 结构化系统需求

结构化并优先级排序系统需求。

注 3: 结构化标准的例子可以是分组（例如，按功能）或产品变体识别。

注 4: 优先级排序可以根据项目或利益相关者需求进行，例如通过定义发布范围。请参阅 SPL.2.BP1。

洞察: 本实践的核心是对复杂需求的管理和组织。通过结构化（例如按功能分组）和优先级排序，使得海量的系统需求变得易于理解、管理和规划。优先级排序尤其重要，它直接影响项目范围、资源分配和发布计划，确保核心价值优先实现。

SYS.2.BP3: 分析系统需求

分析已规定的系统需求，包括它们之间的相互依赖关系，以确保正确性、技术可行性，并支持项目管理进行项目估算。

注 5: 关于项目可行性请参阅 MAN.3.BP3，关于项目估算请参阅 MAN.3.BP5。

注 6: 技术可行性可以基于例如平台或产品线，或通过原型开发或产品演示器来评估。

洞察: 这条实践是系统需求的**“质量门”**。它要求深入审查需求的内在品质（正确性、无矛盾）和外部约束（技术上是否能实现），并识别需求间的相互影响。这种分析不仅保障了需求本身的质量，还为项目管理提供了关键输入（如估算），帮助项目在早期就识别潜在的技术风险和资源瓶颈。

SYS.2.BP4: 分析对系统上下文的影响

分析系统需求将对相关系统上下文中的元素产生的影响。

洞察: 本实践强调大局观和系统思维。在定义系统需求时，不仅仅要关注系统本身，还要考虑它将如何影响其外部环境（例如，与之交互的其他系统、用户、基础设施等）。这种分析有助于识别潜在的外部依赖、接口问题和意想不到的副作用，避免局部优化导致整体问题。

SYS.2.BP5: 确保一致性并建立双向可追溯性

确保系统需求与利益相关者需求之间的一致性，并建立双向可追溯性。

注 7: 双向可追溯性支持一致性，促进变更请求的影响分析，并支持证明利益相关者需求的覆盖率。仅可追溯性（例如，链接的存在）不一定意味着信息相互一致。

注 8: 可能存在系统需求无法追溯到的非功能性利益相关者需求。例如过程要求。此类利益相关者需求仍需验证。

洞察: 这是 ASPICE 中最核心的原则之一。它要求建立系统需求与其上层利益相关者需求之间的明确链接，并确保内容上的一致性。双向可追溯性不仅是审计和合规性的要求，更是变更管理、缺陷分析和证明需求覆盖率的强大工具。注释还提醒我们，即使建立了链接，仍需确保内容的一致性。也就意味着对于需求管理工具而言，不仅需要有链接，而且链接的需求或相关内容发生变化时需要提示需求相关人员。

SYS.2.BP6: 沟通已商定的系统需求及其对系统上下文的影响

将已商定的系统需求以及对系统上下文影响分析的结果，传达给所有受影响方。

洞察: 本实践强调沟通的及时性、全面性和有效性。系统需求一旦确定并获得批准，必须立即且清晰地通知所有相关团队（如软件团队、硬件团队、测试团队），以及系统上下文中的相关方。这确保了所有人都基于同一套最新的、已批准的需求工作，避免信息孤岛和因信息滞后导致的错误。

3. SYS.3 系统架构设计 (System Architectural Design) 的基础实践

SYS.3.BP1: 规定系统架构的静态方面

根据功能和非功能系统需求，规定并文档化系统架构的静态方面，包括外部接口以及一组定义的系统元素及其接口和关系。

洞察: 这条实践聚焦于系统“骨架”的定义。它要求清晰地描绘系统的组成部分（元素）、它们之间的结构关系以及与外部世界的连接方式。这是系统蓝图的基础，确保了所有参与者对系统结构有一致的理解，为后续的详细设计和开发提供稳固框架。

SYS.3.BP2: 规定系统架构的动态方面

根据功能和非功能系统需求，规定并文档化系统架构的动态方面，包括系统元素的行为以及它们在不同系统模式下的交互。

注 1: 系统元素交互的例子包括反映机械部件惯性、ECU 处理时间以及总线系统信号传播时间的时序图。

洞察: 与静态方面互补，这条实践关注系统“生命”或“行为”。它要求描述系统元素在不同状态（如正常运行、故障模式、启动/关机等）下的动态响应、数据流、控制流以及它们之间的时间关系。这对于理解系统的运行时性能、并发性、故障模式和整体响应能力至关重要。

SYS.3.BP3: 分析系统架构

分析系统架构中与产品生命周期相关的技术设计方面，并支持项目管理进行项目估算，并推导出非软件系统元素的特殊特性。文档化系统架构设计决策的理由。

注 2: 关于项目可行性请参阅 MAN.3.BP3，关于项目估算请参阅 MAN.3.BP5。

注 3: 产品生命周期阶段的例子有生产、维护与维修、退役。

注 4: 技术方面的例子有生产制造性、可重用预存在系统元素的适用性，或系统元素的可用性。

注 5: 适合分析技术方面的方法的例子有原型、仿真和定性分析（例如 FMEA 方法）。

注 6: 设计理由的例子有经过验证的使用、重用产品平台或产品线、自制或购买决策，或以演进方式发现（例如基于集合的设计）。

洞察: 这条实践是架构设计的质量保障和决策透明度的关键。它要求对架构进行多维度、跨生命周期的深入分析（如可制造性、可维护性、重用性、FMEA等），并识别出非软件组件的特定要求。更重要的是，它强制要求记录所有设计决策背后的理由。这不仅有助于未来理解设计意图，也为应对变更、解决问题和进行审计提供了宝贵的历史信息。

SYS.3.BP4: 确保一致性并建立双向可追溯性

确保系统架构元素与代表物理最终产品属性或特性的系统需求之间的一致性，并建立双向可追溯性。

注 7: 双向可追溯性进一步支持一致性，促进变更请求的影响分析，并证明验证覆盖率。仅可追溯性（例如，链接的存在）不一定意味着信息相互一致。

注 8: 可能存在系统架构设计无法追溯到的非功能性需求。例如不直接涉及或代表物理最终产品的属性或特性。此类需求仍需验证。

洞察: 这是 ASPICE 流程的核心粘合剂。它确保了从“要做什么”（系统需求）到“怎么做”（系统架构）之间的紧密联系。双向可追溯性是变更管理（快速评估影响）、验证覆盖率分析和证明设计符合需求的基石。注释强调了“一致性”不仅仅是链接的存在，更是内容上的匹配，并且提醒有些非功能性需求可能不直接映射到架构元素，但仍需验证。

SYS.3.BP5: 沟通已商定的系统架构

将已商定的系统架构，包括其特殊特性，传达给所有受影响方。

洞察: 这条实践强调了沟通的及时性与全面性。一旦系统架构被确定并获得批准，其详细内容（包括识别出的特殊技术特性）必须及时、清晰地传达给所有相关的开发团队（如软件、硬件团队）、测试团队以及其他利益相关者。这确保了所有下游活动都基于统一的、最新的架构视图，避免信息孤岛和因理解偏差导致的问题。

4. SYS.4 系统集成与集成验证 (System Integration and Integration Verification) 的基础实践

SYS.4.BP1 侧重于“如何计划测试”，SYS.4.BP2 侧重于“如何选择测试范围和优先级”，而 SYS.4.BP3 则侧重于“如何执行测试并记录结果”。它们共同构成了系统集成验证的完整闭环。

• SYS.4.BP1 对应着编写测试用例、测试方法（验证技术）、定义通过/失败标准、进入/退出准则以及测试平台/环境的准备。它是测试计划和准备阶段。
  
• SYS.4.BP2 对应着选择哪些测试用例需要执行，并对其进行优先级排序，特别是要考虑回归测试的需求和发布范围。
  
• SYS.4.BP3 对应着执行测试，即按照计划实际进行集成并运行选定的测试用例，并详细记录测试结果。
  

SYS.4.BP1: 规定系统集成验证的验证措施

根据系统架构的静态和动态方面，基于已定义的系统元素集成序列和前置条件，规定验证措施，包括：

• 验证措施的技术。
  
• 验证措施的通过/失败标准。
  
• 验证措施的进入和退出标准的定义。
  
• 所需的验证基础设施和环境设置。

注 1: 验证措施可能关注的例子是接口系统元素之间正确信号流的时序依赖性，或硬件和软件之间的交互，如系统架构中规定的。系统集成测试用例可能关注：

• 系统项之间正确的信号流。
  
• 系统项之间信号流的及时性和时序依赖性。
  
• 所有使用接口的系统项对信号的正确解释，和/或系统项之间的动态交互。

洞察: 这条实践强调了“集成测试计划的全面性和精确性”。它要求在集成开始前，就明确定义如何验证集成后的系统元素，不仅仅是功能，更要关注元素间的接口、时序和动态交互。此外，明确的通过/失败标准以及进入/退出准则，确保了测试的客观性和可控性，而基础设施和环境的准备则保障了测试的可执行性。

SYS.4.BP2: 选择验证措施

为每个集成步骤文档化验证措施的选择，并考虑选择标准，包括回归验证的标准。文档化的验证措施选择应根据发布范围具有足够的覆盖率。

注 2: 选择标准的例子可以是需求的优先级排序、回归验证的需求（例如，由于系统架构设计或系统组件的变更），或所交付产品发布（例如，测试台架、测试轨道、公共道路等）的预期用途。

洞察: 本实践的核心是“有策略的测试用例选择”。它强调了测试用例的选择不是随意进行的，而是要基于项目需求、变更影响和发布目标进行有针对性的选择。特别是对回归验证的强调，确保了在集成新功能或修复缺陷时，不会引入新的问题或破坏现有功能，这对于保证系统稳定性至关重要。

SYS.4.BP3: 集成系统元素并执行集成验证

根据系统元素之间规定的接口和交互，以及定义的序列和前置条件，集成系统元素直至系统完全集成。执行所选的系统集成验证措施。记录验证措施数据，包括通过/失败状态和相应的验证措施数据。

注 3: 开始系统集成的先决条件的例子可以是成功的系统元素验证或预存在系统元素的鉴定。

注 4: 有关处理与预期结果不符的验证结果，请参阅 SUP.9。

洞察: 这条实践是“执行层面”的核心。它要求严格按照集成计划和验证措施进行操作。强调“根据规定”和“记录数据”，确保了集成过程的受控性和验证结果的完整性。同时，先决条件（如已完成单元验证）的存在，保障了集成是在一个稳定的基础上进行的，避免了“集成地狱”的发生。

SYS.4.BP4: 确保一致性并建立双向可追溯性

确保验证措施与系统架构之间的一致性，并建立双向可追溯性。建立验证结果与验证措施之间的双向可追溯性。

注 5: 双向可追溯性支持一致性，促进变更请求的影响分析，并证明验证覆盖率。仅可追溯性（例如，链接的存在）不一定意味着信息相互一致。

洞察: 这再次体现了 ASPICE 的核心原则之一——“可追溯性”。它不仅要求验证措施能够追溯到所验证的架构元素，还要求验证结果能追溯到具体的验证措施。这种精细化的追溯链条是变更影响分析、缺陷根因分析和证明验证充分性的关键，确保了验证活动的全面性和透明度。

SYS.4.BP5: 汇总并沟通结果

汇总系统集成和集成验证结果并传达给所有受影响方。

注 6: 在总结中提供测试用例执行的所有必要信息，使其他方能够判断后果。

洞察: 这条实践强调了“信息共享和决策支持”。集成和验证的结果不仅仅是测试团队的内部信息，而是需要被整理、汇总，并及时、清晰地传达给所有相关的利益相关者（如项目管理、软件团队、硬件团队、QA）。这确保了所有人都基于最新的测试状态做出决策，并能理解任何问题的潜在影响。

5. SYS.5 系统验证 (System Verification) 的基础实践

SYS.5.BP1：是编写系统验证的测试用例、测试方法（技术）、定义通过/失败标准、进入/退出准则以及测试平台/环境的准备。这是系统验证的计划和准备阶段。

SYS.5.BP2：是选择哪些系统测试用例需要执行，并对其进行优先级排序，特别是要考虑回归测试的需求和发布范围。

SYS.5.BP3：是执行系统测试，即运行选定的系统级测试用例，并详细记录测试结果。

SYS.5.BP1: 规定系统验证的验证措施

• 验证措施的技术。
  
• 验证措施的通过/失败标准。
  
• 验证措施的进入和退出标准的定义。
  
• 必要的验证措施序列。
  
• 所需的验证基础设施和环境设置。

注 1: 系统验证措施可能涵盖热、环境、鲁棒性/寿命和 EMC（电磁兼容性）等方面。

洞察: 这条实践聚焦于“如何证明系统符合所有需求”。它要求在进行系统级验证前，详细规划所有验证活动。不仅要考虑功能性，还要深入到非功能性需求（如性能、可靠性、EMC 等），并明确测试方法、通过准则、执行顺序和所需的测试环境。这是确保系统质量和符合性的基础，涵盖了系统级的所有验证维度。

SYS.5.BP2: 选择验证措施

文档化验证措施的选择，并考虑选择标准，包括回归验证的标准。验证措施的选择应根据发布范围具有足够的覆盖率。

注 2: 选择标准的例子可以是需求的优先级排序、回归验证的需求（例如，由于系统需求的变更），所交付产品发布（测试台架、测试轨道、公共道路等）的预期用途。

洞察: 本实践强调“基于策略的测试用例选择”。在实际执行验证时，并不是所有验证措施都会被执行。选择过程需依据需求优先级、变更影响（尤其是回归验证的需求，以防新修改引入旧问题）和产品发布的目的。这确保了验证工作的高效性和有效性，将资源集中在最关键的验证点上。

SYS.5.BP3: 执行集成系统的验证

使用所选的验证措施执行集成系统的验证。记录验证结果，包括通过/失败状态和相应的验证措施数据。

注 3: 有关处理与预期结果不符的验证结果，请参阅 SUP.9。

洞察: 这条实践是“系统级测试执行的核心”。它要求严格按照之前规划的验证措施执行测试，并详尽记录所有测试的实际结果、通过或失败状态，以及任何相关的数据。这是证明系统质量的直接证据，也是缺陷管理（参照 SUP.9）和后续改进的基础。

SYS.5.BP4: 确保一致性并建立双向可追溯性

确保验证措施与系统需求之间的一致性，并建立双向可追溯性。建立验证结果与验证措施之间的双向可追溯性。

注 4: 双向可追溯性支持一致性，促进变更请求的影响分析，并证明验证覆盖率。仅可追溯性（例如，链接的存在）不一定意味着信息相互一致。

洞察: 这是 ASPICE 流程的“黄金准则”。它在系统验证层面再次强调了可追溯性。确保每个验证措施都能追溯到其所验证的系统需求，并能反向追溯。同时，验证结果也要能追溯到具体的验证措施。这种完整、双向的追溯链条是验证有效性、覆盖率分析、变更影响评估以及最终产品合规性证明的关键。

SYS.5.BP5: 汇总并沟通结果

汇总系统验证结果并传达给所有受影响方。

注 5: 在总结中提供测试用例执行的所有必要信息，使其他方能够判断后果。

洞察: 这条实践强调**“信息透明与决策支持”**。系统验证的最终结果是项目状态和产品质量的关键指示器。及时、清晰地汇总这些结果（包括测试通过率、未决缺陷、风险等），并传达给所有利益相关者（如项目管理、开发团队、客户），确保所有人都基于统一的、最新的信息做出决策，并能理解验证结果可能带来的影响。

6. SYS.4与SYS.5的区别

SYS.4 和 SYS.5 虽然都属于验证活动，但它们在测试对象、测试目的和验证关注点上存在明确的区别，代表了 V 模型右侧的不同阶段：

测试对象与范围不同：

• SYS.4 (系统集成与集成验证)：其测试对象是已集成的系统元素或子系统。它关注的是元素与元素之间、子系统与子系统之间的接口、数据流、控制流以及它们协同工作时的行为。
  
• SYS.5 (系统验证)：其测试对象是完整、最终集成的整个系统。它关注的是作为整体的系统是否满足其所有的功能和非功能性系统需求。

测试目的和参照基准不同：

• SYS.4 的目的：验证各系统元素或子系统在集成后，它们之间的交互是否正确，是否符合系统架构设计中定义的接口、关系和动态行为。它确保了系统“搭建”的正确性。
  
• SYS.5 的目的：验证整个系统作为最终产品，是否完全满足所有系统需求。它确保了系统“做到了客户想要的功能”。

验证措施的关注点不同：

• SYS.4 的验证措施 (BP1)：更多地关注接口、数据交换、时序同步和系统元素间的动态交互。测试用例通常基于架构设计。
  

• SYS.5 的验证措施 (BP1)：更全面地涵盖了功能和非功能性需求，例如性能、可靠性、安全性、EMC、环境适应性等系统级特性。测试用例直接基于系统需求。

在开发流程中的位置（如下指的“执行”，因为用例编写会在系统设计阶段完成）：

• SYS.4 通常发生在单元测试之后，SYS.5 之前。它是构建完整系统的中间步骤。
  
• SYS.5 通常是产品发布前的最终验证活动，它确认了整个系统已为部署做好准备。
  
• SYS.4 确保了“部件能正确地组装在一起”，而 SYS.5 则确保了“组装好的整体符合客户的最终期望”。