CO・2；系统将采用标准的数据库引皐。
CO-31所有HTML代码将逍照HTML4.0标准。
CO4所有脚本都用Peil语喜来编写。
SJS）S（Assumption）和依赖（Dependency）
兀S小只要是要求员工在岗的每一个公司工作日#自助食堂在
早餐"午養和晚菴时都会营业。
DE-1;白自助食堂订餐系欲的运行依赖于“薪资杉算系统円
所做出的变更，它接受闿’‘自助倉堂订餐系统''订餐的付费
请求"
DEC:
“宜助食堂订餐系统^的运行依赖于"自助倉堂库存系
统丹所做出的变更，当接受“自勒食堂订餐系统并订单盾，
它更新食物条目的有效性。
第三章是系统功能。
需要列出每个功能点，每个功能点包含
以下三个方面：
3.X.1描述和优先级
3.X.2请求/响应序列
3.X.3功能性需求
//详细列出提交给用户的软件功能，用户可以使用所提供的功能执行服务//
或者使用所指定的用例执行任务。
并且描述产品如何响应可预知的出错//条件或非
法输入或动作。
丄•丄描述和优先级
自助食堂的顾客其身份得到验证之后，他们就可以订餐，并可以要求送到公司内指定的地点，也可以去食堂内就餐。
只要所订餐还没有准备好，顾客就可以取消或改变订单。
优先级为高
丄.2请求响应序列
请求：
顾客请求订養，可以是一份或多份。
响应：
条统向顾客询问订餐细节、付费方式和送餐说明请求土顾客请求改变订单。
响应：
如果订单状态是“已接受”，则系统允许用户编辑以前的订单.
请求戈顾客请求取消订单。
响应：
如果订单状态是“已接受”，则系统収消订总。
丄3功能性需求
OideiPlMe
登录到"自助食堂订餐系统穴的顾客可以通过该系统订餐，可以订一份或多饴都可以
I
系统将确认订餐的顾客所注册的付费方
式是从工资中扣除餐费的伯费方式
Order,Place.R^giste
iNo
如果顾客没有注册从工资中扣除餐费的彳寸费方式，那么系统将为顾客提供一些选择方案，顾客可以现在注册并继续逬行订餐，也可以
订餐后去食堂用餐1不送餐），或者还可以退出锥自助食堂订餐至统力
第四章是外部接口需求。
包含四个部分:
4.1用户界面
//包括
//户界
//陈述所需要的用户界面。
描述每个用户界面的逻辑特征。
以下是可能要
的一些特征：
//4将要采用的用户界面标准或产品系列的风格
//♦屏幕布局或解决方案的限制
//4将出现在每个屏幕的标准按钮、功能或导航链接
//♦快捷键
//4错误信息显示标准
//对于用户界面的细节，例如特定对话框的布局，建议写入一个独立的用
面规格说明中，不要写入软件需求规格说明书中
4.2硬件接口
//描述系统中硬件每个接口的特征。
可能包括支持的硬件类型、软硬件之间//交流的数据和控制信息的性质以及所使用的通信协议
4.3软件接口
//描述产品与其它外部组件的连接，包括数据库，操作系统，工具库和集成//的商
业组件。
明确并描述在软件组件之间交换数据或信息的目的，描述所//需要的服务及内
部组件通信的性质，确定将在组件之间共享的数据。
如果//必须用一种特殊的方法来实
现数据共享机制，那么就必须把它定义为一种//实现上的限制
4.4通信接口
//描述与产品所使用的通信功能相关的需求，包括电子邮件、WEB浏览器、//网络
通信标准或协议及电子表格等，定义相关的信息格式、规定通信安全//或加密问题、数
据传输速率和同步通信机制
1.用户界面（UserInterface,Uf）
LTidt摄自助倉堂订程寡统"的屏專is面梅遵照氏g
ImpactInternetApplicationUserMerfaceStandard（Pre
Impact公司的Ii止创口衬应用程序用户界面标准丿版本丄山【总】
系统禅所显示的毎个HTML网贡都提供带助糙
按，解释如诃便用这些网页.
UI小面的全部导航和食物疑且选择，除了综含
使用鼠标裁键盘共同克威外，还可以只通过犍盘来叮牲弋成、
3.软件接口（SoftwareInterfaces,SI）
SI4：
自助險堂库存系统
SI-1h自助食堂订餐系统通过程序界面向自助食堂库存系统发生所订的食物条目和数量
SM.2：
自助食堂订餐系统将询问自助食堂库存东统,以确定所请求的食物是否有效
SL13t当自助偸堂库存系统通知自助食堂订餐系统某一指定的食物条目已经没货时启助食堂订覆系统会从当日的菓单中将该食鞭条2刮除
第五章是其他非功能性需求。
包含四个部分:
5.1性能需求
〃阐述不同的应用领域对产品性能的需求，并解释它们的原理以帮助开
//发人员做出合理的设计选择。
确定相互合作的用户数或者所支持的操//作，响应时间以及与实时系统的时间关系；还要定义容量需求，例如存//储器和磁盘空间的需求或者存储在数据库中表的最大行数。
也可能需要
//针对每个功能需求或特性分别陈述其性能需求
5.2安全性需求
//陈述与系统安全性、完整性相关的需求，包括产品创建或使用的数据保//护。
明确产品必须满足的安全性或保密性策略。
5.3软件质量属性
//详细陈述与客户或开发人员至关重要的质量特性。
这些特性必须是确定//的、定量的并可检验的。
至少应指明不同属性的相对侧重点。
5.4其它需求
//理、
//定义至今未出现的需求。
例如国际化需求、法律上的需求、有关操作、管维护、安装、配置、启动、关闭、修复、容错、监控等等方面的需求
1,性能需求
PE4:
在当地时间早農S点到10点这一段高峰期间，
系统将能适应加。
个用卢，平均錄个会话估计捋续8分钟"
PE-2*系统生成的所有Web页面，通过速率为40KBpS；
的调制解调緡庄不超过丄。
秒的时间内可以全部下戟F来*
PE-3:
用户提交了査询之后，对萱询的响应时间不能粗
过P在此时间内将要査询緒果显示在屏專上，
PE-4：
用户向系统提空信息后，系统将在4秒内向用户
显示确认消息中
£妥全性＜Securify＞需求
SE-lt所有涉及功能信息或个人身份信息的网络事务，
都娶按照BR-5A进行加密操作。
SE-2除浏览菜单外+用户必须登录到“自助食堂订寮系
统”才能克成苴他所有操作®
SE3顾客的登录受计算机条统访问控制策略的隔制，具
体请
SE-1:
勒禽宜的工作人员，只貢那些授权为藥单管理员的，
才能通过系统创建或编辑菜单，具体请参照BR-21.
SF-5只有那些被攪权可以在家访问公司内联网的用户，
才可以在公司以外的地方使用“自助食堂订程杀STa
GET;系统只允许顾智浏览他们自己以前的订单.而不箴刮览
茸他除客的订单.
4.软件质量属性
Availability何用性）小“自助食堂订餐系统”将对公司内联网的用户可用，拨号用在当地时间早晨5点到晚上12点内99.9。
。
的时间可用,当地时间晚上12点到早晨,点92。
的时间可用。
Robustness®壮性）如果在订单得到确认或取消之前，
用户和系统的连接中断，那么用户应该能通过“自助食堂订
餐系统"恢复不主整的订单•
第六章是数据字典。
包含两个部分:
6.1实体关系图
6.2实体定义
埒齐懺卷肚疔刊匕:
说啾対K怦的业莽證炭泾亚弄嫌韓）
H
■U八肘
J7/
第七章是业务规则与业务算法:
7.1业务规则
//列举出有关产品的所有操作规则。
例如什么人在特定环境下可以进行何种//操作。
这些规则不是功能需求，但它们可以暗示某些功能需求执行这些规//则。
业务规则的
范例如下图所示：
7.2算法说明
//用于实施系统计算功能的公式和算法的描述，类似于业务规则。
如神州行
//套餐的计费标准说明。
//a.每个主要算法的概况；
//b.用于每个主要算法的详细公式。
|T面是单独业务规则収点沖皆RuleBR）类别的一个范何h
n>
规则宦义
规则类型
来源
送餐的时间窗□是上分钟，以澤一劃钟开始
事实
静态
自助億堂
经理
BR-2
送餐必须在当地时间上午E点和下午2点之间左成
约束
动态
自助禽堂
经理
BR-3
一张订单上的所有
饭菜必须送到同一
个地点
静态
自助金堂
经理
BRU
一张订单上的所有饭菜必须采用同一种付费方找来支忖費用
约束
静态
自助儉堂
经理
BR-S
订单必须在用餐日
前14内预定
约束
动态
I
肖助債堂
1.文档的最后是附录部分，包括：
附录A:
分析模型（包括涉及的数据流图、类图、状态转换图）
附录B:
待确定问题的列表
附录C:
编写文档的原则
ffiDJ**自助食堂订餐系統】■。
版本的部分数擔模型”
图D.3订单状态的状蛊转换图
步骤阅读
升级会员 