需求规格说明书项目名称模板.docx
- 文档编号:11400291
- 上传时间:2023-05-31
- 格式:DOCX
- 页数:24
- 大小:29.77KB
需求规格说明书项目名称模板.docx
《需求规格说明书项目名称模板.docx》由会员分享,可在线阅读,更多相关《需求规格说明书项目名称模板.docx(24页珍藏版)》请在冰点文库上搜索。
需求规格说明书项目名称模板
软件需求规格说明书
产品发布标识
[本模板用于软件需求开发管理流程中软件需求规格说明书的编写。
其中包括用方括号括起来并以蓝色斜体(样式=infoblue)显示的文本,它们用于向作者提供指导,在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式(样式=正文)。
一般说来,一个产品需求对应一份软件需求,在软件需求中也可以分成多个分册。
此时本文档可命名为“软件需求规格说明书_产品标识_XXX分册”。
]
[软件需求规格说明书的定义:
详细描述系统或者子系统的范围、边界、用户界面、外部行为等。
此文档用来让读者了解系统或者子系统的外部黑盒概念,并指导《高层设计》、《测试案例》以及后续开发,以及作为系统测试的依据,指导系统测试案例的开发。
[当某一章/节没有内容时,必须注明N/A,同时标注理由。
例如:
本章/节内容无需考虑。
特别说明:
当某章/节内容参见其它文档时,不能注明N/A,而应该写明参见某文档的具体章节。
]
]文档版本号:
文档编号:
文档密级:
保密
归属部门/项目:
产品名:
子系统名:
编写人:
编写日期:
kkfun技术(深圳)有限公司版权所有
内部资料注意保密
修订记录:
修订版本号
修订人
修订日期
修订描述
V1.0A
XXX
2004-5-8
创建初稿
V1.0B
BBB
2006-4-21
根据适应性修订
目录
1简介6
1.1目的6
1.2范围6
1.3预期的读者和阅读建议6
1.4参考资料7
1.4.1包含文档7
1.4.2相关文档7
1.5定义、首字母缩写词和缩略语7
2整体说明8
2.1功能简介8
2.2运行环境8
2.3假设和依赖8
2.4外部约束9
3功能性需求9
3.1特性集名称一9
3.1.1特性一9
3.1.1.1功能划分10
3.1.1.1.1功能点110
3.1.1.1.2功能点210
3.1.1.2SFR<编号>:
XXX功能性需求(二选一)11
3.1.1.2.1角色描述11
3.1.1.2.2用例概述11
3.1.1.2.3前置条件11
3.1.1.2.4SFR<编号>.<场景编号>:
场景111
3.1.1.2.4.1前置条件11
3.1.1.2.4.2执行步骤11
3.1.1.2.4.3后置条件11
3.1.1.2.5SFR<编号>.<场景编号>:
场景211
3.1.1.2.5.1前置条件11
3.1.1.2.5.2执行步骤12
3.1.1.2.5.3后置条件12
3.1.1.2.6SFR<编号>.<场景编号>:
场景312
3.1.1.2.6.1前置条件12
3.1.1.2.6.2执行步骤12
3.1.1.2.6.3后置条件12
3.1.1.2.7界面示意图12
3.1.1.3SFR1:
用户注册12
3.1.1.3.1角色描述13
3.1.1.3.2用例概述13
3.1.1.3.3前置条件13
3.1.1.3.4SFR2.1:
正常流14
3.1.1.3.4.1前置条件14
3.1.1.3.4.2执行步骤14
3.1.1.3.4.3后置条件15
3.1.1.3.5SFR2.2:
异常流115
3.1.1.3.5.1前置条件15
3.1.1.3.5.2执行步骤15
3.1.1.3.5.3后置条件15
3.1.1.3.6SFR2.3:
异常流216
3.1.1.3.6.1前置条件16
3.1.1.3.6.2执行步骤16
3.1.1.3.6.3后置条件16
3.1.1.3.7界面示意图17
3.1.1.4SFR<编号>:
XXX报表(二选一)17
3.1.1.4.1.1指标说明17
3.1.1.4.1.2维度说明17
3.1.1.4.1.3输入条件17
3.1.1.4.1.4样例说明17
3.1.1.4.1.5包含内容18
3.1.1.4.1.6适用范围18
3.1.1.4.1.7报表标题18
3.1.1.4.1.8排序方式18
3.1.1.4.1.9统计周期18
3.1.1.4.1.10……18
3.1.2特性二18
3.2特性集名称二18
4界面及接口19
4.1总体界面效果19
4.2总体接口描述19
5非功能性需求19
5.1获取来源19
5.2适用的标准19
5.3准确性20
5.4可用性20
5.4.1SNR<编号>:
可用性需求一20
5.5安全性20
5.5.1系统安全:
21
5.5.2操作安全:
21
5.5.3操作监控:
21
5.5.4数据安全:
21
5.5.5维护工具:
21
5.5.6数据监控:
21
5.5.7算法安全:
21
5.5.8产品安全标准22
5.6可靠性22
5.6.1SNR<编号>:
可靠性需求一23
5.7性能23
5.7.1SNR<编号>:
性能需求一24
5.8可维护性25
5.8.1SNR<编号>:
可维护性需求一25
5.9可部署性(可选)25
6文档需求25
6.1用户手册25
6.2联机帮助25
6.3安装指南、配置文件、自述文件25
7附录26
1简介
[本章应提供整个系统或者子系统的概述。
它应包括此系统或者子系统的目的、范围、定义、首字母缩写词、缩略语、参考资料以及依赖和假设。
]
[注:
软件需求规格说明书完整地记录本系统或者子系统的需求。
]
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特性一
[此节可把《产品需求说明书》章节对应的特性集复制到此处]
3.1.1.1功能划分
[此节应从使用用户的角度描述将特性划分成相应的功能用例,并给出总体功能结构。
对于复杂的系统,还需要对主要子系统中的基本功能进行描述。
描述方法包括结构图、流程图或对象图或者表格等等。
但应注意此处划分成的部分并不对应于最终程序实现时的不同功能模块。
本节应包括对应功能特征各部分的内容,包括下列内容:
此功能对应的用例图以及相关的用例说明;此处可以用用例图来描述:
关于用例的编号规则:
SFR<编号>。
对应用例的编号、简要说明。
此处如用表格来描述,建议采用以下表格:
用例编号
用例名称
简要说明
]
3.1.1.1.1功能点1
[此节应对系统的基本功能进行描述,并描述该功能点与内部模块、外部系统或外部模块之间的关系
a、功能描述
b、该功能与内部模块的关系
c、该功能与外部系统或模块的关系]
3.1.1.1.2功能点2
[此节应对系统的基本功能进行描述,并描述该功能点与内部模块、外部系统或外部模块之间的关系]
a、功能描述
b、该功能与内部模块的关系
c、该功能与外部系统或模块的关系]
3.1.1.2SFR<编号>:
XXX功能性需求(二选一)
[如果是报表部分功能特征开发,可不选择本节模板。
此处可用图例简单描述用例,说明该用例的使用角色,业务实体,以及相关的业务实体等]
3.1.1.2.1角色描述
[描述角色相关的事项,例如角色的名称,角色的职责等;
角色:
谁使用此功能,或者在此功能之外与该功能进行交互的人或事务。
角色并不单纯指某个人,也可能包括某个其他功能或者构件]
3.1.1.2.2用例概述
[此处描述用例的相应事项,例如相关的业务实体等。
]
3.1.1.2.3前置条件
[本节应描述本用例发生的前置条件,包括前置用例,输入条件或者进入用例的约束]
3.1.1.2.4SFR<编号>.<场景编号>:
场景1
[在本节应描述对应用例的正常流,即满足该用例执行时所有条件时的正常执行过程。
]
3.1.1.2.4.1前置条件
[在此处应场景1发生的前置条件。
]
3.1.1.2.4.2执行步骤
[在此处应描述用例正常执行,即满足该用例执行时所有条件时的正常执行过程以及步骤说明]
3.1.1.2.4.3后置条件
[此处应描述在正常流程执行完毕以后的结果,例如输出,或者是触发下一个用例。
]
3.1.1.2.5SFR<编号>.<场景编号>:
场景2
3.1.1.2.5.1前置条件
[在此处应描述场景2发生的前置条件。
]
3.1.1.2.5.2执行步骤
[在此处应描述用例执行时,由于某种情况产生的分支流,异常事件也是属于一种分支流,在此处可以用时序图/活动图把该分支流发生的逻辑描述出来。
]
3.1.1.2.5.3后置条件
[在此处应描述当用例执行时产生的分支流输出的结果,例如输出结果,或者是否启动另外一个用例。
]
3.1.1.2.6SFR<编号>.<场景编号>:
场景3
3.1.1.2.6.1前置条件
[在此处应描述场景3发生的前置条件。
]
3.1.1.2.6.2执行步骤
[在此处应描述用例执行时,由于某种情况产生的分支流,异常事件也是属于一种分支流,在此处可以用活动图把该分支流发生的逻辑描述出来。
]
3.1.1.2.6.3后置条件
[在此处应描述当用例执行时产生的分支流输出的结果,例如输出结果,或者是否启动另外一个用例。
]
3.1.1.2.7界面示意图
[在本节应出具用例相关的界面示意图,以指导后续的设计活动开发]
3.1.1.3SFR<编号>:
XXX报表(二选一)
[本节主要是针对于面向BI/Report实现的功能性需求描述。
本节应包括对应功能特征各部分的内容,包括下列内容:
功能描述:
描述该功能的作用,以及为客户带来的价值。
]
3.1.1.3.1.1指标说明
[此处应描述该报表有哪些指标。
至于指标的定义和算法,可以参考指标相关的技术文档。
]
3.1.1.3.1.2维度说明
[此处应描述该报表展现的维度]
3.1.1.3.1.3输入条件
[此处应描述查询报表时的输入条件,如有必要,可以提供查询界面Demo。
]
3.1.1.3.1.4样例说明
[注:
对于面向BI/Report的功能来说,样例说明即其界面示意。
可以比较准确的描述分析或者报表的界面,以对后续的开发活动做出指导。
指标1
指标2
指标3
……
]
3.1.1.3.1.5包含内容
[此处应说明报表的数据包含的数据内容,例如:
CS:
包含全网SP以及本地接入全网SP的短信业务汇总数据。
PS:
包含全网SP以及本省/直辖市的全网本地接入SP、本地SP的短信业务汇总数据。
]
3.1.1.3.1.6适用范围
[此处应说明报表的适用范围,是适用于中央,还是各省市,以及全网等]
3.1.1.3.1.7报表标题
[此处应说明报表的标题,如果有分集团和省报表,应分别定义报表的名称,例如:
CS:
短信业务各SP分地区分用户品牌基础报表
PS:
短信业务各SP分地区分用户品牌基础报表(2空格)(省份)]
3.1.1.3.1.8排序方式
[此处应说明报表内容的排序方式,如果有多级排序,应在此说明排序的顺序,例如:
排序顺序
排序维度
排序方式
1
SP服务代码
升序排列
2
企业代码
升序排列
3
地区代码
升序排列
]
3.1.1.3.1.9统计周期
[此处应说明报表报表的统计周期,例如:
本报表的统计周期为:
日,周,月
]
3.1.1.3.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.1SNR<编号>:
可用性需求一
[在此给出需求说明。
例子:
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),根
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 规格 说明书 项目 名称 模板