有人说，用例是项目利益相关方对系统的契约，那么需求规格说明也不是写给自己看的，它也是利益相关方共同遵守的契约。

所以需求的描述应当简单、明了，具有可读性，不会让人产生歧义。

这样的需求才可能是被利益相关方共同遵守的契约。

要形成这样的需求契约，需求描述应当遵循以下准则：

准则1：使用简单的语法

描述需求的句子结构应该非常简单，并且在整个需求规格说明中都遵循同样的规则，如：

主语……前置短语……谓语动词……直接宾语。

例如：

系统……从账户余额中……扣除……一定数量。

假如描述需求的句子没有一个简单的结构，所描述的需求可能就会变得难以理解。

准则2：明确地写出“控制者”

每一个动作都应明确谁是控制者。

以踢足球为例。球员1将球传给球员2，球员2运球，然后将球传给球员3。在每一个步骤中，都会有人“控制球”。“在句子结束的时候，谁控制足球？”不论什么时候，这个问题都应该有明确的答案。

准则3：从系统外部的角度来描述需求

编写需求不能从系统内部来看待外部世界，也不能从系统内部来描述系统。比如：“读取ATM卡和PIN号码，并从账号余额中扣除一定数量。”这就是从系统内部来描述系统的行为。这种方式违反了准则2，不知道谁是动作的主体。

正确的方式是从系统外部的角度来描述需求，如：

用户插入ATM卡并输入PIN，系统从账号余额中扣除一定数量。

准则4：显示过程向前推移

在描述完成某个功能所需的步骤时，应避免描述很多过小的步骤。因为这样将导致该功能的描述段落变得很长。所以应当将一些小的步骤合并，这样的需求可读性更好、更加清晰。

而要合并小的步骤，就要找到具有较高层次目标的步骤，这就需要将过程前移。比如：

一个过小的步骤：用户按下Tab键

为什么用户要按下Tab键呢？是为了将焦点移到地址框中。为什么她要将焦点移到地址框中呢？因为在系统开始工作前，她要输入用户名和地址。

因此，这个过小的步骤可以合并到下面的步骤中：

用户输入名字和地址。

准则5：显示操作者的意图，而不是动作

在需求规格说明中，我们只关心用户的意图，而不关心具体的动作。对具体动作的描述属于设计的任务，而不应该出现在功能需求文档中。

比如，以下的需求描述就不是很恰当：

1．系统要求用户输入名字。

2．用户输入名字。

3．系统要求用户输入地址。

4．用户输入地址。

5．用户点击“确定”。

6．系统显示用户的简介。

以下的需求描述会更好：

1．用户输入名字和地址。

2．系统显示用户的简介。

准则6：“确认”而不是“检查是否”

在很多功能描述中，都需要系统验证一些业务规则是否满足。通常，人们说系统检查某个条件是否满足，但是用“检查”这个动词并不好，因为它并不是真正的目的，系统这样做的真正的目的是为了确认、验证或确保某些事情。所以我们将“系统检查密码是否正确”替换为：

系统验证了密码是正确的。

比如，下面的需求描述：

2．系统检查密码是否正确。

3．如果密码正确，系统向用户提供有效的操作。

可以修改为：

2．系统验证密码正确。

3．系统向用户提供有效的操作。

这样修改后，就是描述了一个功能需求成功的场景。而：“如果密码无效时，应该怎么办？”则可以作为异常情况描述。

准则7：习惯用语：“用户让系统A与系统B交互”

当正在开发的系统A要从系统B中获取信息，我们不能这样写：“用户点击获取按钮，这个时候系统从系统B获得数据。”而应该这样描述：

用户命令系统从系统B获取后台数据。

通过编写方式的转变，我们指明是由用户控制执行的时间，并说明了用户、系统A，系统B的职责及交互的细节。

准则8：用“检测到什么”的方式来编写条件

在编写前置/后置条件时，应该写出系统检测什么，而不仅仅是发生了什么。

比如，不能写“客户忘记了PIN”。系统是不可能知道客户忘记了密码还是客户离开了，或者其他什么原因没有输入密码。在用户没有任何动作的情况下，这意味着系统只能检测到等待时间超过了限制。所以，这样的条件应当描述为：

等待用户输入密码的时间超时或PIN输入的时间超时。

这正是：

需求描述有技巧，遵循准则会更好

八个准则引美玉，只愿需求描述好

参考书目：编写有效用例，作者：（美）科伯恩（Cockburn,A.），译者：王雷，张莉，出版社：电子工业出版社