模板-软件需求规约.docVIP

卷 号 卷内编号 密 级 项目编号分 类: 模板 使用者: 项目组 文档编号： 软件需求规约 版本号 项 目 承 担 部 门： 撰 写 人（签名）： 完 成 日 期： 本文档 使 用部门： □主管领导 □项目组 □客户（市场） □维护人员 □用户 评审负责人（签名）： 评 审 日 期： 文档信息 标题: 作者: 创建日期: 上次更新日期: 版本: 部门名称: 修订文档历史记录 日期 版本 说明 作者 目录 1. 简介 3 1.1 目的 3 1.2 范围 3 1.3 定义、首字母缩写词和缩略语 3 1.4 参考资料 3 1.5 概述 3 2. 整体说明 3 3. 具体需求 3 3.1 功能 3 3.1.1 功能性需求一 3 3.2 可用性 3 3.2.1 可用性需求一 3 3.3 可靠性 3 3.3.1 可靠性需求一 3 3.4 性能 3 3.4.1 性能需求一 3 3.5 可支持性 3 3.5.1 可支持性需求一 3 3.6 设计约束 3 3.6.1 设计约束一 3 3.7 联机用户文档和帮助系统需求 3 3.8 购买的构件 3 3.9 接口 3 3.9.1 用户界面 3 3.9.2 硬件接口 3 3.9.3 软件接口 3 3.9.4 通信接口 3 3.10 许可需求 3 3.11 法律、版权及其他声明 3 3.12 适用的标准 3 4. 支持信息 3 软件需求规约 简介 软件需求规约 (SRS) 的简介应提供整个 SRS 的概述。它应包括此 SRS 的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 目的 [阐明此 SRS 的目的。SRS 应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。] 范围 [简要说明此 SRS 适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到此文档影响的任何其他事物。] 定义、首字母缩写词和缩略语 [本小节应提供正确理解此 SRS 所需的全部术语的定义、首字母缩写词和缩略语。?这些信息可以通过引用项目词汇表来提供。] 参考资料 [本小节应完整列出此 SRS 中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。] 概述 [本小节应说明该 SRS 中其他部分所包含的内容，并解释此文档的组织方式。] 整体说明 [SRS 的这一节应说明影响产品及其需求的一般因素。本节并不列出具体的需求，而只是提供在第 3 节中详述的各种需求的背景，以使这些需求便于理解。所包括的内容有： ? 产品总体效果 ? 产品功能 ? 用户特征 ? 约束 ? 假设与依赖关系 ? 需求子集] 具体需求 SRS 的这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。?当利用用例建模时，这些需求在用例和适用的补充规约中记录。如果没有利用用例建模，则可以将补充规约的概要直接插入此节。如下所示。] 功能 [此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序，此节会成为 SRS 包的主体部分，所以应仔细考虑此节的组织方式。此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。功能性需求可能包括特性集、性能和安全性。 功能性需求一 [需求说明。] 可用性 [此节应包括所有影响可用性的需求。 可用性需求一 [在此给出需求说明。] 可靠性 [对系统可靠性的需求应在此处说明。以下是一些建议： ? 可用性—指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。 ? 平均故障间隔时间 (MTBF) – 通常表示为小时数，但也可表示为天数、月数或年数。 ? 平均修复时间 (MTTR) — 系统在发生故障后可以暂停运行的时间。 ? 精确度 — 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 ? 最高错误或缺陷率—通常表示为每千行代码的错误数目 (bugs/KLOC) 或每个功能点的错误数目 (bug