流程体系 - 需求和需求管理

1、综述

1.1 需求类型

  ISO/IEC/IEEE 29148:2018中需求类型属性重要示例

需求类型	描述
功能性	功能需求描述了系统、系统基本功能或要执行的任务。
性能	通常需求定义在某种条件下，一项功能或任务被执行的程度或完成的有多好。这些是系统性能的定量需求，可单独验证。请注意，单个功能、功能需求或任务可能存在多个性能需求。
	易用性/使用质量需求（用户性能和满意度方面）	为满足用户的要求提供系统的设计和评价基础。易用性/使用质量需求是与系统的整体需求规范联合制定并形成其一部分的。
接口	接口需求是对系统如何与外部系统（外部接口）进行交互，或者系统内的系统元素（包括人员元素）如何相互交互（内部接口）的定义。
设计约束	通过强加不可移动的边界和限制，来限制对解决方案的设计者的选择需求（例如，系统应包含旧系统遗留的或提供的系统元素，或者某些数据应保存到在线仓库中）。
过程需求	过程需求主要是利益相关方（通常是需方或用户）通过合同或工作说明书加上的需求。过程需求包括：遵守国家或地方法律，包括环境法律；行政要求；需方/供方关系需求；和具体的工作指令。公司政策或实践也可能对过程需求施加程序要求。系统或系统要素实现的过程需求（例如强制执行特定设计方法）通常在项目协议文档中记录（例如，合同，工作说明和质量计划书）。
非功能需求	非功能需求规定了系统所需的运行或存在的需求或系统性质。他们定义了一个系统是怎样的。此类需求的例子包括质量需求和人员因素需求。
	质量需求	非功能需求包括一些“能力”，包括例如可运输性、生存能力、灵活性、可移植性、可重用性、可靠性、维护性和信息安全性。宜在起草需求文档之前制定非功能性质量需求（例如“能力”）清单。这一清单宜适应待开发系统。同时，视情况宜将质量需求的测度包括在内。
	人员因素需求	从安全性、性能、有效性、效率、可靠性、维护性、健康、幸福感和满意度方面明确系统与人类用户（以及受使用影响的其他利益相关方）交互结果的特性。这些特性包括诸如易用性的测度（易用性的测度包括有效性、效率和满意度），人员可靠性，免受不利健康影响。

1.2 非功能需求

    本章节基于《GB/T 40473-2021 银行业应用系统 非功能需求》，该标准列举了如下几种非功能需求：

1. 功能适宜性。目的在于给出包括功能完整性、功能正确性和功能适合性的功能适宜性需求，这些需求从严谨的需求分类看，可以看作是功能需求，但在银行业应用系统的研发中，往往被视作非功能需求。
2. 性能效率。目的在于给出包括时间特性、资源利用和容量的性能效率需求。
3. 兼容性。目的在于给出包括共存性和互操作性的兼容性。
4. 易用性。目的在于给出包括可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性和易访问性的易用性。
5. 可靠性。目的在于给出包括成熟性、可用性、容错性和易恢复性的可靠性。
6. 安全性。目的在于给出包括保密性、完整性、抗抵赖性、可核查性和真实性的安全性。
7. 可维护性。目的在于给出包括模块性、可重用性、易分析性、易修改性和易测试性的可维护性。
8. 可移植性。目的在于给出包括适应性、易安装性和易替换性的可移植性。

2、需求挖掘

2.1 利益相关方需求

1. 定义的目的/目标
2. 包含来自（合同）评审的议题/需求
3. 识别任何：

- 时间进度/约束

- 所需的功能和功能特性

- 必要的性能考虑因素/约束

- 必要的内部/外部接口考虑因素/约束

- 所需的系统特性/约束

- 人机工程考虑因素/约束

- 安全（security）考虑因素/约束

- 环境考虑因素/约束

- 操作考虑因素/约束

- 维护考虑因素/约束

- 安装考虑因素/约束

- 支持考虑因素/约束

- 设计约束

- 安全（safety）/可靠性考虑因素/约束

- 质量要求/期望

2.2 基本实践

SYS.1.BP1:获得利益相关方需求和要求。通过直接征求客户意见并通过评审客户业务提案（相关部分）、目标运行和硬件环境以及其它影响客户需求的文档来获取并定义利益相关方的需求和要求。

注1：需求挖掘可能需要客户和供应商的参与。

注2：约定的利益相关方需求和对变更的评估可基于可行性研究和/或成本和时间分析。

注3：必须收集并记录保持每个客户需求可追溯性所需的信息。

SYS.1.BP2:理解利益相关方的期望。确保供应商和客户对每个需求有同样的理解。

注4：与客户一起评审需求和要求有助于更好的理解客户需要和期望。

SYS.1.BP3:达成需求共识。获得所有相关方关于需求的明确协议，以便于开展工作。

3、系统需求

1、系统需求由系统工程师编写，即熟悉产品功能、性能要求，系统经验丰富的人员； 

2、系统需求在系统需求阶段编写。项目启动，系统概念确定后，根据用户需求，系统定义和相关规范要求，开始编写系统需求； 

3、系统需求主要包含三部分内容：功能、性能和接口； 

4、系统需求中写明系统需求实现什么，但不需要写具体怎么做，即明确阐述需要实现的要求，但不限定设计实现的细节。

3.1 系统需求规范

1. 系统需求包括：系统的功能和能力; 业务、组织和用户需求; 安全（safety）、安全（security）、人因工程（人体工程学）、接口、操作和维护的需求; 设计约束和合格需求。
2. 识别所需的系统概述
3. 识别系统要素之间的任何相互关系的考虑因素/约束
4. 识别系统要素和软件之间的任何相互关系的考虑因素/约束
5. 识别每个所需系统要素的任何设计考虑因素/约束，包括：

- 内存/容量需求

- 硬件接口需求

- 用户接口需求

- 外部系统接口需求

- 性能需求

- 指令结构

- 安全（security）/数据保护特性

- 应用参数设置

- 手动操作

- 可重用组件

1. 描述操作能力
2. 描述环境能力
3. 文档化需求
4. 可靠性需求
5. 物流需求
6. 描述安全（security）需求
7. 诊断需求

3.2 基本实践

SYS.2.BP1:定义系统需求。使用利益相关方需求及其变更，以识别系统所需的功能和能力。在系统需求规范中定义功能性和非功能性系统需求。

注1：影响功能和能力的应用参数是系统需求的一部分。

注2：关于利益相关方需求的变更。

SYS.2.BP2:结构化系统需求。在系统需求规范中结构化系统需求，例如：

 按项目相关集群进行分组，

 按项目中逻辑顺序排序，

 基于项目相关准则进行分类，

 根据利益相关方需要进行优先级排序。

注3：优先级排序通常包括将功能性内容分配给已计划的发布。

SYS.2.BP3: 分析系统需求。分析已定义的系统需求（包括它们的相互依赖关系），以确保正确性、技术可行性和可验证性，并且支持风险识别。分析对成本、进度和技术的影响。

注4：对成本和进度的影响分析有助于项目估算的调整。

SYS.2.BP4: 分析对运行环境的影响。识别定义的系统和运行环境中其他要素之间的接口。分析系统需求对这些接口和运行环境的影响。

SYS.2.BP5:制订验证准则。对每一个系统需求制订验证准则，定义定性的和定量的措施用于需求验证。

注5: 验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作系统测试用例开发或其它证明符合系统需求的验证措施的输入。

4、硬件需求

5、软件需求

5.1 软件需求规范

1. 识别使用的标准
2. 识别任何软件架构的考虑因素/约束
3. 识别所需的软件要素
4. 识别软件要素之间的关系
5. 须考虑：

- 任何所需的软件性能特性

- 任何所需的软件接口

- 任何所需的安全（security）特性

- 任何数据库设计需求

- 任何所需的错误处理和恢复属性

- 任何所需的资源消耗特性

5.2 基本实践

SWE.1.BP1:定义软件需求。使用系统需求和系统架构及其变更来识别软件所需的功能和能力。在软件需求规范中定义功能性和非功能性软件需求。

注1: 影响功能和能力的应用参数是系统需求的一部分。

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

SWE.1.BP2:结构化软件需求。在软件需求规范中结构化软件需求，例如：

 按项目相关集群进行分组，

 按项目中逻辑顺序排序，

 基于项目相关准则进行分类，

 根据利益相关方需要进行优先级排序。

注3: 优先级排序通常包括将软件内容分配给已计划的发布。参见SPL.2.BP1。

SWE.1.BP3:分析软件需求。分析已定义的软件需求，包括其相互依赖关系，以确保正确性、技术可行性和可验证性，并支持风险识别。分析对成本、进度和技术的影响。

注4：对成本和进度的影响分析有助于项目估算的调整。

SWE.1.BP4:分析对运行环境的影响。分析软件需求对系统要素接口及运行环境的影响。

注5: 运行环境是指软件运行所在的系统（例如：硬件、操作系统等）。

SWE.1.BP5:制订验证准则。对每个软件需求制订验证准则，定义定性的和定量的措施以用于需求验证。

注6: 验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作软件测试用例开发或其它证明符合软件需求的验证措施的输入。

5.3 软件需求规格说明

本章节基于GB/T 9385-2008 计算机软件需求规格说明规范。

5.3.1 基本性质

SRS是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。SRS可由来自供方、顾客或双方的一个或多个人员编写。编写SRS应关注以下基本点：

1. 功能——软件将执行什么功能？
2. 外部接口——软件如何与人、系统的硬件及其他硬件和其他软件进行交互？
3. 性能——各种软件功能的速度、响应时间、恢复时间等是多少？
4. 属性——软件的可用性、可靠性、可移植性、正确性、可维护性、安全性如何？
5. 影响产品实现的设计约束——是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求？

5.3.2 环境

应考虑SRS在整个项目计划中的作用。项目计划的定义见GB/T 11457。软件既可以是项目的所有功能，也可以是更大系统的一部分。在后一种情况下，典型的SRS将指出系统及其软件部分的接口，并将外部性能和功能需求写入软件部分。显然，SRS应当在系统需求上扩展并与及保持一致。

5.4 好的软件需求

注：5.4章节内容整理自知乎：如何写一份牛X的软件需求 - 知乎 (zhihu.com)

5.4.1 

软件需求应当只描述必要的信息，只能包含描述性、定义性的内容，而不能包含解释性的内容。比如下面这个需求：

The signal ACC Active State shall be set to SUPPRESSED if the following conditions are fulfilled[ACC-Req 002]:

• Safe Vehicle Speed is less than 30kph OR
• Safe Vehicle Speed is greater than 120kph.

需求中的“shall”、“set to”等都是定义性的用词，不拖泥带水，使用最简单明了的词句描述软件行为。很多人写需求时会有拖沓毛病（比如加入一些废话，或者写容易引发歧义的内容），比如写成这样：

The signal ACC Active State shall [ ***always*** ] be set to SUPPRESSED if [ **all of** ] the following conditions are fulfilled。

5.4.2

不能使用有二义性的语句或词组，不能使用带主观色彩的词语。尽量定义软件在什么情况下“做什么”，而不是定义在什么情况下“不做什么”（前者更简单完备，不容易有遗漏）。如下面的例子：

The signal ACC Active State shall be set to DEACTIVATED if [ ***each of ***] the following conditions are fulfilled[ACC-Req 002]:

• Camera Status is invalid，
• Radar Status is invalid .

这里的"each of" 就引入了二义性的。前述两个条件彼此到底是“与”的关系，还是“或”的关系呢？不同的人理解就不一样。如果你英语好一点，那么就知道each of 是指“与”的关系，即只有雷达和摄像头都失效了，ACC才会退出。但如果想指“或”的关系，描述应该用 "either of" 。正确的写法应该删除 each of, 并明确的写出 OR 关系词, 来消除二义性：

The signal ACC Active State shall be set to DEACTIVATED if the following conditions are fulfilled[ACC-Req 002]:

• Camera Status is invalid，OR
• Radar Status is invalid .

偶尔也会有人将需求写成这样：

The signal ACC Active State shall be set to DEACTIVATED if the following conditions are fulfilled[ACC-Req 002]:

• Safe Vehicle Speed is [***less enough***], OR
• Safe Vehicle Speed is [***too fast***].

“如果车速足够慢就退出ACC”，“如果车速太快了就退出ACC”。这些主观的、完全没有明确定义的概念让人怎么去开发？

另外，需求尽量不要写成否定句，读起来费劲，还容易遗漏，比如：

The signal ACC Active State shall [***NOT***] be set to DEACTIVATED if the following conditions are fulfilled[ACC-Req 002]:

• Camera Status is valid，OR
• Radar Status is valid .

"只要雷达或者摄像头有一个可用，ACC就不退出"。

5.4.3

每条需求都必须是组成某个功能的最基本单元，不能被分解的。例如：

The signal ACC Active State shall be set to SUPPRESSED if the following conditions are fulfilled[ACC-Req 002]:

• Safe Vehicle Speed is less than 30kph OR
• Safe Vehicle Speed is greater than 120kph.

仔细看，这条需求，其实可以分解为两条需求：

1. The signal ACC Active State shall be set to SUPPRESSED if Safe Vehicle Speed is less than 30kph.
2. The signal ACC Active State shall be set to SUPPRESSED if Safe Vehicle Speed is greater than 120kph.

本条需求，可以适当放宽，但一定要考虑好需求怎么分配，以及测试用例怎么写的问题。

5.4.4

每条需求都必须是能够直接测试的，即需求里描述的信号接口是完整的，是测试设备可以直接控制或读取的。比如：

The signal ACC Active State shall be set to SUPPRESSED if Safe Vehicle Speed is less than 30kph.

这条需求写明了软件输入信号是Safe Vehicle Speed（可改变CANbus上的车速信号）, 输出信号是 ACC Active State（可通过XCP来观测）。只有在测试人员（软件需求对应的是HIL测试）能够改变输入信号、观察输出信号的情况下，这条需求才是合理的。如果信号不能直接观察，就要改变需求的描述方式。这就是HIL测试工程师一定要参与需求评审的原因。

还有一种情况是需求内容根本无法测试。例如最好不要在软件需求里写PI控制器的详细控制特性，因为很多情况下HIL测试是不容易设计出测试用例的。这部分需求最好写到软件需求的下一级，也就是设计需求中，用SIL的方式测试。

5.4.5 

根据V模型，所有的软件需求向上必须要关联一条系统需求，向下必须关联一条设计。平级必须关联一条HIL测试用例。

5.4.6 

好的需求文档除了定义软件行为，还要有充足的解释性内容，帮助阅读者理解软件行为，做到仅看文档就能知其然、之其所以然。这就是需求文档的“信息information“部分。

前面说需求requirements 只能包含描述性、定义性的内容。所以，除了这部分以外，所有的其他内容都属于信息。信息主要分成三类：

1. 解释软件行为的原因，举例子、作类比，补充材料帮助读者理解
2. 重复定义的软件行为。为了解释行为A，把其他需求文档中的相关软件行为B再复述一遍。由于行为B已经作为需求在别处出现过了，它的复述虽然是定义性语言，但也只能作为信息。
3. 需求作者给HIL测试团队留下的建议。很多时候HIL测试是外包团队进行，他们对软件接口并不一定充分熟悉。有时软件需求的作者会在需求文档中写下一些备注，指导HIL团队找到正确的接口。