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

需求分析

2.1业务建模

A. 业务流程建模。

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

细化迭代4:实现退货用例_第1张图片

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

 

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

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

 

 

 

 

 

B. 领域建模。

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

细化迭代4:实现退货用例_第2张图片

2.2需求规格说明

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

细化迭代4:实现退货用例_第3张图片

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模型:

细化迭代4:实现退货用例_第4张图片

数据库表:

细化迭代4:实现退货用例_第5张图片


你可能感兴趣的:(细化迭代4:实现退货用例)