需求文档目录是一张按统一字段登记每份需求文档的索引表，用来回答“有哪些需求文档、各自处于什么版本和状态、由谁负责、评审结论如何、文件放在哪里”。本文提供一份可直接复制到表格工具中使用的空白目录模板，逐字段说明填写口径，划分必填与选填，并给出一份含多行记录的完整填写样例，最后说明目录随项目变化时的调整与维护方法。示例数据为演示情景，可按团队实际情况替换。
要点总览（TL;DR）
- 需求文档目录是一张按统一字段登记每份文档的索引表，核心字段包括文档编号、名称、所属需求/模块、类型、版本、状态、负责人、评审结论、存放位置和更新时间。
- 文档编号、名称、所属需求/模块、类型、版本、状态、负责人、存放位置、更新时间建议设为必填；评审结论在文档进入评审后补填，暂缺时用“待评审”“待归档”“待指派”等统一标注说明原因。
- 填写时一行对应一份文档，编号全表唯一，版本与状态分开记录，存放位置写到可直达的文件路径或页面，并与版本字段对应。
- 目录需要指定维护责任人，在文档新建、修改、评审完成和状态变化时当天更新，每个迭代结束前整体核对，升版时旧版本归档并保留记录。
- 目录与文档分散在不同工具时，可把目录作为索引，将文档承载在支持版本记录和需求关联的平台上，让存放位置指向对应页面。
可复制空白需求文档目录模板
下面这张表就是目录的空白结构，字段顺序固定，便于不同人按同一口径登记。使用时把表头复制到 Excel、在线表格或文档表格中，每份需求文档占一行，新文档登记时在末尾追加一行，已有文档修改时更新对应行，不另起新表。
| 文档编号 | 文档名称 | 所属需求/模块 | 文档类型 | 版本 | 状态 | 负责人 | 评审结论 | 存放位置 | 更新时间 |
|---|---|---|---|---|---|---|---|---|---|
登记时把握三条规则：一行只对应一份文档，同一需求拆成多份文档时分别占行；文档编号在整张表中唯一，后续引用、评审记录和归档都以编号定位；存放位置填写可定位到具体文件或页面的路径，避免只写“共享盘”这类无法直接找到的笼统描述。表格行数按项目文档量增减，表头字段保持不变。
目录字段说明：每个字段记录什么
字段含义写清楚，不同人填出来的目录才能互相对照。下表逐项说明每个字段记录的内容和填写口径。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 文档编号 | 该文档在目录中的唯一标识 | 按团队约定规则生成，如“需求编号-文档类型缩写-序号”，一经分配不再更改 |
| 文档名称 | 文档的正式标题 | 与文档内标题保持一致，写清需求对象，避免“需求文档1”这类无法辨识的名称 |
| 所属需求/模块 | 文档服务的需求条目或功能模块 | 填写需求编号或模块名称，一份文档对应多个需求时填主需求，其余在文档内说明 |
| 文档类型 | 文档在需求过程中的类别 | 按团队固定分类填写，如需求说明、原型说明、接口说明、验收标准 |
| 版本 | 文档当前修订版本 | 采用统一编号方式，如 V1.0、V1.1，内容实质变更升主版本，文字修订升次版本 |
| 状态 | 文档当前所处阶段 | 从固定状态集中选择，如草稿、评审中、已通过、已归档 |
| 负责人 | 对该文档内容和更新负责的人 | 填写具体人员，不填团队或岗位名称，便于变更时找到对接人 |
| 评审结论 | 最近一次评审的结果 | 填写通过、有条件通过、退回修改等结论，并注明评审日期 |
| 存放位置 | 文档实际所在位置 | 填写可直达的文件路径、页面链接或目录层级，保证他人能按此找到原文 |
| 更新时间 | 该行记录最近一次修改日期 | 填写日期，文档内容或状态变化时同步更新 |
其中文档编号、版本、状态三个字段相互配合：编号保证唯一，版本记录改了几次，状态说明当前走到哪一步。三者分开记录，读者既能找到文档，也能判断这份文档是否可以作为当前依据。
必填与选填字段的划分
必填字段用于保证目录能被检索、追溯和交接，缺一项就会影响使用；选填字段用于补充信息，按项目需要决定是否填写。划分如下表。
| 字段 | 填写要求 | 理由或适用场景 |
|---|---|---|
| 文档编号 | 必填 | 唯一标识，引用和归档都依赖它 |
| 文档名称 | 必填 | 检索和识别文档的基本信息 |
| 所属需求/模块 | 必填 | 建立文档与需求的对应关系 |
| 文档类型 | 必填 | 区分文档用途，便于按类查找 |
| 版本 | 必填 | 判断文档是否为当前有效版本 |
| 状态 | 必填 | 说明文档所处阶段，决定能否作为依据 |
| 负责人 | 必填 | 变更和问题反馈的对接人 |
| 存放位置 | 必填 | 从目录直达原文 |
| 更新时间 | 必填 | 判断记录是否及时维护 |
| 评审结论 | 选填 | 文档尚未评审时暂不填写；进入评审流程后补填，用于追溯评审结果 |
字段暂缺时不要留空让人猜测，用统一标注说明原因：尚未评审的评审结论填“待评审”，存放位置暂未确定的填“待归档”并在备注中说明计划时间，负责人未定的填“待指派”。标注本身也是信息，能让后续维护者知道这一行还缺什么。评审结论虽为选填，但文档一旦进入评审，就应在结论出来后及时补填，否则目录无法反映文档的真实可用状态。
填写示例：一份需求文档目录的完整样例
以下样例演示同一需求下多份文档如何登记，覆盖需求说明、原型说明和接口说明三种类型，并展示版本、状态、评审结论与存放位置的配合方式。数据为演示情景。
| 文档编号 | 文档名称 | 所属需求/模块 | 文档类型 | 版本 | 状态 | 负责人 | 评审结论 | 存放位置 | 更新时间 |
|---|---|---|---|---|---|---|---|---|---|
| REQ-021-DOC-01 | 订单退款需求说明 | REQ-021 订单退款 | 需求说明 | V1.2 | 已通过 | 张岚 | 通过（2025-03-12） | 需求库/订单退款/需求说明_V1.2 | 2025-03-12 |
| REQ-021-DOC-02 | 订单退款页面原型说明 | REQ-021 订单退款 | 原型说明 | V1.1 | 评审中 | 李哲 | 待评审 | 需求库/订单退款/原型说明_V1.1 | 2025-03-14 |
| REQ-021-DOC-03 | 退款接口字段说明 | REQ-021 订单退款 | 接口说明 | V1.0 | 草稿 | 王敏 | 待评审 | 需求库/订单退款/接口说明_V1.0 | 2025-03-15 |
| REQ-022-DOC-01 | 会员积分规则需求说明 | REQ-022 会员积分 | 需求说明 | V2.0 | 已通过 | 陈然 | 有条件通过（2025-03-10），补充过期规则后复审 | 需求库/会员积分/需求说明_V2.0 | 2025-03-11 |
从样例可以看出几个填写要点。同一需求的文档共用需求编号前缀，靠末尾序号区分，编号一眼能看出归属。版本与状态分开记录：REQ-021-DOC-01 已到 V1.2 且状态为已通过，说明它是当前可依据的版本；REQ-021-DOC-02 处于评审中，版本为 V1.1，评审结论填“待评审”，表示结论尚未产生。REQ-022-DOC-01 的评审结论写明了“有条件通过”及复审条件，比只写“通过”更能反映真实情况。存放位置统一采用“目录层级/文件名_版本”的写法，与版本字段对应，读者按路径打开的就是目录中登记的那一版。
目录的调整与日常维护方法
目录建好后需要随项目推进持续维护，否则很快会与实际文档脱节。调整字段和维护记录可以按以下规则执行。
- 新增字段的判断依据：当团队反复需要按某一信息筛选或追溯，而现有字段无法表达时，再新增字段。例如需要统计文档的评审轮次，可增加“评审次数”；新增字段应同时补充字段说明和必填判断，并回填已有记录。
- 删减字段的判断依据：某字段连续多个项目无人填写、也不参与检索和交接时，可以合并或删除。删除前确认没有流程依赖该字段，例如评审结论被评审流程引用，就不宜删除。
- 维护责任人：由需求负责人或指定的文档管理员维护整张目录，各文档负责人负责更新自己那几行的版本、状态和存放位置。责任到人，避免出现“大家都以为别人会更新”的空档。
- 更新时点：文档新建时登记新行；文档内容修改、评审完成、状态变化时当天更新对应行和更新时间；每个迭代结束前做一次整体核对，检查是否有文档未登记或状态滞后。
- 版本变更处理：文档升版时更新版本字段和存放位置，旧版本移入归档目录，目录中保留一行记录并标注“已归档”，便于追溯历史依据。
- 归档规则：需求关闭或文档被替代后，将状态改为已归档，不再作为当前依据；归档记录保留在目录中，不直接删除行。
当目录登记与文档实际存放分散在不同工具中时，可以把目录作为索引、把文档承载在支持版本记录和需求关联的平台上。ONES Wiki 支持页面组关联项目，使需求与文档互相对应，并记录所有页面版本、支持随时查看与回滚，这与目录中版本、状态字段的维护需求相衔接；其页面模板库可用于创建制式化的文档模板，减少每次新建文档时的格式差异。团队可以据此把目录中的“存放位置”指向对应页面，让索引与原文保持同步。具体模板形态和版本功能差异，选型时以实际产品核验为准。
常见问题
团队刚开始建目录，字段能不能先少填几个，后面再补？
可以分步推进，但建议先保证检索和追溯所依赖的字段完整。文档编号、名称、所属需求/模块、版本、状态、负责人和存放位置这几项一旦缺失，目录就无法回答“这份文档在哪里、是不是当前依据、找谁确认”。如果项目初期确实来不及填全，用统一标注写清缺失原因和计划补齐时间，例如评审结论填“待评审”、存放位置填“待归档”，避免留空让人猜测。字段补齐后再去掉标注。
同一份需求文档同时服务多个需求，所属需求/模块怎么填？
按主需求填写，也就是这份文档主要支撑的那条需求，其余关联需求在文档正文中说明。目录的一行只对应一份文档，不建议为同一份文档重复登记多行，否则版本和状态会出现多份记录，后续难以判断哪一行是当前依据。如果多个需求对文档的依赖程度接近，可以由需求负责人协商确定主需求，并在目录备注中写明其他关联需求编号。
文档升版后，旧版本在目录里怎么处理？
升版时更新该行的版本字段和存放位置，把旧版本文件移入归档目录，目录中保留原记录并将状态改为“已归档”，不直接删除行。这样既能让读者按目录找到当前有效版本，也能在追溯历史依据时查到旧版本的去向。如果团队需要保留每个版本的独立记录，可以为旧版本单独增加一行并标注已归档，同时在当前版本行中注明替代关系。
目录由一个人维护，还是每个文档负责人各自更新？
建议采用“统一责任人加文档负责人”的方式：由需求负责人或指定的文档管理员维护整张目录的结构、字段口径和整体核对，各文档负责人更新自己那几行的版本、状态、评审结论和存放位置。责任到人后，文档变更当天就能反映到目录中。只靠一个人维护时，文档负责人需要主动告知变更，容易滞后；完全分散时，字段口径又容易不一致。两种方式可以按团队规模选择，关键是明确谁对哪一行负责。
目录里的存放位置写成共享盘路径，为什么还是找不到文件？
共享盘路径通常只定位到目录层级，文件改名或移动后就失效。存放位置建议写到可直达的文件路径、页面链接或“目录层级/文件名_版本”的形式，并与版本字段对应，让读者打开的就是目录中登记的那一版。如果文档承载在支持页面版本记录的平台上，可以直接填写页面链接，页面内容更新后链接保持不变，目录与原文更容易保持同步。
