网站架构时要注意功能规格

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

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

但是，无论这个项目有多么庞大或复杂，有几条规则适用于撰写任何类型的需求。

乐观（be positive）。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。比如，下面这句，描述就不太好：

这个系统不允许用户购买没有风筝线的风筝。

替换成下面这句会更好：

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

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

对比下面的例子：

1、该网站要是残疾人可用。

2、该网站要遵守中国残疾人法案的第XXX条。

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

本课主题：网站架构时要注意功能规格

相关主题：
网站架构需要注意的十九点概要
网站架构中的功能需求和内容需求
详谈网站架构的内容需求
请拨打热线：0571-86586571