员工订餐系统需求规格说明书
网上订餐系统需求规格说明书
<网上订餐系统 >需求规格说明书撰写人（署名）：完成日期：评审负责人（署名）：评审日期：目录1.前言 ......................................................错误 ! 不决义书签。
目的 . ...............................................错误 ! 不决义书签。
定义 . ...............................................错误 ! 不决义书签。
登录模块： . ...........................................错误 ! 不决义书签。
用户注册模块 . .........................................错误 ! 不决义书签。
购物车模块： . .........................................错误 ! 不决义书签。
订单模块： . ...........................................错误 ! 不决义书签。
基本信息管理模块： . ...................................错误 ! 不决义书签。
通告模块： . ...........................................错误 ! 不决义书签。
参照资料 . ...........................................错误 ! 不决义书签。
2.整体概括 . .................................................错误 ! 不决义书签。
产品表记 . ...........................................错误 ! 不决义书签。
产品描绘 . ...........................................错误 ! 不决义书签。
订餐系统说明书
订餐系统说明书(总7页) -CAL-FENGHAI.-(YICAI)-Company One1-CAL-本页仅作为文档封面，使用请直接删除订餐系统说明书V3.5一、软件优势订餐系统是一套解决因普通消费机不能订餐而衍生的一套综合性订餐消费管理系统，其优势主要表现在：1）卡类消费模式很灵活：可以根据需要设置不同的消费类型卡。
2）可以限制卡是否同一餐别进行多次订餐或多次刷卡消费。
3）充值灵活：可实现单卡充值、批量充值、卡类充值。
4）员工可以通过电脑、手机进行在线订餐：方便使用电脑的可以使用PC端在线订餐，不方便使用电脑的可以安装手机APP进行在线订餐。
5）PC端或手机APP都很方便对未来餐别的订餐和点菜进行撤消。
6）餐厅厨房可以随时了解某一天、某一餐别的订餐情况和点菜情况。
7）刷卡时可以根据订餐情况、点菜情况进行不同扣费：如：订了餐再用餐的扣费不同、没有订餐就去用餐的扣费又不同、点菜时扣费不同、不同卡扣费不同、不同餐别扣费不同等。
8）餐厅刷卡端界面可以随意调整色调和背景。
9）餐厅刷卡提示更人性化：支持声音提示、语音提示、声音+语音提示。
10）餐厅支持离线刷卡，即使断网、服务器崩溃了都可消费刷卡。
11）P C端在线订餐支持通告发布和留言管理。
12）外卖送餐的支持在线刷卡扣费。
二、启用流程订餐系统由后台管理、餐厅刷卡端、PC版在线订餐、手机APP在线订餐和手机APP在线刷卡等多个程序端进行组成，为了实现软件的最佳效果，请遵循下面的流程来启用软件：1）员工档案：录入员工信息。
2）餐厅设置：录入公司餐厅（食堂）名称，方便订餐统计分类。
3）餐别设置：系统默认分早餐、午餐、晚餐、宵夜4个餐别，用户可能根据需要删除不要的餐别。
4）菜品设置：录入所有菜品信息。
5）每周菜谱：设置每周一到周日，每个餐别的菜品。
如早餐有什么菜、午餐有什么菜?6）7）卡类设置：设置每种卡的消费模式，如：消费模式有：A)标准模式：按指定餐别、订餐与否、点菜与否进行不同扣费。
订餐系统需求分析说明书
需求分析说明书该文档描绘网上订餐系统需求，包括功能需求分析，性能需求分析，业务需求分析，数据需求分析。
1.1文档范围本文档包含以下几个局部:<1>. 文档介绍<2>. 产品介绍<3>. 产品面向的用户群体<4>. 功能需求分析<5>. 性能需求分析<6>. 业务需求分析<7>. 数据需求分析<8>. 运行环境规定1.2读者对象数据库设计者，代码编写者1.3 参考文档[1]软件工程-----理论者的研究方法机械工业出版社原书第六版[2]Java程序设计清华出版社雍俊海[3]Web编程技术机械工业出版社厉小军主编[4]数据库原理及其应用教程第二版黄德才主编科学出版社2.1背景当今社会的生活节奏越来越快，人们对餐饮的要求也越来越高，不仅要求色香味俱全，而且对于就餐的时间和方式也有了更高的要求，许多顾客由于工作繁忙无法抽出时间来享受美味，这样就产生了快捷订餐的要求，最快的方式莫过于利用计算机网络，将餐饮业和计算机网络结合起来，就形成了网上订餐系统，用才能的餐饮企业对对餐品提供商提供网上订餐效劳，不仅进步餐饮企业的效劳质量，扩大知名度，也是为最终用户提供方便快捷的食品效劳。
社会对餐饮的快捷性要求形成了对网上订餐的要求，该工程将使用javaWeb技术的servlet+jsp+javaBean实现快捷的开发与部署，并且可以最大限度的保证系统的稳定性。
网上订餐系统将极大的方便食客的就餐，同时也有利于我们的管理和售后效劳。
同时，我们的订餐系统还能帮助我们的酒店〔餐馆〕扩大营业范围，增加知名度等。
2.2产品的功能<1>.菜色展示系统菜色展示系统是一套基于数据库平台的即时发布系统，可用于各类菜色的展示、添加、修改和删除等。
网站管理员可以管理菜色简介、价格、图片等多类信息。
阅读者在前台可以阅读到菜色的所有资料，如菜色价格和详细介绍等菜色信息。
矿业职工订餐管理系统项目需求说明书
矿业职工订餐管理系统项目需求说明书2017年11月矿业编制：业务单位审批：方案审核：目录1. 项目背景及需求 22. 系统建设目标 33. 系统建设内容 33.1. 就餐中心刷卡付款系统 3 3.1.1. 刷卡流程图 3 3.1.2. 卡务管理平台 5 3.1.3. 中心就餐系统软件7 3.1.4. 数据集中与交互9 3.1.5. 刷卡系统所需报表：93.2. 远程职工手机订餐14 3.2.1. 用户手机微信小程序15 3.2.2. 个人手机微信订餐部分功能说明19 3.2.3. 订餐系统统计报表273.3. 井下订餐284. 项目费用预算28 4.1. 就餐中心刷卡付款系统预算284.2. 远程职工手机订餐系统预算305. 其他说明301.项目背景及需求矿业分公司因企业发展需要，采用集中就餐，降低运行成本，提升服务职工就餐质量改革。
为此，需要取消原选矿区域就餐中心、升级改造副井、机关就餐中心，同时将井下餐地面零散就餐方式改变为集中至副井就餐中心。
公司现有职工订餐情况：目前职工就餐有两种方式，分别是井下就餐系统刷卡订餐，用户是经过公司人事部审核确认具有井下餐就餐员，系统刷卡部分为理达公司模块，系统管理层纳入生产管理系统中订餐管理子系统模块，兼顾网上订餐、领导值班订餐、报表等功能，较好实现了井下职工就餐需求和日常管理，但是无法满足细化管理要求，即下井职工与井下就餐人员统计分析；另外是地面刷卡就餐，采用规定时间随到随吃的方式，就餐地点（三个就餐点）、就餐人数、就餐时间的不确定性导致做菜过多造成原材料的浪费或者职工对菜品的不满意，同时理达刷卡系统设备技术老旧（运行时间达15年），故障率逐年上升。
根据公司2017年11月16日会议要求，各相关单位明确需求，该系统满足以较低成本，稳定技术，开发该系统满足矿业职工生产经营中用餐问题。
2.系统建设目标系统上线时间：2018年1月25日系统使用范围：矿业在职正式职工系统原则：1、优质化服务员工2、按需制作，杜绝浪费，节约成本3、搭建现代化管理模式，提升管理水平3.系统建设内容3.1. 就餐中心刷卡付款系统将原就餐刷卡系统升级，主要更新原老化服务器、POS机、IC卡、结算平台软件，公司中心机房托管，满足环境和集中备份要求。
酒店餐饮管理系统的需求规格说明书
软件需求规格说明书1软件需求说明引言1.1编写目的为了说明编写本软件所需要的数据，所拥有的功能、性能及对功能、性能的规定，对所需设备、运行环境等的要求。
预期读者为本小组的开发人员。
1.2背景说明：a．软件系统的名称：酒店餐饮管理系统。
b．本项目的任务的开发者：面向用户：酒店餐饮的前台服务员、厨房管理员、原材料的供货部门以及经理部门的管理人员。
实现该软件的计算中心或计算机网络：支持Windows98对等网和NT/2000网络。
1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料本软件开发的《可行性研究报告》、《项目开发计划》、用户手册、软件工程导论（清华大学出版社张海藩）数据库原理及应用2任务概述2.1目标本餐饮管理系统广泛适用于中、小型餐饮行业、咖啡厅、饭店、酒楼、等场所。
为方便酒店管理人员更有效的管理酒店而开发。
该系统可以帮助餐饮企业处理日常工作业务,规范管理工作和操作流程,是餐饮行业的得力助手。
另外，本餐饮管理系统具有强大的统计分析功能，可以帮助经营者分析自己企业的经营状况。
比如可以很方便的统计出任意一天、任意一段时间的营业额，使对自己的企业经营状况了如指掌；可以统计出任意一段时间的菜品销售排行榜，可以按照各菜品的销售额、销售数量、利润等任意排行，使你清楚的了解贵公司哪些菜品顾客最喜欢、哪些菜品利润最高，进而可以分析这样的菜品为什么顾客比较喜欢，从而为贵公司的经营决策提供了科学依据；以及统计出任意一段时间的平均客流时段分析等。
本餐饮管理系统属小型网络系统，可应用于酒店中的餐饮部门以及咖啡厅、饭店、酒楼、等场所，具有一定的独立性。
2.2用户的特点本餐饮管理系统对用户的教育水平与技术专长要求不高，一般只要求具备电脑操作基本知识，会打字就可以了。
维护人员为本小组开发人员，均为计算机专业本科教育，懂得VC++6.0编程，数据库管理等相关技术。
2.3假定和约束a.系统可以长期运行，版本也可以不断升级，来满足用户的新需求。
员工订餐系统需求规格说明书
编码：WXRT-SMSFE-E-RD-R01 XXX科技有限公司员工订餐系统(RSMS)系统需求规格说明书拟制人 _______________ 日期_________________审核人 _______________ 日期_________________批准人 _______________ 日期_________________更改控制业目录1文档介绍目的在系统的完成目标方面，为客户和开发者建立共同协打下基础。
对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求。
提交开发效率，使开发人员在设计开始之前，周密的思考全部需求，从而减少事后重新设计、重新编码、重新测试的反工活动。
加强对需求内容的检查和复查，尽可能的在开发早期发现遗漏、错误的理解和和不一致性，以便及时加以纠正。
为正本计价和编制计划进度提供基础。
通过需求分析帮助项目组更加合理的进行项目估算。
为确认需求和验证需求提供一个基准。
便于对需求进行双向跟踪。
便于系统移植、功能扩展和后期维护。
总的来说本说明书的目的在于明确说明系统需求，界定系统实现功能的范围，指导系统设计及编码范围本文档作为系统概要设计、详细设计、数据库设计的根据和对文档以及项目的验收依据，所有设计都要围绕需求规格说明书来进行。
读者对象项目组所有成员、需求提出者以及一些相关领导参考文档术语与缩写解释2 产品介绍由于天气炎热，给员工外出就餐带来不便，加上大学城各大高校进入假期，很多食堂餐厅停业，因此员工的午餐问题急需解决。
在公司高层领导的关注下，大学城XXX科技公司，JAVA研发小组迅速组建研发小组，经过轮番讨论设计，最终确定研发RSMS员工订餐系统，为员工提供良好的订餐平台，更有效、更方便的解决员工就餐问题。
系统主要分为两大功能模块，一个是系统前台用户部分，主要面向公司内部员工订餐活动；另一个是平台管理员部分，主要是管理员工的订单以及商家管理，包括菜肴的更新以及商家信息的更新，和一些平台管理的日常辅助功能。
网上订餐系统需求规格说明书(模板)
网上订餐系统需求规格说明书组名：指导老师：组员：目录1.引言1.1 编写的目的 (4)1.2 背景 (4)1.3 定义 (4)1.4 参考资料 (4)2.任务概述2.1 目标 (4)2.2 用户的特点 (5)2.3假定和约束 (5)3.需求规定3.1对功能的规定 (5)3.2 对性能的规定 (7)3.2.1精度 (7)3.2.2时间特性要求 (7)3.2.3灵活性 (7)3.3输入/输出要求 (7)3.4数据管理能力要求 (7)3.5故障处理要求 (7)3.6其他专门要求 (7)4.运行环境规定4.1 系统软件配置 (8)4.2 硬件配置 (8)1. 引言1.1编写目的此立项报告旨在确定本项目的基本目标、主要内容，设计实现的流程、工作负荷、费用开支、人员结构、设备情况、局限性，运行设计的项目时间总体规划、进度分段标准、阶段考核方法，以及项目验收方式、提交的内容清单、后续工作情况。
1.2背景员工到食堂用餐，在路途和排队上浪费很多时间，并且去晚了经常会吃不到想吃的食物；员工对食堂的满意度不高，有将近一半的员工会选择去周边饭店用餐。
因此，食堂更无法准确预测员工需求，经常会出现有些食物因为没有卖出去只好倒掉，而员工需要的一些食物却已卖完的现象。
1.3定义本产品是为餐厅专门开发的一套订餐管理系统，旨在合理化安排餐厅的工作，提高餐厅的管理效率，同时方便员工就餐。
1.4 参考资料《软件系统分析与设计》、《需求分析最佳实践》。
2.任务概述 2.1目标开发网上报餐系统节省员工的时间和精力，避免食堂食物的浪费，同时让每位就餐员工都吃到满意的食物，提高服务质量以及员工对餐厅的满意度。
此系统非独立结构，它依赖与已经搭建好的网络平台和后台的数据库管理软件如下图所示：Internet 数据接口程序图2.1-12.2用户的特点该软件的最终用户为开放的网络中有餐饮需求的用户，包括服务提供者和消费者，他们无需特定的计算机技能，2.3假定和约束该系统所开发的在特定的系统环境支持下进行如协议限定，因而难以保障它在多层次网路结构中能够安全、稳定的运行，同时加上开发水平的限定很难保证进行全面深入的测试工作，以及现在网络设备的发展导致接入成本增加和软件开发成本限定，使得一系列的问题难以解决，这都需要软件使用者根据自身的发展需求来定制相应的软件。
订餐系统详细设计说明书
详细设计说明书1、引言：1、1编写目的：在前一阶段（概要设计说明书）中，已解决了实现该系统需求的程序模块设计问题。
包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。
在以下的详细设计报告中将对在本阶段中对系统所做的所有详细设计进行说明。
在本阶段中，确定应该如何具体地实现所要求的系统，从而在编码阶段可以把这个描述直接翻译成用具体的程序语言书写的程序。
主要的工作有：根据在《需求分析说明书》中所描述的数据、功能、运行、性能需求，并依照《概要设计说明书》所确定的处理流程、总体结构和模块外部设计，设计软件系统的结构设计、逐个模块的程序描述（包括各模块的功能、性能、输入、输出、算法、程序逻辑、接口等等），解决如何1．接受：客户信息（台号，点的菜）2．输出：打印机输出表单；3．进行数据库的查询、修改工作；4．接受并判断错误，输出相应的出错消息；在以下的各个阶段中，《用户操作手册》将与本阶段的工作紧密结合，努力作到让用户易懂易学。
《测试报告》和《维护报告》也将参考本说明书，检验本系统的各项性能指标，及时发现纰漏及时修补，一定要把功能强大、稳定可靠、便于维护的机票预定系统交到用户手中。
1、2项目背景：由《412》软件开发小组负责开发。
本系统项目主要由两部分形成：1、前台电脑；2、数据库服务器；1、3文中特殊的定义和缩写：1．3．1定义SQL SERVER: 系统服务器所使用的数据库管理系统（DBMS）。
SQL: 一种用于访问查询数据库的语言事务流：数据进入模块后可能有多种路径进行处理。
主键：数据库表中的关键域。
值互不相同。
外部主键：数据库表中与其他表主键关联的域。
ROLLBACK: 数据库的错误恢复机制。
1．3．2 缩写系统：若未特别指出，统指本订餐系统。
SQL: Structured Query Language（结构化查询语言）。
ATM: Asynchronous Transfer Mode (异步传输模式)。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
编码：WXRT-SMSFE-E-RD-R01 XXX科技有限公司
员工订餐系统
(RSMS)
系统需求规格说明书
拟制人 _______________ 日期_________________
审核人 _______________ 日期_________________
批准人 _______________ 日期_________________
更改控制业
目录
1文档介绍
1.1目的
在系统的完成目标方面，为客户和开发者建立共同协打下基础。
对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符
合他们的要求。
提交开发效率，使开发人员在设计开始之前，周密的思考全部需求，从而减少事后重新设计、重新编码、重新测试的反工活动。
加强对
需求内容的检查和复查，尽可能的在开发早期发现遗漏、错误的理
解和和不一致性，以便及时加以纠正。
为正本计价和编制计划进度提供基础。
通过需求分析帮助项目组更
加合理的进行项目估算。
为确认需求和验证需求提供一个基准。
便于对需求进行双向跟踪。
便于系统移植、功能扩展和后期维护。
总的来说本说明书的目的在于明确说明系统需求，界定系统实现功能的范围，指导系统设计及编码
1.2 范围
本文档作为系统概要设计、详细设计、数据库设计的根据和对文档以及项目的验收依据，所有设计都要围绕需求规格说明书来进行。
1.3 读者对象
项目组所有成员、需求提出者以及一些相关领导
1.4 参考文档
1.5 术语与缩写解释
缩写、术语解释
餐车餐车是系统提供给用户的一个快捷订餐工具。
用户可以将自己中意的产品放入餐车，然后进入餐
车进行批量下订单
2 产品介绍
由于天气炎热，给员工外出就餐带来不便，加上大学城各大高校进入假期，很多食堂餐厅停业，因此员工的午餐问题急需解决。
在公司高层领导的关注下，大学城XXX科技公司，JAVA研发小组迅速组建研发小组，经过轮番讨论设计，最终确定研发RSMS员工订餐系统，为员工提供良好的订餐平台，更有效、更方便的解决员工就餐问题。
系统主要分为两大功能模块，一个是系统前台用户部分，主要面向公司内部员工订餐活动；另一个是平台管理员部分，主要是管理员工的订单以及商家管理，包括菜肴的更新以及商家信息的更新，和一些平台管理的日常辅助功能。
3产品面向的用户群体
该系统的最终用户为XXX公司内部所有员工。
本系统将给员工的订餐带来极大便利，同时减轻了订单工作人员的工作负担
4产品应遵循的标准或规范
本产品遵循CMMI3的标准规范。
5产品范围
本产品适用于电子商务领域，电子商务的处理方式和范围主要包括以下三面：
1)企业内部之间的信息共享和交换。
通过企业内部的虚拟网路，分布
各地的各分支结构以及企业内部的各级人员可获取所需的企业信息。
避免了纸张贸易和内部流通的形式，从而提高了效率，降低了经营成本。
2)企业与企业之间的信息共享和交流。
EDI(电子数据交换)是企业之间
进行电子贸易的重要方式，避免了人为的错误和低效率。
EDI主要应用的企业与企业之间，企业与批发商之间，批发商与零售商之间。
3)企业与消费者之间。
企业在因特网上设立网上商店，消费者通过网
络在网上购物，在网上支付，为消费者提供了一种新型的购物环境。
综上所述，本产品着重于第三方面内容。
6产品中的角色
7产品的功能性描述7.1功能性需求分类
7.1.1前台功能性需求分类
7.1.2后台功能性需求分类
7.2需求功能详细描述
一下是对7.1中的功能进行详细描述：7.2.1前台功能描述
7.2.1.1.1 浏览菜肴
7.2.1.2 浏览商家（餐厅）
7.2.1.3 浏览餐厅活动
7.2.1.4 搜索菜肴
7.2.1.5 搜索商家（餐厅）
7.2.1.6 搜索餐厅活动
7.2.1.7 添加到餐车
7.2.1.8 马上预定
7.2.1.9 预定
7.2.1.10 修改订餐数量
7.2.1.11 删除菜肴
7.2.1.12 查看订单
7.2.1.13 撤销订单
7.2.1.14 个人信息维护
7.2.1.15 显示余额
7.2.1.16 投诉举报
7.2.1.17 意见反馈
7.2.1.18 评论餐厅
7.2.1.19 评论菜肴
7.2.1.20 评价菜肴
7.2.1.21 推荐餐厅
7.2.2 后台功能描述7.2.2.1 管理员信息维护
7.2.2.2 搜索操作日志
7.2.2.3 查看操作日志
7.2.2.4 删除操作日志
7.2.2.5 创建角色
7.2.2.6 分配权限
7.2.2.7 搜索角色
7.2.2.8 修改角色
7.2.2.9 删除角色
7.2.2.10 创建管理员帐号
7.2.2.11 搜索管理员
7.2.2.12 分配角色
7.2.2.13 修改管理员角色
7.2.2.14 管理员密码重置
7.2.2.15 删除管理员账号
7.2.2.16 添加菜肴
7.2.2.17 搜索菜肴
7.2.2.18 查看菜肴
7.2.2.19 修改菜肴
7.2.2.20 删除菜肴
7.2.2.21 添加商家（餐厅）
7.2.2.22 查看商家（餐厅）
7.2.2.23 搜索商家（餐厅）
7.2.2.24 修改商家（餐厅）
7.2.2.25 删除商家（餐厅）
7.2.2.26 添加商家（餐厅）活动
7.2.2.27 搜索商家（餐厅）活动
7.2.2.28 查看商家（餐厅）活动
7.2.2.29 修改商家（餐厅）活动
7.2.2.30 删除商家（餐厅）活动
7.2.2.31 导出报表（订单管理）
7.2.2.32 搜索订单
7.2.2.33 查看订单
7.2.2.34 撤销订单
7.2.2.35 删除订单
7.2.2.36 添加代订信息
7.2.2.37 导出报表（代订管理）
7.2.2.38 搜索代订信息
7.2.2.39 查看代订
7.2.2.40 修改代订
7.2.2.41 撤销代订
7.2.2.42 付账记录
7.2.2.43 删除代订
7.2.2.44 添加菜肴类型
7.2.2.45 搜索菜肴类型
7.2.2.46 修改菜肴类型
7.2.2.47 删除菜肴类型
7.2.2.48 账户充值
7.2.2.49 搜索账户
7.2.2.50 账户注销
7.2.2.51 搜索充值记录
7.2.2.52 删除充值记录
7.2.2.53 查看投诉
7.2.2.54 搜索投诉
7.2.2.55 删除投诉
7.2.2.56 查看意见
7.2.2.57 搜索意见
7.2.2.58 导出报表（意见反馈）
7.2.2.59 删除意见
7.2.2.60 查看评论
7.2.2.61 搜索评论
7.2.2.62 屏蔽评论
7.2.2.63 删除评论
8 产品的非功能性需求8.1 用户界面需求
8.2 软硬件环境需求
8.3 产品质量需求
8.4 接口需求
该系统的登录功能与公司的邮箱系统衔接，利用公司员工的邮箱名和密码来登录本系统
8.5 其他需求
该系统要遵循http网络传输协议。
最大并发连接数应该能达到1000人次。
9 附录A：需求建模与分析报告
A.1系统前台用户用例模型
A.2 平台管理员用例模型
10 附录B：需求确认
需求评审报告摘要
需求文档输入名称，标识符，版本，作者，完成日期，…
输入名称，标识符，评审日期，…
需求评审
报告
评审结论[ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。
[√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。
[ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。
评审意见。