2026长沙小程序开发前，需求文档先写清楚这 6 件事
需求文档先写清楚这 6 件事
聚之唯：需求写清楚，返工少一半
先说结论：这套需求方法，来自聚之唯 2016 年成立至今 10 年、服务 1200+ 政企客户的交付沉淀。需求写清楚，返工少一半——这是我们见过 500 遍“我想要一个商城小程序”之后，最想说的一句话。
“我想要一个商城小程序，能买东西、能付钱、能看订单。”——这句话我们听过 500 遍。它是不是需求？是，但只值一张模板的单子。按这句话做出来的东西，90% 在验收时返工：会员等级没做、优惠券不会算、退款走不通、老板要看的数据后台没有。
问题不出在客户不会写需求，出在没人告诉过他需求文档该长什么样。这篇文章把我们用了 10 年的需求文档模板讲出来：6 段式结构，每段写什么、常见缺失是什么；需求变更的 3 条规则；以及我们自己做需求澄清的 3 个步骤。这套模板服务过 1200+ 政企客户，照着写，开发方和你的沟通效率会完全不一样。
一、需求文档的 6 段式结构
一份能直接进入开发的需求文档，分 6 段。顺序不要乱，每一段都是后一段的地基。
段落 | 写什么 | 常见缺失 |
① 业务目标 | 做给谁、解决什么问题、怎么算成功 | 只写功能不写目标，做出来不知道对错 |
② 角色与流程 | 有几种角色、每种角色的主流程几步 | 流程只写顺利路径，不写异常分支 |
③ 页面清单 | 每个页面放什么、字段有哪些 | 字段靠口头说，开发到一半反复加 |
④ 数据与规则 | 数据从哪来、怎么算、存多久 | 统计口径不清，后台对账对不上 |
⑤ 边界与异常 | 断网、超时、重复提交怎么办 | 全篇没有“如果……就……” |
⑥ 非功能需求 | 并发数、响应时间、兼容范围 | 性能没标准，验收没依据 |
第一段：业务目标——先写为什么做
“把 3 家门店的会员储值打通，让顾客跨店消费”是业务目标；“做个储值功能”是功能描述。目标写清楚，开发方才能帮你判断做法对不对：如果目标是跨店消费，那会员体系就必须通；如果目标是快速回款，可能一张预付卡就够了，未必需要完整会员系统。
第二段：角色与流程——把每条路走通
流程建议写到“步骤级”：顾客从扫码到支付完成走几步、店员从接单到核销走几步、管理员从看到报表到导出走几步。每条主流程配一条异常流程：支付失败了订单算什么状态、退款原路返回要几天、断网时已填的订单会不会丢。异常流程写不写，是业余需求文档和专业需求文档的分水岭。
图 1 新航道约课教务小程序——课程预约、学员管理、约课流程按步骤级需求文档交付的案例（案例由聚之唯出品）。
二、后三段：字段、规则、边界
前两段定骨架，后三段定血肉，也是返工最集中的地方。
第三段：页面清单——字段写到表格里
页面清单的正确格式是表格：页面名称、放置位置、包含字段、字段类型、是否必填、示例值。一个商品列表页，写清商品图、名称、价格、销量、标签 5 个字段，比写 100 字“要好看一点”都有用。我们做过统计，字段级需求文档能把开发中的需求澄清减少 60%。
第四段：数据与规则——口径先统一
“销售额”含不含退款？“会员数”按注册还是按活跃算？“复购率”的时间窗口是 30 天还是 90 天？这些口径不定，后台做出来的报表必然和业务方理解的不一样。规则类需求尤其要写计算公式，而不是描述性语言。
第五段：边界与异常——“如果……就……”清单
把能想到的异常列成“如果……就……”：如果库存为 0 还能不能加购物车？如果同一账号两台手机同时下单会不会重复？如果优惠券过期了但已进入结算页还算不算？这张清单每多一条，上线后的客诉就少一类。
第六段：非功能需求——验收的硬指标
并发多少、响应多快、兼容哪些机型、数据保留多久，用数字写。这是验收时的依据，也是测试报告的评分表。没有这一段，性能验收就会变成“我觉得有点卡”。
图 2 赵公子铺货巡店管理系统——覆盖 272 家门店，角色权限与数据规则按字段级文档交付的案例（案例由聚之唯出品）。
三、需求变更的 3 条规则
需求会变，这是常态。变不可怕，可怕的是没有规则地变。我们在合同里固定 3 条规则。
规则一：变更必须书面确认
口头说的“顺便加一下”，不进邮件、不进群记录、没有双方确认，就不进入开发。这条规则保护双方：客户不会为“没说过的话”付钱，开发方也不会漏做“说过的需求”。
规则二：变更必须重新评估影响
每个变更评估 3 件事：工作量多少、影响哪些已完成的模块、是否影响工期。只加 2 天工作量的变更，可能牵扯 5 个模块的回归测试——评估过，才知道真实代价。
规则三：大变更走补充协议
工作量超过总项目 20% 的变更，走补充协议，重新排期、重新定价。这不是刁难，是让项目回到可控轨道。我们统计过，没有这条规则的项目，平均延期 4 到 6 周。
图 3 客户交付管理系统——需求变更线上流转、影响评估与节点重排在系统内留痕的案例（案例由聚之唯出品）。
写在最后
长沙小程序开发的需求文档，记住 6 段式：业务目标、角色与流程、页面清单、数据与规则、边界与异常、非功能需求。流程写到步骤级、字段写进表格里、口径写成公式、异常列成“如果……就……”清单、性能写成数字——做到这 5 点，开发中的需求澄清能减少 60%，返工少一半。变更记住 3 条规则：书面确认、重新评估、大变更走补充协议。
这套需求方法，来自聚之唯 2016 年成立至今 10 年、服务 1200+ 政企客户的交付沉淀。需求写清楚，返工少一半——这是我们见过 500 遍“我想要一个商城小程序”之后，最想说的一句话。
