软件需求规格说明书

软件需求规格说明书模板

版本：<1.0>文档编号：0304密级：秘密编写：编写日期：年月日审核：审核日期年月日批准：批准日期：年月日Copyright@Egao,Allrightreserved修订记录版本章节名称修订内容修订日期修订人批准人1.0第一版发布用户需求确认书重写用户确认承诺内容2.3标题有用户特点改为用户类和特性写作提醒修改2.4原2.4一般约束改为2.4运营环境，2.5设计和实现上的限制，并修改相应写作提醒3.2.1标题用户接口改为用户界面，并修改相应写作提醒3.4删除原3.4设计约束3.4.2修改原3.5.2安全性的写作提醒3.4.5删除原3.5.5警告3.3.3增长非功能需求标题。调整原3.3.3性能需求，3.4属性，4其他需求为非功能需求之下级章节。3.3.3.53.3.33.3.4增长3.3.3.5软件质量属性3.3.3业务规则3.3.4用户文档3.5其他需求并为3.3.5，修改写作提醒4删除原5附录写作提醒。增长4.1附录A词汇表，4.2附录B分析模型，4.3附录C待拟定问题列表及相关写作提醒。<项目名称>软件需求规格说明书

版本：<>文档编号：密级：秘密编写：编写日期：年月日审核：审核日期年月日批准：批准日期：年月日Copyright@RongHui,Allrightreserved修订记录版本章节名称修订内容修订日期修订人批准人目录1 引言 11.1 编写目的 11.2 范围 11.3 定义 11.4 参考资料 12 项目概述 12.1 产品描述 12.2 产品功能 22.3 用户特点 22.4 运营环境 22.5 设计和实现上的限制 22.6 假设和依据 33 具体需求 33.1 功能需求 33.1.1 功能需求1 33.1.2 功能需求2 43.1.3 功能需求3 43.2 外部接口需求 43.2.1 用户接口 43.2.2 硬件接口 43.2.3 软件接口 53.2.4 通信接口 53.3 非功能性需求 53.3.1 性能需求 53.3.2 属性 53.3.3 业务规则 63.3.4 用户文档 63.3.5 其他需求 64 附录 74.1 附录A：词汇表 74.2 附录B：分析模型 84.3 附录C：待拟定问题的列表 8用户需求确认书本《软件需求规格说明书》建立在双方对需求的共同理解基础之上，我批准后续的开发工作根据该《软件需求规格说明书》开展。假如需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。用户职务用户署名签订日期引言编写目的说明编写这份软件需求说明书的目的，指出预期的读者范围。范围说明：待开发的软件系统的名称；说明软件将干什么，假如需要的话，还要说明软件产品不干什么；描述所说明的软件的应用。应当：尽也许精确地描述所有相关的利益、目的、以及最终目的。假如有一个较高层次的说明存在，则应当使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。定义列出本文献中用到的专门术语的定义和缩写词的原词组。参考资料列出要用到的参考资料，如：本项目的经核准的计划任务书或协议、上级机关的批文；属于本项目的其他已发表的文献；本文献中各处引用的文献、资料，涉及所要用到的软件开发标准。列出这些文献的标题、文献编号、发表日期和出版单位，说明可以得到这些文献资料的来源。项目概述产品描述叙述该项软件开发的意图、应用目的、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。假如本软件产品是一项独立的软件，并且所有内容自含，则说明这一点。假如所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。产品功能本条是为将要完毕的软件功能提供一个摘要。例如，对于一个记帐程序来说，需求说明可以用这部分来描述：客房帐目维护、客房财务报表和发票制作，而不必把功能所规定的大量的细节描写出来。有时，假如存在较高层次的规格说明时，则功能摘要可从中取得，这个较高层次的规格说明为软件产品分派了特殊的功能，为了清楚起见，请注意：编制功能的一种方法是制作功能表，以便客房或者第一次读这个文献的人都可以理解；用方框图来表达不同的功能和它们的关系也是有帮助的。但应牢记，这样的图不是产品设计时所需求的，而只是一种有效的解释性的工具。用户特点拟定你觉得也许使用该产品的不同用户类并描述它们相关的特性。有一些需求也许只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开运营环境描述了软件的运营环境，涉及硬件平台、操作系统和版本，尚有其它的软件组件或与其共存的应用程序设计和实现上的限制拟定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。也许的限制涉及如下内容：•必须使用或者避免的特定技术、工具、编程语言和数据库。•所规定的开发规范或标准（例如，假如由客户的公司负责软件维护，就必须定义转包者所使用的设计符号表达和编码标准。•公司策略、政府法规或工业标准。•硬件限制，例如定期需求或存储器限制。•数据格式标准。（报表格式，数据命名等）•与其他应用间的接口；•并行操作；•审查功能；•控制功能；•通信协议；•应用的临界点；•安全和保密方面的考虑。假设和依据本条列出影响需求说明中陈述的需求的每一个因素。这些因此不是软件的设计约束，但是它们的改变也许影响到需求说明中的需求。例如：假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不也许使用的，于是，需求说明就要进行相应的改变。具体需求功能需求功能需求1对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。由四个部分组成：引言描述的是功能要达成的目的、所彩的方法和技术，还应清楚说明功能意图的由来和背景。输入具体描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（涉及精度和公差）；操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，规定操作员进行格式调整；指明引用接口说明或接口控制文献的参考资料。加工定义输入数据、中间参数，以获得预期输出结果的所有操作。它涉及如下的说明：输入数据的有效性检查；操作的顺序，涉及事件的时间设定；响应，例如，溢出、通信故障、错误解决等；受操作影响的参数；降级运营的规定；用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）；输出数据的有效性检查。输出具体描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（涉及精度和公差）、非法值的解决、犯错信息；有关接口说明或接口控制文献的参考资料。此外，对着重于输入输出行为的系统来说，需求说明应指定所有故意义的输入、输出对及其序列。当一个系统规定记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态作出响应。也就是说，这种情况如同有限状态机。功能需求2．．．．．．功能需求3．．．．．．外部接口需求用户接口陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特性。以下是也许要涉及的一些特性：•将要采用的图形用户界面（GUI）标准或产品系列的风格。•报表或菜单的页面打印格式和内容；•输入输出的相对时间；•屏幕布局或解决方案的限制。•将出现在每个屏幕的标准按钮、功能或导航链接（例如一个帮助按钮）。•快捷键。•错误信息显示标准。对于用户界面的细节，例如特定对话框的布局，应当写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。硬件接口要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还也许涉及如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。软件接口在此要指定需使用的其他软件产品（例如，数据管理系统、操作系统或数学软件包），以及同其他应用系统之间的接口。对每一个所需的软件产品，要提供如下内容：名字；助记符；规格说明号；版本号；来源。对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，但不必具体描述任何已有完整文献的接口，只要引用定义该接口的文献即可。通信接口指定各种通信接口。例如，局部网络的协议等等。非功能性需求性能需求从整体来说，本条应具体说明软件、或人与软件交互的静态或动态数值需求。静态数值需求也许涉及：支持的终端数；支持并行操作的用户数；解决的文卷和记录数；表和文卷的大小。动态数值需求也许涉及：欲解决的事务和任务的数量，以及在正常情况下和峰值工作条件下一定期间周期中解决的数据总量。所有这些需求都必须用可以度量的术语来叙述。例如，95％的事务必须在小于1s时间内解决完，不然，操作员将不等待解决的完毕。属性在软件的需求之中有若干个属性，以下指出其中的几个（注意：对这些决不应理解为是一个完整的清单）。可用性可以指定一些因素，如检查点、恢复和再启动等，以保证整个系统有一个拟定的可用性级别。安全性详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。你也许更喜欢通过称为完整性的质量属性来阐述这些需求，完整性将在第11章介绍。一个软件系统的安全需求的范例如下：“每个用户在第一次登录后，必须更改他的最初登录密码。最初的登录密码不能重用。”可维护性规定若干需求以保证软件是可维护的。例如：软件模块所需要的特殊的耦合矩阵；为微型装置指定特殊的数据＼程序分割规定。可转移＼转换性规定把软件从一种环境移植到另一种环境所规定的用户程序，用户接口兼容方面的约束等等。软件质量属性详尽陈述与客户或开发人员至关重要的其它产品质量特性。这些特性必须是拟定、定量的并在也许时是可验证的。至少应指明不同属性的相对侧重点，例如易用限度优于易学限度，或者可移植性优于有效性。业务规则列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些自身不是功能需求，但它们可以暗示某些功能需求执行这些规则。一个业务规则的范例如下：“只有持有管理员密码的用户才干执行$100.00或更大额的退款操作。”用户文档列举出将与软件一同发行的用户文档部分，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。其他需求定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。你还可以增长有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。。在模板中加入与你的项目相关的新部分。假如你不需要增长其它需求，就省略这一部分。如：数据库本项对作为产品的一部分进行开发的数据库规定一些需求，它们也许涉及：在功能需求中标记的信息类别；使用的频率；存取能力；数据元素和文卷描述符；数据元素、记录和文卷的关系；静态和动态的组织；数据保存规定。注：假如使用一个现有的数据库包，这个包应在“软件接口”中命名，并在那里具体说明其用法。操作这里说明用户规定的常规的和特殊的操作。在用户组织之中各种方式的操作。例如，用户初始化操作；交互作用操作的周期和无人操作的周期；数据解决运营功能；后援和恢复操作。注：这里的内容有时是用户接口的一部分。场合适应性需求这里涉及：对给定场合或相关任务或操作方式的任何数据或初始化顺序的需求