一、用例描述是啥？—— 用例图的“文字说明书” 📖
关键字：用例描述、what而非how、事件流
📌
用例图是“功能的漫画”，
用例描述就是“漫画的文字脚本”
——它讲清楚“这个用例是做啥的、谁来用、怎么用”，但
不写“系统内部怎么实现”
（比如不写“用Java还是Python开发”）。
💡 新手类比：
就像点外卖的“操作说明”：只写“打开APP→选餐→付款→等配送”，不写“APP后台怎么调接口、怎么算配送费”。
二、用例描述的“标配内容”：一个都不能少 ✅
关键字：用例名称、参与者、触发器、前置/后置条件、事件流
📋 核心组成（以“提交订单”为例）：
- 🔤用例名称：比如“提交订单”（动词短语，说清楚干啥）；
- 👫参与者：比如“会员”（谁用这个功能）；
- 🚨触发器：“当用户点击‘提交订单’按钮时”（啥时候触发这个用例）；
- 🔑前置条件：“用户已登录且购物车有商品”（用例执行前必须满足的条件）；
- 🏁后置条件：“订单生成并扣减库存”（用例执行后的结果）；
- 🔄事件流：用例的“操作步骤”（最核心的部分！）。
三、事件流：用例的“操作剧本” 🎬
关键字：基本事件流、扩展事件流、快乐路径
- 基本事件流：“一帆风顺”的操作 ✨
也叫“快乐路径”——描述
没出任何问题的理想流程
，用编号写步骤。比如“提交订单”的基本事件流：
-
会员在购物车点击“提交订单”； 2. 系统验证会员信息和商品信息； 3. 系统检查商品库存； 4. 系统计算订单总价； 5. 系统从会员账户扣减金额； 6. 系统生成订单并发送给仓库； 7. 系统显示“订单提交成功”页面。
-
扩展事件流：“出意外”的应对方案 ⚠️
描述
异常/分支情况
，比如“库存不足”“账户余额不够”，用“A-编号”区分。比如：
A-1 若商品库存不足： 1. 系统提示“商品XXX库存不足”； 2. 用例终止，会员需修改订单。
四、补充约束：用例的“隐形规则” 📜
关键字：数据需求、业务规则、非功能需求
📌
除了“怎么操作”，还要写用例的“规则”——比如：
- 📊数据需求：“订单信息包含订单号、商品列表、金额”；
- 📏业务规则：“只有商品信息确认无误后，才能要求支付”；
- ⚡非功能需求：“订单提交响应时间不超过2秒”。
五、用例文档：把描述“打包”成正式文件 📁
关键字：用例文档、标准化模板
📚
把上面的内容整理成“标准化文档”，就是用例文档——比如课本里“提交订单”的用例文档（表4-2），是团队沟通的“统一手册”（产品、开发、测试都看这个）。
💡 新手提醒：
写用例描述时，
别写界面细节
（比如“点击红色的提交按钮”）——因为界面可能改，但“提交订单”的流程不会变~
总结：用例描述是“需求的统一语言” 🗣️
🎉
用例描述解决了“产品说的功能，开发听不懂”的问题——它用“业务语言”写清楚功能的“谁、做啥、咋做”，让所有人对“需求”的理解保持一致~