需求规格说明书的价值，恰恰在于它排除了什么
在我们的流程里，需求规格说明书（Statement of Work）位于需求澄清和工作量评估之间。名义上，它是一份说明"要做什么"的文件。但实际上，决定它价值的是另一个部分——不包含范围清单（out-of-scope list），也就是明确写出"不做什么"的那一段。
差别在客户提出"顺手加一点"的那一刻显现出来。如果说明书只写了包含的内容，任何请求看起来都像是在已定范围内的一次澄清。如果有一份不包含范围清单，同样的请求会立刻被识别为范围边界（scope boundary）的变更——接下来讨论的是工期和价格，而不是你是否够"通融"。
需求规格说明书是管理预期的工具，不是方案说明书。它真正起作用的部分是不包含范围清单，因为它把未来的一次"顺口澄清"变成了一项独立的决策，而不是免费追加。需求波动性（requirements volatility）的数据显示，范围变更与工期、预算超支之间存在统计显著的关联；关于歧义（ambiguity）的研究则表明，文档写得再正式，本身也无法杜绝理解偏差。
不包含范围清单到底解决了什么问题
把它的作用拆开来看，一共四项，没有一项与技术方案本身有关。
把澄清变成决策。只要边界没有划定，每一个请求都会被当作关系问题来讨论：是否要给这个面子。边界一旦划定，讨论的就是范围问题：算进当前阶段还是下一阶段，给多长工期，按什么条件。
保护双方，而不是只保护一方。客户能清楚知道自己没有为什么付钱、拿不到什么——这往往比"包含清单"更重要。有一种常见的误解，认为不包含范围清单只对乙方有利：事实恰恰相反，没有它，客户往往是在验收之后才发现缺了什么。
让工作量评估真正有意义。只有边界清晰的范围才能被评估。不包含范围清单正是这个边界，评估的数字正是相对于它才成立；没有这个边界，评估就会退化成谈判中的一句筹码，而不是流程中的一个环节。
在开工前暴露双方认知的差异。这是它最有价值的功能。客户读不包含范围清单，会比读工作内容描述读得更仔细——因为那里写的是他们拿不到什么。正是在这次阅读中，那些原本要到验收时才会暴露的分歧被提前发现了。
| 说明书章节 | 谁会认真读 | 什么时候起作用 |
|---|---|---|
| 方案描述 | 乙方 | 开发过程中 |
| 工作范围清单 | 双方，在确认阶段 | 评估阶段 |
| 不包含范围清单 | 甲方 | 首次澄清时和验收时 |
| 验收标准（acceptance criteria） | 双方，收尾阶段 | 交付时 |
第二列解释了一个常见的失衡：文档是乙方写的，也是写给乙方自己看的，所以方案那一节往往写得很详细，而排除条款那一节却很简短，甚至干脆没有。可恰恰是第二节，决定了接下来三个月的走向。
需求波动性真正的代价有多大
需求变更与项目结果之间的关联已经被量化过，这些数字值得在你答应"顺手加一点"之前先了解一下。
需求波动性与工期、预算超支之间存在统计显著的关联。样本中只有14%的项目按期或提前完成且未超预算；大多数项目工期超出25–50%，预算超出4–25%。
这项研究的局限性是真实存在的：它是问卷调查，不是受控实验；21%的回收率带来了偏向"问题项目"受访者的风险；而且这项研究已经有二十多年历史。我把它当作一种持续存在的关联的证据，而不是当作硬性标准来引用。但其背后的机制并没有过时：范围变更却不重新核定工期和价格，本质上就是把风险转嫁给了乙方，而这正是统计数据所捕捉到的东西。
为什么文档写得再正式也挡不住歧义
第二个常见的误解是：说明书写得越正式、越详细，理解偏差就越少。实验验证给出的是相反的答案。
三位审查者花4.5小时对一份需求文档进行审查，共发现58处歧义：其中4处纯属语言表达问题，54处是需求工程特有的问题。作者建议，应在编写正式规格说明之前、而不是之后，通过审查来发现歧义。
这项实验的规模不大——本质上是围绕单一文档展开的一组练习式案例研究，这一局限我要坦率地说清楚。但4比54这个比例本身很能说明问题：绝大多数理解偏差并非来自语言表达，而是来自内容层面的空白——那些双方都以为"不言自明"因而没有写下来的东西。不包含范围清单正好处理的就是这一层问题。
标准怎么说
国际标准ISO/IEC/IEEE 29148规范了系统与软件产品的需求工程流程。第二版，2018年发布，2024年确认维持不变。
这里需要一种在引用标准时常常缺失的诚实。标准全文是付费的，我只读过官方的摘要，其中说明了适用对象和适用范围。那份经常被引用的"好需求应具备的特征"清单——完整性、无矛盾性、可验证性——我没有核对过原文，所以不把它当作直接引用来使用。我引用这份标准只为了一件事：确认需求工程已经被视为一门独立的工程学科，有自己的标准，而不是合同的附属条款。
如何写一份不包含范围清单
第二个来源最有价值，也最容易被低估。这类项目通常会被追加要求的事项清单，是从过往经验中一点点积累出来的，它让不包含范围清单从一份形式文件变成了真正的工具：它提前预演了一场原本会在一个月之后、在更糟的条件下才发生的对话。
第三个来源消除了一整类冲突。任何依赖第三方的事项——权限、材料、审批——都必须明确写出来，并说明延误会带来什么后果。否则，第三方的延误默认会变成乙方自己的问题。
让需求规格说明书真正起作用的四条规则
先写排除项，再写包含项
从"不包含什么"入手，你反而会得到一份更精确的"包含什么"清单。
维护一份常见追加请求清单
记录这类项目通常会被追加的要求。这份清单积累一年，就能省下几个月的争论。
明确写出第三方依赖
权限、材料、审批，以及延误会带来的后果。要写明确，并附上日期。
写清楚范围变更申请（change of scope）的流程
不是禁止变更——变更是不可避免的——而是一条规则：说清楚工作量评估和工期会因此发生什么变化。
如果需求规格说明书里没有一节写明"不包含什么"，这份文档描述的只是乙方的意图，而不是项目的边界。
关于需求规格说明书，最常被问到的问题
需求规格说明书里必须写哪些内容？
四个部分：工作范围清单、不包含范围清单、带有延误后果说明的第三方依赖、以及范围变更申请的处理流程。技术方案描述固然有用，但并非必须——在项目早期，方案描述往往还有害，因为它会在需求真正被理解之前就把实现方式定死了。实际上，这份文档真正起作用的是第二部分和第四部分。
客户提出"顺手加一点"，该怎么应对？
对照不包含范围清单来核实，而不是按工作量来评估。如果这一项已经写在清单里，讨论只涉及工期和价格，五分钟就能谈完。如果清单里没有，那正好是补充清单、为以后做准备的机会——而当下这个请求，按范围变更申请的流程来处理。真正危险的不是某一个小请求本身，而是一堆小请求在没有一次正式讨论的情况下悄悄累积起来。
写得详细的需求规格说明书能避免理解偏差吗？
只能部分避免。对需求文档的实验性审查表明，发现的绝大多数歧义并非语言表达问题，而是内容层面的空白——那些双方都觉得"显而易见"因而没写清楚的东西。文档篇幅解决不了这个问题，形式化之前的审查才能解决。一个实用的做法是：找一个没有参与编写的人来读这份文档，把他提出的每一个问题都记录下来。
如果我们是按迭代方式工作，还需要需求规格说明书吗？
你需要的是它真正起作用的那一层——当前迭代的范围边界，以及范围变更申请的处理规则。在迭代式工作中，把整个项目从头到尾都写清楚确实没有意义：需求本来就会变化，而需求波动性的数据也说明这是常态，不是例外。但正因为变化更多，迭代边界和复核流程才更加重要，而不是更不重要。
需求规格说明书在流程中的位置（介于需求澄清和工作量评估之间）以及客户合作的阶段划分，来自Alego.Digital的内部协作规范。用于说明文档结构的需求规格说明书示例，来自公司的项目档案（一家咨询集团和一家工业企业的需求规格说明书，2026年）。这些属于作者所在公司的内部资料，未经独立第三方核实，仅作为说明机制的示例。维护常见追加请求累积清单这一做法，是作者本人的经验做法，在公司文档中并未正式化。
- Zowghi D., Nurmuliani N. A Study of the Impact of Requirements Volatility on Software Project Performance. APSEC, 2002. opus.lib.uts.edu.au
- Kamsties E., Berry D. M., Paech B. Detecting Ambiguities in Requirements Documents Using Inspections. WISE, 2001. cs.uwaterloo.ca
- ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. iso.org