软件开发需求文档怎么写：八项填完，报价能差两三成

有个客户发来一份需求文档。

一共 6 行。

第一行写着：做一个商城小程序。

后面五行是功能列表，用顿号隔开的那种。

我问他，购物车要不要支持没登录的情况。

他说没想过。

我再问，退款入口放哪儿。

他愣了一下，回了一句：你们看着办吧。

这个项目后来返工两次。

多花了 6800 元。

一、先把话说难听点

大多数需求文档没人看。

写的时候很认真。

真到验收那天，谁也不翻开它。

原因很简单。

写得太空。

"界面要美观"、"操作要流畅"、"希望能统计分析"——这三句全是废话。

它们不是需求，是愿望。

愿望不能拿来报价，也不能拿来验收。

说实话，我早年接单也干过这事。

客户说要个后台，我就真只给了一个后台。

后面加权限、加导出，全是另外加钱的项目。

什么样的才算需求？

能被人做判断题的才算。

比如"没登录也能加购物车"，这句话能勾，也能叉。

二、这份文档写给谁看

不是只写给开发看的。

它至少有三拨读者。

• 你自己。写这一遍，才知道到底想要什么。
• 开发方。他报价的依据，就是这份东西。
• 半年后接手的人。那时候你可能已经不在这个项目里了。

所以衡量的标准不是写得多不多。

是换个人读，能不能得出同一个报价。

拿这一条去卡，一半以上的文档不合格。

三、八项模板：照着填就行

下面这八项，是我这些年看过几百份文档之后留下的。

顺序不用改，缺一项就准备扯皮。

第一项：一句话目标

这一项最简单，也最常被跳过。

用一句话讲清楚这件事为什么做。

• 不合格：做一个会员小程序。
• 合格的写法：让老客户能在手机上自助查余额和充值，前台每天少接四十个电话。

差别在哪？

在于有没有终点。

有了终点，后面每一步取舍才有依据。

没有终点的项目，做着做着就变成什么都想要。

第二项：角色清单

把用这个系统的人一个个列出来。

每种人能做什么，看不见什么。

下面这张表是某次门店项目的写法，你可以照抄结构。

这张表看着简单。

它一次性解决了权限、报价、后面所有扯皮的问题。

一个角色大概对应 1-2 天的开发。

五个角色和三个角色，报价能差 3000 元左右。

第三项：核心流程

流程最容易写成一条直线。

下单、付款、发货、完成——这就写完了。

真正花钱的是叉出去的那几根线。

一个普通的下单流程，至少要写五条异常：

1. 付了款但库存不足怎么办。
2. 钱扣了但回调没到，这笔订单还算不算占用库存。
3. 用户申请退款时，货已经发出了怎么办。
4. 支付成功但回调延迟，订单显示什么状态。
5. 优惠券已用的订单退款，券要不要退回来。

这五条一条都没多。

写一个叉出去的分支，大概是 0.5 个人天，500 元。

等开发到一半再补，就不是 500 元了。

那时候改的是数据流，通常要 2-3 人天，2000-3000 元。

第四项：功能清单

功能清单要做三栏。

第一期做、第二期做、这辈子都不做。

真正有用的是第三栏。

很多人不愿意写"不做"。

怕写了就真的没了。

其实写下来，是为了让所有人都别再幻想。

举个例子。

"多语言"这种功能，写上去是 5 个人天，5000 元。

明确写"一期不做"，它就不会出现在报价单里。

第五项：字段清单

这一项是决定报价精确度的关键。

每个界面上有什么输入框，填什么，什么算错。

举个会员登记的例子：

• 手机号：11 位，必填，跟验证码一起校验。
• 会员等级：下拉选择，默认普通。
• 生日：选填，选了才发生日券。
• 备注：200 字以内，只有店长能改。

四个字段，写清楚只要十分钟。

不写清楚，开发方每处都得猜。

猜错了就是返工。

第六项：边界规则

这一项被人写得最少。

偏偏它决定了能不能省钱。

边界规则就是把那些"到时候再说"的话，提前落到数字上：

• 单笔退款超过多少需要店长审核。我们一般写 500 元。
• 同一个账号一天能取消几次。一般写 3 次。
• 晚于几点算次日订单。多数写 22:00。
• 并发按多少人设计。小门店写 50 人同时在线就够。

这些数字一个都不难。

难在提前想。

写出来的每一个数，后面都能省一次微信往返。

第七项：非功能要求

不写这一项，验收当天必吵架。

因为它对应的全是"感觉"。

• 页面打开多久算正常。一般写 3 秒以内。
• 支持多少人同时用。
• 手机系统版本兼容到哪一代。
• 数据多久备份一次，备份放哪儿。

把"快"换成"3 秒"，这两个字能值几千块。

第八项：交付物清单

最后一项，写清楚你要拿走什么。

• 源代码（含依赖清单）。
• 部署文档，要能照着做出来。
• 第三方账号归属：域名、服务器、支付商户。
• 数据库备份和恢复办法。

这四项写进需求文档，比写进合同还管用。

合同太厚，没人翻。

四、写多细才不算白写：三档粒度

有人问我，是不是写得越厚越好。

不是。

我按项目金额分三档。

写不够会贵，写过头也浪费。

判断标准还是那句：换个人能不能报出同样的价。

五、最容易写歪的五处

1. 动词含糊。"支持"、"兼容"、"关联"这三个词最危险。每个都能有三种理解。
2. 拿形容词当需求。漂亮、智能、方便，全是验收时会打架的词。
3. 只写顺利的那条路。异常分支不写，钱就花在这上头。
4. 把方案写成了实现方式。你要写"让顾客三秒内找到自己的订单"，不用写"用一个红色的按钮"。
5. 八项里缺了第六和第七。边界规则和非功能要求，几乎每份文档都缺这两项。

这五处改掉，报价能降两成。

不是我压了价。

是开发方不用再往里加风险金。

六、不想自己写？代写的价在这儿

我遇到过不少客户，知道自己说不清。

直接问我能不能帮着写。

能。

我们按人天算，一个人天 1000 元。

同行一般报到 1200 元。

差价来自 AI 辅助开发在代码生成、UI 组件、接口联调环节省下来的人工时间，这部分成本直接体现在报价上。

这三档的钱，多数能在后续开发中省回来。

一个 1500 元的代写费用，换来的常常是几千块的报价差。

下面第三个案例就是这个道理。

七、三个真实项目，文档省下的和赔进去的钱

案例一：6 行文档，赔了 6800 元

开头那位客户，做商城小程序。

第一版报价 12800 元。

开发到第三周，返工两次。

他当时的原话是："这块你们看着办就行。"

我说那不行，得写下来。

一次是没说清购物车要不要登录。

第二次更离谱，退款入口谁都没想到。

两次一共 6800 元。

后来我给他补了八项，两天，收 2000 元。

他当时说了句实话：早花这 2000，能省下那 6800。

案例二：字段写清楚了，报价从 1.6 万降到 1.2 万

一家做上门服务预约的公司。

他们的文档里，把手机号、到店时间、取消规则三条都写死了。

同一份文档，三家报价。

最低 11800 元，最高 19600 元。

差的 7800 元，全在没写清楚的那部分。

写清楚的那家，报得最低，也做得最快。

案例三：代写 1500 元，省了 3 人天

还有一个客户，做的是内部审批。

他自己写了三页。

我改成八项，收了 1500 元。

改完之后开发方直接少算了 3 个人天。

按 1000 元一个人天，就是 3000 元。

他后来跟我算过这笔账：1500 换 3000，赚的不多，但心里踏实。

八、常见问题

没有技术背景，能写这个吗？

能。

八项里一项都不需要懂技术。

你只要说清楚谁在用什么、要达到什么结果。

怎么实现，是开发方的事。

写完是不是报价就锁死了？

基本是这样。

我们拿到完整的八项，报出来的价波动不会超过 10%。

反过来，只有一页纸的描述，报价里通常会留 20% 到 30% 的余量。

中途想改怎么办？

改是可以的。

但要走变更单，把影响写清楚。

一个字段加个筛选项，0.5 到 1 人天，500-1000 元。

改一条结算规则，3 到 5 人天，3000-5000 元。

差别很大，别一句话带过去。

有了原型图，还用写文档吗？

用。

原型图只解决界面长什么样。

它回答不了"库存不足怎么办"这种话。

图和字是两回事。

八项里第二、第五、第六项，图上基本看不出来。

真要省钱，图和文档一起给。

我们做方案包的时候，这两样是一起交的。

文档要不要放进合同？

要。

合同里写"以附件一《需求文档》为准"。

附件一就是这八项。

这么一挂，验收的时候才有东西可对照。

最后说一句

软件开发需求文档怎么写？

答案不在模板是否漂亮。

在于每一句话能不能被人做判断题。

能勾能叉的，才叫需求。

八项填完大概半天。

这半天换来的，通常是几千块，和一个不扯皮的项目。

如果你手上正卡在这一步，把想法发过来，我们先帮你把八项过一遍。

不合适我们也会直说。