网上订餐系统需求规格Word文件下载.docx

网上订餐系统需求规格Word文件下载.docx

《网上订餐系统需求规格Word文件下载.docx》由会员分享，可在线阅读，更多相关《网上订餐系统需求规格Word文件下载.docx（24页珍藏版）》请在冰豆网上搜索。

3、事件流16

（四）顾客留言16

1.用例图16

（五）加入购物车16

1、用例图16

2、用例的事件流描述17

3、事件流17

4、替代流17

（六）查看购物车17

1、用例图17

3、事件流18

（七）修改购物车中的商品18

1、用例图18

2、用例的事件流描述18

（八）删除购物车中的商品19

1、用例图19

2、用例的事件流描述19

3、事件流19

（九）清空购物车19

2、用例的事件流描述20

3、事件流20

（十）结账20

1、用例图20

3、事件流21

4、分支流21

（十一）确认订单21

1、用例图21

2、用例的事件流描述21

（十二）（十二）查看订单22

1、用例图22

2、用例的事件流描述22

3、事件流22

（十三）修改订单23

1、用例图23

2、用例的事件流描述23

3、事件流23

（十四）删除订单24

1、用例图24

2、用例的事件流描述24

3、事件流24

4.4.类图25

4.5.动态图25

（一）顾客订餐25

（二）管理员管理模块26

5.性能需求27

5.1.界面需求27

5.2.系统安全性需求27

5.3.经济可行性分析27

6.签字27

1.导言

1.1.目的

该文档是关于用户对于网上订餐系统的功能和性能的要求，重点描述了网上订餐系统的设计需求，将作为对该工具在概要设计阶段的设计输入。

。

本文档的预期读者是：

●设计人员

●开发人员

●项目管理人员

●测试人员

●用户

1.2.范围

该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决整个项目系统的“做什么”的问题。

在这里，对于开发技术并没有涉及，而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。

1.3.缩写说明

无

1.4.术语定义

1.5.引用标准

[1]《企业文档格式标准》V1.1

北京长江软件有限公司

[2]《需求规格报告格式标准》V1.1

北京长江软件有限公司软件工程过程化组织

1.6.参考资料

[1]《UML》V1.1

北京长江软件有限公司软件工程过程化组织

1.7.版本更新信息

本文档的更新记录如下表。

修改编号

修改日期

修改后版本

修改位置

修改内容概述

001

2012.4.5

0.1

全部

初始发布版本

002

2012.4.10

0.2

细节

增加

003

2012.4.15

0.3

修改

004

2012.4.16

0.4

005

2012.4.18

1.0

2.系统定义

2.1.项目来源及背景

随着人们生活水平的提高，人们对自己的饮食也渐渐的注重起来，很多人在进行紧张工作之余会选择享受美食进行放松。

但很多时候会出现这样的情况，人们到餐厅就餐，会出现排队或没有位置的现象；

还有就是有的人懒得出去，想在自己的家里就能享受到美味的食物。

这样就出现了订餐这样的做法。

现在普遍使用的订餐方式是电话预订，这种预订方式简洁，方便，错误率也比较低，但是由此引发的一些不良现象也比较多，主要是订餐后出现餐厅并没将信息记录在案，这样的订餐就没有了意义，另外这种订餐方式只是进行电话的预订，很可能会出现订餐但是不履行订单也不进行订餐取消的现象，订餐人员对订餐信息不了解就会进行相关信息的询问，这样就在一定程度上造成了时间的浪费，餐厅人员会在同一天反复重复相同的信息，造成了人力资源的浪费。

2.2.用户定义

网上订餐系统的使用者主要有两种：

系统管理员、客户。

系统管理员：

网上订餐系统的系统管理者，进行系统的日常维护，并进行日常的管理，并按照餐厅的意愿，对菜谱和员工的信息进行各种管理，比如添加、修改、删除、更新等。

客户：

网上订餐系统的主要使用者，他们是餐厅的顾客，能进行基本功能的使用和操作，但是不能对系统进行管理。

通过调查，网上调查系统的客户具有一下特征：

a主要居住或工作在离餐厅不太远的地方

b主要是工作繁忙者或单身人士

c能够经常上网的人

d有喜事等特殊情况的人群

2.3.项目目标

本项目设定的目标如下：

·

系统能够提供友好的用户界面，使操作人员的工作量最大限度的减少；

系统具有良好的运行效率，能够达到提高生产率的目的；

系统应有良好的可扩充性，可以容易地加入其他系统的应用；

平台的设计具有一定的超前性，灵活性，能够适应企业生产配置的变化；

通过这个项目可以锻炼队伍，提高团队的项目管理能力。

3.应用环境

P4系列、AMDK9以上系列等PC台式机和便携式电脑；

运行时占用内存：

≤100MB；

所需硬盘空间：

软件平台：

中文Windows98以上系统；

Struts1、SQL数据库的电脑。

3.1.系统运行的网络环境

无论是客户端的用户还是管理端的管理用户都可以通过网络登录到本系统中。

用户通过网络注册会员填写并查询相关信息。

管理端的管理员再对会员的信息进行添加、修改和删除操作。

管理端的系统管理员需要设置管理端的用户以及相应的权限。

3.2.系统运行的硬件环境

本系统的硬件环境如下：

客户机：

普通PC

●CPU：

P41.8GHz以上

●内存：

256MB以上

●能够运行IE5.0以上或者Netscape4.0以上版本的机器

●分辨率：

推荐使用1024×

768像素

Web服务器

P41.0GHz

1G以上

●硬盘：

80GB以上

●网卡：

KMb/s速度

数据库服务器

P42.0GHz

1GB以上

80GB以上

3.3.系统运行软件环境

本系统的软件环境如下：

●操作系统：

UNIX/Linux/Windows2000或以上版本

●数据库：

SQLServer2000

●开发工具包：

JDKVersion1.4.2

●Web服务器：

Tomcat

●浏览器：

IE5.0以上

4.功能规格

采用面向对象分析作为主要的系统建模方法，使用UML（UnifiedModelingLanguage）作为建模语言。

UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。

在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。

用例描述角色（用户、外部系统以及系统处理）是如何与系统交互来完成工作的。

用例模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来可以派生出动态对象模型。

设计用例时，我们遵循下列步骤：

1）识别出系统的角色。

角色可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。

重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者（角色）是谁。

尽可能地确保所有角色都被完全识别出来。

2）描述主要的用例。

可以采取不断地问自已“这个角色究竟想过系统做什么？

”来准确地描述用例。

3）重新审视每个用例，为它们下个详尽的定义。

4.1.功能分析

根据对该系统的分析，该系统应具有如下功能：

（1）顾客登录网上订餐系统进行菜单浏览

显示菜品的各种信息，可分类查询、动态搜索、设计页面分类、布局排版；

以方便顾客浏览选择。

（2）顾客注册为会员

顾客访问本网站，直接进入本网站主页。

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

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

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

（3）顾客对自己的个人信息进行更改，比如联系电话。

以及账户密码。

（4）顾客对已选的菜单进行更改，选择更改数量或者取消选择。

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

1）菜品详细信息

显示餐品中某一餐品的详细信息，包括菜名，配料，口味，价格等，以供顾客放进自己的购物车。

2）购物车

实现对已定菜品的管理，包括增加菜品，删除菜品，修改数量。

3）提交购物车并生成订单

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

4）结帐付款

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

5）结束订餐

设置友好的结束界面。

（5）管理员后台管理

具体功能如下表：

功能类别

子功能

顾客管理

顾客登录

顾客注册

顾客操作

餐品展示

餐品的详细介绍

放进购物车

查看购物车

详细信息提交

反馈意见

查看所有留言

结束订单

管理员操作

增加餐品

修该餐品

删除餐品

回复留言

删除留言

结帐付款

确认和配送信息

4.2.顶层用例图

顶层用例图

订餐系统用例图

4.3.用例分析与描述

（1）登录

1．用例图

2．用例的事件流描述

1　简单描述：

本用例描述了顾客如何登录到系统中。

2　前置条件

无。

3　后置条件

如果用例成功，用例登录到系统中，否则系统的状态不变。

3．事件流

⏹基流

（1）顾客登录到基于顾客的网站时，用例启动。

（2）系统提示顾客输入顾客名和密码

（3）顾客输入自己的顾客名和密码，提交。

（E-1）

（4）系统验证输入的名字和密码，顾客登录系统成功。

（E-2）

⏹替代流

E-1：

包含了单引号、双引号或为空，系统提示错误。

E-2：

系统检索不到该顾客的密码，系统提示错误。

（2）注销

用例描述：

清除内存中顾客名、购物车信息，并返回到登录页。

（3）修改顾客信息

1、用例图

2、用例的事件流描述

（1）简单描述：

该用例描述了如何修改顾客的信息，但顾客的顾客名不允许修改。

（2）前置条件

顾客已登录。

（3）后置条件

用例成功，把顾客的信息保存到数据库中。

3、事件流

基流

（1）系统提示输入顾客的信息。

（2）顾客输入所需信息，提交。

（3）系统把所需的信息保存到数据库中。

替代流

系统验证输入的数据不合法（不能包含单引号、双引号，邮箱必须满足要求），提示错误。

（4）顾客留言

1.用例图

用例的事件流描述

该用例描述了顾客留言的信息，但顾客的不能删除留言。

用例成功，把顾客的回复留言信息保存到数据库中。

（5）加入购物车

4、替代流

（E-1）系统验证输入的数据不合法（不能包含单引号、双引号，邮箱必须满足要求），提示错误。

（6）查看购物车

（2）顾客输入所需信息，提交（E-1）。

（7）修改购物车中的商品

顾客修改购物车中商品的数量。

系统处于查看购物车状态。

用例成功，购物车中商品的数量被更改。

（1）系统提示更改商品的数量。

（2）顾客输入要更改商品的数量，确认更改。

（3）系统刷新购物车。

顾客输入的商品数量只能是（1-50）间的整数。

否则提示错误。

（8）删除购物车中的商品

删除购物车中的某个商品。

用例成功，删除商品。

（1）系统提示删除商品。

（2）顾客删除商品，确认

（9）清空购物车

顾客清空购物车中的商品。

用例成功，系统清空购物车。

（1）系统提示清空购物车。

（2）顾客清空购物车。

（10）结账

加入购物车完毕，即可进入结帐状态。

用例成功，便可进入网上银行。

（1）系统提示顾客结帐。

（2）顾客确认结帐。

（3）系统检查购物车是否为空。

（4）系统进入该顾客的登录界面，顾客输入密码确认。

（5）检索成功，不成功。

购物车为空，系统提示错误，并转入至首页。

4、分支流

1：

系统进入网上银行付款。

2：

停留在登录界面。

（11）确认订单

确认生成订单。

付款方式用例成功。

用例成功，把订单数据存储到数据库中。

（1）系统提示确认订单。

（2）顾客确认订单。

（3）系统生成订单号。

（4）系统生成订单记录并存入数据库中。

（5）系统清空购物车。

（6）付款方式。

（12）（十二）查看订单

查看该顾客的所有订单或基于组合条件的订单。

用例成功，系统显示该顾客的订单情况。

顾客选择查看所有订单，或基于组合条件查看订单。

分支流

A、系统检索该顾客的所有订单

B、系统显示所有订单，当显示的订单超过一页时，系统显示“第一页、上一页、下一页、最后一页”的页浏览提示。

A、系统提示顾客输入订单号、发生订单的时间段、或订单的状态（已执行、部分执行、未执行）

B、顾客输入所需信息，提交。

C、统检索满足组合条件的所有订单。

D、系统显示满足条件的订单。

系统验证输入的合法性，不合法系统提示错误

（13）修改订单

顾客修改订单的订单明细，付款方式。

系统处于查看订单状态中。

用例成功，把修改的订单存储到数据库中。

（1）系统提示修改订单。

（2）顾客确认修改（E-1）。

（3）系统提示输入要修改的订单。

（4）顾客输入修改信息，提交（E-2）

（5）系统存储订单情况至数据库中。

已审核的订单不能修改，否则提示错误。

不合法输入，系统提示错误。

（14）删除订单

顾客删除不需要的订单。

用例成功，系统删除该订单。

（1）系统提示删除该订单。

（2）顾客确认删除该订单。

（3）系统从数据库中删除该订单。

已审核的订单不能删除，否则提示错误。

4.4.类图

4.5.动态图

（1）顾客订餐

（2）管理员管理模块

5.性能需求

根据用户对本系统的要求，确定系统在响应时间、可靠性、安全性等方面有较高的必能要求。

5.1.界面需求

系统人机界面操作友好，本系统外界界面具有简洁性和友好性等特点，但又不失独特的页面风格，界面采用引入的图片温馨暖格调的色调，优雅大方，系统内部结构采用框架布局，使整个系统看起来更有层次感，在用户功能操作上，设计简单方便，符合了现代化管理系统的界面要求。

5.2.系统安全性需求

系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。

系统需能够防止各类误操作可能造成的数据丢失，破坏。

防止用户非法获得网页以及内容。

5.3.经济可行性分析

本订餐系统所需要的硬件和软件都是目前广泛使用的，如软件件运行环境windows98以上系统、数据库SQLServer2000、编程语言JAVA等等，都可以通过网上、图书馆等各种渠道得到，不需要再花费大量的资金去购买高成本的设备，大大提高了在设计过程中的工作效率，且投入使用后，便于后期工作的维护，因此，本系统在经济上是可行的。

6.签字

本需求规格经过双方认可，特签字如下表

用户签署信息

企业签署信息

单位名称

浙江“我要吃”公司

浙江XX有限公司

签署人姓名

ＸＸＸ

签署日期