一个需求一致性检查实例

1 背景

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

前文讨论了一个需求完整性检查的例子，本文再来讨论一个需求一致性检查的实例。

2 需求实例

这是一组描述汽车转向灯逻辑的需求。其控制逻辑如下：

REQ01：当转向灯拨杆（pitman_arm）处于DOWN位置且保持时间小于0.5s，则左转向灯（left blinker）应为ON且保持3s；

REQ02：当转向灯拨杆（pitman arm）处于UP位置且保持时间小于0.5s，则右转向灯（right blinker）应为ON且保持3s；

REQ03：当转向灯拨杆处于DOWN位置且保持时间不小于0.5s, 则左转向灯应为ON直到转向灯拨杆离开DOWN位置；

REQ04：当转向灯拨杆处于UP位置且保持时间不小于0.5s, 则右转向灯应为ON直到转向灯拨杆离开UP位置；

REQ05：左转向灯和右转向灯永远不能同时为ON；

上述需求存在事件/状态歧义，前文已经讨论过。这里不再重复。

上述需求中，输入为转向灯拨杆（pitman_arm），可取值为{CENTER，UP，DOWN}。输出为左转向灯（left blinker）、右转向灯（right blinker），可取值为{ON，OFF}。

3 一致性判据

所谓需求不一致（inconsistency），简单理解为需求之间存在冲突。

本质上，一组需求定义了针对目标对象的一个约束集合，该约束集合规定了一个解空间。如果需求是一致的（consistency），则解空间非空，即存在一个或多个实现，能满足所有约束。

第一种需求不一致，是违反了存在一致性（existential consistency），是指由于需求冲突导致解空间为空，也即不存在能够满足需求的实现。例如，一条需求要求系统具有属性P，另一条需求要求具有属性非P，则找不到任何一种系统实现，能够同时满足这两条需求。

另一种需求不一致，是违反了部分一致性（partial consistency）。例如，req1为“当x<=10, 则y为true”，req2为“当x>=10，则y为false”。同时满足req1、req2且不冲突的解空间不为空；但是当x=10时，y既为true也为false，则需求冲突。

本实例中，“REQ05：左转向灯和右转向灯永远不能同时为ON”为安全性需求。本文检查的一致性，是指在其他需求（REQ01到REQ04）的约束下，是否存在违反上述安全性需求的情形。这也属于部分一致性检查。

4 检查结果

下图给出了对上述需求进行检查的结果。

图1 需求检查结果

从结果可见，检查未通过，需求中存在一致性缺陷。检查结果给出了一个反例，说明了导致一致性缺陷出现的路径。

该反例中，Step 10中，当时间为0.52s时，出现了左转向灯(left_blinker)、右转向灯(right_blinker)都为ON的情况，即违反了“REQ05：左转向灯和右转向灯永远不能同时为ON”这一条需求。

检查前序步骤，Step 4中，在时间为0.01s时，转向灯拨杆(pitman_arm)变为DOWN；Step 6中，在0.02s时，转向灯拨杆(pitman_arm)变为UP，则在DOWN位置的保持时间小于0.5s。按照“REQ01：当转向灯拨杆处于DOWN位置且保持时间小于0.5s，则左转向灯应为ON且保持3s”，此时左转向灯应为ON，且应保持3s。

Step 10中，在0.52s时，转向灯拨杆(pitman_arm)保持在UP位置已等于0.52s，按照“REQ04：当转向灯拨杆处于UP位置且保持时间不小于0.5s, 则右转向灯应为ON直到转向灯拨杆离开UP位置”，此时右转向灯应为ON，同时左转向灯尚且保持为ON。这就出现了左右转向灯同时为ON的情况。

说明：在给出的反例中，时间约束实际是个区间。简单起见，这里取下界。

5 对实例的说明

之前的“一个需求完整性检查实例”中，反例仅由前置状态和当前状态两个步骤构成。相比之下，本例中的反例，是由多步骤的时间-状态序列构成的，是一种更一般的情况。

本实例中，REQ01到REQ04属于功能需求（或者行为需求），REQ05为安全性需求。安全性需求是一种负面（negative）需求，表明某种属性永不应为真。从部分一致性的角度，本实例找到一个反例，表明REQ05被违背；但是，从存在一致性的角度，满足所有需求（包括安全性需求）的系统实现是存在的，这需要后续的设计、实现环节补充约束。因此，是否需要在当前需求层次保证安全性需求的满足性，是工程问题。从工具的角度，仅提供一种能力，按需使用即可。

6 总结

本文给出一个具体的需求一致性检查实例，来帮助理解更一般的需求检查的使用场景。