需求遗漏实现指已经进入实现范围的需求，在需求到实现再到验证的追溯链路中找不到对应的实现记录，因而无法确认它是否被真正做出来。它属于追溯缺口的一种，判断依据是需求条目与实现条目之间的对应关系是否成立，与开发进度是否完成、测试是否覆盖属于不同口径。下面从定义、边界、相邻概念、常见误判和团队统一口径五个方面展开。
要点总览（TL;DR）
- 需求遗漏实现指需求已进入实现范围，但在需求到实现的追溯链路中找不到对应实现记录，无法确认是否被真正做出来。
- 判断依据是需求条目与实现条目的对应关系是否成立，与开发进度是否完成、测试是否覆盖属于不同口径。
- 需求未关联实现、实现未关联需求、需求遗漏实现是追溯缺口的三个方向，遗漏实现是需求未关联实现中“应实现而未实现”的具体表现。
- 测试没覆盖、需求变更或取消、实现条目标题相似但未关联，都不应直接判为需求遗漏实现。
- 统一口径的做法是先约定需求、实现、验证三类对象的记录方式，评审时按方向分列缺口，未确认项标注待核实。
需求遗漏实现指什么
用一句话概括：需求存在，实现记录缺失。这里的“存在”指需求已经形成可追踪的条目并进入实现范围，“缺失”指在追溯链路中找不到与之对应的实现条目，例如开发任务、代码提交记录或实现说明。两者同时成立，才构成需求遗漏实现。
判断依据落在需求与实现条目的对应关系上，而不是看需求文档写了多少、开发人员口头说做了多少。具体可以从三个检查点确认：需求条目是否有唯一标识并处于已确认或已排期状态；实现侧是否有可识别的条目，并且该条目明确指向这条需求；这条对应关系是否能在评审或追溯分析中被复现和查证。三个检查点都通过，说明对应关系成立；实现侧找不到条目，才记为遗漏实现。
需要与“需求没做完”区分开。需求没做完描述的是实现进度，开发任务可能已经建立、正在推进，只是尚未完成；需求遗漏实现描述的是记录与关联是否成立，即使开发已经完成，只要追溯链路中没有建立对应关系，仍然属于遗漏实现。反过来，一条需求关联了实现条目但进度停留在进行中，属于进度问题，不记为遗漏实现。把这两类问题分开记录，评审时才能分别找到责任人和处理方式。
定义边界：哪些情况算、哪些不算
需求遗漏实现的观察范围限定在需求到实现和验证这条链路内，起点是需求条目进入实现范围，终点是实现条目与需求的对应关系可以被查证。超出这条链路的问题，归入相邻主题处理，避免同一个术语被用来描述不同性质的问题。
以下情况属于本概念的讨论范围：需求已确认并纳入本次实现范围，实现清单中找不到对应条目；需求与实现条目曾经建立关联，但关联被删除或指向了错误的需求；同一需求对应多个实现条目时，部分条目缺失导致覆盖不完整。
以下情况不属于需求遗漏实现，应归入其他口径：测试用例是否覆盖需求、测试是否充分，属于测试覆盖与需求验证的范畴，不在本节展开；需求从提出到退役的跨阶段治理、基线管理和变更影响分析，属于 ALM 应用生命周期管理的范围；需求本身的变更、取消和优先级调整，属于需求变更管理，不构成遗漏实现。
还有一种需要单独标注的情况：评审时发现某条需求在实现清单中找不到条目，但尚不能确认实现是否以其他形式存在，例如在别的项目空间、由外部团队承接或记录在链路之外。此时只能记为待核实，不能直接判定为遗漏。待核实项需要指定核实人和核实期限，核实完成后再归入遗漏实现或关闭，否则会把记录缺失误判成实现缺失。
追溯缺口的两类方向与遗漏实现的关系
需求与实现之间的追溯缺口可以从两个方向观察，需求遗漏实现是其中一个方向下的具体表现。把方向分清，评审记录才不会把不同性质的问题混在同一张清单里。
| 缺口类型 | 观察方向 | 典型表现 | 判断依据 |
|---|---|---|---|
| 需求未关联实现 | 从需求侧看实现 | 需求条目存在，实现侧没有对应条目 | 需求条目下查不到任何实现记录 |
| 实现未关联需求 | 从实现侧看需求 | 开发任务或提交存在，找不到来源需求 | 实现条目上没有指向需求的关联 |
| 需求遗漏实现 | 从需求侧看实现，且需求应实现 | 需求已进入实现范围，实现记录缺失 | 需求状态为已确认或已排期，实现侧无条目 |
需求未关联实现描述的是需求侧有记录、实现侧没有对应条目的状态，它覆盖的范围更宽，既包括应当实现却没有记录的情况，也包括尚未排期、暂不实现的情况。需求遗漏实现是其中“应实现而未实现”的那部分，强调需求已经进入实现范围这一前提。实现未关联需求则是反方向的缺口，实现侧有工作项，但需求侧找不到来源，常见于临时插入的开发任务或跨团队转交的工作。
三类缺口共同构成需求与实现对应关系的缺口视图。评审时按方向分别记录，可以避免把“需求没排期”和“需求排期了但没建实现条目”记成同一类问题；追溯分析时按方向汇总，也能看出缺口主要集中在需求侧登记不全还是实现侧关联不全，从而决定先补哪一端的记录习惯。
一个具体例子与常见误解
假设一次版本评审中，产品经理列出本期确认的十二条需求，逐条核对实现清单。其中一条“支持按组织架构导出成员列表”在需求库中有条目、状态为已确认，但在开发任务清单里找不到任何对应任务，代码仓库中也没有相关提交记录。评审记录将该条标记为需求遗漏实现，并指定开发负责人当天核实是否存在链路之外的实现。第二天核实确认没有开发任务，该条正式归入遗漏实现，补建任务并重新排期。这个例子说明，判定动作发生在需求条目与实现条目的对照环节，结论需要经过核实才能落定。
围绕这个概念，有三种常见误读需要澄清。
误解一：把需求遗漏实现等同于需求变更或需求取消。需求变更描述的是需求内容或范围发生调整，需求取消描述的是需求不再实施，两者都可能让实现条目消失，但性质是需求侧的决定。遗漏实现描述的是记录与关联缺失，即使需求内容没有任何变化，只要实现条目没有建立，同样成立。评审时先确认需求状态，再判断是否属于遗漏实现。
误解二：把测试没覆盖也算作需求遗漏实现。测试是否覆盖需求，考察的是验证环节的完整性，属于测试覆盖与需求验证的口径。一条需求可能已经建立了开发任务并完成开发，只是没有对应的测试用例，这种情况记为测试覆盖缺口，不记为遗漏实现。两类缺口可以在同一张评审表中分列记录，但归类和责任人不同。
误解三：看到实现条目就认为需求已被覆盖，忽略关联是否成立。实现清单里存在一条标题相似的任务，并不等于它关联到了这条需求。如果任务没有指向需求条目，或者指向了另一条需求，从追溯链路看这条需求仍然处于未关联实现的状态。核对时要看关联关系本身，而不是凭标题相似做判断。
在评审与追溯分析中如何统一口径
统一口径的关键是把术语落到可操作的记录规则上，让不同角色在评审会上说的是同一件事。可以从四个动作入手。
第一，先约定需求、实现、验证三类对象的记录方式。明确需求以什么条目承载、实现以什么条目承载、验证以什么条目承载，以及三类条目之间通过什么方式建立关联。记录方式确定后，“找不到对应条目”才有明确的查找范围，不会因为对象定义不同而各说各话。
第二，评审时按方向分别记录缺口类型。把需求未关联实现、实现未关联需求、需求遗漏实现分列在同一张评审表中，每条记录写明需求编号、缺口方向、发现依据和处理人。分列记录的好处是汇总时可以直接看出缺口分布，也便于后续按类型统计趋势。
第三，对未确认项标注待核实，避免口径混用。评审现场无法确认实现是否存在于链路之外时，统一记为待核实并写明核实人和期限，不直接写成遗漏实现。待核实项在下次评审前完成闭环，要么转为遗漏实现，要么关闭并补充关联记录。
第四，借助需求与工作项的关联关系承载追溯记录。关联关系是判断缺口方向的直接依据，团队可以把需求条目与开发任务、测试任务的关联作为评审前的准备动作，评审时直接查看关联结果，减少现场翻找。ONES ALM 方案以数字线程贯通需求、开发、测试、变更与发布，支撑过程追溯和影响分析；在这一流程中，需求条目与实现任务的关联记录可以作为评审时核对缺口方向的依据，需求变化时也能沿关联关系查看受影响的任务和测试内容。对于采用 ASPICE 相关流程的团队，ONES ASPICE 解决方案支持跨域协作全过程的可追溯性，可作为统一记录方式的承载环境之一。
口径统一之后，团队还可以定期做一次追溯分析：按缺口方向统计数量，观察需求侧登记不全和实现侧关联不全哪一端更集中，再针对性地调整记录习惯。这样，“需求遗漏实现”就不只是一个评审时用到的术语，而成为团队持续改善追溯完整性的一个观察指标。
常见问题
需求遗漏实现和需求没做完有什么区别？
需求没做完描述的是实现进度，开发任务可能已经建立、正在推进，只是尚未完成；需求遗漏实现描述的是记录与关联是否成立。即使开发已经完成，只要追溯链路中没有建立需求与实现条目的对应关系，仍然属于遗漏实现。反过来，一条需求关联了实现条目但进度停留在进行中，属于进度问题，不记为遗漏实现。把这两类问题分开记录，评审时才能分别找到责任人和处理方式。
评审现场无法确认实现是否存在时，应该怎么记录？
评审时发现某条需求在实现清单中找不到条目，但尚不能确认实现是否以其他形式存在，例如在别的项目空间、由外部团队承接或记录在链路之外，此时只能记为待核实，不能直接判定为遗漏。待核实项需要指定核实人和核实期限，核实完成后再归入遗漏实现或关闭。这样可以把记录缺失与实现缺失区分开，避免口径混用。
实现清单里有一条标题相似的任务，能说明需求已被覆盖吗？
不能。实现清单里存在一条标题相似的任务，并不等于它关联到了这条需求。如果任务没有指向需求条目，或者指向了另一条需求，从追溯链路看这条需求仍然处于未关联实现的状态。核对时要看关联关系本身，而不是凭标题相似做判断。这也是需求遗漏实现容易被误判的常见情形之一。
测试没有覆盖某条需求，算不算需求遗漏实现？
不算。测试是否覆盖需求，考察的是验证环节的完整性，属于测试覆盖与需求验证的口径。一条需求可能已经建立了开发任务并完成开发，只是没有对应的测试用例，这种情况记为测试覆盖缺口，不记为遗漏实现。两类缺口可以在同一张评审表中分列记录，但归类和责任人不同。
团队怎样借助工具承载需求与实现的关联记录？
关联关系是判断缺口方向的直接依据，团队可以把需求条目与开发任务、测试任务的关联作为评审前的准备动作，评审时直接查看关联结果。ONES ALM 方案以数字线程贯通需求、开发、测试、变更与发布，支撑过程追溯和影响分析；在这一流程中，需求条目与实现任务的关联记录可以作为评审时核对缺口方向的依据。对于采用 ASPICE 相关流程的团队，ONES ASPICE 解决方案支持跨域协作全过程的可追溯性，可作为统一记录方式的承载环境之一。
