细化迭代二——3.需求分析[收银]

2 需求分析

2.1业务建模

业务建模(Business Modeling)对领域内企业管理和业务对象进行建模。包括业务流程建模和领域建模。业务流程建模描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向。领域建模是从现实的问题域中找到最有代表性的概念对象，抽象成分析类。

A. 业务流程建模。

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

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

涉众：客户、店员

业务规则：

使用到的单据：

收款票据，内容包括：店名，店铺地址，开单时间，店员号，商品名，商品单价，商品折扣，商品规格，商品数量，应收金额，实收金额，找零金额等

  B. 领域建模。

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

2.2需求规格说明

需求规格说明书(Software Requirements Specification)描述了系统的功能需求。构建系统用例模型描述功能需求。

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

B. 用例详述文本。

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

用例UC1：开单

范围：POS应用

级别：用户目标

主要参与者：收银员

涉众及其关注点：

-收银员：希望能够精准、快速的输入货品信息。希望能够快速的选择折扣权限。

-顾客：希望得到快速的服务。希望便捷、清晰地看到所输入的商品项目和价格。

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

成功保证：建立新的销售单，准确输入商品信息，准确计算税金，准确计算商品总价。

主成功场景：

1、顾客携带所购商品到收银台通过POS机付款。

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

3、收银员输入商品条码。

4、系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。

收银员重复3~4步，直到输入结束。

5、收银员选择客户可享受的折扣。

6、系统显示总价。

扩展：

*a.店长在任意时刻要求进行超控操作：

1. 1.   系统进入店长授权模式

2. 2.   店长执行某一店长模式的操作。如，回复其他登录者中断的销售交易，取消销售交易等。

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

 

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

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

2. 2.   系统重建上次状态

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

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

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

1a.客户或店长需要恢复一个中断的销售交易。

1. 1.   收银员执行恢复操作，并且输入ID以提取对应的销售记录。

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

2a.未发现对应的销售记录。

1、系统向收银员提示错误

2、收银员可能会开始一个新销售交易，并重新输入所有商品。

1. 3.   收银员继续该次销售交易。

3a.无效商品ID：

1、系统提示错误并拒绝输入该ID。

2、收银员响应该错误。

2a.商品ID可读（例如通用产品代码）：

1. 1.  收银员手工输入商品ID。

2. 2.  系统显示商品项目的描述和价格。

2a.无效商品ID：系统提示错误。收银员尝试其他方法。

2b.系统内不存在该商品ID，但是该商品附有价签：

1、收银员请求店长执行超控操作。

2、店长执行相应的超控操作。

3、收银员选择手工输入价格，输入价签上的价格，并且请求对该价目进行标准计税。

2c.收银员通过执行寻找产品帮助以获取正确的商品ID及其价格。

2d.收银员可向其他员工询问商品ID或价格，然后手工输入ID或价格。

3b.当有多个商品项目属于同一类别的时候（如2件相同的上衣），不必记录每个商品项目的唯一标识：

1、收银员可以输入类别的标识和商品的数量。

3-6a.顾客要求收银员从所购商品中去掉一项：

1、收银员输入商品ID并将其删除。

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

3-6b.顾客要求收银员取消销售交易

1、收银员在系统中取消销售交易。

3-6c.收银员延迟销售交易

1、系统记录销售交易信息，使其能够在任何POS登录中恢复操作。

2、系统显示用来恢复销售交易的“延迟票据”，其中包含商品项目和销售交易ID。

5a.系统检测到与外部税务计算系统服务的通信障碍：

1、系统在POS机节点上重启此服务，并继续操作。

1a.系统检测到该服务无法重启。。

1、系统提示错误。

2、收银员手工计算和输入税金，或者取消该销售交易。

5b.顾客符合打折条件：

1、顾客是会员：

1、输入顾客会员卡号。

2、系统按照打折规则显示折扣总计。

2、顾客符合当季打折要求。

1. 1.   收银员选择折扣种类。

2. 2.   系统按照打折规则显示折扣总计。

特殊需求：

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

• 在访问远程服务失败的情况下具有比较强的恢复功能。

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

技术与数据变元表：

*a.店长超控需要刷卡（由读卡器读取超控卡）或在键盘上输入授权码。

3a.商品ID可以用条码扫描器或键盘输入。

3b.商品ID可以使用UPC、EAN、JAN或SKU等任何一种编码方式。

5a.顾客的会员号可用刷卡读取或在键盘上输入。

发生频率：可能会不断地发生。

 

2.3 补充性规格说明

   补充性规格说明补货并确定其他类型的需求，如可靠性（如10000人并发访问）、可用性（如1米外轻松看到文本）、接口（如支持钱箱、支持网银支付接口）等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。

        简要描述本项目最终系统数据查询与报表，系统权限管理的功能需求。也可以描述项目组计划实现的其他需求。

功能性

1、日志和错误处理

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

2、可插拔规则

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

3、安全性

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

可用性

1、店员能够看到POS屏幕显示器的显示：

在1米外能够轻松的看到显示器上的文本。

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

2、快捷、准确的销售交易处理及其重要，因为购买者希望快速结束支付过程，否则会给他们的购买体验带来负面影响。

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

可靠性

1、可恢复性

如果在使用外部服务（支付授权、账务系统等）时出现错误，为了完成销售交易，需要尝试才用本地方案（如存储和转发）加以解决。

2、性能

购买者希望非常快速的完成销售处理过程，因此，外部的支付授权是瓶颈之一，我们的目标是：90%的情况下，能够在1分钟之内完成授权。

3、数据备份

系统支持定时或实时的对数据进行备份，避免数据的破坏或者丢失，如处理销售交易过程中，系统出现闪退或者奔溃情况下导致的数据丢失或者需要重新录入。

可支持性

1、可适应性

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

2、可配置性

系统具备一定的可配置能力以适应该店对其POS系统的不同的网络配置需求。

实现约束

使用的程序设计语言为java，其具备易于开发，能够提高远期的移植和可支持性能力。

购买构件

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

免费开源构件

尽可能的使用免费的java 技术开源构件，如：

Maven

easyui

ssh

jquery

jeecg

接口

1、重要硬件和接口

显示屏（显示POS系统）。

条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为键盘输入）。

票据打印机

信用卡、借记卡读卡器

2、软件接口

由于存在众多外部协作系统，如税金计算器，账务，库存等，我们需要采用不同的接口，接入不同的系统。

所关注领域内的信息

1、信用卡和借记卡支付处理

当支付授权服务批准了信用卡或借记卡支付后，将由支付授权服务而不是买方来负责对卖方的支付。因此，对于每笔支付，卖方都需要将授权服务的未付金额记录于其应收账户下。通常，授权服务在每晚执行电子转账操作，将卖方当天的应收总额转入其账户下，同时对每笔交易扣除（少量的）服务费。

2、销售税

对税金计算采用税金计算器计算。

3、商品标识：UPC、EAN、SKU、条形码和条形码读取装置

UPC、EAN、SKU是常用的三种商品销售标识系统

 

用例UC2：收银

范例：POS应用

级别：用户目标

主要参与者：收银员

涉众及其关注点：

-收银员：希望能准确快速的收款。

-顾客：希望能准确快速的付款，希望得到购买凭证，以便退货。

-希望确保记录了支付授权服务的支付票据。希望能自动、快速的更新账务和库存信息。

-政府税收代理：希望能从每笔交易中抽取税金。

-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。

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

成功保证：生成票据。记录支付授权的批准。

主成功场景：

1、收银员告知顾客总额，并请顾客付款。

2、顾客付款，系统处理支付。

3、系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理）和库存系统（更新库存）。

4、系统打印票据。

5、顾客携带商品和票据离开。

扩展：

1a.顾客要求现金付款，但所携带的现金不足:

1、顾客要求使用其他支付方式。

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

2a.现金支付：

1、收银员输入收取的现金额。

2、系统显示找零金额，并弹出现金抽屉。

3、收银员放入收取的现金，并给顾客找零。

4、系统记录该现金支付。

2b.信用卡支付：

1、顾客输入信用卡账户信息。

2、系统显示其支付信息以备验证。

3、收银员确认。

4、系统向外部支付授权服务系统发送支付授权请求，并请求批准该支付。

4a.系统检测到与外部系统协作时的故障：

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

2、收银员请求顾客更换支付方式。

5、系统收到批准支付的应答并提示收银员，同时弹出现金抽屉，放入签名后的信用卡支付票据。

5a.系统收到拒绝支付的应答：

1、系统向收银员提示支付被拒绝。

2、收银员请求顾客更换支付方式。

       5b.应答超时。

1、系统提示收银员应答超时。

2、收银员重试，或者请求顾客更换支付方式。

6、系统记录信用卡支付信息，其中包括支付批准。

7、系统显示信用卡支付的签名输入机制。

8、收银员请求顾客签署信用卡支付。将签名后的信用卡支付票据放入现金抽屉并关闭抽屉。

2c.收银员取消支付步骤：

1、系统回到“商品输入”模式。

4a.打印票据。

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

2、收银员更换纸张。

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

特殊需求：

• 90%的信用卡授权响应时间小于30秒。

技术与数据变元表：

2a.信用卡账户信息应用读卡器输入。

 

2.4 系统顺序图与操作契约

系统顺序图（SSD）针对用例的一个特定场景，阐述从参与者到系统的跨越系统边界的事件制品，便于设计阶段为类分配职责。操作契约(Contract of Operation)定义了重要系统事件对领域模型内对象状态的变化。

A. 系统顺序图。使用UML顺序图，选择1个业务活动用例绘制系统顺序图。

开单：

收银：

B. 操作契约。选择系统顺序图中复杂的系统事件编写操作契约。

如有需要，使用UML状态图对某些关键对象（如订单）状态转换进行建模分析