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

1. System Engineering Process Group (SYS)

系统工程过程组（SYS）是 ASPICE 中“主要生命周期过程”的核心组成部分，它涵盖了从理解客户需求到系统集成验证的整个系统开发 V 模型左侧及部分右侧的关键活动。它旨在确保系统需求被正确识别、分析、分配、设计，并最终集成和验证，以满足所有利益相关者的期望。

SYS是所有工程活动的基础。它位于 V 模型的最顶端，负责定义整个系统的蓝图和行为。它是连接客户需求与具体实现（如软件、硬件开发）的桥梁，也是确保最终产品符合初衷的保障。

如下图所示：

SYS主要包含如下5部分内容：

1.1 SYS.1 需求获取 (Requirements Elicitation)

关注理解并记录客户和利益相关者的需求，确保需求的完整性和正确性。

1.1.1 目的

从所有相关利益方处获取、识别并记录产品或服务的需求，并确保对这些需求达成共识和承诺 。

1.1.2 过程结果

• 与所有利益相关者之间需要建立并维护一种持续的、不间断的沟通机制。
• 不仅要理解利益相关者的期望，更要将其转化为明确的需求，并获得所有相关方的认可和同意
• 对需求变更的严格管理，即任何源自利益相关者的新需求或修改，都必须经过分析，评估其潜在风险和对项目的影响，以便进行有效管理
• 确保所有受需求变更或状态更新影响的各方都能及时、准确地了解到最新需求状态

1.2 SYS.2 系统需求分析 (System Requirements Analysis)

将利益相关者需求转化为可管理、可验证的系统需求。

1.2.1 目的

分析客户需求并将其转化为系统需求，对这些需求进行管理 。

1.2.2 过程结果

• 对系统需要实现的功能和非功能特性进行了明确的、详细的描述和定义。
• 系统需求被组织成清晰的结构（例如，分组、层次化），并且根据重要性或紧急程度进行了排序，以便在开发过程中进行决策。
• 对系统需求进行了深入审查，以确保它们没有错误、没有矛盾，并且在当前的技术和资源条件下是可实现的。
• 在定义系统需求时，需要考虑这些需求将如何影响系统部署和运行的环境，例如对性能、资源、安全等方面的影响。
• 确保系统需求与客户或利益相关者的原始需求保持一致，并且能够从系统需求追溯到利益相关者需求，反之亦然。
• 系统需求在最终确定前需要获得所有相关方的批准和共识，并且这些确定的需求必须及时有效地通知所有受影响的团队或个人。

1.3 SYS.3 系统架构设计 (System Architectural Design)

基于系统需求，创建系统的逻辑和物理架构。

1.3.1 目的

建立系统架构，并将其分配给硬件、软件或人工元素，从而满足系统需求 。

1.3.2 过程结果

• 在系统设计阶段，不仅要勾勒出系统的整体框架，还需要明确构成系统的各个独立部分（元素），以及这些元素各自的功能、它们之间如何连接、相互作用以及如何进行通信。
• 对设计好的系统架构进行审查和评估，对照预设的、明确的标准（如性能、安全性、可靠性、可维护性等）来检查其是否满足要求，并识别出架构中可能具有特殊意义或需要特别关注的属性。
• 确保系统架构的设计与系统需求完全吻合，没有矛盾之处。同时，能够从架构的任何部分追溯到其所实现的需求，也能从任何需求追溯到其在架构中的实现方式，反之亦然。
• 在系统架构确定并获得相关方认可后，必须及时、清晰地将这份架构设计以及其中识别出的所有特殊属性，告知所有会受到其影响的团队或个人，确保信息同步。

1.4 SYS.4 系统集成与集成验证 (System Integration and Integration Verification)

将系统元素逐步集成，并对集成后的系统进行验证。

1.4.1 目的

将系统元素集成并验证其与系统架构和系统集成策略的一致性 。

1.4.2 过程结果

• 在系统元素集成前，需要明确定义如何验证这些集成后的系统元素。验证的范围不仅包括整体功能，还特别强调对元素间接口和交互的验证。
• 各个独立的系统部件已按照计划逐步合并，最终形成一个完整的、可发布的产品或系统版本。
• 在执行验证时，需要根据本次发布的具体范围，选择合适的验证方法和测试用例，并且要特别考虑进行回归验证（即确保新的集成没有破坏已有的功能）。
• 按照既定的验证计划执行测试，并详细记录所有测试的输出和结果，以便后续分析和追溯。
• 所有的验证活动都能追溯到它们所验证的特定系统架构元素（如模块、接口），反之亦然，从而保证验证的完整性，并检查验证是否符合架构设计。
• 能够从任何验证结果追溯到是哪种验证措施（测试用例、方法）产生了它，反之亦然。这对于理解测试失败的原因和评估验证的有效性至关重要。
• 系统集成和验证活动完成后，需要对所有的结果进行整理和总结，并及时将这些信息（包括成功、失败、缺陷等）通知所有相关的团队和利益相关者。

1.5 SYS.5 系统验证 (System Verification)

验证完整的系统是否满足其需求。

1.5.1 目的

验证已集成的系统是否符合系统需求 。

1.5.2 过程结果

• 在验证整个系统之前，需要明确定义将采取哪些方法、步骤和测试用例来确保系统符合其既定的所有需求。
• 在执行验证时，选择的测试方法和范围需要与当前即将发布的版本所涵盖的功能和修改相匹配，并确保考虑进行回归验证，以避免引入新的缺陷或破坏现有功能。
• 严格按照之前定义的验证计划执行测试，并详细记录所有测试的输出、通过或失败状态，以便后续分析和追溯。
• 确保每个验证活动或测试用例都能追溯到它所验证的特定系统需求，反之亦然。这保证了所有需求都得到了充分的验证覆盖。
• 能够从任何验证结果追溯到是哪种具体的验证措施（例如，哪个测试用例）产生了它，反之亦然。这对于理解测试失败的原因、验证活动的完整性以及审计非常重要。
• 在系统验证活动完成后，需要对所有测试结果进行整理、总结，并及时将这些关键信息（包括测试通过情况、发现的缺陷、验证覆盖率等）清晰地通知所有相关的团队和利益相关者。

2. SYS的核心价值

• 质量提升：通过系统的需求管理和验证，从源头确保产品质量，减少后期缺陷和返工。
• 风险降低：早期识别和解决需求不明确、设计缺陷等问题，避免风险累积，降低项目失败率。
• 效率优化：清晰的流程指导和可追溯性，减少沟通成本，提高开发效率。
• 可预测性增强：标准化的实践和明确的输出，使得项目进度和质量更具可预测性。
• 符合行业标准与法规：满足汽车行业对功能安全（ISO 26262）和网络安全（ISO/SAE 21434）等高标准的要求。

3. SYS与其它流程组的衔接

SYS 流程组并非孤立存在，它与 ASPICE 中的其他流程组紧密衔接，共同构成了完整的开发体系。

3.1 与采购（ACQ）和供应（SPL）流程组的衔接

• SYS 流程的输入（如利益相关者需求）可能来源于 ACQ.3 合同协议或 ACQ.4 供应商监控。
• SYS 流程的需求可能分配给外部供应商（例如，外包的硬件或软件），此时需要与 SPL.2 产品发布流程紧密配合，确保供应商的交付物符合系统需求。

3.2 与软件工程（SWE）和硬件工程（HWE）流程组的衔接

• SYS.3 系统架构设计将系统需求分配到软件元素（触发 SWE.1 软件需求分析）和硬件元素（触发 HWE.1 硬件需求分析）。
• SYS.4 系统集成和集成验证、SYS.5 系统验证依赖于 SWE 和 HWE 流程组的输出（如已验证的软件组件和硬件组件）作为集成和验证的输入。

这种衔接体现了 ASPICE 的“插件”概念，即系统级流程是基础，而软件和硬件等领域特定流程可以根据产品类型“插入”到评估范围中 。

3.3 与支持（SUP）流程组的衔接：

• 质量保证 (SUP.1)：对 SYS 过程及其工作产品进行独立审计，确保符合标准。
• 配置管理 (SUP.8)：管理所有 SYS 相关的基线（如需求基线、架构基线），确保其完整性和可追溯性。
• 问题解决管理 (SUP.9)：SYS 过程中发现的任何问题或缺陷都需要通过 SUP.9 进行管理和解决。
• 变更请求管理 (SUP.10)：所有对系统需求或架构的变更都需要通过 SUP.10 进行受控管理。

3.4 与管理（MAN）流程组的衔接

• 项目管理 (MAN.3)：负责 SYS 流程的规划、执行、监控和控制，确保资源、进度和质量目标达成。
• 风险管理 (MAN.5)：SYS 过程中识别出的技术风险、项目风险等都需通过 MAN.5 进行分析和应对。
• 度量 (MAN.6)：收集和分析 SYS 过程及工作产品的度量数据，以支持过程改进和项目决策。

3.5 与验证 (VAL.1) 流程组的衔接

• SYS.5 系统验证侧重于系统是否满足其定义的需求。而 VAL.1 验证则侧重于产品是否满足其预期用途或利益相关者的真实需求。两者虽有区别，但SYS.5的输出是VAL.1的重要输入和基础。

4. 实施SYS的基础

个人认为ASPICE是以系统思维为基础思想，以流程思维组织内容，从流程的本质出发去做的总结，比如输入、输出、决策、活动、逻辑关系、客户、供应商、价值，以及围绕着PDCA(Plan, Do, Check, Action)这个闭环而设计的。

成功实施 SYS 流程组，并非简单地引入文档模板或工具，而是需要企业在以下几个方面具备相应的能力和现状基础：

a.高层管理承诺与支持：实施 ASPICE 是一个变革过程，需要高层领导的坚定支持，提供必要的资源（时间、预算、人员）并树立正确的质量导向。

b.清晰的组织架构与职责：需要明确定义系统工程师、需求分析师、架构师、测试工程师等角色的职责、权限和相互关系，避免职责重叠或真空。

c.现有开发流程的成熟度：

1. 需求管理基础：企业应具备一定的需求管理经验，至少能有效收集、记录和沟通需求。如果现有需求管理混乱，将难以进行系统级的需求分析和分配。
2. 设计和测试基础：应有基本的系统设计和测试方法，哪怕是非正式的。对 V 模型开发模式有基本认知。
3. 变更控制意识：对变更的管理应有初步的意识，理解变更可能带来的影响。

d.具备或可引入合适工具：

1. 需求管理工具 ：支持需求的捕获、管理、追溯、版本控制和基线化。
2. 建模工具：支持系统架构设计，如 SysML 工具。
3. 配置管理工具：用于所有工作产品的版本控制和基线管理。
4. 缺陷管理工具：用于跟踪和管理测试及验证过程中发现的问题。

e.员工能力与培训：

1. 系统思维能力：工程师需要具备从整体角度看待问题、理解系统复杂性和跨领域协调的能力。
2. ASPICE 知识：所有相关人员，特别是系统工程团队，需要接受 ASPICE 培训，理解其目的、流程和期望。
3. 工具使用技能：员工需要熟练使用上述各类工具。

f.文化准备：

1. 质量意识：全员应具备高度的质量意识和对过程遵循的认同。
2. 协作文化：SYS 流程组强调跨部门、跨领域的协作（如与软件、硬件团队），需要打破部门壁垒，建立协作共享的文化。
3. 持续改进心态：认识到过程改进是一个长期过程，鼓励从失败中学习，并不断优化。

5. 对SYS的总结

• 需求驱动: 系统开发的核心起点和全程导向，确保所有设计与实现都紧密围绕客户及利益相关者的根本需求展开。

• 系统化: 通过结构化的V模型方法和明确的流程步骤，将复杂的开发过程分解并有序组织，确保全面性和可控性。

• 可追溯: 建立从客户期望到最终实现所有工作产品之间的双向链接，保证变更影响清晰、来源明确，增强透明度。

• 可验证: 通过系统的集成与验证活动，确保系统及其各部分符合既定的需求与设计，降低缺陷风险，保障质量。

• 集成: 强调系统元素之间以及系统与外部接口之间的顺畅连接与协同工作，确保各部分有机结合形成完整系统。

• 共识: 促使所有关键利益相关者对需求、架构和方案达成一致理解和承诺，减少误解与冲突，保障项目顺利进行。