什么是用例（Use Case）

它是一种建模思想，从 UML 而来。分为用例图和用例文档。用例图不是用例，真正的用例是会写在用例的文档里。

用例就是通过用例图和用例文档组合起来描述系统如何被使用以及系统如何与参与者互动。

• 参与者

• 以某种方式与系统交互的人或事

• 用例

• 系统与其参与者所执行的有价值操作

• 用例不是功能或特性，用例包含一个对参与者来说有完整意义的过程。

比如：用户输入密码，这是个功能；而用户取款，这才是个用例

• 用例解释系统如何向利益相关者/参与者提供功能性价值。

• 用例通过使用者视⻆描述系统与其互动的方式，从而观测出系统实现。

• 特性:人们可以取钱 用例:取钱

• 特性:系统可以自动选择吐钞面值组合 用例:取钱

用于产品经理来讲，要做的事情就是想办法告诉工程师，用户会在什么环境下，什么场景下，怎样的来使用，所以要尽量把这些用例的场景想的足够完善。

• 用例不是用例图，用例的大部分内容会在用例文档中描述出来。

• 没有大量交互的产品很难通过用例来表达，比如策略型产品、AI 类产品的引擎、业务接口描述等等。

• 用例缺乏约束性描述，还需要「非功能型需求」等描述。

• 我们需要一个组织 UC 的整体业务文档，可以用 PRD 来做这件事情。

用例是很重要的单位元素，但是它不是产品文档的全部。

用例的参与者

• 参与者不会是"人"，而是"角色"，一个人可以有多个身份。

在画用例图的时候要注意，并不是有一个人就画一个，要根据角色来画。

• 参与者不一定是"人"，也可能是系统，甚至有可能是时间

比如系统的定时任务，这个参与者就不是一个人

• 先写多，再合并抽象

把脑子里能想到的角色都写出来，越多越好，然后再合并抽象

• 要抽象，但是不要过度泛化

用例的粒度

• 系统为参与者提供的具备完整价值的服务。(关注价值而非功能)

用例的粒度没有固定的公式可用，根据实际情况来判定。如果一个功能很复杂涉及的场景比较多，那它可能就会是一个用例。例如，如果当前做的一个完备的电商系统，那对于订单的增删改查的每一项就不是一个独立的用例，需要把这些抽象成一个用例，可如果当前做的就是一个订单管理系统，那订单的增删改查每一项就可以抽象成一个独立的用例。

• 这个用例是一个完整的具有可销售价值的服务吗?老板测试?

一个最简单的验证方法就是，这个东西用户会买单吗？如果会，那就是好用例，否则就不是。

不断的迭代，会发现更好的方式

• 用例:用户管理 vs. 修改用户密码

• 以主动的逻辑命名

• ⻛险评估 vs. 评估⻛险

后面的说法好于前者，某个参与者做某件事情

用例文档包含的内容

• 标题作者修改历史

• 简要描述

• 利益相关者/涉众/参与人及其相关利益

• 事件流:基本流程/扩展流程/异常流程

刚开始写的时候一定要按照这个流程来写，把基本流程、扩展流程、异常流程完全分开；基本流程非常简单，大部分文字都在描述扩展流程和异常流程。

• 辅助图例

状态机、流程图或者界面的线框图

• 前置条件/后置条件

• (*)术语表

• (*)界面图例

• (*)限制条件/特殊需求/策略

用例文档是描述需求的一种方式。在用例文档里不应该描述交互 ，不应该说用户点击按钮，应该说用户提交请求，不应该说用户关闭窗口，应该说用户提交完成的请求。用例是要交给交互设计师来设计，在这里写交互会影响交互设计师的判断。教科书里的说法和实际使用会不同。

用例文档的核心-事件流

• 用例文档中最重要的部分是「事件流」，描述如何通过交互传递由用例所承诺的价值。

• 用例文档是一个被严格流程化规范化的故事，它像一个"词牌名"。

这样写可以规范你的思考，去保证事无巨细的想到交互过程里面可能覆盖到的异常和可能覆盖到的扩展

• 用例开始(入口) → {用户发起请求 → 系统校验请求 → 系统处理 → 系统反馈} → 用例结束

• 基本流/扩展流/异常流

• 坐 8 路汽⻋，江二村下⻋;确定 6 路汽⻋还营运，坐 6 路汽⻋到地铁 2 号线江陵路站;地铁出来⻔口吃点东⻄。

• 如果不饿不想吃东⻄，也可以旁边星巴克坐一会儿。

• 如果 6 路汽⻋不运营了，就直接打⻋。

基本流的含义是一个分支都没有，全部都是按照用户发起请求，系统校验请求，系统反馈请求的逻辑一直走到最后。然后在每一个用户发起请求的地方都有可能长出来一个扩展流，在每一个系统校验请求的地方都有可能发展出一个异常流，在每一个系统处理的过程中都有可能有扩展或异常。然后从具体的点上去长出扩展流和异常流放到外面去。基础流蠢蠢的就结束了。

• 基本流中没有任何分支，没有如果，只有顺序描述，预期会成功的路线。

• 即便啰嗦，也要严格按照 1 2 3 4 步骤编写，可以帮助自己快速切换视图，注意主语。

• 基本流必须完整，不能引用其他扩展流。

• 事件流的故事描述，不应该有交互和界面相关的元素(也不一定)

• 用户点击提交按钮 ✕

• 用户向系统请求提交表单 ✓

• 没有具体技术实现

• 系统将销售记录生成 SQL 并执行，写入数据路 ✕

• 系统记录销售 ✓