项目管理-方案阶段-需求规格说明书.docVIP

需求规格说明书 目录 （在完成需求规格说明书后，请在此处建立一个目录索引） 1 引言 1.1 编写背景 说明编写需求规格说明书的主要背景条件及目的等。 1.2 参考资料 列出下列资料的作者、标题、编号、版本和发布日期等信息，必要时说明如何得到这些资料： 本项目经核准的项目章程、项目范围说明书、合同或上级机关的批文； 项目开发计划； 本文档中引用的文件、资料，其中应该包括软件开发规范； 业务需求说明书。 1.3 术语定义 列出本文档中用到的可能会引起混淆的专门术语、定义和缩写词（通用，非通用）的原文注释（中英文）。 2 概述 描述本项目下最终产品（如软件、硬件或服务）的特性及影响其需求的一般因素。 2.1 产品的描述 用一个名字标识要生产的软件、硬件或服务产品。例如，宿主数据库管理系统，报表生成器等； 说明软件、硬件或服务产品将干什么，如果需要的话，还要说明这个产品不干什么； 说明此产品的应用情况及开发意图，应当尽可能精确地描述所有相关的利益、目的以及最终目标；如果有较高层次的规格说明存在（例如，已存在系统设计规格说明书），则应使这里的陈述与高层次规格说明中的类似陈述相一致； 列出开发项目的委托单位、承办单位及其主管部门； 如果被开发产品是独立的，则应在本节描述被开发产品的概况； 如果本应用系统是一个较大的系统或项目中的一个组成部分，那么本节应当概述这个系统或项目的每一个组成部分的功能，并标识其主要外部接口。注意，这里仅仅是一个综述性的描述。 可以用图形表达一个较大的系统或项目的主要组成、相互联系和外部接口。 本节不进行具体设计方案的描述，也不描述解决问题时的具体设计约束。本节应对在本说明书第三章（具体需求）中列出的设计约束提供理由。 2.2 产品的功能 本节应简单叙述该项目最终产品的功能。例如，对于一个财务管理系统，可以在这节描述帐目维护、财务报表等的基本要求，而不必描写为完成这些功能所要求的大量细节。有时本节内容可以直接从较高层次的规格说明中引用（如果存在）。为了清晰起见，需注意： 应当给出一个使用户、委托单位或者第一次读这个文档的人易理解的功能清单； 可以用图形表达不同功能和它们之间的关系。但要注意，这样的图形不是产品设计时所需要的，而只是一个有效的解释性工具。 本节不应当陈述具体的需求，而只应对本说明书第三章（具体需求）中要描述的需求给出理由。 2.3 开发环境 说明本产品（属于较大系统的一部分时）所依赖的支持环境。如列出软件开发所采用的操作系统、编程语言、编程工具（编译器和调试器〕、数据库平台和网络平台等。 2.4 组织结构与业务需求 对产品（系统或服务）涉及的现有的组织结构和业务流程进行简单描述 ，特别是业务的特点。进一步描述系统对组织架构和业务流程的需求，如业务变动需求。 2.5 用户特点 本节描述影响产品具体需求的最终用户的特点，并划分系统的逻辑用户群。 软件生存周期的运行和维护阶段，许多人员与系统有关。这些人员中有用户、操作员、维护人员和系统工作人员。这些人的某些特点，如教育水平、经验、技术专长等，都对系统运行有重要影响。 如果系统的大多数用户是临时用户，那么他们的具体需求可能是要求系统包含有许多如何完成基本功能的提示，而不是记忆许多繁琐的细节。 本节不陈述具体需求或针对某些特殊需求而考虑的若干具体设计约束，本节应对在本说明书第三章（具体需求）中描述的某些具体需求或设计约束提供理由。 2.6 一般约束 本节给出对一些条款的概括描述，这些条款将影响承办单位在设计阶段的工作和计划，它们包括： a) 管理方针； b) 硬件的限制； c) 与其他应用的接口； d) 并行操作； e) 实时性能； f) 检查功能； g) 控制功能； h) 信号交换协议； i) 应用的临界点； j) 安全和必威体育官网网址方面的考虑。 本节不列举具体的需求或具体的设计约束。但是，应对第三章（具体需求）中描述的某些具体需求和设计约束提供理由。 3 具体需求 本章包括软件开发者进行设计时所需要的全部细节。通常本章是需求规格说明书中篇幅最长和最重要的部分。 必须按照可验证、无歧义等要求，对用户的每个具体需求给出详细定义； 应当利用引言、概述和附录部分中的有关讨论及交叉引用关系，提供每个具体需求的背景及注释内容； 具体需求的一种分类方法为：功能需求，性能需求，设计约束，属性，外部接口需求，其它需求。 必须注意到： 具体需求应当按逻辑可读的方式组织； 每一个具体需求应使用指定的方法进行客观的验证。 3.1 功能需求 本节描述软件产品的输入经过什么处理，产生什么输出，它描述在软件中发生的基本操作。 对于每一类功能或者有时对于每一个功能，都需要描述其输入、处理和输出等需求。这些内容通过以下四小节加以描述。 3.1.1