酒店餐馆管理系统用例图及规约
酒店管理用例图和活动图
房间预订用况：用况名称：房间预订参与的执行者：酒店工作人员，客户前置条件：一个合法的酒店工作人员已登录到该酒店系统事件流：1、当客户通过网上或者电话咨询该酒店并选择酒店房间预订时用况开始2、查询客户需要的房间情况，确认房间可用3、有空房则往下执行，否则结束预订4、输入客户姓名、身份证号，查询是否合法客户5、是则往下执行，否则结束预订6、登记客户入住时间7、用况结束后置条件：在管家系统中更新房间信息Check in 用况：用况名称：check in参与的执行者：酒店工作人员，客户前置条件：一个合法的酒店工作人员已登录到该酒店系统事件流：1、当客户到前台要求入住时用况开始2、输入客户身份证号询问客户姓名，确认为已预订客户3、是则跳到第六步，否则往下执行4、登记客户姓名及身份证号，查询是否合法客户5、是则往下执行，否则结束6、允许入住7、用况结束后置条件：在管家系统中更新房间信息，并跳转到账务系统建立客户账户用况：用况名称：建立客户账户参与的执行者：酒店工作人员前置条件：一个合法的酒店工作人员已登录到该酒店系统事件流：1、当允许客户入住后事件流开始2、系统自动生成一个新账号3、查询客户是否为合约客户，是则往下执行，否则跳到第5步4、输入客户房间号，姓名，身份证号，生成该客户消费账号，自动累计其消费情况并加入优惠措施5、询问客户是否愿意加入合约客户，是则往下执行，否则跳到7步6、跳到合约客户系统，新建合约客户，跳到第3步7、生成普通账户，输入客户房间号，姓名，身份证号，生成该客户消费账号，自动累计其消费情况8、用况结束后置条件：更新收银系统数据账务查询用况：用况名称：账务查询参与的执行者：酒店工作人员，客户前置条件：一个合法的酒店工作人员已登录到该酒店系统事件流：1、当客户提出check out时用况开始2、进入收银系统查询客户消费金额，查询需交金额3、收取金额4、查询需交余额是否为0，是则往下执行，否则跳到第2步5、允许check out下面是余秋雨经典励志语录，欢迎阅读。
uml 餐馆管理信息系统
用例 建模
参与者与涉众的关系
用例 建模
涉众也称干系人,是与要建设的这个 系统有利益相关的一切人和事,涉众 的利益要求会影响系统的建设。 涉众不等于用户。 涉众建议并界定了系统必须要做的 工作。用例应该满足包含所有涉众 关注点的事物。
前置条件和后置条件
前置和后置条件表示用例开始状态 和结束会发生什么
用例建模 领域建模 系统顺序图 系统契约 对象交互图 设计类图
用例建模
用例 建模
用例视图应该包含一组定义了该系统 完整功能的用例，或者至少定义了当 前迭代所规定功能的用例 用例视图应该是客户、最终用户、领 域专家、测试人员和任何其他涉及系 统的人员，不需要详细了解系统结构 和实现就容易理解的
餐馆预约系统的初始用例图
“预约日期可以选择” “顾客姓名可以选择” “可以用条码扫描器或键盘输入商品 id”
领域建模（ 领域建模（概念模型）
建立一个领域模型 领域模型——添加关联 领域模型——添加属性
领域 建模
简介
领域 建模
领域模型：显示最重要的业务概 念和它们之间的关系的类图 领域模型用关联和泛化显示了这 些概念之间的关系。领域模型通 领域模型通 常不包含操作
用例 建模
在大型平板显示器上的触摸屏界面。 在大型平板显示器上的触摸屏界面。文本信 息要能够在1 息要能够在1米之外看清 90%的信用卡授权机构的响应应该在30秒收到 的信用卡授权机构的响应应该在30 90%的信用卡授权机构的响应应该在30秒收到 ……
技术和数据的变化列表
用例 建模
技术和数据的变化列表：系统通常 有一些技术上的变化是关于“应该 怎么做”，而不是“应该做什么”， 需要在用例中将这种变化记录下来。
用例 建模
UML旅店管理系统用例图、用例规约
一.旅店管理系统用例图
二．用例规约
1.预定房间
1 .1简要说明
本用例允许客户预订旅店的未被预订的房间，系统提供未被预订的房间的信息列表。
1.2 先置条件
客户进入旅店管理系统，并选择预订房间功能。
1.3 事件流
（1）基本事件流
A 客户选择要预订的房间的类型，双人间或单人间。
B 根据客户选择的房间类型，从所有该类型房间中，筛选未被预定的房间，将这些房间的信息列表显示，供客户查询。
C 客户选定房间，并输入要预订的天数。
（2）备选事件流
A 客户所需要类型的房间已全部被预订，则提示客户，该类型房间已全部被预订，询问客户是否选择另一类型的房间。
B 用户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发生冲突，则系统提示，该房间在哪些日期里已被预订，并询问当前客户是更换房间还是修改预订天数。
1.4 后置条件
A 客户选择房间和预订天数并确认后，系统要求客户输入客户信息，包括客户的姓名、地址、联系电话、有效证件号。
另外，系统将计算出客户需要缴纳的定金和总费用，并显示出来。
B 客户重新选择房间类型，或修改天数，则刷新用户界面。
点餐管理系统用例图
点餐管理系统用例图1. 引言本文档描述了一个点餐管理系统的用例图，用于展示系统的功能和用户与系统的交互。
点餐管理系统是为了便捷、高效地管理餐厅的点餐过程而开发的。
2. 用例图概述用例图是一种用于描述系统功能和用户交互的图形化表示方法。
它包括了系统的各个用例（功能）、参与者（用户或外部系统）以及它们之间的关系。
以下是点餐管理系统的用例图：用例图用例图3. 参与者本系统包含以下参与者：3.1. 顾客 (Customer)顾客是使用点餐管理系统进行点餐和支付的用户。
3.2. 服务员 (Waiter)服务员是负责为顾客提供服务的人员。
4. 用例本系统包含以下用例：4.1. 点餐和结账 (Place Order and Check Out)该用例描述了顾客通过系统点餐并完成支付的过程。
参与者：顾客、服务员场景：1.顾客打开点餐管理系统。
2.顾客浏览菜单并选择菜品。
3.顾客选择并添加菜品至购物车。
4.顾客查看购物车中的菜品和总价。
5.顾客点击结账按钮。
6.系统生成账单并显示给顾客。
7.顾客输入支付信息并确认支付。
8.系统确认支付成功，完成点餐和结账流程。
4.2. 餐桌管理 (Table Management)该用例描述了服务员管理餐桌状态和分配顾客的过程。
参与者：服务员场景：1.服务员打开点餐管理系统。
2.服务员查看餐桌状态和空闲餐桌数量。
3.服务员分配顾客到一个空闲餐桌。
4.服务员将餐桌状态设置为已使用。
5.服务员在顾客完成用餐后将餐桌状态设置为空闲。
5. 关系用例图中的关系表示了不同用例之间的关联和依赖关系。
以下是点餐管理系统用例图中的关系：•顾客和点餐和结账用例之间存在关联关系，表示顾客通过点餐和结账来实现点餐。
•服务员和点餐和结账用例之间存在关联关系，表示服务员在点餐和结账过程中提供服务。
•服务员和餐桌管理用例之间存在关联关系，表示服务员通过餐桌管理来管理餐桌状态和顾客分配。
6. 总结本文档描述了一个点餐管理系统的用例图，包括了系统的参与者、用例以及它们之间的关系。
酒店订餐管理系统UML建模
大学软件学院《UML系统建模基础教程》大作业酒店订餐管理系统UML建模一、需求分析随着科学技术和互联网的迅猛发展，网络已经改变了我们的生活，通过网络交易成为当下的一种时尚，受到越来越多的人青睐，各个行业也将其当成一种重要的营销手段，酒店订餐管理系统也得益于网络的发展，提高了管理水平，扩大了营销围。
酒店订餐管理系统是中小型酒店餐饮企业用来对客人的订餐活动进行管理的信息管理系统。
该信息系统不仅能够为客人提供方便的订餐功能，同时也能够达到提高酒店餐饮企业管理水平的目的。
订餐系统的功能性需求包括以下容：（1）酒店的接待员使用为客人提供订餐服务，根据客人的订餐要求，在指定的时间和桌号安排好客人的就餐事宜；按客人的要求执行修改订单的操作；在客人临时取消预订时删除订餐信息；在客人订餐时间到达前，及时提供提醒服务。
（2）酒店领班在订餐客人到店用餐时和用餐离店后分别在系统做好记录并保存；能够为客人注册成为会员；可以查询、修改和删除会员信息；可以为客人提供换桌服务。
二、酒店订餐管理系统UML建模简介：基于UML建模的酒店订餐管理系统，通过用例图、类图、序列图、协作图、状态图、活动图、构件图、部署图来进行酒店订餐管理系统建模的。
三、创建系统的用例模型：(一)接待员（Receptionist）用例图：接待员用例能够通过该系统进行如下活动：（1）记录订餐信息。
接待员将客人的订餐要求输入到系统中保存。
（2）订餐定时提醒。
接待员在客人的预定的订餐时间之前给客人一个提醒，同时再次加以确认。
（3）取消订餐记录。
客人因临时原因取消订餐，接待员将系统中原来的订餐信息取消。
用例规约：用例名称记录订餐顾客(二)领班（Captain）用例图：领班用例能够通过该系统进行如下活动：（1）记录订餐客人到店。
领班在有预订的客人前来酒店就餐时，在系统中记录预订客人已到店的信息并保存。
（2）记录订餐客人离店。
领班在预订的客人用餐离店后，在系统中记录预订客人用餐完毕的信息并保存，表示整个订餐过程结束。
餐饮管理系统图2016.1.15
结果： 出品
生产区 值班人员
对对讲机沟通的 信息作出反应
将沟通信息反馈 给相应区域人员
各区域 人员
按照岗位安排， 坚守岗位
根据值班人员告 知的信息，检视 存货量，并制作 产品
制作好产品，将 产品放置出菜处
出菜人员
受影响 系统： 服务
出菜
成功关键要素
1.各区域人员坚守岗位 2.所有工作岗位都按照每日营业 额预估值存货 3.餐厅经理确保按标准执行程序 4.维持存量表与存货量相符 5.值班经理对危险区域作出适当 回应
检查即将推 出的促销活 动以确定产 品需求
从物流中心 订购产品， 确保储存区 整齐有序
餐厅副理
检视补齐式 存量表，并 准备产品
餐厅副理
安排员工接 货，确定物 流送货行程
收到货品时， 检查产品是 否正确，品 质和状况是 否良好
员工
产品存放适当（位 置、安全、轮替），
锁好相隔较远的干 货间
副经理
计算使用量、 库存量
服务系统图
“我们很自豪能够创 造独一无二的服务体 验，让所有人都感到 受欢迎和受重视”
餐厅经理
1.确保建立并遵循重新赢回顾客程序 2.树立卓越的服务体验并以身作则 3.确保服务区经过规划与标识方便使用
服务经理
1.树立卓越服务体验的榜样 2.确保员工坚守岗位 3.确保向服务团队提供正确的回馈（表 扬、教练、纠正）以提高绩效
4.合理应对危险区（顾客在明档排队超 过3分钟、等候区排队超过3桌） 5.确保整体顾客满意
迎宾员/ 服务员
欢迎（服务六声）
领位
询问用餐人数
专心聆听顾客说话 清楚有效地沟通
预结账
解说温馨提示
值班经理
酒店餐馆管理系统用例图及规约
酒店餐馆管理系统⽤例图及规约由图可见，该⽤例图包括8个⽤例、5个参与者。
⽤例图的编号和名称是：1.注册与登录，2.个⼈信息管理，3.⾷品管理，4.餐台管理，5.核准菜单，6.产⽣报表，7.采购消费信息处理，8.消费统计。
参与者的名称：顾客，前台客服，厨房⼯作⼈员，采购员，收银员。
⼆、⽤例规约1.注册与登录1.1 简要说明本⽤例⽤于向顾客提供注册功能和注册后的登陆以及前台客服的登陆。
每位顾客必须注册后才能登录系统内订餐。
注册信息包括使⽤本系统的账号、密码、联系地址和电⼦邮件等。
注册完成后，可登录餐馆管理系统，系统将会保存这些信息，以⽅便管理及联系⽤户。
1.2 事件流1.2.1 基本流当顾客进⾏注册时，开始执⾏以下基本流：（1）系统要求顾客填写个⼈信息，包括使⽤本系统的账号、密码、联系地址、信⽤卡卡号、信⽤卡有效期和电⼦邮件等。
（2）顾客填写个⼈信息。
（3）系统验证顾客所填写的信息的格式和内容。
（4）保存该顾客信息。
（5）顾客进⼊登陆界⾯进⾏登录。
1.2.2 备选流1.2.2.1 顾客信息验证错误如果系统检测到顾客输⼊的信息格式或内容有错，例如账号中含有⾮法字符、输⼊密码和确认输⼊密码不⼀致，会给予错误提⽰，并清空填写错误的⽂本框，要求顾客重新输⼊。
1.2.2.2 顾客信息保存失败如果系统发现数据库中已经保存了同样账号的顾客记录，会向顾客报告保存失败的错误信息，并使页⾯跳回注册页⾯，要求顾客修改注册信息。
1.3 特殊需求⽆。
1.4 前置条件顾客必须⾸先访问餐馆管理系统的页⾯，然后单击注册、登录。
1.5 后置条件如果该⽤例成功，系统数据库中将增加⼀条该顾客的信息。
否则，系统维持原状。
1.6 扩展点⽆。
2.个⼈信息管理2.1 简要说明顾客注册完成后登陆系统进⾏订餐操作，同时前台客服也要登陆系统进⾏顾客信息和点餐信息的管理。
顾客登录进⼊餐馆个⼈信息管理系统页⾯后，通过查看基本信息以后，顾客可以进⾏信息的⼀些补充。
餐馆系统用例及用例图
•记录预约(Recork booking)事件路径：1接待员输入要预约的日期2系统显示该日的预约3有一张合适的餐桌可以使用：接待员输入顾客的姓名、电话、预约的时间、用餐人数和餐桌号4系统记录并显示新预约。
可选或例外的事件路径3a 没有可用的餐桌:1 没有合适的餐桌可以使用，用例终止3b 餐桌过小1 接待员输入顾客的姓名电话预约时间，用餐人数和餐桌号2 用餐人数多于餐桌容纳的人数，系统询问是否继续预约3 如果回答“否”, 用例将不进行预约而终止4 如果回答“是”, 预约将被输入，并附有一个警告标志。
•记录到达：(Record arrival)基本事件路径１领班输入当前日期２系统显示当天的预约３领班确认一个选定的预约已经到达４系统对此进行记录并更新显示器，将顾客标记为已经到达。
可选或例外的事件路径3a 没有提前预订：1 系统中没有记录该顾客的预约，领班输入预约时间、人数和餐桌号，创建一个未预约登记；2 系统记录并显示新预约//将红字的部分，独立为一个用例，用例描述如下：●记录未预约顾客(Record walk_in)基本事件路径1 侍者领班执行“显示预约”用例2 侍者领班输入时间、用餐人数和分配给顾客的餐桌3 系统记录并显示新预约●取消预约(Cancel booking)基本事件路径1 侍者领班执行“显示预约”用例2 接待员选择要求的预约3 接待员取消该预约4 系统询问接待员确认取消5 接待员回答“是”，系统记录取消并更新显示可选或例外的事件路径4a 预约的时间是在该现时间之前1 系统显示，预约的时间是在该查询时间之前，2 系统显示不能取消过去某段时间的预约4b 已经记录了顾客到来的预约1 系统显示不能取消该预约 调换餐桌（Table transfer）基本事件路径1 侍者领班选择需要的预约2 侍者领班改变该预约的餐桌分配3 系统记录改变并更新显示•显示预约（Display Bookings）:1用户输入一个日期2系统显示当日的预约。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
由图可见，该用例图包括8个用例、5个参与者。
用例图的编号和名称是：1.注册与登录，2.个人信息管理，3.食品管理，4.餐台管理，5.核准菜单，6.产生报表，7.采购消费信息处理，8.消费统计。
参与者的名称：顾客，前台客服，厨房工作人员，采购员，收银员。
二、用例规约1.注册与登录1.1 简要说明本用例用于向顾客提供注册功能和注册后的登陆以及前台客服的登陆。
每位顾客必须注册后才能登录系统内订餐。
注册信息包括使用本系统的账号、密码、联系地址和电子邮件等。
注册完成后，可登录餐馆管理系统，系统将会保存这些信息，以方便管理及联系用户。
1.2 事件流1.2.1 基本流当顾客进行注册时，开始执行以下基本流：（1）系统要求顾客填写个人信息，包括使用本系统的账号、密码、联系地址、信用卡卡号、信用卡有效期和电子邮件等。
（2）顾客填写个人信息。
（3）系统验证顾客所填写的信息的格式和内容。
（4）保存该顾客信息。
（5）顾客进入登陆界面进行登录。
1.2.2 备选流1.2.2.1 顾客信息验证错误如果系统检测到顾客输入的信息格式或内容有错，例如账号中含有非法字符、输入密码和确认输入密码不一致，会给予错误提示，并清空填写错误的文本框，要求顾客重新输入。
1.2.2.2 顾客信息保存失败如果系统发现数据库中已经保存了同样账号的顾客记录，会向顾客报告保存失败的错误信息，并使页面跳回注册页面，要求顾客修改注册信息。
1.3 特殊需求无。
1.4 前置条件顾客必须首先访问餐馆管理系统的页面，然后单击注册、登录。
1.5 后置条件如果该用例成功，系统数据库中将增加一条该顾客的信息。
否则，系统维持原状。
1.6 扩展点无。
2.个人信息管理2.1 简要说明顾客注册完成后登陆系统进行订餐操作，同时前台客服也要登陆系统进行顾客信息和点餐信息的管理。
顾客登录进入餐馆个人信息管理系统页面后，通过查看基本信息以后，顾客可以进行信息的一些补充。
在预定结束时，顾客需要填写一些相关资料以形成顾客订单信息保存在该餐馆管理系统的顾客信息库中。
2.2 事件流2.2.1 基本流当顾客登录到餐馆管理系统后，开始执行以下基本流：（1）顾客进入个人信息页面后，浏览个人信息。
（2）顾客补填有关其个人资料的表单并将本次就餐人数与就餐时间填写清楚。
（3）当顾客填写完所有的信息后，经确认后提交有其顾客订单信息的表单。
（4）系统经过验证后，反馈给顾客验证信息，同时将顾客信息连同顾客选定的饭菜信息一并存入顾客信息库。
2.2.2 备选流2.2.2.1 顾客账号不存在当顾客在预定结束时填写个人资料后，系统经过验证后，发现该顾客账号不在该餐馆管理系统的顾客信息数据库中，系统反馈一个错误信息给顾客，让顾客重新填写相关个人资料。
2.3 特殊需求无。
2.4 前置条件顾客要想订餐，必须先登录到该餐馆管理系统中；若没有顾客账号，则该顾客还需要现在该系统中注册一个顾客账号。
2.5 后置条件该用例实现后，顾客信息的情况就通过顾客订单信息被保存在了系统的顾客信息库中，由系统对此进行统一的管理；反之，系统的顾客信息库中的信息不发生任何的改变。
2.6 扩展点无。
3.食品管理3.1 简要说明顾客登陆系统补充万个人信息后进行订餐操作，同时前台客服也可登陆系统进行顾客点餐信息的管理。
顾客登录进入餐馆食品管理系统页面后，通过查看菜单信息以后，顾客可以进行选择要点的饭菜，并将菜单信息传给产生报表系统和核准菜单系统。
3.2 事件流3.2.1 基本流当发送订货通知时，系统开始执行以下基本流：（1）顾客进入选餐页面后，浏览所有的菜单信息。
（2）顾客对选定的饭菜，下订单。
（3）系统将点餐订单交给核准菜单系统和产生报表系统。
3.2.2 备选流3.2.2.1 订餐通知发送失败由于网络或各种原因向采购部门发送的订货通知发送失败，系统会提示失败字符。
3.2.2.2 取消发送订餐通知若取消发送订餐通知，则系统销毁该订单。
3.3 特殊需求无。
3.4 前置条件顾客要想订餐，必须先登录到该餐馆管理系统中；当顾客补充信息保存后，该顾客才能进入食品管理系统进行点菜。
3.5 后置条件该用例实现后，顾客预定饭菜的情况就通过该系统传给核准菜单系统和产生报表系统；反之，系统不向其他系统发送任何的信息。
3.6 扩展点无。
4.餐台管理4.1 简要说明本用例是用来确定顾客餐台信息之用。
当顾客提交了顾客信息单后，系统与餐台信息库进行连接，通过检测若有满足的餐台类型，则直接反馈给顾客他们的餐台信息（包括餐台类型和餐台号等）；若发现顾客所需的餐台类型暂时没有空台时，系统反馈信息给顾客，让顾客进行一些选择（比如是调整就餐时间还是分开就坐等）。
4.2 事件流4.2.1 基本流当接收到顾客信息单信息时，开始执行以下基本流：(1)根据顾客细信息单信息，连接餐台信息库。
(2)根据就餐时间和就餐人数对比餐台数据库，确定餐台号。
(3)向顾客发送反馈信息，给定餐台号。
4.2.2 备选流4.2.2.1 餐台无空缺若发现顾客所需的餐台类型暂时没有空台时，系统反馈信息给顾客，让顾客进行一些选择（比如是调整就餐时间还是分开就坐等）。
4.3 特殊需求无。
4.4 前置条件顾客个人信息和就餐时间就餐人数必须已经填写完成并提交，被保存至顾客信息库。
4.5 后置条件如果该用例成功，会生成通知顾客的反馈信息。
否则，系统维持原状。
4.6 扩展点无。
5. 核准菜单5.1 简要说明本用例是用来确定顾客菜单信息之用。
当顾客提交了点餐信息单后，系统与食品库存清单进行连接，通过检测若全部能够满足，则直接打印出菜单交给厨房工作人员，并将该菜单信息传给产生报表系统；若发现有不能满足的食品，则将核准后的菜单交由厨房工作人员与产生报表系统。
5.2 事件流5.2.1 基本流当核准菜单系统收到食品管理系统传来的菜单信息以后，开始执行以下基本流：（1）检查菜单信息。
（2）连接食品库存清单。
（3）进行对比，确定核准后菜单。
（4）打印出核准后菜单，交由厨房工作人员并将核准菜单传给产生报表系统。
5.2.2 备选流无。
5.3 特殊需求无。
5.4 前置条件顾客必须提交了订餐信息。
5.5 后置条件如果该用例成功，则打印出菜单交给厨房工作人员，并将菜单传给产生报表系统。
否则，系统维持原状。
5.6 扩展点无。
6. 产生报表6.1 简要说明对比原始菜单和核准后的菜单，确定是否需要食品采购，如若需要采购，则产生采购清单，并将采购清单交由采购员，同时将采购单信息传给采购消费信息处理系统6.2 事件流6.2.1 基本流当产生报表系统收到原始菜单和核准后的菜单时，开始执行以下基本流：（1）系统对比原始菜单和核准后的菜单。
（2）如需采购，打印出采购清单给采购员，让采购员去采购。
（3）将采购信息传给采购消费信息处理系统。
6.2.2 备选流6.2.2.1 打印失败由于网络或各种原因没有出处数据导致打印失败，系统会提示失败字符，重新进行打印。
6.3 特殊需求无。
6.4 前置条件原始菜单和核准后的菜单必须都已经传入产生报表系统。
6.5 后置条件如有需要，则打印出采购清单交给采购员并同时将采购信息交给采购消费信息处理系统。
6.6 扩展点无。
7.采购消费信息处理7.1 简要说明采购信息进入该系统，该系统连接食材价格表，对采购花费进行统计，并将花费消息进行统计存入财务数据库。
7.2 事件流7.2.1 基本流当采购信息进入该系统时，开始执行以下基本流：（1）该系统连接食材价格表。
（2）对比采购信息和食材价格表，统计出采购花费信息。
（3）将采购花费信息存入财务数据库。
7.2.2 备选流7.2.2.1 食材价格表连接失败由于网络等原因，无法连接食材价格表。
进行再次连接或者稍后重试。
7.2.2.2 采购花费信息存入失败由于网络或者线路问题，存入失败，系统提示错误信息，系统进行重传。
7.3 特殊需求无。
7.4 前置条件采购信息必须进入该系统。
7.5 后置条件该用例成功，则财务数据库存入一条新的信息，否则，系统数据库维持现状。
7.6 扩展点无。
8.消费统计8.1 简要说明该系统连接食材价格表，和核准后菜单进行对比，计算出顾客消费情况，并将顾客消费情况传给收银员，同时将信息存入财务数据库。
8.2 事件流8.2.1 基本流当核准后菜单进入该系统时，开始执行以下基本流：（1）该系统连接食材价格表。
（2）对比食材价格表和核准菜单，计算出顾客消费情况。
（3）将顾客消费情况传给收银员。
（4）将顾客消费情况存入财务数据库。
8.2.2 备选流8.2.2.1食材价格表连接失败由于网络等原因，无法连接食材价格表。
进行再次连接或者稍后重试。
8.2.2.2 顾客消费信息存入失败由于网络或者线路问题，存入失败，系统提示错误信息，系统进行重传。
8.3 特殊需求无。
8.4 前置条件核准菜单必须进入该系统。
8.5 后置条件该用例成功，则财务数据库存入一条新的信息，否则，系统数据库维持现状。
8.6 扩展点无。
三补充规约1.目的本补充规约列出了餐馆管理系统的非功能性需求和部分全局性需求。
它和用例模型在一起，组成了完整的系统需求规格说明书。
2.范围本说明书除定义了许多用例中共有的功能性需求以外，还定义了系统的非功能性需求，如可靠性、可用性、系统性能和可支持性等。
3.参考无4功能性4.1满足多个顾客的并发执行。
4.2当顾客预定饭菜时，系统必须判断该食品是否还有剩余，若该食品已无库存，需提醒顾客，并通知采购部门进行采购。
5 可用性顾客界面视窗与WINDOWS系统兼容。
6. 可靠性保证系统在配置完成以后24小时都可用，平均无故障时间应超过300小时。
7.性能7.1 该系统应支持多达1000名顾客在任意特定时间使用中央数据库，并支持多达500名顾客在任何时候访问本地服务器。
7.2 系统要求对数据库的访问，存取速度要快，特别是对食品目录的访问的反应时间要在8秒内8. 可支持性无。
9. 安全性系统要求有较高的安全性，由于在管理订单时，顾客的信息都在网络上传输，所以必须提供额外的安全性措施。
10 设计约束无。
四术语表1.简介本文档用来对一些术语进行定义，同时对用例说明或其他文档中读者不太熟悉的术语进行解释性的描述。
2.名词定义这份术语表包含了餐馆管理系统的重要概念。
2.1 顾客：指每个使用该餐馆管理系统进行预定的人和每个到餐厅吃饭时登记的人。
2.2 前台客服：负责接待顾客和管理输入顾客的个人信息及点餐信息。
2.3 厨房工作人员：餐馆的工作人员，包括核准菜单打印人员和厨师以及传菜生。
2.4 收银员：顾客就餐结束时的接待处理人员，负责顾客的结账管理。
2.5 食品：餐馆供应的一切食物（包括主食、零食以及酒水等）。
2.6 个人信息：用户注册时填写的信息。
2.7 食品信息：食品的名称、价格、所属类型和现有数量等信息。