凭栏听雨菜品信息
描述：用来描述一道菜的相关信息 别名：菜品
组成：菜名编号 + 菜名 + 单价 菜谱表
描述：用来描述系统中所有菜品信息 别名：菜谱
组成：由菜品信息构成的一个表 餐桌表
描述：用来描述餐厅当前所有餐桌的使用信息 别名：无 组成：餐桌信息 餐桌信息
描述：用来描述餐厅当前某一餐桌的使用信息 别名：无
组成：餐桌编号 + 餐桌占用信息
等待配菜员处理的json格式订单队列
描述：用来描述由配菜员处理的json格式订单队列 别名：订单队列
组成：json格式订单+桌号
3.2 数据结构
数据结构用于实现在计算机中的存储和处理，有别于数据字典。
用户表
描述：用来描述就餐会员用户信息 别名：无
组成描述：用户ID+用户名+桌号+订单状态+账单状态+就餐时间
菜谱表
描述：用来描述系统中所有菜品信息 别名：无 组成描述：库存表 账单表
描述：用来描述系统中所有消费记录 别名：无
组成描述：账单编号+菜品信息+消费总价+订单时间 餐桌表
描述：用来描述餐厅当前所有餐桌的使用信息 别名：无
组成描述：由餐桌信息构成的一个顺序表
订单
描述：用来描述某一餐桌的用餐信息 别名：无
组成描述：账单编号 + 菜品编号+菜品名+菜品价格+菜品数量+ 菜品总价+ 确认订单时
间 + 确认完成时间 + 订单标志位
订单队列
描述：用来描述由厨房前台端系统处理的订单信息的队列 别名：无
组成描述：由订单构成的一个队列
3.3 数据流程图
客人或服务员
使 用
餐厅前台端系统 点 信息 结账 信息 更 单 回执 查询 信息回执 催单 信息回执 回执 新 菜 订单 餐桌编号 餐桌编号 餐桌编号 谱 发 查询 信息 催单 信息 结账 单 信息回执 回执 回执
信息回执 更新队列 服务器后台端系统 信息回执 查 数据库更新 服务 询 器端 订单 餐 队列 更 下 回 回 回 催 回 桌 新 . 数据库 表
单 执 单 执 单 执 厨房系统
完成 确认 催 信息 订单 订单 单 回执
厨房端订单队列
4. 系统要求
4.1 性能要求
系统必须有很高的运作效率，用户填写的订单在输入到系统后，系统必须快速及时地做出响应，迅速地处理有关信息，显示出所有必须的信心并打印出各项清单；由于需要存储大量用户的信息，所以系统必须有足够大的存储容量；系统必须能够承受各种不确定因素以保护存储的信息的安全，并能够准确记录各种内部事件；系统可靠性也是系统最为重要的性能要求之一，要求在意外因素之下，系统仍然能够保护系统和存储的信息的完整。
4.2 体验要求
接口是用户与系统进行通信的主要通道，因此，接口除了完备的功能外，还必须简洁明
了，方便用户的使用，这样才能提高餐厅的工作效率，继而为餐厅节省了不必要浪费的时间。
必须使用户能准确快速地进行信息输入，从而使得用户与系统之间的通信时间尽可能地
缩短。
系统必须能准确快速地打印出各类清单。
5.意外处理
出错信息 入座不成功 提交订单错误 结账金额错误
显示可选桌号 提示检查订单格式内容 检查是否有菜品没上 错误处理 6可行性要求
6.1技术可行性
本系统是基于linux基础上研发的，目前采用linux和sqlite3作为后端，安卓为前端的
技术已经很成熟，并且linux和sqlite3相关的技术支持很多，所以在技术可行性方面不存在问题。
在前端，采用安卓操作系统带来了更加稳定和易用的技术，并且安卓具有节省资源和成
本的优势。
6.2经济可行性
基建投资：
需要一个PC终端，即一台联想商务电脑，windowsXP或win7操作系统，一台惠普商用
打印机，还要一个数据库管理系统，多个小型终端（可以是平板电脑），总计5万左右。
其它一次性支出：
项目 可行性分析以及需求研究 开发设计 测试基准 转化原有的数据库 总价
经常性支出（五年）：
PC终端和各个客户端的维护，网络的维护，再加上一些其他的不可预知的费用，大概
价格（万元） 1 2 1 0.5 4.5 要5.5万左右。
支出总计：5 + 4.5 + 5 .5 = 15 万元
6.3法律可行性
本系统采用的均是开源资源，所以除了在硬件上有成本支出外，在软件方面上不存在法
律风险。
7. 结论意见
经过上面的可行性研究分析，该项目在操作性、技术可行性、经济可行性、法律可行性
上军满足要求。因此，开发此系统的构想是可行的，可以着手实施。
