当前位置:文档之家› 网上订餐需求分析报告

网上订餐需求分析报告

********************
****************
网络订餐需求分析报告
******
课程名称: *********
小组成员: ************** **************
一.研究意义 (2)
市场前景 (2)
功能分析 (3)
1.顾客登录网上订餐系统进行菜单浏览 (3)
2.顾客注册为会员 (3)
3.顾客个人设置 (3)
4.顾客购物车 (4)
5.管理员后台管理 (4)
二.顶层用例示意图 (6)
三.用例分析与描述 (8)
用户登陆 (10)
订餐服务 (11)
查看历史订单 (12)
订单处理 (13)
四.类图 (14)
动态图 (14)
管理员模块 (15)
五.性能要求 (15)
1. 时间特性要求 (15)
2. 可扩充性要求等 (15)
3. 安全可靠性 (16)
4. 其它专门要求 (16)
一.研究意义 (2)
市场前景 (2)
功能分析 (3)
1.顾客登录网上订餐系统进行菜单浏览 (3)
2.顾客注册为会员 (3)
3.顾客个人设置 (3)
4.顾客购物车 (4)
5.管理员后台管理 (4)
二.顶层用例示意图 (6)
三.用例分析与描述 (8)
用户登陆 (10)
订餐服务 (11)
查看历史订单 (12)
订单处理 (13)
四.类图 (14)
动态图 (14)
管理员模块 (15)
五.性能要求 (15)
1. 时间特性要求 (15)
2. 可扩充性要求等 (15)
3. 安全可靠性 (16)
4. 其它专门要求 (16)
“饿了吗”学校网上订餐系统需求分析报告一.研究意义
随着学校学生人数的增加,学生对餐饮服务的要求更加高;许多学生不满足于学校食堂的餐饮或嫌学校食堂就餐排队时间长,而选择回宿舍点外卖,所以网上订餐及配送是一种个性化、多样化的服务产业。

随着网络技术的发展和普及,将餐饮服务与个性化、多样化服务的电子商务相结合,形成了方便、快捷、个性化的网上订餐系统,通过网上订餐,顾客不必亲临现场,便可以为自己、朋友等点一份既营养又实惠的美食。

其最大的优势在于:图文并茂,信息能够及时更新和在线查看,并有效地解决了传统就餐过程出现的排队,拥挤,信息不能及时更新的现象。

这样既节省了时间,也可以为广大学生用户提供更多选择。

市场前景
据不完全统计,我们学校有点过外卖的人数占学生总人数的90%以上,现在学生宁愿点外卖也不愿去食堂就餐的原因有如下几点。

1.大学校园食堂饭菜变化较少,而且味道不太合口。

2.大学生普遍都的懒惰心理。

3.大学食堂与宿舍距离有一定距离,大学课程比较分散。

学生去食堂就餐嫌麻烦。

所以大学校园外卖点餐系统是非常有市场前景的。

功能分析
根据对该系统的分析,该系统应具有如下功能:
1.顾客登录网上订餐系统进行菜单浏览
显示菜品的各种信息,可分类查询、动态搜索、设计页面分类、布局排版;以方便顾客浏览选择。

2.顾客注册为会员
顾客访问本,直接进入本主页。

可选择登陆,若为注册可选择注册,只有注册顾客方可点餐。

注册提供顾客名和密码,顾客名能自动检测,若已存在则提示不可用。

另外加入记住密码功能,登陆一次可在两周无需再次登陆,直接进入登陆状态。

3.顾客个人设置
自己的个人信息进行更改,比如联系。

以及账户密码。

4.顾客购物车
对已选的菜单进行更改,选择更改数量或者取消选择。

当顾客确定订餐完毕后,顾客将其提交只服务器后台点餐系统,并生成订单。

以下为顾客点餐流程:
1.菜品详细信息
显示餐品中某一餐品的详细信息,包括菜名,配料,口味,价格等,以供顾客放进自己的购物车。

2.购物车
实现对已定菜品的管理,包括增加菜品,删除菜品,修改数量。

3.提交购物车并生成订单
接受购物车信息,随即获取订单号,动态刷新顶单状态,固定时间(如30秒)完成一道菜,顾客可继续修改为完成的菜品,已完成菜品无法进行操作,顾客修改订单并保存。

4.结帐付款
选择付款方式及对此次订餐的评价。

5.结束订餐。

5.管理员后台管理
1.管理员在后台登录后,可以创建新的管理员。

2.管理员可以对餐厅网上订餐系统上的菜单进行添加、删除和修改,比如更改菜单的图片,价格,菜单的描述,更换新品,添加新菜等。

3.管理员对菜单进行管理,确定订单的生成。

4.订单提交厨房予厨师,生产菜品。

5.转交外卖派送员派送。

具体功能表:
评价
结束订单
管理员操作增加菜品
修改菜品
查看及回复留言付款操作支付方式
支付结果
配送确认配送结果二.顶层用例示意图
顾客 注册
登陆 购物车
订单信息 个人信息设

支付
评价
三.用例分析与描述
订餐用户使用图例1
管理员分为两类:一类是系统管理员用例如用例图2所示。

管理员进行的操作(后台操作)包括用户管理,信息的浏览、添加、删除、修改等等
用例图2
另一类管理员是订餐管理人员,专门负责处理用户预约的订单,用例图如图3所示。

用例图3
除了用用例图描述系统需求以外,以下用活动图对系统的主要例进行说明,更具体地描述该用例与角色的交互。

用户登陆
用户登陆图例
用户登录实现为本注册用户提供身份确认的功能,保证合法用户的应有权益。

而且是否登录也将决定用户能否订餐。

用户登录的前置条件是在登录前,用户必须完成“注册”。

订餐服务
订餐图例
在订餐服务用例中,每个用户都有个购物车,用户可以将自己选定的菜品及其数量放入到购物车中,并且随时可以查看自己预定的菜品的数量和总价格。

本用例开始前用户必须登录到系统中。

如果用例成功,顾客可以浏览自己购物车中的信息并决定是购买还是删除。

查看历史订单
查看历史订单图例
注册用户可以查看自己的历史订单,在历史订单中,可以浏览曾经订购过的菜品,对于已经送餐后的菜品,可以进行评分和信息反馈,不能重复评论,某个菜品在这里的评分会影响其在整个中的推荐指数。

订单处理
订单处理图例
处理订单的过程是订餐管理人员参与的,当前台有新的订单生成时,会自动在后台的现有订单列表中显示出来,订餐管理人员可以点击查看未处理的订单,根据实际情况进行处理,或者删除不需要的订单记录。

四.类图
动态图
管理员模块
五.性能要求
1.时间特性要求
查询服务部分:用户通过电脑提交查询命令到返回结果不超过5秒钟。

数据管理部分:提交某一数据录入到结果返回不超过5秒钟。

2.可扩充性要求等
①各种字典数据的编码要尽可能采用行业标准,自行编码也应
合乎规。

②数据库的设计应考虑可扩充性,以适应今后能对数据库中的所有信息进行及时更新。

③尽可能使用字典数据,建立字典表,一方面减少数据存储,另一方面维护容易。

3.安全可靠性
本系统运行在校园网络上,前端通过windows的浏览器进行使用,要考虑到校园网在与外部网连接的情况下可能会受到外来的安全威胁;操作员口令应采用加密存放方式,不同权限的用户对数据有不同层次的访问:禁止、浏览、修改等;要设计好系统的差异或增量备份以及操作日志。

4.其它专门要求
在程序的开发过程中,应遵循结构化的程序设计原则,设立运行日志,加强系统的可维护性;注重系统的界面友好性、各程序模块界面的统一。

相关主题