网上订餐系统功能需求分析报告
外卖系统分析分析报告
1、项目名称餐饮店的外卖订餐系统平台的建设2、项目背景（1）网上订餐的市场背景随着越来越多的人接受了电子商务这种便捷、快速的交易形式，网上订餐的顺势而出很快受到了大家的欢迎。
互联网的应用以普及千家万户,这为网络订餐提供了良好的发展空间。
同时，网上订餐服务的直观、有效、便捷等优点是传统的电话订餐业务无法比拟的。
调查数据显示，诸多白领更乐于选择网上订餐服务,网上订餐将是白领一族捕获餐店信息、进行订餐的发展趋势。
（2）网上订餐的市场优势网络订餐可通过色彩、图片、阐明、设立动画加强产品的宣传，大大达成了餐饮业的规定。
实现产品管理方便，起到立竿见影的效果，不用由于更改菜色而重新印刷。
只要在后台鼠标轻轻一点，全线立刻更新。
3、项目目的网上订餐系统是顾客实现网络交易的一种方式，含有和谐直观的界面，安全快捷的支付方式，让卖家第一时间收到订单信息，让顾客第一时间内获取外卖信息，为顾客提供更高质量的服务。
既节省了时间，又让顾客觉得方便、快捷，又对每个订单的信息保管妥善、解决及时，实现高度智能化管理，令订餐更快捷，便利，交互方便。
4、项目内容系统制作分为前台和后台。
前台重要涉及的对象是网站的顾客.（1）登陆和注册：登陆是为老客户服务的，注册重要是为新顾客准备的。
（2）菜品展示：重要展示本店的特色菜品的详情图，让顾客能更直观的理解选择自己喜欢的。
（3）前台信息：前台顾客能够任意浏览本店的菜品更新信息，并能够对菜品进行评价。
（4）外卖公示：能够对本店的某些外卖优惠活动进行公布，以及优惠的具体时间。
（5）查询模块：顾客能够对本店的喜欢的菜品进行查询，然后能够在评论区理解其它顾客的体验状况。
（6）联系我们：重要用于反馈某些菜品和其它服务的有关建议，让我们懂得局限性，不停改善提高，同时公示出本店的联系电话、地址以及配送时间，让顾客能够随时联系。
后台重要涉及的对象是网站的管理员：（1）登陆模块：重要用于管理员登陆使用。
（2）顾客注册信息管理模块：重要是进行审核管理，涉及网站的注册信息。
(完整版)网上订餐需求分析
************************************网络订餐需求分析报告******课程名称： *********小组成员： ************** **************一．研究意义 (2)市场前景 (2)功能分析 (3)1.顾客登录网上订餐系统进行菜单浏览 (3)2.顾客注册为会员 (3)3.顾客个人设置 (3)4.顾客购物车 (3)5.管理员后台管理 (4)二．顶层用例示意图 (5)三．用例分析与描述 (7)用户登陆 (9)订餐服务 (9)查看历史订单 (10)订单处理 (11)四．类图 (12)动态图 (12)管理员模块 (12)五．性能要求 (13)1. 时间特性要求 (13)2. 可扩充性要求等 (13)3. 安全可靠性 (14)4. 其它专门要求 (14)一．研究意义 (2)市场前景 (2)功能分析 (3)1.顾客登录网上订餐系统进行菜单浏览 (3)2.顾客注册为会员 (3)3.顾客个人设置 (3)4.顾客购物车 (3)5.管理员后台管理 (4)二．顶层用例示意图 (5)三．用例分析与描述 (7)用户登陆 (9)订餐服务 (9)查看历史订单 (10)订单处理 (11)四．类图 (12)动态图 (12)管理员模块 (12)五．性能要求 (13)1. 时间特性要求 (13)2. 可扩充性要求等 (13)3. 安全可靠性 (14)4. 其它专门要求 (14)“饿了吗”学校网上订餐系统需求分析报告一．研究意义随着学校学生人数的增加，学生对餐饮服务的要求更加高；许多学生不满足于学校食堂的餐饮或嫌学校食堂就餐排队时间长，而选择回宿舍点外卖，所以网上订餐及配送是一种个性化、多样化的服务产业。
随着网络技术的发展和普及，将餐饮服务与个性化、多样化服务的电子商务相结合，形成了方便、快捷、个性化的网上订餐系统，通过网上订餐,顾客不必亲临现场,便可以为自己、朋友等点一份既营养又实惠的美食。
(完整版)网上订餐系统需求分析报告.docx
网上订餐系统需求分析报告—— 08 信计三班一产品介绍：1产品名称：糖果网上订餐系统2产品概述：在网络技术快速发展的今天，原先普通的电话预定餐厅已经不能满足的功能需求。
网络越来越贴近生活，本产品通过网络订餐方便商家客户互动。
用户通过注册登陆的方式能及时看到餐饮商家更新的信息，包括就餐环境，座位信息，菜肴信息等，可以预定台位，就餐后可添加用户反馈。
商家可及时更新信息，查看预定，处理订单，通知客户订单确认。
系统管理员可以维护更新发布消息，还可以产生餐厅排行榜，财务管理，菜谱管理等一些辅助功能。
3面向用户：各大餐饮服务业，订餐客户二产品需求：根据本产品功能及客户需求，产品需求叙述如下：1 用户注册可选择登陆，若未注册可选择注用户访问本网站直接进入本网站可直接进入网站主页，册，只有注册用户方可点餐，用户分为三类：普通用户：只能登陆查询餐厅菜肴信息，不能订餐；实名认证用户：可以查询信息，可以订餐，但是订餐总金额及订餐数目有限制，并享受一部分商家优惠。
VIP 用户：可以查询信息，订餐不受任何限制，可享受更多商家优惠，但分季度收取会员费用。
注册提供用户名，密码邮箱等信息。
实名认证用户及 vip 还需要身份证，住址等更为详细信息。
.2登陆3查看餐厅信息显示餐厅的各种信息，包括餐厅名称 ,ID 图片文字说明。
可在分类查询，动态搜索，设计页面分业，布局排版问题，以方便用户浏览选择，用户再找到自己喜欢的餐厅后，点击餐厅图片进入此餐厅信息页面，内容有餐桌信息和菜肴信息，可分别点击进入餐桌及菜肴的选择。
4查看餐桌信息用户再点击进入餐桌信息后，可以查看剩余餐桌图片，编号，找到自己喜欢的餐桌可以点击确定，还可以根据就餐人数，分类查询，动态搜索。
5查看菜肴信息用户再点击进入菜肴信息后，可以查看所有菜肴信息，包括名称口味图片编号价格等，找到自己喜欢的菜肴可以点击确定，还可以根据就餐爱好，分类查询，动态搜索。
6 订餐确认用户在选择餐厅座位及菜肴后，可点击确定，系统根据用户选择会自动生成订单信息，包括订单 ID 用户名餐厅 ID 餐厅名称餐桌 ID 菜肴 ID 菜肴名称等。
校园网上订餐系统需求说明书分析报告
校园网上订餐系统需求说明书分析报告
自查报告。
为了确保校园网上订餐系统能够满足用户的需求，我们对系统进行了自查，并撰写了以下报告。
1. 用户需求分析。
我们首先对用户需求进行了分析。
通过调研和访谈，我们了解到用户希望能够通过校园网上订餐系统方便地浏览菜单、下单、支付和配送。
他们也希望系统能够提供多样化的餐饮选择，并且能够方便地查看订单状态和历史订单信息。
2. 系统功能分析。
在系统功能分析方面，我们对系统的菜单浏览、下单、支付和配送流程进行了详细的分析。
我们确保系统能够提供用户友好的界面，方便用户浏览菜单和下单，并且能够支持多种支付方式。
我们也确保系统能够及时更新订单状态，并提供配送跟踪功能。
3. 技术实现分析。
在技术实现方面，我们对系统的架构和技术选型进行了分析。
我们选择了稳定可靠的服务器和数据库，并采用了先进的前端和后端开发技术，以确保系统能够稳定运行并且具有良好的性能。
4. 安全性分析。
在安全性方面，我们对系统的数据加密、用户认证和支付安全进行了分析。
我们确保系统能够保护用户的个人信息和支付信息，并且能够防范常见的网络安全威胁。
通过以上自查报告，我们确认校园网上订餐系统已经满足了用户的需求，并且具有良好的功能性、技术实现和安全性。
我们将继续监测系统的运行情况，并及时进行改进和优化，以确保系统能够持续满足用户的需求。
校园网上订餐系统需求说明书分析报告
校园网上订餐系统需求说明书分析报告
自查报告。
在设计校园网上订餐系统的需求说明书时，我们团队进行了自查，以确保系统能够满足用户的需求并提供良好的用户体验。
以下是我们的自查报告：
1. 用户需求分析，我们对校园学生和教职员工的订餐需求进行了深入的调研和分析，确保系统能够满足他们的各种用餐需求，包括早餐、午餐、晚餐以及特殊饮食需求。
2. 系统功能需求，我们对系统的各项功能进行了详细的规划和设计，确保用户可以方便地浏览菜单、下单、支付和评价餐品，同时商家可以管理菜单、订单和库存等。
3. 界面设计，我们进行了多轮的界面设计和测试，以确保用户界面简洁直观、操作流畅，提升用户体验和易用性。
4. 安全性和隐私保护，我们重视用户数据的安全和隐私保护，系统采取了严格的安全措施，确保用户信息不被泄露和滥用。
5. 性能和稳定性，我们对系统的性能和稳定性进行了多次测试，确保系统能够在高并发情况下保持稳定运行，并能够快速响应用户的操作。
通过以上的自查，我们相信我们的校园网上订餐系统能够满足用户的需求，并提供良好的用户体验。
我们将继续努力，不断改进系统，以更好地为用户和商家提供服务。
【精品作文】网上订餐系统需求分析
（6）防止软件受到意外或蓄意的存取、使用、修改、毁坏或泄密的。
（7）软件属性其数据应能集中存放于总部的数据库服务器，客户端
（8）安全性：不防止软件受到意外或蓄意的存取、使用、修改、毁坏或泄密的， 该系统上的所有数据应能集中存放于总部的数据库服务器并定期备份。
1.2 定义
本产品是为餐厅专门开发的一套订餐管理系统，旨在合理化安排餐厅的工作，提餐厅的管理效率，同时方便员工就餐。
1.3 参考资料
《软件系统分析与设计》《需求分析最佳实践》
2. 项目概述
2.1项目背景
员工到食堂用餐，在路途和排队上浪费很多时间，并且去晚了经常会吃不到想吃的食物；员工对食堂的满意度不高，有将近一半的员工会选择去周边饭店用餐。因此，食堂更无法准确预测员工需求，经常会出现有些食物因为没有卖出去只好倒掉，而员工需要的一些食物却已卖完的现象。
6.3 经济可行性分析 ........................ 20
6.4 法律可行性 ............................ 20
1. 引言
1.1 编写目的
此立项报告旨在确定本项目的基本目标、主要内容，设计实现的流程、工作负荷、费用开支、人员结构、设备情况、局限性，运行设计的项目时间总体规划、进度分段标准、阶段考核方法，以及项目验收方式、提交的内容清单、后续工作情况。
2.2 项目目标
开发手机订餐系统节省学生的时间和精力，避免学生在食堂排队等很多时间，同时也减少食堂食物的浪费，并提高服务质量以及学生对食堂的满意度。
2.3 构件图
图2.3-1 构件图
2.4 上下文关系图
网上订餐系统需求分析
网上订餐系统需求分析网上订餐系统是一种通过网络平台实现用户在线点餐、下单和支付的系统。
以下是一般性的网上订餐系统的需求分析：1.用户注册和登录：o用户应该能够注册账号并登录系统，以便进行点餐和下单。
o注册应该包括基本信息（如姓名、地址、联系方式）和登录凭据（如用户名、密码）。
2.菜单浏览和搜索：o用户应该能够浏览菜单，查看菜品和价格等相关信息。
o提供搜索功能，以便用户可以根据关键词（如菜名、分类）查询特定的菜品。
3.点餐和下单：o用户应该能够将菜品添加到购物车，并设置数量和其他特殊要求。
o用户可以查看购物车的内容，并调整菜品的数量或删除菜品。
o当用户确认订单并选择支付方式后，系统应该自动生成订单并进行相应的结算操作。
4.用户评价和反馈：o用户应该能够对订餐体验进行评价和反馈。
o提供评分系统和评论功能，以便其他用户参考。
5.支付和配送：o系统应该支持多种支付方式（如在线支付、货到付款）。
o用户应该能够在订单中选择配送方式，并提供必要的配送信息（如地址、联系人、联系电话）。
o配送应该能够实时追踪订单状态，并提供相应的配送通知。
6.商家管理系统：o商家应该能够登录系统，查看和管理订单。
o提供订单处理和配送状态的管理工具。
7.系统管理和维护：o系统应该有权限管理功能，以分配不同角色的用户权限和限制访问。
o提供运营统计报表和数据分析工具，以便管理者进行业务分析和决策。
8.用户界面设计：o系统应该具备友好的用户界面设计，易于使用和导航。
o考虑到多平台访问，系统应该支持不同设备（如电脑、手机、平板）的访问和适配。
需要注意的是，上述需求分析只是一个基本框架，具体的网上订餐系统的需求会根据实际业务要求和用户期望有所差异。
因此，在开展网上订餐系统需求分析时，最好与相关利益相关方（如用户、商家、管理者）进行充分沟通和讨论，以便满足他们的具体需求和期望。
网上点餐系统需求分析报告
网上点餐系统需求分析说明书姓名：罗永亮、朱文剑、钟云、尹玲玲、周应成学院：信息工程分院开发部门：Java项目组撰写人：钟云目录1.文档概述 (4)1.1 编写目的 (4)1.2 定义 (4)1.3 参考资料 (4)2.项目概述 (4)2.1 项目背景 (4)2.2 项目目标 (4)2.3构件图 (5)2.4上下文关系图 (5)2.5 对产品进一步解析 (6)2.6 项目适用范围 (6)3.项目需求分析3.1 性能需求分析 (6)3.2项目活动图 (7)3.3系统报表 (8)3.4 系统用例图 (8)3.5用例文档 (10)4.项目技术方案 (12)4.1方案概述 (12)4.2编程环境 (12)4.3数据库的实现 (12)5．可行性分析 (12)5.1技术可行性分析 (12)5.2运行可行性分析 (13)5.3 经济可行性分析 (13)5.4分工可行性分析…………………………135.5进程分析…………………………………135.6法律可行性………………………………141.引言1.1编写目的此立项报告旨在确定本项目的基本目标、主要内容，设计实现的流程、工作负荷、费用开支、人员结构、设备情况、局限性，运行设计的项目时间总体规划、进度分段标准、阶段考核方法，以及项目验收方式、提交的内容清单、后续工作情况。
1.2定义本产品是为餐厅专门开发的一套订餐管理系统，旨在合理化安排餐厅的工作，提高餐厅的管理效率，同时方便员工就餐。
1.3参考资料《软件系统分析与设计》《需求分析最佳实践》2. 项目概述2.1项目背景员工到食堂用餐，在路途和排队上浪费很多时间，并且去晚了经常会吃不到想吃的食物；员工对食堂的满意度不高，有将近一半的员工会选择去周边饭店用餐。
因此，食堂更无法准确预测员工需求，经常会出现有些食物因为没有卖出去只好倒掉，而员工需要的一些食物却已卖完的现象。
2.2 项目目标开发手机订餐系统节省员工的时间和精力，避免员工在食堂排队等很多时间，同时也减少食堂食物的浪费，并提高服务质量以及员工对餐厅的满意度。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
“我要吃”系统功能需求分析报告报告成员：2011年11月5日目录一、功能分析 (1)（一）顾客登录网上订餐系统进行菜单浏览 (1)（二）顾客注册为会员 (1)（三）顾客对自己的个人信息进行更改，比如联系电话。
以及账户密码。
(1)（四）顾客对已选的菜单进行更改，选择更改数量或者取消选择。
当顾客确定订餐完毕后，顾客将其提交只服务器后台点餐系统，并生成订单。
(1)1、菜品详细信息 (1)2、购物车 (1)3、提交购物车并生成订单 (1)4、结帐付款 (1)5、结束订餐 (1)（五）管理员后台管理 (1)1、管理员在后台登录后，可以创建新的管理员。
(1)2、管理员可以对餐厅网上订餐系统上的菜单进行添加、删除和修改，比如更改菜单的图片，价格，菜单的描述，更换新品，添加新菜等。
(1)3、管理员对菜单进行管理，确定订单的生成。
(1)4、管理员根据不同的属性来查询订单，比如生成日期或者编号等。
(2)5、管理员根据不同的时间段统计处营业额，成本，同时还能统计出每道菜的销售量、任何时间段的销售情况以及每一个顾客的消费情况。
(2)二、顶层用例图 (3)三、用例分析与描述 (4)（一）登录 (4)1、用例图 (4)2、用例的事件流描述 (4)3、事件流 (4)（二）注销 (4)（三）修改顾客信息 (5)1、用例图 (5)2、用例的事件流描述 (5)（四）顾客留言 (5)1.用例图 (5)（五）加入购物车 (6)1、用例图 (6)2、用例的事件流描述 (6)3、事件流 (6)4、替代流 (6)（六）查看购物车 (6)1、用例图 (6)2、用例的事件流描述 (7)3、事件流 (7)（七）修改购物车中的商品 (7)1、用例图 (7)2、用例的事件流描述 (7)3、事件流 (8)（八）删除购物车中的商品 (8)1、用例图 (8)2、用例的事件流描述 (8)3、事件流 (8)（九）清空购物车 (8)1、用例图 (9)2、用例的事件流描述 (9)3、事件流 (9)（十）结账 (9)1、用例图 (9)2、用例的事件流描述 (9)3、事件流 (10)4、分支流 (10)（十一）确认订单 (10)1、用例图 (10)3、事件流 (10)（十二）查看订单 (11)1、用例图 (11)2、用例的事件流描述 (11)3、事件流 (11)（十三）修改订单 (12)1、用例图 (12)2、用例的事件流描述 (12)3、事件流 (12)（十四）删除订单 (12)1、用例图 (12)2、用例的事件流描述 (13)3、事件流 (13)四、类图 (14)五、动态图 (14)（一）顾客订餐 (14)（二）管理员管理模块 (15)五、总结 (15)（一）系统主要特色与优点接受 (15)（二）系统不足与改进方案 (16)“我要吃”系统功能需求分析报告一、功能分析根据对该系统的分析，该系统应具有如下功能：（一）顾客登录网上订餐系统进行菜单浏览显示菜品的各种信息，可分类查询、动态搜索、设计页面分类、布局排版；以方便顾客浏览选择。
（二）顾客注册为会员顾客访问本网站，直接进入本网站主页。
可选择登陆，若为注册可选择注册，只有注册顾客方可点餐。
注册提供顾客名和密码，顾客名能自动检测，若已存在则提示不可用。
另外加入记住密码功能，登陆一次可在两周内无需再次登陆，直接进入登陆状态。
（三）顾客对自己的个人信息进行更改，比如联系电话。
以及账户密码。
（四）顾客对已选的菜单进行更改，选择更改数量或者取消选择。
当顾客确定订餐完毕后，顾客将其提交只服务器后台点餐系统，并生成订单。
1、菜品详细信息显示餐品中某一餐品的详细信息，包括菜名，配料，口味，价格等，以供顾客放进自己的购物车。
2、购物车实现对已定菜品的管理，包括增加菜品，删除菜品，修改数量。
3、提交购物车并生成订单接受购物车信息，随即获取订单号，动态刷新顶单状态，固定时间（如30秒）完成一道菜，顾客可继续修改为完成的菜品，已完成菜品无法进行操作，顾客修改订单并保存。
4、结帐付款选择付款方式及对此次订餐的评价。
5、结束订餐设置友好的结束界面。
（五）管理员后台管理1、管理员在后台登录后，可以创建新的管理员。
2、管理员可以对餐厅网上订餐系统上的菜单进行添加、删除和修改，比如更改菜单的图片，价格，菜单的描述，更换新品，添加新菜等。
3、管理员对菜单进行管理，确定订单的生成。
4、管理员根据不同的属性来查询订单，比如生成日期或者编号等。
5、管理员根据不同的时间段统计处营业额，成本，同时还能统计出每道菜的销售量、任何时间段的销售情况以及每一个顾客的消费情况。
具体功能如下表：二、顶层用例图顾客系统管理员顶层用例图顾客系统管理员订餐系统用例图三、用例分析与描述（一）登录1、用例图2、用例的事件流描述（1）简单描述：本用例描述了顾客如何登录到系统中。
（2）前置条件无。
（3）后置条件如果用例成功，用例登录到系统中，否则系统的状态不变。
3、事件流基流（1）顾客登录到基于顾客的网站时，用例启动。
（2）系统提示顾客输入顾客名和密码（3）顾客输入自己的顾客名和密码，提交。
（E-1）（4）系统验证输入的名字和密码，顾客登录系统成功。
(E-2) 替代流E-1：包含了单引号、双引号或为空，系统提示错误。
E-2：系统检索不到该顾客的密码，系统提示错误。
（二）注销用例描述：清除内存中顾客名、购物车信息，并返回到登录页。
（三）修改顾客信息1、用例图2、用例的事件流描述（1）简单描述： 该用例描述了如何修改顾客的信息，但顾客的顾客名不允许修改。
（2）前置条件顾客已登录。
（3）后置条件用例成功，把顾客的信息保存到数据库中。
3、事件流基流（1）系统提示输入顾客的信息。
（2）顾客输入所需信息，提交。
(E-1)（3）系统把所需的信息保存到数据库中。
替代流E-1：系统验证输入的数据不合法（不能包含单引号、双引号，邮箱必须满足要求），提示错误。
（四）顾客留言1.用例图用例的事件流描述（1）简单描述：该用例描述了顾客留言的信息，但顾客的不能删除留言。
（2）前置条件顾客已登录。
（3）后置条件用例成功，把顾客的回复留言信息保存到数据库中。
（五）加入购物车1、用例图2、用例的事件流描述（1）简单描述：该用例描述了如何修改顾客的信息，但顾客的顾客名不允许修改。
（2）前置条件顾客已登录。
（3）后置条件用例成功，把顾客的信息保存到数据库中。
3、事件流基流（1）系统提示输入顾客的信息。
（2）顾客输入所需信息，提交。
(E-1)（3）系统把所需的信息保存到数据库中。
4、替代流(E-1)系统验证输入的数据不合法（不能包含单引号、双引号，邮箱必须满足要求），提示错误。
（六）查看购物车1、用例图2、用例的事件流描述（1）简单描述：该用例描述了如何修改顾客的信息，但顾客的顾客名不允许修改。
（2）前置条件顾客已登录。
（3）后置条件用例成功，把顾客的信息保存到数据库中。
3、事件流基流（1）系统提示输入顾客的信息。
（2）顾客输入所需信息，提交（E-1）。
（3）系统把所需的信息保存到数据库中。
替代流E-1：系统验证输入的数据不合法（不能包含单引号、双引号，邮箱必须满足要求），提示错误。
（七）修改购物车中的商品1、用例图2、用例的事件流描述（1）简单描述：顾客修改购物车中商品的数量。
（2）前置条件系统处于查看购物车状态。
（3）后置条件用例成功，购物车中商品的数量被更改。
3、事件流基流（1）系统提示更改商品的数量。
（2）顾客输入要更改商品的数量，确认更改。
(E-1)（3）系统刷新购物车。
替代流E-1：顾客输入的商品数量只能是（1-50）间的整数。
否则提示错误。
（八）删除购物车中的商品1、用例图2、用例的事件流描述（1）简单描述：删除购物车中的某个商品。
（2）前置条件系统处于查看购物车状态。
（3）后置条件用例成功，删除商品。
3、事件流基流（1）系统提示删除商品。
（2）顾客删除商品，确认（3）系统刷新购物车。
（九）清空购物车1、用例图2、用例的事件流描述（1）简单描述：顾客清空购物车中的商品。
（2）前置条件系统处于查看购物车状态。
（3）后置条件用例成功，系统清空购物车。
3、事件流基流（1）系统提示清空购物车。
（2）顾客清空购物车。
（3）系统刷新购物车。
（十）结账1、用例图2、用例的事件流描述（1）简单描述：加入购物车完毕，即可进入结帐状态。
（2）前置条件系统处于查看购物车状态。
（3）后置条件用例成功，便可进入网上银行。
3、事件流基流（1）系统提示顾客结帐。
（2）顾客确认结帐。
（3）系统检查购物车是否为空。
(E-1)（4）系统进入该顾客的登录界面，顾客输入密码确认。
（5）检索成功，不成功。
替代流E-1：购物车为空，系统提示错误，并转入至首页。
4、分支流1：系统进入网上银行付款。
2：停留在登录界面。
（十一）确认订单1、用例图顾客2、用例的事件流描述（1）简单描述：确认生成订单。
（2）前置条件付款方式用例成功。
（3）后置条件用例成功，把订单数据存储到数据库中。
3、事件流基流（1）系统提示确认订单。
（2）顾客确认订单。
（3）系统生成订单号。
（4）系统生成订单记录并存入数据库中。
（5）系统清空购物车。
（6）付款方式。
（十二）查看订单1、用例图2、用例的事件流描述（1）简单描述：查看该顾客的所有订单或基于组合条件的订单。
（2）前置条件顾客已登录。
（3）后置条件用例成功，系统显示该顾客的订单情况。
3、事件流基流顾客选择查看所有订单，或基于组合条件查看订单。
分支流1：A、系统检索该顾客的所有订单B、系统显示所有订单，当显示的订单超过一页时，系统显示“第一页、上一页、下一页、最后一页”的页浏览提示。
2：A、系统提示顾客输入订单号、发生订单的时间段、或订单的状态（已执行、部分执行、未执行）B、顾客输入所需信息，提交。
C、统检索满足组合条件的所有订单。
D、系统显示满足条件的订单。
系统验证输入的合法性，不合法系统提示错误（十三）修改订单1、用例图2、用例的事件流描述（1）简单描述：顾客修改订单的订单明细，付款方式。
（2）前置条件系统处于查看订单状态中。
（3）后置条件用例成功，把修改的订单存储到数据库中。
3、事件流基流（1）系统提示修改订单。
（2）顾客确认修改（E-1）。
（3）系统提示输入要修改的订单。
（4）顾客输入修改信息，提交（E-2）（5）系统存储订单情况至数据库中。
替代流E-1：已审核的订单不能修改，否则提示错误。
E-2：不合法输入，系统提示错误。
（十四）删除订单1、用例图2、用例的事件流描述（1）简单描述：顾客删除不需要的订单。
（2）前置条件系统处于查看订单状态中。
（3）后置条件用例成功，系统删除该订单。
3、事件流基流（1）系统提示删除该订单。
（2）顾客确认删除该订单。
（E-1）（3）系统从数据库中删除该订单。