需求分析与澄清要解决的是“大家说的是不是同一件事”：把业务方口头的、零散的诉求，转成可执行、可验收的共同理解。本文按执行顺序给出五个步骤、一份追问清单、角色分工与记录模板，以及进入建模或评审前的完成检查，帮助产品、业务分析和项目角色完整走完一次澄清。
要点总览（TL;DR）
- 需求分析与澄清按五步执行：收集来源、识别干系人、拆解场景并追问、形成澄清记录、组织澄清会并书面确认，前两步定“听谁的、听什么”，后两步把理解固定下来。
- 追问围绕四组问题展开：业务场景与触发条件、角色权限与数据口径、异常路径与边界条件、非功能约束，落点是把“要快”“要灵活”这类模糊词改写成含条件与结果的可验证表述。
- 角色分工上，需求提出方说清目标并书面确认，业务负责人裁定口径与优先级，产品/分析人员组织追问并整理记录，开发与测试代表从实现和验证角度补问。
- 核心交付物是澄清记录、待确认清单和假设清单，每项未决项都要有责任人和计划关闭时间，确认与变更需留痕。
- 澄清完成的判断标准是理解一致、边界完整、表述可验证、未决项有处置、结论经书面确认，满足后才进入需求建模与正式评审。
需求分析与澄清的核心动作与执行顺序
一次完整的澄清可以拆成五步：收集来源、识别干系人、拆解场景并追问、形成澄清记录、组织澄清会并书面确认。前两步确定“听谁的、听什么”，第三步把模糊表述问实，后两步把理解固定下来。顺序不宜颠倒——在理解尚未对齐时直接进入结构化建模，返工成本会明显上升。
下表给出每一步的输入、动作、输出和完成标志，可直接作为执行模板使用。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集需求来源 | 业务方诉求、用户反馈、工单、会议记录、现有流程文档 | 汇总原始表述，标注提出人、提出时间、来源渠道，保留原话不做改写 | 需求来源清单 | 每条诉求都能追溯到提出人和原始场景 |
| 2. 识别干系人 | 需求来源清单、组织分工 | 区分提出方、业务负责人、实际使用角色、受影响的上下游岗位 | 干系人清单及各自关注点 | 每个关键角色都有明确对接人，无遗漏的受影响方 |
| 3. 拆解场景并追问 | 原始诉求、干系人清单 | 按“谁、什么触发条件、做什么、输入输出、异常与边界”逐项追问，把模糊词改写为可验证表述 | 场景描述、追问问答记录、待确认问题 | 主要场景能说清触发条件和结果，模糊词已替换或列入待确认 |
| 4. 形成澄清记录 | 追问记录、假设与未决项 | 整理成结构化记录：原始诉求、澄清后表述、假设、未决项及责任人 | 澄清记录、待确认清单、假设清单 | 每条未决项都有责任人和计划关闭时间 |
| 5. 澄清会与书面确认 | 澄清记录、待确认清单 | 组织澄清会逐条过未决项，当场确认或明确后续答复时间，会后发出书面结论 | 经确认的澄清记录、会议结论 | 需求提出方书面确认，未决项数量与风险已明确 |
需要说明的是，第3步的追问与第4步的记录是交替进行的：追问中发现的假设先记下来，记录整理时又会暴露新的空白，再回到追问。把这两步当成一次性的先后关系，容易在会议上才发现关键信息缺失。第5步的书面确认是进入后续建模和正式评审的入口，口头共识在跨角色传递中容易失真。
澄清会上要追问哪些问题：场景、角色、数据与边界
追问的目标是把“要一个报表”“优化一下流程”这类表述，变成别人能照着做、能照着验的表述。可以按四组问题推进，每组都有固定的追问角度。
业务场景与触发条件
- 这件事在什么情况下发生？由什么事件或时间点触发？
- 发生频率大概是多少？高峰期和日常有什么区别？
- 现在没有这个功能时，大家是怎么处理的？现有做法中哪一步最费时？
- 完成后，谁最先感知到变化？他希望看到什么结果？
角色、权限与数据口径
- 哪些角色会使用？各自能看什么、能改什么、不能做什么？
- 数据从哪里来，由谁录入或同步？以哪个系统为准？
- 关键指标的计算口径是什么：统计范围、时间口径、是否含异常数据？
- 同一份数据在不同角色眼中是否有不同口径？差异如何处理？
异常路径、边界条件与非功能约束
- 数据缺失、重复、超时、权限不足时，系统或流程应如何表现？
- 数量上限、并发量、响应时间、可用性有没有明确要求？
- 涉及审批或对外通知时，失败后是否需要重试、补发或人工介入？
- 有没有合规、审计或留痕方面的硬性要求？
把模糊词改写为可验证表述
追问的落点是改写。下面几组对照可以说明改写的方向：
| 模糊表述 | 追问后可能得到的可验证表述 |
|---|---|
| “报表要快” | “在日均10万条记录下，查询结果在3秒内返回；超过3秒需显示加载状态” |
| “支持导出” | “支持按当前筛选条件导出Excel，单次上限5万行，超出时提示缩小范围” |
| “审批要灵活” | “审批链按金额分三档：5000元以下一级审批，5000至5万元两级，5万元以上三级并可加签” |
| “提醒相关人员” | “任务到期前1天向负责人发送站内通知，逾期当天向负责人及其主管各发送一次” |
改写后的表述应包含可观察的条件和结果，能被开发估算、被测试设计用例。追问中一时答不上来的问题，不要当场猜测，直接进入待确认清单。
角色分工与澄清交付物
澄清不是产品一个人的事。需求提出方负责说清业务目标和验收期望，业务负责人对口径和优先级拍板，产品/分析人员负责组织追问并整理记录，开发与测试代表从实现和验证角度提出可行性问题。角色清晰，追问才不会停留在业务表面。
| 角色 | 主要职责 | 产出 |
|---|---|---|
| 需求提出方 | 说明业务背景、目标与期望结果，确认澄清结论 | 原始诉求、书面确认 |
| 业务负责人 | 裁定数据口径、优先级和跨部门规则冲突 | 口径说明、决策结论 |
| 产品/分析人员 | 组织追问、拆解场景、整理澄清记录、主持澄清会 | 澄清记录、待确认清单、假设清单 |
| 开发代表 | 提出实现约束、数据依赖和技术可行性问题 | 技术约束说明、待确认技术项 |
| 测试代表 | 从可验证角度追问异常路径和验收条件 | 验收要点、异常场景清单 |
三份核心交付物的字段建议如下：
- 澄清记录：需求编号、原始诉求、澄清后表述、涉及角色与场景、数据口径、假设、未决项、确认人、确认时间。
- 待确认清单：问题描述、影响范围、提出人、责任人、期望答复时间、当前状态。
- 假设清单：假设内容、依据、若不成立的影响、验证方式与验证时间。
确认与变更要留痕：每次澄清会形成书面结论，需求提出方确认后记录版本；后续口径或范围变化时，在原记录上标注变更内容和变更人，保留历史版本以便回溯。团队如果使用 ONES，可以把澄清记录放在 ONES Wiki 文档中，通过页面组关联对应项目，让需求与文档互相对应；成员可在线添加注释和评论反馈，页面版本可随时查看与回滚，便于保留确认过程。待确认项也可以作为工作项跟踪责任人和关闭状态。ONES Assistant 可围绕用户反馈、PRD 等材料提炼要点和待澄清问题，作为追问的起点，具体效果取决于输入材料的完整程度。
一个完整示例：从模糊诉求到可确认的需求
以下为演示情景，用于说明追问与改写的具体过程。
初始诉求：业务方提出“希望系统能自动提醒合同快到期，避免漏续签”。这句话包含目标，但缺少触发条件、提醒对象和异常处理。
第一轮追问（场景与角色）：合同到期前多久需要提醒？提醒给谁——合同负责人、法务还是部门主管？续签由谁发起？答复是：提前30天提醒合同负责人，续签由负责人发起、法务审核。此时仍不清楚提醒方式和失败处理。
第二轮追问（数据与边界）：到期日以哪个字段为准？没有录入到期日的合同怎么办？合同已终止或已续签的是否还要提醒？答复是：以合同主档的到期日为准；缺失到期日的合同需单独列出由管理员补录；已终止合同不再提醒，已续签的以新合同到期日计算。
第三轮追问（异常与非功能）：提醒发送失败怎么办？负责人离职或转岗如何处理？答复是：发送失败次日重试一次，仍失败则通知管理员；负责人为空时提醒其上级。
澄清后的可验证表述：“合同主档到期日前30天，系统向合同负责人发送站内通知；到期日缺失的合同进入待补录列表并通知管理员；已终止合同不提醒，已续签合同按新合同计算；通知发送失败次日重试一次，连续失败通知管理员；负责人为空时通知其上级。”
未决项：是否需要同时发送邮件、提醒时间是否可配置，这两项列入待确认清单，由业务负责人在约定日期前答复。
这个示例可迁移的规律是：先问清“谁在什么条件下收到什么”，再问“数据从哪来、缺失怎么办”，最后问“失败和例外怎么处理”。三轮追问后，原本一句话的诉求变成了可设计、可测试的表述，剩余不确定项也被显式记录，而不是留到开发阶段才暴露。
澄清完成检查：判断可以进入下一步的条件
澄清做到什么程度算完成，可以用一组可逐项核对的条目判断。全部通过或未通过项已有明确处置，才适合进入需求建模与正式评审。
| 检查维度 | 检查项 | 通过标准 |
|---|---|---|
| 理解一致性 | 需求提出方、业务负责人、产品、开发、测试对目标与范围的理解是否一致 | 各方能用自己的话复述同一目标，无相互矛盾的表述 |
| 边界完整性 | 主要场景、异常路径、数据口径、权限规则是否都有说明 | 每个场景都有触发条件、处理结果和例外说明 |
| 可验证性 | 关键表述是否可被测试验证 | 模糊词已改写为含条件与结果的表述，或已列入待确认 |
| 未决项管理 | 待确认清单和假设清单是否完整 | 每项都有责任人、影响说明和计划关闭时间 |
| 确认留痕 | 澄清结论是否经需求提出方书面确认 | 有确认人、确认时间和记录版本 |
对未决项要分级处置：影响范围、验收标准或数据口径的，必须在进入建模前关闭；影响实现细节但不改变业务目标的，可带条件进入下一步，并在评审前关闭；属于后续迭代的，明确移出本次范围并记录。假设清单中的每一项都要标注“若不成立的影响”，让后续角色知道风险在哪里。
交接给建模与评审时，入口条件是：澄清记录已确认、关键未决项已关闭或有明确关闭计划、假设已显式记录、验收要点可供测试参考。满足这些条件，结构化表达和正式评审才有稳定的输入，澄清阶段的工作也才算真正交付。
常见问题
澄清会上业务方一时答不上来的问题，应该当场定还是先记下来？
建议先记入待确认清单，不当场猜测。追问中答不上来的问题通常涉及数据口径、异常处理规则或优先级判断，当场拍板容易留下错误共识。记录时写清问题描述、影响范围、提出人、责任人和期望答复时间，会后由责任人跟进，并在澄清记录中标注该问题尚未关闭。如果这个问题影响验收标准或数据口径，应在进入建模前关闭；只影响实现细节的，可以带条件进入下一步，并在评审前关闭。
需求提出方和业务负责人不是同一个人时，澄清结论由谁确认？
由需求提出方确认业务目标和期望结果，由业务负责人裁定数据口径、优先级和跨部门规则冲突，两者职责分开。实际操作中，澄清记录可以设两个确认位：目标与范围由提出方确认，口径与规则由业务负责人确认。如果两人对同一问题给出不同答复，应回到澄清会当面裁定，并把裁定结果和依据写入记录，避免后续角色各按自己的理解执行。
澄清记录和后续的需求文档是什么关系，需要重复维护吗？
澄清记录是需求文档的输入，不需要重复维护同一份内容。澄清记录保留原始诉求、追问问答、假设和未决项，侧重过程留痕；进入需求建模与表达阶段后，把已确认的表述整理成结构化需求文档，澄清记录作为依据保留并可回溯。后续口径或范围变化时，在原记录上标注变更内容和变更人，保留历史版本，这样评审时能看清每条结论是怎么来的。
小团队人手少，能不能省掉澄清会和书面确认？
可以简化形式，但建议保留书面确认这一环。人手少时，澄清会可以压缩成一次短会或异步过一遍待确认清单，关键是让需求提出方对结论留下书面确认，比如在文档或工作项上回复确认。口头共识在跨角色传递、人员变动或时间拉长后容易失真，书面记录同时也是后续变更对比的基准。团队如果使用 ONES，可以把澄清记录放在 ONES Wiki 文档中，通过页面组关联对应项目，成员在线添加注释和评论反馈，页面版本可随时查看与回滚，便于保留确认过程。
澄清阶段发现需求本身价值不大或与其他需求冲突，该怎么处理？
这属于澄清过程中暴露的范围与优先级问题，应记录后交由业务负责人裁定，不在澄清环节自行取舍。处理方式通常有三种：与其他需求合并、调整优先级排入后续迭代、明确移出本次范围。无论哪种，都要在澄清记录中写明结论和依据，并同步给提出方。把这类问题显式记录，比带着冲突进入建模更省返工。
