把需求写成规格：输入、输出、约束与验收标准四要素详解

干需求分析这些年，我最大的体会是：大多数项目烂尾，真不是代码写得烂，而是需求从来就没被写清楚过。业务方丢过来一句“我要个工具”，开发打开IDE就开始写，测试拿到一句话需求也不知道该测什么，最后上线全靠默契。到这一篇正好是这个系列的第五篇，前面聊过不少做需求的方法，今天落到最硬核的地方：把需求写成规格。说白了就是回答四个问题——输入是什么、输出是什么、有什么约束、怎么算验收通过。这四件事搞定了，一份需求规格说明书的地基就立住了，剩下的都是往上填肉。

这篇东西适合谁看？如果你是产品、需求分析师、项目经理，或者是个常年被一句需求砸中的开发，建议认真读完。我不打算只讲理论，后面专门有一整节实操演示，从一个最普通的例子“输入日期算第几天”出发，一步一步从一句话需求写成完整规格，模板可以直接拿走改着用。

1. 先搞清楚：什么是“规格”，为什么非写不可

1.1 一句话需求、需求描述和规格，三者差多远

业务方每天抛出来的，几乎全是一句话需求。“后台加个导出”“写个程序输入日期就算第几天”“做一个弹窗，用户确认完再走”。这种需求不是不能做，但它只说了“想要什么”，没说“做到什么程度”。开发为了开工只能自己猜：导出什么格式？按什么条件导？数据量多大？日期怎么输入？闰年怎么处理？每一个猜错的地方，后面都是一轮返工加扯皮。

从我的经验看，需求从一句话变成能落地的规格，至少要穿过三层：

• 第一层，一句话需求：口头描述，方向是对的，其余全缺。
• 第二层，需求描述：把场景和用户讲清楚了。比如“运营每月1号要从后台导出上个月的订单明细用来对账”，这就比一句话强不少。
• 第三层，规格：把上面那句人话拆成可验证的条款——输入包含哪些字段、输出文件用什么格式、数据量上限多少、导出耗时多久、验收时怎么判断通过。

很多团队卡在第二层就不肯往下走，觉得“我已经写清楚了呀”。但“写清楚”和“可执行”之间还隔着一层规格的距离。判断标准很简单：一份文档看完，开发能不能直接开始编码？测试能不能顺手列出测试点？如果都不能，那它只是会议纪要，不是规格。

1.2 为什么偏偏是“输入、输出、约束、验收标准”这四个要素

有人可能会问，拆成这四个要素是不是太机械了？我自己的理解是，这四个词正好对应一个可计算系统的全部边界。任何一段逻辑，本质上都是一个函数：在给定约束下，把输入映射成输出，最后用验收标准判断映射得对不对。

• 输入回答“程序吃什么”，输出回答“程序吐什么”，约束回答“什么绝对不能做”，验收标准回答“怎么才算做好”。

需求侧的任何一条要求，都能归到这四类里，几乎不会遗漏。反过来，如果这四个问题都明明白白，系统边界就彻底清晰了。开发写的代码、测试写的用例、业务方签字确认，看的是同一组条款，不再各说各话。

这个思路其实不是软件行业的发明。如果你接触过FPGA开发，对“约束”这个词会特别亲切——XDC约束文件里密密麻麻全是约束，把每根引脚的时序、位置、电平标准定得死死的，工具照着约束做布局布线就行。硬件工程师用约束文件描述“必须满足的条件”，我们做软件的人用“约束”和“验收标准”描述“必须满足的底线”，底层逻辑完全一致。

1.3 没有规格的“改一下”，是怎么拖垮项目的

说一个我真实带过的项目片段。当时要做一个查询工具，业务方扔过来一句话：“用户在页面输入VIN码，能查到车型信息。”开发很快就做了一版，界面能输入18位VIN，查到了就显示车型配置。看着没问题吧？

结果上线前测试问了三个问题：VIN码里字母O和数字0怎么区分？查不到的VIN码提示什么？一天能查多少笔，有没有限流？业务方当场愣住，开发也愣住——这三个问题谁都没定义过。于是现场开会，先补了校验规则（VIN码本来就不含字母I、O、Q，直接拦截非法字符），再定了查不到时的提示文案，最后找运维确认了接口的调用上限。那次是运气好，三个人恰好在场，半天定了。如果业务方不在，这个功能就要带着“未知行为”上线，跑出问题再返工。

这类事在任何团队都在反复发生。它不是“不会做”，而是没人把“要做什么、边界在哪、怎么算好”提前落到文字上。规格的意义就在这里：把不确定性挡在需求阶段，别让不确定性留到上线阶段再爆炸。

2. 四要素逐个拆解：输入、输出、约束、验收标准

2.1 输入：把边界问清楚，bug就少一半

先讲输入。我检查规格写得好不好有个笨办法：只看“输入”一节回答了多少个问题。输入部分至少要回答：数据从哪来、什么格式、取值范围、最大最小、能不能为空、能不能重复、非法值怎么办。

举一个极简例子。“写一个函数，输入字符串，输出逆序后的字符串”——这话听着够简单吧？但输入侧的问题一串一串的：字符串用什么编码，UTF-8还是ASCII？最长是多少，100字符还是100K？中间有空格怎么处理，整体逆序还是每个词内部逆序？空字符串返回什么？NULL呢？如果输入含emoji，按字符逆序还是按字节逆序？这些问题不定义，开发写出来的代码一定是不完整的。很多人搜“字符串逆序C语言”找到个能跑的demo，往上套就完了，其实输入边界才是区分demo和生产代码的关键。

再比如单片机场景的“输入捕获测频率”，输入信号是什么电平、什么幅值、最小脉宽多少、用哪个定时器通道，全都要在规格里写死。硬件工程师按自己的理解接了线，测出来频率偏了，你都不知道是程序问题还是输入信号本身的问题。

我把输入侧要问的问题整理成了一张表，写规格时对照着过一遍：

输入也是bug重灾区。如果你统计过自己调试时花的时间，会发现相当大比例是在处理边界输入——空串、0、负数、超长字符串、不可见字符。在规格阶段把输入的边界列清楚，等于在coding之前就消灭一大批运行期才会暴露的问题。输入写得多细，开发的底气就有多足，这话一点都不夸张。

2.2 输出：结果必须可观察、可断言

输出这部分，核心只有一个要求：输出结果要让测试能直接断言。所谓断言，就是拿实际结果和预期结果做比较，比得上就过，比不上就挂。如果输出五花八门、还带随机变化，测试就没法写了。

回到日期例子。需求说“输入日期，输出它是当年第几天”。那输出到底长什么样？只打印一个数字60，还是打印“2025年3月1日是2025年的第60天”？是输出一行还是多行？如果后续要支持批量输入，每条输出占一行还是用分隔符？这些细节决定了测试用例怎么写，也决定了调用方怎么解析结果。

规格里的输出，要定义四件事：内容（输出哪些信息）、格式（文本、JSON、CSV、还是纯数字）、精度（小数几位、怎么进位）、时机（实时输出还是攒批输出）。技术圈里天天有人搜“printf怎么输出4位小数”、“C++指定顺序输出”、“格式化输出时类型转换”，全是在和输出格式较劲。如果产出规格时就提前把格式锁死，这些麻烦能省掉一半。

还有一类输出最容易漏：错误输出。程序正确运行时的输出大家都会写，但出错时的输出呢？输入日期非法，是提示“日期格式错误，请重新输入”还是直接崩溃？错误信息是给人读的还是给程序解析的？把异常路径的输出提前定义了，开发和测试才不会各猜各的。

2.3 约束：不只是限制，更是护城河

约束是四要素里最容易被跳过的，因为人写需求时天然习惯描述“要什么”，不习惯写“不要什么”。但恰恰是空白地带，最让后面的人头疼。约束定了系统的可行域，它同时也是护城河。

一条合格的约束，要同时满足三点：明确、可测、可追溯。比如“单次导出最多支持10万行”，明确且可以测试；“导出速度要快”，不合格——什么叫快？没人能测。“手机号不得明文展示在页面上”，合格，因为可以逐条检查页面和数据库。

约束还分层次。我一般按四类来写：

• 功能约束：哪些功能明确不做。比如“本系统不做自动退款，只生成退款单”。
• 性能约束：响应时间、吞吐量、并发数、数据量上限。比如“在200并发以内，95%的接口响应小于500ms”。
• 资源约束：内存、磁盘、带宽限制。嵌入式项目常写“运行时内存不超过32KB”。
• 合规约束：数据存在哪、存多久、是否脱敏、谁能看。

写性能约束的时候要特别小心，必须带条件。“性能要好”不是约束，“界面响应要快”也不是。完整写法是“在测试环境用JMeter压1000个并发用户，持续10分钟，P95响应时间小于300ms且无超时错误”——这叫约束。

生活里我常拿盖房子打比方：需求告诉你“我要一间厨房”，这是要什么；约束告诉你“这堵承重墙不能砸，下水管只能走这边”，这是不能做什么。两者加在一起，厨房最终才长成该有的样子。只写要什么，不写不能做什么，开发就会在灰色地带反复试探，最后盖出一个你都不认识的厨房。

2.4 验收标准：把“做得好”变成可勾选的清单

验收标准是整个规格的出口。前面的输入、输出、约束写得再好，没有验收标准，项目结束的那一刻就是一笔糊涂账。

我习惯把验收标准写成一组可执行的用例，每条都是明确的“当……则……”。日期计算这件小事，验收标准长这样：

写验收标准的过程，其实就是在把模糊的“做个日期工具”翻译成一条条可勾选的清单。测试照这张表生成用例，开发照这张表自测，评审的时候大家对着表一条条过。没有这张表，验收靠什么？只能靠“我觉得差不多行了”。

还有对照可以帮你自检：把模糊说法和明确说法放在一起看，一眼就知道哪个能用。

3. 实操演示：从一句话需求到一份完整规格

3.1 第一轮提问：把没说的边界全部问出来

进入实操环节，我们从零走一遍。假设业务方丢来一句原话：“写个程序，输入日期，算出来这是当年的第几天。”就这一句，没了。

注意，这不是一个完整需求，这只是一个起点。我们接下来要做的事情，是通过一轮又一轮提问，把这句话变成一份完整规格。第一轮大概要问这些：

1. 日期怎么输入？键盘交互式输入、命令行参数、还是函数参数被别的程序调用？
2. 输入格式是什么？三个整数“2025 3 1”？还是字符串“2025-03-01”？
3. 年份范围有要求吗？只支持1900到2100，还是任意正整数？
4. 闰年按什么规则？是按公历标准格里高利历吗？“四年一闰、百年不闰、四百年再闰”？
5. 输出什么内容？只给数字，还是带日期的完整描述？
6. 非法日期怎么办（比如2月30日）？直接报错退出，还是提示后继续？
7. 一次只处理一个日期，还是要能连续处理多组？

这七个问题，就是四要素框架的具体化。把答案拿齐，规格就能动笔了。

我特别想说清楚这轮提问的意义：需求沟通不是“听懂了就动手”，而是“听懂之后还要把没说的边界全部问出来”。业务方不会主动告诉你“年份别超过9999”这种问题，但你不问，开发就敢把年份填成10000，程序就炸了。提问是需求人的本职工作，不是多此一举。

3.2 输入侧定稿：把答案锁进规格

假设业务方这样回答：日期通过命令行参数输入，格式为三个整数，依次是年、月、日。年份限定1900到2100。希望支持多组日期，逐个处理。

那么输入部分就可以这么写：

• 输入来源：命令行参数，支持一次传入多组日期，每组三个整数，依次为年、月、日。
• 输入格式：年月日均为整数，例如2025 3 1。
• 取值范围：年∈[1900, 2100]；月∈[1, 12]；日根据公历规则校验，例如2月为1-28（平年）或1-29（闰年），4月为1-30等。
• 闰年规则：格里高利历标准，即“四年一闰、百年不闰、四百年再闰”。
• 非法输入行为：任何超范围输入判为非法日期，输出错误提示后继续处理下一组，不中断整个程序。

这里面没有一句废话，每一句都在告诉开发“边界在哪里”。最后一条尤其关键，它提前锁死了程序的容错行为，而不是让开发自己拍板选退出还是跳过。合法的边界写清楚了，不合法的行为也写清楚了，输入侧就没有留白。

顺带解释一个小细节：为什么年份定1900到2100，而不是“任意年份”或者“1900到9999”？因为1900正好是能被4整除但被100整除的年份，是闰年规则的边界情况；2100同理。把边界年份纳入合法区间，等于强制开发处理“百年不闰”的逻辑，测试也自然会有对应的边界用例。定范围的时候刻意往边界上靠，是写规格的人给自己留的伏笔。

3.3 输出侧与约束定稿：格式和限制一起锁死

接下来是输出侧：

• 正常输出：对每组合法输入输出一行，格式为“YYYY年M月D日是当年的第N天”，例如“2025年3月1日是2025年的第60天”。
• 异常输出：对每组非法输入输出一行，格式为“输入日期无效：YYYY-MM-DD，请输入1900-2100年间的真实日期”。
• 输出载体：标准输出（控制台）。

约束部分也一并定掉：

• 功能约束：仅支持公历日期，不做农历换算；仅计算“当年第几天”，不输出星期等附加信息。
• 性能约束：单个日期计算耗时不超过100ms（普通办公电脑）。
• 资源约束：无特殊要求，但程序必须在无额外运行时依赖的桌面环境下直接运行。

你可能觉得“单个日期低于100ms”这种约束有点小题大做，但这就是规格的习惯：宁可写一个保守数值，也别留空白。留白意味着开发不知道做到什么程度算合格，测试也没有基准去验证。

开发拿到规格后可以这样实现，这里给一段参考C代码，注意这段代码不属于规格，它只是开发根据规格写出来的一种实现方案：

#include <stdio.h> int is_leap(int year) { // 四年一闰，百年不闰，四百年再闰 return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); } int day_of_year(int year, int month, int day) { static const int mdays[] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; int days = day; for (int m = 0; m < month - 1; m++) { days += mdays[m]; } if (month > 2 && is_leap(year)) { days += 1; } return days; } int main(void) { int y, m, d; // 按规格循环读取多组参数，逐组处理 // 合法性校验逻辑按规格中的取值范围执行 return 0; }

如果你已经接触过“输入一个日期的年、月、日，计算并输出这天是该年的第几天”这类练习，会发现这段实现很眼熟。关键是：规格约束的是行为，不是代码本身。开发可以换成查表法、公式法、甚至写成一行表达式，只要结果对、性能达标、异常行为一致，都算合格。把行为以规格方式锁死，把实现留给开发，这是需求人和开发之间最舒服的合作距离。

3.4 落成验收用例，附一份可以直接抄的模板

验收用例前面已经示范过一张表了，这里不再重复。但我要补一个点：约束也要能变成验收项。性能约束对应“对一组100组日期做批量计算，整体耗时小于10秒”；合规约束对应“程序不访问网络，不向任何外部接口发送数据”。每一类约束都能找到对应的验收动作，找不到的约束就是废话，趁早删掉。

到这里，一份完整的规格已经成型。开发照着写代码，测试照着列用例，业务方照着确认签字，这就是“把需求写成规格”的全部意义。

最后给一份我用了很久的通用模板，结构稳，不容易漏项，你可以直接复制：

# [功能名] 需求规格说明书 ## 1. 背景与目标 一句话说明：为什么做这个功能，解决什么问题。 ## 2. 输入 - 来源： - 格式： - 取值范围： - 合法性判定规则： - 非法输入行为： ## 3. 输出 - 正常输出内容与格式： - 异常输出内容与格式： - 输出时机： - 输出载体： ## 4. 约束 - 功能约束： - 性能约束： - 资源约束： - 合规约束： ## 5. 验收标准 - [ ] AC-01：…… - [ ] AC-02：…… ## 6. 变更记录 - 版本、日期、修改人、修改内容

把这套模板发给任何一个开发，他的第一反应往往是“这个能用”。因为他不缺技术，缺的是一个不用反复瞎猜的需求环境。

4. 写规格最容易踩的五个坑

4.1 把实现方案写进规格

新手最容易犯的错，是在规格里写“用整型数组存储每月天数，用for循环累加”。问题在于：你把开发怎么做写了进去，却没规定做成什么样。开发本来可以设计更优雅的实现，但你一句话把路堵死了。

正确写法是约束行为而不是约束实现：“计算结果应符合格里高利历闰年规则”。至于开发是用查表、公式、还是循环，那是他的自由，只要结果对、性能达标，都算合格。规格管“什么”和“做到什么程度”，实现是开发的地盘，越界即犯规。

4.2 只说正常情况，不提异常

我看过太多规格，输入输出写得漂漂亮亮，翻到异常部分一片空白。当你发现自己写的规格没有任何异常处理条款时，基本可以断定它离“能上线”还差一半。

破解办法很粗暴：写完正常逻辑后，强制自己列出至少三种非法输入，并为每一种补上期望行为。日期工具写“2月30日”“月份13”“年份2101”三条就够了。多问自己一句“如果这里传来一个垃圾数据”，规格的完整度立刻上一个台阶。

4.3 用模糊词汇

“方便”“大概”“尽量”“比较好”“界面美观”“响应迅速”——看到这些词就该警惕，这不是规格，这是愿望清单。

规格的语言只有两种：命令式（必须、不得）和条件式（当……时……）。把每一个模糊词替换成具体数值或具体描述。“界面美观”可以变成“按钮间距不低于8px，文字不小于14号，页面整体采用品牌规范配色”，至少这条是可判断的。

4.4 验收标准不可测

“程序运行正常”不可测，什么叫正常？“功能符合业务要求”不可测，什么要求？“用户觉得好用”更不可测。

验收标准的本质是一组带期望值的断言：输入什么、做什么、得到什么。每一条都改成“当输入X时，程序输出Y，且耗时小于Z”的形式，立刻从愿望变成可执行。写验收标准的时候，脑子里要浮现一台模拟的测试机器：它能验证这一条吗？不能就改写。

4.5 需求变了，规格不更新

这个坑比前四个都要命。需求变更是常态，最怕的是开发对着旧规格写新功能，测试照着旧规格列用例，最后上线时新代码跑着，旧文档也摆着，谁都不知道谁是对的。

我的习惯是规格文档里永远保留“变更记录”一节，任何一次变更都留下一行：改了什么、谁改的、什么时候改的、为什么改。出问题的时候顺着记录追溯，三步之内就能定位到决策人。规格是活的文档，不是写完一版就供起来的牌位。这句话在做需求的人嘴里值得反复说。

5. 同一份规格，不同人看到的重点不一样

5.1 开发要的是“不用猜”

开发拿到规格，第一诉求是：看完就能写代码。最能打动开发的规格，是输入输出边界极清楚、异常行为有约定、性能指标有数值。

开发最恨的规格是“情况我都说明白了，细节你看着办”。这不叫规格，叫甩锅。反过来，如果一份规格能让开发收到之后的第一小时里不追着业务方跑，那就是一份好规格。我衡量规格品质有个简单标准：开发拿到后第一件事是开始敲代码，还是拨电话问你问题——前者是规格该有的样子，后者说明还得改。

5.2 测试要的是“能断言”

测试的命根子是断言。所以给测试看规格，重点看验收标准是否每条都可执行。测试会把“当输入X时输出Y”的验收用例直接转化成自动化脚本，只有格式统一、预期明确，这个转化才顺畅。

我认识的成熟测试，最怕的不是bug，而是需求文档里没有一条可执行的验收标准，只能靠业务方凭感觉验收。凭感觉验收的项目，最后往往就是扯皮现场。

5.3 业务方要的是“看得懂”

业务方不关心实现，也不关心字段格式，只关心这功能能不能解决他的问题。所以摆在业务方面前的，应该是背景与目标、典型使用场景、几个直观的输入输出示例。

我的做法是在规格开头写一小段“人话版”，把整个功能用三句话讲完，业务方看完点头了，后面那些条条款款他就不抵触了。写规格的人要习惯“一个文档两套语言”：业务方看开头那段人和示例，开发测试看条条款款，放在同一份文档里互不干扰。

我个人写了这么多年规格，踩坑又爬坑之后最深的一个体会是：输入、输出、约束、验收标准这个框架，看起来像四个待填的空格，实际上是一套逼你把话说清楚的武器。每次想偷懒省略细节的时候，就想想当初那个因为没有规格而在上线前集体开会的下午。保持这个习惯，你的项目会少吵很多架，多产出一批真正能直接上线的功能。