极客大学产品经理训练营用例Use Case 第8课总结

本文链接：https://blog.csdn.net/zgpeace/article/details/113729471

说明

讲师：邱岳(二爷)

在这里插入图片描述

在这里插入图片描述

用例的特征：

拍卖的用例图：火柴人表示角色，一般左侧放重要的角色，右边放次重要的角色。
在这里插入图片描述

系统为参与者提供的具备完整价值的服务。（关注价值而非功能）
【查看商品详情】是不是一个用例？
答案：看情况。教科书说不是一个用例，因为对用户没有什么价值，购买才能使。当查看商品详情有比较明确的终点和目的的时候，是可以当做一个用例的。比如商品详情里面的放大缩小图片，比如购买商品详情里面，作为部分的商品的时候，比如商品详情里有商品使用教程。
这个用例是一个完整的具有可销售价值的服务吗？老板测试？
比如老板问，你整天忙着干嘛，你说一天忙着登录，那老板就疯了。
用例：用户管理 vs. 修改用户密码

99% 的情况用管理订单。如果订单很复杂，比如淘宝的订单系统，那么就需要单独拆开。
以主动的逻辑命名
风险评估× vs. 评估风险 ✔️
划定系统边界，什么是边界内的? 外的？

用例：ATM机
在这里插入图片描述

用例文档中最重要的部分是【事件流】，描述如何通过交互传递用例所承诺的价值。
用例文档是一个被严格流程化规范化的故事，它像一个【词牌名】。
用例开始（入口）–> {用户发起请求 --> 系统校验请求 --> 系统处理 --> 系统反馈 } --> 用例结束
基本流 / 扩展流 / 异常流
例子基本流：坐 8 路汽车，江二村下车；确定 6 路清澈还营业，做 6 路汽车到地铁 2 号线江陵路站；地铁出来门口吃点东西。
例子扩展流：如果不饿不想吃东西，也可以旁边星巴克做一会儿。
例子异常流：如果 6 路汽车不运营了，就直接打车。
基本流中没有任何分支，没有如果，只有顺序描述，预期会成功的路线。
即使啰嗦，也要严格按照 1 2 3 4 步骤编写，可以帮助自己快速切换视图，注意主语。
基本流必须完整，不能引用其它扩展流。
事件流的故事描述，不应该有交互和界面相关的元素（也不一定）
用户点击提交按钮 ×
用户向系统请求提交表单 ✔️
也不一定的例子（公司没有交互设计师时）
没有具体技术实现
- 系统将销售记录生成 SQL 并执行，写入数据路 ×
- 系统记录销售 ✔️

一起写一个： ATM 机取钱的事件流

基础流程

扩展流程

4a. 系统无法识别银行卡
4a1. 系统提示用户，银行卡错误
4a2. 系统推出卡片
4a3. 用例结束
4b. 系统识别到挂失银行卡
4b1. 系统提示用户，银行卡有误
4b2. 系统发出警报，并录下用户脸庞
4b3. 系统锁住 ATM 小房间
4b4. 用例结束
4c. 系统识别卡片插反
4c1. 系统提示用户，卡片插反
4c2. 系统推出卡片
4c3. 系统播放正确的卡片插入样式
4c4. 用户重新插入卡片，若未插入卡片，用例结束
4c5. 执行用例4
7a. 系统验证密码不正确
7a1. 系统提示用户密码错误，提示用户剩余密码尝试次数
7a2. 系统展示密码输入界面
7a3. 用户输入密码
7a4. 系统扣除密码尝试次数
- 7a5. 系统校验密码正确
  7a5a. 系统校验密码错误
  7a5a1. 判断尝试次数用尽
  7a5a2. 锁卡
  否则执行 7a1
  7a6. 继续执行步骤 8