需求分析与澄清、需求建模、需求评审常在同一段项目周期里交替发生，边界不清时最容易出现两种浪费：澄清会上开始画模型，评审会上重新追问业务背景。可操作的划分口径是看交付物——需求分析与澄清交付“相关方对需求理解一致”的结论，需求建模交付“可被评审和开发使用的结构化表达”，需求评审交付“对已形成需求文档或模型的质量结论”。本文按这三类交付物说明各自的范围、完成标志与交接点。
要点总览（TL;DR）
- 用交付物划分边界：需求分析与澄清交付“相关方理解一致”的结论，需求建模交付“可被评审和开发使用的结构化表达”，需求评审交付“对需求文档或模型的质量结论”。
- 需求分析与澄清的完成标志是三条：关键歧义有结论、验收口径可用业务语言描述、提出者与实现方理解无实质分歧。
- 建模会暴露新歧义，属于正常回流；回流的问题应回到澄清闭环，由建模人员自行假定会让模型语义失真。
- 评审发现理解缺口应退回澄清，发现表达缺陷应退回建模；在评审会上临时重做需求分析，结论往往不可靠。
- 评审通过不等于业务方接受，业务确认也不能替代质量检查，两类结论应分别记录。
一句话区分：理解、表达与检查
三项活动回答的核心问题不同，因此可以用“当前要产出什么”来判断自己处在哪一段。需求分析与澄清回答“需求到底指什么、为什么提、什么算满足”；需求建模回答“怎样把已澄清的需求组织成结构清楚、可推演的表达”；需求评审回答“这份需求文档或模型是否达到可进入后续环节的质量”。
以交付物作为分界依据，比按会议名称或时间顺序判断更可靠。同一场会议里可能先澄清再评审，但只要产出的东西是“歧义结论”，它属于澄清；产出的是“评审意见与通过结论”，它属于评审。三项活动存在交叠：建模会暴露新的歧义，评审也会发现理解缺口，但交叠不改变主责——暴露出的理解问题回到澄清解决，表达问题回到建模修正，评审负责给出结论而不是替前两段完成工作。
| 活动 | 核心问题 | 主要交付物 | 完成信号 |
|---|---|---|---|
| 需求分析与澄清 | 需求指什么、为什么提、什么算满足 | 经确认的需求陈述、术语与假设清单、待确认问题及结论 | 关键歧义有结论，验收口径可描述，相关方理解一致 |
| 需求建模 | 如何结构化表达已澄清的需求 | 用例、业务流程、数据与状态模型等 | 模型完整、内部一致，可被评审与开发使用 |
| 需求评审 | 需求文档或模型是否达到质量要求 | 评审意见、缺陷项、通过或有条件通过结论 | 结论明确，缺陷项有责任人与处理去向 |
需求分析与澄清的范围与完成标志
需求分析与澄清是一组以“消除理解偏差”为目标的活动，它的产物是共识而不是图形或正式结论。典型活动包括：识别需求来源与提出背景；访谈干系人，区分提出者、使用者、受影响者与决策者；澄清问题与目标，确认要解决的是哪个业务问题；确认范围与约束，明确本次做什么、不做什么，以及时间、合规、系统条件等限制；逐条消除原始需求中的歧义，把“要快”“要方便”“要能统计”这类表述转成可讨论的具体含义。
这一阶段的输入通常是业务诉求、原始需求条目、相关方名单与背景材料。输出包括需求陈述、术语与假设清单、待确认问题清单及其结论。术语清单常被忽略，但它决定了后续建模和评审是否在同一语义上讨论；假设清单则把“暂时按某种理解推进”的部分显性化，避免假设在 downstream 被当成事实。
完成标志可以按三条核验：关键歧义已有明确结论，不以“后面再说”结项；验收口径可以用业务语言描述，即相关方能说出“什么情况下算满足”；相关方对需求陈述的理解一致，提出者与实现方对同一条需求的解读没有实质分歧。需要说明的是，这一阶段不包括详细结构化建模，也不产出正式评审结论；澄清会上顺手画的草图可以帮助讨论，但不构成建模交付物。
需求建模承接什么：从理解到结构化表达
需求建模的输入是已经澄清的需求陈述与约束条件，而不是原始诉求本身。把尚未澄清的需求直接画成流程图或用例，常见结果是模型精致但语义错误，返工成本高于先澄清。建模的任务是选择合适表达形式，把需求组织成可推演、可检查的结构：用例描述角色与目标的交互；业务流程表达步骤、分支与例外；数据模型表达业务对象、属性与关系；状态模型表达对象在生命周期中的状态与迁移条件。
建模过程会反向暴露新的歧义。例如画状态模型时发现“订单取消后能否恢复”没有结论，画流程时发现异常分支缺少业务规则。这类发现属于正常回流：把问题登记为待确认项，回到澄清环节与相关方确认，再把结论补进模型。回流不等于建模失败，它说明模型起到了检查理解的作用；但回流的问题应在澄清中闭环，而不是由建模人员自行假定。
建模完成的标志是模型可被评审与开发使用：关键场景覆盖完整，模型内部一致，术语与澄清阶段的术语清单对得上，读者能依据模型理解需求而不需要额外口头解释。达到这一状态后，模型才进入评审对象范围。
需求评审检查什么：正式质量关口的位置
需求评审的对象是已经形成的需求文档、模型与验收口径，它是一次正式的质量检查，而不是需求分析的替代。检查内容通常包括：完整性，需求条目、异常分支与约束是否有遗漏；一致性，文档与模型之间、条目之间是否矛盾；可测试性，验收口径能否转化为可执行的验证条件；可行性，在已知技术与资源条件下是否可实现；优先级依据，排序是否有业务理由支撑。
评审的输出是评审意见、缺陷项与结论。结论可以是直接通过、有条件通过或退回修改；有条件通过应写明条件与复核方式，缺陷项应明确责任人与处理去向。评审发现的问题按性质分流：属于表达或模型缺陷的，回到建模修正；属于理解缺口、业务规则缺失或相关方未达成一致的，退回澄清补充，而不是在评审会上临时重做需求分析。评审会时间有限，现场重新访谈和推演业务背景，往往既得不出可靠结论，也拖慢评审节奏。
相邻概念区别：容易混淆的四组关系
边界争议多发生在相邻概念之间。下面四组关系用同一口径对照：各自处理的对象是什么，产出什么，什么情况下应切换到另一项活动。
| 关系 | 区别要点 | 判断与切换 |
|---|---|---|
| 分析与澄清 | 同属一个阶段的两类动作：分析侧重拆解问题、目标与范围，澄清侧重消除表述歧义、对齐相关方理解 | 两者共享同一份交付物，即经确认的需求陈述与澄清记录，无需强行分成两个阶段 |
| 建模与设计 | 建模表达“需求是什么”，设计表达“方案怎么做” | 模型中开始出现技术选型、组件划分、接口实现方式时，已进入设计范畴，应移出需求模型 |
| 评审与用户确认 | 评审是质量检查，关注完整、一致、可测试、可行；用户确认是业务接受，关注需求是否符合业务预期 | 评审通过不等于业务方接受，业务确认也不能替代质量检查，两者结论应分别记录 |
| 评审会与澄清会 | 澄清会用于形成理解共识，评审会用于对已成形的文档或模型给出结论 | 评审会上出现大量“这条到底什么意思”的追问，说明澄清未完成，应退回澄清而非现场补做 |
一个具体例子：从诉求到评审通过
以下为演示情景，用于说明三段活动如何接力。业务方提出诉求：“希望审批更快，减少来回沟通。”这句话本身无法直接建模，也无法直接评审。
澄清阶段先确认：审批指哪类单据，当前平均耗时与来回沟通发生在哪些环节，业务方所说的“快”是缩短等待时间还是减少退回次数，哪些节点可以并行、哪些必须串行，合规上是否有不可省略的审批人。澄清结论形成需求陈述：某类单据在满足合规审批人的前提下，将非必要串行节点改为并行，退回时须一次性列明全部缺项；验收口径描述为“同类单据从提交到终审的平均等待时间下降，且退回次数可统计”。同时登记术语（如“终审”指哪一级）与假设（如并行节点不改变审批责任归属）。
建模阶段依据上述陈述产出流程图与状态模型：流程图标出并行分支与退回路径，状态模型标出单据从提交、审批中、退回补正到终审的各状态及迁移条件。建模中发现“退回补正后是否重新走全部节点”未明确，登记为待确认项回到澄清，确认后补入模型。
评审阶段检查文档与模型：异常分支是否覆盖、验收口径能否测试、并行改造在现有系统条件下是否可行、优先级依据是否成立。评审发现“退回次数统计”缺少数据来源说明，属于文档缺陷，退回补充；若发现业务方对“终审”级别理解不一致，则退回澄清。常见误解有两类：把评审会当成澄清会，在会上重新追问业务背景；把建模当成分析，用画图代替与相关方确认语义。两者都会让边界失效，责任落空。
在协作工具中让三段边界可追踪
边界要稳定，除了定义清楚，还需要让每段的输入、输出和交接留下记录。可以用工作项承载澄清问题：每条待确认问题作为独立工作项，记录提出背景、责任人、结论与确认时间，并关联到对应的需求条目；结论关闭后，需求条目上的歧义状态随之更新。这样澄清是否完成可以直接从问题项的关闭情况判断，而不是依赖会议记忆。
需求文档与模型放在文档区维护版本，澄清结论、术语与假设清单、模型文件在同一需求空间内关联，避免评审时拿到过期版本。评审意见与结论同样留痕：缺陷项作为工作项关联到文档或模型的具体位置，结论记录通过、有条件通过或退回，并写明条件与复核方式，便于后续回溯“当时为什么这样定”。状态流转体现交接：需求条目从澄清中进入待评审，评审通过后进入可开发，退回则回到澄清或建模，责任人和下一步动作随状态明确。
ONES 可以在这一层承担记录与衔接：澄清问题、评审缺陷以工作项管理并关联需求条目，需求文档与模型在文档区维护版本，评审结论随状态流转保留痕迹，使“理解共识—结构化表达—评审结论”三段各有交付物、各有责任人。工具不替代判断，但能让每次交接有据可查，减少边界模糊带来的重复讨论。
常见问题
澄清会开完，需求条目就可以直接进入评审了吗？
不一定。澄清会结束只说明讨论发生过，是否达到可评审状态要看交付物：关键歧义是否都有明确结论、验收口径能否用业务语言描述、提出者与实现方对同一条需求的解读是否一致。三项都满足，需求陈述与澄清记录才算成形，可以进入建模或评审；仍有悬而未决的问题项，应先关闭或明确处理去向，再往下走。
建模时发现需求没澄清清楚，应该停下来等澄清，还是先按假设画完？
建议把发现的问题登记为待确认项，回到澄清环节与相关方确认，再把结论补进模型。按假设画完看似节省时间，但假设会随模型进入评审和开发，后续纠正的成本更高。可以并行推进不受该问题影响的部分，同时把受影响的分支标为待确认，避免把假设当成既定事实交付。
评审会上业务方对需求理解提出异议，应该当场讨论清楚吗？
这类异议属于理解缺口，适合退回澄清处理，而不是在评审会上现场补做需求分析。评审会时间有限，现场重新访谈和推演业务背景，往往得不出可靠结论，还会拖慢评审节奏。可行的做法是记录异议内容与相关方，评审对不受影响的部分给出结论，受影响条目退回澄清，澄清完成后再安排复核。
需求评审通过后，还需要业务方确认吗？
需要，两者检查的内容不同。评审关注完整性、一致性、可测试性与可行性，回答“这份需求文档或模型质量是否达标”；业务确认关注需求是否符合业务预期，回答“这是不是我们要的东西”。评审通过不代表业务方接受，业务确认也不能替代质量检查，两类结论分别记录，后续回溯时才能分清问题出在质量还是业务判断。
小团队人手少，三段活动可以合并做吗？
活动可以合并到同一场讨论中完成，但交付物仍建议分开留下记录。比如一次会议里先澄清语义、再画草图、最后给出结论，只要分别记录澄清结论、模型版本和评审意见，边界依然可追踪。风险在于合并后容易只留会议纪要，事后无法判断某条需求是“已澄清”还是“被默认”，返工和争议往往由此产生。
