ASPICE学习笔记 SWE.1 软件需求分析

ASPICE软件需求分析实践指南

原创已于 2025-02-28 15:06:08 修改 · 1.1k 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#嵌入式 #单片机 #汽车

于 2025-02-13 19:31:56 首次发布

SWE.1 软件需求分析

在这里插入图片描述

概述

过程 ID

SWE.1

过程名称

软件需求分析

过程目的

其目的是：建立一组已结构化和已分析的软件需求，与系统需求和系统架构相一致。

3.8.1.1 迭代与增量开发

通常情况下，产品的功能内容会在迭代中发生变化，并在各个版本中逐步演进。“增量” 可以理解为添加之前不存在的功能或元素（例如：建造房屋）。“迭代” 则可以理解为对现有功能或元素进行完善或调整（例如：雕塑家创作雕塑）。

因此，最终产品的完整需求集并非必须在项目开始时就全部确定。相反，与客户商定的发布范围将定义增量内容和迭代返工计划。在这方面，需求的创建可以由随时间推移的发布定义来驱动。

3.8.1.2 对运行环境的影响

SWE.1.BP1仅规定了所考虑软件自身的需求，即软件应实现的需求。相比之下，BP4要求阐述由于这些需求，系统对其运行环境所产生的影响和后果。这里的运行环境指的是SWE.1中所考虑软件边界之外的一切事物。运行环境中的元素包括：

人类用户：例如在信息娱乐系统中；
软件运行的目标设备；
因设计不佳或过度设计的人机界面（HMI）而导致的压力、分心、不适或疲劳。

这种对运行环境的影响需要反馈给相关方，以便做出相应更改。否则，这些影响可能会被用于对所考虑软件的需求进行迭代。

过程成果

定义了软件需求。
结构化了软件需求并进行优先级排序。
分析了软件需求的正确性和技术可行性。
分析了软件需求对运行环境的影响。
建立了软件需求与系统需求之间的一致性和双向可追溯性。
建立了软件需求与系统架构之间的一致性和双向可追溯性。
约定了软件需求，并与所有受影响方沟通。

基本实践

1. SWE.1.BP1: 定义软件需求

使用系统需求和系统架构来识别和文档化软件的功能性和非功能性需求。

注1: 需求特性在一些标准中有定义，诸如 ISO IEEE 29148、ISO/IEC IEEE 24765、ISO 26262-8:2018 或 INCOSE 需求编写指南等。

注2: 上述标准共有的关于已定义的需求特性的示例如，可验证的（即：需求文本中固有的验证准则）、无歧义的/可理解的，无设计和实现限制的，以及不与任何其他需求相矛盾的。

注3: 如果只有软件开发，系统需求和系统架构是指给定的运行环境。在这种情况下，可将利益相关方需求作为识别软件所需功能和能力的基础。

注4: 软硬件接口（HSI）定义将硬件置于上下文中，因此它是系统设计级别的接口决策。如果存在这类 HSI，可为软件需求提供输入。

功能是由机械、硬件、软件或三者组合实现的。软件需求来源于系统需求中由软件实现的部分。对于纯软件开发，软件需求直接来源于相关方需求。
在软件需求分析过程中，需要识别软件相关的功能性和非功能性需求，并分配到对应软件。一些软件需求可以从系统需求中直接获取，有些需要进行转化。ASPICE明确要求创建软件需求规范。
同系统需求类似，软件需求必须具有颗粒度和可理解。不清楚和一般性的需求必须和系统需求相关方确认。软件需求应当形成列表或数据库，并能够结构化。软件需求在SWE.6过程中验证。

推荐规则和建议

对于不清楚或不一致的需求，必须和系统需求相关方确认或澄清。
软件需求必须反映最新的更改。

软件需求属性

需求ID：每个需求应有唯一的标识符。
描述：需求的详细描述，以文本形式给出。
类型：需求可以是标题、信息性或功能性的。
类别：需求可以是功能性的或非功能性的，不适用的情况也需要标明。
状态：需求的状态可以是未适用、进行中、准备审核、已批准或已废弃。
安全级别：需求可能涉及的安全级别，如果不适用则标明不适用，否则指定相应的安全完整性等级（如QM, ASIL A, ASIL B等）。
验证标准：需求满足的验证标准，以文本形式给出。
版本发布：需求可能涉及的版本发布，如果不适用则标明不适用，否则列出相关的版本。
优先级：需求的优先级，如果不适用则标明不适用，否则列出优先级。
风险：需求相关的风险等级，如果不适用则标明不适用，否则列出风险等级。

评级规则(3.1):

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

序号	名称
1	如果没有证据表明不明确或不一致的要求没有与相应的系统需求所有者进行确认澄清，则应降低指标BP1。
2	如果软件需求规格说明书未反映最新变化，则指标BP1的评级不得高于L。
3	如果SYS.2的PA 1.1被降级，则SWE.1的BP1应与之评级一致
4	如果SYS.3的PA 1.1被降级，则SWE.1的BP1应与之评级一致。
5	如果软件需求规范（BP1）被降级，PA 1.1应下调，因为所有指标（BP2，BP3，BP4，BP5，BP6，BP7和BP8）都受到影响。

答疑:

问题	回答
软件需求的来源有哪些？	软件需求的来源只有系统需求与系统架构，其中最主要的是系统需求。所有与软件相关的系统需求与系统架构都要传递到软件需求。
来自客户平台的或者已经描述的非常精细的软件相关的需求，该如何处理？	先纳入到系统需求，再传递到软件需求。需要将软件需求的描述方式转化为系统需求的描述方式。
软件需求里是否需要体现外包产品部分？	供应商提供的软件基于我们给供应商的需求。需要管理好给供应商的需求，然后在软件架构里管理好相关的接口。
如何从系统层级的输入转化出软件需求？	对系统需求中与软件相关的内容，进一步拆解、提炼，并转化为软件需求的描述方式。系统需求与软件需求的区分：系统需求描述以自然语言，软件需求以ASW、BSW等为主语。

2. SWE.1.BP2: 需求的结构化

需求的结构化并进行优先级排序。

注5：结构化准则的示例如，分组（如按功能）或产品变体识别。

注6：可以根据项目或利益相关方需要（如发布范围的定义）进行优先级排序。参见SPL.2.BP1

通过以下列举的措施在软件需求规范中构建软件需求：
• 分组到项目相关集群，
• 按项目的逻辑顺序排序，
• 根据项目的相关标准进行分类
• 根据客户需求确定优先顺序

评级规则(3.1):

序号	名称
1	如果（需求）分类不符合上述规定，则指标 BP2 的评级不得高于 L。
2	如果功能与版本的映射不能反映客户和其他利益相关者的需求，则应降低BP2评级。
3	如果没有确定优先级的证据，但发布计划将功能映射到未来的版本，则不应降低BP2指标的级别。

答疑:

软件需求如何做结构化的？

1. 先按照接口需求、功能需求、功能安全需求、平台需求、软件约束、安全与加密需求进行分类，功能需求中再按照不同功能、适当的层级与颗粒度进行分组。一般来讲最小颗粒度的组中不超过10-15条需求。
1. 大众明确要求：需求每个层级的需求数量不能超过10

3. SWE.1.BP3: 分析软件需求

分析已定义的软件需求（包括它们的相互依赖关系），以确保正确性、技术可行性，并支持项目管理的项目估算。

注7：项目可行性参见 MAN.3.BP3，项目估算参见 MAN.3.BP5。

注8：技术可行性评估可基于平台或产品，或通过原型开发。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
● 分析软件需求是正确实施的基础。即使有时需求非常详细或它们的实现看起来非常简单，也必须对这些需求进行有根据的分析。
● 软件风险，例如：
• 使用未充分验证的技术方案或工具，如自动生成代码
• 指定的开发工具链或测试套件不完整
• 非功能性软件需求不能被满足，因为代码是自动生成的
• 自动生成代码的增加了测试工作

评级规则(3.1):

序号	名称
1	如果未从正确性、技术可行性和可验证性方面评估软件需求及其相互依赖关系，则指标 BP3 不得评为 F 级。
2	如果项目计划中对工作包的估计涵盖了对成本和进度的影响的分析，则不应将其用于贬低 BP3 指标。
3	如果 BP3 降级了，那么 MAN.3.BP5 也应相应的进行降级。
4	如果 BP3 降级了，那么 MAN5 也应进行相应的降级。

答疑:

问题	回答
软件需求分析的结果是什么？	软件需求分析的结果主要指的是软件需求规格说明书中的各属性列，可以对照Doors中的文档，逐项说明各属性内容及含义
每个功能在什么阶段实现是依据什么定义的？	结合产品发布计划和系统需求中的实现阶段来定义的
软件需求的优先级和发布阶段需要都进行标注吗？	优先级和发布阶段一一对应，保留一个就可以
测试方法是怎么设定的？	验证方法包括审查、分析、测试、仿真等，其中的测试方法，又分为基于需求的测试、故障注入测试、性能测试、外部接口测试等
非功能需求，是怎么传递到软件架构的？	非功能需求，需要先从系统需求落入软件需求，然后根据软件需求的分组体现到软件架构中

希望这能帮助您更好地理解软件需求分析的相关内容。

4. SWE.1.BP4: 分析对运行环境的影响

分析软件需求对运行环境中要素的影响。

评级规则(3.1):

序号	名称
1	如果对运行环境影响的分析没有考虑上述列表中的方面或与项目相关的其他方面，则应降低BP4的评级。
2	如果内存、处理器时间和/或外设资源储备不足，则应降低BP4的评级。

答疑:

对运行环境的影响是在什么时候进行评估？

软件需求分析报告中第5条评估了对运行环境的影响。

运行环境影响分析是从哪些方面进行分析？有影响的具体内容是什么？

对操作环境的影响分析包括对范围内软件的影响以及其他软件部件、其他系统或整车的影响，考虑以下可能方面：
- 接口
- 信号和信号质量
- 电压和电流
- 性能
- 接口响应时间（信号响应、采样时间、周期时间、总线lond、信号延迟、抖动）
- 微控制器响应时间（处理时间）
- 环境
- 温度
- 电磁兼容
- 资源
- 内存/只读存储器使用情况
- EEPROM/数据闪存使用情况

5. SWE.1.BP5: 确保一致性和建立双向可追溯性

确保软件需求与系统架构之间的一致性并建立双向可追溯性。
确保软件需求与系统需求之间的一致性并建立双向可追溯性。

注9: 冗余的可追溯性是非意图的。

注10: 可能存在软件需求无法追溯的非功能性系统需求，例如过程需求或与后续软件产品生命周期阶段相关的需求，如事件处理。这些需求仍然需要验证。

注11: 双向可追溯性支持一致性，并有助于变更请求的影响分析和验证覆盖率的证明。仅有追溯性本身（如存在两者之间的链接），并不一定意味着两者之间的信息是一致的。

注12: 在只有软件开发的情况下，系统需求和系统架构是指给定的运行环境。在这种情况下，可确保利益相关方需求与软件需求之间的一致性和双向可追溯性。

评级规则(3.1):

序号	名称
1	仅在软件开发的情况下，如果建立了从软件需求到利益相关者需求的可追溯性，则不得降低指标BP5。
2	如果SYS.2的PA 1.1被降级，则SWE.1的BP5应与之评级一致。
3	如果SYS.3的PA 1.1被降级，则SWE.1的BP5应与之评级一致。

答疑:

序号	问题	回答
1	能展示一下这条需求是从哪里导出的吗？	在Doors中的软件需求文档，展示软件需求的出项链接。软件需求的出向链接可能指向系统需求或系统架构，评估时一般会抽查几条软件需求的追溯链接，按照评估师的要求展示即可。
2	软件需求对系统需求、系统架构的追溯要求是如何定义的？都必须达到100%吗？	软件需求可以直接追溯到系统架构，对于软件部分的覆盖度必须为100%，系统架构进一步可以追溯到系统需求，系统架构对于系统需求的覆盖度也是100%。从而间接保证软件需求对于系统需求的追溯度为100%。
3	功能安全需求链接到？	功能安全需求链接到TSR。
4	如何确保追溯性满足要求？	1. 检查Doors中软件需求总条目与已经建立出向链接的软件需求条目是否相同来确认所有的软件需求都向上进行了追溯； 2. 检查软件需求对系统需求的覆盖度，软件需求对系统需求覆盖率=链接了软件需求且分配给软件的系统需求条目数/分配给软件的系统需求条目数*100% 3. 软件需求评审检查单中有对追溯性的检查项：软件需求和系统需求之间是否已经建立的双向链接？软件需求和系统架构之间是否已经建立的双向链接？
5	软件需求的出向链接是否可以区分链接到了系统需求还是系统架构？	出项链接可以通过Doors中的分析功能判断链接到系统需求还是系统架构。
6	怎么保证链接是正确的？如何确保一致性？	通过对软件需求的评审来确保一致性。软件需求评审检查单中包含评审项：系统需求和软件需求是否有一致性？评审时要对每一条软件需求与其链接的系统需求的内容进行比较，看二者描述是否具有一致性。

部分软件需求可能来自于其他方面，例如源自产品策略、软件体系结构或软件平台策略的内部需求。追溯性需要建立在这些来源。
软件需求必须清楚地与系统组件关联，尤其当存在多个软件组件时，软件需求必须结构化并明确分配到相应组件。
对于纯软件开发，软件需求直接参考相关方需求。同样地，对于一致性和双向可追溯性，建立于相关方需求和软件需求之间。

对于纯软件开发，软件需求和相关方需求建立双向可追溯性。
对于纯软件开发，软件需求和相关方需求建立一致性。

6. SWE.1.BP6: 沟通约定的软件需求和对运行环境的影响

与所有受影响方沟通约定的软件需求，以及对运行环境影响分析的结果。

所需的机制必须确保将需求和与变更相关的信息提供给所有需要的项目成员。首先，必须确定真正需要此信息的人。制定沟通计划是一个有效方法，它指出了一般情况下和在发生变更时应该告知哪些角色。还必须指定负责实际传达此信息的角色。
通常执行此通信的方法是，需求文档和变更说明存储在文件或配置管理系统中的唯一位置，并且所有相关方均可访问。建立适当的工具平台以发布信息也很重要。还可以将数据库解决方案与集成在各个公司内网的HTML GUI一起使用。项目会议中讨论的更改还可以通过电子邮件（例如，通过会议纪要）进行分发。