6.2用例文本

09 May 2018

摘要用例

UC1 注册商家

• Actor：商家
• Type：Primary
• Description：商家想要使用该点餐系统，登录我们的网站，进入注册界面，填写相关信息，获取手机验证码，完成注册。

UC2 发布菜品

• Actor：商家
• Type：Primary
• Description：厨房研发出新的菜式并认为值得推出，于是商家进入管理菜单页面，点击新建菜品按钮，上传菜品图片以及菜品描述，并且选择菜品类别，最后点击发布。

UC3 催单

• Actor：顾客
• Type：Primary
• Description：顾客点完菜品后，等待许久依然没有上菜，于是进入订单管理页面，在未完成订单中对需要催促的菜品点击催单按钮，并收到厨房的反馈。

非正式用例

UC4 扫码开始点餐

参与者：顾客 服务器

目的：顾客向服务器提交自己所在的餐厅和具体餐桌信息。

概要：顾客进入某餐厅，在餐桌前坐下，用手机扫描餐桌上的二维码，服务器返回二维码对应的餐厅、餐桌信息，顾客确认自己所在的餐厅和餐桌后，开始点餐。

类型：基础 重要

参考：

活动图：

UC5 点餐

参与者：顾客 服务器

目的：顾客选择想要的菜品。

概要：服务器向顾客返回当前餐厅的菜单，顾客浏览菜单并选择需要的菜品及其数量。

类型：基础 重要

参考：

活动图：

UC6 编辑菜品信息

参与者：商家 服务器

目的：商家修改菜单内容。

概要：商家在打开网页，登录在编辑菜品信息处添加、修改或删除菜品，并确认操作。服务器接收到相关信息后修改数据库内容。

类型：基础 重要

参考：

活动图：

详述用例：UC7 扫码点餐

范围

Eat点点 点餐系统

级别

用户目标

主要参与者

顾客

涉众及其关注点

• 顾客：需要便捷地浏览餐厅菜单并向餐厅付款下单。希望可以方便地向餐厅提出其他需求并得到反馈
• 工作人员：需要快速收到顾客的订单通知。希望能够向顾客反馈信息
• 餐厅老板：需要编辑餐厅信息（餐厅介绍、菜单等）。希望可以统计餐厅的业务数据

前置条件

无

后置条件

存储订单信息，更新统计数据

主成功场景

1. 顾客扫码进入餐厅主界面
2. 顾客浏览菜单，编辑订单，然后向餐厅付款下单
3. 系统存储订单，并通知工作人员
4. 工作人员收到订单通知，开始做菜
5. 工作人员上菜

扩展

*a. 顾客随时可以呼叫服务员

1. 顾客在主界面上选择呼叫服务员
2. 系统通知餐厅服务员
3. 某个服务员进行回应

2-a. 菜品库存不足

1. 系统通知顾客某菜品库存不足
2. 系统把库存不足的菜品从菜单上下架
3. 系统把顾客重定向到菜单界面

2-b. 付款失败

1. 系统通知顾客付款失败
2. 系统把顾客重定向到付款界面

3-a. 顾客请求取消未完成的订单

1. 顾客在主界面上发出取消未完成订单的请求
2. 系统通知工作人员
3. 工作人员进行回应

3-a. 工作人员同意取消

1. 系统撤销订单并回滚相应数据
2. 系统通知顾客取消订单操作成功
3. 系统退款给顾客

3-b. 工作人员不同意取消

1. 工作人员给出理由
2. 系统通知顾客取消订单请求已被拒绝，并显示理由

特殊需求

• 系统的平均响应时间低于10秒
• 系统必须可靠，使用者几乎不需要关心系统的失败问题
• 系统要有一定的安全性
• 系统需要实时通知工作人员
• 系统每隔一段时间要统计各项业务数据
• 菜单要支持图片，而且可以控制菜品展示的优先级

技术与数据变元表

• 餐厅老板需要登录以编辑餐厅信息

发生频率

非常高

未决问题

• 系统的可靠性如何保障？
• 系统的实时响应如何保障？
• 系统的安全性如何保障？