软件需求规格说明书模板.docx
- 文档编号:29375640
- 上传时间:2023-07-22
- 格式:DOCX
- 页数:13
- 大小:21.44KB
软件需求规格说明书模板.docx
《软件需求规格说明书模板.docx》由会员分享,可在线阅读,更多相关《软件需求规格说明书模板.docx(13页珍藏版)》请在冰豆网上搜索。
软件需求规格说明书模板
[项目名称]
软件需求规格说明书
CORNER-M2M-R0-002
版本:
1.0
发布时间:
2011-6-8
XXX公司
文件件变更记录
*A-增加*M-修改*D删除
变更版本号
日期
变更类型
(A*M*D)
修改人
变更摘要
审批人/日期
备注(原因、进一步的说明等)
[模板使用必读:
模板内容中[]包含内容为指导性的待替换文字,请在使用中替换为具体内容,或删除。
文件提交时不得再含有这些内容。
]
双方需求签字确认页:
XXXX项目需求分析说明书共页。
经双方共同探讨和研究,并广泛征求YYYY的意见,在深入调研和分析的基础上,形成了该需求规格说明书。
该需求规格说明书能够充分体现XXXX项目的整体要求,符合软件设计思想。
该需求规格说明书将作为双方进行XXXX项目软件开发的唯一基本准则,和唯一软件验收准则。
未经双方共同许可,任何一方不得擅自更改此需求规格说明书中任何内容。
如需特殊更改,经双方协商同意后,签署需求变更单,作为本需求规格说明书修改的依据。
根据签署过的需求变更单修改后的需求规格说明书将替代本需求规格说明书的作用。
本需求规格说明书一式两份,双方各持一份,在XXXX项目软件软件开发全部过程中具有相同的法律效力。
需求确认方:
需求提供方:
代表人:
代表人:
日期:
日期:
【根据实际情况进行裁剪】
目录
1.引言5
1.1目的5
1.2读者对象及阅读建议5
1.3文档范围5
1.4参考文档5
2.综合描述5
2.1产品目标和背景5
2.2外部接口需求5
2.2.1硬件接口5
2.2.2软件接口5
2.3功能清单及重要程度说明5
2.4用例模型6
3.数据模型6
3.1主要模块间的数据流图6
3.2主要业务实体关系图6
3.3数据字典6
3.4主要业务实体状态图6
4.功能性需求6
4.1功能XXX6
4.1.1功能描述6
4.1.2功能数据6
4.1.3功能操作6
4.1.4业务规则/算法6
4.1.5接口描述6
4.1.6特殊需求6
4.2用例XXX7
4.2.1简要说明7
4.2.2用例主角7
4.2.3前置条件7
4.2.4基本流7
4.2.5备选流7
4.2.6特殊需求8
4.2.7后置条件8
4.2.8扩展点8
4.2.9补充说明8
5.非功能性需求8
5.1设计约束8
5.2性能需求8
5.2.1产品速度要求8
5.2.2数据处理能力要求8
5.2.3可用性9
5.2.4可靠性9
5.3安全性需求9
5.4需要符合法规、标准和制度9
5.5用户文档需求9
6.待确定问题列表9
7.词汇表9
1.引言
1.1目的
[说明:
本文档的目标和范围,在项目中的作用等。
]
1.2读者对象及阅读建议
[说明:
指明本文档面向的读者群,及相应的阅读意见。
]
1.3文档范围
[说明:
对本文的范围做阐述,本文档改动时,受到影响的范围。
]
1.4参考文档
[说明:
列出本文档的所有参考文献(可以是非正式出版物),包括计划任务书、合同、批文、引用到的文件、资料及软件开发标准等。
]
2.综合描述
2.1产品目标和背景
[说明:
1、准确定义开发产品的根本原因,即产品所要解决的用户业务问题。
2、产品所要达到的目标。
3、必要时,介绍产品的开发背景、商机]
2.2外部接口需求
[提供包含产品在内的、未来系统的整体软硬件拓扑图]
2.2.1硬件接口
[可裁剪]
[说明:
要指出软件产品和产品硬部件之间每一个接口的逻辑特点。
还可能包括如下事宜:
支撑什么样的设备,如何支撑这些设备,有何约定。
]
2.2.2软件接口
[可裁剪]
[说明:
在此要指定需使用的其他软件产品(例如,数据库系统、操作系统或中间件),及其接口。
对于每一个接口软件,应说明接口的目的,并根据信息的内容和格式定义接口。
]
2.3功能清单及重要程度说明
[用于使用功能点法来描述需求的项目,是产品菜单划分的基础]
[说明:
功能名称、功能描述、重要程度。
重要程度,以ABC三类来表示:
A:
核心功能;B:
辅助功能;C:
外围功能]
编号
功能(类)名称
功能描述
重要程度
1
1.1
1.2
2
2.1
2.2
2.4用例模型
[可裁剪。
用于使用用例来描述需求的项目]
[说明:
列举所有的主角、用例和它们之间的关系,可用用例图来表示]
3.数据模型
3.1主要模块间的数据流图
3.2主要业务实体关系图
3.3数据字典
[可裁剪。
把相关的数据抽取出来统一维护,在其他章节如有类似信息描述,则关联到数据字典的相关部分并加辅助说明,如:
引用到的字段等。
]
3.4主要业务实体状态图
[可裁剪。
用于说明在业务实体的生命周期内,产品功能对业务实体状态的影响。
是列举对业务实体有影响的功能]
4.功能性需求
4.1功能XXX
[可裁剪,用于使用功能点法来描述需求的项目]
4.1.1功能描述
4.1.2功能数据
[是对功能所能影响的业务实体列举]
4.1.2.1YYY表格
[可裁剪。
和数据模型中数据字典二者取一]
字段名称
类型
宽度
取值范围
来源
缺省值
空否
字符
输入
否
数字
参照
是
时间
自动
否
4.1.3功能操作
•操作1:
•操作2:
4.1.4业务规则/算法
•规则1:
•规则2:
4.1.5接口描述
[可裁剪,为其他功能提供接口的规格]
4.1.6特殊需求
[可裁剪,特殊需求为一个功能所专有的非功能性需求]
4.2用例XXX
[可裁剪,用于使用用例来描述需求的项目]
4.2.1简要说明
[说明中应简要表述用例的作用和目的。
一个段落即足以作此说明。
]
4.2.2用例主角
4.2.3前置条件
[用例的前置条件是执行用例之前必须存在的产品状态。
]
4.2.4基本流
[当主角有所行动时,此用例随即开始。
总是由主角来带动用例。
用例应说明主角的行为及系统的响应。
应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件,而不是事件发生的方式和原因。
如果进行了信息交换,则需指出来回传递的具体信息。
例如,只表述主角输入了客户信息就不够明确。
最好明确地说主角输入了客户姓名和地址。
通常可以利用数据模型让用例的复杂性保持在可控范围内-您最好在数据模型中定义客户信息等内容,使用例不至于陷入过多的细节。
简单的备选流可以在用例文本中提供。
如果只需几句话就可说明存在备选流时将发生的事件,则可以直接在事件流一节中说明。
如果备选流较为复杂,则需要用另外一节来单独说明。
例如,备选流小节解释如何说明较复杂的备选流。
虽然清晰明了的叙述性文字是无可替代的,但有时一幅图要比千言短文更具说明性。
只要表达得简洁明了,您就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其他图形。
如果流程图有助于描述复杂的决策流程,那么一定要充分利用它!
同样,对于与状态相关的行为,状态转移图通常比数页文字更能清晰地描述系统的行为。
根据问题来选用妥当的表示方法,但应慎用您的读者可能不太明了的术语、符号或图形。
请切记,您的目的是要阐明问题,而不是混淆问题。
]
<基本流1>
4.2.5备选流
4.2.5.1<第一备选流>
[较复杂的备选流应单独说明,这已在事件流一节的基本流小节中提及。
将备选流小节当作备选行为-在许多情况下,是由于主事件流中发生异常事件,这时每个备选流都可代表备选行为。
这些备选流的长度可以是说明与备选行为相关的事件所需的长度。
当备选流结束时,除非另外说明,主事件流的事件将重新开始。
]
<备选支流>
[如果能使表达更明确,备选流又可再分为多个支流。
]
4.2.5.2<第二备选流>
[在一个用例中很可能会有多个备选流。
为了使表达更清晰,应将各个备选流分开说明。
使用备选流可以提高用例的可读性,并防止将用例分解为过多的层次。
应切记,用例只是文本说明,其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。
]
4.2.6特殊需求
[特殊需求通常是非功能性需求,它为一个用例所专有,但很难或很自然的在用例的事件流文本中表述。
]
<第一特殊需求>
4.2.7后置条件
[用例的后置条件是用例一执行完毕产品可能处于的一组状态。
]
<后置条件一>
4.2.8扩展点
[简要描述本用例事件流中可能被扩展的位置与条件]
4.2.9补充说明
[补充说明主要描述本用例设计的业务实体和业务规则。
每个业务实体应该有明确的、唯一的名称,可以在用例中直接引用,也可以在数据模型中说明每条业务规则应该明确编号。
一组相关用例(属于一个用例范围,具体说他们共享一些业务对象和业务规则)的业务对象和业务规则应该单独放在一起,进行编号,被这些用例引用。
]
<业务实体1>
<业务规则1>
5.非功能性需求
5.1设计约束
[说明:
产品所必需采用的技术、工具和第三方产品等。
]
5.2性能需求
5.2.1产品速度要求
[说明:
对于该软件的时间特性要求,如对:
a.响应时间;b.更新处理时间;c.数据转换和传送时间;d.计算时间等要求。
]
描述:
验收标准:
[说明:
对于每一个非功能性需求,都需要一个验收标准。
验收标准是对需求的量化,它使开发人员可以测试产品是否精确地实现了需求。
对于在描述中未使用定量描述的需求,验收标准可消除其中隐藏的二义性,因此,对于此类需求,必须确定验收标准。
比如:
描述:
产品要在用户感到不耐烦前给出查询结果。
验收标准:
产品在3秒钟内给出结果。
描述:
产品的操作易于学习。
验收标准:
用户代表小组中的80%以上的人能在第一次使用时成功地输入一张完整的单据]
5.2.2数据处理能力要求
5.2.2.1静态处理
[说明:
支持的终端数;支持并行操作的用户数;]
描述:
验收标准:
5.2.2.2动态处理
[说明:
欲处理的事务和任务的数量,以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。
]
描述:
验收标准:
5.2.2.3数据精度
[说明:
对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
]
描述:
验收标准:
5.2.2.4容量要求
[可裁剪]
[说明:
需要管理的文件和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求做出估算。
]
描述:
验收标准:
5.2.3可用性
[指出普通用户和高级用户要高效地执行特定操作所需的培训时间,指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可用性需求]
描述:
验收标准:
5.2.4可靠性
[指出可用时间百分比(xx.xx%)、使用小时数、维护访问权、降级模式操作等。
平均故障间隔时间(MTBF)。
平均修复时间(MTTR)—产品在发生故障后可以暂停运行的时间。
指出产品输出要求具备的精密度(分辨率)和精确度(按照某一已知的标准)。
]
描述:
验收标准:
5.3安全性需求
[说明如何保护软件和数据,以防止偶然或恶意的访问、使用、修改、破坏或泄密。
]
描述:
验收标准:
5.4需要符合法规、标准和制度
[可裁剪]
描述:
验收标准:
5.5用户文档需求
[说明:
主要是在线用户手册与帮助系统,也包括其他的文档]
6.待确定问题列表
[可裁剪]
序号
问题说明
提出人
提出时间
备注
1
2
3
7.词汇表
词汇表的初衷是统一项目干系人对同一件事物的理解,尽量避免沟通中的一些不必要的误解。
●做为词汇表,要尽量沿用用户约定俗成的叫法和说法。
●如果两个或两个以上的词汇是同义的,尽量把它们放在一起,在项目文档中使用其中一个更通用的词汇,另外一个废止。
●在下一步分析和设计的过程中,这里收录的词汇表会沿用下去,并加入各阶段需要的词汇。
[词汇可以按照业务模块分类]
<类别1:
>
词汇
解释说明
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 规格 说明书 模板
![提示](https://static.bdocx.com/images/bang_tan.gif)