XXX系统
软件需求文档
年 月 日
修改记录
目 录
1 前景和范围文档... 4
1.1 业务需求... 4
1.2 解决方案的前景... 5
1.3 范围和局限性... 6
1.4 业务上下文... 6
2 用例描述文档... 9
3 需求规格说明书... 13
3.1 引言... 13
3.2 综合描述... 13
3.3 外部接口需求... 15
3.4 系统特性... 16
3.5 其他非功能性需求... 19
3.6 其他需求... 20
附录A 词汇表... 20
附录B 分析模型... 22
附录C 待确定问题的列表... 23
该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容：
n 前景和范围文档。
n 用例列表和若干用例描述。
n 部分软件需求规格说明。
n 某些分析模型。
n 部分数据字典。
n 若干业务规则。
因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。
这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。
1 前景和范围文档
1.1 业务需求
1.背景、业务机会和客户需要
目前，Process Impact公司的大多数员工平均每天要花费60分钟去自助食堂选择、购买并用午餐，其中大约有20分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午餐、以及以现金方式或以信用卡方式结算餐费上。当员工出去用午餐时，他们平均有90分钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助食堂准备好他们所选择的午餐。但是，员工并不是总能如愿以偿，因为自助食堂有些食物己卖完，而与此同时，自助食堂又不可避免地会浪费大量的食物，因为有些食物没有卖出去而只好倒掉。早餐和晚餐同样面临着这样的问题，只是到自助食堂用餐的员工人数比午餐要少得多。
许多员工都通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一服务的员工可以节约相当可观的时间，而且订到自己所喜欢的食物的机会也增大了。这既提高了他们的工作生活质量，也提高了他们的生产率。自助食堂提前了解到客户需要哪些食物，就可以减少浪费，并提高自助食堂员工的工作效率。要求送货上门的订餐员工将来还可以从本地的饭店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店的大量购餐协议而有可能节约费用。Process Impact公司也可以只在自助食堂订午餐，而在饭店订早餐、晚餐、特定事件的用餐以及周末会餐。
2.业务目标（Business Objective，BO）和成功标准（Success Criteria，SC）
BO-1：初始版本发布之后的6个月内，自助食堂的食物浪费减少50%。
度量单位（scale）：自助食堂的工作人员每星期所倒掉的食物的价值。
计量（meter）：检查“自助食堂存货系统（Cafeteria Inventory System）”的日志。
过去情况（past）[2002.初步调研]：30%
一般标准（plan）：小于15%
最低标准（must）：小于20%。
注 该范例展示了使用Planguage语言来精确陈述业务目标或其他需求这样一种方法。
BO-2：初始版本发布之后的12个月内，自助食堂的运作费用减少50%。
BO-3：初始版本发布之后的3个月内，每个雇员每天的平均有效工作时间增加20分钟。
SC-1：目前通过自助食堂解决午餐问题的那些员工，在初始版本发布之后的6个月内，他们中有75%的人使用“自助食堂订餐系统”。
SC-2：初始版本发布之后的3个月内，对自助食堂满意度的季度调查评价要提高0.5.而在初始版本发布之后的12个月内，这种满意度要提高1.0。
3.业务风险（Risk）
RI-1：“自助食堂雇员联合会（Cafeteria Emp1oyees Union）”可能要求与雇员重新签订合同，以反映新的雇员角色和自助食堂营业时间。（可能性为0.6，影响为3）
RI-2：使用该系统的雇员太少，减少了对系统开发和变更自助食堂经营过程的投资回报。（可能性为0.3.影响为9）
RI-3：本地饭店可能并不认同减价是雇员使用这一系统的正当理由，这会减低雇员对该系统的满意度，并可能会减少他们对这一系统的使用。（可能性为0.4，影响为3）
1.2 解决方案的前景
1.前景陈述
对那些希望通过公司自助食堂或本地饭店在线订餐的员工来说，“自助食堂订餐系统”是一个基于Internet的应用程序，它可以接受个人订餐或团体订餐，结算用餐费用，并触发将预订餐送到Process Impact公司内的指定位置。与当前的电话订餐和人工订餐不同，使用“自助食堂订餐系统”的雇员并不需要到食堂内去用餐，这既可以节约他们的时间，又可以增加他们对食物的选择范围。
2.主要特性（FEature）
FE-1：根据自助食堂提供的选择菜单或送货菜单来订餐。
FE-2：根据本地饭店的送货菜单来订餐。
FE-3：创建、浏览、修改和删除用餐预订服务。
FE-4：注册用餐的付费方式。
FE-5：请求送餐。
FE-6：创建、浏览、修改和删除自助食堂菜单。
FE-7：预订自助食堂菜单上所没有的定做菜。
FE-8：生成自助食堂定做菜的食谱和配料列表。
FE-9：通过公司的内联网可以访问系统，或者授权的员工通过外部Internet访问系统。
3.假设（ASsumption）和依赖（DEpendency）
AS-1：自助食堂内有可以访问公司内联网的计算机和打印机，这样自助食堂的雇员就可以处理期望的订单量，不会遗漏任何送货时间。
AS-2：最多比请求的送货时间晚15分钟，自助食堂有送货人员和送货车辆，这样就能满足所有订单的送货要求。
DE-1：如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一系统进行双向通信。
1.3 范围和局限性
1.初始版本和后续版本的范围
2.局限性（Limitation）和排斥性
LI-1：自助食堂的有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单是食堂整个菜单的一个子集。
LI-2：“自助食堂订餐系统”只能用于俄勒冈州Clackamas的Process Impact公司总部内的自助食堂。
1.4 业务上下文
1.涉众概览
2.项目优先级
2 用例描述文档
各种用户类确认的“自助食堂订餐系统”的用例和主要参与者如下所示：
3 需求规格说明书
3.1 引言
1.目标
软件需求规格说明描述了“自助食堂订餐系统（Cafeteria Ordering System，COS）”1.0版本的软件功能性需求和非功能性需求。这一文档计划由实现和验证系统正确功能的项目团队成员来使用。除非在其他地方另有说明，这里指定的所有需求都具有高优先级，而且都要在版本1.0中加以实现。
2.项目范围和产品特性
“自助食堂订餐系统”允许Process Impact公司雇员向公司的自助食堂在线订餐，并送餐到公司内的指定地点。详细的项目描述请参见Cafeteria Ordering System Vision and Scope Document（自助食堂订餐系统前景和范围文档）[1]。文档中这一部分的标题为“初始版本和后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。
3.参考文献
(l) Karl Wiegers FE%W1Cafeterla Ordering System ViSIon and Scope Document, EWli[# www.procesSImpact.com/projects/COS/COS=viSIon-and_scope.doc
(2) Karl Wiegers BT#P9 Process Impact Intranet Development standard HR.# 1.3, E
WlitE www.procesSImpact.com/corporate/standards/PI intranet=dev=std.doc
(3) Christine Zambito BT#Pi Process Impact BuSIness Rules CataIog, EWil#
www.procesSImpact.com/corporate/po1icies/PI-buSIness=ru1es.doc
(4) Christine Zambito BT#P9 Process Impact Internet Application USEr Interface
Standard HR # 2.0 , E Wl tt # www.procesSImpact.com/corporate/standards/ PI=internet=ui=std.doc
3.2 综合描述
1. 产品前景
“自助食堂订餐系统”是一个新系统，它取代了当前在Process Impact公司自助食堂内以手工方式和电话方式预定和选择午餐的过程。图1是一幅关联图，它演示了1.0版本的外部实体和系统接口。期望系统演化若干个版本，最终与本地若干饭店的Internet订餐服务相连接，并提供信用卡和借记卡授权服务。
图1 “自助食堂订膂系统”版本1.0的关联图
2. 产品功能
在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能，在描述功能时应该针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能，在陈述本软件产品主要功能的作用领域时，也需要对应陈述本软件产品的非作用领域，以利读者理解本软件产品。
为了很好地组织产品功能，使每个读者都容易理解，可以采用列表的方法给出。也可以采用图形方式，将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示，这种表示方法是很有用的。
3.用户类和用户特性
4.运行环境（Operation Environment，OE）
OE-1：“自助食堂订餐系统”的操作将通过如下的Web浏览器来完成：Microsoft Internet Explorer版本5.0和6.0，Netscape Communicator版本4.7和Netscape版本6和版本7。
OE-2：“自助食堂订餐系统”将运行在一个服务器中，该服务器运行当前由公司批准的Red Hat Linux版本和Apache HTTP Server。
OE-3：“自助食堂订餐系统”将允许用户通过公司内联网来访问，如果用户被授权在公司的外部穿过防火墙来访问，那么用户也可以在家里通过Internet来访问该系统。
5.设计和实现的约束条件（constraint）
CO-1：系统的设计、编码和维护文档将遵照Process Impact Intranet Development Standard（Process Impact公司内联网开发标准）版本1.3 [2]。
CO-2：系统将采用公司标准的当前Oracle数据库引擎。
CO-3：所有HTML代码将遵照HTML4.0标准。
CO-4：所有脚本都用Perl语言来编写。
6.用户文档（User Documentation，UD）
UD-1：系统将提供一个分层的和跨链接的HTML联机帮助系统，它描述并演示了所有系统功能。
UD-2：如果是一个新用户第一次使用该系统，系统可以根据用户的要求，提供一个联机教程，这样用户可以使用静态教程菜单来具体实践一下如何订餐。系统不会将采用这一模板的订餐订单存储到数据库中，也不会将这种订单提交给自助食堂。
7.假设（ASsumption）和依赖（DEpendency）
AS-1：只要是要求员工在岗的每一个公司工作日，自助食堂在早餐、午餐和晚餐时都会营业。
DE-1：“自助食堂订餐系统”的运行依赖于“薪资核算系统”所做出的变更，它接受用“自助食堂订餐系统”订餐的付费请求。
DE-2：“自助食堂订餐系统”的运行依赖于“自助食堂库存系统”所做出的变更，当接受“自助食堂订餐系统”订单后，它更新食物条目的有效性。
3.3 外部接口需求
1.用户界面（User Interfaces，UI）
UI-1：“自助食堂订餐系统”的屏幕画面将遵照Process Impact Internet Application User Interface standard（Process Impact公司的Internet应用程序用户界面标准）版本2.0 [4]。
UI-2：系统对所显示的每个HTML网页都提供帮助链接，解释如何使用这些网页。
UI-3：Web页面的全部导航和食物条目选择，除了综合使用鼠标和键盘共同完成外，还可以只通过键盘来单独完成。
2.硬件接口
硬件接口还没有确定。
3.软件接口（Software Interfaces，SI）
SI-1： 自助食堂存货系统。
SI-1.1：“自助食堂订餐系统”通过程序界面向“自助食堂存货系统”发送所订的食物条目数量。
SI-1.2：“自助食堂订餐系统”将轮询“自助食堂存货系统”，以确定请求的食物是否有效。
SI-1.3：当“自助食堂存货系统”通知“自助食堂订餐系统”某一指定的食物条目已经没货时，“自助食堂订餐系统”会从当日的菜单中将该食物条目删除。
SI-2：“薪资管理系统”。“自助食堂订餐系统”通过程序界面与“薪资管理系统”进行通信，完成下面这些操作：
SI-2.1：允许顾客注册从工资中扣除餐费的付费方式。
SI-2.2：允许顾客取消所注册的从工资中扣除餐费的付费方式。
SI-2.3：检查顾客是否注册了从工资中扣除餐费的付费方式。
SI -2.4：为所购餐提交付费请求。
SI-2.5：退还全部或部分上面的费用，其原因是因为顾客拒绝了所订的餐，或对它不满意，也可能是因为没能按照送餐说明完成送餐任务。
4.通信接口（Communications Interfaces，CI）
CI-1:“自助食堂订餐系统”将向顾客发送电子邮件消息，以确认收到订单、价格和送餐说明。
CI-2：“自助食堂订餐系统”将向顾客发送电子邮件消息，以报告订单接受之后订单中或送餐中存在的问题。
3.4 系统特性
需要进行详细的需求记录，详细列出与该系统功能相关的详细功能需求，并且，唯一地标识每一项需求。这是必须提交给用户的软件功能，使得用户可以使用所提供的功能执行服务或者使用所指定的使用实例执行任务。描述软件产品如何响应己知的出错条件、非法输入、非法动作。
如果每一项功能需求都能用一项，也只需要用一项测试用例就能进行验证，那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例，或者必须使用多项测试用例才能验证，那么该项功能需求的描述必然存在某些问题。
功能需求是根据系统功能，即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容，也可以便用这些元素的组合。总而言之，必须选择一种是读者容易理解预期产品的组织方案。用简短的语句说明功能的名称，例如：“1. 订餐”。按照组织的顺序，逐条阐述系统功能。无论说明的是何种功能，都应该针对该系统功能重复叙述（1）~（3）这三个部分。
可以通过各种方式来组织这一部分内容，例如采用：使用实例、运行模式、用户类、对象类、功能等级等，也可以采用它们的组合。其最终目的是，让读者容易理解即将开发的软件产品。一般来说，每个使用实例都对应一个系统功能，因而按照使用实例来组织内容比较容易让用户理解。对应一些被共享的独立使用实例，可以定义一些公用系统功能。
必须特别注意的是，在综合描述部分“产品的功能”中描述的全部需求，以及它们的规格说明；必须在某个系统功能描述中有所反映，而且不应重复。
1.订餐
（1）描述和优先级
自助食堂的顾客其身份得到验证之后，他们就可以订餐，并可以要求送到公司内指定的地点，也可以去食堂内就餐。只要所订餐还没有准备好，顾客就可以取消或改变订单。优先级为高。
（2）刺激/响应序列
刺激：顾客请求订餐，可以是一份或多份。
响应：系统向顾客询问订餐细节、付费方式和送餐说明。
刺激：顾客请求改变订单。
响应：如果订单状态是“已接受”，则系统允许用户编辑以前的订单。
刺激：顾客请求取消订单。
响应：如果订单状态是 “已接受”，则系统取消订单。
（3）功能性需求
（本范例不提供改变和取消订餐订单的功能性需求）
2.创建、浏览、修改和删除订餐
（该范例不提供细节）
3.注册订餐的付费方式
（该范例不提供细节）
4.请求送餐
（该范例不提供细节）
5.创建、浏览、修改和删除自助食堂菜单
（该范例不提供细节）
3.5 其他非功能性需求
1.性能（PErformance）需求
PE-1：在当地时间早晨8点到10点这一段高峰期间，系统将能适应400个用户，平均每个会话估计持续8分钟。
PE-2：系统生成的所有Web页面，通过速率为40KBps的调制解调器在不超过10秒的时间内可以全部下载下来。
PE-3：用户提交了查询之后，对查询的响应时间不能超过7秒，在此时间内要将查询结果显示在屏幕上。
PE-4：用户向系统提交信息后，系统将在4秒内向用户显示确认消息。
2.防护性需求
防护性需求还没有确定。
3.安全性（SEcurity）需求
SE -1：所有涉及功能信息或个人身份信息的网络事务，都要按照BR-33进行加密操作。
SE-2：除浏览菜单外，用户必须登录到“自助食堂订餐系统”才能完成其他所有操作。
SE-3：顾客的登录受计算机系统访问控制策略的限制，具体请参照BR-35。
SE-4：自助食堂的工作人员，只有那些授权为菜单经理的成员，才能通过系统创建或编辑菜单，具体请参照BR-24。
SE-5：只有那些被授权可以在家访问公司内联网的用户，才可以在公司以外的地方使用“自助食堂订餐系统”。
SE-6：系统只允许顾客浏览他们自己以前的订单，而不能浏览其他顾客的订单。
4.软件质量属性
Availability（可用性）-1：“自助食堂订餐系统”将对公司内联网的用户可用，拨号用户在当地时间早晨5点到晚上12点99.9%的时间可用，当地时间晚上12点到早晨5点则95%的时间可用。
Robustness（健壮性）-1：如果在订单得到确认或取消之前，用户和系统的连接中断，那么用户应该能通过“自助食堂订餐系统”恢复不完整的订单。
5 业务规则
下面是单独业务规则（Business Rule，BR）类别的一个范例：
3.6 其他需求
附录A 词汇表
包括数据字典和数据模型等。
送餐说明 ＝顾客名字
+顾客电话号码
+用餐日期
+送餐地点
+送餐时间窗口
送餐地点＝*将所订的餐送到哪个大楼和房间*
送餐时间窗口＝*送餐的时间间隔是15分钟；以每一刻钟开始和结束*
雇员ID号＝*订餐雇员在公司中的ID号：是由6个字符数字组成的字符串*
食物条目描述＝*菜单中食物条目的文本描述，最多100个字符*
食物条目价格＝*一份菜单食物条目的税前费用，以美元和美分来计算*
用餐日期＝*送餐或就餐日期；格式为MM/DD/YYYY；如果订单截止日期在当前日期之后，则用餐日期的默认值为当前日期，否则为第二天；用餐日期不可能在当前日期之前*
订单 ＝订单号
+订单日期
+用餐日期
+1:m（所订的食物条目｝
+送货说明
+订单状态
订单号＝*系统为接受的每一个订单分配一个惟一的、顺序的整数；初始值是1*
订单状态＝[未完成｜已接受｜己准备｜送餐期间｜已送餐丨已取消]* 请参看图D.3的状态转换图*
结算餐费 ＝餐费价格
+付费方式
+（从工资中扣除餐费的事务号）
菜单 ＝菜单日期
+1:m｛菜单食物条目｝
+0:1｛特色菜｝
菜单日期＝*某一特定的食物条目菜单有效的日期；格式是MM/DD/YYYY*
菜单食物条目 ＝食物条目描述
+食物条目价格
订单截止日期＝*所有订单必须在此之前提交的那天的具体时间*
订单日期＝*顾客提交订单的日期：格式是MM/DD/YYYY*
所订的食物条目 ＝菜单食物条目
+所订的数量
顾客 ＝顾客名字
+雇员D号
+顾客电话号码
+顾客地点
+顾客电子邮件
顾客电子邮件＝*提交订单的雇员的电子邮件地址；由50个字母数字组成*
顾客地点＝*提交订单的雇员所在的大楼和房间号；由50个字母数字组成*
顾客名字＝*提交订单的雇员的名字；由30个字母数字组成*
顾客电话号码＝*提交订单的雇员的电话号码；格式为AAA-EEE-NNNN xXXXX，分别表示区号、电话局号、号码和扩展号码*
所付餐费＝*以美元和美分表示的一个订单的总价格，具体计算按照BR-12*
付费方式＝[从工资中扣除｜现金］*从版本2开始添加其他付费方式*
从工资中扣除餐费的事务号＝*“薪资核算系统”为它所接受的每个从工资中扣除餐费的事务分配一个数字，该数字是由8位数字组成的顺序整数*
订餐数量＝*顾客订的每一个食物条目的份数；默认值为1；最大值为日前的存货数量*
特色菜 ＝特色菜描述
+特色菜价格
*菜单经理可以为每个菜单定义一个或多个特色菜，这些特色菜是以优惠价将某些食物条目组合在一起*
特色菜描述＝*每日特色菜的文本描述：最多为100个字符*
特色菜价格＝*以美元和美分表示的一份特色菜的价钱*
图2是“自助食堂订餐系统”1.0版本的部分数据模型，展示了数据字典中描述的实体以及它们之间的关系。
图2 “自助食堂订餐系统”1.0版本的部分数据模型
附录B 分析模型
这是部分包括或涉及到相关的分析模型，例如：
● 数据流程图；
● 类图；
● 状态转换图；
● 实体-关系图。
图3是一幅状态转换图，它展示了可能的订单状态和允许的状态变更。
图3 订单状态的状态转换图