迭代三——文档

(1)  完成UC1,UC2的2.1 业务建模

业务建模（开单用例和支付用例）

A.      业务流程建模。

 

B.      领域建模。

 

(2)  2.2 UC2用例模型

用例UC2：处理支付

范围：RunningPOS系统

主要参与者：收银员

涉众及其关注点：

收银员：希望没有支付错误，因为如 果少收货款，将从其薪水中扣除。

经理：希望准确地记录交易，满足用户要求。希望能够自动，快速地更新账务和库存信息。

公司：希望准确地记录交易，满足客户要求。希望能够自动、快速地更新账务和库存信息。

前置条件：收银员必须经过确认和认证。 

成功保证（或后置条件）：准确计算金额。更新账务和库存信息。生成票据。记录支付信息。

主成功场景（或基本流程）： 

1.收银员开始结算，系统显示应付金额。

2.客户付款（本系统暂时不考虑其他付款方式） 

3.收银员输入所收金额，系统响应并显示找零金额，弹出现金抽屉。（如果有的话）

4.收银员找零后确认支付，系统自动生成支付表单（记录收款人、支付时间、支付方式等）。

5.系统打印票据。

6.收银员将零钱和票据交给客户。

 

扩展（或替代流程）： 

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

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

2. 经理或收银员执行某一经理模式的操作。例如，变更现金结余，恢复其他登录者中断的销售交易，取消销售交易等。 

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

1-5b、系统在任意时刻失败：         

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

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

2. 系统重建上次状态。

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

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

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

             1. 系统提示错误，并建议经理超控。 

               2. 收银员请求经理超控，完成超控后，重做该操作。 

2a、顾客现金付款，但携带的现金不足：     

1.顾客要求使用其他支付方式。 （暂时不考虑） 

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

3a、现金抽屉零钱不足：

1.       收银员请求经理补充现金抽屉零钱

2.       系统响应更新现金抽屉零钱信息

3.       收银员继续找零

5a、打印票据。    

1、如果系统检测到错误，给出提示    

2、收银员更换纸张    

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

 

业务规则：

1.       一张支付表对应一张销售单，支付单号

2.       每个支付表单用表单编号唯一标识。表单编号由系统按时间顺序生成，后生成的表单具有更大的订单号。

3.       收银员确认支付前，允许客户取消订单。

4.       一张支付表对应一个收款人。而一个收款人可对应多张支付表。

 

(3) 2.3 UC2补充性规格说明

功能性

1. 日志和错误处理

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

2．安全性

任何使用都需要经过用户认证

3．报表

经理可制作每月销售报表 (数字或图形报表)

4．  可插拔规则 

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

 

可用性

人性因素

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

应该在一米外轻松看到文本。

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

可理解性 

本系统提供的各种知识菜单以及文字说明要求通俗易懂，易于用户理解。 

 

可靠性 

1．稳定性

在一般条件下，系统稳定，不易出现故障  

2.可恢复性

出现错误时，有合理的应对机制。

3.可维护性

要求本软系统能够拥有良好的可维护性，一满足不断增长的用户需求以及后期BUG的修复工作。

4.性能

迅速响应。