中文翻译《ASPICE in practice》之“ENG.4 软件需求分析”

2.6 ENG.4 软件需求分析

2.6.1 目的

软件需求分析过程的目的是确定系统的软件需求。

在 ENG.3 中，确定了硬件和软件系统元素。现在，从此过程开始直到 ENG.8，只考虑构成系统软件项目的软件部分。软件需求分析是 ENG.3 系统架构设计和 ENG.5 软件设计之间的中间步骤。在 ENG.4 中，确定了软件项目的需求。软件需求分为功能性需求和非功能性需求。

2.6.2 汽车行业特有的特征

实际上，ENG.2 到 ENG.5 流程之间的过渡大多模糊，本质上是迭代和递归的。代码不仅必须满足功能需求，还必须满足软件需求分析范围内确定的其他非功能需求。除了符合编码指南（如 MISRA 规则 [MISRA]）的要求外，还为源代码指定了对软件质量产生积极影响的其他质量要求（例如指标）。例如可分析性、可修改性、稳定性和可测试性。

近年来，越来越多的形式化方法被应用于软件需求分析。例如，不仅对系统而且对软件的需求识别的形式化可以通过创建用例图来实现。用例图是使用 UML 作为描述语言的功能的图形和文本表示。这种形式化程序的优点表现在：无歧义性、更好的理解性、有效的内容传达、独立于实现、可追溯性、可重用性、缺陷检测和正确性证明。

2.6.3 基本实践

BP1：识别软件需求。使用系统需求和系统架构设计作为识别软件功能性和非功能性需求的基础，并在软件需求规范中记录软件需求。

注意：在仅进行软件开发的情况下，系统需求和系统架构设计是指给定的操作环境（另请参阅 BP3 中的注释）。在这种情况下，应使用客户需求作为识别软件所需功能和能力的基础。

识别软件的功能性和非功能性需求并将其分配给单个软件项目。功能性和非功能性软件需求在某种程度上可以直接从系统需求规范中接管，其他需求则需要进行转换。Automotive SPICE 明确要求创建软件需求规范。

评估员注意

很少有项目会建立单独的软件需求规范。大多数项目都在一个文档中描述所有相关需求（功能性和非功能性系统和软件需求）。原因是，尽管系统功能主要由软件决定，但试图将其与硬件功能分开是没有意义的。在这种情况下，对这一基本实践的评级应取决于项目的背景和规模。为了完全实现，应提供证据，证明功能性和非功能性软件需求已明确指定，并且它们充分涵盖了功能范围。换句话说，系统级别和软件级别的各个方面都必须是可见的，无论它们是保存在一个文档中还是保存在多个单独的文档中。

BP2：分析软件需求。从技术可行性、风险和可测试性的角度分析已识别的软件需求。

注：应定义所有软件需求的验证标准，以便进一步开发软件测试用例。

注：分析结果可用于对需求进行分类。

ENG.2 BP2 中给出的考虑也适用于软件需求分析。软件特定的风险包括：

1. 使用未经充分测试的技术解决方案或工具，例如用于自动代码生成
2. 指定的开发工具链或测试套件不完整
3. 由于代码是自动生成的，因此无法满足非功能性软件需求（例如，自动生成的代码不适合 EEPROM）。
4. 如果是自动生成的代码，则测试工作量增加

这里，Automotive SPICE 说明也要求开发验证标准作为此基本实践的一部分。

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

注意：操作环境定义为软件在其中工作的系统（例如硬件、操作系统等）。

我们在 ENG.2 BP3 中的讨论也适用于此基本实践，但仅限于软件的直接操作环境，即软件在其上运行的系统组件。软件需求会影响其他软件部分（例如操作系统）或直接环境中的硬件（例如控制器、内存）。人们可能会问的一个重要问题是软件在某些操作条件下可能导致哪种故障。为了找出答案，人们可以以“危险和可操作性研究”（HAZOP）的形式进行情况分析（参见后续附注），然后在后续开发中考虑其结果。

附记：示例方法 危险和可操作性研究 (HAZOP)

HAZOP 是化学工业在 70 年代开发出来的，并在 90 年代扩展到软件开发。

该方法的目的是通过定性分析（在虚拟环境中）分析软件功能在不同操作条件下的行为，并检测与目标状态的偏差。此外，它还有助于检测和避免可能因意外事件而发生的危险和严重故障。基于 HAZOP 研究，软件需求或架构可能会被接受或拒绝，在后一种情况下，会导致设计修订。

HAZOP 研究由团队进行。软件功能具有与之相关的所谓指导词。例如，软件功能“发送消息”与以下指导词相关联：太频繁、太早、太晚、太少等等。结果收集在表格中（图 2-7）。指导词描述了与正常预期属性的假设偏差。根据这些指导词，将故障原因及其影响列为偏差；然后讨论这些偏差并提出措施以尽量减少故障原因发生的概率或其影响。

图 2-7 HAZOP 表示例

BP4：确定软件需求的优先级并对其进行分类。确定已识别和分析的软件需求的优先级并对其进行分类，并将其映射到未来版本。

注意：另请参阅 SPL.3—产品发布流程。

我们在 ENG.2 BP4 中的审议也适用于这一基本实践。现在，从发布计划中应该可以明显看出何时或在哪个版本中实施软件需求。此时，软件架构问题已包含在发布计划中，因为除了功能优先级之外，还存在技术上合理的需求实施顺序。与系统或硬件相关层相关的需求通常会更早实施，因为它们构成了其他功能的基础。分类主要基于划分为软件架构组件或软件子项目。

BP5：评估和更新软件需求。从成本、进度和技术影响的角度评估软件需求以及系统需求和/或系统架构设计的变更。批准软件需求并更新软件需求规范。

我们在 ENG.2 BP5 中的讨论也适用于这一基本实践，此外，系统架构的修改也可能需要评估甚至修改软件需求。

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

注：在仅软件开发的情况下，系统需求和系统架构设计是指给定的操作环境（另请参阅 BP3 中的注）。在这种情况下，一致性和双向可追溯性将是客户需求与软件需求之间的一致性和双向可追溯性。

我们在 ENG.2 BP6 和 ENG.3 BP5 中所示的审议也适用于此基本实践。在这里，也可以添加不是来自系统需求而是来自其他来源的软件需求（例如，来自产品政策、软件架构或软件平台策略的内部需求）。建议也建立对这些来源的可追溯性。

BP7：确保系统架构设计与软件需求的一致性和双向可追溯性。确保系统架构设计（包括验证标准）与软件需求（包括验证标准）的一致性。通过在系统架构设计（包括验证标准）和软件需求（包括验证标准）之间建立和维护双向可追溯性来支持一致性。

注：如果仅涉及软件开发，请参阅 BP 6 中的注。

与 BP6 类似，必须在系统架构和软件需求之间建立一致性和可追溯性。关于可追溯性，必须明确哪个软件需求与哪个系统架构组件相关联，反之亦然。如果系统架构仅包含一个软件组件，则这一点并不难，但如果它包含多个软件组件，则必须以显示对每个组件的明确分配的方式构建软件需求。

BP8：传达软件需求。建立沟通机制，向所有相关方传播软件需求和需求更新。

ENG.2 BP7 中所示的我们的审议同样适用于这一基本实践。

2.6.4 指定工作产品

13-22 可追溯性记录

参见 ENG.2

17-11 软件需求

软件需求是软件创建的规范，对软件的质量和可用性有重大影响。其中包括：客户要求、系统要求、系统架构、要遵守的标准、限制/约束、软件项之间的关系、性能特性、所需的软件接口、安全特性、发生故障时的行为以及故障后的恢复（参见图 2-4，了解根据 IEEE 标准 830 的需求文档结构）。

2.6.5  2 级的特征

ENG.2 中相应部分给出的陈述也适用于此。