2 需求分析
2.1业务建模
业务建模(Business Modeling)对领域内企业管理和业务对象进行建模。包括业务流程建模和领域建模。业务流程建模描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向。领域建模是从现实的问题域中找到最有代表性的概念对象，抽象成分析类。
A. 业务流程建模。
u 使用UML活动图分析目标系统所支持的业务流程。
u 使用文字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。
B. 领域建模。
使用UML类图构建领域模型。
2.2需求规格说明
需求规格说明书(Software Requirements Specification)描述了系统的功能需求。构建系统用例模型描述功能需求。
（1）系统用例建模
（2）用例详述文本
范围：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系统）。
票据打印机
信用卡、借记卡读卡器
4.2.1
表单利用jquery进行传值和表单验证。
扫一扫
162
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
