软件需求规格说明书(模板).doc
- 文档编号:30787011
- 上传时间:2023-09-22
- 格式:DOC
- 页数:18
- 大小:203.93KB
软件需求规格说明书(模板).doc
《软件需求规格说明书(模板).doc》由会员分享,可在线阅读,更多相关《软件需求规格说明书(模板).doc(18页珍藏版)》请在冰豆网上搜索。
软件需求规格说明书
模板
Version1.0●2011.6.18
软件需求规格说明书
模板使用
要通过本模板创建可以交付的文档请遵循以下指导:
1.删除文档标题页和本页。
2.用你的项目和负责人信息替换封面括号中的文本。
3.用你的项目和负责人信息替换页眉区域括号中的信息。
注意:
请不要移除或修改页脚区域的信息。
4.完成整个模板。
每节包含简短的操作说明,在内容区域中用斜体显示。
可交付的文本编写在操作说明下方或模板提供的表格内。
注意:
交付文档时需要移除斜体的说明。
5.目录内容发生变化时,需要更新文档目录。
在目录区右键选择“更新域”就可以更新整个目录。
注意:
当创建一个软件需求说明时,请移除本页.
[机构/组织名称] 软件需求规格说明书
[项目名称] [版本号]|[版本日期]
软件需求规格说明书
【贪吃蛇】
文件状态:
[√]草稿
[]正式发布
[]正在修改
文件标识:
QST-班号-项目代码-DOC-RS
当前版本:
X.Y
作者:
完成日期:
Year-Month-Day
批准人:
批准日期:
Year-Month-Day
签字:
【机构/组织名称】
2
变更历史
序号
版本
变更日期
变更内容
变更者
1
2
3
4
5
6
7
8
9
10
11
12
目录
0.文档介绍 3
0.1文档目的 3
0.2文档范围 3
0.3读者对象 3
0.4参考文档 3
0.5术语与缩写解释 3
1.项目概述 4
1.1产品介绍 4
1.2产品范围 4
1.3用户群体及角色 4
1.4运行环境 5
1.5假设、依赖和约束 5
2.产品的功能性需求 6
2.1整体业务流程图/用例图 6
2.2功能性需求分类 6
2.3功能类别A 6
2.3.xf功能X 6
2.3.xu用例Y 7
2.4功能类别B 8
3.产品的非功能性需求 8
3.1用户界面需求 8
3.2性能需求 8
3.3产品质量需求 9
3.4其他需求 9
4.接口 9
附录A:
需求建模与分析报告 10
A.1需求模型1 10
A.n需求模型N 10
附录B:
需求跟踪矩阵 11
附录C:
需求确认 12
12
0.文档介绍
0.1文档目的
对贪吃蛇游戏进行需求分析,明白用户需求,明确软件具有的功能,性能及界面,为系统设计和编码人员提供依据,方便后期工作。
0.2文档范围
贪吃蛇的功能需求,性能需求及界面。
0.3读者对象
客户
需求分析人员
文档编写人员
编码人员
测试人员
项目管理人员
0.4参考文档
提示:
列出本文档的所有参考文献(可以是非正式出版物),格式如下:
[标识符]作者,文献名称,出版单位(或归属单位),日期
例如:
[SPP-PROC-PP]SEPG,需求开发规范,机构名称,日期
0.5术语与缩写解释
缩写、术语
解释
…
1.项目概述
1.1产品介绍
提示:
(1)说明产品是什么,什么用途。
(2)介绍产品的开发背景。
提供关于发起这个软件开发的业务组织的概要,包括业务组织的使命及业务目标
1.2产品范围
提示:
描述待开发软件产品的范围。
在描述中应该包括:
l描述软件产品的特征
l介绍软件的功能,并进行简要说明
l描述软件产品“适用的领域”和“不适用的领域”,本产品“应当包含的内容”和“不包含的内容”。
(做什么,不做什么)
l说明软件应用
l描述软件的相关的收益、目的和目标等
此处的描述应与之前的项目文档的类似描述保持一致。
说清楚产品范围的好处是:
(1)有助于判断什么是需求,什么不是需求;
(2)可以将开发精力集中在产品范围之内,少干吃力不讨好的事情;(3)有助于控制需求的变更。
1.3用户群体及角色
提示:
(1)描述本产品面向的用户(客户、最终用户)的特征。
(2)说明本产品将给他们带来什么好处?
他们选择本产品的可能性有多大?
(3)根据用户的特征,按照功能、位置和设备类型等识别每一类用户。
明确每一类型的用户的数量,以及他们使用软件的特点。
根据这些特点划分产品中定义的角色及其工作职责,填写在下表中,各种角色的具体行为将在功能性需求中描述。
软件产品用户的特征会影响特定的需求。
许多人在软件生命周期的运行和维护阶段使用软件。
这些人是用户、操作员、系统维护人员。
这些人的某些特点,如教育水平,经验和技术专长,可能成为软件的运行环境的重要制约因素。
角色名称
职责描述
系统管理员
由程序内部人员担任,负责系统配置,维护,备份及恢复,以及任务管理。
普通玩家
所有玩家,负责玩游戏。
1.4运行环境
提示:
描述软硬件运行环境。
包括硬件平台、操作系统和版本,以及用户、服务器和数据库的地理位置。
列出系统必须和平共存的其他软件组件或应用程序,前景和范围文档中可能包含这样的高层信息。
需求名称
详细要求
硬件
软件
WINDOW7操作系统以上
…
1.5假设、依赖和约束
提示:
列举软件产品的假设、依赖和约束。
但不是每个产品都同时具备这三个条件。
假设描述那些影响在软件需求说明书描述的需求的假设。
假设是那些在项目的生命周期中被认为是真的因素,如果这种假设改变,会对项目产生负面的影响,包括但不限于最终用户的特点,已知的技术基础设施,资源可用性和资金可用性等。
依赖描述那些影响在软件需求说明书中描述的需求的依赖。
依赖是指在项目的范围和控制之外,并且为了项目取得成功而必须为真的情况。
举例来说,一个依赖可能是一个应用程序依赖于一个不同的应用提供具体的数据或者是一个与第三方应用程序的接口需要购买一个应用程序编程接口(API)。
约束提供各种限制软件的范围和功能的因素的描述,包括但不限于行业标准与规范,业务规则,监管政策,基础设施的限制,资源和许可。
约束是通过环境、权利或强制规定施加到解决方案上的限制。
约束通过无法改变的边界及限制,制约了解决方案的设计师可供选择的方案。
2.产品的功能性需求
2.1整体业务流程图/用例图
提示:
以结构化或面向对象的方法绘制出产品整体业务的流程图或用例图。
2.2功能性需求分类
提示:
将功能性需求先粗分再细分,下表中的功能A,功能A.1等符号应当被替换成有含义的名称。
功能类别
子功能
功能类别A
功能A.1
功能A.2
…
功能类别B
功能B.1
功能B.2
…
…
2.3功能类别A
提示:
功能类别的名称与分类表中类别名称应保持一致,它是几个子功能总括名称,形如“采购管理”、“私信系统”。
以下提供了每种描述功能需求的子功能的模板。
2.3.xf功能X
提示:
当采用功能分解的方式描述功能性需求的时候,可按照2.3.xf的模板描述所有的子功能。
需要按照具体的功能标识及命名每一个功能,其中xf是子功能序号,X是功能的名称。
2.3.xf.1描述和优先级
提示:
描述功能,并指出该功能的优先级。
2.3.xf.2输入
提示:
描述功能输入。
2.3.xf.3操作
提示:
描述在功能中执行的操作。
2.3.xf.4输出
提示:
描述功能的输出
2.3.xu用例Y
提示:
当采用用例的方式描述功能性需求时,使用2.3.xu为模板描述每个用例,按照每一个具体的用例标识以及命名每个用例,其中xu是子功能序号,Y是指定用例的名字。
在每个用例子功能中,指定用例信息,包括角色,前置条件,后置条件,操作流程和替代流程等。
用例名称
进入游戏
用例编号
Tcs-001
用例简介
打开程序,进入游戏
优先级
前置条件
打开贪吃蛇程序
后置条件
游戏开始,蛇开始移动
操作流程
步骤
触发者
描述
1
玩家
双击贪吃蛇程序,打开游戏界面
点击选项中的开始或者按下S快捷键
游戏开始,目标移动
扩展流程
例外流程
包含
假设
约束条件
输入及约束
用例名称
玩游戏
用例编号
Tcs-002
用例简介
进入游并开始游戏
优先级
前置条件
打开贪吃蛇程序
后置条件
操作流程
步骤
触发者
描述
1
玩家
玩家通过键盘上下左右键来控制蛇的移动,蛇会做出相应的反应。
蛇吃到食物:
蛇身变长一个,分数加10,速度速度加5。
所按键方向与蛇的移动方向相反,命令无效。
蛇死亡:
蛇与自身相撞或者蛇与墙相撞。
扩展流程
游戏期间可直接关闭游戏
例外流程
包含
假设
约束条件
输入及约束
用例名称
退出游戏
用例编号
Tcs-003
用例简介
优先级
前置条件
游戏正在进行
后置条件
操作流程
步骤
触发者
描述
1
扩展流程
例外流程
包含
假设
约束条件
输入及约束
2.4功能类别B
……
3.产品的非功能性需求
3.1用户界面需求
提示:
描述软件的用户界面需求。
用户界面需求用于捕获应用程序的人机界面的预期行为。
例如,如果用户通过显示终端操作,说明所需的屏幕内容,任何报告或菜单的内容,输入和输出的相对时间。
用户需求可能包括示例的屏幕或报表格式为原型来进行需求的说明。
需求名称
详细要求
…
3.2性能需求
提示:
描述性能条件以及相关的能力。
考虑因素包括:
l发生的动态行为或变化(如比率,速率,运动和噪声水平)
l涵盖设备的承受能力的量化标准,用于在规定的环境和其他条件下满足用户的需求,包括最低总寿命。
说明了需要的持续运行时间以及计划的可用率。
l运行的阶段和模式的性能需求
l支持的终端数量
l支持的并发用户数量
l在正常以及峰值负载的条件下,特定时间内可以处理的事务和任务以及数据量
l在非正常的工作压力下可接受的性能
3.3产品质量需求
提示:
描述软件的质量特性的需求。
需求的描述应该是可度量、可验证的。
描述在特性之间(比如安全性和可移植性)之间的权衡关系。
质量特性的定义包括正确性、有效性、灵活性、完整性/安全、互操作性、可维护性、可移植性、可靠性、可重用性、可测试性、易用性。
主要质量属性
详细要求
正确性
健壮性
可靠性
性能,效率
易用性
清晰性
安全性
可扩展性
兼容性
可移植性
…
3.4其他需求
提示:
描述不适合放在前面需求章节中的任何其他的需求。
如有些软件系统比较强调信息管理需求、安全需求,也可以在此扩展。
4.接口
提示:
描述应用和其他软件、硬件以及通信协议之间的接口的逻辑特性。
每个接口的描述包括:
l该接口的目的
l应用接口对应的系统,包括外部的或内部的
l交换机制
附录A:
需求建模与分析报告
建议用RationalRose对产品需求进行建模与分析。
A.1需求模型1
A.n需求模型N
附录B:
需求跟踪矩阵
提示:
提供指向需求跟踪矩阵的链接,需求跟踪矩阵中说明了在系统需求规格说明中的系统需求、在本软件需求规格说明书中的软件需求以及系统设计中的设计元素之间的对应关系。
SRS中的需求跟踪矩阵应该:
l含有用来说明系统需求与系统设计、软件需求、软件设计等元素之间的可追溯性的列
l含有用来说明集成、验收、回归、性能测试等的可追溯性的列
l填入了所有记录在系统需求规格说明中的需求
l填入了所有记录在系统设计中的设计项
l填入了所有记录在需求规格说明书中的需求项
l说明了系统规格说明书中的系统需求与系统设计中的设计项之间的对应关系
l说明了系统设计中的设计项与需求规格说明中的需求的对应关系
l说明了每一个需求的出处及来源
附录C:
需求确认
提示:
主要分两步:
(1)需求评审,
(2)需求承诺。
对需求的评审应当采用“正式技术评审方式”,将产生一份“需求评审报告”。
在获取责任人(Stakeholders)对需求的承诺之前,该《产品需求规格说明书》必须先通过需求评审。
需求评审报告摘要
需求文档
输入名称,标识符,版本,作者,完成日期,…
需求评审报告
输入名称,标识符,评审日期,…
评审结论
[]工作成果合格,“无需修改”或者“需要轻微修改但不必再审核”。
[√]工作成果基本合格,需要作少量的修改,之后通过审核即可。
[]工作成果不合格,需要作比较大的修改,之后必须重新对其评审。
评审意见
评审小组成员
输入评审小组成员
需求承诺
需求文档
输入名称,标识符,版本,作者,完成日期
客户承诺
承诺…
签字,日期
项目经理承诺
承诺…
签字,日期
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 规格 说明书 模板
![提示](https://static.bdocx.com/images/bang_tan.gif)