需求文档模板要解决的核心问题，是把“需求是什么、为谁解决什么问题、做到什么程度算完成”写成可评审、可追踪的条目。建议用一张主表承载需求条目，字段分为标识与来源、内容与判断、状态与流转三组。下面直接给出可复制的空白表格、逐字段填写口径、必填与选填的划分，以及一条完整填写示例，方便团队按自身情况裁剪后长期使用。
要点总览（TL;DR）
- 需求文档主表用一张横向表格承载，每行一条需求，字段分为标识与来源、内容与判断、状态与流转三组，共12个字段。
- 需求编号、需求描述、验收标准、优先级、状态为必填，其余字段按团队实际选填；草稿阶段只要求编号、描述和状态，待评审前补齐验收标准与优先级。
- 需求描述写动作和对象，用户场景写角色、困境和反馈依据，验收标准拆成可逐条核对的条件，避免“优化体验”“功能正常”这类无法判断的表述。
- 模板调整以触发条件为依据：同类信息反复写进描述则新增字段，长期无人填写则删除或改为选填，评审反复因同类信息缺失退回则升为必填。
- 模板、字段说明、示例三处字段名与取值规范保持一致，模板版本号与每条需求的变更记录分开维护。
可复制的需求文档空白模板
先给结论：需求文档主表用一张横向表格承载即可，每行一条需求，表头固定为三组字段。复制下表到文档或表格工具中，删去示例行即为空白模板。
| 需求编号 | 提出人 | 来源 | 所属模块 | 需求描述 | 用户场景 | 验收标准 | 优先级 | 状态 | 负责人 | 关联文档 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| （如 REQ-001） | （姓名） | （用户反馈／业务方／内部优化） | （模块名） | （一句话说明要做什么） | （谁在什么情况下遇到什么问题） | （可验证的完成条件） | （P0／P1／P2／P3） | （草稿／待评审／已确认／开发中／已完成／已关闭） | （姓名） | （文档标题或链接） | （日期＋变更内容） |
字段布局按三组排列，便于阅读和筛选：标识与来源组包括需求编号、提出人、来源、所属模块；内容与判断组包括需求描述、用户场景、验收标准、优先级；状态与流转组包括状态、负责人、关联文档、变更记录。
表格模板与文档模板两种形态各有适用场景。表格模板适合需求条目多、需要批量筛选排序、与需求池或任务系统对接的团队，一行一条需求，横向对比方便。文档模板适合单条需求需要展开背景、流程图、原型说明的情况，以“标题＋分节”的形式承载，每个字段对应一个小节。实践中可以组合使用：主表管条目和状态，单条需求另附文档写细节，主表的“关联文档”字段指向该文档。
每个字段填什么：字段说明与取值规范
字段说明的作用是让不同的人填出同一口径的内容。下表逐字段给出含义、填写口径和示例值，字段名与上节模板保持一致。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 需求编号 | 需求的唯一标识 | 团队统一前缀加流水号，创建后不再修改 | REQ-2024-018 |
| 提出人 | 提出该需求的人 | 填真实姓名，便于后续澄清 | 张敏 |
| 来源 | 需求产生的渠道 | 从固定选项中选择，如用户反馈、业务方、内部优化、竞品分析 | 用户反馈 |
| 所属模块 | 需求落在哪个功能或业务范围 | 使用团队已有的模块命名，避免自造新词 | 订单结算 |
| 需求描述 | 要做什么 | 一句话写清动作和对象，避免只写“优化体验”这类无法判断的表述 | 结算页支持使用优惠券并实时显示抵扣金额 |
| 用户场景 | 谁在什么情况下遇到什么问题 | 按“角色＋场景＋问题”写，一到两句 | 用户在结算页下单时无法使用已领取的优惠券，只能放弃优惠或退出重下 |
| 验收标准 | 做到什么程度算完成 | 写成可逐条核对的条目，包含条件、动作和预期结果 | 1. 结算页展示可用优惠券列表；2. 选择后金额实时更新；3. 不可用券置灰并说明原因 |
| 优先级 | 相对重要程度 | 使用固定档位，并约定每档的判断依据 | P1 |
| 状态 | 需求当前所处阶段 | 从固定状态集中选择，流转时同步更新 | 待评审 |
| 负责人 | 当前推动该需求的人 | 填具体人名，随阶段交接更新 | 李哲 |
| 关联文档 | 与该需求相关的补充材料 | 填文档标题或链接，注明文档类型 | 《结算页优惠券交互稿》 |
| 变更记录 | 需求内容或状态的调整痕迹 | 按“日期＋变更人＋变更内容”追加，不覆盖旧记录 | 2024-06-12 李哲：验收标准新增第3条 |
需求描述、用户场景、验收标准三者构成一条需求的判断链：描述说明做什么，场景说明为什么值得做，验收标准说明做完如何确认。描述写动作和对象；场景写角色和困境；验收标准写可核对的条目，尽量包含数量、条件或边界。例如“加载更快”无法验收，“列表首屏在常规网络下1秒内展示”则可以逐项核对。
优先级与状态都使用固定取值，避免同一团队出现“高”“紧急”“很重要”混用。优先级档位建议不超过四档，并为每档写明判断依据，例如P0为阻断主流程的问题，P1为影响核心转化或明确用户投诉，P2为体验改进，P3为可延后事项。状态集合同样保持精简，草稿、待评审、已确认、开发中、已完成、已关闭即可覆盖多数团队。
关联文档与变更记录解决的是追溯问题。关联文档在需求确认后补齐，指向原型、技术方案或评审纪要；变更记录在每次修改描述、验收标准或状态时追加一行，保留时间和修改人。需求进入评审、变更和交接环节后，状态与关联记录需要持续维护，这类信息适合放在支持条目状态流转和文档关联的工具中承载。ONES Wiki 支持页面组关联项目，使需求与文档互相对应，并记录页面版本、支持查看与回滚，可用于保存需求说明和变更痕迹；具体配置以实际开通的版本为准。
必填与选填：按评审门槛划分字段
必填与选填的划分依据是评审门槛：缺少该字段，评审人无法判断需求是否成立、是否值得做、是否可验收，就列为必填。按此标准，需求编号、需求描述、验收标准、优先级、状态为必填，其余字段按团队实际选填。
| 字段 | 必填／选填 | 理由或适用场景 |
|---|---|---|
| 需求编号 | 必填 | 唯一标识，缺失则无法引用、关联和追踪 |
| 需求描述 | 必填 | 没有描述就没有可评审的对象 |
| 验收标准 | 必填 | 缺失则无法判断完成，容易在交付时产生争议 |
| 优先级 | 必填 | 缺失则无法排序和安排资源 |
| 状态 | 必填 | 缺失则无法判断需求处于哪个环节 |
| 提出人 | 选填 | 需求来自明确渠道时可后补，但评审前建议补齐以便澄清 |
| 来源 | 选填 | 用于统计需求结构和复盘，小团队可简化 |
| 所属模块 | 选填 | 需求量大、需要按模块筛选时填写 |
| 用户场景 | 选填 | 复杂需求建议填写；简单明确的缺陷修复可省略 |
| 负责人 | 选填 | 草稿阶段可空缺，进入待评审后建议指定 |
| 关联文档 | 选填 | 有原型、方案或纪要时填写 |
| 变更记录 | 选填 | 首次创建可留空，发生修改后必须追加 |
按需求阶段区分必填程度，可以让模板在草稿期保持轻量、在评审期保持严格。草稿阶段只要求需求编号、需求描述和状态，允许信息不全，便于快速记录想法；待评审阶段补齐验收标准和优先级，缺少任一项则不进入评审；已确认阶段补齐负责人和关联文档，并把变更记录开始维护起来。这样划分后，字段缺失导致的退回集中在评审前一次处理，减少反复沟通。
完整填写示例：一条需求从提出到确认
下面用一条已填写的需求记录示范全部字段，字段名与前述模板、说明保持一致。
| 字段 | 填写内容 |
|---|---|
| 需求编号 | REQ-2024-018 |
| 提出人 | 张敏 |
| 来源 | 用户反馈 |
| 所属模块 | 订单结算 |
| 需求描述 | 结算页支持选择已领取的优惠券，并实时显示抵扣后的应付金额 |
| 用户场景 | 用户在结算页下单时已领取优惠券，但页面没有使用入口，只能放弃优惠或退出重下，近两周收到12条同类反馈 |
| 验收标准 | 1. 结算页展示当前订单可用优惠券列表；2. 选择优惠券后应付金额实时更新；3. 不可用券置灰并展示不可用原因；4. 取消选择后金额恢复原值 |
| 优先级 | P1 |
| 状态 | 已确认 |
| 负责人 | 李哲 |
| 关联文档 | 《结算页优惠券交互稿》《6月需求评审纪要》 |
| 变更记录 | 2024-06-05 张敏：创建，状态为草稿；2024-06-08 李哲：补充验收标准第3、4条，状态改为待评审；2024-06-12 王芳：评审通过，状态改为已确认，关联交互稿 |
几个关键字段的填写理由值得对照。需求描述写“支持选择优惠券并实时显示抵扣金额”，动作和对象明确；常见错误写法是“优化结算体验”，评审时无法判断范围。用户场景写明了角色、困境和反馈数量，为优先级提供依据；只写“用户需要优惠券”则缺少判断信息。验收标准拆成四条可核对的条件，覆盖展示、更新、异常和回退；写成“优惠券功能正常”会在验收时产生分歧。变更记录按时间追加，能看出这条需求从草稿到确认经历了补充验收标准和评审通过两个节点。
模板的调整与长期维护方法
模板需要随团队变化调整，但调整应有触发条件，避免频繁改表导致历史数据口径混乱。常见触发条件包括：同类信息反复写在需求描述里，说明应新增字段；某字段连续多个季度无人填写，说明可以删除或改为选填；评审反复因同一类信息缺失而退回，说明该字段应升为必填；团队规模扩大、需求来源增多时，补充来源和所属模块用于统计。
裁剪原则可以归纳为三条：字段服务于评审和追踪，不能帮助判断需求成立、排序或验收的字段不进入主表；同类信息只保留一个字段，避免描述与备注重复承载；新增字段先以选填试运行一个周期，确认有人填写且被使用后再考虑转为必填。
模板版本与变更记录分开维护。模板本身记录版本号和修订说明，例如“v1.2 新增所属模块，验收标准改为必填”；每条需求的变更记录只记录该需求自身的变化，两者不混用。模板升级时，历史需求不强制回填新字段，新字段从下一批需求开始适用，并在模板说明中注明生效时间。
模板、字段说明、示例三者需要同步更新，可用下面的检查清单逐项核对：
- 字段名在空白模板、字段说明表、填写示例三处完全一致，没有同义不同名。
- 新增或删除字段后，字段说明表同步增删对应行，并写明填写口径。
- 必填与选填对照表随字段调整更新，阶段门槛描述与之一致。
- 填写示例至少覆盖新增字段，示例值符合字段说明中的口径。
- 模板版本号与修订说明已更新，并注明生效时间。
- 历史需求的变更记录未被覆盖，新字段的回填策略已明确。
如果团队使用文档工具承载模板，可把空白模板做成固定页面，字段说明和示例放在相邻页面，需求条目按项目或模块分组存放。ONES Wiki 支持页面模板库，可一键创建制式化文档，并可为不同角色配置读写权限，适合把模板、说明和示例作为一套标准文档长期维护；具体可用范围以实际开通的版本为准。
常见问题
需求文档模板里的字段越多越好吗？
字段数量以能支撑评审和追踪为准。每个字段都应有明确用途：帮助判断需求是否成立、是否需要优先做、做完如何验收，或者便于后续追溯。如果某个字段连续几个季度无人填写，也没有在评审中被引用，就可以删除或改为选填。字段过多会增加填写负担，也容易让填写人用“备注”类字段承载本应独立记录的信息。
小团队可以只用简化版模板吗？
可以。小团队或需求来源单一的团队，可以先保留需求编号、需求描述、验收标准、优先级、状态五个必填字段，把提出人、来源、所属模块等作为选填。简化版模板仍要保证一条需求能被评审、能判断完成、能看出当前处于哪个环节。随着需求来源增多或团队规模扩大，再按实际使用情况补充来源、所属模块等字段，新增字段先以选填试运行一个周期。
需求变更后，变更记录应该写在哪里？
变更记录写在每条需求自己的记录里，按“日期＋变更人＋变更内容”追加，不覆盖旧记录。模板本身的版本修订说明单独维护，例如“v1.2 新增所属模块，验收标准改为必填”，两者不要混用。这样既能看出单条需求从草稿到确认经历了哪些调整，也能追溯模板规则何时发生变化。历史需求的变更记录在模板升级时保持原样，新字段从下一批需求开始适用。
验收标准写到什么程度才算可验收？
验收标准应写成可逐条核对的条件，包含条件、动作和预期结果，尽量带数量、边界或异常情况。例如“结算页展示可用优惠券列表”“选择后应付金额实时更新”“不可用券置灰并说明原因”，每条都能在验收时逐项确认。写成“优惠券功能正常”则无法判断范围，容易在交付时产生分歧。验收标准也不必穷尽所有细节，覆盖主流程、关键异常和回退即可。
用文档工具维护模板时，怎么让模板、说明和示例保持一致？
把空白模板做成固定页面，字段说明和填写示例放在相邻页面，按同一套字段名维护。每次增删字段时，同步更新字段说明表的对应行、必填与选填对照表，并让填写示例至少覆盖新增字段。ONES Wiki 支持页面模板库，可一键创建制式化文档，并记录页面版本、支持查看与回滚，适合把模板、说明和示例作为一套标准文档长期维护；具体可用范围以实际开通的版本为准。
