Aspice介绍——SWE.1软件需求分析

本文主要是介绍Aspice介绍——SWE.1软件需求分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

---

一、Process purpose（过程目的）

软件需求分析过程的目的是：将系统需求中与软件相关的部分转化为一组软件需求，指导开发及测试。

二、Process outcomes（过程成果）

作为这个过程的成功实施的结果如下：
1）将软件需求分配到系统软件组件中并且定义它们的接口；
2）将软件需求进行分类并分析它们的正确性和可验证性；
3）分析软件需求对运行环境的影响；
4）定义软件需求执行的优先顺序；
5）根据需要更新软件需求；
6）建立系统需求和软件需求之间的一致性和双向可追溯性；建立系统架构设计和系统软件需求之间的一致性和双向可追溯性；
7）对软件需求要进行成本、进度、技术和影响的评估；
8）软件需求传达给所有受影响的各方确认。

三、Base practices（基本实践）

Base Practices (BP)，面向活动的指标。
Work Products (WP)，面向结果的指标

SWE.1.BP1：详述软件需求

根据系统需求、系统架构以及它们的变更来识别软件的功能要求和性能要求。在软件需求规格说明书中详述功能和非功能性软件需求。 [OUTCOME 1, 5, 7]

注1：影响功能和性能的应用程序参数是系统（软件）需求的一部分。
注2：在只有软件开发的情况下，系统的需求和系统架构指的是一个特定操作环境（见注5）。在这种情况下，项目干系人的需求，应作为软件功能和性能的要求基础，同样应用程序参数也是。

SWE.1.BP2：软件需求结构化

将软件需求规格中的软件需求结构化:

1. 按照相关性进行条目分组，
2. 按照逻辑对条目进行排序，
3. 按照条目相关标准进行分类，
4. 根据项目干系人的要求定义优先级。

注3：优先级确定通常根据发布计划分配软件内容。参见 SPL.2.BP1。

SWE.1.BP3：分析软件需求

分析特定软件需求包括分析他们的相互依存关系，以确保正确性、技术可行性和可验证性，并支持风险识别。分析对成本、进度和技术的影响。[OUTCOME 2, 7]

注4：成本和进度的影响分析,是项目预算的调整的依据。参考MAN.3.BP5。

SWE.1.BP4 分析对操作环境的影响

分析软件需求对系统组件的接口和操作环境的影响。[OUTCOME 3，7 ]

注5：操作环境被定义为软件执行的系统（例如硬件、操作系统等）。

SWE.1.BP5 开发验证准则

制定每个软件需求的验证标准，从定性和定量的角度来验证需求。[OUTCOME 2，7 ]

注6：验证标准表明，一个需求可以被约定的限制条件验证，通常作为软件测试用例或其他验证措施的输入量，以证明开发是符合软件需求的。
注7：验证不能被测试覆盖见SUP.2。

SWE.1.BP6 建立双向可追溯性

建立系统需求和软件需求之间的双向可追溯性。建立系统架构和软件需求之间的双向可追溯性。[OUTCOME 6 ]

注8：双向可追溯性支持覆盖，一致性和影响分析。

SWE.1.BP7 确保一致性

确保系统需求和软件需求的一致性。确保系统架构和软件需求的一致性。[OUTCOME 6 ]

注9：双向可追溯性支持一致性，并可以通过审查记录证明。
注10：在只有软件开发的情况下，系统的需求和系统架构是指一个给定的操作环境（见注2）。在这种情况下，要确保项目干系人的需求和软件需求之间的一致性和双向可追溯性。

SWE.1.BP8 交流已定软件需求

沟通确认的软件需求和软件需求更新，并将其传达给所有相关方。[OUTCOME 8 ]

四、Output work products（输出工作产品）

13-04 沟通记录→[ OUTCOME 8 ]
13-19 评审记录→[ OUTCOME 6 ]
13-21 变更控制记录→[ OUTCOME 5，7 ]
13-22 追溯记录→[ OUTCOME 1，6 ]
15-01 分析报告→[ OUTCOME 2，3，4，7 ]
17-08 接口规范→[OUTCOME 1、3 ]
17-11 软件需求规格说明的→[ OUTCOME 1 ]
17-50 验证标准→ [ OUTCOME 2 ]

这篇关于Aspice介绍——SWE.1软件需求分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---