细化迭代2：实现销售开单用例
2.2需求规格说明
需求规格说明书(Software Requirements Specification)描述了系统的功能需求。构建系统用例模型描述功能需求。
A. 系统用例图。绘制整个系统的UML用例图。
B. 用例详述文本。
对所有业务活动用例采用详述风格（包括前置条件、后置条件、主事件流，扩展、业务规则等）进行描述。
用例UC1：开单
范围：超市POS机应用
主要参与者：顾客目标
主要参与者：收银员
涉众及其关注点：
-收银员：希望有准确、快速的输入方式，不会发生付款错误的情况。
-顾客：希望买到商品，井获得快速的服务，同时希望昀购买后能保证退货。
-公司：希望能够准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。
-经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。
-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。
前置条件：收银员必须通过确认和认证。
后置条件：存储销售信息。准确计算销售额。更新售价和库存信息。记录销售量。生成票据和记录支付授权。
主事件流：
1.顾客携带所购商品到收银台通过POS机付款。
2.收银员开始一次新的销售交易。
3.收银员扫描顾客所购商品的商品条形码来处理商品信息。
4.系统逐条记录出售的商品，并显示该商品的描述，价格和累计额。价格通过一组价格规则来计算。
收银员重复3～4步，直到输入结束。
5.系统显示总额和计算折扣。
6.收银员告知顾客总额，并请顾客付款。
扩展
*a.经理在任意时刻要求进行超控操作：
1.系统进入经理授权模式。
2.经理或收银员执行某一经理模式的操作。
3.系统恢复到收银员授权模式。
*b .系统在任意时刻失败：
为了支持恢复处理，要保证所有交易的敏感状态和事件都能够从场景的任何一步中完全恢复。
1.收银员重启系统，登录，请求恢复上次状态。
2.系统重建上次状态。
2a.系统在恢复过程中检测到异常：
1.系统向收银员提示错误，记录此错误，并进入一个初始状态。
2.收银员开始一次新的销售交易。
3a.无效商品ID：
1.系统提示错误并拒绝输入该ID。
2.收银员响应该错误。
2a.商品ID可读。
1.银员手工输入商品ID。
2.系统显示商品项目的描述和价格。
2a.无效商品ID：系统提示错误，收银员尝试其他方式。
3b.当有多个同一类别的商品时，不必记录每个商品的唯一标识：
1.收银员输入商品类别的标识和商品数量。
3-6a.顾客要求收银员去掉某个原先想买的商品:
1.收银员录入要去掉商品的条码与数量。
2.系统更新当前的总销售金额。
3-6b.顾客要求收银员取消这次销售:
1.收银员取消这次销售交易。
3-6c.顾客要求收银员暂停本次销售:
1.系统将销售记录下来，而且之后可以在任何POS终端中取回这比销售交易的记录。
5a.收银员询问顾客是否享受会员优惠
1.顾客享受会员优惠，系统按照打折规则进行交易。
2.顾客不享受会员优惠，系统按照商品原价进行交易。
特殊需求：
•大型、平面显示器，触摸式使用界面，在30厘米外能看清上面的字。
•能在30秒内相应90%的信用授权。
•由于某种原因造成与外部系统（如库存系统）连接出现故障时，希望系统的复原能力比较强。
•显示的文字应是国际化语言文字。
技术与数据变元表：
*a.店长超控需要刷卡（由读卡器读取超控卡）或在键盘上输入授权码。
3a.（如果有条码的话）用键盘或条码扫描器输入商品识别码。
3b.商品识别码可以是UPC、EAN、JAN、SKU中的任何一种。
5a.顾客的会员号可用刷卡读取或在键盘上输入。
发生频率：可能会连续不断地发生。
2.3 补充性规格说明
补充性规格说明补货并确定其他类型的需求，如可靠性（如10000人并发访问）、可用性（如1米外轻松看到文本）、接口（如支持钱箱、支持网银支付接口）等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。
简要描述本项目最终系统数据查询与报表，系统权限管理的功能需求。也可以描述项目组计划实现的其他需求。
简介
本文档中描述的是在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、条形码和条形码读取装置。