需求分析与澄清的目标，是把一句模糊诉求转成业务方、研发和测试都能确认的理解。可执行的主线是：还原业务问题与目标，拆分需求条目，逐条澄清边界与例外，确认可行性和冲突，最后形成确认记录并跟踪待定项。下面按步骤、问题清单、角色分工、完整示例和完成检查展开，适合需求负责人和业务分析人员直接照着做。
要点总览（TL;DR）
- 需求分析与澄清按六步推进：还原业务问题、梳理使用场景、拆分需求条目、澄清边界与例外、确认可行性与冲突、形成确认记录并跟踪待定项，每步都要有输入、动作、输出和完成标志。
- 澄清会按业务目标、用户角色、正常与异常流程、数据权限与业务规则、非功能要求与约束、优先级与范围六类提问，把“快一点”“看情况”这类模糊表述追问成可验证的条件。
- 业务方对目标和规则负责，需求负责人对条目完整性和记录负责，研发对可行性负责，测试对可验证性负责；待定项必须写明缺失信息、责任人、关闭条件和期限。
- 澄清完成的判断标准是：条目可理解可确认、边界与例外明确、业务规则完整、非功能要求与约束已记录、待定项有责任人和期限、确认记录获得业务方认可。
- 澄清记录和待定项可以挂在需求条目下统一维护，让每次澄清的结论和关闭情况有据可查，再进入后续评审。
需求分析与澄清的核心步骤
需求分析与澄清可以拆成六步。每一步都应有明确的输入、动作、输出和完成标志，避免澄清停留在“聊过了”的状态。完成标志的作用是让参与者对“这一步做完了没有”有共同判断，而不是靠感觉推进。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 还原业务问题 | 业务方提出的原始诉求、相关背景材料 | 追问诉求背后的业务问题、目标用户和期望结果，区分“想要的功能”和“要解决的问题” | 一段业务问题与目标描述 | 业务方确认问题描述准确，目标可以用一句话说清 |
| 2. 梳理使用场景 | 业务问题与目标描述 | 按角色还原正常流程和关键异常分支，标出触发条件与结果 | 场景清单，含角色、触发条件、主流程、异常分支 | 每个主要角色至少有一个场景，异常分支有初步描述 |
| 3. 拆分需求条目 | 场景清单 | 把场景拆成可独立确认的条目，区分功能需求、非功能需求、业务规则和约束 | 编号后的需求条目清单 | 每条需求有唯一编号、一句话描述和来源场景 |
| 4. 澄清边界与例外 | 需求条目清单 | 逐条确认适用范围、不适用范围、例外情况和待定项，记录判断依据 | 带边界说明和待定项标记的条目 | 每条需求都能回答“什么情况下适用、什么情况下不适用” |
| 5. 确认可行性与冲突 | 带边界说明的条目 | 与研发、测试核对技术可行性、数据来源和依赖，识别条目之间或与现有规则的冲突 | 可行性结论、冲突清单及处理意见 | 冲突有明确处理方式，可行性结论有责任人确认 |
| 6. 形成确认记录并跟踪 | 前五步的全部产出 | 整理成确认记录，列出待定项、责任人和关闭期限，进入跟踪 | 确认记录与待定项跟踪表 | 业务方认可记录内容，待定项均有责任人和期限 |
拆分需求条目时，功能需求描述系统要做什么，非功能需求描述性能、可用性、安全、兼容等质量要求，业务规则描述必须遵守的判断逻辑，约束描述不可更改的前提，例如必须沿用的既有流程、外部系统提供的接口范围或合规要求。四类内容混在一条里，后续确认时容易各说各话，拆开记录能让每类问题找到对应的确认人。
澄清边界时，重点问“什么情况不适用”和“出现例外怎么处理”。很多争议来自双方对默认情况的理解不同，把例外显式写出来，比反复解释更有效。暂时无法确认的内容不要含糊带过，直接标为待定项，写明缺什么信息、由谁补充、什么时候关闭。
确认可行性时，需求负责人组织研发和测试对条目逐条过一遍，重点看数据是否可得、依赖是否具备、规则是否自洽。发现冲突时，记录冲突双方、影响范围和可选处理方案，交由业务方在方案之间做选择，而不是由需求负责人单方面取舍。确认记录形成后，待定项进入跟踪，每次澄清或变更都更新记录状态，直到全部关闭或明确转为后续范围。
澄清会上该问哪些问题
澄清会的问题要围绕“把模糊表述变成可确认的理解”来设计。下面按类别给出可直接复用的问题清单，会前按需求特点挑选，会上逐项记录回答，未答完的转为待定项。
业务目标与成功判断
- 这个需求要解决什么业务问题？现在这个问题是怎么处理的？
- 上线后用什么指标判断它有效？由谁在什么时间点评估？
- 如果只能实现一部分，哪部分价值最高？
用户角色与使用场景
- 哪些角色会使用这个功能？各自的操作频率和熟练程度如何？
- 典型使用场景从什么动作开始，到什么结果结束？
- 有没有跨角色交接的环节？交接时以什么为凭据？
正常流程与异常分支
- 正常流程分几步？每步的输入和输出是什么？
- 数据缺失、重复提交、超时、权限不足时分别怎么处理？
- 异常发生时由谁介入，处理结果如何反馈给用户？
数据、权限与业务规则
- 需要哪些数据？数据从哪里来，由谁维护，更新频率如何？
- 谁能看、谁能改、谁能审批？权限按角色还是按数据范围划分？
- 有哪些必须遵守的判断规则？规则有没有例外，例外由谁批准？
非功能要求与约束条件
- 对响应时间、并发量、可用性有没有明确要求？依据是什么？
- 是否涉及历史数据迁移、外部系统对接或合规审查？
- 有哪些不能改的既有流程、技术限制或时间窗口？
优先级与范围边界
- 本期必须包含什么，可以延后什么？
- 哪些内容明确不在本期范围内？
- 如果时间或资源受限，先保哪些条目？
提问时尽量让回答落到具体动作和具体数据上。例如“要快一点”可以继续追问“哪个操作、在多少数据量下、期望多久完成”，把形容词转成可验证的条件。回答中出现“一般”“通常”“看情况”时，追问一次例外情形，往往能发现被忽略的业务规则。
角色分工与各阶段交付物
澄清要避免停留在口头沟通，关键是每个阶段都有明确的责任人和可检查的交付物。业务方对业务目标和规则负责，需求负责人对条目的完整性和记录负责，研发对可行性判断负责，测试对可验证性负责。
| 阶段 | 业务方 | 需求负责人 | 研发 | 测试 | 交付物与确认方式 |
|---|---|---|---|---|---|
| 还原业务问题 | 说明问题、目标和现状 | 组织访谈、整理问题描述 | 了解背景，提出初步疑问 | 了解背景 | 业务问题与目标描述，业务方书面确认 |
| 梳理使用场景 | 提供角色和流程信息 | 整理场景清单，标注异常分支 | 补充技术相关场景 | 从验证角度补充边界场景 | 场景清单，澄清会过一遍 |
| 拆分需求条目 | 确认条目是否符合业务意图 | 拆分并编号，区分四类需求 | 标注实现依赖 | 标注可测试性疑问 | 需求条目清单，评审前发出 |
| 澄清边界与例外 | 确认适用范围和例外处理 | 逐条记录边界和待定项 | 提出约束条件 | 提出异常分支的验证条件 | 带边界说明的条目，会上确认 |
| 确认可行性与冲突 | 在冲突方案中做选择 | 组织核对，记录冲突与处理意见 | 给出可行性结论 | 评估验证成本 | 可行性结论与冲突清单，责任人签字或书面回复 |
| 形成确认记录 | 认可记录内容 | 整理记录，维护待定项跟踪表 | 确认技术相关条目 | 确认验证相关条目 | 确认记录与待定项跟踪表，业务方认可后归档 |
待定项需要单独管理，每条至少包含：待定内容、缺失的信息、责任人、计划关闭时间和当前状态。关闭条件写清楚，例如“业务方确认例外审批人后关闭”或“外部系统接口范围书面回复后关闭”。没有责任人和期限的待定项，实际上等于没有记录。
当需求条目、边界说明和待定项数量增多时，散落在文档和聊天记录里容易失去同步。ONES 的需求管理可以把需求条目作为工作项维护状态，把澄清记录和待定项挂在对应条目下，让每次澄清的结论、责任人和关闭情况有统一入口可查。这样在进入后续评审前，团队能直接看到哪些条目已确认、哪些仍在等待回复。
一个完整示例：从模糊诉求到确认记录
以下为演示情景，用于说明澄清过程如何落地。某业务部门提出：“希望系统支持合同到期提醒，最好提前通知，别漏掉。”
澄清问题与得到的回答
- 要解决什么问题？回答：过去有合同到期后才发现续签延误，影响服务连续性。
- 谁需要收到提醒？回答：合同负责人和部门主管。
- 提前多久提醒？回答：希望提前30天，重要合同希望提前60天。
- 怎么定义重要合同？回答：按合同金额和是否涉及独家供应判断，具体标准由业务部门提供。
- 通过什么方式通知？回答：系统内消息，后续再考虑邮件。
- 合同已续签或已终止时还要提醒吗？回答：不需要，应自动停止。
- 到期日当天还没处理怎么办？回答：升级提醒给部门主管。
拆分后的需求条目与边界
| 编号 | 类型 | 需求描述 | 边界与例外 |
|---|---|---|---|
| R-01 | 功能需求 | 合同到期前按配置天数向合同负责人发送系统内提醒 | 默认30天，重要合同60天；已续签、已终止的合同不提醒 |
| R-02 | 业务规则 | 重要合同按金额和独家供应属性判定 | 判定标准由业务部门提供，标准变更需重新确认 |
| R-03 | 功能需求 | 到期日仍未处理的合同，向部门主管发送升级提醒 | 升级仅一次，避免重复打扰 |
| R-04 | 非功能需求 | 提醒在每个工作日固定时间批量生成 | 生成时间待与业务方确认 |
| R-05 | 约束 | 本期仅做系统内消息，邮件通知不在范围内 | 后续版本再评估 |
冲突与待定项处理
澄清中发现一处冲突：业务方希望“重要合同提前60天”，但部分合同从签署到到期不足60天。处理方式是约定此类合同在签署后次日即触发首次提醒，并由业务方确认该规则。另有两项待定：重要合同的金额阈值未定，责任人为业务部门负责人，期限为澄清会后三个工作日；批量生成时间未定，责任人为需求负责人，需与研发确认任务调度窗口后关闭。
最终确认记录的样子
确认记录包含：业务问题与目标一段话；场景清单三条，覆盖正常提醒、续签后停止、到期升级；需求条目R-01至R-05及边界说明；冲突处理结论一条；待定项两条，含责任人和期限；业务方确认意见与确认日期。记录归档后，待定项进入跟踪，关闭前不视为该需求澄清完成。
完成检查：澄清到什么程度可以进入下一步
澄清是否完成，可以用下面的清单逐项判断。全部满足或剩余项已明确转为后续范围，才可以进入评审等下一步；任何一项不满足，都应回到对应步骤补充。
| 检查项 | 判断标准 | 不满足时的处理 |
|---|---|---|
| 需求条目可理解、可确认 | 每条有编号、一句话描述和来源场景，业务方和研发理解一致 | 回到拆分步骤，补充描述或拆细条目 |
| 边界与例外明确 | 每条能说清适用范围、不适用范围和例外处理方式 | 补充澄清会，记录例外及批准人 |
| 业务规则完整 | 判断逻辑、触发条件和规则变更方式均有记录 | 请业务方提供规则明细并确认 |
| 非功能要求与约束已记录 | 性能、数据、权限、合规、依赖等有明确要求或明确标注暂无要求 | 与研发、测试核对后补记 |
| 待定项有责任人和期限 | 每条待定项写明缺失信息、责任人、关闭条件和计划时间 | 会上指定责任人，会后跟踪 |
| 确认记录获得业务方认可 | 业务方对记录内容书面或会上明确确认 | 发送记录请业务方回复确认，未确认前不推进 |
这份清单也可以作为澄清会的收尾动作：会议结束前逐项过一遍，把未满足项直接转为待定项并指定责任人。这样每次澄清都有明确产出，需求从模糊诉求走到可确认的理解，后续评审和实现才有稳定的依据。
常见问题
澄清会上业务方说“这个很简单，你们先做”，需求负责人该怎么处理？
把“简单”转成可确认的条件再往下走。可以请业务方用一句话说明要解决什么问题、上线后怎么判断有效，再追问正常流程分几步、哪些情况算例外。回答过程中出现的空白直接记为待定项，写明缺什么信息、由谁补充、什么时候关闭。这样既不否定业务方的判断，也让条目在进入研发前有可检查的依据。
待定项一直没人回复，澄清要不要继续推进？
待定项没有关闭前，相关条目不宜视为已澄清。可行的做法是给每条待定项设定关闭条件和期限，到期未回复时由需求负责人升级给业务方的上级或项目决策人，并在确认记录中标注影响范围。与待定项无关的条目可以先行推进，避免整批需求被个别问题卡住。
需求条目拆分到什么粒度比较合适？
以“能独立确认、能独立判断是否完成为准”。一条需求对应一个可描述的行为或规则，业务方看一句话能确认是否符合意图，研发能判断依赖，测试能想出验证方式。如果一条需求里同时包含功能、性能要求和审批规则，通常说明还需要继续拆，拆开后每类内容交给对应的确认人。
澄清记录需要写到什么详细程度，口头确认算不算数？
记录至少要能让没参加澄清会的人看懂：业务问题与目标、场景清单、需求条目及边界、冲突处理结论、待定项及责任人和期限、业务方确认意见与日期。口头确认可以作为过程，但建议在会后把记录发给业务方书面回复确认，未确认前不推进到评审，避免后续对当时说了什么产生分歧。
需求澄清和需求评审是什么关系，能不能合并成一次会？
两者目标不同。澄清解决“理解是否一致”，把模糊诉求问成可确认的条目；评审解决“这份需求是否达到进入下一步的质量要求”，属于正式质量检查。小需求可以把澄清和评审安排在同一天，但仍建议先完成澄清记录再评审，否则评审会上容易变成继续澄清，参与人和结论都难以沉淀。
