需求文档目录建议按“文档信息—背景与目标—范围与角色—需求条目—流程与规则—数据与接口—非功能要求—验收与发布—变更与附录”九个部分组织，核心是让每条需求都能被唯一识别、追溯、评审和验收。本文提供一份可直接复制的空白目录模板，并逐项说明填写口径、必填与选填的划分方法，再用一个登录需求示例演示完整填写过程，适合产品、项目与测试人员在新建或规范需求文档时使用。项目规模较小时，可先保留文档信息、背景目标、需求条目、验收标准、变更记录五块，其余部分按复杂度增补。
要点总览（TL;DR）
- 需求文档目录按“文档信息—背景与目标—范围与角色—需求条目—流程与规则—数据与接口—非功能要求—验收与发布—变更与附录”九段组织，核心是让每条需求可识别、可追溯、可评审、可验收。
- 最小可用版本保留文档信息、背景目标、需求条目、验收标准、变更记录五块，其余按项目复杂度增补，裁剪原因写入文档信息。
- 必填与选填的判断标准是：缺少该项是否影响评审结论、验收判断或变更追溯，满足任一条即保留。
- 需求条目字段口径统一：编号唯一不复用，描述写清角色、场景、动作与结果，验收标准写可观察可判断的条件。
- 模板需独立版本管理，字段增删经产品、开发、测试代表评审，并每季度抽查已归档文档的一致性。
可复制空白需求文档目录模板
下面这份目录按九段式组织，编号层级为“一级序号—二级序号—三级序号”，可直接粘贴到文档工具中作为骨架使用。方括号内为空白填写位，填写时替换为实际内容，不适用的段落可整段删除并在文档信息中注明裁剪原因。
1. 文档信息
1.1 文档名称：[填写]
1.2 文档编号：[填写]
1.3 版本号：[填写]
1.4 文档状态：[草稿/评审中/已确认/已归档]
1.5 编写人：[填写]
1.6 评审人：[填写]
1.7 创建日期：[填写]
1.8 最近更新日期：[填写]
1.9 关联项目/迭代：[填写]
1.10 裁剪说明：[删除的段落及原因]
2. 背景与目标
2.1 业务背景：[填写]
2.2 问题描述：[填写]
2.3 目标与衡量指标：[填写]
2.4 预期收益：[填写]
3. 范围与角色
3.1 本期范围：[填写]
3.2 不在本期范围：[填写]
3.3 前置依赖：[填写]
3.4 角色与职责：[角色名称｜职责说明]
4. 需求条目
4.1 需求清单：[需求编号｜需求名称｜优先级｜来源｜状态]
4.2 需求详情（每条需求重复以下结构）
4.2.1 需求编号：[填写]
4.2.2 需求名称：[填写]
4.2.3 需求描述：[填写]
4.2.4 优先级：[高/中/低]
4.2.5 需求来源：[填写]
4.2.6 关联需求：[填写]
4.2.7 业务规则：[填写]
4.2.8 验收标准：[填写]
5. 流程与规则
5.1 主流程说明：[填写]
5.2 分支与异常流程：[填写]
5.3 状态流转：[状态｜触发条件｜后续状态]
5.4 业务规则清单：[规则编号｜规则描述｜适用范围]
6. 数据与接口
6.1 数据对象与字段：[对象名称｜字段｜类型｜必填｜说明]
6.2 数据来源与流向：[填写]
6.3 接口清单：[接口名称｜调用方｜入参｜出参｜异常处理]
6.4 数据保留与清理规则：[填写]
7. 非功能要求
7.1 性能要求：[填写]
7.2 安全与权限要求：[填写]
7.3 兼容性要求：[填写]
7.4 可用性与容错要求：[填写]
8. 验收与发布
8.1 验收范围与方式：[填写]
8.2 验收用例清单：[用例编号｜对应需求编号｜预期结果]
8.3 发布计划：[填写]
8.4 上线检查项：[填写]
9. 变更与附录
9.1 变更记录：[日期｜版本｜变更内容｜变更人｜影响范围]
9.2 待确认问题：[问题｜提出人｜计划确认时间]
9.3 术语表：[术语｜解释]
9.4 参考资料：[填写]
这份骨架只解决“目录长什么样”，各段该写什么、写到什么粒度，需要配合下一节的字段口径使用。
各目录字段说明与填写口径
目录项的价值在于约束填写粒度。同一份模板，如果不同人按各自理解填写，评审时仍会出现信息缺失或口径不一。下面按段落说明每个字段记录什么信息、以什么粒度填写。
文档信息段
这一段解决“这份文档是谁的、处于什么状态、对应哪个项目”的问题。文档编号建议在团队内保持唯一，便于在评审记录、变更记录和测试用例中引用；版本号与文档状态配合使用，草稿阶段可频繁更新，进入评审后每次修改都应升版本；关联项目/迭代用于把文档挂到具体工作上下文，避免同一需求出现多份并行文档。裁剪说明是容易被忽略的一项，删除段落时写明原因，后续接手的人才能判断是“不需要”还是“漏写了”。
需求条目段
需求条目是整份文档的核心，字段口径要统一。需求编号建议采用“项目缩写-序号”的形式，一经分配不再复用；需求描述写清“谁在什么场景下执行什么动作、得到什么结果”，一句话能说清的不拆成多条；优先级用高、中、低三档即可，档位过多反而难以排序；需求来源记录提出方或原始诉求，便于回溯；关联需求用于标注依赖、互斥或替代关系；业务规则写该需求必须遵守的约束；验收标准写可观察、可判断的完成条件，避免“体验流畅”这类无法验证的表述。
流程规则、数据接口与非功能要求段
流程与规则段记录主流程、分支与异常流程、状态流转和规则清单，状态流转建议用“当前状态—触发条件—后续状态”三列表达，规则清单给每条规则编号，便于需求条目引用。数据与接口段记录数据对象、字段、来源流向和接口清单，字段表至少包含类型、是否必填和说明，接口清单写清调用方、入参、出参和异常处理。非功能要求段按性能、安全与权限、兼容性、可用性分类填写，每项尽量给出可测量的条件，例如响应时间、并发量或权限边界，没有明确指标时写明“待确认”并进入待确认问题清单。
必填项与选填项如何划分
必填与选填的判断标准是：缺少该项是否会导致需求无法评审、无法验收或无法追溯。满足其中任一条即为必填，其余按项目复杂度增补。下表给出划分建议。
| 目录段 | 最小可用必填内容 | 按复杂度增补的选填内容 |
|---|---|---|
| 文档信息 | 文档名称、编号、版本、状态、编写人、更新日期 | 评审人、关联项目/迭代、裁剪说明 |
| 背景与目标 | 业务背景、目标与衡量指标 | 问题描述、预期收益 |
| 范围与角色 | 本期范围 | 不在本期范围、前置依赖、角色与职责 |
| 需求条目 | 编号、名称、描述、优先级、验收标准 | 来源、关联需求、业务规则 |
| 流程与规则 | 主流程说明 | 分支与异常流程、状态流转、规则清单 |
| 数据与接口 | 涉及数据对象时的字段表 | 数据流向、接口清单、保留与清理规则 |
| 非功能要求 | 与需求直接相关的性能或权限条件 | 兼容性、可用性与容错要求 |
| 验收与发布 | 验收范围与方式 | 验收用例清单、发布计划、上线检查项 |
| 变更与附录 | 变更记录 | 待确认问题、术语表、参考资料 |
裁剪时按三个问题判断：这段信息是否影响需求评审结论；是否影响测试与验收判断；是否影响后续变更追溯。三个问题都答“否”的段落可以删除，答“是”的保留。涉及外部接口、资金或权限的需求，数据与接口段、非功能要求段通常应保留；内部小工具或一次性活动需求，可只保留最小必填集合。裁剪结果写入文档信息的裁剪说明，避免不同文档之间口径漂移。
完整填写示例：一个登录需求
以下示例为演示情景，用于说明各字段如何落地，不代表真实项目案例。假设某内部系统需要新增账号密码登录能力，按模板填写关键段落如下。
文档信息与背景目标
文档名称为“内部系统账号登录需求说明”，文档编号“IAM-REQ-001”，版本 V1.0，状态为评审中，编写人为产品负责人，关联项目为“账号体系改造”。业务背景写“现有系统依赖人工开通账号，登录入口分散”；目标与衡量指标写“统一登录入口上线后，账号开通由管理员在系统内完成，登录失败原因可查询”。
需求条目填写
需求编号 IAM-REQ-001-01，需求名称“账号密码登录”，需求描述“已开通账号的用户在登录页输入账号和密码，验证通过后进入系统首页”，优先级高，来源为“运维团队提出”，业务规则写“连续输错 5 次锁定 10 分钟”，验收标准写“正确账号密码可登录；错误密码提示统一文案；锁定期间登录被拒绝并提示剩余时间”。第二条需求 IAM-REQ-001-02 为“登录失败原因查询”，优先级中，关联需求标注依赖 01。
验收标准与变更记录
验收用例清单列出用例编号、对应需求编号和预期结果，例如“TC-01 对应 IAM-REQ-001-01，输入正确账号密码，预期进入首页”。变更记录首行记录“V1.0 初稿创建”，后续每次修改追加日期、版本、变更内容、变更人和影响范围。待确认问题记录“锁定时间是否按账号维度计算”，指定提出人和计划确认时间。示例中的字段与上一节口径一一对应：编号唯一、描述含角色动作结果、验收标准可判断、变更可追溯。
模板的调整与长期维护方法
模板建立后需要有人负责维护，否则字段会随项目增多逐渐失控。维护工作集中在版本管理、字段增删评审和定期一致性检查三件事上。
模板版本与变更记录
模板本身应有独立版本号，与具体需求文档的版本区分开。每次调整模板结构或字段口径，在模板变更记录中写明调整内容、原因和生效范围，并注明从哪个版本起新建文档必须使用新模板。已在进行中的文档不强制迁移，可在下次重大修订时对齐。
字段增删的评审与同步机制
新增字段前先确认它解决的是哪类信息缺失，能否用现有字段表达；删除字段前检查是否有文档正在引用。字段调整建议由产品、开发和测试各一名代表参与评审，评审结论同步到模板说明和填写示例，保证模板、字段说明、示例三者一致。涉及需求条目字段变化时，同步检查验收用例和变更记录中的引用方式。
定期清理与一致性检查
建议每季度抽查若干份已归档需求文档，核对是否出现空置段落、口径不一致或编号重复。检查项包括：必填字段是否完整、需求编号是否唯一、验收标准是否可判断、变更记录是否连续。发现的高频问题回流到模板说明中，作为下一版调整依据。
模板落地到协作平台时，可以把目录骨架固化为页面模板，让新建需求文档从同一结构开始。ONES Wiki 支持页面模板库一键创建制式化文档，页面树可按项目组织文档，页面组可关联项目，使需求与文档互相对应；页面版本记录支持查看与回滚，便于对照变更记录核对历史内容。需求条目的状态流转与验收跟踪，则可结合 ONES 项目与任务管理场景使用，具体配置以实际产品为准。这样文档承载目录与说明，工作项承载条目状态，两者通过项目关联保持同步，模板维护时也只需更新页面模板和字段说明两处。
常见问题
项目很小，只写一页需求文档，目录最少保留哪几项？
保留五项即可：文档信息、背景与目标、需求条目、验收标准、变更记录。文档信息至少写名称、编号、版本、状态和更新日期；需求条目写编号、名称、描述、优先级和验收标准；变更记录从初稿创建开始逐条追加。范围与角色、流程与规则、数据与接口、非功能要求这几段，如果确实不涉及，可以整段删除，并在文档信息的裁剪说明里写明原因，方便后续接手的人判断是主动裁剪还是漏写。
需求条目和流程规则、验收用例之间怎么建立对应关系？
用编号串联。需求条目分配唯一编号后，业务规则清单给每条规则编号并在需求条目中引用；验收用例清单中每行标注对应的需求编号；变更记录写明本次变更影响的需求编号。这样评审时可以从一条需求查到它的规则、用例和变更历史，测试也能按需求编号核对覆盖情况。编号一经分配不再复用，需求取消时保留编号并标注状态，避免后续引用错位。
非功能要求没有明确指标时怎么填？
先写清类别和已知条件，例如“登录接口响应时间待压测确认”“仅管理员角色可查看操作日志”，把没有结论的项写入待确认问题清单，注明提出人和计划确认时间。避免留空，也避免写“性能良好”这类无法验证的表述。待确认问题在评审时逐条过，确认后回填到非功能要求段并更新版本号。
模板调整后，已经在写的需求文档要不要全部改？
不强制迁移。模板变更记录中注明从哪个版本起新建文档必须使用新结构，进行中的文档在下次重大修订时对齐即可。涉及需求条目字段增删时，同步检查验收用例和变更记录中的引用方式，避免新旧口径混用。如果调整影响评审或验收判断，可以在团队内发一次简短说明，列出变化点和生效时间。
把目录模板放到协作平台里，文档和需求条目怎么分工？
文档承载目录结构、背景说明、规则与验收标准的完整描述，需求条目的状态流转和验收跟踪放在项目工作项中，两者通过项目关联对应。ONES Wiki 支持页面模板库一键创建制式化文档，页面树可按项目组织文档，页面组可关联项目，页面版本记录支持查看与回滚，便于对照变更记录核对历史内容（claim F1、F2、F3）。具体配置以实际产品为准。这样模板维护时只需更新页面模板和字段说明两处。
