用例（UC，Use Case）

什么是 UC？

用例由参与者、系统和有价值的动作三部分组成。

参与者

1） 参与者又叫火柴人（actor），是以某种方式与系统交互的角色。

2） 参与者先写多，再合并和抽象，但不要过度泛化。

3） 特殊的参与者：系统（内容审核）、时间（每 30min 发送提醒）等。

UC 的特征

1） 用例不是功能或特性，而是系统为参与者所执行的有价值的完整操作。

e.g. 取款、存款可以写用例，但登录不是

2） 用例缺乏约束性描述，还需要【非功能性需求】等描述。

UC 的规范

1） 粒度以“是否有价值”为准侧，而非功能

e.g. 登录可以写作 UC 吗？当是 SSO 系统时，完全可以

2） 命名规范：动词在前

e.g. 评估风险优于风险评估

什么时候用 UC？

1. 有大量交互时

2. 有功能性描述时

1）当角色与系统有大量交互时，用 UC 可以更清晰地看到系统的工作原理；

2) UC 一般用来描述功能性需求，像策略性、业务接口描述等不适用 UC

为什么要写用例

1. 是一种与开发高效沟通的手段，可以帮助缕清数据流转、系统工作原理

2. 一个用例可能含有很多系统特性（feature），但对用户来说其是透明的

怎么写 UC？

首先要明白：用例是通过使用者视角，描述系统与其互动的方式，从而观测出系统实现。

用例文档的组成

• 标题作者修改历史

• 简要描述

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

• 事件流：进本流程 / 扩展流程 / 异常流程

写作流程：用例开始（入口）–> {用户发起请求 --> 系统校验请求 --> 系统处理 --> 系统反馈 } --> 用例结束 • 辅助图例

• 前置条件（确保系统在正确起点） / 后置条件（确保系统正确的结束）

• 术语表()

• 界面图例(）

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

-------------------------------上完课还是不会做作业，就先写写笔记吧--------