细化迭代四
2.1业务建模
A. 业务流程建模。
B. 领域建模
2.2需求规格说明
A. 系统用例图。绘制整个系统的UML用例图。
B. 用例详述文本。
对所有业务活动用例采用详述风格（包括前置条件、后置条件、主事件流，扩展、业务规则等）进行描述。
用例UC3：退货
范围：超市POS机应用
主要参与者：顾客目标
主要参与者：收银员
涉众及其关注点：
-收银员：希望有准确、快速的输入方式，不会发生付款错误的情况。
-顾客：希望买到商品，井获得快速的服务，同时希望昀购买后能保证退货。
-公司：希望能够准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。
-经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。
-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。
前置条件：收银员必须通过确认和认证。
后置条件：存储销售信息。准确计算销售额。更新售价和库存信息。记录销售量。生成票据和记录支付授权。
主事件流：
1.顾客提出退货要求。
2.收银员接受顾客提供的商品和购物票据，并向经理汇报情况。
3.经理根据购物票据对商品进行核查。
4.经理录入退货信息。
5.系统生成退货单。
6.经理根据退货单向顾客返还相应的现金，并打印退货单。
扩展
*a.经理在任意时刻要求进行超控操作：
1.系统进入经理授权模式。
2.经理或收银员执行某一经理模式的操作。
3.系统恢复到收银员授权模式。
*b .系统在任意时刻失败：
为了支持恢复处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。
3a.核查不通过：
1.购物票据里的商品与实际要求退货的商品不符，经理拒绝顾客退货要求，并返还商品。
2.商品受到售后损坏，不符合退货要求。
4a.退货信息录入错误，经理向系统取消退货操作，并重新进行退货操作：
6a.打印退货单。
1.如果系统能够检测到错误，给出提示。
2.收银员更换纸张。
3.收银员请求打印其他票据。
特殊需求：
l大型、平面显示器，触摸式使用界面，在30厘米外能看清上面的字。
l能在30秒内相应90%的信用授权。
l由于某种原因造成与外部系统（如库存系统）连接出现故障时，希望系统的复原能力比较强。
l显示的文字应是国际化语言文字。
l能在步骤3-7之间客户华增加企业的业务规则。
技术与数据变元表：
*a.店长超控需要刷卡（由读卡器读取超控卡）或在键盘上输入授权码。
2.3补充性规格说明
简介
本文档中描述的是在POS系统需求中除用例以外的所有其他需求。
功能性
（这功能有可能是存在于或涉及多个用例中的常见功能）
1.系统记录错误的处理方法：要求记录所有系统错误到可永久保存的储存介质中。
2.系统可嵌入商业规则：从而在某个特定事件发生时，可以使用某企业自己的 商业规则。
3.安全性：要求系统所有的使用行为必须是得到授权的。
可用性
考虑到人的因素，由于顾客希望能看到POS系统显示的内容，所以需要使用大型显示器，以便于顾客在30厘米以外也能看到文字。同时，显示时应该避免使用色盲无法辨别的颜色。另外，为了能及时提醒收银员，不仅要显示文字还需要能够提供声音发出的提示或警告。
可靠性
1.系统中断时的可恢复性：如当系统无法和外部系统通信时，利用本地临时解决的可能性。
2.性能：希望90％以上的交易能在一分钟内完成。
可支持性
1.可适应性：系统要能根据不同情况，设定相应的商业规则，从而在不同情况下提供不同的服务。
2.可配置性：用户够根据自身情况选择系统不同的配置方式，如瘦客户机或胖客户机，两层式系统或多层式系统等。
实现约束
采用Java技术的解决方案。采用Java技术一般被认为除了易于开发外，还能够提高远期的移植和可支持性能力。
购买构件
•税金计算器。必须支持用于不同国家的可插拔计算器。
免费开源构件
一般而言，在该项目中我们尽可能地使用免费的Java技术开源构件。如：
•ssh
•easyui
•maven
•......
接口
1.重要硬件和接口
•触摸屏（触摸动作视为鼠标事件）
•条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为键盘输入）。
•票据打印机。
•信用卡读卡器。
•签名读取装置。
2.软件接口
由于存在外部协作系统，我们需要采用不同的接口，接入不同的系统。
所关注领域内的信息
1.定价
除了定价规则之外，还需要注意，产品有原始价格和可选的常设低标价之分。产品标示的价格（折扣前）是常设低标价。由于财务和税务的原因，即使有常设低标价，也需要维护原始价格。
2信用卡支付处理
当支付授权服务批准了信用卡支付后，将有支付授权服务来负责对卖方的支付。
3.销售税：对税金计算采用第三方软件（税金计算器）计算。
4.商品标识：UPC、EAN、SKU、条形码和条形码读取装置。