中文翻译《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 中的注释）。在这种情况下，应使用客户需求作为识别软件所需功能和能力的基础。

识别软件的功能性和非功能性需求并将其分配给单个软件项目。功能性和非功能性软件需求在某种程度上可以直接从系统需求规范中