当前位置:首页-文章-需求工程-正文

一个需求完整性检查实例

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 检查结果

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

一个需求完整性检查实例 - 第1张

图1 需求检查结果

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

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

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

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

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

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

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

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

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

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

6 总结

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

本文来源: V微智能。

相关文章

换一批