精校版软件需求规格说明书模板.docx

精校版软件需求规格说明书模板.docx

《精校版软件需求规格说明书模板.docx》由会员分享，可在线阅读，更多相关《精校版软件需求规格说明书模板.docx（10页珍藏版）》请在冰豆网上搜索。

精校版软件需求规格说明书模板

完整word版,软件需求规格说明书模板

编辑整理：

尊敬的读者朋友们：

这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望（完整word版,软件需求规格说明书模板）的内容能够给您的工作和学习带来便利。

同时也真诚的希望收到您的建议和反馈，这将是我们进步的源泉，前进的动力。

本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快业绩进步，以下为完整word版,软件需求规格说明书模板的全部内容。

文档编号：

项目编号_过程域_文件名简称

【项目名称】

软件需求规格说明书

文档版本号：

文档编号：

文档密级：

归属部门/项目：

编写人：

生效日期：

版权信息

本文件涉及之信息,属xxxxxxxxxxxxxxxxxx所有。

未经xxxxxxxxx公司允许，文件中的任何部分都不能以任何形式向第三方散发.

网址：

文档修订记录

版本号

修订日期

修订人

修订说明

修订状态

审核日期

审核人

批准人

V0.1

V1.0

修订状态:

A-—增加，M-—修改，D——删除

日期格式：

YYYY-MM-DD

1.前言

1.1.目的

说明编写这份软件需求规格说明书的目的，如:

通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。

1.2.背景

描述系统产生的背景，包括：

a.需开发的软件系统的名称,和英文缩写（可选）,项目编号（可选）；

b.列出此项目的任务提出者、开发者；

c.软件系统应用范围、用户;

d.还可包括:

（1）项目的委托单位，开发单位和主管部门;

（2）该软件系统与其他系统的关系

e。

产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性

1.3.术语与缩写解释

列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。

也可用附件说明.或放到本文件的最后。

1.4.预期读者与阅读建议

描述本文档的主要读者,以及这些读者在阅读时的阅读重点与建议.可用列表的方式列出。

如：

预期读者

阅读建议

领导层

仔细阅读概述，编写目的,文档约定，系统功能介绍和维度指标说明。

公司的业务部门、决策部门、具体的使用部门、业务员、系统管理员

仔细阅读文档约定,系统功能介绍和维度指标说明。

各个部门可重点阅读与本部门相关的内容。

参加需求评审的人员

仔细阅读全部内容。

系统设计人员

仔细阅读全部内容.

系统测试人员

仔细阅读文档约定，系统功能介绍和维度指标说明。

……

……

1.5.参考资料

列出有关的参考资料，如：

a.本项目经核准的计划任务书或合同、上级机关的批文;

b.属于本项目的其他已发表的文件；

c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准.

d.行业标准和规范。

列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料来源.

文档名

版本号

发表日期

来源

文档简称

1.6.需求描述约定

在此说明本文描述需求的约定。

这些约定可以包括：

●需求标识方法，如序列化编号、层次化编号、层次化文本标签等方法。

应确保需求标识在整个项目中的唯一性，且不受需求变更的影响，不得使用WORD自带的序列号作为需求标识

●需求的跟踪颗粒度

●优先级与重要性（本文档中设定的级别，及其含义）

●功能描述的方法。

（若引用了参考资料,应指明参考资料的简称与章节号或页码，以便复核与评审。

）

●界面描述规则，如：

用图形描绘DEMO界面

等等

根据不同类型、不同规模的项目，项目组可以做出增减。

以一个大项目举例如下：

１）本系统的需求标识方法：

层次化编号方法

模块缩写＋序列号，如SZAG01、SZAG01。

01、SZAG01。

01。

02

模块缩写参照表:

模块名

模块缩写

模块名

模块缩写

深圳A股

SZAG

上海A股

SHAG

深圳B股

SZBG

上海B股

SHBG

电子划拨

DZHB

资金清算

ZJQS

　　需求层次:

分三个层次，用三位字符表示.第一层需求指主功能模块，第二层需求指功能模块的主功能点，第三层次指主功能点下的具体需求。

２）本系统的需求跟踪粒度

跟踪到第二层功能需求。

３）本文档的需求级别定义:

●本文档统一规定对需求层次为二级以上（功能模板、主功能点）的定义优先级，三层需求依据二层需求的优先级执行.

●本文档的优先级别分为：

高、中、低

●同时对于主功能点还描述实现的周期：

一期、二期、三期

４）功能描述方法：

本文档从以下几个方面对功能需求进行描述：

a.业务定义/描述。

b.适用的用户类型

c.业务规则/业务要素.

d.输入:

提供所有与本功能有关的输入描述,包括：

输入数据类型、媒体、格式、数值范围、精度、单位等。

e.输出－提供与本功能有关所有输出的描述，包括：

输出数据类型、方式、格式、精度、单位等,以及图形或显示报告的描述.

f.业务操作流程

g.描述正常业务流程，列举异常情况和处理流程。

建议使用UML图示，并配合必要的文字说明

h.约束条件/特殊考虑

列出在各个工作领域不需计算机化的功能并提供其原因以及特殊条件。

５）界面描述规则

　　界面描述可使用VISIO的界面模型进行描述。

2.项目概貌

2.1.系统范围

2.2.系统功能

　　概述了产品所具有的主要功能,确定系统边界、范围。

其详细内容将在系统功能需求和特性中描述，所以在此只需要概略地总结。

很好地组织产品的功能，使每个读者都易于理解。

a.建议以图表形式列出功能结构图,并加入必要文字说明。

b.建议以列表形式列出功能分类，以及优先级，并加入必要文字说明.

2.3.业务详述

用文字或图形方式描述系统的主要业务流程，若引用了参考资料,应指明参考资料的简称与章节号或页码，以便复核与评审。

2.4.数据流程描述（可选）

用文字或图形方式描述系统的数据流程，若引用了参考资料，应指明参考资料的简称与章节号或页码,以便复核与评审。

2.5.用户的特点

列出本软件的最终用户的特点，以及本软件的预期使用频度，确定可能使用该产品的不同用户类并描述它们相关的特征。

有一些需求可能只与特定的用户类相关。

一般来说至少有以下几类:

一般操作者：

系统管理者：

最终用户

2.6.运行环境要求

描述了软件的运行环境，包括硬件平台、操作系统和版本,还有其它的软件组件或与其共存的应用程序。

2.7.设计和实现上的限制

列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）.这可能包括你打算要用的商业组件或有关开发或运行环境的问题对需求实现的影响，也可能是需求或业务规则对设计与实现方法的影响。

可能还来自于经费、投资方面的限制,法律或政策方面的限制，或者可利用的资源和信息的限制。

3.功能列表

罗列本需求中的功能点、需求编号、需求内容、优先级与内容描述。

必要时独立成立做为本需求的附件。

功能点

子功能

需求编号

优先级

内容描述

4.非功能需求

4.1.　系统性能要求

a。

时间特性

说明对于该软件的时间特性要求，时间测量单位的选择：

●高峰期的环境假设、负载假设；

●高峰期的处理时间.

b.精度要求

说明对该软件的输入、输出数据精度的要求。

c。

系统可靠性

为取得系统可靠性，应考虑标准工作日、周末和公共假期的操作时间。

例如：

系统每天需要连续运行24小时,每周运行七天，包括公共假期和周末

d.容错性

e.可扩充性

4.2.　系统界面要求

说明对于该软件的界面要求，如屏幕格式、报表格式、菜单格式、界面布局、风格多样性、输入输出时间等,如界面是否友好、易用、用户视觉效果良好等。

4.3.　系统安全及保密要求

指定可以访问各自功能的用户群，如需要可指定用户访问权和安全包（如有），以便有效控制系统访问和数据访问。

确认审核记录和所有有关报告及接受人。

阐述是否任何违反系统访问的内容都需要监控,以及以什么方式监控。

列明所有安全需求，例如数据加密，信息验证等。

4.4.　系统备份与恢复要求

a.指定每种信息类型的保存期；

b.阐述在保存期过后需要实施的行为，例如：

转移到计算机外部的介质中,或删除它们。

c.如转移到计算机外的介质中，叙述存储期及贮存介质的类型.例如：

磁带、磁盘、报告等。

d.环境异常时，系统恢复策略描述。

4.5.　系统日志

a.日志内容、记录策略

b.日志的保存时长、保存策略

c.日志内容的访问控制

4.6.　其他非功能需求（可选）

可采用列表的形式详细描述,如：

其他非功能需求

详细要求

正确性

健壮性

可靠性

性能,效率

易用性

清晰性

可扩展性

兼容性

可移植性

…

5.外部接口说明

外部接口包括:

硬件接口、软件接口、通信接口,每个接口需考虑以下内容:

a.接口描述，包括接口类型、接口特点（如版本、名称、来源等）

b.接口与本系系统的输入输出关系

c.技术方面的约束

d.转换的安全考虑

6.其他需求

[对其它需要描述但未在本模板中列出的需求，在此进行说明，如果某个这样的需求比较重要,可以单独用新的一节来描述。

这样的需求可能包括,数据库需求、法律需求、国际准则、重用目标等。

]

7.功能需求的详述

为每个确定的商业功能（需实现的功能）描述其定义、业务规则，详细叙述如何从输入转变到输出并且如何获得、处理和产生这些信息。

这些内容在下列标题中有条理的阐述。

a.业务定义/描述。

b.适用的用户类型，指操作本功能所需的授权

c.业务规则/业务要素。

d.输入：

提供所有与本功能有关的输入描述，包括：

输入数据类型、媒体、格式、数值范围、精度、单位等.

e.输出－提供与本功能有关所有输出的描述，包括：

输出数据类型、方式、格式、精度、单位等，以及图形或显示报告的描述。

f.业务操作流程

描述正常业务流程，列举异常情况和处理流程。

建议使用图示,并配合必要的文字说明

g.约束条件/特殊考虑

列出在各个工作领域不需计算机化的功能并提供其原因以及特殊条件.

h.可运用UML系统用例视图进行整体功能描述；

i.用例图表描述或者描述文字单一功能。

8.附件（可选）

附件可能包括各个模块的具体的功能需求描述、需求跟踪表,或者系统的词汇表、待确定问题列表，以及其它所有能够成为需求基线内容的正式文档。

附录A:

需求建模与分析报告（可选）

建议用RationalRose对产品需求进行建模与分析。

A。

1需求模型1

A.n需求模型N

附录B：

需求确认（可选）

提示:

需求确认规程请参见XXXX_RD_REGU_XQKFYGLGC，主要分两步：

（1）需求评审，

（2）需求承诺。

对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告",规程请参见XXXX_RD_REGU_XQKFYGLGC。

在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。

需求评审报告摘要

需求文档

输入名称，标识符,版本，作者,完成日期，…

需求评审报告

输入名称，标识符，评审日期，…

评审结论

［］工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。

［√］工作成果基本合格，需要作少量的修改，之后通过审核即可。

[]工作成果不合格，需要作比较大的修改,之后必须重新对其评审.

评审意见

评审小组成员

输入评审小组成员

需求承诺

需求文档

输入名称，标识符，版本，作者，完成日期

客户承诺

承诺…

签字，日期

项目经理承诺

承诺…

签字，日期