软件需求规格说明书SRS模板.docx

1、软件需求规格说明书SRS模板产品名称密级产品版本共2页XX 软件需求规格说明书拟制日期yyyy-mm-dd评审人日期yyyy-mm-dd批准日期yyyy-mm-dd签发日期yyyy-mm-dd版权所有 XX（仅供内部使用）修订记录日期修订版本Defect IDCR号修改章节修改描述作者2001-06-081.00初稿完成作者名yyyy-mm-dd1.01xxxx.x.x; y.y.yI. 修改XXX1. Xxx2. Xxx3. .作者名xxxx.x.x; y.y.yI. 修改XXX1. Xxx2. Xxx3. .作者名yyyy-mm-dd1.02xxxx.x.x; y.y.yII. 修改XXX

2、1. Xxx2. Xxx3. .作者名yyyy-mm-dd2.00xxxx.x.x; y.y.yI. 修改XXX1. Xxx2. Xxx3. .作者名分发记录Copy No.Holders Name & Role 持有者和角色Issue Date 分发日期1yyyy-mm-dd2yyyy-mm-dd3yyyy-mm-dd4yyyy-mm-dd5yyyy-mm-dd目 录1 简介 21.1 目的 21.2 范围 22 总体概述 22.1 软件概述 22.1.1 项目介绍 22.1.2 产品环境介绍 22.2 软件功能 22.3 用户特征 22.4 假设和依赖关系 23 具体需求 23.1 功能需

3、求 23.1.1 功能需求1 23.2 性能需求 23.2.1 性能需求1 23.3 外部接口需求 23.3.1 用户接口 23.3.2 软件接口 23.3.3 硬件接口 23.3.4 通讯接口 24 总体设计约束 24.1 标准符合性 24.2 硬件约束 24.3 技术限制 25 软件质量特性 26 依赖关系 27 其他需求 27.1 数据库 27.2 操作 27.3 本地化 28 需求分级 29 待确定问题 210 附录 210.1 附录A 可行性分析结果 210.2 附录B 需求建模 210.2.1 数据流图 210.2.2 数据字典 2表目录Table1 *表 错误！未定义书签。表1

4、*表 错误！未定义书签。图目录Figure 1 *图 错误！未定义书签。XX 软件需求规格说明书关键词：能够体现文档描述内容主要方面的词汇。摘 要：缩略语清单：对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。 缩略语英文全名中文解释1 简介1.1 目的这部分要描述文档的目的。应该指明读者。说明本需求文档描述了哪个产品的软件需求。1.2 范围本节应描述文档所包括和不包括的内容。2 总体概述本节描述影响产品和产品需求的一般因素。由以下4个部分构成。 有一点需说明的是本节不描述具体的需求，只是使那些将要描述的具体需求更易于理解。2.1 软件概述2.1.1 项目介绍描述本软件需求所描

5、述的项目的背景。例如：本项目是一系列版本中的一个，或者是替代某个已经存在的系统，还是一个新的独立的项目。2.1.2 产品环境介绍描述的是本产品与其它产品或项目所组成的整体环境。1.如果本产品是独立的并完全自我包含，在此说明这一点。2.如果SRS定义的产品是更大的系统或项目的组件（此种情形经常发生），那么应： A. 描述此大系统或项目每个组件的功能，并且标识接口。 B. 确定本软件产品主要外部接口。（ 注意：在此部分并不进行这些接口的详细描述；对这些接口的详细描述在SRS的其它 部分提供。）C. 描述相关产品硬件和所使用的外部设备。（ 注意： 这只是概述性描述。）通过方块图来描述大系统或项目的主

6、要组件，互连性以及外部接口将是非常有帮助的。本部分不应提出一个具体的设计解决方案或对解决方案的具体设计约束（具体设计约束将在具体需求章节中描述）。本部分内容是产生设计约束的基础。2.2 软件功能概述软件的必须实现的和通过用户操作实现的主要功能。这里只需要进行简要描述（例如目录列表），详细描述在详细需求部分描述。对需求功能进行组织，以便于读者理解，并能指导后续的设计和测试。可以用图表来表示主要需求群组之间的关系，例如：高层的数据流图，面向对象的分析等。有时此部分所要求的功能概述可以从分配具体功能给此软件产品的更高层规格（如果存在的话）直接引用。本节不应描述具体需求。但本节内容是具体需求章节的基础

7、。2.3 用户特征列出对用户或系统操作者的要求，如：经验，能力，角色等。本节不应描述具体需求。但本节内容是具体需求章节的基础。2.4 假设和依赖关系列出可能影响SRS中需求的所有的假设因素（与已知事实相对而言），包括准备使用的第三方或商业组件，操作和开发环境的问题约束等。如果上述假设不正确、没有被告知或者改变了都将对项目产生影响。列出项目对外部条件的依赖，例如重用其他项目的模块等。如果在其他文档（例如项目计划或范围文档等）里已经描述了，在这里可以不用描述。3 具体需求在每一条需求描述中重复下列部分3.1 功能需求本子章节应描述软件产品的输入怎样被转换成输出。它描述了软件必须执行的基本动作。 对

8、每一类功能或有时对每一个单独的功能，必须描述输入、处理、输出方面的需求。这些通常以下面四个子段落来组织：3.1.1 功能需求1用需求编号加上简短词汇做为功能需求名，不要用“功能需求（1）”作为功能名，例如：R.INTF.CALC.001 计算表达式R.INTF.CALC.002 打印需求编号规则按照软件需求管理规程(REP01)进行1. 介绍逐条列出与本特性相关的功能需求。包括项目如何响应预期的错误输入，非法条件和无效输入。需求应该简明，完整，不含糊，可验证，必要的。 当需要的信息不确定的时候使用“待定”。2. 输入本子段落应包含下列内容：A. 对该功能所有输入数据的详细描述，包括： 输入来源

9、 数量 度量单位 时间要求 包含精度和容忍度的有效输入范围B. 在适当的地方提供的对接口规格或接口控制文档的参考。3. 处理本子段落应描述对输入数据所执行的所有操作和如何获得输出的过程。这包括下列规格：A. 输入数据的有效性检测。B. 操作的确切次序，包括各事件的时序。C. 对异常情况的回应，例如： 溢出 通信失败 错误处理D. 用于把系统输入转换到相应输出的任何方法（诸如方程式，数学算法，逻辑操作）。例如，这可能描述下列方面： 对工资单里代扣所得税的计算公式。 用于气象预报的气象模型。E. 对输出数据的有效性检测。4. 输出本子段落应包含：A. 对该功能所有输出数据的详细描述，这个描述包括：

10、 输出的到何处（如打印机，文件） 数量 度量单位 时序 包含精确度和容忍度的有效输出范围 对非法值的处理 错误消息B. 在适当的地方提供对接口规格或接口控制文档的参考。 此外，对那些需求集中在输入/输出行为的系统，SRS应描述所有重要的输入/输出行为及输入输出对的次序。对一个需要记忆其行为以根据输入和过去的行为进行反应的系统，输入输出对的次序是要求的；这种功能行为就类似于有限状态机。3.2 性能需求如果有性能方面的需求，在这里列出并解释他们的原理。以帮助开发者理解意图以做出正确的设计选择。在实时系统中的时序关系。保证需求尽可能的详细而精确。3.2.1 性能需求1 本子章节应从整体上描述静态和动

11、态的量化的对软件（或人与软件交互）的需求。静态的量化需求可能包括：A. 支持的终端数目。B. 支持的同时使用的用户数目。C.处理的文件和记录的数目。D.表和文件的大小。动态的量化需求可能包括:A. 在正常和峰值工作量条件下特定时间段（如一小时）B. 处理的事务和任务的数目以及数据量。所有的这些需求应以可测量的术语进行描述，例如所有的操作应在1秒内被处理完成，而不是描述成操作员不必等待操作的完成。注意： 用于一个具体功能的量化限制通常在该功能的处理子章节中描述。3.3 外部接口需求3.3.1 用户接口详细描述系统与用户之间的接口这应描述下述内容：A. 对每种人机界面，软件所必须支持的特性。例如，

12、如果系统用户通过一个显示终端进行操作，那么应包含下述内容：要求的屏幕格式页面规划及报告或菜单的内容输入和输出的相关时序一些组合功能键的用法B. 与系统用户接口使用相关的所有方面。这可能只是一个简单的关于系统怎样展示给用户而该做什么和不该做什么的列表。例如提供关于长或短错误消息选项。和所有其它需求一样，这些需求也应能被检验，例如，四级打字员经一小时的培训后能在Z分钟内完成功能X，而不是一个打字员能完成功能X。3.3.2 软件接口详细描述与其他系统 /模块 /项目之间的接口在此应描述如何使用其它（必需的）软件产品（例如，数据管理系统，操作系统，或算法工具包），以及与其它应用系统的接口（例如，协议处

13、理系统和数据库管理系统之间的接口）。对每个必需的软件产品，应提供下列信息：A. 名字B. 助记符C. 版本号D. 来源对每个接口，本部分应：A . 讨论与本软件产品相关的接口软件的目的。B. 按消息/函数内容和格式定义接口。如果接口已在其它文档中很清楚地描述，就没有必要在这儿进行详细描述，但需说明应参考的文档。3.3.3 硬件接口详细描述与硬件的接口在此描述软件产品和系统硬件组件之间接口的逻辑特征，也包括支持哪些设备、怎样支持这些设备和协议等。 按软/硬件协议内容和格式定义接口。如果接口已在其它文档中很清楚地描述，就没有必要在这儿进行详细描述，但需说明应参考的文档。3.3.4 通讯接口详细描述

14、通讯接口，如本地网络协议等。按消息/函数内容和格式定义接口。如果接口已在其它文档中很清楚地描述，就没有必要在这儿进行详细描述，但需说明应参考的文档。4 总体设计约束描述可能限制开发人员选择的事项。 4.1 标准符合性本节详细说明需求所采用的标准或规范的来源。如果项目采用了国际标准，应该说明国际标准及项目与标准的偏离情况。4.2 硬件约束本节包括软件在不同的硬件平台运行的需求，如时间相关的约束，内存方面的约束等。4.3 技术限制本节包括对使用特定技术的限制，包括接口，数据库，并行操作，通讯协议，设计约定，编程规范等。5 软件质量特性详细说明项目任何其他的质量特性。该特性对客户和开发者都非常重要。

15、考虑的方面包括：适应性，可用性，正确性，灵活性，交互工作能力，可维护性，可移植性，可靠性，可重用性，鲁棒性，可测试性等。定量的详细描述这些特性，尽可能的可验证。对不同属性之间的重要性加以阐述，如：易用性比易学性更重要。每一个属性单独使用一个小节描述，可根据需要进行增减，如增加可维护性小节等。6 依赖关系解释每一条需求的内部和外部依赖关系。7 其他需求使用适当的章节，详细说明任何其他客户需求，包括数据库，编码需求，错误处理，测试需求等。下面仅列出了少量样例，你可以删除和增加项目。7.1 数据库详细说明项目相关的数据库方面的需求。7.2 操作详细说明用户通常的和特殊的操作需求。7.3 本地化描述支

16、持多语种的需求。8 需求分级需求ID 需求名称需求分级重要性分类如下：A. 必须的 绝对基本的特性；如果不包含，产品就会被取消。B. 重要的 不是基本的特性，但这些特性会影响产品的生存能力。C. 最好有的 期望的特性；但省略一个或多个这样的特性不会影响产品的生存能力。9 待确定问题需求ID问题描述影响(H/M/L)风险责任人解决日期状态(Open/Close)10 附录10.1 附录A 可行性分析结果描述对分配需求的可行性分析结果。10.2 附录B 需求建模 10.2.1 数据流图1. 顶层数据流图在这里画出顶层数据流图2. 0层数据流图在这里画出0层数据流图3. 1层数据流图在这里画出1层数

17、据流图10.2.2 数据字典1. 数据流说明1） 数据流1名称与数据流图中的名称一致，采用数据描述符号说明数据流的内容2） 数据流2名称与数据流图中的名称一致，采用数据描述符号说明数据流的内容2. 数据存储说明1） 数据存储1名称与数据流图中的名称一致，采用数据描述符号说明数据流的内容，另外还需描述数据排列方式2） 数据存储2名称与数据流图中的名称一致，采用数据描述符号说明数据流的内容，另外还需描述数据排列方式3. 加工说明1） 加工1名称采用自然语言，判断表/判断树，伪码的形式描述对数据流进行处理的过程2） 加工2名称采用自然语言，判断表/判断树，伪码的形式描述对数据流进行处理的过程 参考资

18、料清单：请罗列本文档所参考的有关参考文献和相关文档，格式如下：作者书名（或杂志、文献、文档）出版社（或期号、卷号、公司文档编号）出版日期+起止页码例如：1 D. B. Leeson, “A Simple Model of Feedback Oscillator Noise Spectrum,” Proc. IEEE, pp329-330, February 1966 （英文文章格式）2 D. Wolaver, Phase-Locked Loop Circuit Design, Prentice Hall, New Jersey,1991 （英文书籍格式）3 王阳元，奚雪梅等，“薄膜SOI/CMOS SPICE电路模拟”，电子学报，vol.22，No.5，1994 （中文文章格式）4 郑筠，MOS存储系统及技术，科学出版社，1990 （中文书籍格式）5 XXX，SDXXX用户手册 V1.1，基础部文档室，2002/3/12