餐馆预约管理系统.docx
- 文档编号:11949900
- 上传时间:2023-04-16
- 格式:DOCX
- 页数:14
- 大小:21.89KB
餐馆预约管理系统.docx
《餐馆预约管理系统.docx》由会员分享,可在线阅读,更多相关《餐馆预约管理系统.docx(14页珍藏版)》请在冰豆网上搜索。
餐馆预约管理系统
概述
1.简介
餐饮业在一直是服务行业最重要的组成部分之一。
薄利多销一直是餐饮业的营销理念。
如何在当前餐饮行业日趋激烈的竞争环境中脱颖而出并吸引更多的顾客,已成为每位餐饮业经营者所追求的目标。
经过多年发展,餐馆管理已经逐渐由简单而繁琐的人工管理,进入科学系统管理的阶段。
如何有效的节约人力成本是餐饮业致力于解决的首要问题。
当前最有效的手段就是采用系统的自动化电脑管理取代过去的人工方式。
1.1参考资料
[1]《软件工程(第二版)》张海潘编著
[2]《面向对象设计UML实践》Markpriestley著
[3]《面向对象分析与设计(原书第2版)》冯博琴冯岚薛涛崔舒宁编著
2.定位
2.1问题描述
当前该餐馆采用的是一个传统的手工预约系统,将手写预约单保存在一个大文件夹中,这种传统的方法不但效率低,而且容易出错,产生诸多问题。
例如:
a)手工预约单使空餐桌的存在不明显,妨碍顾客进行预约。
b)由于没有备份系统,一张预约单的毁坏将导致相应信息的永久丢失。
c)不容易获得相应的统计数据,例如某时刻餐桌的使用率
d)对系统不容易进行更新等操作
基于上述种种缺陷,该餐馆向我方提出设计更换一个自动化的订餐管理系统,要求保留原有传统手工方式的功能和工作人员熟悉的操作方式,同时改进系统,以节约人力成本。
2.1.1问题1
问题1的描述见表2.1。
表2.1问题1的描述
问题是
手工预约单使空餐桌的存在不明显
影响
前台服务员
问题的后果
顾客订餐容易出现满座,前台服务员对餐桌的调配困难
成功的解决方案
设计实时显示部件,使餐桌的使用情况能及时得到反馈。
2.1.2问题2
问题2的描述见表2.2。
表2.2问题2的描述
问题是
由于没有备份系统,一张预约单的毁坏将导致相应信息的永久丢失。
影响
餐馆管理者,前台服务人员
问题的后果
预定信息的丢失,座位等信息出现混乱。
成功的解决方案
设计实时备份部件,使其在使用过程中能够做到实时备份,操作时用的是实时文件而不是备份文件。
2.1.3问题3
问题3的描述见表2.3。
表2.3问题3的描述
问题是
不容易获得相应的统计数据,例如某时刻餐桌的使用率
影响
餐馆管理者
问题的后果
不能使餐馆的盈利情况得到及时被餐馆所有者了解,不能更好的制定营销策略。
成功的解决方案
在一定的条件下使用实时的记录部件,使整个餐馆的大部分有用数据能够及时记录供管理者参考。
2.2产品定位说明
易学易用,操作极为简便,它是一套纯WINDOWS软件,操作界面友好直观。
功能完整,本系统包括订餐、用餐管理功能,系统具有分类查询和结账计算功,能够实现餐馆的数字化经营。
数据安全性,使数据库安全有保障。
开放性好,采用标准的开发工具和技术,后台数据库采用SQLsever2000,可以提供开放的数据接口,可同其它软件交流数据。
见表2.4。
表2.4餐馆预约管理系统的产品描述
针对于
餐馆管理者,前台服务员
谁
进行餐馆就餐预约管理
该(产品名)
为预定管理提供一个平台
功能
提供一个可以就餐预约管理的平台
不同于
面对面预定
我们的产品
网上/电话预定,不受时空限制,潜在交易增加,降低经营成本,节省时间。
使用UML设计模型,明确、简化系统模块和交易流程。
3.涉众和用户说明
这一部分主要描述了餐馆预约管理系统的涉及人群和用户。
涉及人群主要包括餐馆预定管理系统项目组成员,前台服务人员,餐馆管理者,顾客。
3.1涉众概要
涉众概要见表3.1。
表3.1涉众概要
姓名
描述
职责
开发组成员
主要开发餐馆预定系统
对餐馆预定系统进行设计、架构、编码、测试以及安装。
餐馆管理者
系统中的服务执行方
搜索、查看餐座使用情况,查看订餐者预约信息的功能。
拥有餐桌分配更改的权力和对整体预约情况进行调整。
前台服务员
系统中的服务受理方
搜索、查看餐座使用情况,查看订餐者预约信息的功能。
拥有餐桌分配权力和用餐结算。
顾客
消费群体
根据自己的实际情况决定预约的时间,座位,及就餐情况。
3.2用户概要
用户概要见表3.2。
表3.2用户概要
姓名
描述
职责
涉及人群
接待员
预约接待人员
下订单、修改订单、取消订单、提醒用户
餐馆管理者
领班
主要跟顾客接触完成
记录到达、接待Walk-In、管理会员信息、餐馆信息管理。
前台服务员
3.3涉众简档
3.3.1开发组成员
代表
杨润
说明
主要进行系统的设计、开发、测试和安装工作
类型
主要进行软件开发
职责
开发出符合客户要求的系统
成功标准
开发出的软件符合客户的要求,提供合理的预约管理流程
参与
全程参与
可交付工件
无
意见/问题
开发的技术难点等
3.3.2预约管理系统中的前台服务人员
代表
前台服务人员
说明
系统运营中的预约服务受理方
类型
终端用户
职责
搜索、查看餐座使用情况,查看订餐者预约信息的功能。
拥有餐桌分配权力和用餐结算
成功标准
满足他们提出的主要需求,系统反应迅速且安全、可靠,方便操作,使其能及时得到相关信息
参与
反应出系统的主要需求
可交付工件
可运行系统
意见/问题
需求表达不够清楚
3.3.3顾客
代表
顾客
说明
消费主体
类型
无
职责
无
成功标准
满足顾客需求:
安全、反应快、操作方便
参与
与前台服务人员及参观管理者进行实际交互
可交付工件
无
意见/问题
无
3.3.4餐馆管理人员
代表
餐馆管理人员
说明
主要的服务执行者
类型
终端用户
职责
搜索、查看餐座使用情况,查看订餐者预约信息的功能。
拥有餐桌分配更改的权力和对整体预约情况进行调整。
成功标准
预约量大幅度增加,增加餐馆的利润
参与
提出需求、管理系统
可交付工件
可运行系统
意见/问题
需求不明确
4系统特性
下面描述了餐馆预约管理系统的部分功能特性:
功能名称
功能描述
功能约束
处理过程
添加预约
包括早、中、晚三部分可预定时间,可预约当天及以后3天内的所有空闲餐座当桌位被预订后桌位在预定时间前后一小时保留显示为餐座不可用
预约餐座标记为空闲时可用
通过相关记录预约功能模块将信息读入数据库。
删除预约
当客人取消预定,经前台管理人员确定后,系统将已经预订的桌位改为空闲状态。
餐座必须标记为预约状态时可用
从数据库读预约信息并对数据库执行删除记录动作。
各类信息查询
为用户提供模糊查询预约信息、用餐信息。
联合查询
根据关键字将信息从据库中读取出来
更改预约状态
对已经预约的订单条目信息参照客人要求作出相应的修改。
当客人来时(到达预约时间)餐桌自动显示为用餐状态。
餐座必须标记为预约状态时可用
从数据库读预约信息并对数据库执行修改记录动作。
实时消费管理
桌位查询,查询桌位的状态(包括桌位是否为空,座位数)
。
输入合法的餐座号,已经预约和处于就餐状态的餐座不可查询
根据关键字将信息从据库中读取出来
结算模拟功能
用户用餐结束后可以要求前台进行结算,执行此功能后餐桌更改为空闲状态
要求可结算餐桌均为处于用餐状态餐座
将数据库表中处于用餐状态的所有表目录信息调出查看并选择进行结算后删除条目
开台功能
根据查询后桌位,记录来用餐的客户数目并将餐座状态修改为用餐态
要求订单是完全处理后的情况
将数据库中的订单表进行添加,生成新的订单记录
5其他需求和约束
该系统餐馆管理系统建设计划中订餐系统,是整体系统的一个组成部分。
因此要求能够使该系统与餐馆管理的其他模块相适应。
设备限制:
公用机房电脑。
TableofContents
补充规格说明
1.引言
目的
本文的目的在于定义用例技术未能捕获的系统需求。
这个补充文档和用例一起构成餐馆预约管理的完整的需求描述。
范围
此文档定义了餐馆订餐系统的非功能需求(包括可靠性,可用性,性能等)和用例中通用的功能性需求。
定义,缩略语,缩写
接待员-通过互联网或者电话使用这个预约管理系统来制定订单的人。
管理员-负责接待跟现场安排就餐的人。
用户-领班和接待员。
系统-餐馆预约管理系统。
参考文献
暂无
2.功能性需求
这章描述了用例中通用的功能性需求。
日志系统
所有的系统出错信息都必须被记录到出错日志中。
信息的格式必须是系统错误号码,日期,时间,错误信息。
每次处理前后的消耗的内存和处理时间都必须被记录到性能日志中。
信息的格式必须是日期,时间,消耗的内存,处理时间。
邮件系统
系统所有的电子邮件必须通过预先设定的邮件系统发送。
监视系统
监视系统必须扫描日志系统如果有任何异常的情况,必须使用邮件系统向管理员发警告信。
安全系统
安全系统必须拦截非法的访问,和对网站的恶意进攻包括(XSS,SQLInjection,非法盗链等,非法字符输入等)。
3.可用性
下面列出了和系统的可用性相关的需求。
系统易用性
餐馆预约管理系统的用户界面设计必须简单明了,不需要顾客花费额外的时间来学习。
帮助服务
餐馆预约管理系统的每个重要页面上必须都有相关的帮助页面的链接,使用者可以使用它们来获得必要的帮助信息。
4.可靠性
可用性
餐馆预约管理系统必须能够24小时*7天的工作。
系统严重错误发生的平均时间间隔
系统发生严重错误的平均时间间隔应该大于9000小时。
5.性能
最大的并发人数
餐馆预约管理系统的最大并发访问数应该为100。
在这个范围内,系统应该能够很好的工作。
最大系统相应时间
在最大并发数为100范围内时,系统对用户的最大相应时间应该小于10秒/1万条数据。
最大的事务处理时间
餐馆预定管理系统的用户事务的最大处理时间应该是45秒,如果超过这个时间系统应该自动结束用户的事务处理。
6.保障性
出错对应时间
当系统发生错误时,对应的补丁程序的发布时间应该是小于2天/一件bug。
技术支持时间
本系统完全上线后的一年内,提供的技术支持时间应该是每周8小时*5天。
7.设计上的限制
数据库管理软件
系统必须使用相应接口同关系型数据库管理软件建立连接。
平台要求
系统的平台要求
设备名称
详细要求
处理器
IntelPentium42GHZ或同级别处理器
内存容量
至少256MB,推荐512MB
外存容量
至少30G,推荐80GB
联机/脱机
客户端连接本地数据库服务器
。
Java的版本
系统必须在java1.3以上的版本上运行。
TableofContents
用例调查说明书
8.说明的概述
用例模型
系统用例图如下:
Receptionist
Staff
Recordbooking
Cancelbooking
Dispalybookings
Tabletransfer
Recordwalk-in
Recordarrival
HeadWaiter
用例的概要描述如下表所示:
主要参与者
优先级
用例名
用例概述
接待员
中
显示预约(DisplayBooking)
显示顾客的预约信息。
高
预约记录(RecordBooking)
记录顾客的预约信息。
中
取消预约(CancelBooking)
取消顾客的预约信息。
领班
中
显示预约(DisplayBooking)
显示顾客的预约信息。
高
交换餐桌(TableTransfer)
交换预约餐桌并更新。
高
记录到达(RecordArrival)
记录已执行预约信息。
假设和依赖
假定:
该系统餐馆管理系统建设计划中订餐系统,是整体系统的一个组成部分。
9.详细需求
这章中将使用用例技术描述系统的详细需求。
Use-Case清单
用例名和对应的用例描述文件的关系如下:
编号
用例名
对应用例文件
01
显示预约
01_ucspec.doc
02
记录记录
02_ucspec.doc
03
取消预约
03_ucspec.doc
04
交换餐桌
04_ucspec.doc
05
预约到达
05_ucspec.doc
TableofContents
Glossary
10.引言
本文给出了在餐馆预约管理系统的需求文档中使用到的术语的解释。
目的
明确了这些术语的含义,避免产生混淆。
范围
餐馆预约管理系统的需求文档。
参考文献
[1]《软件工程(第二版)》张海潘编著
[2]《面向对象设计UML实践》Markpriestley著
[3]《面向对象分析与设计(原书第2版)》冯博琴冯岚薛涛崔舒宁编著
11.定义
统计系统
统计系统是指用来统计预约相关信息的的一套程序系统,是一个已经存在的系统。
结算系统
结算系统是指用来进行用餐结算的一套程序系统,此系统处理用餐消费结算相关的工作,是一个已经存在的系统。
J2EE规范
J2EE(Java2Platform,EnterpriseEdition)是SUN公司定义的一个开发分布式企业级应用的规范。
它提供了一个多层次的分布式应用模型和一系列开发技术规范。
数据库管理系统
数据库管理系统(DatabaseManagementSystem)是一种操纵和管理数据库的大型软件,是用于建立、使用和维护数据库。
它对数据库进行统一的管理和控制,以保证数据库的安全性和完整性。
用户通过数据库管理系统访问数据库中的数据,数据库管理员也通过DBMS进行数据库的维护作。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 餐馆 预约 管理 系统