需求确认的依据由四类材料构成：需求来源与业务目标证据、需求条目本身的可核验描述、约束与依赖信息、评审记录与决策授权。确认动作是把这些依据逐条对照需求条目，由需求提出方、产品负责人、研发与测试代表共同判定“可进入开发”或“退回补充”，并留下签字或系统状态记录。本文聚焦需求评审与确认这一环节，说明依据清单、确认步骤、角色分工与完成检查。
要点总览（TL;DR）
- 需求确认的依据分四类：需求来源与业务目标证据、需求条目的可核验描述、约束与依赖信息、评审记录与决策授权，四类齐备才能判定进入开发。
- 确认流程按提交前自查、预审、确认会、结论登记、状态变更五步推进，完成标志是需求状态变为已确认且无未指派遗留项。
- 依据不全时判定为有条件通过或退回，写清缺失项、补充责任人与复检时点，避免条件在开发启动后失去约束力。
- 常见缺口集中在口头确认无记录、验收标准写成功能描述、依赖未落实即通过三类，处理方式是在会上直接给出判定与补充安排。
- 确认结论与遗留项应随需求条目留痕，借助工作项状态与文档关联实现复检和追溯。
需求确认要核对的四类依据
确认会上的表态应当有材料支撑。把依据按四类归并，可以避免会上临时翻找资料，也便于逐条核对。四类依据分别回答四个问题：这个需求为什么做、要做成什么样、受什么限制、谁同意进入开发。
| 依据类别 | 核心问题 | 字段级清单 |
|---|---|---|
| 需求来源与业务目标证据 | 为什么做 | 原始诉求记录（工单、访谈纪要、客户反馈原文）、业务方确认人及确认时间、目标指标（如转化率、处理时长、覆盖范围）及当前基线值 |
| 需求条目描述 | 做成什么样 | 范围边界（包含什么、不包含什么）、验收标准（可测试的判定条件）、优先级及排序理由、明确的非目标 |
| 约束与依赖 | 受什么限制 | 接口方及对接人、合规或安全要求、技术可行性结论、外部依赖的交付时间 |
| 评审与授权记录 | 谁同意 | 参会角色与姓名、评审结论、遗留问题清单、每项遗留问题的责任人 |
四类依据中，前两类决定需求值不值得做、做得对不对，后两类决定能不能按时按规做出来。核对时按条目逐项打勾，缺失项当场记录，作为判定“有条件通过”或“退回”的直接依据。
从需求提出到确认通过的操作步骤
依据清单是静态材料，确认流程则要说明每一步谁做什么、产出什么、何时算完成。下面五个步骤覆盖从提交到状态变更的完整路径。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交前自查 | 原始诉求、业务目标 | 需求提出方补齐来源记录、目标指标与验收标准草稿 | 需求条目初稿及附件 | 四类依据中至少来源、目标、验收标准三项已填写 |
| 预审 | 需求条目初稿 | 产品负责人检查描述完整性，判断是否与业务目标一致 | 预审意见：进入确认会或退回补充 | 每条需求有明确的预审结论 |
| 确认会 | 完整依据材料 | 逐条对照四类依据，判定通过、有条件通过或退回 | 会议结论与遗留项清单 | 每条需求有唯一结论，遗留项有责任人 |
| 结论登记 | 会议结论 | 将状态、通过条件、遗留项与责任人写入需求记录 | 更新后的需求记录 | 记录中的结论与会议结论一致 |
| 状态变更 | 更新后的需求记录 | 确认无未指派遗留项后变更需求状态 | 状态为“已确认”的需求 | 需求状态变为已确认，且无未指派遗留项 |
预审环节的价值在于把明显不完整的条目挡在确认会之前，让会议时间用于讨论有争议的判断，而不是补填基本信息。确认会上的“有条件通过”必须写清条件内容、补充责任人和复检时点，否则条件会在开发启动后失去约束力。
各角色在确认中的职责与交付物
确认会容易变成无人负责的表态会，原因通常是依据由谁提供、结论由谁拍板没有事先约定。下表按角色列出其负责的依据与交付物。
| 角色 | 负责提供的依据 | 交付物 |
|---|---|---|
| 需求提出方 | 来源证据、业务目标、优先级排序理由 | 原始诉求记录、目标指标说明、优先级排序依据 |
| 产品负责人 | 需求条目完整性、范围边界 | 预审意见、确认结论、范围与非目标说明 |
| 研发代表 | 技术可行性、工作量粗估、依赖识别 | 可行性结论、粗估工作量、依赖清单及对接人 |
| 测试代表 | 验收标准的可测性 | 验收标准评审意见，必要时给出可测试的改写建议 |
| 记录人 | 会议过程信息 | 结论、通过条件、遗留项与责任人的登记记录 |
判定权集中在产品负责人，但判定必须建立在其他角色交付的依据之上。研发代表给出的可行性结论和依赖清单，是确认会判断“能否进入开发”的关键输入；测试代表对验收标准的意见，决定需求在开发完成后能否被客观验证。记录人的职责不只是记会议纪要，而是确保每条结论都能在需求记录中查到对应条目。
一个需求确认的完整示例
以下为演示情景，用于说明依据核对与判定记录如何落地。
需求背景：客服团队提出“工单列表支持按客户等级筛选”，来源为季度客服访谈纪要，业务方确认人为客服主管，目标指标是高级客户工单首次响应时长从4小时降至2小时，当前基线为4小时。
逐类核对过程：
- 来源与目标：访谈纪要与确认人齐全，目标指标有基线值，通过。
- 需求条目描述：范围写明“仅列表页筛选，不含导出”，验收标准初稿写为“筛选功能可用”，测试代表指出该描述无法验证，需改为“选择任一客户等级后，列表仅显示该等级工单，且筛选条件在翻页后保持”。
- 约束与依赖：筛选依赖客户等级数据由CRM系统同步，接口方尚未确认同步频率与字段口径。
- 评审与授权：参会角色齐全，但上述两项缺口未解决。
判定为有条件通过：条件一，测试代表在确认会后两个工作日内提交改写后的验收标准；条件二，研发代表在三个工作日内与CRM接口方确认同步频率与字段口径并回填依赖清单。复检时点定为本迭代计划会前，由产品负责人复检两项条件完成情况后变更状态。
判定为退回的情形：若该需求仅有口头提出、无访谈记录或工单原文，且目标指标缺失，则应判定退回，缺失依据为“来源证据”与“目标指标”，补充责任人为需求提出方，补充期限为五个工作日，补齐后重新进入预审。
确认完成的检查项与常见缺口
确认会结束前，可用以下清单逐项核对，全部满足才将需求状态变更为已确认。
- 每条需求都有来源记录，且与业务目标一一对应。
- 验收标准可被测试验证，包含具体输入、预期结果与判定条件。
- 依赖方已确认交付时间与接口口径，并有对接人姓名。
- 结论、通过条件、遗留项均有责任人和期限。
- 需求记录中的状态与会议结论一致，无未指派遗留项。
依据缺失时最常见的三类缺口值得单独留意。一是口头确认无记录，会上达成一致但未写入需求记录，后续无法追溯谁在何时同意了什么。二是验收标准写成功能描述，例如“支持筛选”“优化体验”，测试无法据此设计用例，开发完成后也难判定是否达标。三是依赖未落实即通过，接口方时间和字段口径都未确认，需求进入开发后被动等待，进度风险在确认阶段就已埋下。这三类缺口的共同处理方式是：在确认会上直接判定为有条件通过或退回，并写清补充责任人与复检时点。
用工作项与文档承载确认依据
依据清单和确认结论如果只停留在会议纪要里，复检和追溯时会重新翻找。把依据落到协作工具中，可以让状态、结论与遗留项随需求条目一起流转。
具体承载方式可以按以下对应关系安排：需求条目作为工作项，承载描述、范围边界、验收标准与当前状态；来源证据（访谈纪要、工单原文、业务方确认记录）与评审记录以文档或附件形式关联到该需求；确认结论、通过条件与遗留项通过状态流转和字段留痕，使每条需求的历史判定可查；复检时点由待办或提醒机制承接，到期提醒责任人处理。
ONES 在这一环节可提供工作项与文档层面的承载。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题，并直接执行后续操作。在需求确认场景中，这意味着确认会前可以基于已有工作项和 Wiki 中的需求文档快速梳理待核对条目，会上形成的结论可保存为工作项或 Wiki 页面内容，减少页面切换和重复录入；基于指定 Wiki 页面组提问并附引用来源的方式，也便于复检时定位依据出处。具体字段配置与状态流转方案需结合团队现有的需求管理设置确定。
常见问题
需求确认会开完了，但部分依据当场补不齐，应该怎么判定？
当场补不齐的依据不要用“先通过、后面再补”处理，而是判定为有条件通过，并把条件写成可核验的条目：缺什么依据、由谁在什么期限内补齐、何时复检。复检时点通常放在进入迭代计划之前，由产品负责人核对条件完成情况后再变更状态。如果缺失的是来源证据或目标指标这类基础依据，直接退回补充更合适，补齐后重新进入预审。
需求提出方只给了口头诉求，没有工单或访谈记录，能进入确认吗？
可以进入预审，但不宜直接判定通过。来源证据的作用是让后续追溯知道这个需求由谁提出、基于什么场景，口头诉求缺少这一层记录。可行的做法是由需求提出方补一份简短的诉求说明，写清提出人、使用场景和期望结果，作为来源记录附在需求条目上，再进入确认会。补充成本不高，但能避免开发过程中需求被反复解释。
验收标准写到什么程度才算可测？
可测的验收标准通常包含三个要素：具体输入或操作、预期结果、判定条件。例如“选择任一客户等级后，列表仅显示该等级工单，且筛选条件在翻页后保持”，测试人员可以据此设计用例并给出通过或不通过的结论。写成“支持筛选”“优化体验”这类功能描述，测试无法验证，开发完成后也难判定是否达标，测试代表应在确认会上提出改写建议。
有条件通过的需求，条件一直没完成怎么办？
条件需要绑定责任人和期限，并在需求记录中保持可见。到了复检时点仍未完成的，由产品负责人决定两种处理：条件不影响开发启动的，可保留条件并继续跟踪；条件涉及接口口径或验收标准这类关键依据的，应退回补充，暂不进入开发。关键是让条件状态在需求记录中可查，而不是停留在会议纪要里靠人记忆。
确认结论和依据怎么留存，方便以后追溯？
建议把依据和结论都挂在需求条目上：需求条目承载描述、范围、验收标准与状态；来源记录和评审记录以文档或附件形式关联；结论、通过条件与遗留项写入字段或状态流转记录。这样复检时从需求条目就能看到历史判定。ONES 的工作项与文档能力可以承载这类关联，ONES Assistant 智能助手可基于项目数据与 Wiki 页面回答问题并附引用来源，便于定位依据出处，具体字段与状态配置需结合团队现有设置确定。
