小程序需求文档怎么写：一份可直接用的功能清单模板

昆山小程序开发的需求会上，业务方说「跟常用的商城差不多就行」，开发追了一句「储值能退吗，订单多久未支付自动关」，会议室安静了几秒。这两句话答不上来，后面就会变成两次返工：一次补一张储值流水表，一次补一个定时任务。需求说明书怎么写，其实不取决于文档多厚，而取决于有没有把「差不多」拆成能验收的条目。文档写到位，报价、开发、验收三件事用的是同一份依据。

本文要点

• 需求写到字段级才算可用，页面截图代替不了字段名、类型与校验规则
• 角色权限按「角色 × 页面 × 操作」画，导出与改价这类动作要单独授权
• 每条需求标确认人和优先级，变更走编号与影响评估，避免口头加需求

需求文档的作用

一份需求文档同时是三份东西：报价的依据、开发的依据、验收的依据。三份依据如果不是同一份文字，争议就会在交付前集中冒出来。昆山小程序开发的项目里，报价单按「模块」估、开发按「页面」做、验收按「感觉」收，是返工常见的起点。

判断标准只有一条：每个条目都要能回答「怎么算做完」。「要有会员体系」不算写完，「会员分普通与银卡两档、按累计消费自动升级、后台可手工调整、调整留操作日志」才算。前者是愿望，后者能测。

需求说明书怎么写，可以先定骨架，再往里填：版本记录、术语表、角色权限表、页面与字段清单、状态流转、异常处理、优先级、变更记录、验收口径。术语表常被跳过，代价不小——「订单」在业务口里可能指销售单，在开发口里指支付单，两套理解写到一半才发现对不上。

常见情形是，需求会只留了一份录音和几张参考截图，两周后开发问「优惠券能不能叠加」，业务方回「应该能吧」，这一句就把已写完的计价逻辑推翻了。把当场没答上的问题单独列成「待确认清单」，比留录音管用。

角色与权限表

角色不直接绑人，人挂到角色上，权限落到「角色 × 页面 × 操作」。这样店员离职时改一条账号关联就够，不用逐页改配置。小程序功能清单里，权限表是排在开发之前的那一张表，因为它决定了后台要做几个入口、几套列表。

「查看」和「导出」要分开授权。能看到订单不代表能把全部客户手机号导走，这两件事在数据口径上差着一个量级。改价、退款、手动调整会员等级这类动作也建议单独列权限，并要求写操作日志，记下操作人、时间与前后值。

这张表由谁确认？每一行都该有业务负责人签字，而不是开发替业务猜。尤其是「导出」列，常要同时过一遍负责数据管理的同事。权限表定下来之后，后台的菜单结构、接口鉴权、测试用例都能照着生成，属于投入小、牵动面大的一栏。

页面与字段清单

页面清单写「有哪些页面」，字段清单写「每个页面上有哪些数据」。后者才是能直接照抄的小程序需求文档模板核心。下面这张表建议每个核心页面复制一份，逐字段填。

几个细节值得固定成规范：金额用「分」为单位的整数存，避免浮点误差；时间统一用时间戳并注明时区；枚举字段把取值一个个列出来，别写「状态」两个字就完事；「来源」列区分用户输入、接口返回、系统生成，能顺带确定哪些字段前端不该改。

「确认人」不是形式。字段名填完要由对应业务的负责人过一遍，财务口径的金额、商品口径的规格、运营口径的备注，各归各管。常见情形是，备注字段没写长度上限，用户粘了一千字进去，后台订单列表被撑破，客服打印面单时只显示半截。这类问题在字段表上是一行字，到线上就是一次发版。

页面之外的公共规则

分页每页条数、空状态文案、列表默认排序、时间格式、金额是否含税，这些不属于某个页面，却会在每个页面出现。单列一节「公共规则」，比在十张页面表里重复写十遍更省事，改起来也只改一处。

状态流转与异常

订单的状态流转比其他模块都密，也容易写漏。把状态、触发方、允许流向、超时规则列成表，开发按表写状态机，测试按表写用例。

判断标准：每个状态都要写清「谁触发」和「能不能回退」，只画箭头不写触发方的流程图，到了并发场景就会打架。比如支付回调和用户取消几乎同时到达，谁说了算，要在表里写明以哪个为准。

异常清单单独列，别混在状态里：重复提交要有前端按钮置灰加后端幂等键（out_trade_no 同一笔只处理一次）；并发扣减库存放在事务里或用带条件的更新挡超卖；网络超时后状态不确定，要有主动查单补偿；退款原路失败要落到人工队列；取消订单要回滚库存与优惠券占用。这些分支不产生新页面，却占了订单模块相当一部分工时。昆山小程序开发的需求文档里，异常这一节写得越细，联调阶段来回拉扯越少。

优先级标注方法

用 MoSCoW 四档给每条需求打标，比「重要 / 一般」这类模糊分级好用。

1. Must（本期必须有）：判据是「缺了它，核心链路走不通」，不是「感觉很重要」。下单、支付、订单查询通常属于这一档。
2. Should（应该有）：影响体验但不阻断主流程，比如订单搜索、收藏。
3. Could（可以有）：有余力再做，比如主题皮肤、分享海报。
4. Won't（本期不做）：明确写进文档，而不是留着不说。写下来才不会在验收时被当成漏做。

打标之外还要标依赖。分销依赖会员等级与关系链，数据看板依赖埋点方案，这两类需求如果排到开发后期才提，前面写好的表结构往往要回头改。排期按依赖顺序走，不按喜好顺序走。

常见情形是，把「数据看板」标成 Must，开发到一半发现没有埋点、指标口径也没定，只能停下来补一轮采集。给每条需求标注「依赖哪几条」，这类停顿能提前看见。谈昆山小程序开发的范围时，优先级表也是控制增项的工具：新想法进来，先看它挤掉哪一档，而不是直接插队。

变更管理机制

需求会变，靠的是流程接住变化，而不是靠记性。每次变更填一张变更单，字段固定：编号、提出人、提出日期、原条目、拟改成什么、影响范围、评估结果、确认签字、文档版本号。

• 影响范围要拆成五项：页面、接口、表结构、状态机、工时与工期。只要碰到表结构或状态机，就重新评估，别当成「顺手改一下」。
• 评估结果写清接受、延期到下一期还是折算费用，三选一，不留「再看」。
• 版本号给个简单规则：文案与校验调整走 v1.1，结构或流程变动走 v2.0，方便回滚到某一版对账。
• 归档把每版文档和变更单放一处，验收时按签字过的那一版逐条核，不按聊天记录核。

判断标准：没有编号、没有影响评估、没有签字的口头加需求，不进开发排期。这不是设卡，是让双方对「这次改动要花多少」有同一个答案。

文档骨架可以对照 服务与解决方案 里的交付物说明补齐，或到 行业动态栏目 按同簇读下去；需要有人陪着把字段表和变更单跑一遍，走 免费咨询 说一声。

小结

需求文档的价值不在篇幅，在颗粒度：字段有类型与校验，状态有触发方与回退规则，每条需求有确认人和优先级，每次改动有编号与影响评估。明天就能做的一件事，是挑一个核心页面，把字段清单那张六列表填完，给每个字段写上确认人，再拿去请对应负责人签字。一页纸填完，昆山小程序开发的报价、开发、验收才算用上了同一份依据。本文为行业经验与技术分享，不构成效果承诺；具体交付范围、周期与资费以书面方案为准。