需求规格说明书项目名称模板可编辑.docx
- 文档编号:6629251
- 上传时间:2023-05-10
- 格式:DOCX
- 页数:15
- 大小:24.98KB
需求规格说明书项目名称模板可编辑.docx
《需求规格说明书项目名称模板可编辑.docx》由会员分享,可在线阅读,更多相关《需求规格说明书项目名称模板可编辑.docx(15页珍藏版)》请在冰点文库上搜索。
需求规格说明书项目名称模板可编辑
需求规格说明书项目名称模板(可编辑)
精选资料软件需求规格说明书产品发布标识本模板用于软件需求开发管理流程中软件需求规格说明书的编写。
其中包括用方括号括起来并以蓝色斜体(样式=infoblue)显示的文本它们用于向作者提供指导在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式(样式=正文)。
一般说来一个产品需求对应一份软件需求在软件需求中也可以分成多个分册。
此时本文档可命名为“软件需求规格说明书产品标识XXX分册”。
软件需求规格说明书的定义:
详细描述系统或者子系统的范围、边界、用户界面、外部行为等。
此文档用来让读者了解系统或者子系统的外部黑盒概念并指导《高层设计》、《测试案例》以及后续开发以及作为系统测试的依据指导系统测试案例的开发。
当某一章节没有内容时必须注明NA同时标注理由。
例如:
本章节内容无需考虑。
特别说明:
当某章节内容参见其它文档时不能注明NA而应该写明参见某文档的具体章节。
文档版本号:
文档编号:
文档密级:
保密归属部门项目:
产品名:
子系统名:
编写人:
编写日期:
kkfun技术(深圳)有限公司版权所有内部资料注意保密修订记录:
修订版本号修订人修订日期修订描述VAXXX创建初稿VBBBB根据适应性修订目录简介目的范围预期的读者和阅读建议参考资料包含文档相关文档定义、首字母缩写词和缩略语整体说明功能简介运行环境假设和依赖外部约束功能性需求特性集名称一特性一功能划分功能点功能点SFR编号:
XXX功能性需求(二选一)角色描述用例概述前置条件SFR编号场景编号:
场景前置条件执行步骤后置条件SFR编号场景编号:
场景前置条件执行步骤后置条件SFR编号场景编号:
场景前置条件执行步骤后置条件界面示意图SFR:
用户注册角色描述用例概述前置条件SFR:
正常流前置条件执行步骤后置条件SFR:
异常流前置条件执行步骤后置条件SFR:
异常流前置条件执行步骤后置条件界面示意图SFR编号:
XXX报表(二选一)指标说明维度说明输入条件样例说明包含内容适用范围报表标题排序方式统计周期……特性二特性集名称二界面及接口总体界面效果总体接口描述非功能性需求获取来源适用的标准准确性可用性SNR编号:
可用性需求一安全性系统安全:
操作安全:
操作监控:
数据安全:
维护工具:
数据监控:
算法安全:
产品安全标准可靠性SNR编号:
可靠性需求一性能SNR编号:
性能需求一可维护性SNR编号:
可维护性需求一可部署性(可选)文档需求用户手册联机帮助安装指南、配置文件、自述文件附录简介本章应提供整个系统或者子系统的概述。
它应包括此系统或者子系统的目的、范围、定义、首字母缩写词、缩略语、参考资料以及依赖和假设。
注:
软件需求规格说明书完整地记录本系统或者子系统的需求。
目的本节应描述此文档的目的。
本说明书是整个软件开发的依据它对以后阶段的工作起指导作用。
本文也是项目完成后系统验收的依据。
同时本说明书还是《用户手册》和《测试计划》的编写依据。
范围简要说明此产品需求规格说明书文档的范围、它的相关产品以及受到此文档影响的任何其他事物。
本节应提供此软件需求规格说明书所涉及的软件及其目的的简短描述包括利益和目标。
把软件与企业目标或业务策略相联系。
可以参考项目视图和范围文档而不是将其内容复制到这里预期的读者和阅读建议本节应列举此软件需求规格说明书所针对的不同读者预期读者包括但不限于:
产品经理、设计人员、开发人员和测试人员也可供客户、第三方产品的相关人员阅读。
本文档组织方式以及阅读建议:
第章简介对文档目的、范围等进行说明并说明文档的组织方式第章整体说明对软件进行整体说明有助于了解软件的整体概貌。
第章功能性需求对功能性需求进行详细说明包括用例的详细说明以指导后续的架构设计、软件设计工作并对测试工作提供参考设计人员和开发人员可以从这个部分得到功能性的需求描述并据此进行设计、开发工作测试人员可以据此进行测试案例的设计和测试计划的制定。
第章界面及接口描述界面及接口方面的需求设计人员和开发人员可以从这个部分得到功能特性的界面组织形式从而更好的理解需求并设计和实现需求。
第章非功能性需求对软件的非功能性需求进行描述以指导后续的架构设计、软件设计工作并对测试工作提供参考设计人员和开发人员在设计、开发过程中应当包含对这些需求的设计、开发工作测试人员在测试过程中应当包含对这些需求的测试案例及验证第章文档需求描述文档需求第章附录参考资料此小节应完整地列出软件需求规格说明书中所参考的资料或其它资源。
这可能包括但并不限于包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档或相关产品的软件需求规格说明。
每个文档应标有标题、报告号(如果适用)、日期和出版单位。
列出可以获取这些参考资料的来源。
这些信息可以通过参考附录或其他文档来提供。
同时文档中说明为引用、参考的文档也应该在这里列出。
参考文档需要按包含、相关的关系分别在下面的小节中列出。
包含文档当本文有包含文档时需要提供相关的包含文档列表。
包含文档:
作为本软件需求规格说明书的一部分是不可分割的组成部分是读者阅读本文档时必须同时也阅读的文档。
如当本软件需求规格说明书非常复杂而有分册时则分册就属于本文档的包含文档。
通常情况下软件需求规格说明书没有包含文档相关文档当本文有相关文档时需要提供相关文档列表。
相关文档:
具有关联关系的文档。
读者在阅读本软件需求规格说明书时如果有必要可以参考阅读的文档。
如相关产品、子系统或者模块的产品需求、软件需求、用户界面风格指导相关方请求等相关文档。
定义、首字母缩写词和缩略语此小节应提供正确理解此软件需求规格说明书所需的全部术语的定义、首字母缩写词和缩略语以便读者可以正确地解释软件需求说明。
可以通过参考项目词汇表来获取这些信息。
缩略语术语全称说明整体说明本节应概述正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖说明影响系统及其需求的一般因素。
本节并不列出具体的需求而只是提供在第节中详述的各种需求的背景以使这些需求便于理解。
所包括的内容有:
•产品总体效果•假设与依赖关系功能简介本节应对产品的基本功能做简介的介绍包括以下内容:
本系统的开发意图、应用目标及作用范围。
.概略介绍系统所具有的主要功能。
可以用列表的方法给出也可以用图形表示主要的需求分组以及它们之间的联系例如数据流程图的顶层图或类图等。
.说明本系统与其他相关系统的关系是独立系统还是一个较大系统的组成部分。
可以用表示外部接口和数据流的系统高层次图或者方框图说明。
注:
可以引用或者参考《产品需求说明书》中相应章节的内容运行环境硬件环境:
如果客户对于硬件有特殊要求在此必须按照客户的要求把硬件环境描述出来如果客户对于硬件没有特别指定则在此处应详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。
软件环境:
如果客户对于软件环境有特别要求则在此处应按照客户的要求把软件环境描述出来如果客户对于软件环境没有特别要求则在此处应详细列出本软件运行时所必须的软件环境例如操作系统、网络软件、数据库系统以及其它特殊软件要求。
假设和依赖列举出在对软件需求规格说明中影响需求陈述的假设因素。
如果这些假设不正确、不一致或被更改就会使项目受到影响。
本节列举的假设和依赖可能包括但并不限于以下内容:
确定项目对外部因素存在的依赖。
例如如果你打算把其它项目开发的组件集成到系统中那么你就要依赖那个项目按时提供正确的操作组件。
如果这些依赖已经记录到其它文档(例如项目计划)中了那么在此就可以参考其它文档。
如果本系统的某些功能特性必须依赖于其他系统的功能或者数据这依赖于与相关方达成一致共识包括与相关方达成接口契约以及法律方面的协议等对于一些有争议或者需要裁剪或者简化的软件功能特性已经获得用户的认可。
……(其他假设和依赖)注:
当产品需求与软件需求一一对应时可以直接参考和引用《产品需求规格说明书》“假设与依赖”部分章节的内容但如果产品需求分解成多个软件需求时那么软件需求应根据实际情况把该部分的假设和依赖进行更细致的描述。
外部约束本节应说明本软件在实现时所必须满足的条件和所受的限制并给出相应的原因。
条件与限制包括但并不限于(主要指软件环境、硬件环境市场环境以及政策法规):
必须使用或者避免的特定技术、工具、编程语言和数据库企业策略、政府法规或工业标准例如SOX对于MISC的限制硬件限制例如定时需求或存储器限制经费限制、开发期限项目对外部因素存在的依赖。
例如其它项目开发的软件。
等等功能性需求列出产品的特性。
特性是为让用户获益而必须具备的高级系统功能。
每一项特性都是外部所需的服务它通常需要一系列输入来实现预期的结果。
此节为设计的系统功能性需求,一般以用例结合自然语言来表达。
此节通常按特性来组织但也可能会有其他适用的组织方式。
这一节应包含所有的产品需求其详细程度应使架构设计人员和软件需求设计人员能够设计出可以满足这些需求的系统包括可选流程和异常流程对具体语义做约束。
特性集名称一此节可把《产品需求说明书》章节对应的特性集复制到此处。
在此处应描述该特性集有哪些特性。
特性一此节可把《产品需求说明书》章节对应的特性集复制到此处功能划分此节应从使用用户的角度描述将特性划分成相应的功能用例并给出总体功能结构。
对于复杂的系统还需要对主要子系统中的基本功能进行描述。
描述方法包括结构图、流程图或对象图或者表格等等。
但应注意此处划分成的部分并不对应于最终程序实现时的不同功能模块。
本节应包括对应功能特征各部分的内容包括下列内容:
此功能对应的用例图以及相关的用例说明此处可以用用例图来描述:
关于用例的编号规则:
SFR编号。
对应用例的编号、简要说明。
此处如用表格来描述建议采用以下表格:
用例编号用例名称简要说明
功能点此节应对系统的基本功能进行描述并描述该功能点与内部模块、外部系统或外部模块之间的关系a、功能描述b、该功能与内部模块的关系c、该功能与外部系统或模块的关系功能点此节应对系统的基本功能进行描述并描述该功能点与内部模块、外部系统或外部模块之间的关系a、功能描述b、该功能与内部模块的关系c、该功能与外部系统或模块的关系SFR编号:
XXX功能性需求(二选一)如果是报表部分功能特征开发可不选择本节模板。
此处可用图例简单描述用例说明该用例的使用角色业务实体以及相关的业务实体等角色描述描述角色相关的事项例如角色的名称角色的职责等角色:
谁使用此功能或者在此功能之外与该功能进行交互的人或事务。
角色并不单纯指某个人也可能包括某个其他功能或者构件用例概述此处描述用例的相应事项例如相关的业务实体等。
前置条件本节应描述本用例发生的前置条件包括前置用例输入条件或者进入用例的约束SFR编号场景编号:
场景在本节应描述对应用例的正常流即满足该用例执行时所有条件时的正常执行过程。
前置条件在此处应场景发生的前置条件。
执行步骤在此处应描述用例正常执行即满足该用例执行时所有条件时的正常执行过程以及步骤说明后置条件此处应描述在正常流程执行完毕以后的结果例如输出或者是触发下一个用例。
SFR编号场景编号:
场景前置条件在此处应描述场景发生的前置条件。
执行步骤在此处应描述用例执行时由于某种情况产生的分支流异常事件也是属于一种分支流在此处可以用时序图活动图把该分支流发生的逻辑描述出来。
后置条件在此处应描述当用例执行时产生的分支流输出的结果例如输出结果或者是否启动另外一个用例。
SFR编号场景编号:
场景前置条件在此处应描述场景发生的前置条件。
执行步骤在此处应描述用例执行时由于某种情况产生的分支流异常事件也是属于一种分支流在此处可以用活动图把该分支流发生的逻辑描述出来。
后置条件在此处应描述当用例执行时产生的分支流输出的结果例如输出结果或者是否启动另外一个用例。
界面示意图在本节应出具用例相关的界面示意图以指导后续的设计活动开发SFR编号:
XXX报表(二选一)本节主要是针对于面向BIReport实现的功能性需求描述。
本节应包括对应功能特征各部分的内容包括下列内容:
功能描述:
描述该功能的作用以及为客户带来的价值。
指标说明此处应描述该报表有哪些指标。
至于指标的定义和算法可以参考指标相关的技术文档。
维度说明此处应描述该报表展现的维度输入条件此处应描述查询报表时的输入条件如有必要可以提供查询界面Demo。
样例说明注:
对于面向BIReport的功能来说样例说明即其界面示意。
可以比较准确的描述分析或者报表的界面以对后续的开发活动做出指导。
指标指标指标……
包含内容此处应说明报表的数据包含的数据内容例如:
CS:
包含全网SP以及本地接入全网SP的短信业务汇总数据。
PS:
包含全网SP以及本省直辖市的全网本地接入SP、本地SP的短信业务汇总数据。
适用范围此处应说明报表的适用范围是适用于中央还是各省市以及全网等报表标题此处应说明报表的标题如果有分集团和省报表应分别定义报表的名称例如:
CS:
短信业务各SP分地区分用户品牌基础报表PS:
短信业务各SP分地区分用户品牌基础报表(空格)(省份)排序方式此处应说明报表内容的排序方式如果有多级排序应在此说明排序的顺序例如:
排序顺序排序维度排序方式SP服务代码升序排列企业代码升序排列地区代码升序排列统计周期此处应说明报表报表的统计周期例如:
本报表的统计周期为:
日周月……此处如果有其他需要特别说明可在此增加章节说明。
特性二特性集名称二界面及接口总体界面效果本小节概要描述产品特性包含的的用户界面效果要求且仅要求提供总体性的说明。
总体接口描述本小节列举产品外部接口要求且仅要求能说明各接口关联到的相关产品实体间的关系。
非功能性需求如健壮性、安全保密性、复用性、灵活性、易用性、可维护性、可移植性等。
指明不同属性的相对侧重点例如易用程度优于易学程度或者可移植优于有效性。
健壮性:
说明软件在容错能力故障处理能力上需要达到的目标保证系统稳定可靠安全保密性:
包括用户身份确认或授权方面的需求保密性策略系统所创建或使用的数据的保护等等复用性:
说明本项目是否可以复用已有软件、是否可为其它系统复用灵活性:
说明在运行环境、与其他软件的接口以及开发计划等发生变化时应具有的适应能力。
获取来源列举非功能性需求的获取来源。
例如:
)客户提出的并已经与其他相关方达成一致的非功能性需求)已经存在的特定类型产品所能参照的业界标准)采用相应的测试工具测试同类产品或原型产品所获取的数据)同类产品已经存在的参考基准。
适用的标准列出产品必须符合的所有标准。
其中可能包括法律和法规(FDA、UCC)标准、通讯标准(TCPIP、ISDN)、平台一致性标准(Windows、Unix等)以及质量和安全标准(UL、ISO、CMM)。
准确性此节应描述对系统准确性的要求。
例如数据准确性可用性此节应包括所有影响可用性的需求参考《架构设计说明书》相关章节。
例如•指出普通用户和高级用户要高效地执行特定操作所需的培训时间•指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可用性需求•指出在符合公认的可用性标准(如IBM的CUA标准和Microsoft的GUI标准)方面的需求SNR编号:
可用性需求一在此给出需求说明。
例子:
SNR:
系统必须提供良好的用户界面以方便用户订购和使用业务。
一个阅读过FAQ或观看过使用演示的用户能够在分钟内完成一次用户登陆浏览服务信息定购服务操作。
SNR:
同时要求能够对所有系统级和应用级的错误包括用户的输入错误都能有友好的出错提示页面。
参见附录A提示语定义。
安全性本节应详尽陈述与系统安全性、完整性或与私人问题相关的需求这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。
定义用户身份确认或授权需求。
明确产品必须满足的安全性或保密性策略。
此节应列出将提高所构建系统的安全性的所有需求。
具体的要求参见《产品安全性需求》可维护性遵循此方案的策略。
建立公司级别的产品安全标准,针对各产品的特性确定安全级别系统安全:
根据各产品安全级别的设定,各产品需要从界面到接口到内核到数据层层设防,以便保证系统不可能被轻易入侵,关键数据不可能被轻易破坏和修改操作安全:
根据各产品安全级别的设定,各产品需要建立产品内的审计系统,做到所有高危操作均有据可循,所记录的信息满足内部审计和问题排查的要求操作监控:
根据各产品安全级别的设定,各产品需要有相关的监测工具对系统的非正常操作进行监查,一旦发现异常操作及时告警数据安全:
根据各产品安全级别的设定,各产品对核心数据需要有相关的保护措施,做到非正常操作无法破坏和非法修改,并发现有异动可及时告警维护工具:
根据各产品安全级别的设定,将有操作风险的维护工作均全部工具化和界面化,隔离维护者直接接触系统数据监控:
各产品需要建立相应的业务数据变动异常的标准,开发相关的工具对以上业务数据异常进行监控和分析,以便及时发现SP利用MISC系统漏洞或其他手段违规算法安全:
产品线需要根据各产品的安全级别设定,提高内部管理方法及手段,严格控制关键代码和关键算法,以便防止关键算法和业务流程外泄针对安全问题的处理,产品线需要建立相关的处理机制并配置相关的人员,以便跟进和产品有关的安全问题的后续处理和问题分析针对各产品的安全标准和安全规划,需要在产品设计阶段在控制范围内进行专项讨论,并会合相关部门一起确定相关方案和规划,并安排产品经理制定产品的长期安全目标和短期目标并跟踪加以实施产品安全标准设计相关级别为(),根据安全性的要求决定在产品中接口安全,核心逻辑安全,数据安全,审计手段,维护工具,防攻击手段,安全分析手段,产品部署建议方案中的投入力度开发相关级别为(),根据安全性的要求决定关键算法和关键业务逻辑的相关代码的开发范围及代码扩散范围,并根据相关级别对开发中采用的算法和业务逻辑进行审核检查测试相关级别为(),根据安全性的要求决定安全相关PATCH的测试范围和告知人员并根据相关级别对产品进行相关的安全性测试本节如包含多项可维护性需求可分多小节描述。
可靠性对系统可靠性的需求应在此处说明详尽陈述在软件使用过程中可能发生的损失、破坏或危害相关的需求。
定义必须采取的安全保护或动作还有那些预防的潜在的危险动作。
明确产品必须遵从的安全标准、策略或规则。
本节可参考《架构设计说明书》相关章节。
以下是一些建议:
•可用性指出可用时间百分比(xxxx)、使用小时数、维护访问权、降级模式操作等。
•平均故障间隔时间(MTBF)通常表示为小时数但也可表示为天数、月数或年数。
•平均修复时间(MTTR)系统在发生故障后可以暂停运行的时间。
•精确度指出系统输出要求具备的精密度(分辨率)和精确度(按照某一已知的标准)。
•最高错误或缺陷率通常表示为每千行代码的错误数目(bugsKLOC)或每个功能点的错误数目(bugsfunctionpoint)。
•错误或缺陷率按照小错误、大错误和严重错误来分类。
需求中必须对“严重”错误进行界定例如:
数据完全丢失或完全不能使用系统的某部分功能。
SNR编号:
可靠性需求一需求说明。
例子:
可靠性指系统在规定的时间内及规定的环境条件下完成规定功能的能力。
SNR:
参照现网WAPPortal的运行情况。
要求在连续的天内在网络环境正常、与系统相连的MISCISMGSSOWTBSSP平台功能正常的情况下在系统的额定处理能力之内(额定处理能力参考下文的计算方法)系统发生故障后从开始处理到系统恢复的时间不能超过分钟(按一次计算超过min的概率低于%从系统正式商用开始统计,此处人员到场的延误及分析和处理问题的时间)。
SNR:
系统发生异常到系统发出告警的时间的时延不能超过分钟。
SNR:
健壮性要求:
当用户输入非法数据时不能引起系统的运行故障要保证系统功能%可用SNR:
要求在HPRP(每台配置*MhzGB内存)数据库服务器配置为HPRP(每台配置*MhzGB内存)条件下天内当cpu的使用率低于%内存使用率低于%且系统处理能力不高于额定的处理能力的情况下系统的外部环境出现问题如网络异常、与系统相连的MISCISMGSSO平台等外部系统发生故障并在分钟内全部恢复正常运行后MZonePortal系统功能在分钟内自动恢复次数不能少于总故障次数的%。
性能此节应概述系统的性能特征参考《系统需求说明书》相关章节。
其中需包括具体的响应时间。
如果可行按名称引用相关用例。
•对事务的响应时间(平均、最长)•吞吐量例如每秒处理的事务数•容量例如系统可以容纳的客户或事务数•降级模式(当系统以某种形式降级时可接受的运行模式)•资源利用情况如内存、磁盘、通信等应尽可能详细地确定性能需求。
可能需要针对每个功能需求或特性分别陈述其性能需求而不是把它们都集中在一起陈述SNR编号:
性能需求一【阐述不同的软件功能对系统性能的需求并解释它们的原理以帮助开发人员作出合理的设计选择。
这些性能需求例如:
数据精确度:
根据实际情况确定软件最终输出数据(包括传输中)的数据精确度。
时间特性:
说明开发的软件在响应时间、更新处理时间、数据转换与传输时间、运行时间等方面所需达到的时间特性。
用户数:
最大用户数并发用户数以及相互合作的用户数或者所支持的操作容量需求例如存储器和磁盘容量的需求或者存储在数据库中表的最大行数】。
例子:
SNR:
处理能力在对性能做要求时我们参考WWWPortal和PDAPortal的性能测试结果。
计算方法如下:
用户行为模型:
%的服务信息浏览+%的登录+%的订购。
系统运行环境:
要求在HPRP(每台配置*MhzGB内存)并且CPU平均负荷低于的条件下。
数据库服务器配置为HPRP(每台配置*MhzGB内存)CPU平均负荷低于的条件。
数据库软件为oraclei。
网络环境为内网忽略网络带宽的影响。
页面条件:
参照MZonePorta的DEMOTransaction的页面数介于~个之间除去页面图片以每个HTTP请求回复内容容量平均以KB计算。
忽略底层协议封装和其它开销。
性能要求:
个用户并发时能达到个TPS(TransactionsPerSecondTPS计算方法:
个浏览个登录个定购同时进行得出所有Transactions的平均值)和的点击率(HitsPerSecond)同时每个独立请求的平均响应时间不能大于ms(从发出请求到收到响应的时间)。
以上性能要求是在扣除了调用MISC系统接口和SSO系统接口的时间开销后的值。
可维护性此节应列出将提高所构建系统的可支持性或可维护性的所有需求其中包括编码标准、命名约定、类库、维护访问权和维护实用程序。
SNR编号:
可维护性需求一在此给出需求说明。
可部署性(可选)此节应从需求角度列出对可部署性的考虑比如如何简化部署环节缩短部署时间提高部署效率等。
该章节要求服务总部的同事参与需求评审时重点关注文档需求此节说明为支持成功部署应用程序而必须制作的文档。
用户手册说明用户手册的目的和内容。
讨论预期长度、详细程度是否需要索引、词汇表、教程与引用手册策略等。
还应确定格式和打印约束条件。
联机帮助许多应用程序提供了联机帮助系统来协助用户。
这些系统的性质对于应用程序开发来说独特的因为它们综合了编程(如超链接)和技术写作(组织、演示)的各个方面。
许多人发现联机帮助系统的开发本身就是一个受益于先期规模管理和计划活动的产品。
安装指南、配置文件、自述文件在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 规格 说明书 项目 名称 模板 编辑
![提示](https://static.bingdoc.com/images/bang_tan.gif)