软件需求说明书
专业:软件工程
姓名:管圣腾
学号:2014200747
老师:何滨
2014年12月
目录
-
项目介绍 1 1.1 项目背景与社会现状 1 1.2 项目意义 2 1.3 项目介绍 2 1.4 利益相关者分析 2
-
系统分析与设计 4 2.1 系统总体业务用例图 4 2.3 系统各模块用例分析 5 2.3.1 用户管理模块 5 2.3.2 饭店管理模块 13 2.3.3 菜品管理模块 15 2.3.4 订单管理模块 17 2.3.5 结算管理模块 23
-
词汇表 25 3.1 介绍 25 3.2 定义 25 3.3 内容 25 4 补充规约 27 4.1 介绍 27 4.2 定义 27 4.3 内容 27 4.3.1.范围 27 4.3.2.功能 27 4.3.3.可靠性 27 4.3.5.安全性 28 4.3.6.可扩展性 28 4.3.7.性能 28 4.4 运行环境要求 28 4.4.1 操作系统 28 4.4.2 浏览器 28 4.4.3 数据库 28 4.4.4 服务器 29
-
项目介绍
1.1 项目背景与社会现状
随着互联网时代的到来,从整个ICT(Information Communication Technology,信息、通信、技术)产业来看,经历了五个计算周期,从大型机、小型机 、桌面互联网到移动互联网,第五个发展周期已经到来。这个是移动互联网和移动智能 终端引领的。如果从整个人类社会生活角度来看,其实移动智能终端带来的作用也是非 常重要的,它将是人类历史上第四个广泛渗透、迅速普及,在人类社会生活当中起着重 要作用的终端。
现在绝大部分80后、90后甚至很多00后都是互联网的重度用户,虽然我国接触网络的时 间与西方国家相比,不光是起步晚,发展速度也落后西方国家和日本很大一截。也随着 互联网时代的到来,人们的整体素质在不断的提高,更多的人选择在更加方便的手机终 端进行一些生活必须的操作,越来越多的人习惯于用手机来进行购物消费,而不再拘泥 于传统的一些方式。而且,由于我们国家自身的一些特殊的因素,比如,最近十几年国 家的重视,我国人口基数较大,我国国民经济发展势头良好,人们的购买能力和消费水 平都在不断提升,由于技术的进步智能终端产品的成本在降低等。使得我国移动终端的 增速远远超过发达国家,远远超过全球的平均水平。就拿2011年来说,我国的移动终端 出货量超过1.1亿部,之后的几年也都保持非常高的增长速度。
另外,从操作系统的角度看,Android操作系统战友市场的速度远远超乎想象,在整个全 球智能终端里面,它占有的市场份额超过原来的Windows系统在PC端的份额,2013年年底 ,据IDC(Internet Data Center:互联网数据中心)的调查报告显示,搭载Android系统的智能手机出货量占比首 次突破80%,这是一个多么惊人的数字。而且,在未来很长的一段时期,这个占比会令人 更加惊讶。还有一点值得注意的就是,我国的用户或者产业对新生事物的接受速度远远 超过了全球其他的国家,包括发达国家。全球市场除了中国的数据外,Android只占了新 增终端50%的市场,而中国则占了90%,这是中国市场的特点和需求的特点,和全球其他 地区和国家有着很大的区别。
1.2 项目意义
通过深入了解用户的需求和市场现状,发现不少单位的员工因为工作的需要和快节奏 的工作生活需要,中午需要在公司就餐,而绝大多数公司是没有食堂的,只能从外面的 一些饭店定餐,往往菜品少,没有多少选择项,对菜品质量也无法回馈,饭店也一般只 有一家可选,竞争小。 这样的话,对雇主企业来说,可以作为一项公司给员工的福利,更好的满足员工的需 求,改善公司员工的饮食状况,也会间接的带动公司的效益,提高公司的收益;对员工 来说,每天的饭菜都可以很多的选择机会,吃上自己喜欢的饭菜,自然工作效率就提高 了,也有助于实现自身的价值;对饭店来说,一方面,有了这款APP,他们的销量会比以 往多很多,利润自然有所增加,另外一方面,参与竞争的饭店多了之后,就有助于饭店 提升饭菜品质,降低价格。这样的话,整个就成了一个良性的循环,各方面都获益。
1.3 项目介绍
本项目就是通过对用户对公司定餐的需求研究出发,通过深入了解用户的需求,建立 一个基于C/S结构公司员工定餐管理系统,实现用户的对自己菜品的管理,自己点餐,自 动结算,多饭店对比,菜品图片展示等功能。
1.4 利益相关者分析
此系统主要面向广大的公司上班的职业人员、饭店所有者、系统维护人员。不同的用 户群体有不同特点。下面通过市场调查和分析,对相关人群的特点做一个简单的分析和 归纳。 普通用户:也就是本系统的实际消费者,这类人主要是上班族,接触互联网的机会非 常多,他们更倾向于使用移动设备进行消费和娱乐,很容易向他们推广本APP。 饭店所有者:随着互联网的发展,越来越多的饭店使用信息化管理工具,饭店之间的 竞争也越来越激烈,本款APP可以有效的提高他们饭店的知名度和销售额,向他们推广的 成本比较低。 系统维护人员:拥有系统维护相关专业知识的人,为了便于系统的维护,需要为维护 人员提供友好的管理界面。
-
系统分析与设计
经过认真的分析,本系统主要有三类用户,一种是普通用户,也可以说是单纯的消费 者;第二种是饭店管理员,负责对饭店的信息进行维护和管理;第三种是系统管理员, 主要负责用户权限的管理,以及系统的一些维护操作。系统实行会员制,所有人员都必 须通过注册才能够使用本系统。 系统的主要功能有以下几方面:
-
用户管理 包括用户的注册管理、登录管理,用户信息的维护,用户权限的申请和审批管理。新 用户注册成功,登录后,可以对自己的信息进行完善。
-
饭店管理 包括饭店信息的维护。包括饭店的名称,饭店的图片,饭店的介绍等信息。饭店管理 的权限不是所有用户都具有的,必须是注册用户提出申请,然后等待管理员审批,通过 了之后,才有此权限。
-
菜品以及菜品图片的管理 包括菜品的增加、菜品信息的修改、菜品信息的删除、菜品状态的修改,菜品管理中 涉及到拍照上传,选择图片上传,并按照条件查询不同的菜品。此功能也是只有饭店管 理员才具有。
-
用户订餐管理 普通用户登录以后,可以分类查看菜品的信息,分类的条件包括按菜品类别,还可以 按照不同的饭店来查看;管理自己的订单,包括修改订单的状态,并进行菜品的评价。
-
结算管理 包括计算用户订餐总价,并提交订单,并且模拟支付。
-
2.1 系统总体业务用例图
系统的参与者有普通用户、饭店管理员、系统管理员以及第三方支付系统。 系统的总业务用例图: [pic] 图2-1系统总业务用例图
2.3 系统各模块用例分析
2.3.1 用户管理模块
[pic] 图2-2用户管理模块系统用例图
2.3.1.1用户注册用例
-
系统用例图 [pic] 图2-3用户注册系统用例图
-
用例规约 表2-1 注册用例规约 |用例名称 |注册用例 | |UC编号 |UC01 | |用例描述 |所有使用本系统的用户都必须是注册用户,即第一 | | |次使用之前要通过注册功能。只需在注册的时候提 | | |供唯一用户名(系统后台会自动进行用户名查重操 | | |作)、手机号,以及密码即可,其他的附加信息( | | |用户性别、用户邮箱、用户姓名、用户常用地址等 | | |信息)可以在登录成功之后,由用户自行选择是否 | | |进行填写,不填写也不会影响用户使用本系统。 | |前置条件 |用户必须使用基于Android2.2以上系统的智能机, | | |并且安装此款APP | |基本(主要)事件流 |1)打开本系统,跳过欢迎界面,到达登录界面; | | |2)之前未注册过账号,点击界面中的“注册”按钮;| | |3)进入注册界面,输入自己的手机号,点击“提交”| | |按钮; | | |4)收到短信验证码,输入短信验证码,点击“提交”| | |按钮,注册成功,并进入系统。 | |其他(替代)事件流 |3a)输入的手机号不符合要求,不是有字母、未到1| | |3位等输入错误问题,回到基本事件流3,供用户重 | | |新输入; | | |3b)手机号已经被注册了,收到提示,并提示直接 | | |登录系统,供用户重新输入; | | |3c)手机号码输入错误(但是手机号码是正确的格 | | |式),提示已发送手机验证码,但是手机未收到短 | | |信,回到基本事件流3,供用户重新输入; | | |4a)输入验证码出现错误,回到基本事件流4,供用| | |户重新输入。 | |异常事件流 |1a)系统提示错误,系统兼容性出现问题,用例执 | | |行失败; | | |3d)网络异常,点击提交,系统没有反应,用例执 | | |行失败。 | |后置(事后)条件 |暂无。 | |特殊需求 |暂无。 |
-
活动图 [pic] 图2-4用户注册活动图
2.3.1.2用户登录用例
-
系统用例图 [pic] 图2-5用户登录系统用例图
-
用例规约 表2-2 登录用例规约 |用例名称 |登录用例 | |UC编号 |UC02 | |用例描述 |已通过注册的用户,可以使用注册的账号和密码进 | | |行系统的登陆操作,即在登录页面,输入用户名和 | | |密码,点击登录即可。如果用户名和密码验证成功 | | |,则系统会自动跳转进入系统主界面,验证失败的 | | |话,则会提示用户重新输入或者注册账号。 | |前置条件 |用户必须已经是注册用户。 | |基本(主要)事件流 |1)打开本系统,跳过欢迎界面,到达登录界面; | | |2)之前已注册过账号,输入账号、密码,并点击界| | |面中的“登录”按钮; | | |3)验证成功,成功进入系统主界面。 | |其他(替代)事件流 |2a)输入的手机号不符合要求,不是有字母、未到1| | |3位等输入错误问题,回到基本事件流2,供用户重 | | |新输入; | | |2b)账号、密码验证失败,回到基本事件流2,供用| | |户重新输入; | |异常事件流 |1a)系统提示错误,系统兼容性出现问题,用例执 | | |行失败; | | |2c)忘记密码,点击“忘记密码”,需执行其他的操 | | |作,用例执行失败; | | |2d)网络异常,点击提交,系统没有反应,用例执 | | |行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
-
活动图 [pic] 图2-6用户登录活动图
2.3.1.3用户登录用例
-
系统用例图 [pic] 图2-7用户信息维护系统用例图
-
用例规约 表2-3 个人信息维护用例规约 |用例名称 |个人信息维护用例 | |UC编号 |UC03 | |用例描述 |用户在登录状态可以对自己的信息进行维护,比如 | | |真实姓名、性别、邮箱等信息,注册时提供的手机 | | |号原则上不能更换,如果一定要换的话,要提交申 | | |请,管理员同意才行。 | |前置条件 |用户必须已经成功登陆系统。 | |基本(主要)事件流 |1)成功登陆系统; | | |2)点击进入“个人中心”; | | |3)对个人信息进行维护; | | |4)点击“修改密码”,进入密码修改界面,输入原密| | |码,验证通过后输入新密码,提交,显示修改成功 | | |。 | |其他(替代)事件流 |3a)填写的某些信息条目不符合输入要求,比如不 | | |是有效邮箱等,回到基本事件流3,供用户重新输入| | |; | | |4a)原密码验证失败,回到基本事件流4,供用户重| | |新输入; | | |4b)两次新密码输入不一致,回到基本事件流4,供| | |用户重新输入。 | |异常事件流 |3d)网络异常,点击提交,系统没有反应,用例执 | | |行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
-
活动图 [pic] 图2-8用户信息维护活动图
2.3.1.4权限的申请
-
系统用例图 [pic] 图2-9权限申请系统用例图
-
用例规约 表2-4 申请权限用例规约 |用例名称 |申请权限用例 | |UC编号 |UC04 | |用例描述 |注册成功后,就可以进行菜品的购买,对订单中的 | | |菜品进行评价,但是用户没有权限去管理自己的饭 | | |店。因此,如果用户想在此平台开自己的饭店,这 | | |就需要向系统管理员提出申请,得到系统管理员审 | | |核通过之后才可以拥有饭店管理权限。 | |前置条件 |用户必须已经成功登陆系统,并拥有申请开饭店的 | | |资料。 | |基本(主要)事件流 |1)成功登陆系统; | | |2)点击进入“饭店管理中心”; | | |3)之前未申请过,或者申请未成功的情况下会提示| | |跳转到申请页面;如果申请已提交,但在审核中, | | |提示等待; | | |4)管理员审批; | | |5)审批通过,成功进入饭店管理中心。 | |其他(替代)事件流 |3a)填写的某些信息条目不符合输入要求,比如不 | | |是有效邮箱等,回到基本事件流3,供用户重新输入| | |并提交; | | |4a)各种原因,导致审核未通过,回到基本事件流3| | |,供用户重新输入并提交; | |异常事件流 |3a)网络异常,点击提交,系统没有反应,用例执 | | |行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
-
活动图
[pic] 图2-10权限申请活动图
2.3.2 饭店管理模块
2.3.2.1饭店管理
-
系统用例图 [pic] 图2-11饭店信息维护系统用例图
-
用例规约 表2-5 饭店信息维护用例规约 |用例名称 |饭店信息维护用例 | |UC编号 |UC05 | |用例描述 |普通用户不具有饭店管理的功能,在申请饭店管理 | | |权限之后,用户即可访问此模块,第一次访问此模 | | |块,饭店的信息都是空的,用户需要在第一次访问 | | |的时候进行添加,包括饭店的图片、饭店的名称、 | | |饭店的地址、饭店简介、订餐电话等信息。用户可 | | |以选择是否添加。 | |前置条件 |用户必须提交饭店申请,并获得管理员的审核通过 | | |。 | |基本(主要)事件流 |1)成功登陆系统,并进入饭店管理中心; | | |2)查看饭店基本信息; | | |3)添加饭店基本信息; | | |4)修改饭店基本信息; | | |5)删除饭店某些信息条目。 | |其他(替代)事件流 |3a)填写的某些信息条目不符合输入要求,比如不 | | |是有效邮箱、不是邮箱联系电话等,回到基本事件 | | |流3,供用户重新输入并提交; | | |4a)填写的某些信息条目不符合输入要求,比如不 | | |是有效邮箱、不是邮箱联系电话等,回到基本事件 | | |流4,供用户重新输入并提交; | |异常事件流 |3a)网络异常,点击提交,系统没有反应,用例执 | | |行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
-
活动图 [pic] 图2-12饭店信息维护活动图
2.3.3 菜品管理模块
2.3.3.1 菜品信息维护
-
系统用例图 [pic] 图2-13菜品信息维护系统用例图
-
用例规约 表2-6 菜品信息维护用例规约 |用例名称 |菜品信息维护用例 | |UC编号 |UC06 | |用例描述 |拥有饭店管理权限的用户登录系统,进入饭店管理 | | |中心,点击查看所有菜品,即跳转到本饭店的所有 | | |菜品页面,显示在一个列表中。点击添加菜品按钮 | | |,可以进行菜品信息的填写,并提交;选中某个菜 | | |品,跳转到菜品编辑页面,用户可以修改相关信息 | | |;长按某个菜品,可以在弹出的菜单中选择是否删 | | |除。 | |前置条件 |用户必须处于登陆状态,并已经获得饭店管理权限 | | |。 | |基本(主要)事件流 |1)成功登陆系统,并进入饭店管理中心; | | |2)查看菜品信息; | | |3)添加菜品信息; | | |4)修改菜品信息; | | |5)删除菜品信息条目。 | |其他(替代)事件流 |3a)填写的某些信息条目不符合输入要求或者未填 | | |写某些必须条目,回到基本事件流3,供用户重新输| | |入并提交; | | |4a)填写的某些信息条目不符合输入要求或者未填 | | |写某些必须条目,回到基本事件流4,供用户重新输| | |入并提交; | |异常事件流 |3a)网络异常,点击提交,系统没有反应,用例执 | | |行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
-
活动图 [pic] 图2-14菜品信息维护活动图
2.3.4 订单管理模块
- 订单管理模块系统用例图 [pic] 图2-15订单管理模块用例图
- 订单管理模块活动图 [pic] 图2-16订单管理模块活动图
2.3.4.1 浏览菜品
- 系统用例图 [pic] 图2-17浏览菜品系统用例图
- 用例规约 表2-7浏览菜品用例规约 |用例名称 |浏览菜品用例 | |UC编号 |UC07 | |用例描述 |所有用户在登录成功后,就可以看见菜品的分类, | | |类别有优选推荐、快餐套餐、面类米线、甜点小吃 | | |等,可以点击自己想要的菜品类别,进行浏览,菜 | | |品页面首先是所有此类菜品的一个列表,有图片描 | | |述,也有文字描述,还可以点击进入,查看详情, | | |在详情页面中可以查看当前菜品的评价信息。 | |前置条件 |用户必须已经成功登陆系统。 | |基本(主要)事件流 |1)成功登陆系统,; | | |2)浏览菜品信息; | |其他(替代)事件流 |暂无 | |异常事件流 |2a)网络异常,系统没有反应,用例执行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
2.3.4.2 提交订单
- 系统用例图 [pic] 图2-18提交订单系统用例图
- 用例规约 表2-8 提交订单用例规约 |用例名称 |提交订单用例 | |UC编号 |UC08 | |用例描述 |用户浏览完了菜品,选定自己想要购买的菜品之后 | | |,并填写订单信息,即可以提交订单。 | |前置条件 |用户必须已经成功登陆系统。 | |基本(主要)事件流 |1)成功登陆系统; | | |2)浏览菜品信息; | | |3)选定某个想要购买的菜品,点击购买; | | |4)填写订单接收者的基本信息:姓名、联系电话和| | |联系地址; | | |5)确定提交,生成订单。 | |其他(替代)事件流 | | |异常事件流 |2a)网络异常,系统没有反应,用例执行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
2.3.4.3修改订单状态
- 系统用例图 [pic] 图2-19修改订单状态系统用例图
- 用例规约 表2-9 修改订单状态用例规约 |用例名称 |修改订单状态用例 | |UC编号 |UC09 | |用例描述 |用户浏览完了菜品,选定自己想要购买的菜品之后 | | |,并填写订单信息,即可以提交订单。 | |前置条件 |用户必须成功提交订单,并使用第三方支付系统付 | | |款成功。 | |基本(主要)事件流 |1)用户、饭店管理员成功登陆系统; | | |2)管理员查看付款状态,确认付款后,发货,然后| | |将菜品送出,并修改订单状态为已发货; | | |3)送货; | | |4)用户查看订单; | | |5)用户确认收货,将订单状态改为已收货 | |其他(替代)事件流 |2a)查看订单,发现订单还未发货,可以电话联系 | | |饭店管理员,回到基本事件流2; | | |2b)用户在付款后,申请退款,成功后,订单状态 | | |修改为已退款状态,事件流结束; | | |3a)用户地址或联系方式预留有误,回到基本事件 | | |流2,饭店管理员联系用户修改; | | |5a)用户收到货,未及时将订单状态改为已收货, | | |等待用户或者,饭店管理员电话联系用户,提醒用 | | |户,回到事件流3 | |异常事件流 |2a)网络异常,系统没有反应,用例执行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
2.3.4.4评价菜品
- 系统用例图 [pic] 图2-20评价菜品系统用例图
- 用例规约 表2-10 评价菜品用例规约 |用例名称 |评价菜品用例 | |UC编号 |UC10 | |用例描述 |用户购买成功某菜品后,可以在在订单管理查询到 | | |订单,在用户确认收货之后,用户即可对当前订单 | | |中的菜品进行评价,会跳转到单独的一个评价界面 | | |,用户可以填写评分和具体评价内容,并提交自己 | | |的评论。这里设计的是可以多次评论,即用户可在 | | |此对本订单中的菜品进行评价。 | |前置条件 |用户必须确认收货。 | |基本(主要)事件流 |1)用户成功登录系统; | | |2)消费完之后,确认收货; | | |3)进入订单管理,提交相关菜品的评价信息。 | | |4)系统检测通过后,菜品评价信息展示,供所有用| | |户查看。 | |其他(替代)事件流 |2b)用户在消费完了之后,不进行评价,超过了系 | | |统规定的最长时间,系统自动给出好评。 | |异常事件流 |2a)消费过程中,发现菜品有质量问题,申请退货 | | |,事件流执行失败; | | |3a)用户恶意注水差评,系统检测,予以屏蔽,并 | | |做相应处理; | | |2b)网络异常,系统没有反应,用例执行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
2.3.5 结算管理模块
2.3.5.1评价菜品
-
系统用例图 [pic] 图2-21结算管理系统用例图
-
用例规约 表2-11结算管理用例规约 |用例名称 |结算管理用例 | |UC编号 |UC011 | |用例描述 |提交订单完成后,系统会提示用户,是否马上付款 | | |,如果用户选择直接付款,则会跳转到支付页面, | | |并通过第三方支付软件进行支付。 | |前置条件 |用户必须提交了订单,并拥有第三方支付系统的账 | | |户,比如支付宝、财付通、网银快捷支付等。 | |基本(主要)事件流 |1)用户成功登录系统; | | |2)选中某个菜品,成功提交订单; | | |3)查看订单状态,系统提示是否马上付款; | | |4)选择马上付款,则跳转到支付系统的界面,输入| | |支付系统的账户、密码,并确认付款; | | |5)提示付款成功。 | |其他(替代)事件流 |4a)选择稍后付款,其他操作完了之后,进入订单 | | |管理中,查看未付款订单,点击马上付款,回到基 | | |本事件流4,供用户支付订单; | | |4b)用户在输入第三方支付系统的账户信息后,由 | | |于账户余额不足,提示用户,并回到基本事件流3,| | |等用户充值完成后,再支付; | | |4c)用户在付款过程中,选择取消,回到基本事件 | | |流3,等用户再操作。 | |异常事件流 |2a)消费过程中,发现菜品有质量问题,申请退货 | | |,事件流执行失败; | | |2b)网络异常,系统没有反应,用例执行失败。 | |后置(事后)条件 |暂无 | |特殊需求 |暂无 |
-
词汇表
3.1 介绍
此文件用于定义特定术语的问题域,这可能是不熟悉的用例描述或其它项目文件的阅 读器。通常情况下,这个文件可以作为一个非正式的数据字典,数据采集定义,这样的 用例描述和其他项目文件专注于系统必须做的是什么信息。
3.2 定义
该词汇表包含了定义在基于Android的订餐管理系统中的关键概念。
3.3 内容
在订餐和软件行业中,有一些常用的术语,为方便本文的叙述,现对其说明如下:
- 订单 用户通过本系统,选中了菜品,然后填写了一些必须的信息之后,提交后,产生的一 条记录,成为订单。
- 订单状态 订单总共分为0-未付款,1-已付款,2-已成交,3-已评价,4-已取消,5- 已退款。用户提交了订单之后,订单即为未付款状态,用户使用第三方支付系统支付了 订单,订单即为已付款状态,用户收到货后,即为已成交状态,用户评价完了之后,订 单即为已评价状态,订单提交成功,但未付款,用户取消订单,即为取消状态,用户不 满意,退货退款,之后订单即为已退款状态。
- 在线支付
在线支付是指卖方与买方通过因特网上的电子商务网站进行交易时,银行为其提供网上 资金结算服务的一种业务。它为企业和个人提供了一个安全、快捷、方便的电子商务应 用环境和网上资金结算工具。在线支付不仅帮助企业实现了销售款项的快速归集,缩短 收款周期,同时也为个人网上银行客户提供了网上消费支付结算方式,使客户真正做到 足不出户,网上购物。 4. 第三方支付
第三方支付本身集成了多种支付方式,流程如下:1、将网银中的钱充值到第三方。2、 在用户支付的时候通过第三方中存款进行支付。3、花费手续费进行提现。第三方的支付 手段是多样的,包括移动支付和固定电话支付。最常用的第三方支付是支付宝、财付通 、环迅支付、易宝支付、快钱、网银在线了,其中做为独立网商或有支付业务的网站而 言,最常选择的不外乎支付宝、环迅支付、易宝支付、快钱这四家。 5. 评价系统 经济的飞速发展致使各行各业的竞争日益激烈,对于客户服务质量标准的要求也越来 越高。如何提高单位的服务质量,提高服务人员的工作积极性是摆在单位领导面前的一 迫切问题。为提高服务人员的服务质量,提升服务顾客满意度,开发出的服务评价系统 。评价系统的开发能够帮助顾客办理完业务之后,请顾客对服务人员的服务质量进行评 价,方便管理者对服务人员的服务质量进行统计,促进企事业单位改进服务,提高客户 满意度。 6. 业务用例图和系统用例图 业务用例是描述这个业务的具体工作流的;一次涉众与实现业务目标的业务之间的交 互。它可能包含手工和自动化的过程,也可能发生在一个长期的时间段中。业务用例是 站在系统外看系统的功能,也就是说以整个系统为研究对象的 它是由业务执行者发起 系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者,与计算 机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系,而不是业务 过程。着重系统的控制流、数据流和功能。 7. 网上订餐 顾名思义,网上订餐就是互联网的深入应用。用户通过互联网,能足不出户,轻松闲 逸地实现自己订购餐饮和食品(包括饭、菜、盒饭、便当等)的一种网络订餐形式 8. 移动端APP:移动应用服务,就是针对手机这种移动连接到互联网的业务或者无线网卡业 务而开发的应用程序服务。
4 补充规约
4.1 介绍
补充规约的目的是定义了基于Android系统的订餐管理系统的要求,是对系统规约的
进一步补充说明,对在需求规约中未涉及到和遗漏的功能和行为进行说明解释。
4.2 定义
对在需求规约中未涉及到和遗漏的功能和行为进行说明。
4.3 内容
4.3.1.范围
面向公司上班的上班族,以及饭店所有者。
4.3.2.功能
至少满足100人可同时正常访问系统。
4.3.3.可靠性
凡合法用户可以再任意地方正确无误的访问系统中的信息。系统的故障率控制在1次 /周之内。
4.3.4.可维护性
系统故障可以再24小时内得到解决。
4.3.5.安全性
只有注册的用户才可以访问,用户通过手机号码注册账号,用户的手机号码会被系统 严格的保密,绝对不会泄露给任何第三方。并且用户的密码等敏感信息全部通过MD5加密 算法加密存储,进一步保护用户的隐私安全。
4.3.6.可扩展性
系统后台采用ssh框架,已分层架构进行系统设计使系统的拓展性大大提高。
4.3.7.性能
在正常网络条件下,文本显示不得超过1秒,地图的显示不得超过2秒;采用简洁友好 的图形用户界面风格,设计用户界面
4.4 运行环境要求
4.4.1 操作系统
【服务器端】 Windows7、Windows8/8.1 【移动终端】 基于安卓2.2+系统的智能手机终端
4.4.2 浏览器
服务器端管理员通过浏览器管理并维护整个系统,支持目前主流的浏览器:chrome, Firefox,ie8+,360浏览器,qq浏览器等。
4.4.3 数据库
Mysql5.5
4.4.4 服务器
Tomcat7.0