用例模型评审时，参与者识别不清往往表现为用例边界反复改动、同一业务动作被拆成多条用例，或把岗位名称、具体人员甚至系统内部模块写成了参与者。这类问题属于需求表示层面的偏差，调整思路是先还原系统边界与外部交互方，再逐条核对主参与者与支撑参与者，最后用矩阵验证覆盖关系。本文按症状归类、原因验证、模型调整、验证与预防四步展开，适用于团队完成初版用例模型后的评审与修订场景。
要点总览（TL;DR）
- 评审中先做症状归类：把岗位或人员写成参与者、把系统内部模块写成参与者、同一业务动作拆成多条用例、一条用例挂多个主参与者，都属于参与者识别问题；需求内容争议和粒度问题应分开处理。
- 原因排查按固定顺序推进：先确认系统边界，再确认外部交互方，最后核对主参与者与支撑参与者；每条原因假设都要用交互记录、系统上下文图或参与者—用例矩阵验证，证据不足的登记为待确认项。
- 调整时先重画系统上下文，再把参与者改写为角色或外部系统，为每条用例指定唯一主参与者，并同步合并或拆分用例粒度；修改前保留初版模型备份，评审记录写明调整理由。
- 调整后用参与者—用例矩阵检查孤立角色和无名主参与者，用业务流程走查核对主路径与异常路径，并把参与者命名规则与边界约定写入建模规范，作为后续评审的固定检查项。
参与者识别不清在评审中会呈现哪些症状
评审中出现的分歧并不都源于参与者识别问题。先做症状归类，可以避免把需求内容本身的争议误判为建模问题，也能让后续讨论集中在正确的对象上。以下清单可用于评审现场逐条对照。
典型症状清单
| 症状 | 评审中的具体表现 | 判断要点 |
|---|---|---|
| 把岗位或具体人员写成参与者 | 参与者一栏出现“销售经理”“张三”“运维专员”等名称，同一职责换人后模型需要改动 | 参与者应描述与系统交互的角色，人员变动不影响模型 |
| 把系统内部模块写成参与者 | 出现“订单服务”“消息队列”“数据库”等系统内部组件，用例被拆到组件层面 | 参与者应位于系统边界之外 |
| 同一业务动作被拆成多条用例 | “提交订单”“确认订单”“生成订单记录”分列，实际是同一业务目标的不同步骤 | 一条用例应对应一个对参与者有价值的完整目标 |
| 一条用例挂多个主参与者 | 用例同时标注两三个主参与者，评审时无法判断谁发起、谁受益 | 每条用例应有唯一主参与者，其余为支撑参与者 |
| 用例边界随参与者变化反复改动 | 调整参与者名称后，用例范围、前置条件、后置条件跟着大改 | 边界不稳定通常说明参与者与系统边界未对齐 |
与需求内容争议、粒度问题的区分
如果争议集中在“这个功能要不要做”“业务规则是否正确”，属于需求内容本身的分歧，应转入需求澄清，不在建模层面解决。如果争议集中在“这条用例太大或太细”，属于粒度问题，处理方式与参与者识别不同：粒度问题通过合并或拆分用例目标来调整，参与者问题则要先修正角色定义。两类问题可能同时出现，评审时建议先归类再讨论，避免在同一轮里混改。
逐条排查：参与者为什么会被识别错
原因判断需要区分假设与证据。评审中提出的解释先作为假设记录，再用可核查的材料验证，证据不足的保留为待确认项，不直接写进结论。排查顺序建议固定为：先确认系统边界，再确认外部交互方，最后核对主参与者与支撑参与者。
原因假设与验证证据对照
| 原因假设 | 验证证据 | 确认后的含义 |
|---|---|---|
| 混淆角色与人员 | 交互记录、用户访谈记录、岗位职责说明；检查同一职责是否对应多个参与者名称 | 参与者按角色抽象，人员或岗位调整不触发模型修改 |
| 把内部组件当成外部交互方 | 系统上下文图；核对被列为参与者的对象是否部署在系统边界内 | 内部组件从参与者清单移除，其职责转为系统内部设计 |
| 遗漏外部系统 | 业务流程走查、接口清单、上下游系统清单；检查用例是否缺少触发方或接收方 | 补充外部系统作为参与者，并关联其触发的用例 |
| 按组织架构而非系统边界划分 | 参与者—用例矩阵；检查是否存在按部门划分但与系统交互方式重复的角色 | 合并交互方式相同的角色，按与系统的交互关系重新划分 |
排查顺序与证据不足时的处理
第一步确认系统边界：用系统上下文图圈定哪些能力由本系统提供、哪些由外部承担。边界不清时，参与者讨论容易变成架构讨论，应先冻结边界再继续。第二步确认外部交互方：从业务流程出发，找出所有向系统发起请求或接收系统输出的角色与外部系统。第三步核对主参与者与支撑参与者：对每条用例追问“谁发起、谁接收结果”，发起方通常为主参与者，仅提供信息或被动接收结果的一方标为支撑参与者。
当某项假设缺少交互记录或流程图佐证时，不要在现场直接下结论。处理方式是将其登记为待确认项，注明需要补充的材料和确认人，在下一轮评审前完成核实。这样既保证本轮评审有产出，也避免把猜测固化成模型修改。
按评审结论调整参与者与用例边界
诊断结论确认后，调整应按固定顺序推进，先改边界与参与者，再改用例，最后统一粒度。顺序颠倒会导致用例反复返工。修改前保留初版模型备份，评审记录中写明每条调整的理由，便于回溯。
调整步骤
- 重画系统上下文。明确哪些能力在系统内、哪些是外部交互方。上下文图是后续所有参与者判断的依据，应先达成一致再动用例。
- 改写参与者。把岗位名称、具体人员改写为角色；把系统内部模块从参与者清单移除；把外部系统按系统名称登记为参与者。交互方式相同的重复角色合并，同时承担多种交互方式的混合角色按交互目的拆分。
- 指定主参与者。为每条用例标注唯一主参与者，支撑参与者单独列出并注明其参与方式，例如提供数据、接收通知或审批结果。
- 调整用例粒度。把被拆散的同目标业务动作合并为一条用例；把承担多个独立目标的用例按目标拆分。判断标准是每条用例对主参与者是否产生一个可感知的完整结果。
- 记录修改说明。在评审记录中写明调整前后的参与者名称、用例范围变化及依据，保留初版模型备份，便于对比和回退。
调整中的风险控制
合并用例时容易把不同触发条件的行为压进一条用例，导致主路径与异常路径混杂。控制方法是合并后检查前置条件是否仍然单一，若出现多个互斥的触发条件，应保留为独立用例。拆分用例时则要防止把步骤当目标，拆分后每条用例仍应能独立回答“谁发起、得到什么结果”。涉及跨团队共用的参与者定义时，调整前先与相关方确认命名，避免同一角色在不同模块中出现两种叫法。
参与者清单、用例条目和评审记录需要在同一处维护，修改理由与版本可追溯，评审时才能对照初版判断改动是否合理。ONES 的需求管理可以承载参与者清单、用例条目与评审记录，把建模成果与评审结论关联在同一工作项下，便于后续版本对比和交接。
调整后如何验证并防止再次识别不清
调整完成不等于问题解决，需要用可检查的方式确认覆盖关系完整，并把本次形成的约定固定下来，减少下一轮评审重复出现同类问题。
验证检查项
- 参与者—用例矩阵完整性：每个参与者在矩阵中至少关联一条用例，不存在只登记不交互的角色；每条用例有且只有一个主参与者。
- 业务流程走查：沿主路径和异常路径逐段核对，确认每个触发点和结果接收方都能对应到已登记的参与者，没有遗漏的外部系统。
- 边界一致性：抽查若干用例，确认其前置条件、后置条件与系统上下文图一致，参与者变化不再引起用例范围大幅改动。
- 命名一致性：同一角色在全部用例中使用同一名称，不出现岗位名与角色名混用。
评审通过标准与责任确认
建议在评审结论中明确三项：参与者清单经业务方与建模负责人共同确认；参与者—用例矩阵无孤立角色和无名主参与者；待确认项已全部关闭或指定了确认人和期限。三项满足后由建模负责人签字确认本轮模型版本，后续修改走变更记录。
写入建模规范的约定
把本次调整中形成的规则沉淀为团队建模约定，后续评审直接沿用：参与者只描述系统边界外的角色或外部系统，不写岗位和人员姓名；每条用例标注唯一主参与者，支撑参与者单独列出；新增参与者须同步更新参与者—用例矩阵；用例合并与拆分须在评审记录中说明理由。约定条目宜简短可核对，附在建模规范或评审检查表中，作为每轮评审的固定检查项。
常见问题
评审时怎么快速判断是参与者识别问题，还是需求内容本身有分歧？
看争议的落点。如果讨论围绕“这个功能要不要做”“业务规则是否正确”，属于需求内容分歧，应转入需求澄清。如果讨论围绕“谁发起这条用例”“这个名称算不算参与者”“用例范围为什么随参与者变化”，则属于参与者识别问题。粒度争议单独处理：用例太大或太细通过合并、拆分目标来调整，参与者问题要先修正角色定义。两类问题同时出现时，建议先归类再逐项讨论，避免在同一轮评审里混改。
业务方坚持用岗位名称写参与者，怎么处理？
先把岗位与角色的差异讲清楚：岗位会随组织调整而变化，角色描述的是与系统交互的职责，人员或岗位变动不应触发模型修改。处理时可以保留岗位名称作为角色说明的补充信息，但参与者一栏统一写角色名。如果同一岗位在不同场景下与系统的交互方式不同，就按交互目的拆成两个角色，并在评审记录中写明拆分依据，请业务方确认。
外部系统算参与者吗？遗漏了会有什么影响？
位于系统边界之外、与本系统存在请求或结果传递的外部系统，应登记为参与者。遗漏外部系统通常表现为用例缺少触发方或接收方，业务流程走查时会出现断点。排查时可对照接口清单和上下游系统清单，确认每个跨系统交互都有对应的参与者。补充后同步更新参与者—用例矩阵，避免只改用例、不改清单。
一条用例有多个参与方时，主参与者怎么定？
用“谁发起、谁接收结果”来判断。发起该用例所描述业务动作的一方通常为主参与者；仅提供数据、接收通知或参与审批的一方标为支撑参与者，并注明参与方式。每条用例只保留一个主参与者，这样用例目标才清晰，后续做覆盖检查时也不会出现无人负责的条目。若发现两个参与方都符合发起方特征，往往说明这条用例实际承担了两个目标，应考虑拆分。
调整参与者后，用例数量变化很大，怎么控制返工？
按顺序改：先冻结系统上下文，再改参与者清单，然后才动用例，最后统一粒度。顺序颠倒会导致用例反复返工。修改前保留初版模型备份，评审记录逐条写明调整前后的名称与理由，便于对比和回退。合并用例后检查前置条件是否仍然单一，出现多个互斥触发条件时保留为独立用例；拆分后确认每条用例仍能独立回答“谁发起、得到什么结果”。跨团队共用的角色定义，调整前先与相关方确认命名。
