软件需求规范手册.docx

《软件需求规范手册.docx》由会员分享，可在线阅读，更多相关《软件需求规范手册.docx（23页珍藏版）》请在优知文库上搜索。

1、一.引言软件需求规格阐明书记录对系统或系统0一部分0完整软件需求。如下是一种经典B软件需求规格阐明书概述，用于波及用例建模B项目。此工件由一种包构成，该包包括用例模型的用例、非功能性需求、接口需求以及其他支持信息。本文档模板适合采用用例建模技术的项目需求描述。在正式编写文档时，请删除内容规定部分。1.l编写目的本文档作为*与XXXXXXXXXX企业之间就*建立XXXX司（局或单位）论坛系统需求理解到达一致共识的基础文献，作为双方界定项目范围、签定协议的重要基础，也作为本项目验收的重要根据。同步，本文档也作为*后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之

2、用。1.2合用范围本文档合用于所有与本项目有关的软件开发阶段及其有关人员，其中：*方面的项目负责人、企业方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。1. 3文档概述本文档重要描述了论坛系统项目的软件需求。本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，另首先从顾客界面、软件接口等方面描述系统的外部接口需求，然后深入详细描述功能性需求和非功能性需求以及待确定B问题。1.4 参照资料列出本文0参照文献清单，包括出版单位、作者、版本、日期等信息。示范：仅供参照，不具有任何实质性B内容。XXX总体需求书(XXX单

3、位XXX提供)需求调研汇报XXX设计模式XXXXX出版社1.5 术语、定义和缩写列出本文档所波及的专业术语、缩写词及有关定义。定义所有必要的术语，以便读者可以对的地解释软件需求规格阐明，包括词头和缩写。你也许但愿为整个企业创立一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格阐明中的术语。示范：仅供参照，不具有任何实质性的内容。1) OLTP：On-lineTransactionProcessing,联机事务处理。2) OI.AP：On-LineAnalyticalProcessing,联机分析处理；是使分析人员、管理人员或执行人员可以从多角度对信息进行迅速、一致、交互地存取,从

4、而获得对数据的更深入理解的一类软件技术。1. 6Use-Case图形规范对文档中使用的Use-Case图0图符作简介，同步阐明所应用UML规范时版本，以便理解和统一。假如使用0是UMLVL3原则规范，则可以直接将下列内容作为文档内容。一种Use-Case图显示0是Actor与Use-Case之间B某种关系。表1-1列出了本文档的UseYase图中用到的图符、名称及其功能简介。表1-1UMLVI.3UseCase图符图符名称描述UseCaseUseCase用于体现Use-case图中日勺Use-Case,每个UseCase用于体现所建模系统日勺一项外部功能需求，即从顾客的角度分析所得日勺需求。A

5、ctorActor用于描述与系统功能有关丛J外部实体，它可以是顾客，也可以是外部系统。关联用于连接ACtOr和USeCase,体现该ACtOr所代表B7、J系统外部与该USeCaSe所描述BZ-J系统需求有关。这也是Actor和UseCase之间唯一合法、J连接。扩展由USeCaseA指向USeCaseB（被扩展），体现UseCaseB描述了一项基本需求，而UseCaseA则描述了该基本需求日勺特殊状况，即用例A扩展了用例B日勺需求。泛化UseCaseA（子用例）指向UseCaseB（父用例）,体现USeCaseA继承了USeCaseB日勺特性，并增长了新的特性。包括由UseCaseA指向Us

6、eCaseB（被包括），体现UseCaseA中包括了UseCaseB中日勺行为或功能。二.系统概述2.1业务背景概要描述本系统0业务背景和来源。若用图表更能清晰描述业务背景，则提议在用自然文字描述业务B同步，辅以图形、表格来更精确地描述业务。示范：仅供参照，不具有任何实质性B内容。为切实推进国家助学贷款管理工作，贯彻有关切实推进国家助学贷款工作有关问题的告知（银发202338号）、有关下达2023年度国家助学贷款指导性贷款计划0告知（银发2023253号）和有关加强国家助学贷款三考核工作0告知（银办发2023239号）文献精神及肖钢副行长有关在我司建立银行系统的助学贷款专题记录制度0指示，满足

7、“要按月考核经办银行国家助学贷款0申请人数和申请金额、考核已审批贷款人数和贷款协议金额、考核算际发放贷款人数和发放金额。”“按月编报分省四定的国家助学贷款进度明细表”和“增报国家助学贷款三考核指标分地区、分银行登记表”的工作规定，处理目前记录中存在的指标口径难于统一（银行与学校、教育管理部门），数据采集不准、不细，校名不规范，手工记录劳动量大、效率不高等问题。满足对贷款学生基本信息、信用记录0查询；对学校进度明细B记录；对分地区、分行别的汇总记录以及有关分析等新的管理需求，必须有对应0计算机软件系统支持，以处理数据的采集录入、记录汇总、上报传播的需要。2. 2系统功能以图形、表格等形式简要阐明

8、本软件系统B重要功能，易于读者理解。详细内容将在第4部分阐明。对于采用老式措施分析系统需求，提议用Visio画出整个系统的功能构造。示范：仅供参照，不具有任何实质性0内容。银行业务通用网上记录暨助学贷款记录系统通过定制不同样B业务类别，定制记录业务B项目、指标及其汇总关系等,迅速满足不同样银行业务的记录规定,形成从各级金融机构到*各分支机构，从下级机构到上级机构的业务定制、数据采集、分析、记录和信息公布的记录体系。重要任务和目的是：遵照*统一数据采集、统一信息公布建设原则，增进信息整合和应用整合。作为“*信息系统平台“的一部分，为“*信息系统平台”提供部分公用化模块组件，防止业务模块B反复开发

9、。最终实现一种银行业务通用网上记录系统平台；并能以便地定制新B记录业务，并能灵活适应业务发展需要。运用银行业务通用网上记录系统平台布署助学贷款专题网上记录系统，满足对国家助学贷款的“三考核”规定，满足*全面掌握助学贷款业务信息的需要，并配合建立银行系统的助学贷款专题记录制度。助学贷款记录分析系统可为*全辖各机构和有关部门提供统一0数据采集、分析、报表、信息公布等多方面0功能，并可为商业银行、教育部门以及社会公众提供有关信息查询和记录分析成果。并作为个人征信系统初期应用模型，为增进个人征信系统打下基础。系统功能关系图如下：3. 3顾客类别及特性确定你觉得也许使用该产品的不同样顾客类并描述它们有关

10、B特性。有某些需求也许只与特定的顾客类有关。提供参与系统的主角的名称列表及简要阐明，即简要描述系统所波及的各角色及其职责。示范：仅供参照，不具有任何实质性0内容。注：应在上图位置给出使用本系统的客户组织的角色或岗位职责分派图以替代上图。下表是对上图关键顾客角色（ACtOr）的简要阐明:Actor名称简要阐明权限系统管理者所有权限一般由总部IT人员来担任，顾客数量比较少。负责系统（读、写、的配置、备份与恢复，以及任务管理等工作。删除、创立）XXX岗位系统时钟工作流引擎2.4顾客文档列出所需的顾客文档，例如：顾客手册，联机顾客文档、联机协助系统、有关申明0协助等的需求。示范：仅供参照，不具有任何实

11、质性B内容。本软件应提供实时在线协助（即联机协助系统）、顾客操作手册、系统管理员手册、系统安装手册以及培训文档。2.5设计和实现上的限制确定影响开发人员自由选择B问题，并阐明这些问题为何成为一种限制。描述在进行设计和实现时需要注意的问题,例如，必须使用或者防止的特定技术、工具、编程语言和数据库；所规定的开发规范或原则；企业方略、政府法规或工业原则；数据转换格式原则等等。示范：仅供参照，不具有任何实质性B内容。本系统应具有良好的可扩展性、复杂操作环境的可适应性、灵活可配置的权限控制、大容量数据操作的迅速响应及高可靠性以及与既有系统的兼容性，同步,具有在线提醒和短信息提醒，可以实现多种数据格式的转

12、换，以多种图形格式展示分析成果。本系统应支持多级无限扩展应用，符合国际、国内原则规范，可以与其他系统无缝衔接。2. 6假设和依赖列举出在对软件需求规格阐明中影响需求陈说的假设原因（与己知原因相对立）。这也许包括需求分析人员打算要用的商业组件或有关开发或运行环境的问题。需求分析人员也许认为产品将符合一种特殊B顾客界面设计约定，不过另一种SRS读者却也许不这样认为。假如这些假设不对的、不一致或被更改，就会使项目受到影响。此外，确定项目对外部原因存在aJ依赖。例如，假如你打算把其他项目开发0组件集成到系统中，那么你就要依赖那个项目准时提供对00操作组件。假如这些依赖已经记录到其他文档（例如项目计划）

13、中了，那么在此就可以参照其他文档。示范：仅供参照，不具有任何实质性的内容。本系统需要集成其他软件开发商提供0组件或应用系统，假定需要集成0组件可以准时提供并满足需求。假定这些组件的运行环境与本系统运行环境不发生冲突，能与本系统兼容。此外，假定本文档所描述的软件需求均获得了项目双方所有客户的承认且稳定不变。假如项目后期，客户提出的需求变更超过了本需求规格范围，则将严重影响本系统0设计、开发和程序的稳定。在本软件需求规格阐明书定版之后，客户需求发生了较大变更，变更后的需求规格阐明将不在本文档中补充，而以新B版本文档给出。2. 7假设和依赖列举出在对软件需求规格阐明中影响需求陈说的假设原因（与己知原

14、因相对立）。这也许包括你打算要用的商业组件或有关开发或运行环境B问题。你也许认为产品将符合一种特殊B顾客界面设计约定，不过另一种SRS读者却也许不这样认为。假如这些假设不对时、不一致或被更改，就会使项目受到影响。此外，确定项目对外部原因存在的依赖。例如，假如你打算把其他项目开发的组件集成到系统中，那么你就要依赖那个项目准时提供对啊的操作组件。假如这些依赖已经记录到其他文档（例如项目计划）中了，那么在此就可以参照其他文档。本系统需要集成其他软件开发商提供0组件或应用系统，假定需要集成0组件可以准时提供并满足需求。假定这些组件的运行环境与本系统运行环境不发生冲突，能与本系统兼容。此外，假定本文档所

15、描述的软件需求均获得了项目双方所有客户的承认且稳定不变。假如项目后期，客户提出的需求变更超过了本需求规格范围，则将严重影响本系统0设计、开发和程序的稳定。在本软件需求规格阐明书定版之后，客户需求发生了较大变更，变更后的需求规格阐明将不在本文档中补充，而以新B版本文档给出。三.功能需求本章节重要提供详细的功能性需求描述。对于采用构造化措施分析需求的项目，应采用如下内容组织方式阐明。3. 1系统功能关系图以框图B形式体现新系统B各功能组之间B功能关系图，易于读者理解。详细内容描述将在第4.3部分阐明。应分层次展示整个系统的功能，先从系统一一子系统一一模块逐层展示，并阐明各子系统和模块之间的功能关系。同步，应注意与外部系统的接口。顾客通过“系统登录/注销“子系统进入系统，从“顾客和权限管理“子系统获得对应0权限进行操作，顾客从事业务定制、数据采集、记录分析、信息公布/浏览、业务查询、顾客和权限管理等其被授权B操作，“