细化迭代3:UC2收银用例

2.1 业务建模

   A. 业务流程建模

    (1)UML活动图细化迭代3:UC2收银用例_第1张图片

    (2)文字说明

    ① 付款前涉众:顾客、收银员、POS机系统

      业务规则:商品信息输入完毕之后,POS机系统根据顾客是否为会员计算总金额,会员享有10%的折扣,非会员没有折扣。

     ②付款时涉众:顾客、收银员、POS机系统、第三方认证系统

       在付款时,顾客可以选择现金支付或者银行卡支付。选择银行卡支付的顾客需要进行密码认证才能获得相应的服务。

                     

  B. 领域模型

细化迭代3:UC2收银用例_第2张图片

2.2 需求规格说明

    A. 系统用例图

细化迭代3:UC2收银用例_第3张图片

   B. UC2用例详述文本

       用例UC2:实现收银

       范围:Booshop POS机系统

       级别:用户目标

       主要参与者:收银员

       涉众及其关注点

       -收银员:希望准确、快速的输入,而且没有支付错误。

       -顾客:希望清晰、便捷地看到所输入商品的商品项目和价格。希望得到购买凭证,以便退货。

       前置条件:收银员必须通过确认和验证。

  成功保证:存储销售记录。更新账务和库存信息。生成票据。记录支付授权的批准。

  主成功场景(或基本流程)

  1. 收银员告知顾客显示器上显示的应付金额,并请顾客付款。

  2. 顾客付款,系统处理支付。

  3. 系统记录完整的销售信息,并更新库存系统。

  4. 系统打印票据。

  5. 顾客携带商品和票据离开(如果有)。

  拓展(或替代流程)

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

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

     2. 经理或收银员执行某一经理模式的操作。如:变更现金结余、取消销售交易等。

     3. 系统恢复到收银员模式。

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

     1. 收银员重启系统,登录,请求恢复上次状态。

     2. 系统重建上次状态。

     1a. 顾客选择现金付款,但所携现金不足:

         1. 顾客选择使用其他支付方式。

             1a. 顾客要求取消此次销售交易,收银员在系统上取消该销售交易。

     2a. 现金支付:

          1. 收银员输入收取的现金额。

          2. 系统显示找零金额,并弹出现金抽屉。

          3. 收银员放入收取的现金,并给客户找零。

          4. 系统记录该现金支付。

     2b. 银行卡支付:

          1. 顾客输入银行卡账户信息。

          2. 系统显示其支付信息以备验证。

          3. 收银员确认。

              3a. 收银员取消付款步骤。

                    1. 系统回复到“商品输入”状态。

          4. 系统向外部支付授权服务系统发送支付授权请求,并请求批准该支付。

              4a. 系统检测到与外部系统协作时的故障:

                    1. 系统向收银员提示错误。

                    2. 收银员请求顾客更换支付方式。

         5. 系统收到批准支付的应答并提示收银员,同时弹出现金抽屉(以便放入签名后的银行卡支付票据)。

             5a. 系统收到拒绝支付的应答:

                   1. 系统向收银员提示支付被拒绝。

                   2. 收银员请求顾客更换支付方式。

             5b. 应答超时:

                   1. 系统提示收银员应答超时。

                     2. 收银员重试,或者请求顾客更换支付方式。  

           6. 系统记录银行卡支付信息,其中包括支付批准。

           7. 系统显示银行卡支付的签名输入机制。

           8. 收银员请求顾客签署银行卡支付。顾客输入签名。

           9. 如果在纸质票据上签名,则收银员将该票据放入现金抽屉并关闭抽屉。

     4a. 打印票据:

           1. 如果系统能够检测到错误,给出提示。

           2. 收银员更新纸张。

           3. 收银员请求打印其他票据。


2.3 UC2补充性规格说明

简介

本文档记录了POS机销售系统所有未在用例中描述的需求。

功能性

     1.  日志和错误处理

在持久性存储中记录所有错误,能够出错记录进行统计。

     2.  可插拔规则

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

     3.  安全性

任何使用都需要经过用户认证,且对异常登陆情况进行记录和提示。

     4.  报表的可选择性

经理可以根据需要在系统中选择查看周报表、月度报表以及年度报表;报表包括直观的图形报表和传统报表。

可用性

人性因素

顾客将能够看到POS大屏幕显示器的显示。因此:

  • 应该在1米外能轻松看到文本。

  • 避免使用一般色盲人群难以辨认的颜色。

  • 对商品单价和数量显示进行突出处理,如加粗、加大字体、字体颜色差异。

便捷无误的销售交易处理极为重要,因为顾客希望能够快速离开,否则会降低顾客对购买体验的满意度。

收银员的视线通常停留在顾客或商品,而非计算机显示器上,因此,提示和警告应该通过声音传递而不仅仅是通过图像传递。

可靠性

      1.      可恢复性

如果在使用外部服务时出现错误,为了完成销售开单交易,需要尝试采用本地方案加以处理。

可支持性

      1.      可适应性

POS机销售系统的不同类别客户在处理销售时有其特有的业务规则和处理需求。因此,在场景中的几个预订之处(如:当开始新的销售交易时,当增加新的商品时),需要能够启用可插拔的业务规则。

      2.      可配置性

不同的客户对其POS系统有不同的网络配置需求。例如,采用胖客户端或瘦客户端,两层或多层物理结构等等。客户要求具备修改配置的能力,以便适应期变更业务的性能的需求。因此,系统应当具备较为灵活的可配置能力。

      3.      可移植性

不同客户使用的软硬件有所差异,因此POS机销售系统应当具备良好的兼容性和可移植性,以满足不同运行环境的需求。

实现约束

    架构师和程序员能力有限,要完成一个能满足基本业务需求的POS机销售系统仍需要更多的努力以及同学老师的指点和帮助。

免费开源构件

一般而言,在系统构建过程中,建议尽可能使用免费的Java技术开源构件。

接口

  •      重要硬件和接口

  •   触摸屏

  •   条形码激光扫描仪

  •   票据打印机

  •   信用卡/借记卡读卡器

  •   签名读取装置

应用领域(业务)规则

ID

规则

可变性

来源

规则1

收银员交接班规则。交接双方必须准确清点交接时钱箱零钞留款,并正确填写交接班记录。

不可变

 

公司规定

规则2

购买者折扣规则。会员可享受10%折扣,普通顾客无折扣。

每个零售商有不同规则

零售商政策

规则3

销售开单规则。每次开单中至少要有1件商品,否则不允许开单。

不可变

系统规定


你可能感兴趣的:(细化迭代3:UC2收银用例)