软件工程课程设计—餐厅点餐系统详细设计.doc

软件工程课程设计 餐厅点餐系统详细设计 姓 名： 院 系： 学 号： 专业班级： 指导老师： 2011 年 6 月 11 日 目录 1、引言 1 1.1编写目的 1 1.2编写背景 1 2、可行性研究 1 2.1 要求 1 2.2 目标 1 2.3 可行性研究方法 1 2.4 决定可行性的主要因素 2 3、需求分析 2 3.1现状 2 3.1.1用传统手工流程的餐饮企业面对的是 2 3.1.2正在使用着餐饮软件的企业面对的是 2 3.1.3内部矛盾分析 3 3.2竞争优势 4 3.2发展前景 5 4、 总体设计 6 4.1 启动系统 6 4.2登陆系统 6 4.3退出系统 6 4.4用户管理 6 4.4.1用户修改个人信息 6 4.4.2用户管理 7 4.4.3 新增用户 7 4.4.4删除用户 7 4.4.5修改用户 7 4.5菜单信息管理 8 4.6自动排序功能 8 4.7提交用户需求及缴费 8 4.8数据库备份 8 4.9数据库同步 8 4.10服务器端日结 8 5、详细设计 9 5.1客户端（顾客） 9 5.2客户端（服务员） 10 5.3客户端（厨师） 10 5.4后台管理 11 5.5服务器 11 6、软件测试 11 7、后记 11 1、引言 1.1编写目的 软件可行性研究报告的编制是为了使用户和软件开发者双方对该软件的初 始规定有一个共同的理解,使之成为整个开发工作的基础. 1.2编写背景 旨在改善就餐厅餐环境，缓解就餐高峰期点餐顾客等待时间过长的问题，运用高科技点餐，突破原有的餐厅服务模式，吸引更多的客户。 2、可行性研究 2.1 要求 主要功能:将餐厅点菜自动化、自由化、个性化 功能需求: 面向经理:后台管理(访问权限，修改菜单，增加菜项，删除菜项，销售情况分析) 面向顾客:显示特色菜，菜单列表，具体菜名查询（显示实际图片），订餐功能，预计等待时间银行卡消费并打印座位凭条(顾客服务员一式两份)及消费凭条 面向服务员:顾客消费结算功能 面向厨师:显示当前任务功能 性能要求: 管理员录入的信息必须无差错地存储至中心服务器，且对客户端的数据应该及时进行更新。 输出要求:数据完整，详实。 输入要求:方便，简捷，快速。 安全与保密要求: 餐厅顾客和厨师以及服务员只有查询和建议功能 管理人员则拥有在其权限内的查询，修改，增加，删除菜单，制定价格等一些管理功能。 2.2 目标 为各大中小型餐厅酒店提供一个统一、方便、安全的信息管理平台. 2.3 可行性研究方法 可行性研究的方法是通过对各大中小型餐厅、酒店管理者进行问卷调查及访问谈话而得到用户对此系统的信任度关注度及依赖度的，通过建模分析，得出了该系统的功能需求，成本分析，可行性分析。 2.4 决定可行性的主要因素 成本/效益分析结果，效益成本。技术可行，现有技术可完全承担开发任务。操作可行，软件能被原有工作人员快速接受。 3、需求分析 3.1现状 顾客：一些生意较好的餐厅人往往比较多，点个菜都要等好久，更别提什么时候能吃上了。 服务员：有的顾客比较挑剔，点菜的时候会对各种菜问个究竟，有的顾客拿点菜迟迟不定主意，人多的时候根本忙不过来。 厨师：刚做完一道菜，同样的菜又要做一份，效率很低，顾客的等待时间也会延长。 经营者：希望有这么一个系统，合理得分配调节，也使顾客就餐更加自主 3.1.1用传统手工流程的餐饮企业面对的是 舞弊：收银员舞弊 等客人结完帐在退菜品，退的钱自己收下；结完账把原始单销毁，多的钱可以自己收下；算错多收钱自己可以收下；茹果收银软件存在漏洞，那就会更危险。酒水员舞弊 退客人的酒水，销售自己带的酒水，获取暴利。 跑单：因上菜速度慢，客人催菜，服务员去厨房催菜，客人趁机走人；或者因上菜慢随最后上来但客人拒绝付款。 错单：厨师看不清单子，做错菜；服务员催的急有时会做重菜；做菜速度慢，菜品被客人退回。 丢单：手写单到厨房的只有一联，各个档口都会抢着用单子，忙时往往会丢单；餐饮软件不稳定就会有丢单现象，丢单是餐饮界“兵家大忌”。 效率低：收银部、传菜部、厨师部、库房等采用手写单据，财务部要核对手写单据，费时费力。 3