软件需求规格说明书.docx

软件需求规格说明书.docx

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

软件需求规格说明书

一．引言

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

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

此工件由一个包组成，该包包含用例模型的用例、非功能性需求、接口需求以及其他支持信息。

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

]---- 在正式编写文档时，请删除内容要求部分。

1.1编写目的

本文档作为***与XXXXXXXXXX公司之间就***建立XXXX司（局或单位）论坛系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。

同时，本文档也作为***后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。

1.2适用范围

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

***方面的项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。

1.3文档概述

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

本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从用户界面、软件接口等方面描述系统的外部接口需求，然后进一步详细描述功能性需求和非功能性需求以及待确定的问题。

1.4参考资料

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

]

示范：

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

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

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

XXX

《设计模式》  XXXXX出版社 

1.5术语、定义和缩写

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

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

你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。

]

示范：

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

1）      OLTP：

On-lineTransactionProcessing，联机事务处理。

2）      OLAP：

On-LineAnalyticalProcessing，联机分析处理；是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。

1.6Use-Case图形规范

[对文档中使用的Use-Case图的图符作简介，同时说明所应用UML规范的版本，以便理解和统一。

如果使用的是UMLV1.3标准规范，则可以直接将下列内容作为文档内容。

]

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

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

表1-1UMLV1.3UseCase图符

图符

名称

描述

UseCase

UseCase

用于表示Use-case图中的Use-Case，每个UseCase用于表示所建模系统的一项外部功能需求，即从用户的角度分析所得的需求。

Actor

Actor

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

关联

用于连接Actor和UseCase，表示该Actor所代表的系统外部与该UseCase所描述的系统需求有关。

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

<>

扩展

由UseCaseA指向UseCaseB（被扩展），表示UseCaseB描述了一项基本需求，而UseCaseA则描述了该基本需求的特殊情况，即用例A扩展了用例B的需求。

泛化

由UseCaseA（子用例）指向UseCaseB（父用例），表示UseCaseA继承了UseCaseB的特性，并增加了新的特性。

<>

包含

由UseCaseA指向UseCaseB（被包含），表示UseCaseA中包含了UseCaseB中的行为或功能。

二．系统概述

2.1业务背景

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

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

]

示范：

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

为切实推进国家助学贷款管理工作，落实《关于切实推进国家助学贷款工作有关问题的通知》（银发[2002]38号）、《关于下达2002年度国家助学贷款指导性贷款计划的通知》（银发[2002]253号）和《关于加强国家助学贷款‘三考核’工作的通知》（银办发[2002]239号）文件精神及肖钢副行长关于在我司建立银行系统的助学贷款专项统计制度的批示，满足“要按月考核经办银行国家助学贷款的申请人数和申请金额、考核已审批贷款人数和贷款合同金额、考核实际发放贷款人数和发放金额。

”“按月编报分省‘四定’的国家助学贷款进度明细表”和“增报《国家助学贷款‘三考核’指标分地区、分银行统计表》”的工作要求，解决目前统计中存在的指标口径难于统一（银行与学校、教育管理部门），数据采集不准、不细，校名不规范，手工统计劳动量大、效率不高等问题。

满足对贷款学生基本信息、信用记录的查询；对学校进度明细的统计；对分地区、分行别的汇总统计以及相关分析等新的管理需求，必须有相应的计算机软件系统支持，以解决数据的采集录入、统计汇总、上报传输的需要。

2.2系统功能

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

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

对于采用传统方法分析系统需求，建议用Visio画出整个系统的功能结构。

]

示范：

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

银行业务通用网上统计暨助学贷款统计系统通过定制不同的业务类别，定制统计业务的项目、指标及其汇总关系等，快速满足不同银行业务的统计要求，形成从各级金融机构到***各分支机构，从下级机构到上级机构的业务定制、数据采集、分析、统计和信息发布的统计体系。

主要任务和目标是：

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

作为“***信息系统平台“的一部分，为“***信息系统平台”提供部分公用化模块组件，避免业务模块的重复开发。

最终实现一个银行业务通用网上统计系统平台；并能方便地定制新的统计业务，并能灵活适应业务发展需要。

利用银行业务通用网上统计系统平台部署助学贷款专项网上统计系统，满足对国家助学贷款的“三考核”要求，满足***全面掌握助学贷款业务信息的需要，并配合建立银行系统的助学贷款专项统计制度。

助学贷款统计分析系统可为***全辖各机构和相关部门提供统一的数据采集、分析、报表、信息发布等多方面的功能，并可为商业银行、教育部门以及社会公众提供相关信息查询和统计分析结果。

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

系统功能关系图如下：

2.3用户类别及特征

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

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

提供参与系统的主角的名称列表及简要说明，即简要描述系统所涉及的各角色及其职责。

]

示范：

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

注：

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

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

Actor名称

简要说明

权限

系统管理者

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

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

全部权限（读、写、删除、创建）

XXX岗位

系统时钟

工作流引擎

2.4用户文档

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

用户手册，联机用户文档、联机帮助系统、关于声明的帮助等的需求。

]

示范：

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

本软件应提供实时在线帮助（即联机帮助系统）、用户操作手册、系统管理员手册、系统安装手册以及培训文档。

2.5设计和实现上的限制

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

描述在进行设计和实现时需要注意的问题，比如，必须使用或者避免的特定技术、工具、编程语言和数据库；所要求的开发规范或标准；企业策略、政府法规或工业标准；数据转换格式标准等等。

]

示范：

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

本系统应具备良好的可扩展性、复杂操作环境的可适应性、灵活可配置的权限控制、大容量数据操作的快速响应及高可靠性以及与现有系统的兼容性，同时，具备在线提醒和短信息提示，能够实现多种数据格式的转换，以多种图形格式展示分析结果。

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

2.6假设和依赖

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

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

需求分析人员可能认为产品将符合一个特殊的用户界面设计约定，但是另一个SRS 读者却可能不这样认为。

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

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

例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。

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

]

示范：

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

本系统需要集成其他软件开发商提供的组件或应用系统，假定需要集成的组件能够按时提供并满足需求。

假定这些组件的运行环境与本系统运行环境不发生冲突，能与本系统兼容。

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

如果项目后期，客户提出的需求变更超出了本需求规格范围，则将严重影响本系统的设计、开发和程序的稳定。

在本软件需求规格说明书定版之后，客户需求发生了较大变更，变更后的需求规格说明将不在本文档中补充，而以新的版本文档给出。

2.7假设和依赖

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

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

你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个SRS 读者却可能不这样认为。

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

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

例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。

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

]

示范：

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

本系统需要集成其他软件开发商提供的组件或应用系统，假定需要集成的组件能够按时提供并满足需求。

假定这些组件的运行环境与本系统运行环境不发生冲突，能与本系统兼容。

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

如果项目后期，客户提出的需求变更超出了本需求规格范围，则将严重影响本系统的设计、开发和程序的稳定。

在本软件需求规格说明书定版之后，客户需求发生了较大变更，变更后的需求规格说明将不在本文档中补充，而以新的版本文档给出。

三．功能需求

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

对于采用结构化方法分析需求的项目，应采用以下内容组织方式说明。

]

3.1系统功能关系图

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

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

应分层次展示整个系统的功能，先从系统――>子系统――>模块逐层展示，并说明各子系统和模块之间的功能关系。

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

]

示范：

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