《软件需求分析》实验指导书(总68页)

《《软件需求分析》实验指导书(总68页)》由会员分享，可在线阅读，更多相关《《软件需求分析》实验指导书(总68页)（68页珍藏版）》请在装配图网上搜索。

1、软件需求分析 实 验 指 导 书 2013 年 9 月 中文软件需求分析课 程 编 号5011011093课程 Software Requirement 名称英文适 用 专 业软件工程Analysis 总学时32理论教学学时28课 4 内 学 分2实践教学学时课 8 外 执笔者刘冰编 写 日 期2012 年 3 月需求工程软件建模与分析（骆斌主编、丁二 讲授 玉编著，高等教育出版社，2009 年 4 月第一版，ISBN 978-7-04-026295-7） 教材 软件需求（第 2 版）（美）Karl E.Wiegers 著， 参考 刘伟琴、刘洪涛译，清华大学出版社、2004 年 11 月 第

2、1 版，ISBN 978-7-302-09834-8） 1 目 录 一、实验目的.3 二、实验的软硬件环境.3 三、实验要求与任务.3 四、实验步骤.3 五、软件需求规格说明书内容、格式要求.4 六、思考题6 【附录一】软件需求规格说明模板.7 【附录二】 评分标准.13 【附录三】前景与范围文档写作范例.14 【附录四】需求文档完整范例20 【附录五】软件需求规格说明书（样例一）.40 【附录六】软件需求规格说明书（样例二）52 2 实验名称：“管理信息系统”软件需求规格说明书的编写 一、实验目的 需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致的协议。这一协议 综合了业务需求、

3、用户需求和软件功能需求。从前面实验中所得出的一些分析文档中，我们 可以知道：项目视图和范围文档包含了业务需求，而使用实例文档包含了用户需求。我们还 必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属 性和外部接口需求。至此，我们综合前面的相关分析结果，来进行需求说明书的编写，进一 步理解由业务需求，用户需求，功能需求三个部分综合而形成软件需求说明书的过程。 二、实验的软硬件环境 硬件：微型计算机，打印机； 软件：Windows XP/7 ，Office 2003/2007，Visual Studio 、Delphi，SQL Server 等 要求实验环境为网络环境

4、。 三、实验要求与任务 1、要求： 完成软件需求规格说明书的编写： （1）用好的结构化和自然语言编写文档型文档 （2）建立图形化模型。 （3） 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 2、具体任务： 开发“管理信息系统”（如人事管理信息系统、财务信息管理系统、酒店信息管理系统、 设备信息管理系统、仓库管理信息系统、进存销管理信息系统、学生信息管理系统、图书馆 信息管理系统，图书销售信息管理新系统等等）。 通过调查获取用户需求，按照需求的内容进行分析，按照内容、格式要求撰写完整的软 件需求规格说明书。 四、实验步骤 1、 参考相关模板，初步理解软件需求规格说明书

5、的结构 2、 结合项目实际，完成软件需求规格说明书 3、 进一步检查、完善相应的需求部分，尽量避免需求遗漏，和定义的不清晰。同时， 3 应确保采用规范图例。 4、 重复进行前面几个步骤，经过小组成员多次讨论，并得到客户的认可，最终达到客 户和开发小组对需求的认识一致。 五、软件需求规格说明内容、格式要求 1、形成软件需求规格说明，要包括以下内容： 文档名称 文档版本号 1 文档编写人 文档编写记录2 审核人3 文档每次修订时间，每次修订人 文档编写目的 说明编写这份软件需求说明书的目的，指出预期的读者 a 待开发的软件系统的名称；b 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算

6、背景描述机网络；c 该软件系统同其他系统或其他机构的基本的相互来往关系。定义，缩写，列出本文件中用到的专门术语的定义和外文首字母组词的原词组。术语a 本项目的经核准的计划任务书或合同、上级机关的批文； b 属于本项目的其他已发表的文件； 参考资料c 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够 得到这些文件资料的来源。 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说 明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的任务目标概述用户的特点关系。如果本软件产品是一项独立的软件，而且全部内容自含

7、，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本 产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说 明该系统的组成和本产品同其他各部分的联系和接口。列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育 水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重 要约束4 假定和 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。约束用列表的方式（例如 IPO 表即输入、处理、输出表的形式），逐项定量 和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、 得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户

8、数。对功能的规定需求规定 例子：I:原始捕获的数据帧P：按照既定的数据帧存储格式，存储到离线文件中O：数据帧文件 1 1 精度对性能2 2 时间特性要求的规定3 3 灵活性解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精输人输度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括出要求对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。数据管说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的理能力增长对数据及其份量的存储要求作出估算。要求故障处列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理要求理的要求。其他专门要求a

9、 处理器型号及内存容量；运行b 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；环境设备的规定c 输入及输出设备的型号和数量，联机或脱机；d 数据通信设备的型号和数量；e 功能键及其他专用硬件5 支持软列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支件持软件等。接口说明该软件同其他软件之间的接口、数据通信协议等控制说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源2、形成软件需求规格说明，格式和编写体例要依据【附录一】模板。 六、思考题 1、软件需求规格说明应该包括哪些方面的内容，如果没有模板，你准备么样组织材料， 来编写需求说明？ 2、总结自己撰写软件需求

10、规格说明的心得与收获。 6 【附录一】软件需求规格说明模板（参见教材 P345-350） 1引言 引言是对整个软件需求规格说明的概览，以帮助读者更好地阅读和理解文档。包括文档 的意图（目的）、主要内容（范围）、组织方式（文档组织）、参考文献（参考文献）和阅读 时的注意事项（定义、首字母缩写和缩略语）。 1.1 文档的意图（目的） 目的是说明软件需求规格说明的主要目标，描述软件规格说明所定义的产品或某些产品 部分。限定预期的读者。 1.2 主要内容（范围） 在这一节中： 根据名称确定将被开发的软件产品。 解释软件产品的预期功能，并在必要的时候解释没有纳人软件产品预期的功能。 描述软件产品的应用，

11、包括相关的好处、目标和目的。 如果在此软件需求规格说明之外，还存在着一个更高层次的规格说明（例如系统需求 规格说明），那么该部分的描述应该与更高层次文档的相关段落保持一致。 1.3 阅读时的注意事项（定义、首字母缩写和缩略语） 定义了正确理解软件需求规格说明所必需的术语、首字母缩写和缩略语。 这部分内容也可以通过添加附录或者引用其他文档来提供。 1.4 参考文献 在这一节中： 提供需求规格说明文档引用的全部文档的清单列表。 利用标题、报告编号（如果适用）旧期和出版机构来标识文档。 指出参考文献的来源，在该来源中可以获得文献。 这部分内容也可以通过添加附录或者引用其他文档来提供。 1.5 组织方

12、式（文档组织） 在这一节中： 描述软件需求规格说明余下部分所包含的内容。 解释软件需求规格说明的组织方式。 2总体描述 从总体上描述影响产品和需求的因素。这部分并不涉及将在文档第 3 部分（详细需求描 述）中描述的具体的需求，而是为其提供背景知识，使其更加易于理解。 21 产品前景 该节将所定义的产品和其他相关的产品联系起来，在联系中描述产品的起源和背景，进 7 而说明对产品的总体预期。 如果产品是一个独立的、完全自包含的系统，那么就应该在这里进行声明。 如果像常见的情况那样，产品仅仅是较大系统的一个组件，那么就应该将较大系统的需 求和软件的功能联系起来进行说明，并标识它们之间的接口。如果能够

13、开发一个可以显示较 大系统的主要组件、内部连接和外部接口的框图，将会有很大帮助。 这一节还应该描述较大系统的其他部分对软件产品的操作预期。这些部分包括： 系统接口：系统接口对软件产品的功能要求。 用户界面：软件产品和用户之间接口的逻辑特征和优化要求。 硬件接口：软件产品和较大系统中硬件组件之间接口的逻辑特征。 软件接口：其他软件系统对软件产品的要求。： 交流接口：本地网络协议之类的交流接口要求。 内存：软件产品在主存储器和辅助存储器上的局限性和可适用特性。 操作：用户要求的正常和特殊操作。 地点改变需求：对指定地点、任务或者操作模式的需求，调整软件装置而需要改变的 地点或者任务的相关特征。 2

14、.2 产品功能 概述软件将要执行的主要功能。此处只需要概略的总结，其详细内容将在第 3 部分（详 细需求描述）中描述。例如，一个账目管理程序的软件需求规格说明会在本节中描述顾客账 目维护、顾客描述和发票处理等功能，但不会提及上述功能的大量细节。如果存在为软件产 品分配功能更高一层的规格说明，那么这个部分的功能概述应该直接从更高层次规格说明的 相关部分提取。 为了清晰起见： 功能的组织应该能够让第一次看到文档的顾客或者其他人理解功能列表。 可以使用文本或者图形化的方法显示不同功能及其联系。 2.3 用户特征 描述产品预期用户的一般特征，包括受教育水平、经验和技术能力等。这些描述信息可 以用来解释

15、第 3 部分（详细需求描述）中特定需求出现的原因，但是本节并不涉及这些特定 的需求。 2.4 约束 对限制开发人员开发方案选择的事项进行一般性描述。这些事项包括： 规章政策。 硬件限制。 和其他应用的接口。 并发操作。 8 审计功能。 控制功能 高阶语言要求（即程序开发语言）。 信号握手协议（即信息交流的可靠性要求）。 应用的临界状态。 安全性考虑。 2.5 假设和依赖 列举并描述了那些会对文档中所述需求产生影响的因素。这些因素并不是软件的设计限 制，但是这些因素的任何变化都会影响到文档中的需求。例如，有这样一个假设：软件产品 的目标硬件上会有某个特定的操作系统。而在实际情况中，如果这样的情况

16、并不存在，那么 文档中的需求将不得不进行相应的改变。 3.详细需求描述 这通常是软件需求规格说明中最多和最重要的部分。它要对所有的软件需求进行充分的 描述。这部分的内容应该包括设计人员进行设计时所需要的所有细节，足以让设计人员设计 出一个满足需求的系统。它还需要清楚地告诉测试人员需要怎么样的测试才能保证得到一个 满足需求的系统。 在这一部分： 细节需求的描述要符合优秀需求的特性要求（参见 2. 5 节），文档的组织和内容整合 要符合优秀软件需求规格说明文档的特性要求（参见 15.5 节）。 细节需求要能够回溯到相关的前期文档，形成前后参照。 所有的需求都要被唯一的标识。 需求的组织应该尽可能的

17、提高可读性。 该部分内容的最佳组织方式要依赖于软件产品的应用领域和特性。IEEE 830-19981 为该部分的文档组织提供了 8 种不同的模板方式，图 15 一 5 所示的模板为其中之一。 图 15 -6 所示的模板是按照系统特性来进行需求组织的，除此之外也可以按照操作模式、 类对象、刺激响应、功能分解、用户类别等方式进行组织。关于其他几种组织方式可参 见教材的附录一（P423-428）。 IEEE 830-1998将需求分成了 5 种类别，并据此进行内容的组织。这 5 种内容是： 功能需求。 性能需求。 约束。 质量属性。 对外接口。 软件需求规格说明模板中第 2 章已经详细解释了 5 种

18、类型需求的区别，本章将仅仅对文 9 档内容的组织进行介绍。 3.1 对外接口需求 描述了设计人员正确开发与软件外部实体的接口所需要的所有信息。 对软件产品对外接口中的输人输出项，可以参照下列方式进行描述： （1）名称。 （2）目的描述。 （3）输人源输出目标。 （4）有效范围，精确度和误差范围。 （5）度量单位。 （6）时间要求。 （7）和其他输人输出项的关系。、 （8）屏幕布局组织。 （9）窗口布局组织。 （10）数据格式。 （11）命令格式。 （12）结束消息。 3.1.1 用户界面 描述系统所需的每个用户界面的逻辑特征。本节可能包括下列内容： 对图形用户界面(GUI)标准的引用或者将要采

19、用的产品系列的样式指南。 有关字体、图标、按钮标签、图像、颜色选择方案、组件的 tab 顺序、常用控件等的 标准。 屏幕布局或解决方案的约束。 每个屏幕中将出现的标准按钮、功能或者导航链接。 快捷键。 消息显示约定。 便于软件定位的布局标准。 满足视力有问题的用户的要求， 3.1.2 硬件接口 描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之 间交流的数据和控制信息的性质以及所使用的通信协议等。 3.1.3 软件接口 描述该产品与其他外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工 具、程序库和集成的商业组件等。声明在软件组件之间交换数据、消息和控制命令

20、的目的。 描述其他外部组件所需要的服务以及组件间通信的性质。确定将在组件之间共享的数据。 10 3.1.4 通信接口 描述与产品所使用的通信功能相关的需求，包括电子邮件,Web 浏览器、网络通信标准 或协议及电子表格等。定义了相关的消息格式。规定通信安全或力。密问题、数据传输速率 和同步通 信机制等。 3.2 功能需求 描述了软件产品在接收和处理外部输入（或者处理和产生对外输出）中发生的基本行为。 需要描述的内容有： z 对输人的验证 z 操作的顺序 z 对异常的响应，例如 数值越界 通信间题 错误处理与恢复 z 参数的说明 z 输出和输人的关系 输人输出序列 将输人转换为输出的公式和规则 3

21、.2.x 系统特性 系统特性是外部期望的系统服务，它接收一系列的输入，并产生外界预期的输出。 3.2.x.1 特性描述 提出了对该系统特性的简短说明。 3.2.x.2 刺激响应序列 列出输入刺激序列（用户动作、来自外部设备的信号或其他触发器）和系统的响应 序列。 3.2.x.3 相关功能需求 详细列出与该特性相关的功能需求。这些是必须提交给用户的软件功能，使用户可以 使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知 的出错条件或者非法输人或动作。 3. 2.x.3.n 功能需求 x.n 对单个需求（功能的某个步骤或者某个方面）的清晰描述，常见形式为“RID：系

22、统应该”。 3.3 性能需求 阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员做出合理 的设计选择。确定相互合作的用户数、所支持的操作、响应时间以及与实时系统的时间关系。 11 还可以定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽 可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是 把它们都集中在一起陈述。 性能需求描述的详细内容和形式示例可参见 2.3.3。 3.4 约束 描述可能由法律法规、标准、规范或者硬件限制等因素带来的设计约束。 约束描述的详细内容可参见 2.3.6. 3.5 质量属性 详尽陈述对客户或开发

23、人员至关重要的产品质量属性。这些特性必须是确定、定量的而 且在可能时是可验证的。 关于质量属性的详细内容可参见 2.3.4. 3.6 其他需求 定义在软件需求规格说明的其他部分未出现的需求，例如国际化需求或法律上的需求。 你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错， 以及登录和监控操作等方面的需求。 附录 附录是对软件需求规格说明正文信息的补充。虽然它并不总是必需的，但是必要的附录 可以增加文档对需求的描述能力。 常见的附录内容包括： I/O 格式示例、成本分析研究、用户调查结果。 有助于阅读软件需求规格说明的背景信息，常见的有术语表、数据字典和分析模型

24、图示。 需要解决但是目前还悬而未决的问题列表。 为了满足安全、导出、初始加载或者其他需求而对代码和数据媒体进行特殊打包处理 的说明。 索引 对文档重要内容的位置引用，可以利用文档编辑工具自动生成。 需求规格说明文档的写作原则与技巧参见教材 P350“需求规格说 文档写作”。 12 【附录二】 评分标准 1、优（90 以上）：文档非常规范、思路很清晰，能较好反映、概括当前项 目内容以及客户各个方面的需求。 2、良（80 以上 ）：文档比较规范、思路比较清晰，能较好反映、概括当前 项目内容以及客户各个方面的需求。 3、中（70 以上）：文档基本规范、思路清晰，能反映、概括当前项目内容 以及客户各个

25、方面的需求。 4、及格（60 以上）：文档组织基本合理，思路基本清楚，能基本反映、概 括当前项目内容以及客户各个方面的需求。 5、不及格（60 下）：文档组织混乱，思路含混，不能反映、概括当前项目 内容以及客户各个方面的需求。 13 【附录三】前景与范围文档写作范例 自助餐厅在线订餐系统 业务需求、高层次解决方案和系统特性都应该被定义到项目前景与范围文档 之中，以为后续的开发工作打好基础。 前景与范围文档目录如下： 1 业务需求 1.1 应用背景 1.2 业务机遇 1.3 业务目标 1.4 业务风险 2 项目前景 2.1 前景概述 2.2 主要特性 2.3 假设与依赖 3 项目范围 3.1 第

26、一版范围 3.2 后续版本范围 3.3 限制与排除 4 项目环境 4.1 操作环境 4.2 涉众 4.3 项目属性 词汇表 参考资料 附录 1、业务需求 （要求说明：该项内容主要目的是清晰地解释系统的业务需求。业务需求描述了新系统 将带给投资人、购买者和用户的主要利益，说明了项目的最终目标。） 1.1 应用背景 （要求说明：概述系统开发的应用背景，描述原有的应用状况，说明新系统开发的动 机。必要的情况下，还需要说明应用的历史延续过程。） 目前，Process Impact 公司的大多数员工平均每天要花费 60 分钟去白助餐厅 用午餐，其中大约有 20 分钟要花在公司和自助餐厅之间的往返、选择午

27、餐和以 14 现金或信用卡方式结账上。当员工到自助餐厅之外去用午餐时，他们平均有 90 分钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助餐厅准备好 他们选择的午餐。但是，员工并不总是能够如愿以偿，因为自助餐厅有些食物已 卖完。而与此同时，自助餐厅又在浪费大量的食物，因为有些食物没有卖掉而只 好倒掉。早餐和午餐同样面临着这样的问题，只是到餐厅用餐的员工人数比午餐 要少得多。 1.2 业务机遇 （要求说明：如果开发的是商业产品，这部分描述的是存在的市场机遇以及产品要参与 竞争的市场。如果是企业信息系统，则应描述要解决的业务问题或需要改进的业务流程，以 及系统的应用环境。 这部分内容还应

28、对已有的产品和可能的解决方案进行比较评估，指出新产品的优点。 说明有哪些问题因为没有该产品而在当前无法解决。还要说明该产品怎样符合市场潮流、技 术发展趋势或企业的战略方向。另外，还应有一段简短的说明描述如果需要为客户提供一个 完整的解决方案，还需要哪些其他的技术、过程和资源。） 许多员工都通过自助餐厅的一个在线订餐系统提出订餐请求，要求在指定的 日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一 服务的员工可以节约相当可观的时间，而且订到自己喜欢食物的机会也增大了。 这既提高了他们的工作生活质量，也提高了他们的生产率。自助餐厅提前了解到 客户需要哪些食物，就可以减少浪费，并

29、提高高员工的工作效率。要求送货上门 的订餐员工将来还可以从本地的其他饭店来订餐，这就大大扩大了员工对食物的 选择范围，并通过与其他饭店的大量购餐协议而有可能节约费用。Process Impact 公司也可以只在自助餐厅订午餐，而在其他饭店订早餐、晚餐、特定事件的用餐 和周末会餐。 1.3 业务目标与成功标准 （要求说明：用量化和可衡量的方式概述产品提供了哪些重要的业务利益。如果其他 文档（如业务用例文档）中已包含了这些信息，此处指明参考文档即可，不必重复其内容。 这一部分还应明确涉众如何定义和判断项目的成功。说明哪些因素对项目获得成功的影响最 大，无论这些因素是否处于组织的控制范围内。还要定义

30、可衡量的标准，用于评估各项业务 目标是否已实现。） 15 BO -1：在第一版应用之后的 6 个月内，减少食物的浪费。 度量标准（Scale）：每周被自助餐厅工作人员扔掉的食物的价值。 SC -1：在第一版应用之后的 s 个月内，目前在自助餐厅用午餐的员工中，75 的人使用在线订餐系统。 SC -2：在第一版应用之后的 3 个月内，对自助餐厅满意度的季度调查评价 要提高 0.5，而在第一版应用之后的 12 个月内，这种满意度要提高 1.0。 1.4 业务风险 （要求说明：概述与产品开发相关的主要风险。风险类别包括市场竞争、时间安排、 用户认可、实现技术以及可能对业务造成的负面影响。要评估每一项

31、风险可能造成的损失、 发生的几率以及对它的控制能力。找出所有可能降低风险的必要措施。如果在业务用例分析 或类似文档中已经给出了这些信息，此处只需指明出处而不必重复该信息。） RI -1：使用该系统的员工太少，减少了对系统开发和变更自助餐厅经营过程 的投资回报。 可能性 0.3，影响为 9。 RI -2：其他本地饭店可能并不认何减价是员工使月这一系统的正当理由，这 会减低员工对该系统的满意度，并可能会减少他们对这一系统的使 月。 可能性为 0.4，影响为 3。 2 项目前景 （要求说明：这一部分建立系统的战略前景，该系统将实现业务目标。前景为产品生 命周期中所有的决策提供了背景。详细的功能需求或

32、项目计划信息不应包括在这一部分内。) 2.1 前景概述 （要求说明：用一个简洁的声明概括系统的长期目标和意图。声明应当反映能够满足不 同涉众需求的平衡的观点。前景声明可以理想化，但应当以当前或预期的市场现状、企业结 构、团体战略和资源限制为依据。） 对那些希望通过公司自助餐厅或其他本地饭店在线订餐的员工来说，“自助 餐厅订餐系统”是一个基于 Internet 的应月程序，它可以接受个人订餐或团体订 餐，结算用餐费用，并触发将预订餐送到 Process Impact 公司内指定位置的事件。 16 与当前的电话订餐和人工订餐不同，使用“自助餐厅订餐系统”的雇员并不需要到 食堂内去用餐，这既可以节约

33、他灼的时间，又可以扩大他们对食物的选择范周。 2.2 主要特性 （要求说明：为新产品的每一项主要特性或用户功能进行固定的、唯一的命名或编号， 突出其超越原有产品或竞争产品的特性。给每项特性一个唯一的标号，这样可以追踪其去向 用户需求、功能需求和其他系统元素。） FE- 1：根据自助餐厅提供的菜单来订餐。 FE-2：根据真他本地饭店的送货菜单来订餐。 FE-3：请求送餐。 FE-4：创建、浏览、修改、删除用餐预订。 FE-5：通过公司的内联网访问系统，或者授权员工通过外部 Internet 访问系统。2.3 假设与依赖 （要求说明：记录构思项目和编写前景与范围文档过程中涉众所提出的每一项假设。

34、由于一方所做的假设往往不为其他各方所知，因此通过将所有的假设记录下来并进行检查， 各方就能对项目潜在的基本假设达成一致。这样便能够避免可能的混乱以及这种混乱会在将 来造成的影响。 这一部分还记录项目对不在自身控制范围内的外部因素的主要依赖关系。这类外部因素 包括悬而未决的行业标准或政府法规、其他项目、第三方厂商及开发伙伴等。） AS-1：自助餐厅内有可以访问公司内网的计算机和打印机。 AS-2：自助餐厅有送货人员和送货车辆，最多比请求的送货时间晚 15 分钟。 DE-1：如果某饭店有自己的联机订餐系统，那么“自助餐厅订餐系统”必须能 与这一系统进行双向通信。 3 项目范围 （要求说明：项目的范

35、围定义了解决方案的概念和范围，同时也要表明系统不能提供 哪些功能，它可以帮助涉众建立现实的期望。） 3.1 第一版范围 （要求说明：概述计划在产品的第一个版本中实现的主要特性。描述产品的质量特性， 17 产品依靠这些特性为不同类别的用户提供预期利益。 如果目标是集中开发力量和维持合理的项目进度，就不要企图在 1.0 版本中包含所有可 能的需求。那样会导致项目范围在不知不觉中增大，使得进度延误。应该把注意力集中在那 些能够在最短时间内，以最适宜的成本，为最大多数用户提供最大价值的特性上。） 3.2 后续版本范围 （要求说明：如果要采取阶段性的开发方式，需要决定推迟实现哪些特性，并为后续 的版本做

36、出时间安排。后续版本能够实现更多的需求和特性，并可完善最初的功能。随着产 品的不断成熟，系统的性能、可靠性和其他质量特征也将得到改进。） 表 1 版本范围 3.3 限制与排除 (要求说明：管理范围蔓延的方法之一是，定义项目包含的需求与不包含的需求之间的 界线。此处应列出涉众可能希望得到、但不在产品或其某个特定版本计划之内的功能和特 性。) LI-1：自助餐厅的有些食物不适宜送货，因此“自助餐厅订餐索统”的顾客使 用的送货菜单是食堂整个菜单的一个子集。 LI -2“自助餐厅订餐系统”只能用子 Process Impact 公司总部内的自助餐厅。 4 项目环境 4.1 操作环境 （要求说明：描述系

37、统将用于什么样的环境，定义关键的可用性、可靠性、性能等质 量属性要求。这些信息对系统的结构定义有着重要的影响。 与操作环境相关的问题包括： 用户是地理分散的还是集中的？ 18 不同的用户会在什么时间访问系统？ 数据在何处生成，用于何处？ 访问数据时的最大响应时间是否已知？ 用户能否容忍服务中断？ 是否需要提供访问安全控制和数据保护？） 4.2 涉众 （要求说明：描述项目涉众的相关信息，重点介绍不同类型的客户、目标市场和目标 市场中的用户类别，说明他们和系统密切相关的一些特征。） 4.3 项目属性 （要求说明：要想更有效地进行决策，涉众就必须就项目的相关属性及其优先级达成 一致。这些属性包歌括：

38、特性（功能、范围）、质量、成本、进度和人员。 对任何一个特定的项目而言，上述每个属性都有三种影响因素： 驱动因素(Driver)：重要的成功目标。 约束因素（Constraint）：项目必须在一定的限制下展开工作。 可调整因素(Degree of Freedom)：可以根据其他方面进行平衡和调整的因素。 项目经理的目标是：在约束因素施加的限制内，合理安排可调整因素，获得最大的驱 动因素。 在项目属性之间不可调和时，属性间的优先级顺序指导项目管理者采取正确的行动。 例如，对于急需面市的系统，其进度是第一优先级，这样在项目无法按照预定计划前进时， 就可能会推迟特定功能的实现，或者增加人员和投资。再

39、例如，对于人员（或费用）受限的 系统，人员（费用）是第一优先级，在项目出现偏离时就可能延迟系统的完成期限，或者推 迟部分功能的实现。除特例情况之外，质量都是一个不应该被牺牲的项目属性。） 表 2 项目属性的示例 19 【附录四】 需求文档完整范例 本附录通过“自助食堂订餐系统(Cafeteria Ordering System COS)”这样一个假想的小型 项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容： 前景和范围文档。 用例列表和若干用例描述。 部分软件需求规格说明。 某些分析模型。 部分数据字典。 若干业务规则。 因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我

40、们的目标只是提供一 种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部 分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的， 因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信 息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。 这些文档总的来说都遵照前面章节所描述的模板，但是，因为这只是一个小型项目， 所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。 每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。 1 前景和范围

41、文档 1.1 业务需求 1背景、业务机会和客户需要 目前，Process Impact 公司的大多数员工平均每天要花费 60 分钟去自助食堂选择、购买 并用午餐，其中大约有 20 分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午 餐、以及以现金方式或以信用卡方式结算餐费上。当员工出去用午餐时，他们平均有 90 分 钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助食堂准备好他们所选择的 午餐。但是，员工并不是总能如愿以偿，因为自助食堂有些食物已卖完，而与此同时，自助 食堂又不可避免地会浪费大量的食物，因为有些食物没有卖出去而只好倒掉。早餐和晚餐同 样面临着这样的问题，只是到自助

42、食堂用餐的员工人数比午餐要少得多。 许多员工都通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的 日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一服务的员工 可以节约相当可观的时间，而且订到自己所喜欢的食物的机会也增大了。这既提高了他们的 工作生活质量，也提高了他们的生产率。自助食堂提前了解到客户需要哪些食物，就可以减 少浪费，并提高自助食堂员工的工作效率。要求送货上门的订餐员工将来还可以从本地的饭 店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店的大量购餐协议而有可能 节约费用。Process Impact 公司也可以只在自助食堂订午餐，而在饭

43、店订早餐、晚餐、特定 事件的用餐以及周末会餐。 2业务目标（Business Objective. BO）和成功标准（Success Criteria SC) BO-l：初始版本发布之后的 6 个月内，自助食堂的食物浪费减少 50%。 度量单位（scale）：自助食堂的工作人员每星期所倒掉的食物的价值。 20 计量(meter)检查“自助食堂存货系统（Cafeteria Inventory System）”的日志。 过去情况（past）2002，初步调研：30% 一般标准（plan）：小于 15% 最低标准（must）：小于 20% BO-2：初始版本发布之后的 12 个月内，自助食堂的运作费

44、用减少 50。 BO-3：初始版本发布之后的 3 个月内，每个雇员每天的平均有效工作时间增加 20 分钟。 SC-1：目前通过自助食堂解决午餐问题的那些员工，在初始版本发布之后的 6 个月内， 他们中有 75%的人使用“自助食堂订餐系统”。 SC-2：初始版本发布之后的 3 个月内，对自助食堂满意度的季度调查评价要提高 0.5, 而在初始版本发布之后的 12 个月内，这种满意度要提高 1.0. 3业务风险（RIsk) RI-1：“自助食堂雇员联合会(Cafeteria Employees Union)”可能要求与雇员重新签订合 同，以反映新的雇员角色和自助食堂营业时间。（可能性为 0.6.影响

45、为 3） RI-2：使用该系统的雇员太少，减少了对系统开发和变更自助食堂经营过程的投资回报。 （可能性为 0.3，影响为 9) RI-3：本地饭店可能并不认同减价是雇员使用这一系统的正当理由，这会减低雇员对该 系统的满意度，并可能会减少他们对这一系统的使用。（可能性为 0.4，影响为 3） 1.2 解决方案的前景 1前景陈述 对那些希望通过公司自助食堂或本地饭店在线订餐的员工来说，“自助食堂订餐系统” 是一个基于 Internet 的应用程序，它可以接受个人订餐或团体订餐，结算用餐费用，并触发 将预订餐送到 Process Impact 公司内的指定位置。与当前的电话订餐和人工订餐不同，使用

46、“自助食堂订餐系统”的雇员并不需要到食堂内去用餐，这既可以节约他们的时间，又可以 增加他们对食物的选择范围。 2主要特性（FEature) FE-1：根据自助食堂提供的选择菜单或送货菜单来订餐。 FE-2：根据本地饭店的送货菜单来订餐。 FE-3：创建、浏览、修改和删除用餐预订服务。 FE-4：注册用餐的付费方式。 FE-5：请求送餐。 FE-6：创建、浏览、修改和删除自助食堂菜单。 FE-7：预订自助食堂菜单上所没有的定做菜。 FE-8：生成自助食堂定做菜的食谱和配料列表。 FE-9：通过公司的内联网可以访问系统，或者授权的员工通过外部 Internet 访问系统。 3假设(ASsumpti

47、on)和依赖(DEpendency) AS-1：自助食堂内有可以访问公司内联网的计算机和打印机，这样自助食堂的雇员就 可以处理期望的订单量，不会遗漏任何送货时间。 AS-2：最多比请求的送货时间晚 15 分钟，自助食堂有送货人员和送货车辆，这样就能 满足所有订单的送货要求。 DE-1：如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一 系统进行双向通信。 1.3 范围和局限性 21 LI-2：1初始版本和后续版本的范围 2局限性（Limitation）和排斥性 LI-1：自助食堂的有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单 是食堂整个菜单的一个子集。 “自

48、助食堂订餐系统”只能用于俄勒冈州 Clackamas 的 Process Impact 公司总部内 的自助食堂。 1.4 业务上下文 1涉众概览 22 23 24 25 26 27 28 29 30 31 3 软件需求规格说明 3.1 介绍 1目标 软件需求规格说明描述了“自助食堂订餐系统(Cafeteria Ordering System, COS)1.0 版本 的软件功能性需求和非功能性需求。这一文档计划由实现和验证系统正确功能的项目团队成 员来使用。除非在其他地方另有说明，这里指定的所有需求都具有高优先级，而且都要在版 本 1.0 中加以实现。 2项目范围和产品特性 “自助食堂订餐系统”

49、允许 Process Impact 公司雇员向公司的自助食堂在线订餐，并送 餐到公司内的指定地点。详细的项目描述请参见 Cafeteria Ordering 枷 tem Visionand Scope Document(自助食堂订餐系统前景和范围文档）【1】。文档中这一部分的标题为“初始版本和 后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。 3参考文献 （1） Karl Wiegers 所著的 Cafeteria Ordering System Vision and Scope Document，其 网址是 vision and scope.doc （2）Karl Wi

50、dgers 所著的 Process Impact Intranet Development Standard 版本 1.3，其 网址是 intranet dev-std.doc （ 3 ） Christine Zambito 所 著 的 Process Impact Business Rules Catalog, 其 网 址 是 rules.doc （ 4 ） Christine Zambito 所 著 的 Process Impact Internet Application User Interface Standard 版本 2.0,其网址是 internet ui std.doc 3.

51、2 总体描述 1产品远景规划 “自助食堂订餐系统”是一个新系统，它取代了当前在 Process Impact 公司自助食堂内 以手工方式和电话方式预定和选择午餐的过程。图 D.1 是一幅关联图，它演示了 1.0 版本的 外部实体和系统接口。期望系统演化若干个版本，最终与本地若干饭店的 Internet 订餐服务 相连接，并提供信用卡和借记卡授权服务。 32 33 OE-1：OE-2：OE-3：3运行环境(Operating Environment，OE) “自助食堂订餐系统”的操作将通过如下的 Web 浏览器来完成：Microsoft Internet Explorer 版本 5.0 和 6.

52、0，Netscape Communicator 版本 4.7 和 Netscape 版本 6 和版本 7。 “自助食堂订餐系统”将运行在一个服务器中，该服务器运行当前由公司批准的 Red Hat Linux 版本和 Apache HTTP Server。 “自助食堂订餐系统”将允许用户通过公司内联网来访问，如果用户被授权在公 司的外部穿过防火墙来访问，那么用户也可以在家里通过 Internet 来访问该系统。 4设计和实现的约束条件（constraint） CO-1：系统的设计、编码和维护文档将遵照 Pruccss Impact Intranet Development Standard （Process Impact 公司内联网开发标准）版本 1.3 【2】。 CO-2：系统将采用公司标准的当前 Oracle 数据库引擎。 CO-3：所有 HTML 代码将遵照 HTML 4.0 标准。 CO-4：所有脚本都用 Perl 语言来编写。