定制软件需求说明该写什么？

“我们需要一个更好的预订系统”是很自然的起点。接下来要问的是：有人想预订时，实际会发生什么？

在第一次与开发人员交谈前，选一项工作，从最初的请求写到最终结果，也别漏掉棘手的地方。即使不知道软件该怎么开发，你也可以用日常语言讲清楚。

从人们实际做的一项工作开始

设想一家虚构的培训公司。一位客户发邮件，想报名某门课程，占两个名额。课程协调员查看是否有空位、回复客户并记录预订。如果课程已满，还得有人决定提供什么其他选择。

这些就足以成为一份有用的需求说明的起点。“开发一个带仪表盘的门户”会让开发人员猜测更多事情：谁来用、他们要完成什么、怎样才算预订成功。

英国政府的在开发服务前先弄清问题的指南建议了解用户、他们经历的整个流程以及限制条件。指南中的政府交付流程只适用于其自身情境。对于例子中的培训公司，起点可以简单得多：怎样让这位客户报上课程？

把当前做法和希望发生的改变分开

请实际做这项工作的人讲述最近的一次经历。先记下你观察到的情况，再写希望哪里有所改变。对于这家虚构公司，笔记可能是这样：

前一部分记录当前做法，后一部分提出改变，并把尚未决定的事明确留下。这很重要，因为员工可能有不同习惯：有人在等待客户回复时先留出名额，另有人让名额继续开放。先记下两种做法，再请开发人员把其中一种写成规则。

写明起点、终点和棘手情况

以课程咨询为例，实用的提纲可以包含：

• 起点： 一封邮件询问某门课程在指定日期能否提供两个名额。
• 相关人员： 课程协调员处理请求；培训经理决定有关预订规则的问题。
• 信息： 课程日期、空余名额、所需名额和客户的回复。目前这些信息散落在收件箱、电子表格和日历中。
• 完成结果： 协调员记录双方确认的预订，剩余名额随之更新，客户收到约定的确认信息。
• 棘手情况： 客户想要两个名额，但只剩一个。协调员需要在提供其他日期时让请求保持待处理状态。

这些只是示例中的拟议笔记，并非适用于所有培训公司的既定规则。问问自己的业务中，“双方确认的预订”是什么意思。发出名额邀请、客户接受，还是完成付款后，才算占用名额？把问题写下来，就能一起作出决定。

再用虚构记录做一个简短例子：课程 A 在 5 月 12 日还剩一个名额；咨询 B 想要两个。写出你期望的处理结果，以及由谁决定。这样开发人员就有了具体问题可讨论。

标明必要条件、想法和未解问题

必要条件： 协调员必须能看到哪些请求还需要自己回复。说明原因：否则就得在共用收件箱中翻找未完成的工作。

待讨论的想法： 客户或许可以自行选择另一个课程日期。在弄清相关工作以及谁会受益之前，先把它保留为一种可能性。

未解问题： 什么时候应预留名额，谁可以取消预留？写明由培训经理决定，而不是默默让开发人员替你制定业务规则。

也要写上真实存在的限制。例如，现有日历必须保留，只有特定员工可以查看客户信息，或某门课程必须在已知日期前得到支持。说明哪些限制已经确定，以及原因。如果日期或预算仍只是偏好，也要如实标明。

说明怎样判断结果是否有用

“更好用”需要一个具体例子。对这家公司来说，协调员应该能跟进一次咨询直到答复，并找到所有仍在等待处理的请求。用正常预订和只剩一个名额的情况，讨论完成的软件必须展示什么。

你还可以记录一个想衡量的现有问题，例如员工为寻找尚未回复的咨询，需要在多个工具之间查找的频率。说明你已经观察到了什么，还有什么需要核实。先确定比较基准，再商定目标。

把需求说明发给实际做这项工作的人看，再交给开发人员。他们可能指出遗漏的步骤，或解释某条看似省事的捷径会造成什么麻烦。把未解决的问题留在文档中，并为每个问题指定回答的人。

我们开发定制商业软件。如果你想和我们讨论项目，可以带上这样一项工作：现在怎样做、想改变什么、一个具体例子，以及仍有哪些问题。然后可以围绕实际工作讨论范围和商业条款。需求说明只是谈话的起点，技术调研和设计仍需继续。

关于准备软件需求说明的常见问题