Requirement Specification（需求规格说明）

• 6.1 Usecase Diagram（用例图）
• 6.2 Use Cases（用例+活动图）
  • 正式用例
  • casual用例
    • casual用例1–显示餐厅用餐情况
    • casual用例2-显示餐桌具体情况
    • casual用例3-接收订单
    • casual用例4-订单分配厨师/菜品分配服务员
    • casual用例5-响应催单
    • casual用例6-结账
    • casual用例7-菜品信息管理
  • brief用例
    • brief用例1–搜索菜品
    • brief用例2–用户点餐
    • brief用例3–用户点评
• 6.3 Domain Model（领域模型）
• 6.4 State Model（状态模型）
• 6.5 System Sequence Diagram（功能模型）
  • 15310022-付款
  • 15331020-评价菜品
  • 15331030-点餐
  • 15331016-完成订单
  • 15331007-搜索菜品
  • 15331149-排队
  • 15331147-导航
• 6.6 Supplementary Requirements（补充需求）
  • 修订历史
  • 简介
  • 功能性
  • 可用性
  • 可靠性
  • 可支持性
  • 实现约束
  • 接口
  • 应用的领域（业务）规则
  • 所关注领域内的信息

6.1 Usecase Diagram（用例图）

6.2 Use Cases（用例+活动图）

正式用例

• 用例名称

  • 处理账单

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与者

  • 顾客

• 涉众及其关注点

  • 顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到商品项目和价格。

  • 商家：希望生成的价格正确。希望准确地记录交易，满足顾客需求。希望能够自动、快速地更新账务和账单信息。希望确保记录了支付授权服务的支付票据。

  • 支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商家的应付款。

  • 政府税收代理：希望能从每笔交易中抽取税金。

• 前置条件

  • 顾客已完成点餐操作

• 成功保证（或后置条件）

  • 存储付款信息。更新账务。记录支付授权的批准。准确计算税金。

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

  • 顾客点击订单进行付款

  • 系统根据菜单生成应付金额

  • 顾客付款，系统处理支付

  • 系统记录完整的订单信息，并把信息发送到账务系统

• 扩展（或替代流程）

  • 系统在任意时刻失败：

    • 为了支持恢复和更正账务处理，要保证所有交易的敏感状态和事件都能从场景的任何一步中恢复。

    • 顾客重启系统，登陆，请求恢复上次状态。

    • 系统重建上次状态。

    • 系统在恢复过程中检测到异常：

      • 系统向顾客提示错误，记录此错误，并进入一个初始状态

      • 顾客开始一次新的消费记录。

  • 顾客需要使用优惠券：

    • 顾客进入我的优惠券界面，选择要使用的优惠券

    • 系统按照规则扣除相应金额。

      • 选择的优惠券不适用于所购商品：

      • 系统向顾客提示错误。

  • 顾客要求取消付款交易：

    • 顾客在系统中取消付款交易。

  • 系统检测到与外部税务计算系统的通信故障:

    • 系统重启此服务，并继续操作。

      • 系统检测到该服务无法重启。

      • 系统提示错误。

      • 商家手工计算和输入税金。

• 特殊需求

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

  • 90%的信用卡授权响应时间小于30s

  • 在访问远程服务失败的情况下有较强的恢复能力

• 技术和数据变元素

  • 无

• 发生频率

  • 可能会不断地发生

• 未决问题

  • 研究远程服务的恢复问题

  • 税法如何变化

casual用例

casual用例1–显示餐厅用餐情况

• 用例名称

  • 显示餐厅用餐情况

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与人员

  • 餐厅后台管理人员

• 前置条件

  • 无

• 后置条件

  • 显示出餐厅内所有餐桌的状态

• 主要成功场景

  • 餐厅管理人员在系统首页选择显示餐厅用餐情况

  • 显示出各个餐桌状态

• 扩展（或替代流程）

  • 系统崩溃：在选择时遇到系统崩溃问题，系统将提示错误信息，管理人员可以重新从第1步做起重新选择。

  • 电脑崩溃：处理流程如上

casual用例2-显示餐桌具体情况

• 用例名称

  • 显示餐桌具体情况

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与人员

  • 餐厅后台管理人员

• 前置条件

  • 管理人员选择了某个餐桌查看

• 后置条件

  • 显示出所选餐桌的状态，所有已点菜品以及菜品情况

• 主要成功场景

  • 餐厅管理人员在显示所有餐桌后选择某餐桌

  • 显示出管理人员想要查看的餐桌的状态，所有已点菜品以及菜品情况

• 扩展（或替代流程）

  • 系统崩溃：在选择时遇到系统崩溃问题，系统将提示错误信息，管理人员可以重新从第1步做起重新选择。

  • 电脑崩溃：处理流程如上

casual用例3-接收订单

• 用例名称

  • 桌面自助点餐系统

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与人员

  • 餐厅后台管理人员

• 前置条件

  • 无

• 后置条件

  • 记录桌号、菜号，并返回确认信息，更改菜品状态，将菜品列入排队列表，等待分配厨师

• 主要成功场景

  • 餐厅管理人员选择接受前台订单信息

  • 后台记录桌号、菜号，并返回确认信息，更改菜品状态为已下单阶段，将菜品列入排队列表，等待分配厨师。若前台删除菜品，则将该对应菜品从排队列表中移除，正在制作中和已上菜的菜品无法删除。

• 扩展（或替代流程）

  • 系统崩溃：在选择时遇到系统崩溃问题，系统将提示错误信息，管理人员可以重新从第1步做起重新选择。

  • 电脑崩溃：处理流程如上

casual用例4-订单分配厨师/菜品分配服务员

• 用例名称

  • 订单分配厨师

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与人员

  • 餐厅后台管理人员

• 前置条件

  • 管理人员已经接收了前台的订单信息

• 后置条件

  • 将需要做的菜品信息按需分配给厨师们

  • 将已经做好的菜品按需分配给服务员

• 主要成功场景

  • 餐厅管理人员选择对菜品或厨师有要求的菜手动安排厨师，其余的按照先来先服务进行

  • 餐厅管理人员选择对服务员有要求的菜手动安排服务员，其余的按照先来先服务进行

• 扩展（或替代流程）

  • 系统崩溃：在选择时遇到系统崩溃问题，系统将提示错误信息，管理人员可以重新从第1步做起重新选择。

  • 电脑崩溃：处理流程如上

casual用例5-响应催单

• 用例名称

  • 订单分配厨师

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与人员

  • 餐厅后台管理人员

• 前置条件

  • 管理人员已经接收了前台的催单信息

• 后置条件

  • 服务员响应催单并送菜

• 主要成功场景

  • 餐厅管理人员选择响应催单并且分配服务员进行送菜

• 扩展（或替代流程）

  • 系统崩溃：在选择时遇到系统崩溃问题，系统将提示错误信息，管理人员可以重新从第1步做起重新选择。

  • 电脑崩溃：处理流程如上

casual用例6-结账

• 用例名称

  • 结账

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与人员

  • 餐厅后台管理人员

• 前置条件

  • 管理人员已经接收了前台的订单信息

• 后置条件

  • 结账后将餐桌状态改为已结账

• 主要成功场景

  • 餐厅管理人员选择结账后，显示餐桌所有点餐信息，并打印账单，打印发票

• 扩展（或替代流程）

  • 系统崩溃：在选择时遇到系统崩溃问题，系统将提示错误信息，管理人员可以重新从第1步做起重新选择。

  • 电脑崩溃：处理流程如上

casual用例7-菜品信息管理

• 用例名称

  • 菜品信息管理

• 范围

  • 泡面佬扫码点餐系统

• 级别

  • 用户目标级别

• 主要参与人员

  • 餐厅后台管理人员

• 前置条件

  • 无

• 后置条件

  • 菜品的序号、名称、价格、种类、口味、评价、图片等已经更新

• 主要成功场景

  • 餐厅管理人员选择增加、修改、删除菜品

  • 若增加菜品，则要求输入菜品的序号、名称、价格、所属种类、口味等；若修改菜品，进行菜品的选择，并选择要修改的项；若删除菜品，则选择要删除的菜品

• 扩展（或替代流程）

  • 系统崩溃：在选择时遇到系统崩溃问题，系统将提示错误信息，管理人员可以重新从第1步做起重新选择。

  • 电脑崩溃：处理流程如上

brief用例

brief用例1–搜索菜品

1. 用户点击搜索图标索引。

2. 用户输入搜索的菜品信息关键字。

3. 餐厅后台根据该关键字，检索菜品信息，生成结果信息。

4. 餐厅系统解析结果，将匹配的菜品信息一一导入目标列表并更新。

5. 用户可重新搜索菜品。

brief用例2–用户点餐

1. 用户添加想点的菜品及对应数量进购物车。

2. 用户进行结算，确认订单，付款。

3. 餐厅管理人员记录桌号、菜品信息，生成订单信息，打印发票。

4. 订单信息导入排队列表，等待分配厨师。

5. 厨师根据菜品信息制作菜品。

6. 服务员将已制作好的菜品根据桌号送达。

7. 餐厅管理人员更改订单状态。

brief用例3–用户点评

1. 用户已经用完餐。

2. 用户根据用餐体验对餐厅服务进行评价。

3. 餐厅后台生成并保存评价信息。

4. 餐厅后台对评价信息进行分类（有图/好评/差评/关键字）

5. 餐厅后台系统将该评价信息导入进当前已有评价信息列表并更新。

6. 用户可对评价进行修改或者追评。

6.3 Domain Model（领域模型）

6.4 State Model（状态模型）

点餐：

订单有以下几种状态：

待确认、已确认、已支付、已接单、已取消、退款中、已退款、已关闭、已接单、已完成

6.5 System Sequence Diagram（功能模型）

15310022-付款

15331020-评价菜品

15331030-点餐

15331016-完成订单

15331007-搜索菜品

15331149-排队

15331147-导航

 

6.6 Supplementary Requirements（补充需求）

修订历史

版本	日期	描述	作者
初始草案	2018年6月5日	第一个草案，主要在细化阶段中进行精化	15331007_CYT

简介

本文档记录了泡面佬扫码点餐小程序所有未在用例中描述的需求。

功能性

（通常跨越多个用例的功能性）

1. 日志和错误处理

在持久性存储中记录所有的错误。

1. 可插拔规则

在几个用例（见定义）的不同场景点执行任意一组规则，以支持对系统功能的定制。

1. 安全性

任何使用都需要经过用户认证。

可用性

人性因素

顾客将需要在手机屏上完成扫码点餐的全部操作。因此：

1. 界面文本表达需简洁易懂。

2. 图片、字体要清晰，避免使用一般色盲人难以辨认的颜色。

快捷、无错的点餐处理极为重要，因为顾客希望尽快完成点餐，否则会给他们的使用体验（以及对泡面佬小程序的评价）带来负面影响。

顾客对菜品的全部判断都来自界面上的展示。因此，采用图像传递菜品信息是必要的。

可靠性

1. 可恢复性

如果在使用外部服务（支付授权、……）时出现错误，为了完成订餐交易，需要尝试采用本地方案加以解决。

1. 性能

正如“人性因素”一节中提到的，用户希望非常快速地完成点餐处理过程。外部的支付授权是瓶颈之一。我们的目标是能在10s内获得授权。

可支持性

1. 可适应性

泡面佬扫码点餐的不同客户在点餐时有不同的处理需求。因此，在场景中几个预定之处（例如，当开始新的点餐时，当增加新的菜品时），需要能够启用可插拔的业务规则。

1. 可配置性

不同客户对泡面佬小程序有不同的配置要求，如采用安卓端或IOS端等等。因此，小程序需要具备一定的可配置能力以适应上述需求。

实现约束

采用小程序语言wxml+wxss+JS开发前端，docker部署后台。我们认为小程序语言的可支持能力最高。

接口

1. 重要的硬件和接口

手机触摸屏（触摸动作视为鼠标事件）。

1. 软件接口

由于存在众多的外部协作系统（库存、账务、管理……），我们需要采用不同的接口，接入不同的系统。

应用的领域（业务）规则

ID	规则	可变性	来源
规则1	顾客折扣规则。示例： 普通顾客无折扣额 VIP用户15%折扣额	高 每个商家有不同规则	商家政策
规则2	销售折扣规则。示例： 每周一折扣额为5% 每天下午4点到6点水果茶的折扣额为25%	高 每个商家有不同规则，每天或每小时都可能改变	商家政策
规则3	产品（商品级）折扣规则。示例： 薯饼本月折扣额为10% 汉堡买二送一	高 每个商家有不同规则，每天或每小时都可能改变	商家政策

所关注领域内的信息

1. 定价

除了在应用领域规则中描述的定价规则之外，还需注意的是，菜品有原始价格和可选的常用价格之分。即使有常设低标价，也需维护原始价格。

1. 支付处理

支付授权被批准后，将由支付授权服务而不是买方来负责对卖方的支付。因此，对于每笔服务，卖方都需要将授权服务的未付金额记录于其应收账户下。通常，授权服务在每晚执行电子转账操作，将卖方当天的应收总金额转入其账户下。