Use cases

详述用例 Use case 1 顾客点餐

范围 ：tiny hippo 点餐应用

级别 ：用户目标

主要参与者 ：顾客

涉众及关注点：

• 顾客： 希望便捷、清晰地看到本店的所有菜式。希望便捷、清晰地看到店内的可点菜式。同一桌上的不同顾客可以同时对本桌的菜单进行编辑。可以先确认点部分菜单，需要再灵活添加，最后吃饱了再确认付款总金额。可以看到当前点餐的金额。
• 前台服务员：希望能够得到当前店中这一桌的用餐状态。得到这一桌点餐确认菜单。对已经上的菜式可以方便在系统上确认并反馈给用户。可以获得这一桌当前的消费金额。
• 店主：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即使在某些服务器构件不可用时（如微信支付），也能够完成销售。希望能够自动、快速地更新账务和库存信息。
• 支付授权服务：希望接受到格式和协议正确的数字授权请求。希望准确计算对餐馆的应付款。

前置条件 ：顾客必须先通过扫码确认在一个特定的桌子坐下。顾客必须通过微信登录认证。

成功保证（后置条件） ：存储销售信息。准确计算税金。更新账务和库存信息。记录提成、生成票据。记录支付授权的批准。

主成功场景（或基本流程） ：

1. 参与点餐的顾客（可多人）通过扫空闲餐桌上的二维码确认就坐。
2. 参与点餐的顾客（可多人）通过浏览菜单界面了解当前餐馆可选菜式的信息。
3. 参与点餐的顾客（可多人）选择各自想要的菜式，并选择份数，添加进预订单界面。
4. 参与点餐的顾客（可多人）可以在预订单中查看当前此桌已点菜式的份数和总共金额。
5. 参与点餐的顾客（可多人）均确认预订单后，预订单冻结，不能再修改菜式与份数，厨房开始准备相应菜式。
6. 顾客可以在中途新建预订单，并通过确认后（即重复2~5步）进行加菜。
7. 顾客用餐完毕后，选择支付方式。
8. 若选择支付方式为现金支付，则可以到前台服务员处选择合适的收款方式进行收款（可选现金、支付宝、刷卡支付）。
9. 若选择支付方式为微信支付，则在线支付即可。
10. 系统生成订单票据，顾客携带票据离开（如果有）。

扩展（或替代流程）：

• *a. 顾客在点餐过程的任意时段意外退出小程序：
  1. 系统保存当前顾客的用餐状态。
  2. 顾客重新进入系统后，系统恢复顾客退出之前的界面信息。
• 3a. 顾客选择此菜式的时候恰好没有剩余食材了
  1. 跳出弹窗告知该菜式恰好没有食材了并表示歉意
• 4a. 同一桌的多个顾客之间的点餐信息进行协调
  1. 每位顾客点了哪份菜式以及选了几份在预订单界面中会显示。
  2. 参与点餐的顾客（可多人）仅能够在预订单中删除自己点菜式和份数。
  3. 参与点餐的顾客（可多人）可以在预订单中原有的菜式上添加份数。
• 5a. 系统友情提醒再次确认订单无误。
  1. 原则上不接受用餐中途退菜服务，在确认订单前弹窗提醒帮助顾客合理选择份量。
• 8a. 现金支付
  1. 前台服务员输入收取的现金额
  2. 系统显示找零金额
  3. 前台服务员放入收取的现金，并给顾客找零
  4. 系统记录该现金支付，初始化该桌号的用餐状态
• 8b. 微信支付
  1. 顾客点击支付，选择微信支付选项
  2. 系统调用微信支付接口，提示顾客支付金额以及输入密码
  3. 顾客确认金额无误支付订单，微信返回支付状态为支付成功，系统记录该在线支付，初始化该桌号的用餐状态
• 8c. 支付宝支付
  1. 前台服务员提供本店的支付宝二维码付款码
  2. 顾客打开支付宝扫一扫进行扫码付款
  3. 前台服务员确认收款金额并确认用餐完毕，系统记录该在线支付，初始化该桌号的用餐状态
• 8d. 信用卡支付
  1. 前台服务员使用信用卡支付设备引导顾客完成支付流程
  2. 前台服务员确认用餐完毕，系统记录该信用卡支付，初始化该桌号的用餐状态

特殊需求：

• 支持文本显示的语言国际化

技术与数据变元表：

• 9a. 可以支持微信、支付宝、 信用卡、现金付款。

发生频率 ：可能会不断地发生。

未决问题 ：

• 研究远程服务的恢复问题
• 不同顾客获取当前预订单状态的时候，如何保证数据一致性问题
• 顾客扫码确认就坐后因事暂离，如何规避不道德的占座问题

非正式用例

Use Case 2.1 顾客支付

主成功场景：顾客点完餐后，进入订单界面，点击支付，系统提示是否确认提交订单，顾客点击确定后，系统提示选择支付方式，顾客选择微信支付并成功支付，订单状态自动更新为已支付，购物车被清空。

交替场景：

• 顾客点击支付后发现要修改订单，点击取消支付返回订单页面。
• 顾客选择支付方式为现金支付，到前台要求现金或银行卡支付或支付宝支付，前台服务员提供合适的收款方式收到付款后手动更新订单状态为已支付。
• 如果系统检测到与支付平台通信失败，顾客无法支付，跳转回订单页面顾客重新选择支付。

用例图：

活动图：

Use case 2.2 顾客提交订单

主成功场景：桌上每位顾客点餐完毕后，询问大家是否点完餐了，点击提交订单，确认并提交订单，订单页面上显示已提交。

交替场景：

• 顾客需要加菜，在主菜单界面添加菜品后，返回订单页面，发现已提交状态变为提交订单，并留意到tips写着不会重复下单，顾客确认新订单后提交新订单，订单状态重新变为已提交。
• 顾客提交订单后，选择支付订单。

用例图：

活动图：

简述用例

Use case 3.1 查看今日推荐

• Actor：顾客
• Type：Primary
• Description：顾客进入小程序，切换到今日推荐的页面，浏览自己感兴趣的菜单，并点击进入菜单查看相关描述和菜式推荐，选择自己喜欢的菜式加入到购物车。

Use Case 3.2 新增菜品

• Actor：商家
• Type：Primary
• Description：厨房研发出了新的菜式，老板试过味道觉得可以推出， 于是进入管理界面，提供菜式图片url与菜品的描述，选择菜品的类别， 并点击确定，在菜单页面看到该菜式后，打开小程序，在主菜单页面也能看到该菜品，上传成功。

Use Case 3.3 新增推荐

• Actor：商家
• Type：Primary
• Description：现在是世界杯期间，老板认为可以给顾客推荐自己店里一组世界杯主题的菜，于是进入管理界面，点击新增推荐的功能， 提供新菜单的封面图url，输入标题，选择菜式与描述，点击submit，看到推荐页面出现该推荐菜单，打开小程序后推荐页面也能看到该菜单。