6.需求规格说明书
21 Apr 20186.1 用例图
可以使用鼠标右键查看原图
-
顾客用例
-
商家用例
6.2 用例文本
摘要用例
UC1 注册商家
- Actor：商家
- Type：Primary
- Description：商家想要使用该点餐系统，登录我们的网站，进入注册界面，填写相关信息，获取手机验证码，完成注册。
UC2 发布菜品
- Actor：商家
- Type：Primary
- Description：厨房研发出新的菜式并认为值得推出，于是商家进入管理菜单页面，点击新建菜品按钮，上传菜品图片以及菜品描述，并且选择菜品类别，最后点击发布。
UC3 催单
- Actor：顾客
- Type：Primary
- Description：顾客点完菜品后，等待许久依然没有上菜，于是进入订单管理页面，在未完成订单中对需要催促的菜品点击催单按钮，并收到厨房的反馈。
非正式用例
UC4 扫码开始点餐
参与者：顾客 服务器
目的：顾客向服务器提交自己所在的餐厅和具体餐桌信息。
概要：顾客进入某餐厅，在餐桌前坐下，用手机扫描餐桌上的二维码，服务器返回二维码对应的餐厅、餐桌信息，顾客确认自己所在的餐厅和餐桌后，开始点餐。
类型：基础 重要
参考：
UC5 点餐
参与者：顾客 服务器
目的：顾客选择想要的菜品。
概要：服务器向顾客返回当前餐厅的菜单，顾客浏览菜单并选择需要的菜品及其数量。
类型：基础 重要
参考：
UC6 编辑菜品信息
参与者：商家 服务器
目的：商家修改菜单内容。
概要：商家在打开网页，登录在编辑菜品信息处添加、修改或删除菜品，并确认操作。服务器接收到相关信息后修改数据库内容。
类型：基础 重要
参考：
详述用例：UC7 扫码点餐
范围
Eat点点 点餐系统
级别
用户目标
主要参与者
顾客
涉众及其关注点
- 顾客：需要便捷地浏览餐厅菜单并向餐厅付款下单。希望可以方便地向餐厅提出其他需求并得到反馈
- 工作人员：需要快速收到顾客的订单通知。希望能够向顾客反馈信息
- 餐厅老板：需要编辑餐厅信息（餐厅介绍、菜单等）。希望可以统计餐厅的业务数据
前置条件
无
后置条件
存储订单信息，更新统计数据
主成功场景
- 顾客扫码进入餐厅主界面
- 顾客浏览菜单，编辑订单，然后向餐厅付款下单
- 系统存储订单，并通知工作人员
- 工作人员收到订单通知，开始做菜
- 工作人员上菜
扩展
*a. 顾客随时可以呼叫服务员
- 顾客在主界面上选择呼叫服务员
- 系统通知餐厅服务员
- 某个服务员进行回应
2-a. 菜品库存不足
- 系统通知顾客某菜品库存不足
- 系统把库存不足的菜品从菜单上下架
- 系统把顾客重定向到菜单界面
2-b. 付款失败
- 系统通知顾客付款失败
- 系统把顾客重定向到付款界面
3-a. 顾客请求取消未完成的订单
- 顾客在主界面上发出取消未完成订单的请求
- 系统通知工作人员
- 工作人员进行回应
3-a. 工作人员同意取消
- 系统撤销订单并回滚相应数据
- 系统通知顾客取消订单操作成功
- 系统退款给顾客
3-b. 工作人员不同意取消
- 工作人员给出理由
- 系统通知顾客取消订单请求已被拒绝，并显示理由
特殊需求
- 系统的平均响应时间低于10秒
- 系统必须可靠，使用者几乎不需要关心系统的失败问题
- 系统要有一定的安全性
- 系统需要实时通知工作人员
- 系统每隔一段时间要统计各项业务数据
- 菜单要支持图片，而且可以控制菜品展示的优先级
技术与数据变元表
- 餐厅老板需要登录以编辑餐厅信息
发生频率
非常高
未决问题
- 系统的可靠性如何保障？
- 系统的实时响应如何保障？
- 系统的安全性如何保障？
6.3 领域模型
领域模型（Domain Model）如下：
6.4 State Model（状态模型）
状态模型（State Model）如下：
6.5 System Sequence Diagram（系统顺序图）
SSD1 15331321
契约CO1：编辑订单
操作：（操作，菜品）
交叉引用： 用例： 扫码点餐
前置条件： 操作参数必须是增加、删除中的其中一个
后置条件： 返回一个更新后的购物车