需求关闭指单项需求在交付物验收通过、遗留问题有明确处置、相关记录可追溯后，由约定角色把需求状态置为关闭。它解决的是“这条需求能不能结案”的问题，判断依据是验收结论、遗留项处置和记录完整性。本文围绕单项需求展开，给出准入条件、操作步骤、角色分工、记录示例与完成检查表；项目整体验收与产品整体效果评估不在讨论范围。文中也会说明如何用ONES承载关闭记录与状态流转。
要点总览（TL;DR）
- 需求关闭的判断依据是验收结论、遗留项处置和记录完整性三项，缺任何一项都不应进入关闭流程。
- 关闭按四步执行：提交关闭申请、核对证据、确认关闭或退回补充、归档并通知，其中核对证据是整条流程的关键控制点。
- 需求负责人负责证明需求可以关闭，验收或评审人负责判断证据是否成立，提出人确认结果与原始诉求一致，测试与文档角色提供证据材料。
- “有条件通过”可以关闭，前提是遗留项有责任人、处理方式和计划时间，并被提出人接受；关闭后仍需保留遗留项与后续处理的关联。
- 关闭后用检查表逐项核对验收结论、遗留项去向、记录追溯、提出方知晓和状态一致性，并定期抽查已关闭需求以收紧准入条件。
需求关闭前要满足哪些准入条件
需求关闭的常见问题，是交付物已经上线、需求却长期挂在“待关闭”状态，或者在没有验收结论的情况下被直接关掉。要避免这两种情况，需要先把关闭准入条件写清楚：满足哪些条件才允许提交关闭，缺哪一项就退回补充。下面这份清单可以直接作为团队的需求关闭准入模板，按项目实际情况增删条目。
| 准入条件 | 通过标准 | 需要的证据 |
|---|---|---|
| 验收结论已形成并留痕 | 验收人给出“通过”或“有条件通过”的明确结论，写明验收范围、时间与验收人 | 验收记录、验收单或验收会议纪要 |
| 遗留问题与缺陷有处置结论 | 每个遗留项都有责任人、处理方式（本次修复、转后续需求、接受风险）和计划时间 | 遗留项清单、缺陷单状态 |
| 需求文档、变更记录与交付物可追溯 | 需求描述、验收标准、变更记录与最终交付物能互相对应，版本一致 | 需求文档、变更单、交付物清单 |
| 提出方与承接方对关闭口径一致 | 双方对“需求已满足到什么程度”没有分歧，或有分歧但已形成书面结论 | 确认记录、沟通结论 |
这四项条件中，验收结论和遗留项处置是硬性门槛，缺少任何一项都不应进入关闭流程。文档与变更记录的可追溯性决定了关闭之后还能不能复盘：如果需求中途改过范围，而变更记录缺失，关闭时看似通过，后续追溯就会断链。提出方与承接方口径一致则是一项容易被忽略的条件，尤其在“有条件通过”的场景下，双方对遗留项的理解必须写进同一份记录，避免关闭后反复翻案。
准入条件应随需求类型调整。例如内部工具类需求可以简化验收形式，但遗留项处置和记录追溯仍需保留；对外交付类需求则应增加客户确认环节。条件一旦确定，就作为关闭申请的核对依据，而不是每次关闭时临时讨论。
需求关闭的操作步骤：从提交申请到归档
准入条件解决“能不能关”，操作步骤解决“怎么关”。建议把关闭拆成四个步骤，每一步都明确输入、动作、输出和完成标志，让提交人和评审人对进度有共同判断。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交关闭申请 | 验收结论、遗留项清单、需求文档与变更记录 | 需求负责人对照准入清单逐项核对，附上证据后提交关闭申请 | 关闭申请单，含证据附件与遗留项处置说明 | 申请单进入待评审状态，证据齐全 |
| 2. 核对证据 | 关闭申请单及附件 | 验收或评审人核对验收结论是否覆盖全部验收标准，遗留项是否都有处置结论 | 核对意见，列出缺失项或疑问项 | 核对意见形成，明确通过或退回 |
| 3. 确认关闭或退回补充 | 核对意见 | 通过则确认关闭并记录关闭时间与关闭人；退回则写明需补充的证据，由负责人补齐后重新提交 | 关闭结论或退回通知 | 需求状态更新为已关闭，或回到待补充状态 |
| 4. 归档并通知 | 关闭结论与全部证据 | 把验收记录、遗留项处置、变更记录与交付物归入同一需求记录，通知提出方和相关角色 | 归档完成的需求记录 | 提出方收到关闭通知，记录可被检索 |
第2步的核对是整条流程的关键控制点。核对人需要逐条比对验收标准与验收结论，确认没有“验收范围小于需求范围”的情况；对遗留项则要确认每一项都有明确去向，而不是笼统写“后续处理”。退回补充时，退回理由要具体到缺哪份证据、哪个遗留项没有结论，避免负责人反复猜测。
第4步的归档常被简化成“改个状态就结束”。归档的实际要求是让关闭后的需求仍可追溯：谁验收的、验收结论是什么、遗留项转到了哪里、交付物是哪个版本。通知对象至少包括需求提出人和承接团队负责人；涉及对外交付的需求，还应通知对接客户的角色。完成标志以提出方收到通知为准，而不是以状态变更完成为准。
谁负责关闭：角色分工与交付物
关闭环节涉及多个角色，职责不清时最容易出现“都以为对方会关”或“关了但没人认”的情况。下面按角色列出在关闭节点上的职责边界和应提交或确认的产物。
| 角色 | 关闭环节职责 | 提交或确认的产物 |
|---|---|---|
| 需求提出人 | 确认交付结果满足原始诉求，对“有条件通过”的遗留项表示接受或提出异议 | 验收确认意见、对遗留项处置的确认 |
| 需求负责人 | 对照准入条件整理证据，提交关闭申请，补齐退回项 | 关闭申请单、证据附件、遗留项处置说明 |
| 验收或评审人 | 核对验收结论与证据完整性，做出确认关闭或退回的决定 | 核对意见、关闭结论 |
| 测试角色 | 提供测试结论与缺陷状态，说明未修复缺陷的处置方式 | 测试报告、缺陷清单及状态 |
| 文档角色 | 确认需求文档、变更记录与交付物版本一致并完成归档 | 归档记录、文档版本说明 |
分工的核心是让“提交”和“把关”分开：需求负责人负责证明需求可以关闭，验收或评审人负责判断证据是否成立。提出人参与确认，保证关闭结果与原始诉求对得上。测试与文档角色提供的是证据，而不是关闭决定权，他们的产物构成关闭申请的材料基础。
出现争议时，需要有明确的裁决路径。常见做法是先由需求提出人与需求负责人就争议点形成书面说明，再由验收或评审人依据验收标准和变更记录给出结论；仍无法达成一致的，提交到需求所属业务线或产品线的负责人裁决，并把裁决结论写入需求记录。裁决路径应事先约定，而不是争议发生后再临时找人。争议期间需求保持未关闭状态，遗留项按“待裁决”单独登记，避免被默认关闭。
示例：一条需求从验收到关闭的完整记录
以下为演示情景，用于说明关闭记录的字段填写与判断逻辑，不代表真实客户案例。
某业务系统提出一条需求：“订单列表支持按客户名称模糊查询，返回结果不超过2秒。”需求负责人完成开发后进入验收。验收记录写明：验收时间、验收人、验收范围（查询功能与响应时间）、验收结论为“有条件通过”，因为客户名称包含特殊字符时的查询结果存在少量遗漏，已登记为遗留缺陷。
遗留项处置记录写明：该缺陷由开发角色在两周内修复，修复前在需求记录中标注影响范围；提出人确认接受这一处置方式。变更记录显示需求范围未发生变更，交付物版本与需求文档版本一致。测试报告附有查询功能的测试用例执行结果，缺陷清单中该缺陷状态为“待修复”，并关联到本需求。
关闭申请由需求负责人提交，附验收记录、遗留项处置说明、测试报告与文档版本说明。验收或评审人核对后确认：验收结论覆盖全部验收标准，遗留项有责任人和时间，证据齐全，于是确认关闭，记录关闭时间与关闭人。归档后，该需求记录中可检索到验收结论、遗留缺陷及其后续修复状态、变更记录和交付物版本；提出人收到关闭通知，并在通知中看到遗留缺陷的跟踪入口。
这个示例说明两个判断要点：一是“有条件通过”可以关闭，前提是遗留项有明确处置并被提出人接受；二是关闭不等于遗留项消失，归档记录需要保留遗留项与后续处理的关联，便于关闭后继续跟踪。
关闭完成检查：逐项判断是否真正闭环
关闭动作完成不等于闭环成立。建议在需求关闭后或关闭评审时，用下面的检查表逐项核对，任何一项不通过都应视为未真正闭环，需要补正或重新打开。
| 检查项 | 通过标准 | 证据与负责人 |
|---|---|---|
| 验收结论完整 | 结论明确，覆盖全部验收标准，有验收人和时间 | 验收记录，验收或评审人 |
| 遗留项有去向 | 每项遗留问题都有责任人、处理方式和计划时间，或已转为新需求 | 遗留项清单，需求负责人 |
| 记录可追溯 | 需求文档、变更记录、交付物版本能互相对应 | 归档记录，文档角色 |
| 提出方已知晓 | 提出人收到关闭通知，对结论无未决异议 | 通知记录，需求负责人 |
| 状态与记录一致 | 需求状态为已关闭，关闭时间、关闭人与记录一致 | 需求记录，验收或评审人 |
阻断关闭的情形主要包括：验收结论缺失或验收范围小于需求范围；遗留项没有处置结论，或处置结论没有责任人；变更记录缺失导致交付物与需求对不上；提出方对关闭有未决异议且未走裁决路径。出现这些情形时，应退回补充而不是先关闭再补记录。
关闭后的回看同样重要。可以按固定周期抽查已关闭需求，重点看遗留项是否按计划处理、转为新需求的事项是否进入需求池、关闭记录是否完整。抽查发现的问题应反馈到准入条件和检查表本身，例如某类遗留项反复被漏记，就把它加入准入清单的必填项。通过这种回看与纠偏，关闭机制才能随团队实践逐步收紧，而不是停留在一次性的流程文档上。
用ONES承载需求关闭的记录与流转
关闭流程落到工具上，需要解决三件事：需求状态能按流程流转、验收与遗留项等证据能和需求关联留存、关闭结论能交接给相关角色。ONES通过统一的业务需求池、产品需求池与工单系统，把业务反馈与产品开发联动起来，构建需求—任务—测试—缺陷的全流程闭环，这为单项需求的关闭提供了记录基础。
在状态流转方面，需求从提出、开发、验收到关闭的过程可以在统一的需求池与任务看板中推进，业务、产品经理与研发团队通过各自视角实时同步状态与信息，追溯需求与问题。关闭节点上的状态变更因此有据可查，提出人和承接方看到的是同一份需求记录。
在证据留存方面，ONES配套用例库、测试计划、缺陷管理与报告生成等功能，测试结论和缺陷状态可以作为关闭申请的材料；需求文档与变更记录则可归入同一需求的工作上下文。关闭时把验收结论、遗留项处置和文档版本关联到需求记录，归档后仍可检索。ONES还支持通过模板、权限和流程配置来适配团队约定的关闭流程，例如按需求类型设置不同的核对要求。
在评审与交接方面，关闭结论形成后，可通过需求记录和通知把结果交接给提出方与相关角色；ONES Assistant智能助手能够理解项目、工作项、迭代和Wiki页面等工作上下文，基于项目数据和团队知识回答问题并执行后续操作，可用于查询某条需求的验收与遗留项情况。具体使用哪些能力，应结合团队已有的需求池、工单与文档配置来确定。
常见问题
需求验收结论是“有条件通过”，还能关闭需求吗？
可以关闭，前提是遗留项已经写清楚。需要满足三点：每个遗留项都有责任人、处理方式和计划时间；提出人对这一处置方式明确表示接受；遗留项与需求记录保持关联，关闭后仍能跟踪到后续修复状态。
如果遗留项只写了“后续处理”而没有责任人和时间，或者提出方对处置方式有异议且未走裁决路径，就应退回补充，暂不关闭。
需求关闭后发现问题，应该重新打开还是新建需求？
判断依据是问题属于原需求范围还是新范围。原需求验收标准内的内容未达成、或验收结论本身有误，应重新打开原需求，保留原记录并补充说明；属于新增诉求、范围扩展或原需求未覆盖的场景，则新建需求并关联原需求，便于追溯来源。
两种处理都应在原需求记录中留下说明，避免关闭记录与后续动作脱节。
遗留缺陷转成后续需求后，原需求还需要保留缺陷信息吗？
需要保留。原需求记录中应写明该缺陷转为哪条新需求、由谁承接、计划时间，并保留缺陷单与新需求的关联。这样关闭后的需求仍能回答“当时遗留了什么、后来处理到哪一步”。
如果只在新需求里记录，原需求的关闭记录就出现断点，后续复盘时难以还原验收时的实际状态。
团队规模较小、角色合并时，关闭流程怎么简化？
可以合并角色，但要保留“提交”和“把关”两个动作的分离。例如需求负责人同时承担文档归档，验收或评审人由提出人或其指定代表担任，测试结论由开发角色提供并留痕。
准入条件中的验收结论、遗留项处置和记录追溯三项建议保留，可以简化形式，例如用一条记录代替正式验收单。争议裁决路径也应事先约定，避免角色合并后无人拍板。
关闭后的需求记录需要保留哪些内容，保留多久？
至少保留验收结论与验收人、遗留项清单及处置去向、需求文档与变更记录、交付物版本、关闭时间与关闭人、提出方的确认记录。保留期限按团队所在行业的合规要求和项目周期确定，对外交付类需求通常需要更长的留存时间。
保留的目的是让关闭后的需求仍可检索和复盘，因此记录之间要能互相对应，而不是分散存放。
