功能规格文档程序员容易会不愿意看，最终导致产品不愿意写。要解决这个问题，我们需要的不是文档有多厚多详细，而是要足够清楚和准确。
无论项目规格多复杂，多庞大，以下几条规则都可以适用于所有的功能规格说明书。
1. 乐观
描述这个系统将要做什么事情去“防止”不好的情况发生。而不是描述这个系统“不应该”做什么。
例如：
这个系统不允许用户购买没有风筝线的风筝。
替换成以下情况可能更好：
如果用户想买一个没有线的风筝的话，系统应该引导客户到风筝页面。
当然我认为不应该的情况也需要写上，因为客户有可能偏要不按指引走，而且测试也会做一些违背正常情况的测试。但是我们可以在他不按指引走之前尽量制止他。
2. 具体
尽可能详细地解释清楚状况，这是我们决定一个功能是否被实现的具体途径。
这里需要比较具体的例子来进行分析，但是我们在写下每一个名词的时候，需要考虑清楚是否需要对其进行修饰（形容词，数量词等），不进行修饰会不会导致需求范围扩大。
3. 避免主观语气
这是另一种使需求“保持明确”和“避免歧义”的途径，因而也避免了误解的可能性
通常我们写需求规格文档不会用主观语气写的。我们需要量化，定量来确定需求。
