需求规格说明书-项目名称(模板)

软件需求规格说明书_项目名称软件需求规格说明书产品发布标识本模板用于 软件需求开发管理流程 中 软件需求规格说明书的编写。其中包括用方括号括起来并以蓝色斜体（样式=infoblue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=正文）。一般说来，一个产品需求对应一份软件需求，在软件需求中也可以分成多个分册。此时本文档可命名为“软件需求规格说明书_产品标识_XXX分册”。软件需求规格说明书的定义：详细描述系统或者子系统的范围、边界、用户界面、外部行为等。此文档用来让读者了解系统或者子系统的外部黑盒概念，并指导高层设计、测试案例以及后续开发，以及作为系统测试的依据，指导系统测试案例的开发。当某一章/节没有内容时，必须注明N/A，同时标注理由。例如：本章/节内容无需考虑。特别说明：当某章/节内容参见其它文档时，不能注明N/A，而应该写明参见某文档的具体章节。文档版本号：文档编号：文档密级：保密归属部门/项目：产品名：子系统名：编写人：编写日期：kkfun技术（深圳）有限公司 版权所有内部资料 注意保密修订记录：修订版本号修订人修订日期修订描述V1.0AXXX2004-5-8创建初稿V1.0BBBB2006-4-21根据适应性修订目 录1 简介61.1 目的61.2 范围61.3 预期的读者和阅读建议61.4 参考资料71.4.1 包含文档71.4.2 相关文档71.5 定义、首字母缩写词和缩略语72 整体说明82.1 功能简介82.2 运行环境82.3 假设和依赖82.4 外部约束93 功能性需求93.1 特性集名称一93.1.1 特性一 功能划分.1 功能点1.2 功能点2 SFR：XXX功能性需求 (二选一).1 角色描述.2 用例概述.3 前置条件.4 SFR.：场景1.4.1 前置条件.4.2 执行步骤.4.3 后置条件.5 SFR.：场景2.5.1 前置条件.5.2 执行步骤.5.3 后置条件.6 SFR.：场景3.6.1 前置条件.6.2 执行步骤.6.3 后置条件.7 界面示意图 SFR1：用户注册.1 角色描述.2 用例概述.3 前置条件.4 SFR2.1：正常流.4.1 前置条件.4.2 执行步骤.4.3 后置条件.5 SFR2.2：异常流1.5.1 前置条件.5.2 执行步骤.5.3 后置条件.6 SFR2.3：异常流2.6.1 前置条件.6.2 执行步骤.6.3 后置条件.7 界面示意图 SFR：XXX报表 (二选一).1.1 指标说明.1.2 维度说明.1.3 输入条件.1.4 样例说明.1.5 包含内容.1.6 适用范围.1.7 报表标题.1.8 排序方式.1.9 统计周期.1.10 183.1.2 特性二183.2 特性集名称二184 界面及接口194.1 总体界面效果194.2 总体接口描述195 非功能性需求195.1 获取来源195.2 适用的标准195.3 准确性205.4 可用性205.4.1 SNR：可用性需求一205.5 安全性205.5.1 系统安全:215.5.2 操作安全:215.5.3 操作监控:215.5.4 数据安全:215.5.5 维护工具:215.5.6 数据监控:215.5.7 算法安全:215.5.8 产品安全标准225.6 可靠性225.6.1 SNR：可靠性需求一235.7 性能235.7.1 SNR：性能需求一245.8 可维护性255.8.1 SNR：可维护性需求一255.9 可部署性（可选）256 文档需求256.1 用户手册256.2 联机帮助256.3 安装指南、配置文件、自述文件257 附录261 简介本章应提供整个系统或者子系统的概述。它应包括此系统或者子系统的目的、范围、定义、首字母缩写词、缩略语、参考资料以及依赖和假设。注：软件需求规格说明书完整地记录本系统或者子系统的需求。1.1 目的本节应描述此文档的目的。本说明书是整个软件开发的依据，它对以后阶段的工作起指导作用。本文也是项目完成后系统验收的依据。同时本说明书还是用户手册和测试计划的编写依据。1.2 范围简要说明此产品需求规格说明书文档的范围、它的相关产品，以及受到此文档影响的任何其他事物。本节应提供此 软件需求规格说明书 所涉及的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里1.3 预期的读者和阅读建议本节应列举此 软件需求规格说明书 所针对的不同读者，预期读者包括但不限于：产品经理、设计人员、开发人员和测试人员，也可供客户、第三方产品的相关人员阅读。本文档组织方式以及阅读建议：第一章 简介；对文档目的、范围等进行说明，并说明文档的组织方式；第二章 整体说明；对软件进行整体说明；有助于了解软件的整体概貌。第三章 功能性需求，对功能性需求进行详细说明，包括用例的详细说明，以指导后续的架构设计、软件设计工作，并对测试工作提供参考；设计人员和开发人员可以从这个部分得到功能性的需求描述，并据此进行设计、开发工作；测试人员可以据此进行测试案例的设计和测试计划的制定。第四章 界面及接口，描述界面及接口方面的需求；设计人员和开发人员可以从这个部分得到功能特性的界面组织形式，从而更好的理解需求并设计和实现需求。第五章 非功能性需求，对软件的非功能性需求进行描述，以指导后续的架构设计、软件设计工作，并对测试工作提供参考；设计人员和开发人员在设计、开发过程中应当包含对这些需求的设计、开发工作；测试人员在测试过程中应当包含对这些需求的测试案例及验证；第六章 文档需求，描述文档需求；第七章 附录1.4 参考资料此小节应完整地列出 软件需求规格说明书 中所参考的资料或其它资源。这可能包括但并不限于包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可以获取这些参考资料的来源。这些信息可以通过参考附录或其他文档来提供。同时，文档中说明为引用、参考的文档也应该在这里列出。参考文档需要按包含、相关的关系分别在下面的小节中列出。1.4.1 包含文档当本文有包含文档时，需要提供相关的包含文档列表。包含文档：作为本软件需求规格说明书的一部分，是不可分割的组成部分，是读者阅读本文档时必须同时也阅读的文档。如当本软件需求规格说明书非常复杂而有分册时，则分册就属于本文档的包含文档。通常情况下，软件需求规格说明书没有包含文档1.4.2 相关文档当本文有相关文档时，需要提供相关文档列表。 相关文档：具有关联关系的文档。读者在阅读本软件需求规格说明书时如果有必要可以参考阅读的文档。如相关产品、子系统或者模块的产品需求、软件需求、用户界面风格指导，相关方请求等相关文档。1.5 定义、首字母缩写词和缩略语此小节应提供正确理解此 软件需求规格说明书 所需的全部术语的定义、首字母缩写词和缩略语，以便读者可以正确地解释软件需求说明。可以通过参考项目词汇表来获取这些信息。缩略语/术语全 称说 明2 整体说明本节应概述正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖，说明影响系统及其需求的一般因素。本节并不列出具体的需求，而只是提供在第3节中详述的各种需求的背景，以使这些需求便于理解。所包括的内容有： 产品总体效果假设与依赖关系2.1 功能简介本节应对产品的基本功能做简介的介绍，包括以下内容：1.本系统的开发意图、应用目标及作用范围。2概略介绍系统所具有的主要功能。可以用列表的方法给出，也可以用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图等。3说明本系统与其他相关系统的关系，是独立系统还是一个较大系统的组成部分。可以用表示外部接口和数据流的系统高层次图，或者方框图说明。注：可以引用或者参考产品需求说明书中相应章节的内容2.2 运行环境1.硬件环境：如果客户对于硬件有特殊要求，在此必须按照客户的要求把硬件环境描述出来；如果客户对于硬件没有特别指定，则在此处应详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。2.软件环境：如果客户对于软件环境有特别要求，则在此处应按照客户的要求把软件环境描述出来；如果客户对于软件环境没有特别要求，则在此处应详细列出本软件运行时所必须的软件环境，例如操作系统、网络软件、数据库系统以及其它特殊软件要求。2.3 假设和依赖列举出在对软件需求规格说明中影响需求陈述的假设因素。如果这些假设不正确、不一致或被更改，就会使项目受到影响。本节列举的假设和依赖可能包括但并不限于以下内容：确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了，那么在此就可以参考其它文档。如果本系统的某些功能特性必须依赖于其他系统的功能或者数据，这依赖于与相关方达成一致共识，包括与相关方达成接口契约以及法律方面的协议等， 对于一些有争议或者需要裁剪或者简化的软件功能特性，已经获得用户的认可。(其他假设和依赖)注：当产品需求与软件需求一一对应时，可以直接参考和引用产品需求规格说明书“假设与依赖”部分章节的内容；但如果产品需求分解成多个软件需求时，那么软件需求应根据实际情况把该部分的假设和依赖进行更细致的描述。2.4 外部约束本节应说明本软件在实现时所必须满足的条件和所受的限制，并给出相应的原因。条件与限制包括但并不限于（主要指软件环境、硬件环境，市场环境以及政策法规）：必须使用或者避免的特定技术、工具、编程语言和数据库；企业策略、政府法规或工业标准；例如SOX对于MISC的限制硬件限制，例如定时需求或存储器限制；经费限制、开发期限；项目对外部因素存在的依赖。例如其它项目开发的软件。等等3 功能性需求列出产品的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。此节为设计的系统功能性需求, 一般以用例结合自然语言来表达。此节通常按特性来组织，但也可能会有其他适用的组织方式。这一节应包含所有的产品需求，其详细程度应使架构设计人员和软件需求设计人员能够设计出可以满足这些需求的系统，包括可选流程和异常流程，对具体语义做约束。3.1 特性集名称一此节可把产品需求说明书章节对应的特性集复制到此处。在此处应描述该特性集有哪些特性。3.1.1 特性一此节可把产品需求说明书章节对应的特性集复制到此处 功能划分此节应从使用用户的角度描述将特性划分成相应的功能用例，并给出总体功能结构。对于复杂的系统，还需要对主要子系统中的基本功能进行描述。描述方法包括结构图、流程图或对象图或者表格等等。但应注意此处划分成的部分并不对应于最终程序实现时的不同功能模块。本节应包括对应功能特征各部分的内容，包括下列内容：此功能对应的用例图以及相关的用例说明；此处可以用用例图来描述：关于用例的编号规则：SFR。对应用例的编号、简要说明。此处如用表格来描述，建议采用以下表格：用例编号用例名称简要说明.1 功能点1此节应对系统的基本功能进行描述，并描述该功能点与内部模块、外部系统或外部模块之间的关系a、功能描述b、该功能与内部模块的关系c、该功能与外部系统或模块的关系.2 功能点2此节应对系统的基本功能进行描述，并描述该功能点与内部模块、外部系统或外部模块之间的关系a、功能描述b、该功能与内部模块的关系c、该功能与外部系统或模块的关系 SFR：XXX功能性需求 (二选一)如果是报表部分功能特征开发，可不选择本节模板。此处可用图例简单描述用例，说明该用例的使用角色，业务实体，以及相关的业务实体等.1 角色描述描述角色相关的事项，例如角色的名称，角色的职责等；角色：谁使用此功能，或者在此功能之外与该功能进行交互的人或事务。角色并不单纯指某个人，也可能包括某个其他功能或者构件.2 用例概述此处描述用例的相应事项，例如相关的业务实体等。.3 前置条件本节应描述本用例发生的前置条件，包括前置用例，输入条件或者进入用例的约束.4 SFR.：场景1在本节应描述对应用例的正常流，即满足该用例执行时所有条件时的正常执行过程。.4.1 前置条件在此处应场景1发生的前置条件。.4.2 执行步骤在此处应描述用例正常执行，即满足该用例执行时所有条件时的正常执行过程以及步骤说明.4.3 后置条件此处应描述在正常流程执行完毕以后的结果，例如输出，或者是触发下一个用例。.5 SFR.：场景.5.1 前置条件在此处应描述场景2发生的前置条件。.5.2 执行步骤在此处应描述用例执行时，由于某种情况产生的分支流，异常事件也是属于一种分支流，在此处可以用时序图/活动图把该分支流发生的逻辑描述出来。.5.3 后置条件在此处应描述当用例执行时产生的分支流输出的结果，例如输出结果，或者是否启动另外一个用例。.6 SFR.：场景.6.1 前置条件在此处应描述场景3发生的前置条件。.6.2 执行步骤在此处应描述用例执行时，由于某种情况产生的分支流，异常事件也是属于一种分支流，在此处可以用活动图把该分支流发生的逻辑描述出来。.6.3 后置条件在此处应描述当用例执行时产生的分支流输出的结果，例如输出结果，或者是否启动另外一个用例。.7 界面示意图在本节应出具用例相关的界面示意图，以指导后续的设计活动开发 SFR：XXX报表 (二选一)本节主要是针对于面向BI/Report实现的功能性需求描述。本节应包括对应功能特征各部分的内容，包括下列内容：功能描述：描述该功能的作用，以及为客户带来的价值。.1.1 指标说明此处应描述该报表有哪些指标。至于指标的定义和算法，可以参考指标相关的技术文档。.1.2 维度说明此处应描述该报表展现的维度.1.3 输入条件此处应描述查询报表时的输入条件，如有必要，可以提供查询界面Demo。.1.4 样例说明注：对于面向BI/Report的功能来说，样例说明即其界面示意。可以比较准确的描述分析或者报表的界面，以对后续的开发活动做出指导。指标1指标2指标.1.5 包含内容此处应说明报表的数据包含的数据内容，例如：CS：包含全网SP以及本地接入全网SP的短信业务汇总数据。PS：包含全网SP以及本省/直辖市的全网本地接入SP、本地SP的短信业务汇总数据。.1.6 适用范围此处应说明报表的适用范围，是适用于中央，还是各省市，以及全网等.1.7 报表标题此处应说明报表的标题，如果有分集团和省报表，应分别定义报表的名称，例如：CS：短信业务各SP分地区分用户品牌基础报表PS：短信业务各SP分地区分用户品牌基础报表（2空格）（省份）.1.8 排序方式此处应说明报表内容的排序方式，如果有多级排序，应在此说明排序的顺序，例如：排序顺序排序维度排序方式1SP服务代码升序排列2企业代码升序排列3地区代码升序排列.1.9 统计周期此处应说明报表报表的统计周期，例如：本报表的统计周期为：日，周，月.1.10 此处如果有其他需要特别说明，可在此增加章节说明。3.1.2 特性二3.2 特性集名称二4 界面及接口4.1 总体界面效果本小节概要描述产品特性包含的的用户界面效果，要求且仅要求提供总体性的说明。4.2 总体接口描述本小节列举产品外部接口，要求且仅要求能说明各接口关联到的相关产品实体间的关系。5 非功能性需求如健壮性、安全保密性、复用性、灵活性、易用性、可维护性、可移植性等。指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植优于有效性。健壮性：说明软件在容错能力，故障处理能力上需要达到的目标，保证系统稳定可靠；安全保密性：包括用户身份确认或授权方面的需求，保密性策略，系统所创建或使用的数据的保护等等；复用性：说明本项目是否可以复用已有软件、是否可为其它系统复用；灵活性：说明在运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。5.1 获取来源列举非功能性需求的获取来源。例如：1） 客户提出的，并已经与其他相关方达成一致的非功能性需求；2） 已经存在的特定类型产品所能参照的业界标准；3） 采用相应的测试工具测试同类产品或原型产品所获取的数据；4） 同类产品已经存在的参考基准。5.2 适用的标准列出产品必须符合的所有标准。其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix 等）以及质量和安全标准（UL、ISO、CMM）。5.3 准确性此节应描述对系统准确性的要求。例如数据准确性5.4 可用性此节应包括所有影响可用性的需求，参考架构设计说明书相关章节。例如，指出普通用户和高级用户要高效地执行特定操作所需的培训时间指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可用性需求指出在符合公认的可用性标准（如IBM的CUA标准和Microsoft的GUI标准）方面的需求5.4.1 SNR：可用性需求一在此给出需求说明。例子：SNR1:系统必须提供良好的用户界面以方便用户订购和使用业务。一个阅读过FAQ或观看过使用演示的用户能够在10分钟内完成一次用户登陆-浏览服务信息-定购服务操作。SNR2:同时要求能够对所有系统级和应用级的错误，包括用户的输入错误都能有友好的出错提示页面。参见附录A提示语定义。5.5 安全性本节应详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。 此节应列出将提高所构建系统的安全性的所有需求。具体的要求参见产品安全性需求可维护性遵循此方案的策略。建立公司级别的产品安全标准,针对各产品的特性确定安全级别.5.5.1 系统安全:根据各产品安全级别的设定,各产品需要从界面到接口到内核到数据层层设防,以便保证系统不可能被轻易入侵,关键数据不可能被轻易破坏和修改.5.5.2 操作安全:根据各产品安全级别的设定,各产品需要建立产品内的审计系统,做到所有高危操作均有据可循,所记录的信息满足内部审计和问题排查的要求.5.5.3 操作监控:根据各产品安全级别的设定,各产品需要有相关的监测工具对系统的非正常操作进行监查,一旦发现异常操作及时告警.5.5.4 数据安全:根据各产品安全级别的设定,各产品对核心数据需要有相关的保护措施,做到非正常操作无法破坏和非法修改, 并发现有异动可及时告警.5.5.5 维护工具:根据各产品安全级别的设定,将有操作风险的维护工作均全部工具化和界面化,隔离维护者直接接触系统.5.5.6 数据监控:各产品需要建立相应的业务数据变动异常的标准,开发相关的工具对以上业务数据异常进行监控和分析,以便及时发现SP利用MISC系统漏洞或其他手段违规.5.5.7 算法安全:产品线需要根据各产品的安全级别设定,提高内部管理方法及手段,严格控制关键代码和关键算法,以便防止关键算法和业务流程外泄.针对安全问题的处理,产品线需要建立相关的处理机制并配置相关的人员,以便跟进和产品有关的安全问题的后续处理和问题分析.针对各产品的安全标准和安全规划,需要在产品设计阶段在控制范围内进行专项讨论,并会合相关部门一起确定相关方案和规划,并安排产品经理制定产品的长期安全目标和短期目标并跟踪加以实施.5.5.8 产品安全标准设计 相关级别为(1-5),根据安全性的要求决定在产品中接口安全,核心逻辑安全,数据安全,审计手段,维护工具,防攻击手段,安全分析手段,产品部署建议方案中的投入力度.开发 相关级别为(1-3),根据安全性的要求决定关键算法和关键业务逻辑的相关代码的开发范围及代码扩散范围,并根据相关级别对开发中采用的算法和业务逻辑进行审核检查.测试 相关级别为(1-3),根据安全性的要求决定安全相关PATCH的测试范围和告知人员.并根据相关级别对产品进行相关的安全性测试.本节如包含多项可维护性需求，可分多小节描述。5.6 可靠性对系统可靠性的需求应在此处说明，详尽陈述在软件使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。本节可参考架构设计说明书相关章节。以下是一些建议：可用性指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。平均故障间隔时间 (MTBF)通常表示为小时数，但也可表示为天数、月数或年数。平均修复时间 (MTTR)系统在发生故障后可以暂停运行的时间。精确度指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。最高错误或缺陷率通常表示为每千行代码的错误数目 (bugs/KLOC) 或每个功能点的错误数目 (bugs/function-point)。错误或缺陷率按照小错误、大错误和严重错误来分类。需求中必须对“严重”错误进行界定，例如：数据完全丢失或完全不能使用系统的某部分功能。5.6.1 SNR：可靠性需求一需求说明。例子：可靠性指系统在规定的时间内及规定的环境条件下，完成规定功能的能力。SNR6:参照现网WAP Portal的运行情况。要求在连续的7天内，在网络环境正常、与系统相连的MISC，ISMG，SSO，WTBS，SP平台功能正常的情况下，在系统的额定处理能力之内（额定处理能力参考下文的计算方法），系统发生故障后，从开始处理到系统恢复的时间不能超过30分钟（按一次计算，超过30min的概率低于20，从系统正式商用开始统计,此处人员到场的延误，及分析和处理问题的时间）。SNR7:系统发生异常到系统发出告警的时间的时延不能超过3分钟。SNR8:健壮性要求：当用户输入非法数据时，不能引起系统的运行故障，要保证系统功能95可用；SNR9:要求在HP RP5470（每台配置4*550Mhz 4GB内存），数据库服务器配置为HP RP5470（每台配置4*550Mhz 4GB内存）条件下，30天内，当cpu的使用率低于60，内存使用率低于70，且系统处理能力不高于额定的处理能力的情况下，系统的外部环境出现问题，如网络异常、与系统相连的MISC，ISMG，SSO平台等外部系统发生故障，并在20分钟内全部恢复正常运行后，M-Zone Portal系统功能在10分钟内自动恢复次数不能少于总故障次数的80。5.7 性能此节应概述系统的性能特征，参考系统需求说明书相关章节。其中需包括具体的响应时间。如果可行，按名称引用相关用例。对事务的响应时间（平均、最长）吞吐量，例如每秒处理的事务数容量，例如系统可以容纳的客户或事务数降级模式（当系统以某种形式降级时可接受的运行模式）资源利用情况，如内存、磁盘、通信等应尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述5.7.1 SNR：性能需求一【阐述不同的软件功能对系统性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。这些性能需求例如：数据精确度：根据实际情况，确定软件最终输出数据(包括传输中)的数据精确度。时间特性：说明开发的软件在响应时间、更新处理时间、数据转换与传输时间、运行时间等方面所需达到的时间特性。用户数：最大用户数，并发用户数，以及相互合作的用户数或者所支持的操作；容量需求，例如存储器和磁盘容量的需求或者存储在数据库中表的最大行数】。例子：SNR10:处理能力在对性能做要求时，我们参考WWW P