用例建模参与者识别不清怎么调整

用例模型评审时发现参与者识别不清，通常表现为参与者名单里混进了岗位、内部模块或数据来源，或者同一类外部角色被拆成多个名称。调整的思路是先按“与系统交互并从中获得可观察价值的外部角色”这一口径重列候选，再核对每个参与者是否有独立目标和用例集合，最后在评审中验证边界。下面按症状、原因、调整步骤和验证维护四个环节展开。

要点总览（TL;DR）

• 参与者识别不清的典型信号：名单里混入岗位、内部模块、数据库或定时任务，同一外部角色出现多个近义名称，用例与参与者对应关系说不清。
• 调整前先验证原因：区分角色与岗位、外部系统与内部组件、参与者与数据来源、同一角色按交互渠道被拆分这四类误判，证据成立再改模型。
• 调整按固定顺序推进：以系统边界为起点重列外部交互方，为每个候选写出目标与主要用例，合并同义角色、剔除内部组件，最后回写用例与参与者关系。
• 调整后用覆盖检查验证：每个参与者至少有一个用例承载其目标，每个用例有明确发起方，名单中不含内部组件与纯数据来源。
• 把参与者识别口径写入评审清单和变更记录，新增外部对接或流程调整时同步更新名单与别名表，减少同类问题复发。

参与者识别不清在评审中通常表现为什么

参与者识别问题在评审现场往往先以“名单看着别扭”的形式出现，评审者说不清哪里不对，但能感觉到参与者与用例对不上。把这类感觉转成可对照的症状，有助于判断初版模型属于哪一类偏差，也决定了后续调整从哪一步入手。

常见的四类症状可以对照下表逐项检查。症状本身只是线索，同一份模型可能同时出现多种症状，例如既把定时任务列为参与者，又存在两个近义角色名称，这通常说明初版建模时缺少统一的识别口径。

症状	具体表现	初步指向
参与者数量异常膨胀	一个中等规模系统的参与者列了十几个甚至更多，其中不少名称相近或职责重叠	把岗位、交互方式或内部角色都当成了参与者
参与者数量过少	只有一两个参与者，却要承载大量目标差异明显的用例	把多个外部角色合并成了一个笼统的“用户”
同一角色出现多个近义名称	“管理员”“系统管理员”“后台操作员”并存，用例分配交叉	按部门或交互渠道拆分，未做同义合并
把系统、数据库、定时任务列为参与者	参与者中出现“数据库”“消息队列”“每日批处理”等	混淆了外部交互方与系统内部组件
用例与参与者对应关系混乱	一个用例挂多个参与者却说不清谁发起、谁受益；部分参与者没有任何用例	参与者目标未写清，或用例粒度与参与者划分不匹配

对照时建议逐条打勾，并记录每条症状涉及的参与者名称。这份清单在后续原因核对和调整中会反复用到，也是评审记录的一部分。

先分清四类常见误判来源

症状只是表象，调整前需要把原因假设与验证证据对应起来，避免凭印象直接改名。下面四类误判来源覆盖了多数评审场景，每一类都给出可核对的证据，证据成立才按对应方式处理。

原因假设	典型迹象	验证证据
角色与岗位混同	参与者名称直接取自组织架构中的岗位，如“财务专员”“客服主管”	追问该岗位中不同人员是否与系统有不同目标；若目标一致，应合并为一个参与者，岗位差异放到权限或流程说明中
外部系统与内部组件混同	参与者列表里既有外部对接系统，也有本系统内的模块、服务	核对每个候选是否位于系统边界之外、是否通过接口与本系统交互；内部组件应移出参与者，改在用例描述或设计文档中体现
参与者与数据来源混同	数据库、文件、报表源被列为参与者	判断该对象是否主动发起交互并期待可观察结果；仅提供数据的一方按支撑关系处理，在用例中注明数据来源即可
同一角色按交互方式被拆分	同一类外部用户因使用网页端、移动端或批量导入而被拆成多个参与者	比较拆分后的参与者目标是否相同；目标相同则合并，交互渠道差异在用例场景或非功能说明中描述

验证时优先处理证据最容易取得的一类。例如内部组件是否在系统边界内，通常一次边界讨论就能确认；岗位与角色的区分则需要业务方参与，确认不同岗位人员使用系统时目标是否真的不同。原因未经验证就改模型，容易把正确划分改错。

还需要注意一种情况：参与者本身没错，但用例粒度过粗，导致一个参与者对应大量互不相关的用例，评审时看起来像参与者划分有问题。判断方法是看这些用例是否服务于同一目标；目标分散时先考虑拆分用例，再回看参与者是否需要调整。

按交互边界重列参与者的调整步骤

原因核对清楚后，调整按固定顺序推进，先重建候选名单，再逐个确认目标，最后回写关系。这个顺序的价值在于：先解决“谁在边界外”，再解决“谁和谁是一类”，避免在错误名单上反复改名。

第一步：以系统边界为起点重列外部交互方

在评审白板或文档中先画出本次建模的系统边界，明确哪些功能在边界内。然后只从边界外寻找交互方：使用系统的人、与本系统对接的外部系统、接收系统输出的一方。内部模块、数据库、定时任务在这一步直接排除，不进入候选名单。

第二步：为每个候选写出目标与主要用例

对每个候选参与者用一句话写出它通过系统达成什么目标，再列出支撑该目标的主要用例。写不出目标，或目标需要多个互不相关的用例才能拼凑，说明该候选可能不是真正的参与者，或者需要拆分。目标相同、只是操作渠道不同的候选，在这一步就会暴露出来。

第三步：合并同义角色，剔除内部组件

把目标一致的候选合并为一个参与者，保留业务方最熟悉的名称，其余名称作为别名记录在模型说明中，避免后续再次出现。对第二步中确认位于边界内或仅提供数据的对象，从参与者列表移除，并在相关用例中补充支撑关系说明。

第四步：回写用例与参与者关系

按调整后的名单重新分配用例：每个用例明确发起参与者，必要时标注受益参与者；每个参与者至少关联一个承载其目标的用例。回写完成后检查是否存在无人关联的用例，这类用例往往提示遗漏了某个外部角色，或该用例本身不属于当前系统范围。

调整过程中会涉及参与者名单、用例关系和评审意见的同步修改。团队若在需求管理工具中维护用例模型，可以把参与者与用例作为可追踪的工作项或文档条目管理，评审意见挂接到对应条目上，调整后保留变更记录，便于下一轮评审对照。ONES 支持需求与工作项的结构化组织和评审流转，具体承载方式按团队现有配置确定。

调整后如何验证并防止再次走偏

调整完成不等于划分正确，需要用覆盖检查确认每个参与者都有目标支撑，再把检查项固化到评审流程中，减少下一轮模型再次出现同类问题。

用覆盖检查验证参与者划分

检查项	通过标准	责任人
参与者目标覆盖	每个参与者至少有一个用例承载其目标，且目标描述可被业务方确认	需求分析人员
用例发起方明确	每个用例都有明确的发起参与者，受益方与发起方不一致时已注明	用例作者
边界外验证	参与者名单中不存在系统内部组件、数据库或纯数据来源	架构或系统负责人
同义角色合并	不存在目标相同、仅名称或渠道不同的重复参与者	评审主持人
粒度匹配	单个参与者对应的用例目标集中，未出现大量互不相关用例堆叠	评审参与人

覆盖检查建议在调整后的下一次评审中作为固定议程，逐项确认并记录结论。检查不通过的条目回到调整步骤处理，不带着问题进入详细需求编写。

把检查项固化到评审与变更流程

复发预防的关键是让参与者识别口径成为评审的固定检查内容，而不是依赖个人经验。可以在用例模型评审清单中加入上述五项，明确主持人在评审前预检、评审中逐项确认。模型发生变更时，例如新增外部对接系统或调整业务流程，同步更新参与者名单和用例关系，并在变更记录中说明调整理由。参与者名称的别名表也应随模型维护，新成员加入时按别名表统一叫法，减少近义名称再次出现。

经过一轮完整调整和覆盖检查，参与者名单应满足：数量与外部交互方数量相当、每个名称对应独立目标、用例与参与者双向可追溯。达到这个状态后，用例模型可以进入后续的需求细化和评审流转。

常见问题

参与者名单里出现“数据库”“消息队列”这类对象，应该直接删掉吗？

先确认它是否位于系统边界之外、是否主动发起交互并期待可观察结果。多数情况下数据库和消息队列属于系统内部组件或纯数据来源，应从参与者列表移除，改在用例描述中注明数据来源或支撑关系。如果该对象确实是外部系统，通过接口与本系统交互并有明确的交互目标，则保留为参与者，并在名称上体现其外部身份。

同一类用户既用网页端也用移动端，算一个参与者还是两个？

判断依据是目标是否相同。如果两类使用方式服务于同一目标，只是操作渠道不同，应合并为一个参与者，渠道差异放到用例场景或非功能说明中描述。如果不同渠道对应明显不同的目标，例如现场人员用移动端完成即时上报、后台人员用网页端完成审核汇总，则按目标拆分为不同参与者。

评审时有人认为参与者划分没问题，问题出在用例粒度，怎么判断？

看用例是否服务于同一目标。一个参与者对应大量互不相关的用例，通常提示用例粒度过粗，应先拆分用例再回看参与者；一个用例需要多个目标不一致的参与者共同完成，则提示用例可能需要拆分或参与者需要合并。判断时以参与者目标为锚点，目标集中则粒度基本合适，目标分散则先处理粒度问题。

调整参与者后，原有的用例和评审记录怎么处理？

按调整后的名单重新分配用例，每个用例明确发起参与者，受益方与发起方不一致时注明；每个参与者至少关联一个承载其目标的用例。原评审记录保留，并在变更记录中说明调整理由和被合并、移除的名称，作为别名表的一部分。这样下一轮评审可以对照历史结论，避免同一问题反复讨论。

小团队没有专职评审主持人，覆盖检查还能落地吗？

可以简化执行。把五项覆盖检查压缩为三条必查项：每个参与者有目标、每个用例有发起方、名单中无内部组件和数据来源，由需求分析人员在模型更新后自查并记录结论。团队规模扩大或外部对接增多时，再补充同义角色合并和粒度匹配两项，并指定一人负责评审前预检。