ASPICE V4.0包括的如下与需求(Requirements)相关的Process中，SYS.2, HWE.1, SWE.1的“BP 1 - Specify Requirements”中要求基于需求特征 (Characteristics of requirements)，来定义Requirements Specification。

而ASPICE V3.1，并未有明确要求在定义需求时需要遵循需求特征。

ASPICE模型中推荐的，需求特征的参考标准有ISO IEEE 29148, ISO 26262-8，以及INCOSE Guide for Writing Requirements.

如下文章谈及的需求特征，借鉴了ISO IEEE 29148及ISO 26262-8，读者可以参考。

浅谈需求及需求特征

本文对INCOSE Guide for Writing Requirements中定义的需求特征 (Characteristics of requirements)进行解读。

需求特征的分类

伴随着项目进展，伴随着需求分析和设计活动，高层级的需求转化为底层级的需求，例如：

Stakeholder needs and requirements –> 转化为 –> System Requirements

System Requirements –> 转化为 –> Software Requirements

System Requirements –> 转化为 –> Hardware Requirements

分类1是指，与需求的形式转换相关的需求特征。

需求是所有相关方达成一致的“Agreement(协议或承诺)”，也是各方都需要遵守的“Obligation(义务)”。分类2是从这个方面来定义的需求特征。

C1 – 必要的(Necessary)

定义的所有需求，都是必要的。

不必要的需求，会消耗项目的资源、成本和时间，也可能会带来不必要的风险。

可以通过如下途径判断需求的必要性：

去除掉这个需求，产品仍然可以满足相关方的需要

这个需求，可以被其他需求实现或替代

这个需求，无法向上追溯(即: 无法追溯到源头)

需求工程师无法对这个需求，给出合理的理由

C2 – 合适的(Appropriate)

合适的(Appropriate)，也可称为“implementation free”。是指需求的意图、需求的详细程度，需要与其所在的层次相匹配。

需求可以在各个层级上来定义，不同的层级，其主语是不一样的，所以需求的描述一定需要与其“主语”所在的层级相匹配。需求描述的主语，不能是其上一个层级的，也不能是其下一个层级的。

例：

BMS SW的Software Requirements，是描述的对“BMS SW”这个Software的要求。

“Sensor Handler模块需要读取从Driver模块采集到的数据，并对数据进行滤波和真实性检查的处理。” --> 这条需求描述的主语是”Sensor Handler模块”，是软件架构设计层级的，因此这条需求不是BMS SW的SW Requirements。

这个示例的需求描述，还存在哪些问题？违反了本文阐述的哪些规则？

C3 – 明确的(Unambiguous)

需求描述所表达的意图，是明确的，所有读者对其的理解是唯一的。

例如：

电池充电的场合，当电池充满时，BMS系统需要及时切断主正接触器。--> 不同的相关方，对“及时”的理解，会一致吗？

C4 – 完整的(Complete)

完整的需求描述，是无需进一步的说明，即可准确表达其意图并明确其验证成功的标准。

例如：

需求描述时，包括可能出现的各种场景（例如：正常，异常等）。

功能需求必须包括一个完整且可验证的性能特征。

接口需求必须关联到，这个接口是哪个实体，在与谁进行怎样的交互时使用的。

需求描述中用到的“术语”，必须有唯一的定义。

基于标准或法规的要求必须清楚地描述：系统需要做什么才能满足标准或法规的要求和意图。

C5 – 原子的(Singular)

需求需要是原子的，不可再分的。一个需求描述中，不能包括多个需求点。

这样做的目的，是为了更好的对需求进行管理，有利于不同层级间需求的追溯、有利于进行验证(Verification)和确认(Validation)。

C6 – 可实现的(Feasible)

需求在项目的约束条件内是可实现的，约束条件可包括例如：成本、进度、技术、法律、道德、安全等。

例如：

在某些国家，手机相机在拍照时是不能静音的，这不是技术上的不可实现，这是依据当地的法律和道德的不可实现。

C7 – 可验证/可确认的(Verifiable/Validatable)

验证(Verification)的含义，可参考如下文章：

谈ISO26262:2018软件部分的验证方法(1)

验证(Verification)和确认(Validation)概念的区分，会另外撰写文章进行说明。

所有的需要(needs)和需求(Requirements)，都需要被验证及确认，以判断其被正确的实现，并符合预期。

这里借用如下图例，给读者以参考：

源自INCOSE Guide to Writing Requirements Figure 7: Needs and Requirements in the Context of Verification and Validation

C8 – 正确的(Correct)

需求的描述，必须是其所依据的上一个层级需求的准确和明确的表达。

“正确”意味着“没有错误”，例如：未包含不正确的信息、未遗漏信息、和未有模棱两可的措辞等。

例如：

System Requirements来自于Stakeholder Requirements，那么System Requirements的正确性是指：以Stakeholder Requirements为判定准则，System Requirements是否是对的。

C9 – 符合的(Conforming)

需求描述，需要符合其所需要遵循的指南或标准。

需求描述的标准，例如：

需求描述的Pattern：When <Condition clause>, the <Subject clause> shall <Action verb clause> <object clause>, <optional qualifying clause>

这样做的好处：

在一个组织里面，如果需求都是遵循统一的标准或指南，则需求会被更容易的定义、理解和Review。

有助于识别与完整的（C4）、明确的（C3）和可验证/可确认（C7）特征相关的错误。