[misp]细化迭代三

2.1业务建模

业务建模(Business Modeling)对领域内企业管理和业务对象进行建模。包括业务流程建模和领域建模。业务流程建模描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向。领域建模是从现实的问题域中找到最有代表性的概念对象，抽象成分析类。

A. 业务流程建模。

u  使用UML活动图分析目标系统所支持的业务流程。

UC1销售开单用例

UC2收银用例

u  使用文字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。

涉众：顾客、收银员、酒店经理

业务规则：

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系统）。

票据打印机

信用卡、借记卡读卡器