# 六、轻松写就功能规格说明书 - 第2节：什么是规格说明书？ (你看过第一篇吗？如果还没有可以到这裡看。) 这一系统的文章是在探讨功能规格而非技术规格(译注：也称为工程规格)。人们常会把这两者搅混。我不知道是否有其他标准术语，不过我个人的用法如下： 功能规格纯粹由使用者的角度来描述产品如何运作。它不管东西是怎麽做出来的。功能规格会述及功能，还会详述画面、功能表、对话框等等。 技术规格则是描述程式内部的实作。它会说明资料结构、关连式资料库模型、程式语言及工具的选用、演算法等等。 当你从头设计一个产品时，最重要的一点就是要确定使用者的体验。要显示什麽样的画面，运作的逻辑为何，要达成什麽功能。再来还要考虑如何达成。如果产品本身要做什麽都还没决定，争论要用哪种程式语言是完全没有意义的。我在这个系列中只会讨论功能规格。 我写了一篇简短的规格范例，应该能让你大致瞭解一份良好功能规格的重点。在我们继续之前请先读这份规格范例。 读完了吗？ 一定还没有。现在就去读完再回来，这样我们才能讨论一份良好规格所应具备或不应包含的东西。我会在这裡等你。谢谢。 (耐心地等待...) 噢，很好。你回来了。 下面列出一些我在每份规格上都会放的项目。 一段声明。纯粹自卫用。如果你写一段文字说「这份规格还没完成」，别人就不会衝进你办公室把你的头咬掉。等时间流逝规格开始完整时，你可以改写成「就我所知这份规格已经够完整了，不过有什麽漏掉了，请告诉我」这提醒我每份规格都需要： 一位作者。有些公司认为规格应该要由整组人来写的。如果你尝试过团体写作，就知道那是最可怕的酷刑。团体写作就留给拥有大批新出厂哈佛毕业生的管理顾问公司吧，他们需要做大量的虚工才能收取钜额费用。你的规格应该由一个人负责并撰写。产品规模很大时就切成几区，让不同人写各区的规格。其他公司认为把个人名字放在规格上会让他「独佔功劳」，会太过自我本位，不是良好的「团队合作」模式。胡说。人们对被指派的工作应该要同时有责任和所有权。如果规格有问题，在规格上印上大名的规格负责人应该要负责解决。 脚本。当你在设计产品时，一定要想出某些真实存正的状况以及人们使用的方法。否则最后就会设计出一个完全没有真实用途的产品(就像Cue?Cat)。替你的产品选好客户群，针对每种客户想像一个完全虚构而又完全典型的使用者，用很典型的方式使用产品。我的UI设计书(可以在线上免费取得)中的第9章讨论虚构使用者和情境的建立。这些使用者或情境就是用在这裡的。状况定得愈清楚愈真实，针对真实或虚构使用者的设计就愈好。这也正是我会放入这麽多虚构细节的缘故。 非目标。当你和整组人一起建立产品时，通常每个人都会各有所好，因而产生各式各样真正或虚构的必备心爱功能，如果要将这些功能全部都做出来，恐怕永远做不完而且要花很多很多的钱。所以你必须马上开始删功能，而删功能的最佳方法就是利用规格的「非目标」章节，列出我们不打算做的东西。非目标可能是个不会具备的功能(「没有精神感应式介面！」)，也可能是较一般性的定义(「我们不在意这个版本的效能。这个产品跑得多慢都没关係。如果第二版时间够，我们会把效率最佳化。」)这些非目标很容易引起争议，不过儘早把它们曝露出来却是非常重要的。就像老乔治布希说的：「绝对不会做！」 概要。这就像是规格书的目录。它可以是张简单的流程图，也可以是段广泛的架构讨论。大家会先读这部份知道大致轮廓，再来看细节才有意义。 细节、细节、细节。最后会进到细节。除非必须了解特定的细节，否则大多数人都会略过这一部份。当你在设计一个网路服务时，有个好方法就是把所有可能的画面都取个正式的名称，再对每个画面用一整章钜细糜遗地详述细节。 细节是功能规格中最重要的部份。由范例规格中，你可以注意到我对登入页面各种错误状况有极为详细的说明。当邮件地址错误时要怎麽做？密码错误时要怎麽做？这所有的错误状况，都会对应到将要撰写的真实程式码，不过更重要的是这些状况都会对应到某人必须做的决策。某个人必须决定遗忘密码时的处理方式。由于不决定就无法写程式，所以规格就必须把决定写下来。 未定义项目。第一版的规格有未定义项目是正常的。我在写初版草稿时总是有很多未定义项目，不过我都会标示出来(加上特殊格式便于寻找)，如果可以的话还会讨论各种可选用的方案。等程式人员开始作业时，所有未定义项目都必须处理乾淨。(你可能认为，先让程式员从简单的项目做起，你稍后再把未定义项目定清楚。这是个坏主意。光是处理程式人员实作程式时出现的新问题就够了，根本不会记得还有些旧问题有待处理。另外解决重大项目时所用的方法也可能会严重影响到程式的写法。) 旁注。在写规格时要记住你会有各种不同的读者：程式员、测试人员、行销人员、技术作者等等。当你在撰写时可能会想到一些只对某类读者有用的小资料。举例来说，我会把写给程式员看的讯息(通常描述某些技术实作细节)标成「技术注解」。行销人员直接跳过而程式人员就会细读。通常我的规格裡满满都是「测试注解」，「行销注解」和「文件编写注解」 规格必须是活的。某些程式团队会有一种「瀑布」心态：我们会一次就把整个程式设计好，所以把规格写好印出来丢给程式员就可以收工回家了。对这种想法我只能说：「哈哈哈哈哈哈哈哈！」 这种作法正是规格如此不受欢迎的原因。很多人都对我说：「规格根本没用，因为没有人会照著做。规格总是过时而且从来无法反映产品。」 原谅我。你的规格可能总是过时又不能反映产品。不过我的规格可是时常更新的。只要产品还在开发而又出现新的决策，就会持续进行更新。规格总会反映我们对产品运作的最佳认知。只要在程式完成时(也就是所有功能完备但尚未测试除错)规格才会冻结不变。 为了让大家好过一点，我不会每天重新发行规格。通常我会在伺服器上放一份最新版供大家参考。遇到特别的里程碑时，我会印一份出来，裡面加上修订标记让大家不必重读整份文件(他们可以快速地发现修订标记以便找出变更所在)。 谁该写规格？请看第三篇。