细化迭代三——实现收银用例需求文档

2.1业务建模

A业务流程建模

1. 使用UML活动图分析目标系统所支持的业务流程

（1）点餐：

 

  

（2）付款：

 

 

2. 必要的说明

（1）涉众：顾客，店员，经理

（2）业务规则：

ID	规     则	可  变  性	来    源
规则1	银联卡支付需要签名	可能会一直要求顾客“签名”，但是在两年内，大多数顾客希望在数字设备上记录签名，并且在5年内，我们预期需要支持现在美国法律所支持的新的唯一数字编码“签名”	所有银联卡授权公司的政策
规则2	税务规则。销售中需要考虑税务事宜。当前详情参见政府公布的状况。	高。各级政府每年都会变更税法	法律

 

（3）使用到的单据：

        订单（店名，店铺地址，电话，序号，商品名，商品编号，商品单价，商品折扣，商品数量，金额，总计金额，开单时间，开单人员编号）

         付款票据证明（店名，店铺地址，电话，序号，商品名，商品编号，商品单价，商品折扣，商品数量，金额，总计金额，实收金额，找零，开单时间，开单人员编号）

 

B领域建模

 

2.2需求规格说明

A系统用例图

 

 B用例详述文本

用例UC1：处理开单

范围：餐饮POS机应用

级别：用户目标

主要参与者：顾客，员工

前置条件：员工必须经过确认和认证

成功保证（或后置条件）：建立新的销售单，准确输入商品信息，存储销售信息。更新账务和库存信息。准确计算税金，准确计算商品总价。生成票据。

主成功场景：

1.员工开始新的一次销售,系统自动生成一个订单号。

2.顾客点餐。

3.员工开单。

4.员工上菜，顾客用餐。

5.顾客携带账单到收银台付款。

6.员工开始新的一次服务。

7.员工确认账单，收钱。

8.系统打印消费凭证。

扩展：

*a：经理在任意时刻要求进行超控操作：

1.系统进入经理授权模式。

2.经理或收银员执行员工某一经理模式的操作。例如，变更现金结余，恢复其他登录者中断的销售交易，取消销售交易等。

3.系统回复到员工授权模式。

*b:系统在任意时刻失败：

1.员工重启系统，登录，请求恢复上次状态。

2.系统重建上次状态。

  1a.系统出错，无法生成订单号。

     1.员工重启系统，登录。

  3a.出不了单。

     1.系统提示错误。

       1a.系统提示没有纸张。

          1.员工放入新的纸张。

       1b.系统出错。

          1.员工重启系统，登录，排除错误。

          2.员工可能会开始一个新销售交易，并重新进行点餐。

       1c.未发现对应的销售交易。

          1.系统向员工提示错误。

          2.员工可能会开始一个新销售交易，并重新进行点餐。

2a.点完餐之后发现部分菜品已售罄。

   1.员工向顾客说明情况。

   2.顾客修改订单。

   3.系统修改订单信息。

3a.顾客改变订单。

   1.员工执行改变订单操作。

   2.员工开出新的订单。

8a.系统打印不了消费凭证。

 1.系统提示错误。

   1a.系统提示没有纸张。

      1.员工放入新的纸张。

   1b.系统出错。

      1.员工重启系统，登录，排除错误。

      2.员工输入订单号以提取对应的销售交易。

业务规则：

ID	规     则	可  变  性	来    源
规则1	银联卡支付需要签名	可能会一直要求顾客“签名”，但是在两年内，大多数顾客希望在数字设备上记录签名，并且在5年内，我们预期需要支持现在美国法律所支持的新的唯一数字编码“签名”	所有银联卡授权公司的政策
规则2	税务规则。销售中需要考虑税务事宜。当前详情参见政府公布的状况。	高。各级政府每年都会变更税法	法律

 

 

2.3 补充性规格说明

A功能性

1. 日志和错误处理

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

2. 可插拔规则

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

3. 安全性

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

 

B可用性

1. 服务员能够看到POS屏幕显示器的显示：

    服务员开单时手上都有一台小型下订机，因屏幕较小，要能够轻松的看到显示器上的文本。

    收银员的POS屏幕较大在1米外能够轻松的看到显示器上的文本。

    分辨率要够高，避免使用一般色盲人群难以辨认的颜色。

2. 快捷、无错的下单极为重要，因为购买者希望尽快开单上菜，否则会给他们的用餐体验（和对餐厅的评价）带来负面影响；

3. 服务员的视线通常停留在顾客，而不是计算机显示器上，因此，提示和告警应该通过声音传递而不仅仅是通过图像传递。

 

C可靠性

1. 可恢复性

    如果在使用外部服务（支付授权、账务系统等）时出现错误，为了完成订单支付交易，需要尝试才用本地方案（如存储和转发）加以解决。

2. 性能

    顾客希望非常快速的完成支付过程，因此，外部的支付授权是瓶颈之一，我们的目标是：90%的情况下，能够在1分钟之内完成授权。

3. 数据备份

    系统支持定时或实时的对数据进行备份，避免数据的破坏或者丢失，如处理下订单过程中，系统出现闪退或者奔溃情况下导致的数据丢失或者需要重新录入。

 

D可支持性

1. 可适应性

    不同类型的顾客在消费时有其特有的业务规则和处理需求。因此，在场景中的几个预定之处（如开始新的消费时，增加新的商品时），需要能够启用可插拔的业务规则。

2. 可配置性

系统具备一定的可配置能力以适应该店对其POS系统的不同的网络配置需求。

 

E实现约束

    使用的程序设计语言为java，其具备易于开发，能够提高远期的移植和可支持性能力。

 

F购买构件

税金计算器，必须支持用于不同国家的可插拔计算器。

 

G免费开源构件

    尽可能的使用免费的java 技术开源构件，如：Maven、easyui、ssh、jquery、Jeecg

 

H接口

1. 重要硬件和接口

    下订机

    显示屏（显示POS系统）

    票据打印机

    信用卡、借记卡读卡器

2. 软件接口

由于存在众多外部协作系统，如税金计算器，账务，库存等，我们需要采用不同的接口，接入不同的系统。

I所关注领域内的信息

1. 信用卡和借记卡支付处理

    当支付授权服务批准了信用卡或借记卡支付后，将由支付授权服务而不是买方来负责对卖方的支付。因此，对于每笔支付，卖方都需要将授权服务的未付金额记录于其应收账户下。通常，授权服务在每晚执行电子转账操作，将卖方当天的应收总额转入其账户下，同时对每笔交易扣除（少量的）服务费。

2. 销售税

    对税金计算采用税金计算器计算。

2.4 系统顺序图与操作契约

A系统顺序图

    开单及付款顺序图：

 

 

B操作契约

契约CO1：makeNewSale

操作：makeNewSale（） 交叉引用：用例：点餐 前置条件：无 后置条件：创建了Sale的实例saleOrder（创建实例）。           saleOrder被关联到deskService和orderItemService（形成关联）。           saleOrder的属性被初始化（修改属性）。

 

契约CO2：enterOrderItem

操作：enterOrderItem(itemID:ItemID,quantity:integer) 交叉引用：用例：点餐 前置条件：正在进行中的点餐 后置条件：创建了product的实例product（创建实例）。           Product被关联到productService（形成关联）。

 

契约CO3：endSale

操作：enterSale() 交叉引用：用例：点餐 前置条件：正在进行中的点餐 后置条件：Sale.isComplete被置为真（修改属性）。

 

契约CO4：makePayment

操作：makePayment(amount:money) 交叉引用：用例：点餐 前置条件：正在进行中的点餐 后置条件：创建了Payment的实例Json（创建实例）。          Json被关联到orderItemService（形成关联）。

4.3 数据库设计

Ø customer表

Ø desk表

Ø product表

Ø product_category表

Ø sale_order表

Ø sale_order_item表

转载于:https://my.oschina.net/u/2331280/blog/477479