需求规格说明书实用模板

1、软件需求规格说明书模版 目录1简介41.1编写目的41.2预期的读者和阅读建议41.3术语、定义、符号及缩略语41.4参考资料42综合描述42.1项目背景52.2产品功能52.3应用模型52.4运行环境52.5假设和依赖53功能需求63.1包结构模型/模块关系模型63.2用例包1（采用用例模型）63.2.1用例模型图63.2.2主要信息63.2.3用例173.3特性1（不采用用例模型）83.3.184非功能性需求114.1性能需求114.1.1性能需求1114.2可靠性需求114.2.1可靠性需求1114.3安全需求114.3.1安全需求1114.4其他需求114.4.1其他需求1115外部接

2、口需求125.1用户接口125.1.1125.2硬件接口135.2.1135.3软件接口145.3.1145.4通信接口155.4.1156附录161 简介提出对软件需求规格说明书的纵览，帮助读者理解文档如何编写并且如何阅读和解释。1.1 编写目的对产品（也可能是项目，但是我们统称为产品）进行定义，在该文档中详尽说明这个产品的需求，包括修正或发行版本号。如果这个产品需求规格说明书只与整个系统的一部分有关，那么只定义文档中说明的部分或子系统。举例：本文的目的是为了清晰地说明产品要实现的所有功能，产品的设计、编码和测试都要以本文的内容为基础。同时，本文确定的内容还作为产品验收的基准。客户、项目组要

3、共同协商本文内容。1.2 预期的读者和阅读建议列举本文档所针对的不同读者，例如开发人员、市场人员、测试人员、客户等。描述文档中剩余部分的内容及其组织结构，提出最适合每一类型读者阅读文档的建议。1.3 术语、定义、符号及缩略语按字母或拼音顺序列出所有的定义和缩略语，以便读者可以正确地理解产品需求规格说明书，包括词头和缩写。注意：只需要列出对理解本文有用的术语。举例：PRS：Product Requirement Specification（产品需求规格说明书）。 1.4 参考资料列举编写软件需求规格说明书时所参考的资料或其它来源。可能包括用户界面风格指导、合同、标准、系统需求规格说明书、用户需求

4、、相关产品的产品需求规格说明书。这里应该给出参考资料详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。2 综合描述这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。2.1 项目背景描述产品需求规格说明书中所定义的产品的背景和起源。说明该产品是否是产品系列中的下一个成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个全新的产品。2.2 产品功能概述产品必须具备的主要功能，本文档在第三章对产品功能进行详细描述，在此仅作概括总结，重点在系统层次上描述产品的功能需求和功能分类，还可能包括保证产品

5、与外部组件正确连接的需求。可以使用列表的方法给出，也可使用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图。以使描述更加有效。2.3 应用模型运用场合、环境、组网、应用举例。绘制产品的结构图示、与系统相交互的外部对象之间的关系。如果该部分内容与市场需求分析报告中“产品的组网与应用分析”内容完全相同，请直接引用（例如：请参见市场需求分析报告中“产品的组网与应用分析”）。2.4 运行环境描述产品的运行环境，包括为支持产品工作所需的其它的组件或者与其共存的产品；对于软件产品还应包括硬件平台、操作系统和版本、必须安装的软件部件和其他应用软件等。2.5 假设和依赖列出所有会影响需求

6、实现的假设因素（相对于已知的事实而言），可能包括打算要用的商业组件或有关开发或运行环境的问题。例如，本项目产品计划要使用某些第三方软件产品或商业软件产品，虽然目前还未得到这些软件，但我们可以假设这些软件一定能够得到。如果这些假设不正确、或发生改变，会影响项目的开发，因此，这些假设往往又是一种风险。此外，确定项目对外部因素存在的依赖。例如，如果项目的开发或项目产品的使用要依靠其它外部因素，比如与其它产品共用的软件包、准备重用的软件构件等，也要在此说明。3 功能需求本章将详细解释产品所有的功能需求。功能需求是根据系统特性即产品所提供的主要服务来组织的。你可能更喜欢通过用例、运行模式、用户类、对象类

7、或功能等级来组织这部分内容，你还可以使用它们的组合。总之，你必须选择一种使读者易于理解预期产出的组织方案。如果使用传统的需求分析方法，本章的每一节描述一个功能需求，每个功能需求又从编号、名称、优先级、输入、处理、输出、验收准则7项来说明。如果使用UML模型描述需求分析结果，本章的每一节采用“使用用例”描述一个功能需求，并在此说明参考的“使用用例”文件名；如果你采用模型工具绘制用例视图，你应在此注明所用工具的名称、版本等信息。本章中所列出的需求，要求细化到如下程度：（1）设计人员可以依据该需求设计并实现系统；（2）系统测试人员可以依据该需求编写测案并对系统进行验证。3.1 包结构模型/模块关系模

8、型使用UML模型描述需求分析结果时，在本节划分出系统的包结构，用图表示出用户机构与本系统各个包之间的关系和本系统各包部分之间的关系。使用传统的需求分析方法时，在本节划分出系统的各功能模块结构，用图表示出用户机构与本系统各个功能模块之间的关系和本系统各功能模块之间的关系。3.2 用例包1（采用用例模型）3.2.1 用例模型图3.2.2 主要信息【对于每个包应当说明以下信息：名称简要说明该包所拥有的用例列表该包所拥有的角色列表直属该包的包列表】3.2.3 用例13.2.3.1 优先级该需求的优先级，按高、中、低的优先级分类。对高、中、低的解释如下：高：关键的功能特性，必选，不能实现意味着无法满足客

9、户的需求。所有“高”优先级的需求必须在本次项目开发中实现。中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。3.2.3.2 简要说明【用例的简要说明应反映用例的角色和目的。在撰写说明时，应参考用例中所涉及的主角、词汇表，并根据需要定义新概念。以下是回收机系统中“回收贮藏物品”用例的简要说明示例：回收贮藏物品：用户使

10、用本机器来自动统计所有回收物品（瓶子、罐子以及箱子），并得到一张收据。收据将在收银机处兑现。】3.2.3.3 参与者3.2.3.4 事件流【用例事件流包含用例建模工作所得到的最重要的信息。应该清楚地说明用例的事件流，让外行也能很容易地理解它。请记住，事件流应该说明系统做什么，而不是说明为了执行所需的行为而对系统进行的设计。事件流的两个主要部分是主事件流和扩展事件流。主事件流应包括在执行用例时“通常”会发生的事件。扩展事件流包括与正常行为相关的可选或异常特征的行为，同时也包括正常行为的各种变形。您可以将扩展事件流看作是主事件流的“绕行道”，有些扩展事件流将返回到主事件流，而有些将结束此用例的执行

11、。】3.2.3.4.1 主事件流3.2.3.4.2 扩展事件流3.2.3.5 前置条件【前置条件或后置条件所说明的状态应该是用户可以观察到的状态。“用户已经登录系统”或“用户已经打开文档”都是可观察状态的示例。前置条件是对用例何时开始的约束。它并不是使用例开始的事件。例如自动柜员机中“提取现金”用例的前置条件为：客户拥有一张个人专用卡，这张卡正好可以塞进读卡器，并且该卡已经分到一个 PIN 号，还向银行业务系统进行了登记。】3.2.3.6 触发条件【触发条件是说明触发用例执行的条件。例如“预定客房”用例的触发条件是客户申请预定客房，其前置条件是当前有空的客房。】3.2.3.7 后置条件【例如，

12、自动柜员机中“提取现金”用例的后置条件为：当用例结束时，所有帐户和交易日志都已收支平衡，与银行业务系统的通信已重新初始化，并且银行卡已经返还给客户。】3.3 特性1（不采用用例模型）在此对进行概要性说明，例如：此模块中包含实现预付费业务所需的所有功能。3.3.1 本节的标题需以实际的需求名代替。3.3.1.1 编号为需求定义一个唯一的编号，便于需求跟踪。3.3.1.2 名称及说明需求名称，如果需要可以在此对需求的内容作简要的描述。3.3.1.3 优先级该需求的优先级，按高、中、低的优先级分类。对高、中、低的解释如下：高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的

13、需求必须在本次项目开发中实现。中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。3.3.1.4 输入列出本需求所有的输入（触发条件、输入参数）。对每项输入，可能的属性如下：输入名说明类型例如：Int、String输入值的范围输入来源格式3.3.1.5 处理描述为了满足该项功能应进行哪些事务处理。可以用文本方式、伪指

14、令或流程图来描述。3.3.1.6 输出列出本需求所有的输出（输出参数、处理结果）。对每项输出，可能的属性如下：输出名说明类型输出值的范围输出值的目标格式4 非功能性需求4.1 性能需求4.1.1 性能需求14.1.1.1 编号4.1.1.2 名称及说明4.1.1.3 优先级4.1.1.4 验收准则4.2 可靠性需求4.2.1 可靠性需求14.2.1.1 编号4.2.1.2 名称及说明4.2.1.3 优先级4.2.1.4 验收准则4.3 安全需求4.3.1 安全需求14.3.1.1 编号4.3.1.2 名称及说明4.3.1.3 优先级4.3.1.4 验收准则4.4 其他需求4.4.1 其他需求1

15、4.4.1.1 编号4.4.1.2 名称及说明4.4.1.3 优先级4.4.1.4 验收准则5 外部接口需求表三：外部接口需求分类表需求类别编号需求名称优先级描述5.1 用户接口陈述产品中所需要的用户界面。描述每个用户界面的逻辑特征。以下是可能要包括的一些特征：l 将要采用的图形用户界面标准或整个产品系列的风格；l 屏幕布局；l 将出现在每个屏幕的标准按钮（如帮助）、功能或导航链接；l 键盘快捷键；l 错误信息显示标准。如果必要，用户接口需求的细节可在独立的用户接口规格文件中描述。5.1.1 本节的标题需以实际的需求名代替。5.1.1.1 编号为需求定义一个唯一的编号，便于需求跟踪。5.1.1

16、.2 名称及说明需求名称，如果需要可以在此对需求的内容作简要的描述。5.1.1.3 优先级该需求的优先级，按高、中、低的优先级分类。对高、中、低的解释如下：l 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的需求必须在本次项目开发中实现。l 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。l 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版

17、本中实现。5.1.1.4 验收准则说明用于验证满足需求的验收准则。5.2 硬件接口描述系统中软件和硬件每一接口的特征，可能包括软件所支持的设备类型、软硬件之间交流的数据和控制信息的性质、通讯协议等。5.2.1 本节的标题需以实际的需求名代替。5.2.1.1 编号为需求定义一个唯一的编号，便于需求跟踪。5.2.1.2 名称及说明需求名称，如果需要可以在此对需求的内容作简要的描述。5.2.1.3 优先级该需求的优先级，按高、中、低的优先级分类。对高、中、低的解释如下：l 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的需求必须在本次项目开发中实现。l 中：重要的功能，

18、必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。l 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。5.2.1.4 验收准则说明用于验证满足需求的验收准则。5.3 软件接口说明本产品与其它外部组件（包括数据库、操作系统、工具、运行库、集成的商业部件等，要指明它们的名字和版本）的连接。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在

19、组件之间共享的数据。如果必须用一种特殊的方法来实现数据共享机制，例如在多任务操作系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制。5.3.1 本节的标题需以实际的需求名代替。5.3.1.1 编号为需求定义一个唯一的编号，便于需求跟踪。5.3.1.2 名称及说明需求名称，如果需要可以在此对需求的内容作简要的描述。5.3.1.3 优先级该需求的优先级，按高、中、低的优先级分类。对高、中、低的解释如下：l 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的需求必须在本次项目开发中实现。l 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在