需求到交付的追踪矩阵

这个场景能帮你做什么

需求文档和任务表各自完整，仍可能出现有需求没安排工作、有交付没验证、做了工作却找不到需求依据。本任务把需求连接到目标、工作包、交付物和验收证据，形成覆盖缺口清单。

开始前需要准备什么

准备当前需求清单及编号、批准范围、业务目标、工作分解、交付清单、验收条目和已有验证记录。注明每份资料的版本和状态；以后版本、已取消和本期批准需求分开。

具体怎么做

第一步：建立需求主清单

让 WorkBuddy 保留原编号、需求描述、来源、责任人、优先级、版本、状态与状态日期。检查同号不同义和同义不同号，不自行改编号消除冲突。

第二步：逐层建议对应关系

逐项连接业务目标、工作包、交付物、验收条目和证据位置。允许一对多和多对一，不为表格整齐强行一对一。

每个对应说明依据。只有名称相似而没有内容证明时，列建议关联待确认。软件项目可关联设计开发测试，一般项目使用实际工作阶段。

第三步：反查覆盖缺口

从需求查到交付，找无任务、无产物或无验证的需求；再从工作包反查需求，找无批准依据的新增工作。已取消、推迟的需求核决定依据，不混入本期遗漏数。

第四步：确认状态并维护版本

任务被标完成，不代表需求已经验证。让工具分别保留任务状态与验收状态，交负责人确认关联和实际结果。批准变更后同步矩阵版本，保留历史状态。

可以直接交给 WorkBuddy 的完整要求

请把需求清单与目标、工作包、交付物、验收和证据建立追踪矩阵。
保留原需求编号、描述、来源、优先级、版本及状态日期，不自动改号或改变批准状态。
每项关联列出依据；允许一对多、多对一。缺证据或只靠标题猜测的关系标待确认。
分别输出无任务、无交付、无验证证据、范围外工作和状态冲突。取消及延期项保留批准依据，不算作普通遗漏。
任务完成与需求验收分开，不以矩阵填满证明功能已实现。输出矩阵及覆盖缺口，原文件不改动。

完成后会得到什么

矩阵包含需求编号、描述、来源、目标、工作包、交付物、验收要求、证据、相关版本和确认状态；缺口表明确要补关系、补工作还是补验证。

结果应该怎么检查

核本期批准需求总数；多行展开不能重复计数；取消和延期有依据；每条关键关联能回原文。检查工具是否把“有测试任务”误写成“测试已通过”。

遇到这些情况怎么处理

不同材料编号不一致，先建立经确认的编号对应；需求过于宽泛，先拆到可交付和验证的层次；缺交付记录，保留未验证，不凭执行人一句完成关闭需求。

哪些由工具处理，哪些必须人工决定

WorkBuddy 建议关联和发现缺口，业务及交付负责人确认覆盖关系，验收人员确认结果。工具不凭文档存在证明实际实现，也不批准需求变更。