RUP软件文档模板+-+软件需求规约2.doc

<项目名称>软件需求规约用于<子系统或特性>版本<>[注:以下提供的模板用于RationalUnifiedProcess。其中包括用方括号括起来并以蓝色斜体(样式=InfoBlue)显示的文本,它们用于向作者提供指导,在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式(样式=BodyText)。][要定制MicrosoftWord中的自动字段(选中时显示灰色背景),请选择File>Properties,然后将Title、pany等字段替换为此文档的相应信息。关闭该对话框后,通过选择Edit>SelectAll(或Ctrl-A)并按F9,或只是在字段上单击并按F9,可以在整个文档中更新自动字段。对于页眉和页脚,这一操作必须单独进行。按Alt-F9,将在显示字段名称和字段内容之间切换。有关字段处理的详细信息,请参见Word帮助。]修订历史记录日期版本说明作者<日/月/年><><详细信息><姓名>                目录1.  简介    目的    范围    定义、首字母缩写词和缩略语    参考资料    概述  42.  整体说明  43.  具体需求    功能    <功能性需求一>    可用性    <可用性需求一>    可靠性    <可靠性需求一>    性能    <性能需求一>    可支持性    <可支持性需求一>    设计约束    <设计约束一>    联机用户文档和帮助系统需求    购买的构件    接口    用户界面    硬件接口    软件接口    通信接口    许可需求    法律、版权及其他声明    适用的标准  84.  支持信息  (SRS)的简介应提供整个SRS的概述。它应包括此SRS的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。][注:软件需求规约(SRS)记录对系统或系统的一部分的完整软件需求。 以下是一个典型的SRS概述,用于以传统的自然语言风格表达需求而不涉及用例建模的项目。它在一个文档中记录了所有的需求,而适用的部分可从补充规约(此后将不再需要)中插入。对于涉及用例建模的SRS模板(由包含用例模型的用例、适用的补充规约及其他支持信息的包组成),请参见rup_SRS-。][SRS可能有许多不同的组织方式。有关这些方式的进一步阐述以及SRS的其他结构组织方式,请参见[IEEE830-1998]。]目的[阐明此SRS的目的。SRS应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。]范围[简要说明此SRS适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型,以及受到此文档影响的任何其他事物。]定义、首字母缩写词和缩略语[本小节应提供正确理解此SRS所需的全部术语的定义、首字母缩写词和缩略语。 这些信息可以通过引用项目词汇表来提供。]参考资料[本小节应完整列出此SRS中其他部分所引用的任何文档。每个文档应标有标题、报告号(如果适用)、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。]概述[本小节应说明该SRS中其他部分所包含的内容,并解释此文档的组织方式。][SRS的这一节应说明影响产品及其需求的一般因素。本节并不列出具体的需求,而只是提供在第3节中详述的各种需求的背景,以使这些需求便于理解。所包括的内容有:?  产品总体效果?  产品功能?  用户特征?  约束?  假设与依赖关系?  需求子集],其详细程度应使设计人员能够设计出可以满足这些需求的系统,并使测试人员能够测试该系统是否满足这些需求。 当利用用例建模时,这些需求在用例和适用的补充规约中记录。如果没有利用用例建模,则可以将补充规约的概要直接插入此节。如下所示。]功能[此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序,此节会成为SRS包的主体部分,所以应仔细考虑此节的组织方式。此节通常按特性来组织,但也可能会有其他适用的组织方式,例如按用户或子系统组织的方式。功能性需求可能包括特性集、性能和安全性。当利用应用程序开发工具(如需求工具、建模工具等)来获取功能性时,此节文档将引用获取相应数据的方法,并指出用来获取数据的工具的位置和名称。]<功能