一个需求完整性检查实例

1 背景

需求结构化后，可以对需求进行自动化检查。需求检查有多种应用，例如完整性检查、逻辑一致性检查、上下级需求一致性检查等。

本文讨论一个具体的需求完整性检查的例子，来管中窥豹，帮助理解需求检查能做点什么。

2 需求实例

这是一组描述汽车前照灯开关逻辑的需求。前照灯的控制开关有三个状态，即ON（开）、OFF（关）、AUTO（自动）。其控制逻辑如下：

REQ01：当开关为ON时，前照灯状态应为点亮；

REQ02：当开关为OFF时，前照灯状态应为熄灭；

REQ03：当开关为AUTO时，传感器检测到光强小于60%且保持时间大于2秒，前照灯状态应为点亮；

REQ04：当开关为AUTO时，传感器检测到光强大于70%且保持时间大于3秒，前照灯状态应为熄灭；

REQ05：当开关为AUTO时，传感器检测到光强在60%到70%之间，前照灯应保持前序状态。

这一组需求看起来似乎很直观合理。

3 完整性判据

这里采用的完整性检查的判据为：针对输入变量，如果存在未被需求覆盖的取值集合，则认为是需求是不完整的。

针对本文讨论的需求，其输入变量为如下两个：

控制开关，为枚举类型，可取值为{ON，OFF，AUTO}；

光强，为实数类型，取值范围为0-100%；

输出变量为前照灯，其取值为{点亮，熄灭}。

按照完整性判据，如果能找到至少一个<开关, 光强>的取值，在上述需求逻辑中没有定义，不能获得输出变量的状态，则表明该需求是不完整的。

4 检查结果

这里直接给出通过工具对上述需求进行检查的结果，见下图。

需求检查结果

从图中可见，工具给出了4个场景，需求逻辑没有覆盖，表明需求存在完整性缺陷。

分析第一个场景，即在光强为60%的初始状态（前置条件）下，令光强为3%、开关为AUTO，此时需求逻辑未覆盖。之所以未覆盖，根源在下述需求：

REQ03：当开关为AUTO时，传感器检测到光强小于60%且保持时间大于2秒，前照灯状态应为点亮；

也即，光强从不小于60%变化到小于60%，但保持时间不大于2秒，不符合上述需求的条件，也不符合其他需求的条件，导致该场景未被覆盖。

找到了这一缺陷的解释，则可以补充完善需求，消除这一条完整性缺陷。

对其他几个场景，都可以做类似分析。实际上，经过综合分析可知，本例中的完整性问题，都是由于需求中的时间约束引起的。

5 对本需求检查实例的说明

本文所给出的实例较为简单，因此所进行的需求完整性检查也有其特殊性，主要在两个方面：

一是对检查结果的解释。工具对需求进行检查，给出“存在需求缺陷”的结论及缺陷场景，并不代表就已经定位到引起该缺陷的问题。一般来讲需要人去理解、解释。如果需求比较复杂，缺陷场景将远比本实例复杂，可能是经过了上百个状态后，才能出现缺陷；此时，人去分析导致缺陷的原因也是困难的，但至少提供了一个明确的线索。

二是本实例的检查结果给出了多个缺陷场景，实际上从路径覆盖的角度是完整的，也即是一个sound结果。但是，对于一般的需求检查，由于复杂性，一般只要给出一个场景，表明需求存在完整性缺陷，就完成了一次检查。本例给出多个缺陷场景，可以认为是一种特殊情况。

6 总结

本文给出一个具体的需求完整性检查的例子，来帮助直观理解需求检查是什么以及能做点什么。