需求文档模板.docx

1、需求文档模板文档编号：项目编号SRS流水号 第版分册名称： 第册/共册项目名称（项目编号）软件需求规约XXXX有限公司总页数正文附录生效日期编制批准变更履历修改编号版本修改内容修改人修改日期1. 简介 11.1 目的 11.2 范围 11.3 参考资料 11.4 概述 12. 整体说明 12.1 产品总体效果 22.2 假设与依赖关系 22.3 系统运行环境 22.3.1 设备及分布 22.3.2 支撑软件 23. 具体需求 23.1 功能性 33.1.1 功能性需求1 33.2 可用性 33.2.1 可用性需求1 33.3 可靠性 33.3.1 可靠性需求1 43.4 安全性需求 43.4.

2、1 安全性需求1 43.5 性能 43.5.1 性能需求1 53.6 可支持性 53.6.1 可支持性需求1 53.7 设计约束 53.7.1 设计约束1 53.8 联机用户文档和帮助系统需求 53.9 购买的构件 63.10 接口/界面 63.10.1 用户界面 63.10.2 硬件接口 63.10.3 软件接口 63.10.4 通信接口 63.11 许可需求 63.12 法律、版权及其他声明 63.13 适用的标准 74. 界面原型 75. 需求优先级 76. 软件功能列表 77. 附件 81. 简介软件需求规约(SRS)的简介应提供整个文档的概述。它应包括软件需求规约的目的、范围、定义、

3、首字母缩写词、缩略语、参考资料和概述。软件需求规约记录对系统或系统的一部分的完整软件需求。?以下是一个典型的软件需求规约概述，用于涉及用例建模的项目。此工件由一个包组成，该包包含用例模型的用例、适合的补充规约以及其他支持信息。文档的提示性语言请在报告完成时将提示文字删除。1.1 目的阐明此软件需求规约的目的。软件需求规约应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。1.2 范围简要说明此软件需求规约适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到此文档影响的任何其他事物。1.3 参考资料本小

4、节应完整地列出此软件需求规约中其他部分所引用的所有文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。1.4 概述此小节应说明软件需求规约其他部分所包含的内容，并解释文档的组织方式。2. 整体说明软件需求规约的这一节应说明影响产品及其需求的一般因素。本节并不列出具体的需求，而只是提供在第3节中详述的各种需求的背景，以使这些需求便于理解。2.1 产品总体效果用技术性语言描述产品的总体需求2.2 假设与依赖关系本节说明所有重要的技术可行性假设、子系统或构件可用性假设，或者可作为此软件需求规约所述软件可行性的基础的

5、其他与项目有关的假设。2.3 系统运行环境详细说明系统的运行环境2.3.1 设备及分布可以从以下方面进行描述：1. 主机类型2. 网络类型3. 存储器类型、容量4. 其他特殊设备5. 设备分布图2.3.2 支撑软件可以从以下方面进行描述：操作系统数据库管理系统其他支撑软件等3. 具体需求软件需求规约的这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。3.1 功能性此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序，此节会成为软件需求规约包的主体部分，所以应仔细考虑此节的组织方式。此节通常按特

6、性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。功能性需求可以包括特性集、功能和安全性。当利用应用程序开发工具（如需求工具、建模工具等）来获取功能性时，此节文档将引用获取相应数据的方法，并指出用来获取数据的工具的位置和名称。3.1.1 功能性需求1需求说明3.2 可用性软件产品的可用性是产品使用方便且实用的程度。也可定义为：系统操作人员在给定的操作时间剖面、给定的操作时间内，不会遇到界面问题的可能性。此节应包括所有影响可用性的需求。例如，1. 指出普通用户和高级用户要高效地执行特定操作所需的培训时间2. 指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系

7、统的可用性需求3. 指出在符合公认的可用性标准（如IBM的CUA标准和Microsoft的GUI标准）方面的需求可用性需求若用户没有提出需求，则指明按照事业部可用性规范执行，此处不用具体描写3.2.1 可用性需求1在此给出需求说明3.3 可靠性可靠性是指软件在用户可接受模式下持续、一致运行的能力。对系统可靠性的需求应在此处说明。以下是一些建议：1. 可用性指出可用时间百分比(xx.xx%)、使用小时数、维护访问权、降级模式操作等。2. 平均故障间隔时间(MTBF)通常表示为小时数，但也可表示为天数、月数或年数。3. 平均修复时间(MTTR)系统在发生故障后可以暂停运行的时间。4. 精确度指出系

8、统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。5. 最高错误或缺陷率通常表示为每千行代码的错误数目(bugs/KLOC)或每个功能点的错误数目(bugs/function-point)。6. 错误或缺陷率按照小错误、大错误和严重错误来分类。需求中必须对“严重”错误进行界定，例如：数据完全丢失或完全不能使用系统的某部分功能。3.3.1 可靠性需求1需求说明3.4 安全性需求此节应包括所有安全性需求。确定需要保护的数据；确定各种数据所受到的安全威胁的类型，如意外的损坏或破坏；故意的损坏或破坏；商业间谍行为；欺骗；黑客行为；病毒3.4.1 安全性需求1需求说明3.5 性能此节应概述

9、系统的性能特征。其中需包括具体的响应时间。如果可行，按名称引用相关用例。对事务的响应时间（平均、最长）1. 吞吐量，例如每秒处理的事务数2. 容量，例如系统可以容纳的客户或事务数3. 降级模式（当系统以某种形式降级时可接受的运行模式）4. 资源利用情况，如内存、磁盘、通信等3.5.1 性能需求1在此给出需求说明3.6 可支持性支持性是指软件易于被修改、增强或修复的能力。此节应列出将提高所构建系统的可支持性或可维护性的所有需求，其中包括可测试性（如在线状态测试），可扩展性（在线升级），可维护性（远程维护，维护时间），可配置性，可安装性，本地支持等等3.6.1 可支持性需求1在此给出需求说明3.7

10、 设计约束此节应列出所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计决定，其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。如有客户提供的技术、业务规范等文档需作为此文档的附件。如果需要兼容遗留系统的数据，也需要在此说明，并附上对遗留系统数据的详细说明文档3.7.1 设计约束1在此给出需求说明3.8 联机用户文档和帮助系统需求如果存在对联机用户文档、帮助系统、关于声明的帮助等的需求，请在此说明。3.9 购买的构件此节说明在系统中使用的所有购入构件、所有适用的许可或使用限制，以及所有相关的兼容性及互操作性或接口标准。3.10 接口/界面此节规定

11、应用程序必须支持的接口/界面。它应非常具体，包含协议、端口和逻辑地址等，以便于按照接口/界面需求开发并检验软件。3.10.1 用户界面说明软件将实现的用户界面。3.10.2 硬件接口此节指出软件所支持的所有硬件接口，其中包括逻辑结构、物理地址、预期行为等。3.10.3 软件接口此节说明软件系统中与其他构件之间的软件接口。这些构件可以是购入的构件、取自其他应用程序重新利用的构件，也可以是为此SRS范围之外的子系统开发，但该软件应用程序必须与之交互的构件。3.10.4 通信接口说明与其他系统或设备（如局域网、远程串行设备等）的所有通信接口。3.11 许可需求定义所有许可执行需求或软件将体现的其他使

12、用限制需求。3.12 法律、版权及其他声明此节说明软件涉及的所有必需的法律免责声明、保证、版权声明、专利声明、字标、商标或徽标符合性问题。3.13 适用的标准通过引用，此节说明了所有适用的标准以及适用于所述系统的相应标准的具体部分。例如，其中可以包括法律、质量及法规标准；业界在可用性、互操作性、国际化、操作系统相容性等方面的标准。4. 界面原型界面原型能让用户事先对界面产生直观的认知并提出重要的意见和建议，以避免事后弥补可用性和功能缺陷的高昂代价。界面原型可以是手工绘制的草图、借助计算机绘制的图片、甚至可以模拟简单的操作。在揭示问题的前提下，界面原型越简单越好。5. 需求优先级确定所有识别的需

13、求（包括非功能性需求）的编号和优先级，提供优先级列表。功能性需求编号为FUN-序号，非功能性需求编号为SUPP-序号;优先级用高中低表示。优先级为高的需求为：必不可少的，不满足这些需求就无法使系统满足客户的需要；优先级为中的需求为：对于系统在大多数应用中的有效性及效率都较为重要的需求，如果遗漏了可能会影响客户或用户满意度；优先级为低的需求为：在不太典型的应用中比较有用或者可以合理而有效地实现其替代需求，这些特性的使用次数将会相对较少，不会对客户满意度造成严重的影响。需求编号需求描述优先级FUN-1高FUN-2中FUN-3中SUPP-1低6. 软件功能列表确定该软件产品具有的功能，对于产品升级项目，需要明确功能对应的产品的版本。功能编号同功能需求编号，功能编号为FUN-序号。功能编号功能描述产品版本FUN-11.0FUN-21.0FUN-31.0FUN-41.17. 附件后台系统建议提供规则性说明文档，如采集规则、预处理规则、计费规则等作为附件