需求规约.doc

1、软件需求规约用于版本 Version: 软件需求规约 Date: Confidential , 2000 Page 2修订历史记录日期 版本 说明 作者Version: 软件需求规约 Date: Confidential , 2000 Page 3目录1. 简介 41.1 目的 41.2 范围 41.3 定义、首字母缩写词和缩略语 41.4 参考资料 41.5 概述 42. 整体说明 43. 具体需求 53.1 功能 53.1.1 53.2 可用性 53.2.1 63.3 可靠性 63.3.1 63.4 性能 63.4.1 73.5 可支持性 73.5.1 73.6 设计约束 73.6.1 7

2、3.7 联机用户文档和帮助系统需求 73.8 购买的构件 73.9 接口 73.9.1 用户界面 73.9.2 硬件接口 73.9.3 软件接口 73.9.4 通信接口 83.10 许可需求 83.11 法律、版权及其他声明 83.12 适用的标准 84. 支持信息 8Version: 软件需求规约 Date: Confidential , 2000 Page 4软件需求规约 1. 简介软件需求规约 (SRS) 的简介应提供整个 SRS 的概述。它应包括此 SRS 的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。 注：软件需求规约 (SRS) 记录对系统或系统的一部分的完整软件需求。

3、 以下是一个典型的 SRS 概述，用于以传统的自然语言风格表达需求而 不涉及用例建模 的项目。它在一个文档中记录了所有的需求，而适用的部分可从补充规约（此后将不再需要）中插入。对于涉及用例建模的 SRS 模板（由包含用例模型的用例、适用的补充规约及其他支持信息的包组成），请参见 rup_SRS-uc.dot。 SRS 可能有许多不同的组织方式。有关这些方式的进一步阐述以及 SRS 的其他结构组织方式，请参见 IEEE830-1998。 1.1 目的阐明此 SRS 的目的。 SRS 应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所

4、需的其他因素。 1.2 范围简要说明此 SRS 适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到此文档影响的任何其他事物。 1.3 定义、首字母缩写词和缩略语本小节应提供正确理解此 SRS 所需的全部术语的定义、首字母缩写词和缩略语。 这些信息可以通过引用项目词汇表来提供。 1.4 参考资料本小节应完整列出此 SRS 中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。 1.5 概述本小节应说明该 SRS 中其他部分所包含的内容，并解释此文档的组织方式。 2. 整体

5、说明SRS 的这一节应说明影响产品及其需求的一般因素。本节并不列出具体的需求，而只是提供在第 3 节中详述的各种需求的背景，以使这些需求便于理解。所包括的内容有： 产品总体效果Version: 软件需求规约 Date: Confidential , 2000 Page 5 产品功能 用户特征 约束 假设与依赖关系 需求子集 3. 具体需求SRS 的这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。 当利用用例建模时，这些需求在用例和适用的补充规约中记录。如果没有利用用例建模，则可以将补充规约的概要直接插入此节。如下所

6、示。 3.1 功能此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序，此节会成为 SRS 包的主体部分，所以应仔细考虑此节的组织方式。此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。功能性需求可能包括特性集、性能和安全性。当利用应用程序开发工具（如需求工具、建模工具等）来获取功能性时，此节文档将引用获取相应数据的方法，并指出用来获取数据的工具的位置和名称。 3.1.1 需求说明。 3.2 可用性此节应包括所有影响可用性的需求。例如， 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出典型任务的可评测任务次数或根据用户已知

7、或喜欢的其他系统确定新系统的可用性需求 指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求 Version: 软件需求规约 Date: Confidential , 2000 Page 63.2.1 在此给出需求说明。 3.3 可靠性对系统可靠性的需求应在此处说明。以下是一些建议： 可用性 指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。 平均故障间隔时间 (MTBF) 通常表示为小时数，但也可表示为天数、月数或年数。 平均修复时间 (MTTR) 系统在发生故障后可以暂停运行的时间。 精确度 指出系统输出

8、要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 最高错误或缺陷率 通常表示为每千行代码的错误数目 (bugs/KLOC) 或每个功能点的错误数目 (bugs/function-point)。 错误或缺陷率 按照小错误、大错误和严重错误来分类。需求中必须对 “严重 ”错误进行界定，例如：数据完全丢失或完全不能使用系统的某部分功能。 3.3.1 需求说明。 3.4 性能此节应概述系统的性能特征。其中需包括具体的响应时间。如果可行，按名称引用相关用例。 对事务的响应时间（平均、最长） 吞吐量，例如每秒处理的事务数 容量，例如系统可以容纳的客户或事务数 降级模式（当系统以某种形式降级时可接

9、受的运行模式） 资源利用情况，如内存、磁盘、通信等3.4.1 在此给出需求说明。 Version: 软件需求规约 Date: Confidential , 2000 Page 73.5 可支持性此节应列出将提高所构建系统的可支持性或可维护性的所有需求，其中包括编码标准、命名约定、类库、维护访问权和维护实用程序。 3.5.1 在此给出需求说明。 3.6 设计约束此节应列出所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。 3.6.1 在此给出需求说明。 3.7 联机用户文档和帮助系统需求如果

10、存在对联机用户文档、帮助系统、关于声明的帮助等的需求，请在此说明。 3.8 购买的构件此节说明在系统中使用的所有购入构件、所有适用的许可或使用限制，以及所有相关的兼容性及互操作性或接口标准。 3.9 接口此节规定应用程序必须支持的接口 /界面。它应非常具体，包含协议、端口和逻辑地址等，以便于按照接口 /界面需求开发并检验软件。 3.9.1 用户界面说明软件将实现的用户界面。 3.9.2 硬件接口此节指出软件所支持的所有硬件接口，其中包括逻辑结构、物理地址、预期行为等。 3.9.3 软件接口此节说明软件系统中与其他构件之间的软件接口。这些构件可以是购入的构件、取自其他应用程序重新利用的构件，也可

11、以是为此 SRS 范围之外的子系统开发，但该软件应用程序必须与之交互的构件。 Version: 软件需求规约 Date: Confidential , 2000 Page 83.9.4 通信接口说明与其他系统或设备（如局域网、远程串行设备等）的所有通信接口。 3.10 许可需求定义所有许可执行需求或软件将体现的其他使用限制需求。 3.11 法律、版权及其他声明此节说明软件涉及的所有必需的法律免责声明、保证、版权声明、专利声明、字标、商标或徽标符合性问题。 3.12 适用的标准通过引用，此节说明了所有适用的标准以及适用于所述系统的相应标准的具体部分。例如，其中可以包括法律、质量及法规标准；业界在可用性、互操作性、国际化、操作系统相容性等方面的标准。 4. 支持信息支持信息用于使 SRS 更易于使用。它包括： 目录 索引 附录其中可以包括用例示意板或用户界面原型。如果包含附录， SRS 应明确指出是否将附录当作需求的一部分。