需求规格详细说明书.doc

《需求规格详细说明书.doc》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、<项目名称>软件需求规格说明书[用于<子系统或特性>]状态o草稿标识号BNSW-PRJ-项目名缩写-RD-SRSü初始版当前版本V1.0o修订版发布日期2003-05-31模板编号BNSW-TEMP-RD-SRS密级o无密级ü秘密o绝密[注：以下提供的模板用于博恩软件公司。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=BodyText）。][要定制MicrosoftWord中的自动字段（选中时显示灰色背

2、景），请选择文件>属性，然后将标题、主题和公司等字段替换为此文档的相应信息。关闭该对话框后，通过选择编辑>全选（或Ctrl-A）并按F9，或只是在字段上单击并按F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见Word帮助。]修订历史记录日期版本说明作者2003-05-200.1提供《需求规格说明书》模板草稿蒋程2003-05-230.2提供模板编号，修改日期格式蒋程目录1.简介41.1目的41.2范围41.3定义、首字母缩

3、写词和缩略语41.4参考资料41.5概述42.整体说明43.具体需求53.1功能53.1.1<功能性需求一>53.2可用性53.2.1<可用性需求一>53.3可靠性53.3.1<可靠性需求一>53.4性能63.4.1<性能需求一>63.5可支持性63.5.1<可支持性需求一>63.6设计约束63.6.1<设计约束一>63.7联机用户文档和帮助系统需求63.8购买的构件63.9接口63.9.1用户界面63.9.2硬件接口73.9.3软件接口73.9.4通信接口73.10许可需求73.11法律、版权及其他声明73.12适用的标准74

4、.支持信息7软件需求规约1.简介软件需求规约(SRS)的简介应提供整个SRS的概述。它应包括此SRS的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。][注：软件需求规约(SRS)记录对系统或系统的一部分的完整软件需求。 以下是一个典型的SRS概述，用于以传统的自然语言风格表达需求。它在一个文档中记录了所有的需求，而适用的部分可从补充规约（此后将不再需要）中插入。如果使用了用例模型作为补充，则可以有效补充相应的功能性描述，这是，需要写出用例模型文件以及其版本。][SRS可能有许多不同的组织方式。有关这些方式的进一步阐述以

5、及SRS的其他结构组织方式，请参见[IEEE830-1998]。]1.1目的[阐明此SRS的目的。SRS应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。]1.2范围[简要说明此SRS适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到此文档影响的任何其他事物。]1.3定义、首字母缩写词和缩略语[本小节应提供正确理解此SRS所需的全部术语的定义、首字母缩写词和缩略语。 这些信息可以通过引用项目词汇表来提供。]1.4参考资料[本小节应完

6、整列出此SRS中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。]1.5概述[本小节应说明该SRS中其他部分所包含的内容，并解释此文档的组织方式。]2.整体说明[SRS的这一节应说明影响产品及其需求的一般因素。本节并不列出具体的需求，而只是提供在第3节中详述的各种需求的背景，以使这些需求便于理解。所包括的内容有：•产品总体效果•产品功能•用户特征•约束•假设与依赖关系•需求子集]1.具体需求SRS的这一节应包含所有的软件

7、需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。 当利用用例建模时，这些需求在用例和适用的补充规约中记录。如果没有利用用例建模，则可以将补充规约的概要直接插入此节。如下所示。]1.1功能[此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序，此节会成为SRS包的主体部分，所以应仔细考虑此节的组织方式。此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。功能性需求可能包括特性集、性能和安全性。当利用应用程序开发工具（如

8、需求工具、建模工具等）来获取功能性时，此节文档将引用获取相应数据的方法，并指出用来获取数据的工具的位置和名称。]1.1.1<功能性需求一>[需求说明。]1.2可用性[此节应包括所有影响可用性的需求。例如，•指出普通用户和高级用户要高效地执行特定操作所需的培训时间