用例文档应该包括哪些内容

1. 什么是用例？

2. 什么是用例的参与者？

3. 用例的粒度

4. 用例文档包含的内容

 

1. 什么是用例？

1. 用例是为其参与者所执行的有价值的操作。参与者是以某种方式与系统交互的人或事。
2. 用例不是功能或特性，用例包含一个对参与者来说有完整意义的过程。
3. 用例解释系统如何向利益相关者/参与者提供功能性价值。
4. 用例通过使用者视角描述系统与其互动的方式，从而观测出系统实现。
   1. 特性︰人们可以取钱   ——用例:取钱
   2. 特性:系统可以自动选择吐钞面值组合  ——用例:取钱
5. 用例不是用例图，用例的大部分内容会在用例文档中描述出来。
6. 没有大量交互的产品很难通过用例来表达，比如策略型产品、Al类产品的引擎、业务接口描述等等。
7. 用例缺乏约束性描述，还需要「非功能型需求」等描述。
8. 我们需要一个组织UC的整体业务文档，可以用 PRD来做这件事情

2. 什么是用例的参与者？

1. 参与者不是具体的人，而是角色，一个人可以多个角色
2. 参与者不一定是人，也有可能是系统
   1. 比如时间、模块等
3. 先写多一些参与者，然后再进行合并和抽象。
4. 抽象时候要适度，但不要过度泛化。

3. 用例的粒度

1. ·系统为参与者提供的具备完整价值的服务。(关注价值而非功能)
   1. 「查看商品详情」是不是一个用例?
   2. 理论定义上不是一个用例，但实际上如果这个动作比较复杂，交互较多，他就能成为一个用例
2. 这个用例是一个完整的具有可销售价值的服务吗?老板测试?
   1. 用例:用户管理vs.修改用户密码
3. 以主动的逻辑命名
   1. 风险评估vs.评估风险(✔)
4. 划定系统边界，什么是边界内的?外的?

4. 用例文档包含的内容

1. 标题作者修改历史
2. 简要描述
3. 利益相关者/涉众/参与人及其相关利益
4. 事件流：基本流程/扩展流程/异常流程
   1. 用例文档中最重要的部分是「事件流」，描述如何通过交互传递由用例所承诺的价值。
   2. 用例文档是一个被严格流程化规范化的故事，它像一个「词牌名」
      1. 用例开始（入口)→{用户发起请求→系统校验请求→系统处理→系统反馈}→用例结束
      2. 即便啰嗦，也要严格按照上面步骤编写，可以帮助自己快速切换视图，注意主语。
   3. 基本流/扩展流/异常流
      1. 基本流（没有异常/分支）：做8路汽车，江二村下车;确定6路汽车还营运，坐6路汽车到地铁2号线江陵路站;地铁出来门口吃点东西。
      2. 扩展流（用户做出了另外的选择）如果不饿不想吃东西，也可以旁边星巴克做一会儿。
      3. 异常流（系统没有像预期那样反馈用户数据）如果6路汽车不运营了，就直接打车。
   4. 基本流中没有任何分支，没有如果，只有顺序描述，预期会成功的路线。
   5. 基本流必须完整，不能引用其他扩展流。
   6. 事件流的故事描述，不应该有交互和界面相关的元素（也不一定)
      1. 用户点击提交按钮  ✖
      2. 用户向系统请求提交表单 ✔
   7. 没有具体技术实现
      1. 系统将销售记录生成SQL并执行，写入数据库 ✖
      2. 系统记录销售 ✔
5. 辅助图例
6. 前置条件/后置条件
7. (*）术语表
8. (*）界面图例
9. (*）限制条件/特殊需求/策略