2.1业务建模
业务建模(Business Modeling)对领域内企业管理和业务对象进行建模。包括业务流程建模和领域建模。业务流程建模描述系统内各单位、人员之间业务关系、做业顺序和管理信息流向。领域建模是从现实的问题域中找到最有表明性的概念对象，抽象成分析类。java
A. 业务流程建模。安全
u 使用UML活动图分析目标系统所支持的业务流程。网络
UC1销售开单用例并发
UC2收银用例性能
u 使用文字对流程中每一个活动的涉众、业务规则、使用到的单据进行必要的说明。ui
涉众：顾客、收银员、酒店经理spa
业务规则：设计
ID日志 |
规则对象 |
可变性 |
来源 |
规则1 |
顾客折扣规则。如： 酒店经理：10%折扣额 |
高，没每间酒店都有不一样规则 |
酒店政策 |
使用到的单据：
收款票据，内容包括：酒店名称，开单时间，台号，经理工号，消费详细，商品单价，商品数量，应收金额，实收金额，找零金额等
B. 领域建模。
u 使用UML类图构建领域模型。
2.2需求规格说明
需求规格说明书(Software Requirements Specification)描述了系统的功能需求。构建系统用例模型描述功能需求。
A. 系统用例图。绘制整个系统的UML用例图。
B. 用例详述文本。
对全部业务活动用例采用详述风格（包括前置条件、后置条件、主事件流，扩展、业务规则等）进行描述。
范围：POS应用
主要参与者：经理，收银员
前置条件：收银员和经理必须通过确认和认证
成功保证（后置条件）：存储消费信息。准确计算税金，准确计算消费总额，生成票据。
主成功场景：
1．经理给用户开台
2．顾客物色好菜式后，经理给顾客点菜
3．经理把顾客所点的菜式输入POS系统
4．顾客用餐
5．顾客用餐完毕要求结帐
6．收银员进行结帐，系统显示总额和所计算的税金，并打印出小票
7．经理凭票据向顾客收款
8．顾客付款
扩展：
*a.系统在任意时刻失败：
1. 收银员或经理重启系统，登陆，请求恢复上次状态。
2. 系统重建上次状态
1a.顾客因人数或者喜爱须要换桌
经理进入系统，修改这次消费订单对应的台号
4a.顾客用餐过程须要加菜
经理给顾客进行加单，而且输入系统对应的消费订单
4b.顾客用餐过程因等待过久或者因菜式有问题须要进行退单
经理确认状况给顾客进行退单，而且更新系统对应的消费订单
7a.顾客核对本身的消费详细记录，发现有有误及时提出
1.经理核对具体状况，确认无误后进入系统更新订单
2.继续第6步
2.3 补充性规格说明
补充性规格说明补货并肯定其余类型的需求，如可靠性（如10000人并发访问）、可用性（如1米外轻松看到文本）、接口（如支持钱箱、支持网银支付接口）等。也能够包括其余跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。
简要描述本项目最终系统数据查询与报表，系统权限管理的功能需求。也能够描述项目组计划实现的其余需求。
功能性
1、日志和错误处理
在持久性存储中记录全部错误。
2、可插拔规则
在几个用例的不一样场景点执行任意一组规则，以支持对系统功能的定制。
3、安全性
任何使用都须要通过用户认证。
可用性
1、避免使用通常色盲人群难以辨认的颜色。
2、快捷、准确的结帐处理及其重要，由于顾客但愿快速结束结帐过程，不然会给他们的购买体验带来负面影响。
可靠性
1. 性能
须要体现出系统的稳定性以及反应速度。
2、数据备份
系统支持定时或实时的对数据进行备份，避免数据的破坏或者丢失，如处理消费交易过程当中，系统出现闪退或者奔溃状况下致使的数据丢失或者须要从新录入。
可支持性
1、可适应性
不一样客户在处理销售时有其特有的业务规则和处理需求。所以，在场景中的几个预约之处（如开始新的销售交易时，增长新的商品时），须要可以启用可插拔的业务规则。
2、可配置性
系统具有必定的可配置能力以适应该店对其POS系统的不一样的网络配置需求。
实现约束
使用的程序设计语言为java，其具有易于开发，可以提升远期的移植和可支持性能力。
购买构件
税金计算器，必须支持用于不一样国家的可插拔计算器。
免费开源构件
建议使用免费的Java技术开源构件。
接口
重要硬件和接口
显示屏（显示POS系统）。
票据打印机
信用卡、借记卡读卡器