软件需求规范手册

一.引言

［软件需求规格阐明书记录对系统或系统的一部分日勺完整软件需求。如下

是一种经典日勺软件需求规格阐明书概述，用于波及用例建模日勺项目。此工件由一

种包构成，该包包括用例模型日勺用例、非功能性需求、接口需求以及其他支持信

息。本文档模板适合采用用例建模技术的项目需求描述。］一一在正式编写文

档时，请删除内容规定部分。

1.1编写目日勺

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

系统需求理解到达一致共识口勺基础文献，作为双方界定项目范围、签定协议口勺重

要基础，也作为本项目验收的重要根据。同步，本文档也作为***后继工作开展

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

求之用。

L2合用范围

本文档合用于所有与本项目有关日勺软件开发阶段及其有关人员，其中：***

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

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

1.3文档概述

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

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

从顾客界面、软件接口等方面描述系统日勺外部接口需求，然后深入详细描述功能

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

1.4参照资料

［列出本文的参照文献清单，包括出版单位、作者、版本、日期等信息。］

示范：------仅供参照，不具有任何实质性H勺内容。

《XXX总体需求书》(XXX单位XXX提供)

«xxx需求调研汇报》XXX

《设计模式》XXXXX出版社

1.5术语、定义和缩写

［列出本文档所波及的专业术语、缩写词及有关定义。

定义所有必要的术语，以便读者可以对日勺地解释软件需求规格阐明，包括词

头和缩写。你也许但愿为整个企业创立一张跨越多项项目的词汇表，并且只包括

特定于单一项目H勺软件需求规格阐明中的术语。］

示范：-----仅供参照，不具有任何实质性日勺内容。

1)OLTP：On-lineTransactionProcessing,联机事务处理。

2)OLAP：On-LineAnalyticalProcessing,联机分析处理；是使分析人

员、管理人员或执行人员可以从多角度电信息进行迅速、一致、交互地

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

1.6Use-Case图形规范

［对文档中使用的Use-Case图的图符作简介，同步阐明所应用UML规范的版

本，以便理解和统一。假如使用日勺是UMLVI.3原则规范，则可以直接将下列内

容作为文档内容。］

一种Use-Case图显示H勺是Actor与Use-Case之间欧I某种关系。表1-1列出

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

表1-1UMLVI.3UseCase图符

图符名称描述

用于体现Usc-casc图中的JUse-Case,每个UseCase

Use

UseCase用于体现所建模系统的一项外部功能需求，即从顾

Case

客日勺角度分析所得的需求。

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

ActorActor

客，也可以是外部系统。

用于连接Actor和UseCase,体现该Actor所代表

关联的系统外部与该UseCase所描述的系统需求有关。

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

由UseCaseA指向UseCaseB（被扩展），体现

UseCaseB描述了一项基本需求，而UseCaseA则

«extends»扩展

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

例B的需求。

由UseCaseA（子用例）指向UseCaseB（父用例），

泛化体现UseCaseA继承了UseCaseB的特性，并增

长了新日勺特性。

由UseCaseA指向UseCaseB（被包括），体现

«include»包括

UseCaseA中包括了UseCaseB中的行为或功能。

二.系统概述

2.1业务背景

［概要描述本系统日勺业务背景和来源。若用图表更能清晰描述业务背景，则

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

示范：-----仅供参照，不具有任何实质性的内容。

为切实推进国家助学贷款管理工作，贯彻《有关切实推进国家助学贷款工作

有关问题时告知》（银发［2023］38号）、《有关下达2023年度国家助学贷款指

导性贷款计划的告知》（银发［2023］253号）和《有关加强国家助学贷款'三考

核'工作的告知》（银办发［2023］239号）文献精神及肖钢副行长有关在我司建

立银行系统的助学贷款专题记录制度的指示，满足“要按月考核经办银行国家助

学贷款的申请人数和申请金额、考核已审批贷款人数和贷款协议金额、考核算际

发放贷款人数和发放金额。”“按月编报分省‘四定'口勺国家助学贷款进度明细

表”和“增报《国家助学贷款'三考核'指标分地区、分银行登记表》”的工作

规定，处理目前记录中存在的指标口径难于统一（银行与学校、教育管理部门），

数据采集不准、不细，校名不规范，手工记录劳动量大、效率不高等问题。满足

对贷款学生基本信息、信用记录的查询；对学校进度明细的记录；对分地区、分

行别的汇总记录以及有关分析等新的管理需求，必须有对应的计算机软件系统支

持，以处理数据的采集录入、记录汇总、上报传播的需要。

2.2系统功能

［以图形、表格等形式简要阐明本软件系统的重要功能，易于读者理解。详

细内容将在第4部分阐明。对于采用老式措施分析系统需求，提议用Visio画出

整个系统的功能构造。］

示范：------仅供参照，不具有任何实质性口勺内容。

银行业务通用网上记录暨助学贷款记录系统通过定制不同样日勺业务类别，定

制记录业务的项目、指标及其汇总关系等，迅速满足不同样银行业务的记录规定，

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

据采集、分析、记录和信息公布日勺记录体系。重要任务和目日勺是：遵照***统一

数据采集、统一信息公布建设原则，增进信息整合和应用整合。作为“***信息

系统平台“R勺一部分，为“***信息系统平台”提供部分公用化模块组件，防止

业务模块的反复开发。最终实现一种银行业务通用网上记录系统平台；并能以便

地定制新的记录业务，并能灵活适应业务发展需要。运用银行业务通用网上记录

系统平台布署助学贷款专题网上记录系统，满足对国家助学贷款的“三考核”规

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

款专题记录制度。助学贷款记录分析系统可为***全辖各机构和有关部门提供统

一的数据采集、分析、报表、信息公布等多方面的功能，并可为商业银行、教育

部门以及社会公众提供有关信息查询和记录分析成果。并作为个人征信系统初期

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

系统功能关系图如卜：

2.3顾客类别及特性

［确定你觉得也许使用该产品日勺不同样顾客类并描述它们有关的特性。有某

些需求也许只与特定的顾客类有关。提供参与系统的主角的名称列表及简要阐

明，即简要描述系统所波及日勺各角色及其职责。］

示范：-----仅供参照，不具有任何实质性口勺内容。

注：应在上图位置给出使用本系统日勺客户组织日勺角色或岗位职责分派图以替

代上图。

下表是对上图关键顾客角色（Actor）日勺简要阐明：

Actor名称简要阐明权限

所有权限

至绪环种者一般由总部IT人员来担任，顾客数量比较少。负责系统（读、写、

示次目理百的配置、备份与恢复，以及任务管理等工作。删除、创

立）

XXX岗位

系统时钟

工作流引擎

2.4顾客文档

［列出所需的顾客文档，例如：顾客手册，联机顾客文档、联机协助系统、

有关申明的协助等的需求。］

示范：-----仅供参照，不具有任何实质性H勺内容。

本软件应提供实时在线协助（即联机协助系统）、顾客操作手册、系统管理

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

2.5设计和实现上日勺限制

［确定影响开发人员自由选择H勺问题，并阐明这些问题为何成为一种限制。

描述在进行设计和实现时需要注意的问题，例如，必须使用或者防止的特定技术、

工具、编程语言和数据库；所规定的开发规范或原则；企业方略、政府法规或工

业原则；数据转换格式原则等等。］

示范：-----仅供参照，不具有任何实质性的内容。

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

限控制、大容量数据操作的迅速响应及高可靠性以及与既有系统的兼容性，同步,

具有在线提醒和短信息提醒，可以实现多种数据格式的转换，以多种图形格式展

示分析成果。

本系统应支持多级无限扩展应用，符合国际、国内原则规范，可以与其他系

统无缝衔接。

2.6假设和依赖

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

对立）。这也许包括需求分析人员打算要用日勺商业组件或有关开发或运行环境的

问题。需求分析人员也许认为产品将符合一种特殊的顾客界面设计约定，不过另

一种SRS读者却也许不这样认为。假如这些假设不对时、不一致或被更改，

就会使项目受到影响。

此外，确定项目对外部原因存在的I依赖。例如，假如你打算把其他项目开发

的组件集成到系统中，那么你就要依赖那个项目准时提供对日勺的操作组件。假如

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

档。］

示范：-----仅供参照，不具有任何实质性日勺内容。

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

件可以准时提供并满足需求。假定这些组件的运行环境与本系统运行环境不发生

冲突，能与本系统兼容。

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

定不变。

假如项目后期，客户提出加、J需求变更超过了本需求规格范围，则将严重影响

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

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

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

2.7假设和依赖

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

对立）。这也许包括你打算要用日勺商业组件或有关开发或运行环境的问题。你也

许认为产品将符合一种特殊日勺顾客界面设计约定，不过另一种SRS读者却也

许不这样认为。假如这些假设不对的、不一致或被更改，就会使项目受到影响。

此外，确定项目对外部原因存在的依赖。例如，假如你打算把其他项目开发

的组件集成到系统中，那么你就要依赖那个项目准时提供对日勺欧I操作组件。假如

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

档。］

示范：-----仅供参照，不具有任何实质性口勺内容。

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

件可以准时提供并满足需求。假定这些组件的运行环境与本系统运行环境不发生

冲突，能与本系统兼容。

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

定不变。

假如项目后期，客户提出加、J需求变更超过了本需求规格范围，则将严重影响

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

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

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

三.功能需求

［本章节重要提供详细H勺功能性需求描述。走于采用构造化措施分析需求的

项目，应采用如下内容组织方式阐明。］

3.1系统功能关系图

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

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

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

并阐明各子系统和模块之间口勺功能关系。同步，应注意与外部系统的接口。］

示范：-----仅供参照，不具有任何实质性口勺内容。

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

统获得对应日勺权限进行操作，顾客从事业务定制、数据采集、记录分析、信息公

布/浏览、业务查询、顾客和权限管理等其被授权时操作，“日志管理”子系统

进行登记。顾客从“协助”子系统获得协助。

3.2系统功能清单

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

功

能

优先

需求章节项功能项编号功能项名称功能简要描述

级

数

描述顾客怎样登录课程注册..t-

LDAP-FI-101登录

系统

容许学生在学期结束前查当

LDAP-FT-102查当作绩单高

作绩单

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

4.3课程注

8LDAPFI103注册课程课程，也包括更新、删除课程高

册管理

等

容许专家在下学期到来之前，

选择讲讲课

LDAP-FT-104从课程目录中选择符合自己高

程

的课程

3.3<功能组1>

功能简述

［简要描述本子系统的重要功能，并以功能关系图展示子系统。］

示范：-----仅供参照，不具有任何实质性H勺内容。

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

数据管理功能，具有灵活易用、功能强大的特点，是顾客创立数据库资源并对采

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

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

数据构造定制

基础数据管理

业务查询定义

数据库模型导入

数据采集接口规范定制

0

注：提议对上图各功能项进行简要阐明。

《功能组1》与其他功能组之间欧I关系框图如下图所示:

业务定制

数据采集

记录分析

信息公布/浏览

业务查询

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

系统参数、数据构造

系统参数、数据构造

系统参数

功能清单

［以表格日勺形式列出〈功能组1》中所有功能项，便于读者检索。］

示范：-----仅供参照，不具有任何实质性的内容。

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

LDAP-FI-101登录描述顾客怎样登录课程注册系统高

LDAP-FI-102查当作绩单容许学生在学期结束前查当作绩单高

容许学生向课程目录中注册课程，也包括

LDAP-FI-103注册课程高

更新、删除课程等

选择讲讲课容许专家在下学期到来之前，从课程目录

LDAP-FI-104高

程中选择符合自己的课程

••••••••••••中

＜登录系统）

［详细列出功能模块或功能单元的详细需求。这些是必须提交给顾客的软件

功能，使顾客可以使用所提供日勺特性执行服务或者使用所指定的I使用实例执行任

务。描述产品怎样响应可预知的出错条件或者非法输入或动作。必须唯一地标识

每个需求。］

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

功能编号LDAP-FI-101功能名称登录系统

参与者有权限的顾客优先级高

简要描述描述顾客怎样成功登录课程注册系统

执行条件无

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

1.系统祈求该actor输入他或她/、J顾客名和口令；

2.该actor输入他或她日勺顾客名和口令；

3.系统验证该actor输入欧I顾客名和口令，并将该actor登录信息记入系统

日志中。

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

1.无效顾客名和或口令

假如该actor输入一种无效的顾客名和或口令，系统应显示一种错误消息。

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

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

外部接口无

补充阐明顾客名提供列表选择，顾客名不能超过15字符，口令不能少于6

字符

<功能需求2>

［构造同］

《功能需求N>

［构造同］

3.4<功能组2>

［构造同3.3］

3.5〈功能组N>

［构造同3.3］

四.非功能需求

4.1系统质量需求

［本条应描述协议中标混的或从更高层次规格阐明派生出来日勺对系统或子系统质

量方面日勺需求，例如包括有关系统日勺功能性（实现所有所需功能的能力）、性能（支

持欧J顾客数、操作响应速度、资源占用约束等）、可靠性（产生对欧I、一致成果

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

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

可重用性（可被多种应用使用欧I能力）、可测试性（易于充足测试的能力）、易用性

（易于学习和使用欧I能力）以及其他属性的I定量需求。需求应尽量详细、量化和

可以验证。］

性能

［论述不同样H勺应用领域对产品性能的需求，并解释它们的原理以协助开发

人员作出合理的设计选择。确定互相合作的顾客数或者所支持的操作、响应时间

以及与实时系统H勺时间关系。你还可以在这里定义容量需求，例如存储器和磁盘

空间的需求或者存储在数据库中表的最大行数。尽量详细地确定性能需求。也许

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

陈说。］

示范：------仅供参照，不具有任何实质性日勺内容。

系统容量：支持3万顾客，支持GB级数据。数据库表行数不超过100万行,

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

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

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

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

可靠性

［论述客户对系统的可靠性方面日勺规定。可靠性是软件无端障运行一

段时间日勺概率。］

示范：------仅供参照，不具有任何实质性日勺内容。

本系统H勺最终顾客波及面广，因此，整体系统运行规定稳定，有很强H勺防错、

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

可靠性指标：在持续运行状况下，系统可靠性99.9999%。提供应用服务器

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

可维护性

［论述客户对系统的可维护性方面的规定。可维护性表明了自软件中

纠正一种缺陷或做一次更改H勺简易程度。］

示范：------仅供参照，不具有任何实质性日勺内容。

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

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

上具有通用性，易修改和扩展。软件开发使用组件技术，保证了可维护性高。系

统具有开放性，是指记录、分析内容日勺可修改、可扩展性。例如，通过一定日勺授

权，系统管理人员即可根据未来记录制度变动欧I需要对记录指标进行增、删等修

改，无需通过软件开发技术人员。

兼容性：系统应支持多种操作系统、数据库系统和、WEB服务器系统。采用

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

可用性

［论述客户对系统H勺可用性方面的规定。可用性表明了软件具有随时随地可

以访问和操作的能力。］

示范：-----仅供参照，不具有任何实质性H勺内容。

本系统采用B/S和C/S混合模式，支持脱机方式，因此可以保证顾客随时随

地访问系统。同步，系统采用容错技术，具有数据恢复功能，可以保证顾客随时

随地操作系统。

灵活性

［论述客户对系统口勺灵活性方面的规定。灵活性表明了软件系统可以易于适

应需求H勺变化的能力。］

示范：-----仅供参照，不具有任何实质性日勺内容。

适应多种数据传播方式，可以提供灵活配置以适应业务需求日勺变化，如可自

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

的定制以适应某个详细H勺业务系统。

可移植性

［论述客户对系统日勺可移植性方面的规定。可移植性表明了软件易于修改以

适应多种环境的能力。］

示范：------仅供参照，不具有任何实质性的内容。

本系统支持多种网络环境，尤其是互联网，可以实现跨平台操作。

可重用性

［论述客户对系统H勺可重用性方面日勺规定。可重用性表明了软件可以被多种

应用使用的能力。］

示范：------仅供参照，不具有任何实质性H勺内容。

本系统提供组件式服务，部分公用组件可以被其他系统所使用。同步，在未

来后继升级系统时，可以使得部分组件被重用。

可测试性

［论述客户对系统口勺可测试性方面日勺规定。可测试性表明了软件可以在有限

时间、人力资源程度内被充足测试的能力。］

示范：------仅供参照，不具有任何实质性日勺内容。

软件系统具有良好H勺可测试性，可以在4个工作周、3个人力H勺状况下顺利

完毕所有测试项目。详细测试项目如下：

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

单元测试：对构成系统H勺每个组件进行数据构造测试和功能性测试，重点是

组件的功能和程序逻辑。

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

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

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

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

性能测试：测试系统的操作对应速度以及资源占用效率。

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

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

测试。

易用性

［论述客户对系统欧I易用性方面日勺规定，易用性包括人机界面的友好

性，新顾客或不常使用产品日勺顾客在学习使用产品时日勺简易程度等。］

示范：-----仅供参照，不具有任何实质性日勺内容。

系统应操作简朴、易学易用、符合原则浏览将操作风格，丰富的联机协助，

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

4.2安全性需求

［详尽陈说与系统安全性、完整性或与私人问题有关的需求，包不顾

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

将会影响到产品H勺使用和产品所创立或使用日勺数据的保护。定义顾客身份确认或

授权需求。明确产品必须满足的安全性或保密性方略。］

示范：-----仅供参照，不具有任何实质性H勺内容。

网络安全：能经受来自互联网的i般性恶意袭击。如病毒（包括木马）袭击、

口令猜测袭击、黑客入侵等。因此，必须配置较强的J网络安全防备、响应能力，

为应用系统提供安全可靠的网络记录平台。

数据库安全：数据库级备份和恢复。数据库级顾客进行角色和权限授权。使

得在异常状况发生时，系统可以得以迅速恢复，防止数据的丢失或将其影响降到

最低程度。同样，要保证存储过程中数据不被非法访问和篡改。

应用系统的安全：通过对顾客的身份鉴别，并实行对应的访问控制方略后，

使顾客只能完毕得到系统授权的数据访问功能操作。顾客只有经授权后才可以更

新程序，防止因错误程序更新而影响系统的正常运行。

4.3环境需求

［以列表形式或分类方式描述有关系统或子系统必须运行的环境需求，例如

包括硬件平台、操作系统和版本，尚有其他的软件组件或与其共存日勺应用程序。］

示范：------仅供参照，不具有任何实质性口勺内容。

砧胜操作系统及应用服务鳖件及其版应用软件及其部件

硬件其版本

IBMServer、DB2（7.2EE以上版

Apache>MSITS5.0等；本）

服务器IBMRS6000A1XWAS（4.0以上版本）、OracleEE（9iEE以

WebLogic（7.0以上版上版本）

本）等;

浏览客PTTIE5.0以上或Netscape

800/64M/2G旭演及以上

户端同等版本以上

提议配置IE5.0以上或NetscapeMicroStrategy7i客

特殊客

2G/64M/2G的。20个及以同等版本以上户端

户端

上

4.4保密性和私密性需求

［本条应指明保密性和私密性日勺系统需求，包括：系统运行的保密性/私密性

环境、提供日勺保密性或私密性的类型和程度、系统必须经受的保密性/私密性的

风险、减少此类危险所需的安全措施、系统必须遵照H勺保密性/私密性政策、必

须提供的保密性/私密性审核、保密性/私密性必须遵照确实证/承认准则。］

示范：------仅供参照，不具有任何实质性H勺内容。

数据保密：网络传递数据通过加密。需要保证数据在采集、传播和处理过程

中不被偷窥、窃取、篡改。

4.5业务规则

［列举出有关产品日勺所有操作规则，例如什么人在特定环境下可以进行何种

操作。这些自身不是功能需求，但它们可以暗示某些功能需求执行这些规则。假

如波及非常多的业务规则，需要单独作为一章来描述。］

示范：------仅供参照，不具有任何实质性日勺内容。

在数据上载前，报数人员要核查数据；在数据上载后，系统应反馈数据上载

成功信息。

4.6其他需求

［论述未在需求规格阐明书模板中定义H勺需求，如人员培训、包装和交时、

数据迁移等方面H勺需求。假如不需要增长其他需求，可省略这一部分。

定义在软件需求规格阐明的其他部分未出现白勺需求，例如国际化需求或法律

上日勺需求。你还可以增长有关操作、管理和维护部分来完善产品安装、配置、启

动和关闭、修复和容错，以及登录和监控操作等方面H勺需求。］

示范：-----仅供参照，不具有任何实质性口勺内容。

本系统应提供数据迁移日勺接口，需要将原有系统日勺数据顺利迁移到本系统

中。

本系统规定在安装过程的任何环节都应提供退出安装的操作，并能自动删除

已复制日勺文献。

在系统运行过程中，计算机忽然断电，系统应具有数据备份和数据恢复功能,

并提供数据修复和容错功能。

五.接口需求

［运用本节来确定可以保证新产品与外部组件对时连接的需求。关联图体现

了高层抽象的外部联接。需要把对接口数据和控制组件的详细描述写入数据字典

中。假如产品的不同样部分有不同样的外部接口，那么应把这些外部接口的详细

需求并入到这一部分的实例中。］

5.1顾客界面

［描述系统的界面类型以及界面的特定规定，包括界面布局、界面风格、界

面规范等。指出界面采用的原则或格式，所提供的原则功能（如协助），快捷键

设置，错误显示格式，初步的GUI产品构件，并描述所需要的顾客界面的软件组

件。描述每个顾客界面的逻辑特性。而对于顾客界面口勺细节，例如特定对话框的

布局，应当写入一种独立的顾客界面规格阐明中，而不能写入软件需求规格'阐明

中。］

示范（以B/S为例）：------如下示范仅供参照，应根据项目实际特点灵活

掌握。

本软件系统的顾客界面总体规定：界面友好，布局合理，操作以便，美观大

方。

本软件系统H勺界面应遵照总体规定，分别从如下几种方面进行详细规定（以

B/S为例）：

1.界面布局

系统页面重要划分为三个显示区（如图）顶端为标题栏区，显示标题栏目信

息；左侧为栏目区，显示树型栏目导航信息；右侧为信息条目列表区（主显示区），

内容包括信息条目分单元列表。

树形导航区

信心条目显示区

系统栏目导航区

Banner区

2.界面风格

系统界面整体风格为：上部为Banner和系统栏目导航，左侧是各个功能有

关口勺目录树，右侧是各个功能的详细E句数据以及功能实现。

系统界面色调以白色为背景色，一般字体为常规五号宋体字，目前操作（焦

点）应以不同样颜色或虚框形式与非目前操作以示区别。所有界面风格应遵照统

一的界面规范。

1）系统的查询页面风格，如下图：

2）在列表中增长一项向风格，如下图:

3）对某个详细细节的修改，如下图

3.界面规范

1）将系统中的查询、系统管理等不同样权限的页面分开，使得系统的

构造尽量清晰。

2）信息列表保持行高的一致，使分页规范；相似操作按钮位置的放置

相对固定等。

3）对操作者的操作应予以对应