系统的边界、有意义的任何事（人、事、物）、参与者与系统交互的 “具体业务场景 / 动作”、用例间关系
做业务用例的核心是梳理“谁（角色）在业务中做什么（动作）、达成什么目标”，用标准化结构呈现业务流程，方便沟通和落地。
一、明确核心前提（避免做无用功）
- 锁定业务范围：先界定“做哪个业务/场景”，比如“用户线上充值”“员工请假审批”，不超出边界。
- 识别关键角色（参与者）：包括外部角色（用户、客户、合作方）和内部角色（员工、系统管理员），明确“谁和业务交互”。
- 定义业务目标：每个用例对应一个具体目标，比如“用户完成账户充值”“审批通过员工请假申请”，不模糊。
二、业务用例的核心组成（按顺序梳理）
1. 用例基本信息（清晰标识）
- 用例名称：简洁动宾结构，比如“用户注册”“订单退款”。
- 编号：按业务模块编号，比如“UC-用户-001（用户注册）”，方便管理。
- 参与者：明确核心交互角色，比如“用户”“客服人员”。
- 业务目标：一句话说明该用例要达成的结果。
2. 前置条件（触发用例的前提）
- 列出执行用例前必须满足的条件，比如“用户已下载APP并打开”“员工已入职且有系统账号”。
3. 后置条件（用例执行后的结果）
- 分“成功结果”和“失败结果”，比如“成功：用户账户余额增加；失败：充值未到账，提示错误信息”。
4. 核心流程（主场景，按步骤写）
- 按时间顺序列出“参与者动作+系统/业务响应”，每步只写一个核心操作，比如：
- 用户点击“充值”按钮，选择充值金额。
- 系统展示支付方式（微信、支付宝）。
- 用户选择支付方式并完成支付。
- 系统验证支付结果，更新账户余额。
- 系统向用户发送充值成功通知，用例结束。
5. 扩展流程（异常/分支场景）
- 梳理主流程之外的特殊情况，比如“用户支付超时”“支付失败”“填写信息错误”，每个分支对应处理步骤：
- 分支1（支付超时）：步骤3后未完成支付→系统提示“支付超时”，返回充值页面，用例终止。
- 分支2（支付失败）：步骤4验证支付失败→系统提示“支付失败，请重试”，允许用户重新选择支付方式。
6. 其他补充（可选，按需添加）
- 业务规则：比如“单笔充值最低10元，最高5000元”“请假审批需部门经理先批，再由HR确认”。
- 数据需求：需记录的信息，比如“充值记录（用户ID、金额、支付时间、订单号）”。
三、实操步骤（从简单到复杂）
- 先画用例图（梳理关系）：用矩形表示业务边界，小人表示参与者，椭圆表示用例，线条连接“参与者-用例”，明确交互关系。
- 逐个填写用例详情：按上面的“核心组成”，针对每个椭圆（用例）补充信息。
- 评审优化：找业务负责人、执行角色（比如客服、开发）核对，确认流程无遗漏、规则无偏差。
四、注意避坑
- 不写技术细节：业务用例聚焦“业务层面”，比如只写“系统验证支付结果”，不写“系统调用支付接口、校验签名”。
- 一个用例一个目标：避免“用户注册+登录”合并为一个用例，拆分后更清晰。
- 流程不冗余：每个步骤都是达成目标的必要操作，删除无效动作（比如“用户查看首页”不属于“充值”用例）。