<项目名称> Version: <1.0> 软件需求规约 Date:<dd/mmm/yy> <document identifier> 软件需求规约 1.简介 就件需求规约SRS的简介应提供整个SRS的概述。它应包括此SRS的目的、范围、定义、首字 母缩写词、缩略语、参考资料和概述。1 [注：软件需求规约SRS记录对系统或系统的一部分的完整软件需求。以下是一个典型的SRS概 述，用于以传统的自然语言风格表达需求而不涉及用例建模的项目。它在一个文档中记录了所有 的需求，而适用的部分可从补充规约（此后将不再需要）中插入。对于涉及用例建模的SRS模板 (由包含用例模型的用例、适用的补充规约及其他支持信息的包组成)，请参见rp_SRS-uc.dot。.] SRS可能有许多不同的组织方式。有关这些方式的进一步阐述以及SS的其他结构组织方式，请 参见IEEE830-19981.1 1.1目的 「阐明此SRS的目的。SRS应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非 功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。] 1.2范围 【简要说明此SRS适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到 此文档影响的任何其他事物。】 1.3项目的目标和成功准则 「本小节应提供正确理解此SS所需的全部术语的定义、首字母缩写词和缩略语。这些信息可以通 过引用项目词汇表来提供。】 1.4参考资料 [本小节应完整列出此SS中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适 用)、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其 他文档来提供。1 1.5概述 [本小节应说明该SRS中其他部分所包含的内容，并解释此文档的组织方式。] 2. 目前系统 3.建议的系统 SS的这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的 系统，并使测试人员能够测试该系统是否满足这些需求。当利用用例建模时，这些需求在用例和 适用的补充规约中记录。如果没有利用用例建模，则可以将补充规约的概要直接插入此节。如下 所示。] 3.1概述 Confidential ©<公司名称>，2000 Page 4<项目名称> Version: <1.0> 软件需求规约 Date: <dd/mmm/yy> <document identifier> Confidential <公司名称>, 2000 Page 4 软件需求规约 1. 简介 软件需求规约 (SRS) 的简介应提供整个 SRS 的概述。它应包括此 SRS 的目的、范围、定义、首字 母缩写词、缩略语、参考资料和概述。] [注：软件需求规约 (SRS) 记录对系统或系统的一部分的完整软件需求。 以下是一个典型的 SRS 概 述，用于以传统的自然语言风格表达需求而不涉及用例建模的项目。它在一个文档中记录了所有 的需求，而适用的部分可从补充规约（此后将不再需要）中插入。对于涉及用例建模的 SRS 模板 （由包含用例模型的用例、适用的补充规约及其他支持信息的包组成），请参见 rup_SRS-uc.dot。] [SRS 可能有许多不同的组织方式。有关这些方式的进一步阐述以及 SRS 的其他结构组织方式，请 参见 [IEEE830-1998]。] 1.1 目的 [阐明此 SRS 的目的。SRS 应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非 功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。] 1.2 范围 [简要说明此 SRS 适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到 此文档影响的任何其他事物。] 1.3 项目的目标和成功准则 [本小节应提供正确理解此 SRS 所需的全部术语的定义、首字母缩写词和缩略语。 这些信息可以通 过引用项目词汇表来提供。] 1.4 参考资料 [本小节应完整列出此 SRS 中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适 用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其 他文档来提供。] 1.5 概述 [本小节应说明该 SRS 中其他部分所包含的内容，并解释此文档的组织方式。] 2. 目前系统 3. 建议的系统 SRS 的这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的 系统，并使测试人员能够测试该系统是否满足这些需求。 当利用用例建模时，这些需求在用例和 适用的补充规约中记录。如果没有利用用例建模，则可以将补充规约的概要直接插入此节。如下 所示。] 3.1 概述