餐饮需求分析v42.docx

餐饮需求分析v42.docx

《餐饮需求分析v42.docx》由会员分享，可在线阅读，更多相关《餐饮需求分析v42.docx（12页珍藏版）》请在冰点文库上搜索。

餐饮需求分析v42

1引言1

1.1编写目的1

1.2背景2

1.3定义2

1.4参考资料2

2任务概述3

2.1目标3

2.2用户的特点3

2.3限制与约束3

3需求规定4

3.1用例图4

3.1.1主要参与者4

3.1.2用例描述4

3.1.3用例关系图8

3.2活动图10

3.2E-R图11

3.4对性能的规定11

3.4.1数据精度要求11

3.4.2时间特性12

3.4.3适应性12

3.4.4故障处理13

4运行环境规定13

4.1系统软件运行环境13

4.1系统硬件运行环境13

4.3接口14

4.4控制14

1引言

1.1编写目的

本说明书的目的在于明确说明系统需求，界定系统实现功能的范围，知道系统设计以及编码。

本说明书的预期读者为：

项目经理，系统分析员，系统设计人员，开发工程师，测试经理以及测试设计人员等。

1.2背景

1）本系统名称为Sunflower餐饮管理系统；

2）本项目的任务提出者是Sunflower项目小组项目经理，开发者为Sunflower开发小组成员，使用用户为餐饮行业服务员及坐台收银员。

1.3定义

1、日志：

软件日志是记录软件问题的信息，同时还可以监视软件使用中发生的事件。

用户可以通过它来检查错误发生的原因。

2、C/S：

C/S又称Client/Server或客户/服务器模式。

服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sybase、Informix或SQLServer。

客户端需要安装专用的客户端软件。

3、ODBE：

开放数据库互连（ODBC）是MICROSOFT提出的数据库访问接口标准。

1.4参考资料

1、UML系统建模与分析设计刁成嘉、刁裔机械工业出版社

2、实用软件工程陆惠恩、张成姝清华大学出版社

2任务概述

2.1目标

本系统针对的用户是中大型餐厅，功能包括点餐与结账，使点餐与管理一体化，提高工作效率，避免手工作业的麻烦。

从而使管理者能够准确、有效地管理。

2.2用户的特点

本软件最终用户是餐厅里中的收银员，因工作简单，无教育程度火技术上的要求，所以本软件应界面友好，简单易用，稳定性高。

2.3限制与约束

本系统必须满足一下限制：

1）系统中所有账户能够提供用户随时使用，完成各自授权的活动。

2）安全可靠，建立系统使用日志。

3）该系统必须确保对数据进行完全保护，以免XX的反问；所有的远程访问都要登录，并且每个登录用户只能根据角色所授的权限进行访问。

4）界面友好，操作简便。

5）软件系统开放性好，结构灵活，可扩充，易于维护。

6）遵循C/S结构总体设计方案对它的约束，在其实施的各个阶段都要服从它的一些规划，包括功能设计、系统配置和计划。

3需求规定

3.1用例图

3.1.1主要参与者

参与者说明

参与者名称：

经理抽象：

否

描述：

餐饮经理指计划、指导和协调餐饮机构活动的人员。

负责餐厅整体经营管理工作，负责组织、监督、知道、检查餐厅月度盘点工作。

参与者说明

参与者名称：

服务员抽象：

否

描述：

本系统中服务员负责日常运作中桌位安排与管理，接受客人菜单并输入系统后传递厨房。

并负责收银结账工作。

3.1.2用例描述

用例：

结账

用例ID：

UC_101

参与者：

服务员

描述：

进行收银工作，将指定的桌位的客人进行总价计算，打印账单和发票，并将账目存储到数据库中。

用例：

预约餐桌

参与者：

服务员

描述：

为客人预订餐桌，并修改餐桌状态。

前置条件：

结束餐饮

事件流

客人至收银台进行本次餐食结算

后置条件

修改餐桌状态

用例：

换台

用例ID：

UC_102

参与者：

服务员

描述：

为客人更换餐桌，并修改对应的餐桌状态。

前置条件：

客人已在餐且有可用餐桌

事件流

客人更换餐桌进行餐食

后置条件

修改更换钱的餐桌状态和更换后的餐桌状态

用例：

增加菜单

用例ID：

UC_103

参与者：

服务员

描述：

当客人需要点菜并需要人工服务时，帮助客人点菜并打印菜单，为客人提供点菜帮助。

前置条件：

客人已点菜

事件流

增加客人菜单项目

后置条件

修改菜单和菜单价格

用例：

修改菜单

用例ID：

UC_104

参与者：

服务员

描述：

当客人需要修改菜单并需要人工服务时，协助客人修改菜单，并打印菜单。

前置条件：

客人已点菜

事件流

修改菜单中已经存在的菜系，更换或者去除

后置条件

修改菜单和菜单价格

用例：

销售统计

用例ID：

UC_105

参与者：

经理

描述：

查询指定时间的账目，根据需要统计结果，并可做出市场预测。

前置条件：

账目存档

事件流

对账目进行统计，做出相应的预测

后置条件

形成初步市场预测

3.1.3用例关系图

用例描述：

除了电子阅菜外，我们还由服务员提供人工服务。

服务员的主要能力如下：

①、结账：

客户结账时，可以引导客户快速结账。

②、预约餐桌：

为客户预约可用餐桌（包含预约中的所有功能）③、换台：

为客户更换餐桌。

④、新增菜单：

应客户要求对客户菜单进行人工增加并打印。

⑤、修改菜单：

应客户要求对客户菜单进行人工修改并重新打印。

用例描述：

此用例为本产品的基本功能之一----统计与预测。

①、销售统计：

由经理全权统计本酒家的销售概况。

②、账目查询：

通过到已售账目的分析做出相应的做③市场预测。

④并提供文本打印备份功能。

3.2活动图

3.2E-R图

3.4对性能的规定

为了保证系统能够长期、安全、稳定、可靠、高效地运行，本系统该满足以下四方面性能需求。

3.4.1数据精度要求

系统对数据处理的准确性和精度要求应当满足；

1）系统产生的货币金额数据保留到小数点后2位。

2）为了保证产生的结果误差最小，市场预测系统用到的数据应保留到小数点后2位。

3）没有特殊要求的实型数据一般保留到小数点后2位。

4）整数保留到个数位。

3.4.2时间特性

系统处理的准确性和及时性是系统的必要性能。

在系统设计和开发过程中，要充分考虑系统当前和将来可能承受的工作量，使系统的处理能力和响应时间能够满足用户对信息处理的需求。

“餐饮管理系统”要求在日常处理中的响应速度为<1秒级，以及及时反馈信息。

在进行统计、分析和市场预测时，根据所需数据量的不同而从秒级到分钟级。

原则是保证操作人员不会因为速度问题而影响工作效率。

3.4.3适应性

“餐饮管理系统”在开发过程中，应该充分考虑以后的可扩充性。

例如管理系统的方式的改变，用户查询的需求也会不断地更新和完善。

所有这些，都要求系统提供足够的手段进行功能的调整和扩充。

而要实现这一点，应通过系统的开放性来完成，即系统应是一个开放系统，可以在符合一定规范的前提下，简单的加入和减少系统的模块，配置系统的硬件。

通过软件的修补、替换完成系统的升级和更新换代。

系统的易用性和易维护性保证。

“餐饮管理系统”直接面对的用户并不是计算机专业人员，这就要求系统能够提供良好的用户接口，友好的人机交互界面。

要实现这一点，就要求系统应该尽量使用用户熟悉的术语和中文信息的界面；针对用户可能出现的使用问题，要提供足够的在线帮助，缩短用户对系统熟悉的过程。

3.4.4故障处理

“餐饮管理系统”中涉及到的数据是企业重要的信息，系统要提供方便的手段供系统维护人员进行数据的备份、日常的安全管理、系统意外崩溃时数据的恢复等工作。

4运行环境规定

4.1系统软件运行环境

1）系统建模采用支持UML的EnterpriseArchitect7.0

2）本系统实现采用Delphi7平台

3）数据管理才用MicrosoftSQLServer2008数据库管理系统。

4）系统操作平台才用微软的WindowsXP。

5）才用XX.XX网络操作系统。

6）服务器端的运行环境：

Windows2003Server

7）客户机运行环境：

WindowsXP

4.1系统硬件运行环境

“餐饮管理系统”共有3台服务器，用户终端机数量不限。

1）用户终端机：

才用联想PC-100，内存512MB，硬盘80GB，大屏幕液晶显示屏。

2）服务器：

联想PC-1000，内存1GB，高速硬盘组200GB，高速缓存，液晶显示屏。

3）网络：

才用XX.XX网络建立的局域网。

4）后台服务器支持系统硬件要求：

CPUPentiumIV3.0以上，内存容量2GB以上，硬盘500GB以上。

4.3接口

和其它软件接口：

ODBE

4.4控制

本软件为应用软件，采用电脑外置键盘和鼠标操作，用户通过键盘鼠标操作及使用本软件。

小组成员：

陈艺华、刘洋、陈乃华、林贵华、刘昊、魏东