软件工程报告.docx

软件工程报告.docx

《软件工程报告.docx》由会员分享，可在线阅读，更多相关《软件工程报告.docx（21页珍藏版）》请在冰豆网上搜索。

软件工程报告

软件工程报告

题目：

在线订餐系统

专　　业:

计算机科学与技术学院班级:

计科11-1班

小组成员：

指导教师：

张磊职称：

中国矿业大学计算机科学与技术学院

2013年9月徐州

附表3：

题目

在线订餐系统

设计日期

年月日至年月日

小组成员

在本次设计中承担的任务

文档成绩

需求分析

可行性研究

指导教师签字：

年月日

题目

可行性研究报告

作者：

日期：

2013.9.22

目录

1项目背景5

2任务概述5

2.1项目目标5

2.2项目范围5

2.3初步想法6

3对现有系统的分析6

3.1处理流程和数据流程6

3.2局限性6

4所建议的系统6

4.1对所建议系统的说明6

4.2处理流程和数据流程7

4.3改进之处7

4.4可行性分析7

4.4.1经济可行性7

4.4.2技术可行性7

4.4.3运行可行性7

4.4.4法律可行性8

5结论8

1项目背景

在现代生活中，人们越来越希望以方便快捷的方式来结局自己的事情。

而在网络越来越流行的今天，通过网络交易显然是一个不错的想法。

在线订餐系统完全可以满足人们对于便捷的需求。

人们在几天前便可以通过这个系统预定自己要吃的饭菜。

同事说明自己用餐的时间及人数。

到了那天便可以直接去食用。

无需等待的同时提高了餐厅的工作效率。

该系统还提供在线订外卖的功能。

通过网络上的图片使人们可以有更多更好的选择。

同时可以使餐厅合理的采购材料。

避免浪费的行为。

对于双方都是一个双赢的局面。

2任务概述

2.1项目目标

A.减少了餐厅成本；

B.提高了餐厅的工作效率；

C.方便了人们的生活；

D.提高了餐厅收入。

2.2项目范围

说明对所建议开发的软件的基本要求：

A.人们在几天前便可以通过这个系统预定自己要吃的饭菜。

同事说明自己用餐的时间及人数。

到了那天便可以直接去食用。

无需等待的同时提高了餐厅的工作效率。

该系统还提供在线订外卖的功能；

B.输出主要分为两个部分。

对于卖家来说，输出指的是买家的订单。

其中包括的信息有菜的名称，价格以及用餐的时间；对于买家来说，输出指的是卖家挂出的信息，包括菜的名称，价格和图片。

；

C.输入和输出一样也包括两个部分，对于卖家来说，输入指的是自己挂出的菜的名称，价格还有图片等信息；对于买家来说，输入的信息是菜的名称，价格以及用餐的时间。

D系统流程图清晰地显示出来了系统大概的的工作流程。

用户先注册、然后登陆、提交订单，卖家接受订单，到了日子之后出菜并开发票。

在此过程中一次更新用户信息表，未处理订单表，已处理订单表以及个人消费表；

E在安全与保密性方面，本系统作为一个WEB服务，尤其自身的优点，机密信息都是保存在服务器上的。

所以安全性能还是不错的；

2.3初步想法

对于该系统来说虽然算是一个较为完备的系统。

不过，还可以做如下改进。

我们可以增加特色菜推荐，并增加各种生日标准套餐、婚庆标准套餐等。

如果有可能的话，我们可以考虑加入用户评价系统让用户可以写下自己的体会。

只要注册了且订单生效了之后即可对商品给出自己的评价。

让以后的人来参考。

3对现有系统的分析

3.1处理流程和数据流程

当用户注册后并且登录。

用户信息储存在用户信息表中。

用户就可以浏览商品。

对于自己感兴趣的餐厅及菜可以详细了解。

用户满意后可以提交订单。

并写入未处理订单表。

详细写明具体的用餐时间及人数。

卖家此时会收到订单提示。

并开始准备。

到了订单上约定的日子顾客只需要去用餐即可。

无需等待或点菜。

当出菜完毕后更新已处理订单表。

用餐完毕后付账并开发票。

并写入个人消费表中。

3.2局限性

任何系统都有其自身的局限性。

本系统的局限性在于不能实现买家和卖家的即时互动，在特殊情况下可能使双方交流出现障碍。

另外，本系统在功能上并不是特别完善。

实现不了让顾客对同一个菜实现比价功能。

也不能按评论好坏顺序排列餐厅。

这样或许会使用户找到评价好的餐厅会比较费力。

4所建议的系统

4.1对所建议系统的说明

对于卖家来说，他们要做的工作就是更新自己商品的信息。

第一次时输入商品的价格，名称，并附上图片。

将其上传到服务器。

同时，如果有订单来，系统会发出声音提示卖家。

卖家看到后可以点击确认。

这样一个待完成的订单就产生了。

对于买家来说，他们要做的工作是浏览时，如果看到合适的餐厅和菜。

只要选择完中意的菜之后点击确定即可提交订单。

然后输入自己用餐的时间以及用餐的人数就可以了。

然后只要到约定的时间去用餐即可。

用完餐之后付账。

半个月之内可以评论该商品。

4.2处理流程和数据流程

此系统和上面的最大的区别在于引进了评论系统。

当人们用完餐之后。

我们可以及时评论该餐厅的菜。

用以给用户参考。

4.3可行性分析

4.3.1经济可行性

本系统只需要将后台应用挂到服务器上即可正常工作。

修改和维护都在后台进行，并不需要太大的花费。

本系统对于维护的成本要求不高。

因此在经济上是可行的。

4.3.2技术可行性

对于本系统，我们要制作一个数据库存放相关信息，比如菜的价格，图片等。

还有，买家和卖家的相关信息。

另外只要制作两个分别针对买家和卖家的网页。

即可实现相关功能。

对于后台，我们可以用PHP和MYSQL来实现。

至于网页可以用XHTML来实现各种复杂的功能。

还可以用Javascript来实现需要的功能。

因此，本系统在技术方面是可行的。

4.3.3运行可行性

本系统对于操作的要求不高，卖家只要输入相关信息并传到网络上去便可以让顾客看到。

在操作上并无大的要求。

对于顾客来说，他们只需要选择相关产品并输入时间等相关信息即可。

因此在运行上是可行的。

4.3.4法律可行性

本系统是一个由我们自己开发并且维护的产品。

使用的技术均在法律允许范围之内。

并没有什么侵权之处。

因此在法律层面上是可行的。

4结论

本系统可以立即开始进行。

题目

软件需求说明书

作者：

日期：

2013年9月22日

目录

1需求分析概述12

2数据流图12

2.1顶层数据流图12

2.2分层数据流图12

2.2.1一层数据流图12

2.2.2二层数据流图12

3数据字典12

3.1数据元素12

3.2数据流13

3.3数据存储13

4加工逻辑描述13

1需求分析概述

在生活节奏越来越快的今天，很多人忙于工作或者学习，到了饭点常常选择叫外卖的方式。

传统的外卖一般是打电话，这样很麻烦而且不直观，不易于消费者方便的选择餐点。

而在线订餐系统继承了原来电话订餐的快捷性，又把对应餐点通过图片方式呈现出来，更加直观方便。

而且本系统还提供聚餐预约服务，聚会的消费者直接事先在线定好时间点好菜，避免其亲自去订餐的麻烦。

本系统目标在于减少餐厅成本、提高餐厅的工作效率、方便人们的生活、提高餐厅收入。

思路与方法：

我们需要制作两个分别针对顾客和商家的网页。

顾客在网站中注册登录、点菜下订单；工作人员在后台更新菜品信息、结账。

对于后台与服务器交互，我们可以用PHP和MYSQL来实现。

至于网页可以用XHTML来实现各种复杂的功能。

还可以用Javascript来实现需要的功能。

Mysql数据库用于存放相关信息，比如菜的价格，图片等。

还有，买家和卖家的相关信息

2数据流图

2.1顶层数据流图

2.2分层数据流图

2.2.1一层数据流图

2.2.2二层数据流图

A订餐子系统

B后台管理子系统

3数据字典

3.1数据元素

名称

用户ID

别名

UserID

取值类型

字符串

长度

8个字节

描述

唯一标识消费者信息的编号

位置

用户信息表、个人菜单

名称

订单号

别名

取值类型

字符串

长度

8个字节

描述

唯一标识订单的标号

位置

个人菜单、菜单列表、未处理菜单列表

名称

菜品号

别名

取值类型

字符串

长度

8个字节

描述

唯一标识菜品的编号

位置

菜品列表、个人菜单

3.2数据流

名称

已订菜单

描述

每个消费者所订菜品列表

来源

1个人菜单

去处

消费者

组成

用户ID+

{菜品编号+菜品名称+数量+单价+总价}

流程量

无

名称

未处理菜单列表

描述

尚未处理的客户订单的列表

来源

2后台管理

去处

工作人员

组成

订单号+

{订餐时间+订餐客户ID}

流程量

无

名称

个人信息

描述

客户在注册时输入的个人信息

来源

1消费者

去处

1注册

组成

用户ID+

{姓名+年龄+家庭住址+联系方式}

流程量

无

名称

个人菜单

描述

每个消费者所享用的菜品列表

来源

1个人菜单

去处

消费者

组成

用户ID+

{菜品编号+菜品名称+数量+单价+总价}

流程量

无

3.3数据存储

名称

用户信息表

输入数据流

客户信息

输出数据流

客户信息

描述

客户个人信息的汇总列表

组成

用户ID+姓名+年龄+家庭住址+联系方式

组织方式

按用户ID由小到大排序

名称

个人菜单

输入数据流

订菜单

输出数据流

个人菜单

描述

客户所享用的菜品的列表

组成

用户ID+姓名+年龄+家庭住址+联系方式

组织方式

按用户ID由小到大排序

名称

菜单列表

输入数据流

订餐

输出数据流

个人菜单

描述

所有客户菜单的集合

组成

订单号+订餐时间+订餐客户ID

组织方式

按订单号由小到大排序

名称

菜品列表

输入数据流

菜品信息

输出数据流

菜品信息

描述

客户所有能点的菜品的列表

组成

菜品编号+菜品名称+分类+单价

组织方式

按菜品编号由小到大排序

名称

已处理菜单列表

输入数据流

上菜单

输出数据流

发票

描述

所有已处理客户菜单的集合

组成

订单号+订餐时间+订餐客户ID

组织方式

按订单号由小到大排序

4加工逻辑描述

名称

注册

编号

1.1

输入

个人信息

输出

用户信息表

功能描述

保留用户个人信息，使其有资格进入订餐系统订餐

加工处理

将用户信息存储起来，方便其他表格调用

名称

登录并检查信息

编号

1.2

输入

用户ID、密码

输出

订菜单

功能描述

审查用户ID密码是否正确匹配

加工处理

若匹配，则用户顺利进入订餐系统；若不匹配，则需重新输入或进行注册

名称

订菜

编号

1.3

输入

订菜单

输出

个人菜单

功能描述

用户选中菜品，系统将菜品存储起来

加工处理

将用户所点菜品信息，存入表格，形成个人菜单

名称

更新菜单

编号

2.1

输入

菜品更新表

输出

菜品列表

功能描述

工作人员根据表格修改现有菜品列表

加工处理

修改后的列表直接呈现在用户面前，方便其点菜

名称

上菜

编号

2.2

输入

未处理菜单列表

输出

已处理菜单列表

功能描述

工作人员根据未处理菜单列表中菜单为客户上菜

加工处理

上菜之后将上菜的菜单从未处理列表中删去，放入已处理列表中

题目

概要设计说明书

作者：

日期：

2013年9月25日

目录

1软件结构设计17

1.1软件结构17

1.2功能需求与模块的关系17

1.3人工处理过程17

1.4尚未解决的问题17

2软件接口设计17

2.1用户接口17

2.2外部接口18

3数据库结构设计18

3.1概念结构设计18

3.2逻辑结构设计18

3.3物理结构设计18

4运用设计18

4.1数据字典设计18

4.2安全保密设计18

1软件结构设计

1.1软件结构

A订餐子系统

B后台管理子系统

1.2功能需求与模块的关系

订餐模块

后台管理模块

点菜

√

结账

√

更新菜品信息

√

1.3人工处理过程

客户首先必须手动输入自己的信息进行注册，注册登录之后要点击自己喜欢的菜品，并最后提交。

工作人员要从后台更新菜品信息，使顾客能看到菜品的最新情况。

1.4尚未解决的问题

说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。

2软件接口设计

2.1用户接口

说明将用户提供的输入数据和它们的语法结构，以及软件的回答信息。

2.2外部接口

说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。

3数据库结构设计

3.1概念结构设计

用E-R图说明本数据库将反映的现实世界中的实体、属性和它们之间的关系等的原始数据形式，包括各数据项的标识符、定义、类型、度量单位和值域，建立本数据库的每一幅用户视图。

3.2逻辑结构设计

说明把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构，形成本数据库的数据库管理员视图。

3.3物理结构设计

建立系统程序员视图，包括：

a．数据在内存中的安排，包括对索引区、缓冲区的设计；

b．所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分；

c．访问数据的方式方法。

4运用设计

4.1数据字典设计

对数据库设计中涉及到的各种项目建立数据字典，以说明它们的标识符、同义名及有关信息。

在本节中要说明对此数据字典设计的基本考虑。

4.2安全保密设计

说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象，进行分别对待而获得的数据库安全保密的设计考虑。