描述需求应遵循的几个简单准则
有人说，用例是项目利益相关方对系统的契约，那么需求规格说明也不是写给自己看的，它也是利益相关方共同遵守的契约。
所以需求的描述应当简单、明了，具有可读性，不会让人产生歧义。
这样的需求才可能是被利益相关方共同遵守的契约。
要形成这样的需求契约，需求描述应当遵循以下准则：
准则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.），译者：王雷，张莉，出版社：电子工业出版社