软件需求规格说明书格式规范.docx

软件需求规格说明书格式规范.docx

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

软件需求规格说明书格式规范

文档状态：

文档编号：

[]Draft

[√]Released

[]Modifying

编撰：

编撰日期：

保密级别：

文档版本：

1.0.0

项目名称

（TheEnglishName）

软件需求规格说明书

XXX项目小组

修订表

编号

生成版本

修订人

修订章节与内容

修订日期

1

2

3

4

5

审批记录

版本

审批人

审批意见

审批日期

1.0.0

1.引言

1.1目的

【说明编写这份软件需求说明书的目的，小组长、项目负责人和其他各部门领导及用户是文档的预期读者。

明确系统范围、系统与其他系统的接口问题、及用户的各种功能、界面等需求。

由预期读者签字确认，审核人中应该包括用户部门领导。

】

1.2适用范围

【说明：

a.待开发的软件系统的名称；

b.说明软件将干什么，如果需要的话，还要说明软件产品不干什么；

c.说明软件与其他系统的接口，本系统要完成什么，不完成什么，要实现的系统功能，需要其他系统提供什么，本系统需要为其他系统提供什么。

】

1.3参考资料

资料名称[标识符]

出版单位

作者

日期

1.4术语和缩略语

术语、缩略语

解释

2.系统概述

2.1产品描述

【叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。

解释被开发软件与其他有关软件之间的关系。

如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。

如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张结构图来说明该系统的组成和本产品同其他各部分的联系和接口。

】

注：

结构图是用来描述系统的总体结构以及系统内部个部分之间的联系，它以树型结构来表示。

例如：

2.2产品功能

【本条是为将要完成的软件功能提供一个摘要。

有时，如果存在较高层次的规格说明时，则功能摘要可从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，可以使用以下任意一种方法来进行说明：

a.编制功能的一种方法是制作功能表，以便客户或者第一次读这个文件的人都可以理解；

b.用方框图来表达不同的功能和它们的关系也是有帮助的。

但应牢记这样的图不是产品设计时所需求的，而只是一种有效的解释性的工具。

】

2.3一般约束

【本条对设计系统时限制开发者选择的其他一些项作一般性描述。

而这些项将限定开发者在设计系统时的任选项。

这些包括：

a．管理方针；

b．硬件的限制；

c．并行操作；

d．通信协议；

安全和保密方面的考虑。

】

3.功能性需求分类

功能性需求分类方法：

【数据流程分析：

数据流程分析主要包括对信息的流动，变换，存贮等的分析。

其目的是尽量发现数据流动中存在的问题，并找出加以解决的方法，优化数据流程。

数据流程图是一种全面的描述系统数据流程的主要工具，他是一组符号来描述整个系统中信息的全貌，综合地反映信息在系统中的流动，处理和存贮情况。

绘制数据流程图常用的以下符号：

外部实体，本系统或子系统以外的人或单位

数据流，一组确定的数据组成

处理过程，表示对数据的加工处理，把它输入的数据流转化为输出的数据流

结构存储，是数据的仓库，表示系统产生的数据存放的地方

例如：

】

【UML的模型图UML的模型图能够将被建模的系统的某一个方面的某一部分以图形的方式表示出来，不同的视图通过将多个不同的模型图有机组合在一起就能够描述系统模型的某方面的特征。

UML的模型图是有模型元素构成的，模型元素以图标的形式直观形象的表达各种概念。

有的模型元素可以在多个模型图中使用，如注释和注释连接可以在任何模型图中使用，用于给其他的模型元素进行注释。

各种模型图能使用的模型元素集合也不相同，在介绍各种模型图的时候会有具体的说明。

UML定义了九种模型图：

用例图（UseCaseView）、类图（ClassDiagram）、对象图（ObjectDiagram）、构件图（ComponentDiagram）、部署图（DeploymentDiagram）、状态图（StateChartDiagram）、活动图（ActivityDiagram）、序列图（SequenceDiagram）以及协作图（CollaborationDiagram）。

例如：

用例图：

活动图：

状态图：

】

【E-R图是相对于概念模型而言的,在数据库中有严格的界定,是P.P.S.Chen于1976年提出的实体-联系方法（Entityt-RelationshipApproach）.该方法用E－R图来描述现实世界的概念模型．

E－R图提供了表示实体型\属性\和联系的方法;▲实体型:

用矩形表示.▲属性:

用椭圆形表示.▲联系:

用菱形表示.

例如：

】

其中用面向对象（用例图）和面向结构（数据流程图）这两种方法要根据项目自身特点，进行选择性地运用，是可选的。

3.1功能描述1

3.1.1具体功能1

【对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求，（根据需要，选择性的用数据流程图，实体图或UML模型图等来表示）。

】

【如果选用面向对象分析该功能时，要写明该功能模块的前置条件，模块中所参与的角色，用用例图对功能模块建模后，要有详细的用例描述话语。

】

3.1.2具体功能2

3.2功能描述2

……

4.产品的非功能性需求

4.1外部接口说明

4.1.1用户接口

【提供用户使用软件产品时的接口需求。

】

4.1.2软件接口

【在此要指定需使用的其他软件产品，以及同其他应用系统之间的接口。

】

4.2性能需求

【从整体来说，本条应具体说明软件、或人与软件交互的静态或动态数值需求。

a.静态数值需求可能包括：

1）支持的终端数；

2）支持并行操作的用户数；

3）系统响应的时间特性；

b.动态数值需求可能包括：

欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。

】

4.2.1硬件的限制

【本项包括在各种硬件约束下运行的软件要求，例如，应该包括：

a.硬件配置的特点（接口数，指令系统等）；

b.内存储器和辅助存储器的容量。

】

4.3属性

【在软件的需求之中有若干个属性，以下指出其中的几个】

4.3.1友好性

【指的是用户对界面的要求，程序界面友好度，可操作性等友好性信息】

4.3.2安全性

【指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。

这个领域的具体需求必须包括：

a.利用可靠的密码技术；

b.掌握特定的记录或历史数据集；

c.给不同的模块分配不同的功能；

d.计算临界值的检查。

】

4.3.3可维护性

【规定若干需求以确保软件是可维护的。

】

4.3.4可转移/换性

【利用开发平台提供的数据转换功能，可以实现跨平台数据转换，实现不同数据库数据间的数据转换，如：

FoxPro、Access、MicrosoftSQLServer间的数据转换。

】

4.4系统的运行环境

【系统的起始运行时间，结束运行时间，运行的时限，运行的周期等。

】

4.5其他需求

4.5.1用户操作需求

【这里说明用户要求的常规的和特殊的操作。

a.在用户组织之中各种方式的操作。

例如，用户初始化操作；

b.数据处理运行功能；

c.后援和恢复操作。

】

5.E-R图和数据字典抽取

5.1E-R图

根据以上的分析，把在整个系统过程中出现的实体及各个实体之间的关联画成E-R图，以更好的从整体角度了解系统中所有的实体。

比如：

5.2数据字典

对系统中出现的各个实体的属性进行整理，形成数据字典，此可以做为后继开发过程中数据结构设计、数据库设计、数据库表结构设计的主要来源。

格式如下例所示：

5.2.1员工基本信息

属性

约束

释义

备注

员工编号

必填

员工在公司的工作编号，唯一标识

姓名

必填

性别

必填

出生年月

必填

身份证号码

必填

籍贯

必填

联系电话

必填

家庭住址

联系地址

必填

所在部门编号

必填

参照部门表

从事岗位（职位）

密码

必填

默认密码

用户角色

必填

参照角色表

操作员分类

必填

1.员工2部门3主管4外部员工（客户或其他）

附录A：

需求确认

需求评审报告摘要

需求文档

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

需求评审报告

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

评审结论

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

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

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

评审意见

评审小组成员

输入评审小组成员