酒店管理系统需求分析文档.docx

上传人:b****7 文档编号:15390338 上传时间:2023-07-04 格式:DOCX 页数:32 大小:277.40KB
下载 相关 举报
酒店管理系统需求分析文档.docx_第1页
第1页 / 共32页
酒店管理系统需求分析文档.docx_第2页
第2页 / 共32页
酒店管理系统需求分析文档.docx_第3页
第3页 / 共32页
酒店管理系统需求分析文档.docx_第4页
第4页 / 共32页
酒店管理系统需求分析文档.docx_第5页
第5页 / 共32页
酒店管理系统需求分析文档.docx_第6页
第6页 / 共32页
酒店管理系统需求分析文档.docx_第7页
第7页 / 共32页
酒店管理系统需求分析文档.docx_第8页
第8页 / 共32页
酒店管理系统需求分析文档.docx_第9页
第9页 / 共32页
酒店管理系统需求分析文档.docx_第10页
第10页 / 共32页
酒店管理系统需求分析文档.docx_第11页
第11页 / 共32页
酒店管理系统需求分析文档.docx_第12页
第12页 / 共32页
酒店管理系统需求分析文档.docx_第13页
第13页 / 共32页
酒店管理系统需求分析文档.docx_第14页
第14页 / 共32页
酒店管理系统需求分析文档.docx_第15页
第15页 / 共32页
酒店管理系统需求分析文档.docx_第16页
第16页 / 共32页
酒店管理系统需求分析文档.docx_第17页
第17页 / 共32页
酒店管理系统需求分析文档.docx_第18页
第18页 / 共32页
酒店管理系统需求分析文档.docx_第19页
第19页 / 共32页
酒店管理系统需求分析文档.docx_第20页
第20页 / 共32页
亲,该文档总共32页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

酒店管理系统需求分析文档.docx

《酒店管理系统需求分析文档.docx》由会员分享,可在线阅读,更多相关《酒店管理系统需求分析文档.docx(32页珍藏版)》请在冰点文库上搜索。

酒店管理系统需求分析文档.docx

酒店管理系统需求分析文档

一 项目前景

1.业务需求

1.1业务背景

随着改革开,以及后来的加入WTO后和西方文化的交流,人民生活水平得到了极大的提高,全社会对服务业的需求也越来越高。

国内的服务行业,特别是宾馆、酒店行业的发展,逐渐打破了传统的普通服务行业的那种以住宿休息为服务核心的单一运营管理方式。

由于这类顶尖酒店的运行模式与传统酒店有很大的差异,它涉及的环节比较多,业务关系也比较复杂,因此到目前为止还没有一套较规范的公认的运营管理标准,而照搬传统的酒店业务管理方法和运营机制显然已经不能适应这些变化,难以满足实际需要了。

同样,那些基于传统酒店业管理模式而开发的计算机管理系统也自然难以适应这种新的业务模式,所以造成一些酒店不得以而采用手工记费和人工结账的办法,尤其是在顶尖酒店开业时和增加新的服务项目时,这种现象往往也很普遍。

采用人工手段进行复杂的业务处理是一种相当原始的方法,尤其是在计算机、互联网高度发展的今天。

这种近乎于原始的方法,在前台操作、预订管理、收据补打印、现金管理、信息查询、报表统计、库存管理、基础资料、账号权限管理等方面都存在着许多薄弱环节,会给酒店的正常运营带来各种麻烦和漏洞。

客观上严重制约着酒店的发展。

酒店业务流程的多样性和客人的流动性也决定了手工方式不可能长久,必须按照新的模式因地制宜地进行全面细致的系统设计和软件开发,以适应这类酒店对计算机管理信息系统的迫切需求。

面对这种具有现代化文明时尚的顶尖型酒店的灵活多变的运营方式,更需要管理者和开发者用现代和超前的眼光去看待它与认识它,要结合信息网络的特点,采用有效手段进行全方位的调查分析。

1.2业务目标

BO-1:

初始版本发布之后的3个月内,酒店运营效率提高50%,服务员工作效率提高20%。

BO-2:

初始版本发布之后的6个月内,酒店收入提高50%。

SC-1:

目前通过系统的管理,在初始版本发布之后的6个月内,顾客的满意度提高30%。

1.3市场需要

随着人民生活水平的提高,人们生活的质量一额大幅提高,所以生活中酒店行业在服务行业中的地位越来越重要。

从激烈的竞争中脱颖而出,已成为每位酒店行业经营者所追求的目标。

根据酒店行业的特点,该系统以住宿以及相关业务为基础,突出将前台操作、预订管理、收据补打印、现金管理、信息查询、报表统计、库存管理、基础资料、账号权限管理等有机结合,可为酒店宾馆经营方向提供依据,为酒店宾馆的发展提供重要保证。

2.解决方案的前景

2.1前景陈述

由于过去老式的管理方式的效率太低,满足不了现在的社会需求,为了能够加快速度,提高服务质量,提高企业效率,让顾客便捷舒适的享受各种服务,我们开发了此酒店宾馆服务管理系统。

2.2主要特性

FE-1:

前台操作、预订管理

FE-2:

收据补打印

FE-3:

现金管理

FE-4:

信息查询

FE-5:

库存管理

FE-6:

基础资料

FE-7:

账号权限管理

2.3假设和依赖

AS-1:

酒店宾馆内有该公司的内部计算机网络,这样可以使系统内部通信

DE-1:

酒店宾馆内应有活动的终端和打印机,终端可以入住客户提高服务效率,打印机使打印信息收据有据可循。

3项目范围和限制

3.1初始发布的范围

FE-1:

开房,消费记账,结账退房,续收和退还客人预付款,客房状态查看,未结账退房,换房以及预定,预定入住,修改预订信息,解除预定,预定客人消费记账,预订信息一览表

FE-2:

预付款凭证补打印,结账单补打印,结账改为未结账,外卖单据查询及补打印

FE-3:

交接班,缴款,收支管理,个操作员目前金额数,改正错误金额数,交接班历史查询,缴款历史查询

FE-4:

在住客人列表,预定客人列表,历史客人列表,未来一月房态,修改过的关键营业数据,客房换房明细查询,收款员收退款流水细账

FE-5:

客房结账明细总表,客房结账汇总表,客人来源统计报表,消费商品统计报表,营业日报表,营业汇总报表,

FE-6:

基础代码,折扣卡代码,挂账单位代码,会员卡代码,操作员房价折扣权限,身份证代码,黑名单代码

FE-7:

用户历史使用记录备案,用户管理,权限管理,软件设置,计费设置

3.2后续发布范围

FE-2:

顾客结账(所有形式)。

FE-3:

入住信息管理,退房管理。

FE-6:

数据库备份、还原。

3.3限制与排除

LI-1:

入住或预定手续办理开始到结束必须在30分钟内结束。

LI-2:

前台终端不可重复项后台传同一顾客的相同服务。

LI-3:

系统只能在酒店宾馆内使用。

4业务环境

4.1涉众档案

涉众

主要价值

态度

主要兴趣

约束条件

酒店宾馆管理层

提高运营效率,增加产值

需要最终版本

减少运营成本,提高产值

酒店宾馆服务员

提高效率增加顾客满意度

担心由于系统的便捷导致裁员

保住工作

接受培训,会使用前台pos机

酒店宾馆顾客

更好的选择入住时间

支持新系统,

减少等待的时间

到酒店就餐

酒店宾馆大堂经理

增加入住额,更好的管理

电子化使环境更好

大堂秩序良好。

处理好软件的正常过度

4.2项目优先级

因素

约束

自由度

特性

初期发布实现的特性必须完全可操作

质量

必须通过95%的用户验收,保证安全和数据的完整性。

进度

10年10月1日前完成第一版

计划10年12月5日前完成第二版。

人员

一名项目经理,两名开发人员,一名测试人员

如有必要还要增加一名测试人员和一名开发人员

成本

最多可超支财政预算的5%

4.3运行环境

OE-1:

系统的操作需在windowsxp/7的操作系统下完成。

OE-2:

系统数据库将运行在一个服务器上,此服务器运行该酒店宾馆的SQLSERVER2008版数据库.

 

二软件需求规格说明书

1引言

1.1概述

该软件需求规格说明描述了“酒店宾馆服务管理系统”1.0版本的软件功能性需求和非功能性需求。

同时还描述了用户在系统的工作中所参与的角色以及拥有的权限,从而使开发团队能够明确地了解所开发的“酒店宾馆服务管理系统”1.0版本的各个方面,帮助他们在实际的开发过程中准确地完成所开发的模块,以满足用户的需求。

该文档计划由实现和验证正确功能的项目团队成员来使用,除非在其他地方另有说明,这里所指定的所有需求都具有高优先级,而且都要在版本1.0中加以实现。

1.2背景

随着改革开,以及后来的加入WTO后和西方文化的交流,人民生活水平得到了极大的提高,全社会对服务业的需求也越来越高。

国内的服务行业,特别是宾馆、酒店行业的发展,逐渐打破了传统的普通服务行业的那种以住宿休息为服务核心的单一运营管理方式。

由于这类顶尖酒店的运行模式与传统酒店有很大的差异,它涉及的环节比较多,业务关系也比较复杂,因此到目前为止还没有一套较规范的公认的运营管理标准,而照搬传统的酒店业务管理方法和运营机制显然已经不能适应这些变化,难以满足实际需要了。

同样,那些基于传统酒店业管理模式而开发的计算机管理系统也自然难以适应这种新的业务模式,所以造成一些酒店不得以而采用手工记费和人工结账的办法,尤其是在顶尖酒店开业时和增加新的服务项目时,这种现象往往也很普遍。

采用人工手段进行复杂的业务处理是一种相当原始的方法,尤其是在计算机、互联网高度发展的今天。

这种近乎于原始的方法,在前台操作、预订管理、收据补打印、现金管理、信息查询、报表统计、库存管理、基础资料、账号权限管理等方面都存在着许多薄弱环节,会给酒店的正常运营带来各种麻烦和漏洞。

客观上严重制约着酒店的发展。

酒店业务流程的多样性和客人的流动性也决定了手工方式不可能长久,必须按照新的模式因地制宜地进行全面细致的系统设计和软件开发,以适应这类酒店对计算机管理信息系统的迫切需求。

面对这种具有现代化文明时尚的顶尖型酒店的灵活多变的运营方式,更需要管理者和开发者用现代和超前的眼光去看待它与认识它,要结合信息网络的特点,采用有效手段进行全方位的调查分析。

1.3参考资料

《软件需求工程》

2任务概述

2.1目标

酒店宾馆服务管理系统运行于windows操作系统的环境下,提供宾馆住房的快捷服务和酒店的系统管理,使用酒店服务管理系统可以使外出住宿真正成为享受,随时更新最新酒店各方面信息,让顾客的整个住宿过程更加的简便捷,服务人员的服务更加的贴心快速。

整个过程也无形中节约了资源,同时也是酒店的管理更加的系统,过程更加的简单化,系统实现后,大大提高了酒店的服务效率。

降低服务过程中的错误发生率,减少信息交流的烦琐过程。

2.2运行环境

2.3OE-1:

系统的操作需在windowsxp/7的操作系统下完成。

OE-2:

系统数据库将运行在一个服务器上,此服务器运行该酒店的SQLSERVER2008版数据库.

2.4假设和依赖

2.5AS-1:

酒店内有该公司的内部计算机网络,这样可以使系统内部通信

DE-1:

酒店内应有活动的终端和打印机,终端可以点菜提高服务效率,打印机打印定菜菜单是厨房有据可循。

3需求规定

3.1对功能的规定

3.1.1用户需求

3.1.1.1组织机构和角色

角色视图:

角色说明:

角色名称

说明

ba管理层人员

酒店管理者,具有大堂经理的一切权限,并且还具有数据库初始化,账号权限管理,员工信息管理权限。

高层管理者

ba_大堂经理

餐厅管理者,具有月收入查询,日收入查询,菜式信息管理等权限。

管理者

ba_酒店服务员

工作人员,具有点菜,加菜,减菜,为顾客结账权限。

员工。

 

(1)管理层人员参与业务:

说明:

管理层人员通过登陆该系统,设置数据库,管理员工信息,收发账号权限,查询日收入和月收入,

(2)大堂经理参与业务:

说明:

大堂经理登录界面查询日收入和月收入,菜式信息。

(3)酒店服务人员参与业务:

说明:

酒店服务员通过登录界面为顾客点菜,中途还可以加菜、减菜,最后为顾客结账。

 

3.1.1.2业务概览

(1)点菜业务

点菜业务说明:

点菜是通过服务员给顾客的菜单,顾客依照菜单上有的菜进行点菜,然后服务员输入信息,系统记录。

(2)加菜业务

加菜业务说明:

加菜过程是在顾客完成点菜过程后,中途又有需要再次进行点菜,后厨通过查看系统进行做菜。

(3)减菜业务

减菜业务说明:

减菜过程是在顾客完成点菜过程后,中途对菜品不满或有什么其他情况进行减菜,后厨通过查看系统进行减菜。

(1)入住房间业务视图

结账业务说明:

结账是在顾客结束这次用餐后,服务员通过查看系统,为顾客结账。

3.1.1.3业务场景

4

(1)入住房间业务场景

(2)点菜业务场景

业务场景说明:

此图描述的是预订机票的业务流程,应使用预定义的businessactor和businessusecase作为泳道和活动。

这样有助检查和发现businessactor和businessusecase。

(1)加菜业务场景

业务场景说明:

此图描述的是预订机票的业务流程,应使用预定义的businessactor和businessusecase作为泳道和活动。

这样有助检查和发现businessactor和businessusecase。

(2)减菜业务场景

业务场景说明:

此图描述的是预订机票的业务流程,应使用预定义的businessactor和businessusecase作为泳道和活动。

这样有助检查和发现businessactor和businessusecase。

(3)结账业务场景

业务场景说明:

此图描述的是预订机票的业务流程,应使用预定义的businessactor和businessusecase作为泳道和活动。

这样有助检查和发现businessactor和businessusecase。

4.1.1系统需求

3.1.2.1概览

此图展现的是业务用例的追溯,业务用例的实现过程在每个用例实现中。

这些实现过程将是概念模型建立的依据和分析归纳的重要来源。

本例实现点菜、加菜、减菜和结账有关的业务用例。

系统将会打印菜单和账单。

 

3.1.2.2系统需求规定

(1)点菜

a业务说明

用例名称

bu_点菜

实现名称

Bur_orderdishes

用例描述

前台服务人员可以通过本用例向系统提交顾客的点菜需求

参与者

前台服务人员

前置条件

顾客必须要在本酒店落座

后置条件

主事件流

1.前台服务人员登录系统进入点菜界面

2.系统记录顾客已经点的菜

3.系统将顾客所点的菜单保存并发送给后厨

4.系统打印顾客已点的菜单。

用例结束

备选事件流

1.a登录信息错

3.a未能提交菜单

业务规则

至少点一样菜

涉及的业务实体

Be_已点菜单,Be_菜单

非功能性需求

只支持本店内使用

b业务场景分析

业务场景分析说明:

服务员登录界面通过验证之后开台点菜,系统记录菜单,完成之后提交订单,询问是否提交,不提交就返回到点菜,提交就打印菜单,后厨做菜,结束用例。

 

c、业务实体分析

业务实体说明:

上图显示的是点菜的业务实体过程,顾客通过菜单进行点菜,系统记录已点菜单。

(2)加菜

a业务说明

用例名称

bu_加菜业务

实现名称

Bur_sidedish

用例描述

前台服务人员通过本用例添加顾客需要添加的菜

参与者

前台服务人员

前置条件

1.该顾客还未结账

2.顾客已经点过至少一样菜

后置条件

记录创建加菜菜单

主事件流

1前台服务人员进入系统加菜业务界面

2.前台服务人员将加菜名输入系统,系统生成加菜菜单

3.系统将加菜菜单保存并发送至后厨

4.系统自动打印出加菜菜单。

用例结束

备选事件流

1.a登录信息错

3.a未能提交菜单

业务规则

至少选择一样菜

涉及的业务实体

Be_加菜菜单,Be_菜单

非功能性需求

只支持本店内使用

b业务场景分析

点菜业务场景分析

业务场景分析说明:

服务员登录界面通过验证之后加菜,系统记录菜单,完成之后提交订单,询问是否提交,不提交就返回到点菜,提交就打印菜单,后厨做菜,结束用例。

c业务实体分析

业务实体说明:

上图显示的是加菜的业务实体过程,顾客通过菜单进行加菜,系统记录加菜菜单。

(3)减菜

a业务说明

用例名称

bu_减菜业务

实现名称

Bur_reduceddish

用例描述

前台服务人员通过本用例减去顾客不再需要的菜

参与者

前台服务人员

前置条件

1.该顾客还未结账

2.顾客已经点过至少一样菜

3.该顾客已经点过这道菜

后置条件

记录创建减菜菜单

主事件流

1前台服务人员进入减菜业务界面

2.查处该顾客已经点的菜的菜单

3.前台服务人员将减菜名输入系统,系统生成减菜菜单

3.前台服务人员将减菜菜单保存并发送至后厨

4.系统自动打印出减菜菜单。

用例结束

业务规则

至少选择一样菜

涉及的业务实体

Be_减菜菜单,Be_菜单

非功能性需求

只支持本店内使用

b业务场景分析

业务场景分析说明:

服务员登录界面通过验证之后减菜,系统记录菜单,完成之后提交订单,询问是否提交,不提交就返回到减菜,提交就打印菜单,后厨撤菜,结束用例。

c业务实体分析

业务实体说明:

上图显示的是减菜的业务实体过程,顾客将有情况的菜取消掉,系统记录减菜菜单。

(4)结账

a业务说明

用例名称

bu_结账业务

实现名称

Bur_settleaccounts

用例描述

前台服务人员通过本用例查询顾客本次的消费

参与者

前台服务人员

前置条件

1.该顾客至少点过一道菜

2.顾客之前没有结过账

后置条件

打印该顾客的消费账单

主事件流

1前台服务人员进入结账菜业务界面

2.前台服务人员将该顾客的点菜菜单费用、加菜菜单费用和减菜菜单费用调出

3.前台服务人员通过该系统得出该顾客本次的总消费账单

4.系统自动打印出总消费账单。

用例结束

业务规则

已经点菜

涉及的业务实体

Be_点菜账单,Be_加菜账单,Be_减菜账单,Be_总消费账单

非功能性需求

只支持本店内使用

b业务场景分析

业务场景说明:

服务员进入结账菜单,系统计算消费金额,付款之后打印账单并保存。

c、业务实体分析

业务实体说明:

上图显示的是结账的业务实体过程,系统将该顾客所有的菜单加在一起,系统进行计算,最后显示总的费用。

 

3.1.2.3数据分析

(1)概览

实体之间关系说明:

各个实体之间都有一定的关系,其关系的对应通过上图可以清楚的看出。

(1)菜单

菜单

Be_菜单

实体描述

每张菜单上都有该酒店的所有菜类,以及该菜所属的菜系和价钱

属性名称

类型

精度

说明

价钱

字符

10

说明各种菜在本酒店的价钱

菜系

字符

20

例如:

鲁菜、川菜、粤菜、闽菜、苏菜、浙菜、湘菜、徽菜。

优惠策略

字符

10

说明某样菜是否打折,打几折。

菜品类型

字符

20

例如:

荤菜、素菜、汤类等。

菜名

字符

20

菜的名字

简介

字符

100

菜单上显示有本酒店的所有可以做的菜,并有本酒店推荐的菜和那些是打折的菜

(2)加菜菜单

加菜菜单

Be_加菜菜单

实体描述

记录顾客又添加的菜品,以及加菜的时间、数量

属性名称

类型

精度

说明

菜名

字符

20

所点菜的名称

价钱

字符

10

说明所加的菜的价钱

加菜时间

日期

系统自动记录时间

(3)点菜菜单

菜单

Be_点菜菜单

实体描述

记录顾客所点的菜品,以及点菜的时间、数量

属性名称

类型

精度

说明

菜名

字符

20

菜的名字

价钱

字符

10

说明所点的菜的价钱

点菜时间

日期

系统自动记录

附加说明

字符

100

所点的菜中是否有正在打折的,例如:

青椒肉丝打7.5折。

所点的菜所属的类型,例如:

鱼香肉丝属于荤菜。

所点的菜所属的菜系:

宫保鸡丁属于鲁菜。

 

(4)减菜菜单

减菜菜单

Be_减菜菜单

实体描述

记录顾客想从所点的菜中撤销的菜品,以及撤菜的时间、数量

属性名称

类型

精度

说明

菜名

字符

20

菜的名字

价钱

字符

10

说明所减的菜的价钱

减菜时间

日期

系统自动记录

附加说明

字符

100

撤菜的简单原因

(5)员工信息

员工信息

Be_员工信息

实体描述

说明员工的编号,进入该酒店的时间,离开本酒店的时间,以及该员工每月的工资,和他的所有福利,现在所担任的职务和他的权限。

属性名称

类型

精度

说明

员工编号

字符

10

员工从进入本酒店时就给其分配的固定编号

密码

字符

20

自己设定的进入系统的密码

员工权限

字符

10

员工在本酒店的权利,以及在本系统中可以阅览到的东西,和是否能够修改该类信息

员工类型

字符

10

该员工在本酒店现在所担任的职务

附加说明

字符

100

某员工是否在工作时间发生意外事故,在事故中是否有公费使用,以及使用金额等。

(6)总费用记录

总费用记录

Be_总费用记录

实体描述

记录顾客想从所点的菜的记录

属性名称

类型

精度

说明

点菜费用

字符

10

说明点菜的价钱

加菜费用

字符

10

说明所加的菜的价钱

减菜费用

字符

10

说明所减的菜的价钱

共计

字符

10

总价

3.2非功能性需求

3.2.1性能需求

因为系统本身不算大,但数据库的储存的数据量还是能够承受数据压力的,系统本身采用局域网通信速度会达到10M/s.

3.2.2安全性需求

SE-1:

所有涉及功能信息或人物权限,都要采用128位的加密。

SE-2:

用户必须登录到“酒店餐饮服务管理系统”才能完成所有操作。

3.2.3软件质量属性

AVailablity(可用性)-1:

“酒店餐饮服务管理系统”系统将在本店内营业时间所有有权限的用户都可以访问,用户早上9点到网上10点99%的时间可用。

Reliability(可靠性)-1:

如果在菜单得到提交之前,用户和系统的连接中断,那么用户应该能通过“酒店餐饮服务管理系统”恢复不完整的菜单。

3.2.4外部接口需求

本系统唯一要连接的硬件就是打印机,酒店后厨和前台都要连接,接口数据采用微软通用的就可以。

3.2.5用户界面

UI-1:

“酒店餐饮服务管理系统”的屏幕画面将遵照公司的界面标准V1.0版本。

UI-2:

系统对所显示的每个模块都有提示功能,鼠标放在上面即可显示。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 成人教育 > 专升本

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2