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