细化迭代4：实现退货用例

需求分析

2.1业务建模

A. 业务流程建模。

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

使用文字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。

 

生成退货信息中有生成退货交易号，记录对应订单号、退货时间、产品及数量、销售价格、退货原因、经手人等信息需要生成。

更新原订单时需要更改订单总额，修改订单中产品项状态为已退货。

 

 

 

 

 

B. 领域建模。

使用UML类图构建领域模型。

2.2需求规格说明

A. 系统用例图。绘制整个系统的UML用例图。

B. 用例详述文本。

对所有业务活动用例采用详述风格（包括前置条件、后置条件、主事件流，扩展、业务规则等）进行描述。

 

范围：快餐店 POS应用

级别：用户目标

主要参与者：经理

涉众及其关注点：

--顾客：希望以最快速度依靠凭证迅速进行退货，得到补偿费用

--经理：希望退货操作在POS机运行是方便的，而且具有安全性，能够准确地修改退货信息。

--公司：希望准确地记录交易，满足顾客需求。希望有一定的容错性，能够完成退货。

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

成功保证：更改销售信息。生成退货信息。更新账务。生成票据。

主成功场景：

1. 顾客到前台出示小票要求退货。

2. 经理通过POS机顺利打开退货界面。

3. 经理扫描顾客的单据，并将信息记录入系统。

4. 系统逐条记录出售的商品，并显示该商品的描述，价格和累计额。价格通过一组价格规则来计算。

5. 系统显示总额。

6. 经理询问顾客是否需要全退货，亦或是只退货某件产品。

7. 顾客确认退货产品

8. 经理使用系统记录被退货的产品

9. 系统打印退货票据。

10. 经理打开收银机找出退货费用给顾客

11. 顾客携带现金和票据离开。

扩展

*a、系统在任意时刻失败:

1、经理重启系统。

2、经理重新进入退货界面。

3、检查系统是否运作正常。

4、继续退货。

3a、票据扫描出错：

1、经理检查扫描机器是否正常。

   1a、机器正常：

   1、经理检查票据是否正规。

6a、顾客要求退货全部产品：

1、经理选择全退货选项。

2、生成退货单据并退货。

10a、找取现金不够：

1、经理调用其他收银机。

2、在系统记录调用现金。

3、将现金转移到本收银机上来。

4、找取现金。

特殊需求：

由于某些原因，我们希望在访问远程服务（如库存系统）失败的情况下具有比较强的恢复功能。

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

使用大尺寸显示屏方便观看。

在访问系统失败时可以恢复系统。

 

 

2.3补充性规格说明

补充性规格说明：

 

修订历史：

版本	日期	描述	作者
初始版本	2015年4月9日	第一个方案，主要在细化阶段中进行精化	陈楚平
修改方案1	2015年5月1日	第二个方案，主要修改了领域规则	梁国栋
修改方案2	2015年5月19日	第二个方案，修改了可靠性和所关注领域内的信息	梁国栋

简介：

 

 记录未在文本用例描述的需求

 

功能性：

 

1. 日志和错误处理

 

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

 

2. 可插入规则

 

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

 

3. 安全性

 

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

 

可用性：

 

1．人性因素

 

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

 

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

 

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

 

快捷，无错的销售交易处理极为重要，因为购买者希望快速离开，否则会给他们购买体验带来付负面影响。

 

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

2.  允许退货

在顾客需要退货的时候：

 

能够调出退货的菜单。

 

退货的界面必须与系统和单据准确地相关联，不允许出错。

 

可靠性：

 

1．性能

 

购买者希望非常快速地完成销售处理过程。收银员希望能快速完成收款处理业务。这对系统的性能有着一定要求，所以我们的要求做到最快的时间内反应收银员的操作。

 

可支持性：

 

1．可适应性

 

系统的不同客户处理销售时有其特有的业务规则和处理需求。因此，在场景中的几个预定之处，需要能够启用可插拨的业务规则。

 

2．可配置性

 

不同的客户对其POS系统有不同的网络配置需求。例如。采用胖客户或瘦客户端。两层或多层物理结构等等。除此之外，他们还要求具备修改配置的能力。以便适应其变更业务和性能的需求。因此，系统应该具备一定的可配置能力以适应这些需求。对此需要进一步分析，以发现哪些地方需要灵活性和灵活性的程度。以及实现这种灵活性所需要的工作。

 

实现约束：

 

   坚持采用JAVA技术的解决方案， JAVA技术除了易于开发外，还能够提高远期的移植和可支持性能力，而且开发员对Java技术相对熟悉，可以减少代码错误。

 

购买构件：

 

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

 

接口：

 

1. 重要硬件和接口

 

-触摸屏

 

-票据打印机

 

2. 软件接口

 

由于存在众多外部协作系统，我们需要采用不同的接口，接入不同的系统。

 

 

应用的领域规则：

ID	规则	可变性	来源
规则1	购买者折扣规则。 示例： 顾客：20%折扣额	高 每个零售商有不同规则	快餐店政策
规则2	销售降价规则 示例： 每周一下午2点到6点超值套餐降至15元	高 每个零售商有不同规则	快餐店政策
规则3	产品折扣规则 示例： 鸡腿堡每周二折扣额为10%	高 每个零售商有不同规则	快餐店政策

所关注领域内的信息

1.销售税

这个的计算可能会十分复杂，并且会根据政府政策有所变更。

2法律相关

对退货的要求时间必须根据法律作出严格的规定，超出时间的系统不允许退货。

4.3 数据库设计

E-R模型：

数据库表：

转载于:https://my.oschina.net/u/2331679/blog/423667