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

2024-01-18 14:20

本文主要是介绍细化迭代三——实现收银用例需求文档,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

2.1业务建模

A业务流程建模

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

(1)点餐:

094643_44cj_2331280.jpg 

  

(2)付款:

094717_rbcS_2331280.jpg 

 

2. 必要的说明

(1)涉众:顾客,店员,经理

(2)业务规则:

    ID

   规     则

   可  变  性

    来    源

 

 

 

  规则1

 

 

 

 银联卡支付需要签名

   可能会一直要求顾客“签名”,但是在两年内,大多数顾客希望在数字设备上记录签名,并且在5年内,我们预期需要支持现在美国法律所支持的新的唯一数字编码“签名”

 

 

  

   所有银联卡授权公司的政策

  

  规则2

    税务规则。销售中需要考虑税务事宜。当前详情参见政府公布的状况。

   高。各级政府每年都会变更税法 

   

      法律

 

(3)使用到的单据:

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

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

 

B领域建模

094747_jqSq_2331280.jpg 

2.2需求规格说明

A系统用例图

094812_QKqA_2331280.jpg 

 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 技术开源构件,如:MaveneasyuisshjqueryJeecg

 

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 数据库设计

095014_tmWJ_2331280.png

Ø customer

095014_CGAL_2331280.png

Ø desk

095014_RzdO_2331280.png

Ø product

095014_9XrH_2331280.png

Ø product_category

095014_lcdw_2331280.png

Ø sale_order

095015_nIJv_2331280.png

Ø sale_order_item

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

这篇关于细化迭代三——实现收银用例需求文档的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/619280

相关文章

使用Python和OpenCV库实现实时颜色识别系统

《使用Python和OpenCV库实现实时颜色识别系统》:本文主要介绍使用Python和OpenCV库实现的实时颜色识别系统,这个系统能够通过摄像头捕捉视频流,并在视频中指定区域内识别主要颜色(红... 目录一、引言二、系统概述三、代码解析1. 导入库2. 颜色识别函数3. 主程序循环四、HSV色彩空间详解

PostgreSQL中MVCC 机制的实现

《PostgreSQL中MVCC机制的实现》本文主要介绍了PostgreSQL中MVCC机制的实现,通过多版本数据存储、快照隔离和事务ID管理实现高并发读写,具有一定的参考价值,感兴趣的可以了解一下... 目录一 MVCC 基本原理python1.1 MVCC 核心概念1.2 与传统锁机制对比二 Postg

SpringBoot整合Flowable实现工作流的详细流程

《SpringBoot整合Flowable实现工作流的详细流程》Flowable是一个使用Java编写的轻量级业务流程引擎,Flowable流程引擎可用于部署BPMN2.0流程定义,创建这些流程定义的... 目录1、流程引擎介绍2、创建项目3、画流程图4、开发接口4.1 Java 类梳理4.2 查看流程图4

C++中零拷贝的多种实现方式

《C++中零拷贝的多种实现方式》本文主要介绍了C++中零拷贝的实现示例,旨在在减少数据在内存中的不必要复制,从而提高程序性能、降低内存使用并减少CPU消耗,零拷贝技术通过多种方式实现,下面就来了解一下... 目录一、C++中零拷贝技术的核心概念二、std::string_view 简介三、std::stri

C++高效内存池实现减少动态分配开销的解决方案

《C++高效内存池实现减少动态分配开销的解决方案》C++动态内存分配存在系统调用开销、碎片化和锁竞争等性能问题,内存池通过预分配、分块管理和缓存复用解决这些问题,下面就来了解一下... 目录一、C++内存分配的性能挑战二、内存池技术的核心原理三、主流内存池实现:TCMalloc与Jemalloc1. TCM

OpenCV实现实时颜色检测的示例

《OpenCV实现实时颜色检测的示例》本文主要介绍了OpenCV实现实时颜色检测的示例,通过HSV色彩空间转换和色调范围判断实现红黄绿蓝颜色检测,包含视频捕捉、区域标记、颜色分析等功能,具有一定的参考... 目录一、引言二、系统概述三、代码解析1. 导入库2. 颜色识别函数3. 主程序循环四、HSV色彩空间

Python实现精准提取 PDF中的文本,表格与图片

《Python实现精准提取PDF中的文本,表格与图片》在实际的系统开发中,处理PDF文件不仅限于读取整页文本,还有提取文档中的表格数据,图片或特定区域的内容,下面我们来看看如何使用Python实... 目录安装 python 库提取 PDF 文本内容:获取整页文本与指定区域内容获取页面上的所有文本内容获取

基于Python实现一个Windows Tree命令工具

《基于Python实现一个WindowsTree命令工具》今天想要在Windows平台的CMD命令终端窗口中使用像Linux下的tree命令,打印一下目录结构层级树,然而还真有tree命令,但是发现... 目录引言实现代码使用说明可用选项示例用法功能特点添加到环境变量方法一:创建批处理文件并添加到PATH1

Java使用HttpClient实现图片下载与本地保存功能

《Java使用HttpClient实现图片下载与本地保存功能》在当今数字化时代,网络资源的获取与处理已成为软件开发中的常见需求,其中,图片作为网络上最常见的资源之一,其下载与保存功能在许多应用场景中都... 目录引言一、Apache HttpClient简介二、技术栈与环境准备三、实现图片下载与保存功能1.

canal实现mysql数据同步的详细过程

《canal实现mysql数据同步的详细过程》:本文主要介绍canal实现mysql数据同步的详细过程,本文通过实例图文相结合给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的... 目录1、canal下载2、mysql同步用户创建和授权3、canal admin安装和启动4、canal