中文翻译《ASPICE in practice》之“ENG.2系统需求分析实践”

2.4 ENG.2系统需求分析实践

2.4.1 目的

系统需求分析过程的目的是将定义的客户需求转化为一组期望的系统技术需求，以指导系统的设计。

系统需求分析是最重要的过程之一，因为它构成了整个开发工作的重要基础。 系统需求描述了对由不同硬件、机械和软件组件组成的整个系统以及这些组件之间的交互的需求。 糟糕的系统需求分析是开发项目中最大的失败因素之一。

ENG.2 采用 ENG.1 中确定的客户需求（= 客户需求规范级别），并将其转换为技术上更详细的需求（= 系统需求规范级别）。 除了客户要求外，还考虑参与开发的所有其他团体和个人的要求。 对于成功实施系统需求分析特别重要的是不同开发领域的交互。 例如硬件、机械、软件开发和测试部门。

2.4.2 汽车行业特有的特征

通常很难将各个系统组件的需求与客户需求文档分开，其中系统所需的功能通常是从最终客户的角度关注的焦点。 在系统需求分析中，现在的重点是供应商开发团队的技术观点。 在实践中（尽管 Automotive SPICE 中没有要求），各个组件的需求通常是分开的。 例如，这可以通过系统需求文档的相应结构或通过将它们分成不同的文档来完成。

附注：系统

大多数评估都以这样的问题开始：“我们如何定义（术语）系统？”如果没有明确回答这个问题，将会导致评估后期反复出现混乱和负面影响。 AUTOSIG（汽车特别兴趣小组）本身需要两天的时间来讨论并明确定义该术语。 我们需要一个精确的定义，因为后续步骤（例如 ENG.4 软件需求分析）建立在该系统定义之上。 因此，至少应该在硬件和软件之间做出明确的区分。

[IEEE 610] 将系统定义为“为完成特定功能或一组功能而组织的组件集合”。 [DIN EN 61508] 将系统定义为一组根据设计进行交互的元素，其中系统的元素可以是另一个系统，称为子系统，它可以是控制系统或受控系统，并且可以包括硬件 、软件和人机交互。 汽车行业的系统可以由不同的机械、硬件和软件组件组成。 除了其他之外，系统还可以有以下定义：

1. 车辆及其所有单独的组件，这些组件本身可以细分为更小的子系统。
2. 由机械装置（例如转向装置）、ECU 硬件和软件组成的装配部件或模块。 该定义与 AUTOSIG 提供的定义相对应。
3. ECU由机械结构（外壳）、硬件（印刷电路板、电子元件）和软件组成。 该定义仅涉及 ECU，因此构成上述定义的子类别。
4. 车辆功能分布在多个组件、模块或 ECU 上。 在这种情况下，系统考虑因素在评估过程中可能会变得像您希望的那样复杂。
5. 软件功能分布在多个控制单元上。

2.4.3 基本实践

BP1：确定系统需求。使用客户需求作为识别系统所需功能和能力的基础，并将系统需求记录在系统需求规范中。

注：系统需求包括：系统的功能和能力；业务、组织和用户需求； 安全、安保、人为因素、工程（人体工程学）、接口、操作和维护要求；设计约束和资格要求（ISO/IEC 12207）。

注：对于系统需求规范，可以使用 IEEE 标准 1233-1998，开发系统需求规范指南。

系统需求是根据 ENG.1 中的客户需求得出的。 通常会创建功能或特性列表，以构成后续系统需求规范的基础。 最初通常没有关于如何实现系统需求的规范。 根据上面的第一个注释，系统需求分析不仅包括功能需求，还包括对客户和最终客户重要的其他因素。 如果需求收集有工具支持并且可以相应地进行分析，那么系统需求分析就会更容易。 一般来说，这个方向有明显的趋势。 德国汽车制造商目前使用的标准工具是DOORS。

系统需求分析的结果是系统需求的基线（例如，作为系统需求规范的版本），该基线在项目的进一步过程中被更新和扩展。 “基线” 构成后续开发阶段商定的工作基础，并在项目中规定的里程碑或日期绘制。 系统需求基线应处于配置控制之下或至少进行版本控制。 就系统而言，应考虑以下要求：

1. 功能要求及特点
2. 接口、系统性能、时序行为、操作使用要求以及设计限制/约束
3. 非功能性需求； 这些与系统元件的技术功能没有直接关系。 例如，其中包括质量要求、可修改性、可测试性、可维护性和可靠性、文档、注释和验证（例如，来自编码指南）、商业约束（例如，客户的业务和组织要求）、 业务管理方面、市场需求、上市时间、重用、维护和持续的产品支持。
4. 技术限制
5. 需要考虑的标准（ISO、DIN 等），例如功能安全 [DIN EN 61508]、客户标准（例如技术指南）
6. 数据安全
7. 人体工学

在需求成为合同之前，可能必须分析其可行性（为此，请参阅 BP2）。

BP2：分析系统需求。从技术可行性、风险和可测试性方面分析已确定的系统需求。

注：分析结果可用于需求分类（另见 ENG.2.BP.4）。

对 BP1 中确定的系统需求进行可行性、风险和可测试性分析。 可追溯到客户规范（通常以客户需求规范的形式）的系统需求是技术可行性分析的核心。 参与开发的供应商技术部门评估项目的可行性，即从技术角度确定系统要求在多大程度上可行。 除其他外，有关可行性的考虑因素包括以下问题：

1. 系统要求和其他假设是否现实？
2. 是否有替代解决方案以及在什么前提下？
3. 有哪些技术风险？

根据可行性分析的结果，决定是否继续该项目（进一步评估参见 BP5）。 结果被记录下来。

风险分析（参见 MAN.5，或者，对于危害分析，参见 ENG.4 BP3 的附注）是一种用于预防损坏的工具，通常以风险研讨会的形式进行，在此过程中还考虑了其他方面 例如，软件需求带来的风险。 重点是技术风险，在小型项目中通常会同时识别其他（非技术）风险。 大型项目通常会举办多次风险研讨会，其结果需要由项目管理进行巩固。

关于可测试性，分析需要考虑需求是否真的可测试或者需要付出什么努力。 可测试性分析的主要基础是验证标准，该标准指定了需要满足哪些要求才能被认为已成功验证。 验证标准是在 BP2 范围内制定的。 该要求源自 ENG.2 流程结果的第三个注释 。

可测试性的评估确实需要首先掌握系统架构和其他系统特性，不能仅根据需求来完成。 分析的结果不仅获得了关于系统需求规范的有价值的指示，而且可能还获得了针对可测试性优化的系统设计的有价值的指示。 因此，此时评估可测试性非常有意义，因为可测试性决定了以后的测试工作以及系统可测试的程度。 测试工作取决于其他因素，例如质量要求和要使用的测试环境。 关于要求，测试工作受到以下因素的影响：

1. 导致冗余测试的冗余需求
2. 不明确的需求会妨碍测试用例的定义或使其无法实现
3. 没有可量化标准的不可测试的需求
4. 缺少需求，例如由于接口未解决

在可测试性评估中，根据可测试性来评估需求是有用的（例如，A = »可测试«，B = »在某些条件下可测试«，C =»不可测试« ）。 该评估可以在评审期间进行。 在评估过程中创建测试计划的第一个版本也是有意义的。

BP3：确定对运行环境的影响。确定系统需求和操作环境的其他组件之间的接口，以及需求将产生的影响。

系统需求分析还考虑了系统的直接运行环境和运行条件。 已确定的系统需求以及可行性、风险和可测试性分析的结果可能会对直接环境中的其他系统产生影响。 由于它们构成了系统的直接运行环境，因此需要予以考虑。 示例：ECU 可以在发动机启动前检查发动机防盗装置的状态。 一个有趣的问题，特别是对于高度网络化的控制单元，是系统在某些操作条件下将表现出什么样的行为，例如，在不可信的总线消息的情况下可能出现故障。 例如，可以在系统级别的风险分析（参见 BP2）期间或以“危险和可操作性研究”（HAZOP，参见 ENG.4 BP3 中的附注）的形式确定对操作环境的影响。 然后在进一步开发中考虑 HAZOP 结果。

需求也可能与系统的运行条件产生相互影响。 例如，气候条件、燃料质量、系统的安装位置等。

BP4：对系统需求进行优先级排序和分类。对已识别和分析的系统需求进行优先级排序和分类，并将其映射到系统的未来版本。

注意：请参阅流程 SPL.2 产品发布。

系统需求的优先级和分类构成了发布计划（2 级）的基础，其中需求被分配给单独的发布和交付。 需求优先级是调整工作范围和项目规划的基础。 当面临资源短缺时，低优先级的需求可能会被放弃或推迟到以后的版本。 例如，可以根据以下标准确定系统要求的优先级：

1. 快速原型制作
2. 快速实现基本功能
3. 按照与客户商定的按时交付以及按时 SOP
4. 在规定的日期提供与其他系统或组件的接口
5. 成本效益考虑
6. 客户愿望

分类主要应根据系统组件（软件、硬件、机械）或根据子项目或团队进行。

BP5：评估和更新系统需求。从成本、进度和技术影响方面评估系统需求和客户需求基线的变更。 批准系统需求及其所有更改并更新系统需求规范。

BP2 中已经要求对系统需求（可行性、风险和可测试性）进行技术可行性评估。 BP5 还需要探索技术影响。 例如，如果正在开发安全相关系统，则必须详细考虑其对功能安全的影响的要求。

其他供应商部门，例如控制、管理或销售部门，也对系统要求进行评估。 例如，在项目的早期阶段，他们可以使用项目经理（参见 MAN.3）基于系统需求的成本估算来评估项目在经济上是否可行。 结合 BP2 的评估，可以决定是否继续该项目； 例如，是否发出报价，如果发出，价格是多少。

如果在项目过程中提出了系统需求的变更或新的系统需求，则必须制定受控工作流程来调节系统需求规范中各个点的分析、批准、拒绝和更新（类似于所描述的内容） 在 ENG.1 BP5)。

通常，一开始，项目经理负责任何所需的批准，而随后的变更则由指导委员会或变更请求委员会（CRB，请参阅 SUP.10 BP6）批准。

BP6：确保客户需求与系统需求的一致性和双向可追溯性。确保客户需求与系统需求（包括验证标准）的一致性。 通过建立和维护客户需求和系统需求（包括验证标准）之间的双向可追溯性来支持一致性。

ENG.1 中确定的客户需求是系统需求分析的基础。 在这种情况下，一致性意味着客户需求和系统需求是一致的。 为了判断一致性，我们必须知道哪个系统需求与哪个客户需求在内容上相关，反之亦然（=双向可追溯性）。 然而，在大多数情况下，仅部分系统需求存在可追溯性，因为许多系统需求基于其他来源（例如，源自产品策略和产品架构或平台策略的内部需求）。 由于这些来源也可能被视为来自客户来源，因此也必须在此处建立可追溯性。

对可追溯性的要求还扩展到系统要求中包含的验证标准。 最好通过审核来检查与客户要求的一致性。

BP7：沟通系统需求。建立沟通机制，向所有相关方传播系统需求和更新需求。

所需的机制必须确保将需求和变更相关信息自动提供给所有需要其工作的项目成员。 首先，必须确定真正需要此信息的人。 在这里，制定沟通计划（见图 3-5）也被证明是有用的，它说明了一般情况下以及在发生变化时需要通知哪些角色。还必须指定负责实际传达的信息的角色。 该要求以类似的形式包含在 ENG.2–ENG.4 流程中。

经常实现这种通信的方法是将需求文档和变更注释存储在文件或配置管理系统中的唯一位置，并且所有相关方都可以访问。 建立适当的基础设施来发布系统要求等信息也很重要。 为此，人们还可以使用集成在各自公司内部网中的带有 HTML GUI 的数据库解决方案。 项目会议中讨论的变更还可以通过电子邮件分发（例如，通过会议纪要）。

评估员注意事项

这些机制有效的证据在于相关工具和系统的证明或使用合适的分发列表的通信。

2.4.4 指定工作产品

13-22 追溯记录

该记录用于通过各个开发阶段显示需求、设计元素和代码等之间的（双向）链接。 实践中通常使用映射表或追溯矩阵来显示这些连接（另请参见第 2.24 节）。

评估员注意事项

Automotive SPICE 描述了需求可追溯性及其在生命周期不同阶段的实现应该在两个方向（双向）建立，因此应该在生命周期模型的每个点和两个方向上都是可能的。 在评估中，各个工作产品及其与先前和后续工作产品的链接在不同的开发阶段进行样本检查。

17-08接口要求

对接口的要求通常是指数据格式、时序、调用层次、中断等。内部接口和外部接口有区别。 内部接口描述了系统元素之间的交互。 外部接口存在于操作环境中的其他系统和用户之间。

17-12 系统需求

系统需求是从客户需求文档（例如，客户需求规范）收集或导出的，并写在系统需求文档（例如，系统需求规范）中。 系统需求描述了系统的功能和能力。 例如，需求类别包括功能、组织方面的需求、安全方面、人体工程学、界面、操作和维护需求以及设计约束。 此外，系统需求文档提供了整个系统及其组件关系的概述，特别是那些系统元素与软件的关系。

例如，IEEE 830-1998（软件需求规范的推荐实践）中提供了此类文档的设计建议和质量标准，它也可以应用于系统需求（[IEEE 830]，另请参见图 2-4 ）。

       

2.4.5 Level 2 的特点

论绩效管理

对源自客户需求的系统需求的分析必须以系统的方式进行，并且需要适当的规划。 例如，流程规划包括需求基线和需求审查的安排。 在大多数情况下，客户需求更改后系统需求的更新是异步的。 商定的变更需要在进度和资源规划中考虑。

工作产品管理

过程属性 PA 2.2 的要求特别适用于系统需求文档（例如，系统需求规范）。 例如，这包括系统需求需要接受审查并应由客户接受或确认。 基线包含当时有效的客户和供应商需求文档的版本。