网站功能规格在某些方面的名声不太好。程序员们痛恨功能规格，因为它们非常枯燥，并且会占用大量编码的时间去阅读它们。结果，那些“没有人读的功能规格”反过来又强化了“撰写它们是一件浪费时间的工作”的印象。

关于功能规格的抱怨之一是它们没有反映实际的产品。“在实施过程中事情会产生变化”，每个人都理解这个——这是技术型工作的正常情况。有时候你考虑好的一些事情会行不通，或不大可能以你想像的那种方式来运作。无论如何，这并不是一个把撰写功能规格当成一件失败的工作而放弃的理由。相反，它强调了“维护功能规格”和“及时更新它”的重要性。当事情在实施过程中发生改变的时候，你不应该抬起双手宣称撰写功能规格是没有价值的，而是应该随时注意保持功能规格与开发的同步更新。 但是，无论这个项目有多么庞大或复杂，有几条规则适用于撰写任何类型的需求。

乐观(be posmve)。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。比如，下面这句描述就不太好：这个系统不允许用户购买没有风筝线的风筝。

替换成下面这句会更好

??? 如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面。

具体(be specific)。尽可能详细地解释清楚状况，这是我们能决定一个需求是否被实现的最佳途径。

对比下面的例子：

1．该网站要使残疾人可用。

2．该网站要遵守美国残疾人法案的第508条。

???

第一句话看上去像是定义了一条明确的需求，但是不需要花费太大精力就能看出它有很多漏洞。什么叫做“可用”?如果这个网站提供所有图片的文字描述是否就“可用”了呢?哪些人可以算成残疾人?如果这个网站没有音频，它也必须要使聋人“可用”——这是否就可以了呢?

???

幸运地是，美国国会已经为我们写出了所有的这些定义和区别，那就是第二句话所说的、非常详细地定义了我们的目标的某个法律文件。通过去除有不同释义的可能性，第二条需求完全避开了在实施过程之中或之后有可能出现的争议。

?

?避免主观的语气(avoid su切ectivelanguage)。这是另外一种使需求“保持明确”和“避免歧义”的途径——因而也避免

了误解的可能性。

这里有一个非常主观的需求：

这个网站风格应该是时尚、闪耀的。

?

需求必须可验证——就是说，它必须要能证明“这个需求没有被满足”。你如何去验证这种被宣称为“时尚”和“闪耀”的产品品质?我对于时尚的定义也许并不符合你的，而CEO更可能对此有完全不同的看法。

?

这并不是说你不能要求你的网站时尚，只是必须找到某种方式来明确说出应该达到的标准：这个网站应该符合邮递员Wayne所期望的时尚。

? wayne通常不会对这个项目说些什么，但是我们的项目发起人很显然会尊重他对于时尚的看法。而且这有可能和我们的用户的期望值是一样的。但是这样的一个需求仍然是很主观的，因为我们依赖的是Wayne对于风格的看法，而不是可以更客观界定的一系列的标准。所以，这个需求最好能像这样：

网站的外观应该符合企业的品牌指南文档。

? 时尚的概念已经完全从这个需求中消失了。相反地，我们得到了一个清晰的、毫不含糊的、已有的参考指南。为了确保品牌指南有足够的时尚性，负责市场的副总裁可能需要去了解邮递员Wayne，或者去和她十几岁的女儿交流，甚至她还可能做一些用户调研的工作。这取决于她。但是现在我们可以明确地说出“这个需求是否被满足了”。