软件需求规格说明书Word文档下载推荐.docx
《软件需求规格说明书Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《软件需求规格说明书Word文档下载推荐.docx(8页珍藏版)》请在冰豆网上搜索。
x.x.x;
y.y.y
I.修改XXX
1.Xxx
2.Xxx
3....
1.02
II.修改XXX
……
2.00
分发记录
CopyNo.
Holder'
sName&
Role
持有者和角色
IssueDate
分发日期
1
RDPDTPDT开发代表>
2
ProjectManager项目经理>
3
Teammembers项目组成员>
4
CustomerRepresentative客户代表>
5
Others其他>
目
录
1
简介
2
1.1
目的
1.2
范围
2
总体概述
2.1
软件概述
2.1.1
项目介绍
2.1.2
产品环境介绍
2.2
软件功能
2.3
用户特征
2.4
假设和依赖关系
3
具体需求
3.1
功能需求
3.1.1
功能需求1
3.2
性能需求
3.2.1
性能需求1
3.3
外部接口需求
3.3.1
用户接口
3.3.2
软件接口
3.3.3
硬件接口
3.3.4
通讯接口
4
总体设计约束
4.1
标准符合性
4.2
硬件约束
4.3
技术限制
5
软件质量特性
6
依赖关系
7
其他需求
7.1
数据库
7.2
操作
7.3
本地化
8
需求分级
9
待确定问题
10
附录
10.1
附录A
可行性分析结果
10.2
附录B
需求建模
10.2.1
数据流图
10.2.2
数据字典
表目录
Table1
**表
错误!
未定义书签。
表1
图目录
Figure1
**图
关键词:
能够体现文档描述内容主要方面的词汇。
摘
要:
缩略语清单:
对本文所用缩略语进行说明,要求提供每个缩略语的英文全名和中文解释。
缩略语
英文全名
中文解释
1
简介
1.1目的
这部分要描述文档的目的。
应该指明读者。
说明本需求文档描述了哪个产品的软件需求。
1.2范围
本节应描述文档所包括和不包括的内容。
2总体概述
本节描述影响产品和产品需求的一般因素。
由以下4个部分构成。
有一点需说明的是本节不描述具体的需求,只是使那些将要描述的具体需求更易于理解。
2.1软件概述
2.1.1项目介绍
描述本软件需求所描述的项目的背景。
例如:
本项目是一系列版本中的一个,或者是替代某个已经存在的系统,还是一个新的独立的项目。
2.1.2产品环境介绍
描述的是本产品与其它产品或项目所组成的整体环境。
1.如果本产品是独立的并完全自我包含,在此说明这一点。
2.如果SRS定义的产品是更大的系统或项目的组件(此种情形经常发生),那么应:
A.描述此大系统或项目每个组件的功能,并且标识接口。
B.
确定本软件产品主要外部接口。
(注意:
在此部分并不进行这些接口的详细描述;
对这些接口的详细描述在SRS的其它部分提供。
)
C.描述相关产品硬件和所使用的外部设备。
(
注意:
这只是概述性描述。
通过方块图来描述大系统或项目的主要组件,互连性以及外部接口将是非常有帮助的。
本部分不应提出一个具体的设计解决方案或对解决方案的具体设计约束(具体设计约束将在具体需求章节中描述)。
本部分内容是产生设计约束的基础。
2.2软件功能
概述软件的必须实现的和通过用户操作实现的主要功能。
这里只需要进行简要描述(例如目录列表),详细描述在详细需求部分描述。
对需求功能进行组织,以便于读者理解,并能指导后续的设计和测试。
可以用图表来表示主要需求群组之间的关系,例如:
高层的数据流图,面向对象的分析等。
有时此部分所要求的功能概述可以从分配具体功能给此软件产品的更高层规格(如果存在的话)直接引用。
本节不应描述具体需求。
但本节内容是具体需求章节的基础。
2.3用户特征
列出对用户或系统操作者的要求,如:
经验,能力,角色等。
2.4假设和依赖关系
列出可能影响SRS中需求的所有的假设因素(与已知事实相对而言),包括准备使用的第三方或商业组件,操作和开发环境的问题约束等。
如果上述假设不正确、没有被告知或者改变了都将对项目产生影响。
列出项目对外部条件的依赖,例如重用其他项目的模块等。
如果在其他文档(例如项目计划或范围文档等)里已经描述了,在这里可以不用描述。
3具体需求
在每一条需求描述中重复下列部分
3.1功能需求
本子章节应描述软件产品的输入怎样被转换成输出。
它描述了软件必须执行的基本动作。
对每一类功能或有时对每一个单独的功能,必须描述输入、处理、输出方面的需求。
这些通常以下面四个子段落来组织:
3.1.1功能需求1
用需求编号加上简短词汇做为功能需求名,不要用“功能需求
(1)”作为功能名,例如:
R.INTF.CALC.001计算表达式
R.INTF.CALC.002打印
需求编号规则按照软件需求管理规程(REP01)进行
1.介绍
逐条列出与本特性相关的功能需求。
包括项目如何响应预期的错误输入,非法条件和无效输入。
需求应该简明,完整,不含糊,可验证,必要的。
当需要的信息不确定的时候使用“待定”。
2.输入
本子段落应包含下列内容:
A.对该功能所有输入数据的详细描述,包括:
输入来源
数量
度量单位
时间要求
包含精度和容忍度的有效输入范围
B.在适当的地方提供的对接口规格或接口控制文档的参考。
3.处理
本子段落应描述对输入数据所执行的所有操作和如何获得输出的过程。
这包括下列规格:
A.输入数据的有效性检测。
B.操作的确切次序,包括各事件的时序。
C.对异常情况的回应,例如:
溢出
通信失败
错误处理
D.用于把系统输入转换到相应输出的任何方法(诸如方程式,数学算法,逻辑操作)。
例如,这可能描述下列方面:
对工资单里代扣所得税的计算公式。
用于气象预报的气象模型。
E.
对输出数据的有效性检测。
4.输出
本子段落应包含:
A.对该功能所有输出数据的详细描述,这个描述包括:
输出的到何处(如打印机,文件)
时序
包含精确度和容忍度的有效输出范围
对非法值的处理
错误消息
B.在适当的地方提供对接口规格或接口控制文档的参考。
此外,对那些需求集中在输入/输出行为的系统,SRS应描述所有重要的输入/输出行为及输入输出对的次序。
对一个需要记忆其行为以根据输入和过去的行为进行反应的系统,输入输出对的次序是要求的;
这种功能行为就类似于有限状态机。
3.2
性能需求
如果有性能方面的需求,在这里列出并解释他们的原理。
以帮助开发者理解意图以做出正确的设计选择。
在实时系统中的时序关系。
保证需求尽可能的详细而精确。
3.2.1性能需求1
本子章节应从整体上描述静态和动态的量化的对软件(或人与软件交互)的需求。
静态的量化需求可能包括:
A.支持的终端数目。
B.支持的同时使用的用户数目。
C.处理的文件和记录的数目。
D.表和文件的大小。
动态的量化需求可能包括:
A.在正常和峰值工作量条件下特定时间段(如一小时)