软件随想录(local.joelonsoftware.com/wiki)-2000年10月03日 无痛功能规格 - 第二篇: 规格是什么? - Painless Functional Specific

From The Joel on Software Translation Project

无痛功能规格 - 第二篇：规格是什么？

作者：周思博 (Joel Spolsky)
译：Paul May 梅普华
编辑：Jeff Wang 王家麒
October 3, 2000
A part of Joel on Software, http://www.joelonsoftware.com

(你看过第一篇吗？如果还没有可以到这里看。)

这一系统的文章是在探讨功能规格而非技术规格(译注：也称为工程规格)。人们常会把这两者搅混。我不知道是否有其他标准术语，不过我个人的用法如下：

1. 1. 功能规格纯粹由使用者的角度来描述产品如何运作。它不管东西是怎么做出来的。功能规格会述及功能，还会详述画面、功能表、对话框等等。
   2. 技术规格则是描述程序內部的实现。它会说明数据结构、关连式数据库模型、程序语言及工具的选用、演算法等等。

当你从头设计一个产品时，最重要的一点就是要确定使用者的体验。要显示什么样的画面，运作的逻辑为何，要达成什么功能。再来还要考虑如何达成。如果产品本身要做什么都还没决定，争论要用哪种程序语言是完全没有意义的。我在这个系列中只会讨论功能规格。

我写了一篇简短的规格范例，应该能让你大致了解一份良好功能规格的重点。在我们继续之前请先读这份规格范例。

读完了吗？

一定还没有。现在就去读完再回来，这样我们才能讨论一份良好规格所应具备或不应包含的东西。我会在这里等你。谢谢。

(耐心地等待...)

噢，很好。你回来了。

下面列出一些我在每份规格上都会放的项目。

一段声明。纯粹自卫用。如果你写一段文字说「这份规格还没完成」，别人就不会冲进你办公室把你的头咬掉。等时间流逝规格开始完整时，你可以改写成「就我所知这份规格已经够完整了，不过有什么漏掉了，请告诉我」这提醒我每份规格都需要：

一位作者。有些公司认为规格应该要由整组人来写的。如果你尝试过团体写作，就知道那是最可怕的酷刑。团体写作就留给拥有大批新出厂哈佛毕业生的管理顾问公司吧，他们需要做大量的虚工才能收取巨额费用。你的规格应该由一个人负责并撰写。产品规模很大时就切成几区，让不同人写各区的规格。其他公司认为把个人名字放在规格上会让他「独占功劳」，会太过自我本位，不是良好的「团队合作」模式。胡说。人们对被指派的工作应该要同时有责任和所有权。如果规格有问题，在规格上印上大名的规格负责人应该要负责解决。

脚本。当你在设计产品时，一定要想出某些真实存正的状况以及人们使用的方法。否则最后就会设计出一个完全没有真实用途的产品(就像Cue?Cat)。替你的产品选好客户群，针对每种客户想像一个完全虚构而又完全典型的使用者，用很典型的方式使用产品。我的UI设计书(可以在在线免费取得)中的第9章讨论虚构使用者和情境的建立。这些使用者或情境就是用在这里的。状况定得愈清楚愈真实，针对真实或虚构使用者的设计就愈好。这也正是我会放入这么多虚构细节的缘故。

非目标。当你和整组人一起建立产品时，通常每个人都会各有所好，因而产生各式各样真正或虚构的必备心爱功能，如果要将这些功能全部都做出来，恐怕永远做不完而且要花很多很多的钱。所以你必须马上开始删功能，而删功能的最佳方法就是利用规格的「非目标」章节，列出我们不打算做的东西。非目标可能是个不会具备的功能(「没有精神感应式介面！」)，也可能是较一般性的定义(「我们不在意这个版本的效能。这个产品跑得多慢都没关系。如果第二版时间够，我们会把效率最佳化。」)这些非目标很容易引起争议，不过尽早把它们曝露出来却是非常重要的。就像老乔治布希说的：「绝对不会做！」

概要。这就像是规格书的目录。它可以是张简单的流程图，也可以是段广泛的架构讨论。大家会先读这部份知道大致轮廓，再来看细节才有意义。

细节、细节、细节。最后会进到细节。除非必须了解特定的细节，否则大多数人都会略过这一部份。当你在设计一个网络服务时，有个好方法就是把所有可能的画面都取个正式的名称，再对每个画面用一整章巨细糜遗地详述细节。

细节是功能规格中最重要的部份。由范例规格中，你可以注意到我对登入页面各种错误状况有极为详细的说明。当邮件地址错误时要怎么做？密码错误时要怎么做？这所有的错误状况，都会对应到将要撰写的真实程序代码，不过更重要的是这些状况都会对应到某人必须做的决策。某个人必须决定遗忘密码时的处理方式。由于不决定就无法写程序，所以规格就必须把决定写下来。

未定义项目。第一版的规格有未定义项目是正常的。我在写初版草稿时总是有很多未定义项目，不过我都会标示出来(加上特殊格式便于寻找)，如果可以的话还会讨论各种可选用的方案。等程序人员开始作业时，所有未定义项目都必须处理干凈。(你可能认为，先让程序员从简单的项目做起，你稍后再把未定义项目定清楚。这是个坏主意。光是处理程序人员实现程序时出现的新问题就够了，根本不会记得还有些旧问题有待处理。另外解决重大项目时所用的方法也可能会严重影响到程序的写法。)

旁注。在写规格时要记住你会有各种不同的读者：程序员、测试人员、行销人员、技术作者等等。当你在撰写时可能会想到一些只对某类读者有用的小资料。举例来说，我会把写给程序员看的讯息(通常描述某些技术实现细节)标成「技术注解」。行销人员直接跳过而程序人员就会细读。通常我的规格里满满都是「测试注解」，「行销注解」和「文件编写注解」

规格必须是活的。某些程序团队会有一种「瀑布」心态：我们会一次就把整个程序设计好，所以把规格写好印出来丟给程序员就可以收工回家了。对这种想法我只能说：「哈哈哈哈哈哈哈哈！」

这种作法正是规格如此不受欢迎的原因。很多人都对我说：「规格根本没用，因为没有人会照著做。规格总是过时而且从来无法反映产品。」

原谅我。你的规格可能总是过时又不能反映产品。不过我的规格可是时常更新的。只要产品还在开发而又出现新的决策，就会持续进行更新。规格总会反映我们对产品运作的最佳认知。只要在程序完成时(也就是所有功能完备但尚未测试除错)规格才会冻结不变。

为了让大家好过一点，我不会每天重新发行规格。通常我会在服务器上放一份最新版供大家参考。遇到特别的里程碑时，我会印一份出来，里面加上修订标记让大家不必重读整份文件(他们可以快速地发现修订标记以便找出变更所在)。

谁该写规格？请看第三篇。

这些网页的內容为表达个人意见。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved。