需求追溯表要同时承载两条链路：需求之间的依赖关系，以及需求到实现项、验证项的覆盖关系。字段可以按需求标识、依赖关系、实现覆盖、验证与基线四组组织，主表一行一条需求，两张关系子表一行一条追溯关系。下面给出可直接复制的空白模板、逐字段填写口径、必填取舍、完整示例和维护规则。
要点总览（TL;DR）
- 需求追溯表按四组字段组织：需求标识、依赖关系、实现覆盖、验证与基线；主表一行一条需求，依赖与覆盖各用独立子表，一行只记一条关系。
- 三张表以需求编号为关联键，依赖子表用“需求编号＋上游需求编号”定位，覆盖子表用“需求编号＋实现项编号”定位，关系编号和覆盖编号只用于单行引用。
- 最小可用字段集为八项：需求编号、需求名称、上游需求编号、依赖类型、实现项编号、覆盖状态、验证项编号、基线版本，可先支撑需求到验证的基本链路。
- 依赖类型建议用前置、数据、接口、约束四类，覆盖状态用未覆盖、部分覆盖、已覆盖、覆盖待确认四类，同一张表内保持一套取值。
- 维护上按基线归档只读快照，需求变更时同步复核依赖行与覆盖状态，并在验证前、建基线时、发布后三个时点复核覆盖结论。
可复制空白模板：需求追溯表主表与两张关系子表
建表时先确定一条原则：一行只记录一条关系。需求与需求之间的依赖、需求与实现项之间的覆盖，分别放进独立子表，用需求编号关联。这样同一需求有多条依赖或多条实现项时，不会把多个值挤进一个单元格，后续筛选、统计和变更影响分析都能按行处理。
表一：需求主表
| 字段名 | 填写内容 |
|---|---|
| 需求编号 | |
| 需求名称 | |
| 需求层级 | |
| 需求版本 | |
| 需求状态 | |
| 需求负责人 | |
| 需求来源 | |
| 优先级 | |
| 验收口径 | |
| 基线版本 | |
| 最后更新时间 |
表二：需求依赖关系子表
| 字段名 | 填写内容 |
|---|---|
| 关系编号 | |
| 需求编号 | |
| 上游需求编号 | |
| 依赖类型 | |
| 依赖方向 | |
| 依赖强度 | |
| 变更影响说明 | |
| 依赖状态 | |
| 确认人 | |
| 最后更新时间 |
表三：实现覆盖子表
| 字段名 | 填写内容 |
|---|---|
| 覆盖编号 | |
| 需求编号 | |
| 实现项编号 | |
| 实现类型 | |
| 实现载体 | |
| 覆盖状态 | |
| 覆盖说明 | |
| 验证项编号 | |
| 验证结论 | |
| 基线版本 | |
| 最后更新时间 |
三张表的关联键是需求编号：主表中需求编号唯一，依赖子表用“需求编号＋上游需求编号”定位一条依赖，实现覆盖子表用“需求编号＋实现项编号”定位一条覆盖记录。关系编号和覆盖编号用于单行引用与审计，不替代需求编号作为关联键。
字段说明：每个字段记录什么、怎么填
字段说明要解决的是“同一列在不同人手里填出不同含义”的问题。下表给出每个字段的含义、取值示例和填写口径，模板、说明与示例三处使用同一套字段名。
需求标识类字段
| 字段名 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 需求编号 | 需求的唯一标识 | REQ-042 | 全表唯一，创建后不改；子表引用时原样填写 |
| 需求名称 | 需求的一句话描述 | 订单导出支持按时间范围筛选 | 写业务动作和对象，避免只写模块名 |
| 需求层级 | 需求在层级结构中的位置 | 业务需求／系统需求／子需求 | 按团队既有层级填写，同一层级用词统一 |
| 需求版本 | 需求当前修订版本 | V1.2 | 需求内容变更时递增，与基线版本区分 |
| 需求状态 | 需求当前处理阶段 | 草稿／评审中／已确认／实现中／已验证／已关闭 | 用固定枚举，状态推进时同步更新 |
| 需求负责人 | 对需求内容和变更负责的人 | 产品经理姓名 | 填具体责任人，不填团队名 |
| 需求来源 | 需求提出的渠道或依据 | 客户反馈／内部规划／合规要求 | 便于回溯提出背景，可简写 |
| 优先级 | 需求排期优先级 | 高／中／低 | 与团队排期口径一致 |
| 验收口径 | 判断需求完成的业务标准 | 导出文件包含筛选区间内全部订单 | 写可判断的条件，不写“体验良好”一类描述 |
依赖关系类字段
| 字段名 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 关系编号 | 依赖关系的唯一标识 | DEP-108 | 每条依赖一行，编号唯一 |
| 需求编号 | 被依赖影响的需求 | REQ-042 | 必须是主表存在的需求编号 |
| 上游需求编号 | 本需求所依赖的需求 | REQ-031 | 同样引用主表编号；跨项目时在编号前加项目前缀 |
| 依赖类型 | 依赖的性质 | 前置依赖／数据依赖／接口依赖／约束依赖 | 从固定枚举中选择，见下方枚举说明 |
| 依赖方向 | 依赖的指向 | 本需求依赖上游／上游依赖本需求 | 明确方向，避免双向记录造成重复 |
| 依赖强度 | 依赖对交付的约束程度 | 强／弱 | 强依赖表示上游不满足则本需求无法验收 |
| 变更影响说明 | 上游变化时对本需求的影响 | 上游字段调整将导致导出模板重做 | 写具体受影响的对象，变更评审时更新 |
| 依赖状态 | 依赖是否已满足 | 待满足／已满足／已失效 | 上游交付或变更后同步更新 |
| 确认人 | 确认该依赖成立的人 | 系统负责人姓名 | 依赖评审后填写 |
实现覆盖类字段
| 字段名 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 覆盖编号 | 覆盖关系的唯一标识 | COV-215 | 每条覆盖一行 |
| 需求编号 | 被实现的需求 | REQ-042 | 引用主表编号 |
| 实现项编号 | 承接需求的工作项标识 | TASK-330／STORY-118 | 引用开发任务、故事或配置项编号 |
| 实现类型 | 实现项的性质 | 开发任务／接口／配置／文档 | 按实际承接方式填写 |
| 实现载体 | 实现所在的模块或交付物 | 订单服务-导出模块 | 写到可定位的模块层级 |
| 覆盖状态 | 需求被实现的程度 | 未覆盖／部分覆盖／已覆盖／覆盖待确认 | 用固定枚举，见下方枚举说明 |
| 覆盖说明 | 覆盖判断的依据 | 筛选逻辑已实现，分页导出待补 | 部分覆盖时写明缺口 |
| 验证项编号 | 对应验证活动的标识 | TC-501／CASE-77 | 引用测试用例或验证记录编号 |
| 验证结论 | 验证活动的结果 | 通过／不通过／待验证 | 与验证记录保持一致 |
| 基线版本 | 该覆盖结论对应的基线 | BL-2024-06 | 覆盖结论变化时更新 |
依赖类型与覆盖状态的取值枚举
枚举值的作用是让筛选和统计口径统一。依赖类型建议使用四类：前置依赖指上游需求先完成本需求才能开始；数据依赖指本需求使用上游产生的数据；接口依赖指本需求调用上游提供的接口；约束依赖指上游规则或合规要求限制本需求的实现方式。覆盖状态建议使用四类：未覆盖表示尚无实现项承接；部分覆盖表示已有实现但存在明确缺口；已覆盖表示实现项满足验收口径；覆盖待确认表示实现已完成但验证结论尚未回填。团队可以增删枚举，但同一张表内应保持一套取值。
必填与选填：哪些字段缺失会让追溯断链
必填字段的判断标准是：缺失后无法从需求定位到依赖或实现，或者无法判断覆盖是否成立。其余字段按管理需要选填，用于提升可读性和审计质量。
| 字段 | 必填／选填 | 缺失后果或适用场景 |
|---|---|---|
| 需求编号 | 必填 | 缺失则子表无法关联，整条追溯断链 |
| 需求名称 | 必填 | 缺失后只能靠编号辨认，评审和审计成本上升 |
| 需求状态 | 必填 | 缺失则无法判断追溯结论是否仍然有效 |
| 需求负责人 | 必填 | 缺失则变更和复核无人承接 |
| 上游需求编号 | 必填（存在依赖时） | 缺失则依赖关系无法定位，影响分析失效 |
| 依赖类型 | 必填（存在依赖时） | 缺失则无法区分前置、数据、接口等不同处理方式 |
| 依赖方向 | 必填（存在依赖时） | 缺失易造成重复记录和方向误判 |
| 实现项编号 | 必填（存在实现时） | 缺失则需求到开发的链路断开 |
| 覆盖状态 | 必填 | 缺失则无法统计覆盖情况，也无法触发复核 |
| 验证项编号 | 必填（进入验证阶段后） | 缺失则实现与验证脱节，覆盖结论缺少依据 |
| 基线版本 | 必填（建立基线后） | 缺失则无法判断追溯结论对应哪个交付版本 |
| 需求层级 | 选填 | 需求分层管理时填写，单层需求可省略 |
| 需求来源 | 选填 | 需要回溯提出背景时填写 |
| 优先级 | 选填 | 排期管理需要时填写 |
| 依赖强度 | 选填 | 依赖较多、需要区分阻断程度时填写 |
| 变更影响说明 | 选填 | 变更频繁的需求建议填写 |
| 实现类型、实现载体 | 选填 | 实现项类型多样、需要分类统计时填写 |
| 覆盖说明 | 选填 | 部分覆盖时建议填写，写明缺口 |
最小可用字段集可以压缩为八个：需求编号、需求名称、上游需求编号、依赖类型、实现项编号、覆盖状态、验证项编号、基线版本。这套字段能支撑“需求—依赖—实现—验证—基线”的基本链路，适合刚建立追溯表的团队。随着评审和审计要求提高，再补充负责人、依赖方向、变更影响说明等字段。
常见的断链情形有三类：需求编号在子表中写错或改写，导致关联失效；依赖只记了上游名称没记编号，上游改名后无法定位；覆盖状态长期停留在“部分覆盖”而验证结论未回填，导致统计结果失真。建表时把这三类情形列为检查项，比事后补录更省成本。
填写示例：一条需求从依赖到实现覆盖的完整记录
以下示例为演示情景，用于说明三张表如何联动，数据不代表真实项目。
示例需求主表行
| 需求编号 | 需求名称 | 需求层级 | 需求版本 | 需求状态 | 需求负责人 | 验收口径 | 基线版本 |
|---|---|---|---|---|---|---|---|
| REQ-042 | 订单导出支持按时间范围筛选 | 系统需求 | V1.2 | 实现中 | 产品经理A | 导出文件包含筛选区间内全部订单 | BL-2024-06 |
示例依赖关系行
| 关系编号 | 需求编号 | 上游需求编号 | 依赖类型 | 依赖方向 | 依赖强度 | 变更影响说明 | 依赖状态 |
|---|---|---|---|---|---|---|---|
| DEP-108 | REQ-042 | REQ-031 | 接口依赖 | 本需求依赖上游 | 强 | 上游查询接口字段调整将导致导出模板重做 | 已满足 |
示例实现覆盖行
| 覆盖编号 | 需求编号 | 实现项编号 | 实现类型 | 实现载体 | 覆盖状态 | 覆盖说明 |
|---|---|---|---|---|---|---|
| COV-215 | REQ-042 | TASK-330 | 开发任务 | 订单服务-导出模块 | 部分覆盖 | 筛选逻辑已实现，分页导出待补 |
示例验证与基线行
| 验证项编号 | 验证结论 | 基线版本 | 最后更新时间 |
|---|---|---|---|
| TC-501 | 待验证 | BL-2024-06 | 2024-06-18 |
这组示例中，REQ-042 通过 DEP-108 指向上游 REQ-031，说明导出功能依赖上游查询接口；通过 COV-215 指向 TASK-330，说明实现承接在订单服务的导出模块。覆盖状态为“部分覆盖”，覆盖说明写明了分页导出的缺口，验证项 TC-501 的结论为“待验证”，与部分覆盖的状态一致。若后续分页导出完成，应更新覆盖状态为“已覆盖”，回填验证结论，并同步最后更新时间。
调整与维护：字段裁剪、版本更新与覆盖复核
追溯表的价值在于长期可用，建表只是起点。字段裁剪、变更联动和定期复核需要形成固定规则，否则表格会在两三个版本后失去可信度。
按团队规模与流程裁剪字段
| 场景 | 建议保留 | 可裁剪 |
|---|---|---|
| 小团队、需求数量少 | 最小可用字段集八项 | 需求层级、需求来源、优先级、依赖强度、实现类型 |
| 多团队协作、接口较多 | 最小集＋依赖方向、依赖强度、变更影响说明、实现载体 | 需求来源、优先级 |
| 需要审计或合规留痕 | 全部字段，另加确认人、最后更新时间 | 按审计要求逐项确认，不建议裁剪 |
需求变更时的依赖与覆盖更新规则
需求内容变更时，先更新主表的需求版本和最后更新时间，再检查依赖子表中以该需求为上游的行，逐条判断变更影响说明是否仍然成立；随后检查实现覆盖子表，把受影响的覆盖状态改为“覆盖待确认”，待实现调整和验证完成后回填。需求关闭时，依赖状态改为“已失效”或保留“已满足”，覆盖状态保留最终结论，便于后续回溯。
覆盖状态复核的时点与责任人
建议在三个时点复核覆盖状态：需求进入验证阶段前，由需求负责人确认实现项是否齐全；版本基线建立时，由测试负责人核对验证结论与覆盖状态是否一致；发布完成后，由项目负责人抽查部分覆盖和未覆盖的需求，确认缺口是否有明确处理计划。复核结果直接更新覆盖状态和最后更新时间，不另建台账。
追溯表的版本与归档方式
追溯表本身按基线版本归档：每个基线对应一份只读快照，记录当时的依赖关系、覆盖状态和验证结论；日常维护在工作副本上进行，基线发布时生成快照。这样既保留历史结论，又避免在归档表上继续修改造成口径混乱。
当追溯关系数量增长、跨项目依赖增多时，手工表格的维护成本会明显上升。ONES 围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，需求发生变化时可沿关联关系分析受影响的任务、测试和交付内容。对于需要把追溯表从个人表格转为团队协作资产的场景，可以把需求主表对应为需求工作项，把依赖子表和覆盖子表对应为工作项之间的关联关系，让字段更新与状态流转在同一处完成。
常见问题
需求数量不多的小团队，追溯表可以只保留哪些字段？
可以先用最小可用字段集八项：需求编号、需求名称、上游需求编号、依赖类型、实现项编号、覆盖状态、验证项编号、基线版本。这套字段能支撑从需求到依赖、实现、验证和基线的基本链路。需求层级、需求来源、优先级、依赖强度、实现类型等字段，等评审或排期管理需要时再补。需要留意的是，需求负责人和需求状态建议尽早保留，否则变更和复核容易无人承接。
一个需求对应多个实现项时，覆盖状态怎么填？
按实现项逐行记录，每行填写该实现项自身的覆盖状态，再在主表或汇总视图中按需求汇总。汇总口径建议统一为：只要存在未覆盖的实现项就记为未覆盖，存在缺口记为部分覆盖，全部满足验收口径才记为已覆盖。如果团队习惯在需求层级只保留一个状态，需要在填写口径中写明汇总规则，避免不同人按不同方式判断。
需求变更后，依赖子表和覆盖子表要按什么顺序更新？
先更新主表的需求版本和最后更新时间，再处理依赖子表：找出以该需求为上游的行，逐条判断变更影响说明是否仍然成立，必要时调整依赖状态。随后处理覆盖子表，把受影响的覆盖状态改为“覆盖待确认”，待实现调整和验证完成后回填结论。顺序上先依赖后覆盖，可以避免实现项按旧的上游约束推进。
追溯表用在线表格还是放进研发管理工具里维护？
取决于追溯关系的规模和变更频率。需求数量少、依赖关系简单时，在线表格配合固定模板即可运转。跨项目依赖增多、需求变更频繁时，手工维护关联和状态同步的成本会上升，可以考虑把需求主表对应为需求工作项、把依赖与覆盖对应为工作项之间的关联关系，让字段更新与状态流转在同一处完成。ONES 围绕需求、基线、版本和变更建立统一管理对象，测试用例、缺陷、版本和发布过程可以关联到需求链路中，需求变化时可沿关联关系分析受影响的任务、测试和交付内容。
覆盖状态复核应该由谁负责，多久做一次？
建议按节点而非固定周期复核：需求进入验证阶段前由需求负责人确认实现项是否齐全；版本基线建立时由测试负责人核对验证结论与覆盖状态是否一致；发布完成后由项目负责人抽查部分覆盖和未覆盖的需求，确认缺口有明确处理计划。复核结果直接更新覆盖状态和最后更新时间，不另建台账，减少两套记录对不上的情况。
