细化迭代四——退货

2.1 业务建模

A.业务流程建模

销售收银活动图

细化迭代四——退货_第1张图片

退货活动图

细化迭代四——退货_第2张图片

涉众:顾客,收银员,pos机系统,授权服务

业务规则:

ID

规则

可变性

来源

规则1

购买者折扣规则:

会员价:10%折扣额

员工价:15%折扣额

一般顾客:无折扣

每个餐饮店有不同的规则

餐饮业规则

规则2

会员卡积分规则:

积分100以上:享受会员价后再打九折的优惠

积分200以上:享受会员价后再打八折的优惠

更高的积分同200及以上一样享受同等优惠,不设更高打折优惠

每个餐饮店有不同的规则

餐饮业规则

B.领域模型

细化迭代四——退货_第3张图片

2.2 需求规格说明

A 用例模型

细化迭代四——退货_第4张图片

 

B.用例模型详述文本

用例UC1:处理销售

范围FD POS应用

主要参与者:收银员

涉众极其关注点

收银员:希望能够准确、快速地输入顾客所点餐品编号,而且没有输入错误以及其他意外。

顾客  希望以最小代价完成点餐活动并得到快速服务。希望便捷、清晰看到所点餐品的项目和价格。

餐饮店:希望准确地记录交易,满足顾客要求。希望有一定的容错性,即使在某些服务器构件不可用时,也能完成销售。希望能够自动、快速地更新账务信息和库存信息。

经理:希望能够快速执行超控操作,并易于更正收银员的不当操作

前置条件:收银员必须经过登录和验证。

成功保证:存储销售信息。系统自动记录销售时间。系统显示总金额。

主成功场景

1.       顾客到前台点餐并通过POS机付款。

2.       收银员开始一次新的销售交易。

3.       收银员输入顾客所点餐品编号。

4.       系统逐条记录出售的餐品,并显示该餐品的描述、类别、价格以及数量。

收银员重复3~4步,直至输入结束。

5.       系统显示总金额.

6.       收银员告知顾客总金额,并等待付款.

扩展

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

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

2.经理或收银员执行某一经理模式的操作。例如取消销售交易。

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

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

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

2.系统重建上次状态

 2a.系统在恢复过程中检测到异常

1.系统向收银员提示错误,记录此错误,并进入初始状态。

2.收银员重新开始一次新的销售交易。

1a.顾客或经理需要恢复一个中断的销售交易。

1.收银员执行恢复操作,并且输入订单号以获得相应的销售交易

2.系统显示被恢复的销售交易状态以及合计。

2a.未发现相应的销售交易。

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

2.收银员重新开始一个新的销售交易,并重新输入所有商品。

3.收银员继续该销售交易(可能是输入更多的餐品或者删除餐品)

2-6a. 顾客告诉收银员其手机号码,要求进行会员消费

1.收银员输入该顾客的手机号码,进行核实

2.系统显示会员打折规则并记录(在计算总金额时使用)

3a.餐品IDpos系统未发现(无效)

1.系统提示错误并拒绝收银员输入餐品ID,收银员尝试使用其他方式。

        1a.系统内没有该餐品ID,但是菜单上有该餐品的价格

1.收银员请求经理执行超控操作。

2.经理执行相应的超控操作。

3.收银员手动输入价格。

3b.当一种餐品的数量多于一时,收银员可直接添加该餐品的数量而不是记录每个餐品的唯一标识。

3-6a.顾客要求收银员从所点餐品中去掉某一项

1.收银员输入餐品ID并将其删除。

2.系统删除该项目后并显示更新后的累计额

3-6b.顾客由于特殊原因要求收银员取消销售交易。

1.收银员在系统中取消本次销售交易。

3-6c.顾客临时有事(例如等待朋友一起点餐),要求延迟销售交易。

1.系统记录该销售交易信息,以便随时可以恢复操作。

5a.系统出现故障,无法显示总金额。

1.收银员进行重启系统服务,并继续操作。

1a.重启服务失败

1.收银员手工计算餐品总金额或使用其他方式计算总金额。

6a.顾客要求使用现金(信用卡)支付,发现现金(信用卡余额)不足无法付款。

1.顾客要求收银员取消本次销售交易,收银员取消本次销售交易。

2.顾客要求使用其他方式付款。

6b.顾客要求添加一项餐品项目。

    1.收银员返回到第三步,重新输入顾客所添加的餐品编号ID

特殊需求

使用大尺寸平面显示器触摸屏UI。文本信息可见距离为1米。

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

收银员有权限可返回到上一步骤重新进行销售交易

技术与数据变元素

*a.经理进行操控操作时需要进行登录验证。

3a.餐品ID可用键盘输入。

发生频率

可能会不断发生。

未决问题:

当餐饮店有特价商品或促销活动时,应如何重新定制系统餐品价格规则?

 

用例UC2:收银

范围FD POS应用

主要参与者:收银员

前置条件:收银员必须经过登录和认证身份

后置条件:存储销售交易信息,确定一个订单号对应一笔销售交易。准确计算销售总价和折扣。更新账务和库存信息。生成票据

主成功场景

1.       顾客点餐完毕,收银员根据该销售订单进行结账操作

2.       系统显示应付总金额,收银员告知顾客并等待顾客付款

3.       顾客付款,系统处理支付

4.       系统记录完整的销售信息,并将销售和支付信息发送到外部的账务系统和库存系统。

5.       系统打印票据

6.       顾客携带票据等待领取餐品就餐

扩展:

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

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

2.经理或收银员执行某一经理模式的操作。例如取消处理支付。

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

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

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

2.系统重建上次状态

2a.系统在恢复过程中检测到异常

1.系统向收银员提示错误,记录此错误,并进入初始状态。

2.收银员开始一次新的销售交易。

2-3a.顾客发现现金不足,无法付款:

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

2.顾客要求使用其他方式支付

       2a.顾客使用信用卡支付:

1.顾客输入信用卡密码。

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

3.收银员确认。

4.系统向外部的支付授权服务系统发送请求

5.支付授权服务系统批准该支付,系统收到回答并提示收银员

3b.系统崩溃,

1. 无法开始处理支付消息,收银员重启系统服务,继续操作

  1a.重启服务失败,,收银员向经理请求超控操作,重新开始一次销售交易

2.系统处理支付事件时出现故障,无法计算(显示)找零金额

2a.收银员重启系统服务,继续操作

    1.重启失败,收银员手工计算找零金额

3c.pos机无法自动弹出现金抽屉

  1.收银员手工开启现金抽屉,若无法手工开启,则请求经理执行超控操作

3d.现金抽屉里零钱不足,无法给顾客找零

1.收银员询问顾客是否有零钱支付或者是否使用其他方式付款

2.收银员从其他现金抽屉里取出零钱,给顾客找零

  2a.所有现金抽屉均没有足够的零钱,收银员通知经理,经理及时补充零钱

3e.顾客要求使用会员卡消费或声称他们符合某种优惠条件(例如,会员卡账户积分达到一定程度可以享受打折优惠)

1.       收银员向系统提示打折请求

2.       收银员输入顾客手机号码或会员卡ID确认身份

3.       系统按照打折规则显示折扣总计(若为兑现积分,则在打折的同时扣除结余积分)

5a.打印票据时出现问题

         1.      系统检测出错误,给出提示

        2.       收银员更换纸张

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

 

用例UC3退货

范例: FD POS应用

主要参与者:收银员

涉众及其关注点:

收银员:希望能准确、快速的完成退款,并且不会发生退款错误的情况。

顾客:希望能够退货并取回相应退款金额。

餐饮店:希望能够准确地记录交易,希望确保记录了退货情况。

经理:希望能够快速执行超控操作,并易于更正收银员的不当操作。

前置条件:收银员必须通过确认和认证,购物小票经过确认。

后置条件:存储退货信息。准确计算退货总额。更新财务和库存信息。更改销售量。生成相应退票票据

主成功场景:

1.顾客携带票据到收银台退货,提出退货要求。

2.收银员接受顾客提供的点餐票据,进行核对信息。

4.核查后录入销售单号,并选择退货商品。

5.系统显示退货总额,收银员提交退货申请。

6.系统接受退货申请,修改库存和登记订单。

7.收银员根据退货单向顾客返还相应的现金,并打印退货单。

 

扩展:

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

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

   2.经理或收银员执行某一经理模式的操作。

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

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

为了支持恢复处理,要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。

3a.不允许退餐:

1.票据里的餐品与顾客实际要求退货的餐品不符,拒绝顾客退货要求。

4a.退货信息录入错误,经理向系统取消退货操作,并重新进行退货操作:

6a.打印退货单。

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

2.收银员更换纸张。

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

 

2.3 UC2补充性规格说

(主要是修改迭代二中的补充性规格说明)

补充性规格说明在用例中未提及的其他类型的需求,如可用性、可靠性、接口(如支持网银支付接口)等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。

可用性:

1米外轻松可看到文本

可靠性;

可允许多人同时访问该系统;

需要体现出系统的稳定性以及反应速度。

支持定时进行数据备份(防止系统崩溃时数据丢失);

功能性:

日志与错误处理(在持久性存储中记录所有错误)

安全性(使用系统必须经过用户认证)

权限管理(不同用户有不同的使用管理权限)

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

可对系统任意时刻数据进行查询;

可导入导出系统数据以及打印报表等

 可支持性

 可适应性

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

可配置性(系统可适应快餐店对其POS系统的不同的网络配置需求)

实现约束:

使用java程序设计语言

接口:

1.重要硬件和接口

触摸屏

票据打印机

信用卡读卡器

2.软件接口

需要采用不同接口,接入不同系统(账务、库存等)

所关注的领域内信息

1.   定价

食物餐品的价格根据市场价格定价。

2.   编码

可参考都城快餐店的编码来进行编码。

 

你可能感兴趣的:(细化迭代四——退货)