软件需求规格说明书.docx

软件需求规格说明书.docx

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

软件需求规格说明书

一．引言

[软件需求规格说明书记录对系统或系统的一部分的完整软件需求。

 以下

是一个典型的软件需求规格说明书概述，用于涉及用例建模的项目。

此工件由

一个包组成，该包包含用例模型的用例、非功能性需求、接口需求以及其他支

持信息。

本文档模板适合采用用例建模技术的项目需求描述。

]---- 在正式编

写文档时，请删除内容要求部分。

1.1 编写目的

本文档作为***与 XXXXXXXXXX 公司之间就***建立 XXXX 司（局或单位）论

坛系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同

的主要基础，也作为本项目验收的主要依据。

同时，本文档也作为***后继工作

开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等

理解需求之用。

1.2 适用范围

本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：

***

方面的项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人

员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读

本文档。

1.3 文档概述

本文档主要描述了论坛系统项目的软件需求。

本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次

从用户界面、软件接口等方面描述系统的外部接口需求，然后进一步详细描述

功能性需求和非功能性需求以及待确定的问题。

1.4 参考资料

[列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。

]

示范：

―――仅供参考，不具备任何实质性的内容。

《XXX 总体需求书》（XXX 单位 XXX 提供）

图符

名称

描述

UseCase

Use

Case

用于表示 Use-case 图中的 Use-Case，每个 Use

Case 用于表示所建模系统的一项外部功能需求，即

从用户的角度分析所得的需求。

Actor

Actor

用于描述与系统功能有关的外部实体，它可以是用

户，也可以是外部系统。

关联

用于连接 Actor 和 Use Case，表示该 Actor 所代表

的系统外部与该 Use Case 所描述的系统需求有关。

这也是 Actor 和 Use Case 之间唯一合法的连接。

<>

扩展

由 Use Case A 指向 Use Case B（被扩展），表示

Use Case B 描述了一项基本需求，而 Use Case A

则描述了该基本需求的特殊情况，即用例 A 扩展了

用例 B 的需求。

表 1-1  UML  V1.3  Use  Case 图符

《XXX 需求调研报告》作者：

XXX

《设计模式》XXXXX 出版社

1.5 术语、定义和缩写

[列出本文档所涉及的专业术语、缩写词及相关定义。

定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括

词头和缩写。

你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只

包括特定于单一项目的软件需求规格说明中的术语。

]

示范：

―――仅供参考，不具备任何实质性的内容。

1） OLTP：

On-line Transaction Processing，联机事务处理。

2） OLAP：

On-Line Analytical Processing，联机分析处理；是使分析人

员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地

存取,从而获得对数据的更深入了解的一类软件技术。

1.6 Use-Case 图形规范

[对文档中使用的 Use-Case 图的图符作简介，同时说明所应用 UML 规范的

版本，以便理解和统一。

如果使用的是 UML V1.3 标准规范，则可以直接将下列

内容作为文档内容。

]

一个 Use-Case 图显示的是 Actor 与 Use-Case 之间的某种关系。

表 1-1 列

出了本文档的 Use-Case 图中用到的图符、名称及其功能简介。

泛化

由 Use Case A（子用例）指向 Use Case B（父用

例），表示 Use Case A 继承了 Use Case B 的特性，

并增加了新的特性。

<>

包含

由 Use Case A 指向 Use Case B（被包含），表示

Use Case A 中包含了 Use Case B 中的行为或功能。

二．系统概述

2.1 业务背景

[概要描述本系统的业务背景和起源。

若用图表更能清楚描述业务背景，则

建议在用自然文字描述业务的同时，辅以图形、表格来更精确地描述业务。

]

示范：

―――仅供参考，不具备任何实质性的内容。

为切实推进国家助学贷款管理工作，落实《关于切实推进国家助学贷款工

作有关问题的通知》（银发[2002]38 号）、《关于下达 2002 年度国家助学贷

款指导性贷款计划的通知》（银发[2002]253 号）和《关于加强国家助学贷款

‘三考核’工作的通知》（银办发[2002]239 号）文件精神及肖钢副行长关于

在我司建立银行系统的助学贷款专项统计制度的批示，满足“要按月考核经办

银行国家助学贷款的申请人数和申请金额、考核已审批贷款人数和贷款合同金

额、考核实际发放贷款人数和发放金额。

”“按月编报分省‘四定’的国家助

学贷款进度明细表”和“增报《国家助学贷款‘三考核’指标分地区、分银行

统计表》”的工作要求，解决目前统计中存在的指标口径难于统一（银行与学

校、教育管理部门），数据采集不准、不细，校名不规范，手工统计劳动量大、

效率不高等问题。

满足对贷款学生基本信息、信用记录的查询；对学校进度明

细的统计；对分地区、分行别的汇总统计以及相关分析等新的管理需求，必须

有相应的计算机软件系统支持，以解决数据的采集录入、统计汇总、上报传输

的需要。

2.2 系统功能

[以图形、表格等形式简要说明本软件系统的主要功能，易于读者理解。

详

细内容将在第 4 部分说明。

对于采用传统方法分析系统需求，建议用 Visio 画

出整个系统的功能结构。

]

示范：

―――仅供参考，不具备任何实质性的内容。

Actor 名称

简要说明

权限

系统管理者

一般由总部 IT 人员来担任，用户数量比较少。

负责系

统的配置、备份与恢复，以及任务管理等工作。

全部权限

（读、写、

删除、创

建）

XXX 岗位

系统时钟

工作流引擎

下表是对上图关键用户角色（Actor）的简要说明：

银行业务通用网上统计暨助学贷款统计系统通过定制不同的业务类别，定

制统计业务的项目、指标及其汇总关系等，快速满足不同银行业务的统计要求，

形成从各级金融机构到***各分支机构，从下级机构到上级机构的业务定制、数

据采集、分析、统计和信息发布的统计体系。

主要任务和目标是：

遵循***统一

数据采集、统一信息发布建设原则，促进信息整合和应用整合。

作为“***信息

系统平台“的一部分，为“***信息系统平台”提供部分公用化模块组件，避免

业务模块的重复开发。

最终实现一个银行业务通用网上统计系统平台；并能方

便地定制新的统计业务，并能灵活适应业务发展需要。

利用银行业务通用网上

统计系统平台部署助学贷款专项网上统计系统，满足对国家助学贷款的“三考

核”要求，满足***全面掌握助学贷款业务信息的需要，并配合建立银行系统的

助学贷款专项统计制度。

助学贷款统计分析系统可为***全辖各机构和相关部门

提供统一的数据采集、分析、报表、信息发布等多方面的功能，并可为商业银

行、教育部门以及社会公众提供相关信息查询和统计分析结果。

并作为个人征

信系统初期应用模型，为促进个人征信系统打下基础。

系统功能关系图如下：

2.3 用户类别及特征

[确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。

有一些

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

提供参与系统的主角的名称列表及简要说明，

即简要描述系统所涉及的各角色及其职责。

]

示范：

―――仅供参考，不具备任何实质性的内容。

注：

应在上图位置给出使用本系统的客户组织的角色或岗位职责分配图以

代替上图。

2.4 用户文档

[列出所需的用户文档，例如：

用户手册，联机用户文档、联机帮助系统、

关于声明的帮助等的需求。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本软件应提供实时在线帮助（即联机帮助系统）、用户操作手册、系统管

理员手册、系统安装手册以及培训文档。

2.5 设计和实现上的限制

[确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。

描述在进行设计和实现时需要注意的问题，比如，必须使用或者避免的特定技

术、工具、编程语言和数据库；所要求的开发规范或标准；企业策略、政府法

规或工业标准；数据转换格式标准等等。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本系统应具备良好的可扩展性、复杂操作环境的可适应性、灵活可配置的

权限控制、大容量数据操作的快速响应及高可靠性以及与现有系统的兼容性，

同时，具备在线提醒和短信息提示，能够实现多种数据格式的转换，以多种图

形格式展示分析结果。

本系统应支持多级无限扩展应用，符合国际、国内标准规范，能够与其它

系统无缝衔接。

2.6 假设和依赖

[列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相

对立）。

这可能包括需求分析人员打算要用的商业组件或有关开发或运行环境

的问题。

需求分析人员可能认为产品将符合一个特殊的用户界面设计约定，但

是另一个 S R S 读者却可能不这样认为。

如果这些假设不正确、不一致或被更

改，就会使项目受到影响。

　　此外，确定项目对外部因素存在的依赖。

例如，如果你打算把其它项目开

发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。

如果这些依赖已经记录到其它文档（例如项目计划）中了，那么在此就可以参考

其它文档。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本系统需要集成其他软件开发商提供的组件或应用系统，假定需要集成的

组件能够按时提供并满足需求。

假定这些组件的运行环境与本系统运行环境不

发生冲突，能与本系统兼容。

另外，假定本文档所描述的软件需求均获得了项目双方所有客户的认可且

稳定不变。

如果项目后期，客户提出的需求变更超出了本需求规格范围，则将严重影

响本系统的设计、开发和程序的稳定。

在本软件需求规格说明书定版之后，客户需求发生了较大变更，变更后的

需求规格说明将不在本文档中补充，而以新的版本文档给出。

2.7 假设和依赖

[列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相

对立）。

这可能包括你打算要用的商业组件或有关开发或运行环境的问题。

你

可能认为产品将符合一个特殊的用户界面设计约定，但是另一个 S R S 读者却

可能不这样认为。

如果这些假设不正确、不一致或被更改，就会使项目受到影

响。

　　此外，确定项目对外部因素存在的依赖。

例如，如果你打算把其它项目开

发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。

如果这些依赖已经记录到其它文档（例如项目计划）中了，那么在此就可以参考

其它文档。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本系统需要集成其他软件开发商提供的组件或应用系统，假定需要集成的

组件能够按时提供并满足需求。

假定这些组件的运行环境与本系统运行环境不

发生冲突，能与本系统兼容。

另外，假定本文档所描述的软件需求均获得了项目双方所有客户的认可且

稳定不变。

如果项目后期，客户提出的需求变更超出了本需求规格范围，则将严重影

响本系统的设计、开发和程序的稳定。

在本软件需求规格说明书定版之后，客户需求发生了较大变更，变更后的

需求规格说明将不在本文档中补充，而以新的版本文档给出。

三．功能需求

LDAP-FI-101   登录       描述用户如何登录课程注册

LDAP-FI-102   查看成绩单 允许学生在学期结束前查看

[本章节主要提供详细的功能性需求描述。

对于采用结构化方法分析需求的

项目，应采用以下内容组织方式说明。

]

3.1 系统功能关系图

[以框图的形式表示新系统的各功能组之间的功能关系图，易于读者理解。

详细内容描述将在第 4.3 部分说明。

应分层次展示整个系统的功能，先从系统――>子系统――>模块逐层展示，

并说明各子系统和模块之间的功能关系。

同时，应注意与外部系统的接口。

]

示范：

―――仅供参考，不具备任何实质性的内容。

用户通过“系统登录/注销“子系统进入系统，从“用户和权限管理“子系

统获得相应的权限进行操作，用户从事业务定制、数据采集、统计分析、信息

发布/浏览、业务查询、用户和权限管理等其被授权的操作，“日志管理“子系

统进行登记。

用户从“帮助” 子系统获得帮助。

3.2 系统功能清单

[以表格的形式列出本软件系统所有的功能项清单，具体格式如下：

需求章节功能

级

系统高

成绩单高

LDAP-FI-104   选择讲授课

4.3 课程

注册管理8

LDAP-FI-103   注册课程

程

允许学生向课程目录中注册

课程，也包括更新、删除课

程等

允许教授在下学期到来之前，

从课程目录中选择符合自己

的课程

高

高

…………

…………

3.3<功能组 1>

3.3.1 功能简述

[简要描述本子系统的主要功能，并以功能关系图展示子系统。

]

示范：

―――仅供参考，不具备任何实质性的内容。

业务定制功能组将提供数据库结构定义、数据采集接口规范自定义以及基

础数据管理功能，具有灵活易用、功能强大的特点，是用户创建数据库资源并

对采集业务进行定制集成管理工具。

<功能组 1>各个功能项之间的关系如下图所示。

数据结构定制

基础数据管理

业务查询定义

数据库模型导入

数据采集接口规范定制

注：

建议对上图各功能项进行简要说明。

<功能组 1>与其它功能组之间的关系框图如下图所示：

业务定制

数据采集

统计分析

信息发布/浏览

业务查询

系统参数、数据接口规范、数据结构

系统参数、数据结构

系统参数、数据结构

系统参数

3.3.2 功能清单

[以表格的形式列出<功能组 1>中所有功能项，便于读者检索。

]

示范：

―――仅供参考，不具备任何实质性的内容。

功能编号

LDAP-FI-101

功能名称

登录系统

参与者

有权限的用户

优先级

高

简要描述

描述用户如何成功登录课程注册系统

执行条件

无

功能详细描述：

――详细描述该功能项所执行的操作及其响应

1. 系统请求该 actor 输入他或她的用户名和口令；

2. 该 actor 输入他或她的用户名和口令；

3. 系统验证该 actor 输入的用户名和口令，并将该 actor 登录信息记入系统

日志中。

异常响应描述：

――详细描述该功能项所执行的操作出现的异常响应

1. 无效用户名和或口令

如果该 actor 输入一个无效的用户名和或口令，系统应显示一个错误消息。

在每个功能需求的描述中必须包含以下内容，如表中所列：

LDAP-FI-103   注册课程    允许学生向课程目录中注册课程，也包括

功能项编号功能项名称功能简要描述优先级

LDAP-FI-101 登录描述用户如何登录课程注册系统高

LDAP-FI-102 查看成绩单允许学生在学期结束前查看成绩单高

更新、删除课程等高

LDAP-FI-104    选择讲授课

程

允许教授在下学期到来之前，从课程目录

中选择符合自己的课程                    高

…………中

3.3.3<登录系统>

[详细列出功能模块或功能单元的具体需求。

这些是必须提交给用户的软件

功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行

任务。

描述产品如何响应可预知的出错条件或者非法输入或动作。

必须唯一地

标识每个需求。

]

处理结果

成功登录进入课程注册系统；或者登录不成功，系统状态不变。

特定要求

用户名不能重名，口令不能为空，5 次登录不成功锁定该帐户。

外部接口

无

补充说明

用户名提供列表选择，用户名不能超过 15 字符，口令不能少于

6 字符

3.3.4<功能需求 2>

[结构同 3.3.3]

3.3.5<功能需求 N>

[结构同 3.3.3]

3.4<功能组 2>

[结构同 3.3]

3.5<功能组 N>

[结构同 3.3]

四．非功能需求

4.1 系统质量需求

[本条应描述合同中标识的或从更高层次规格说明派生出来的对系统或子系统质

量方面的需求,例如包括有关系统的功能性（实现全部所需功能的能力）、性能

（支持的用户数、操作响应速度、资源占用约束等）、可靠性（产生正确、一致

结果的能力）、可维护性（易于更正的能力）、可用性（需要时进行访问和操作的

能力）、灵活性（易于适应需求变化的能力）、可移植性（易于修改以适应新环境

的能力）、可重用性（可被多个应用使用的能力）、可测试性（易于充分测试的能

力）、易用性（易于学习和使用的能力）以及其它属性的定量需求。

需求应尽可

能具体、量化和能够验证。

]

4.1.1 性能

[阐述不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人

员作出合理的设计选择。

确定相互合作的用户数或者所支持的操作、响应时间

以及与实时系统的时间关系。

你还可以在这里定义容量需求，例如存储器和磁

盘空间的需求或者存储在数据库中表的最大行数。

尽可能详细地确定性能需求。

可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中

在一起陈述。

]

示范：

―――仅供参考，不具备任何实质性的内容。

系统容量：

支持 3 万用户，支持 GB 级数据。

数据库表行数不超过 100 万行，

数据库最大容量不超过 1000GB，磁盘空间至少需要 40G 以上.

响应指标：

运行速度取决于硬件配置和应用数据规模，在推荐配置环境下：

登录响应时间在 5 秒内，刷新栏目响应时间在 5 秒内，刷新条目分页列表响应

时间 5 秒内，打开信息条目响应时间 3 秒内，刷新部门、人员列表响应时间 5

秒内。

4.1.2 可靠性

[阐述客户对系统的可靠性方面的要求。

可靠性是软件无故障运行一段

时间的概率。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本系统的最终用户涉及面广，因此，整体系统运行要求稳定，有很强的防

错、抗错能力，保证数据报送工作正常进行。

可靠性指标：

在连续运行情况下，系统可靠性 99.9999%。

提供应用服务器

集群技术和组件技术支持高可靠性和伸缩性。

4.1.3 可维护性

[阐述客户对系统的可维护性方面的要求。

可维护性表明了自软件中纠

正一个缺陷或做一次更改的简易程度。

]

示范：

―――仅供参考，不具备任何实质性的内容。

系统从设计上尽量考虑使得***大多数统计系统的建设都能使用本软件搭建

而成，量少做二次开发或者不做二次开发，直接通过系统配置搭建系统，从功

能上具有通用性，易修改和扩展。

软件开发使用组件技术，保证了可维护性高。

系统具有开放性，是指统计、分析内容的可修改、可扩展性。

例如，经过一定

的授权，系统管理人员即可根据将来统计制度变动的需要对统计指标进行增、

删等修改，无需经过软件开发技术人员。

兼容性：

系统应支持多种操作系统、数据库系统和、WEB 服务器系统。

采

用 JAVA、JNDI 技术来保证较好的可移植性和可扩展性。

4.1.4 可用性

[阐述客户对系统的可用性方面的要求。

可用性表明了软件具备随时随地能

够访问和操作的能力。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本系统采用 B/S 和 C/S 混合模式，支持脱机方式，因此能够保证用户随时

随地访问系统。

同时，系统采取容错技术，具备数据恢复功能，能够保证用户

随时随地操作系统。

4.1.5 灵活性

[阐述客户对系统的灵活性方面的要求。

灵活性表明了软件系统能够易于适

应需求的变化的能力。

]

示范：

―――仅供参考，不具备任何实质性的内容。

适应多种数据传输方式，能够提供灵活配置以适应业务需求的变化，如可

自行定义业务规则、采集机构、采集指标、处理逻辑、反馈信息等等，通过多

方面的定制以适应某个具体的业务系统。

4.1.6 可移植性

[阐述客户对系统的可移植性方面的要求。

可移植性表明了软件易于修改以

适应多种环境的能力。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本系统支持多种网络环境，特别是互联网，能够实现跨平台操作。

4.1.7 可重用性

[阐述客户对系统的可重用性方面的要求。

可重用性表明了软件能够被多个

应用使用的能力。

]

示范：

―――仅供参考，不具备任何实质性的内容。

本系统提供组件式服务，部分公用组件能够被其它系统所使用。

同时，在

将来后继升级系统时，能够使得部分组件被重用。

4.1.8 可测试性

[阐述客户对系统的可测试性方面的要求。

可测试性表明了软件能够在有限

时间、人力资源限度内被充分测试的能力。

]

示范：

―――仅供参考，不具备任何实质性的内容。

软件系统具有良好的可测试性，能够在 4 个工作周、3 个人力的情况下顺

利完成所有测试项目。

具体测试项目如下：

代码检查：

程序开发人员除了调试外，还应进行重点检查程序代码语法错

误。

单元测试：

对组成系统的每个组件进行数据结构测试和功能性测试，重点

是组件的功能和程序逻辑。

集成测试：

将组件组装成子系统后，应再次对组装后的子系统进行功能性

测试，重点是组件与组件之间的接口测试。

系统测试：

经过测试后的各子系统组装成系统后，还应组织对整个系统进

行全面的测试，包括功能、性能以及接口测试。

性能测试：

测试系统的操作相应速度以及资源占用效率。

压力测试：

测试系统的可靠性和伸缩性，以验证系统能承受多大的负载。

鉴于本软件系统的特殊性，测试重点应放在功能和性能上，其它方面可略

作测试。

4.1.9 易用性

[阐述客户对系统的易用性方面的要求，易用性包括人机界面的友好性，

新用户或不常使用产品的用户在学习使用产品时的简易程度等。

]

示范：

―――仅供参考，不具备任何实质性的内容。

系统应操作简单、易学易用、符合标准浏览器操作风格，丰富的联机帮助，

人性化的操作界面，界面布局合理，节省操作时间提高生产效率。

4.2 安全性需求

[详尽陈述与系统安全性、完整性或与私人问题相关的需求，包括用户

身份确认或授权需求，数据库安全性需求，工作流程安全性需求等。

这些问题

将会影响到产品的使用和产品所创建或使用的数据的保护。

定义用户身份确认

或授权需求。

明确产品必须满足的安全性或保密性策略。

]

示范：

―――仅供参考，不具备任何实质性的内容。

硬件

操作系统及

其版本

应用服务器软件及其版

本

应用软件及其部件

服务器

IBM RS6000

AIX 4.3.3

IBM HTTP

Server、Apache、MS

IIS5.0 等；

DB2（7.2 EE 以上版

本）

WAS（4.0 以上版本）、

Web Logic（7.0 以上版

本）等；

Oracle EE（9i EE