软件需求说明书提要(SRS)

合集下载

(完整)软件需求规格说明书

(完整)软件需求规格说明书

软件需求规格说明书1范围1.1标识SRS适用范围:城市教育资源管理系统标识号:GDGL004标题:城市教育资源管理系统版本号:V1。

0发行号:Alpha001(内测版)1.2系统概述随着我国政治体制改革、经济体制和教育体制改革的不断深入,城市教育在构建和谐社会中发挥着重要作用.教育资源的优劣,直接关系着教育效益的产出.教育资源管理的好坏将直接影响着学校的建设和发展。

目前中国城市人均教育经费差异很大,城市间高等教育阶段生师比的差距比较大,而基础教育的差距相对较小;城市经济发展水平是影响这些差异的主要因素,其次是城市人口规模;促进不发达地区城市和小城市的经济发展、建立合理的人口流动机制是消除城市间教育资源差异的有利措施。

城市教育资源管理系统是指综合运用地理信息系统(GIS)、多媒体及虚拟现实等现代信息技术实现面向高校教学管理部门提供教学资源管理的服务平台,对学校校舍、课桌、教学用具等硬件设施和师资力量等软件设施的信息的采集、集成和管理,根据地区各等级基础教育学校个数、学校规模和周边做涵盖教育分配地区,确定各个学校教育资源的优劣、所需教育人员以及所能容纳学生人数,也可以进行教育资源的调动管理,教职工人事变动管理,教学资源合理分配与再分配,地区教育质量评价等等。

它的建设将为教育部门对教育资源的管理起到很重要的监督和管理作用。

并能够作为一项新兴的部门管理方法。

1.3文档概述在信息化高速发展的今天,时间效率这样的名词正主导着人们的生活和发展,有必要设计开发一个城市教育资源管理系统。

通过系统功能有效的解决城市间教育经费、教育阶段生师比等等间的差异,从而提高管理效率。

本文档具体对城市教育资源管理系统的软件需求等进行基本分析,确定该系统基本功能及需求,故在此针对本系统编写此文档,本文档的最终解释权在本小组手中,请勿随意更改。

1.4基线本文档的设计基线是《GBT8567—2006计算机软件文档编制规范》.2引用文件[1]GBT8567—2006计算机软件文档编制规范. 2006[2]Y。

软件需求规格说明书(SRS)模板

软件需求规格说明书(SRS)模板

XX 软件需求规格说明书拟制日期yyyy-mm-dd 评审人日期yyyy-mm-dd 批准日期yyyy-mm-dd 签发日期yyyy-mm-dd<公司或企业图标><公司或企业中英文名称>版权所有侵权必究(仅供内部使用)修订记录分发记录目录1 简介 (8)1.1 目的 (8)1.2 范围 (8)2 总体概述 (8)2.1 软件概述 (8)2.1.1 项目介绍 (8)2.1.2 产品环境介绍 (8)2.2 软件功能 (9)2.3 用户特征 (9)2.4 假设和依赖关系 (9)3 具体需求 (9)3.1 功能需求 (10)3.1.1 功能需求1 (10)3.2 性能需求 (12)3.2.1 性能需求1 (12)3.3 外部接口需求 (12)3.3.1 用户接口 (12)3.3.2 软件接口 (13)3.3.3 硬件接口 (13)3.3.4 通讯接口 (14)4 总体设计约束 (14)4.1 标准符合性 (14)4.2 硬件约束 (14)4.3 技术限制 (14)5 软件质量特性 (15)6 依赖关系 (15)7 其他需求 (15)7.1 数据库 (15)7.2 操作 (15)7.3 本地化 (15)8 需求分级 (15)9 待确定问题 (16)10 附录 (16)10.1 附录A 可行性分析结果 (16)10.2 附录B 需求建模 (16)10.2.1 数据流图 (16)10.2.2 数据字典 (17)表目录Table1 **表 ................................................................................................................ 错误!未定义书签。

表1 **表....................................................................................................................... 错误!未定义书签。

软件需求规格说明

软件需求规格说明

软件需求规格说明软件需求规格说明(SRS)说明:1.《软件需求规格说明》(SRS)描述对计算机软件配置项CSCI的需求,及确保每个要求得以满足的所使用的方法。

涉及该CSCI外部接口的需求可在本SRS中给出:或在本SRS引用的一个或多个《接口需求规格说明》(IRS)中给出。

2.这个SRS,可能还要用IRS加以补充,是CSCI设计与合格性测试的基础。

1范围1.1标识本条应包含本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号和发行号。

1.2系统概述本条应简述本文档适用的系统和软件的用途,它应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的投资方、需方、用户、开发方和支持机构;标识当前和计划的运行现场;列出其他有关的文档。

1.3文档概述本条应概述本文档的用途和内容,并描述与其使用有关的保密性或私密性要求。

1.4基线说明编写本系统设计说明书所依据的设计基线。

2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期,也应标识不能通过正常的供货渠道获得的所有文档的来源。

3需求本章应分以下几条描述CSCI需求,也就是,构成CSCI验收条件的CSCI的特性。

[CSCI需求是为了满足分配给该CSCI的系统需求所形成的软件需求。

给每个需求指定项目唯一标识符以支持测试和可追踪性。

并以一种可以定义客观测试的方式来陈述需求。

如果每个需求有关的合格性方法(见第4章)和对系统(若适用,子系统)需求的可追踪性(见5.a条)在相应的章中没有提供,则在此进行注解。

描述的详细程度遵循以下规则:应包含构成CSCI验收条件的那些CSCI特性,需方愿意推迟到设计时留给开发方说明的那些特性。

如果在给定条中没有需求的话,本条应如实陈述。

如果某个需求在多条中出现,可以只陈述一次而在其他条直接引用。

]3.1所需的状态和方式如果需要CSCI在多种状态和方式下运行,且不同状态和方式具有不同的需求的话,则要标识和定义每一状态和方式,状态和方式的例子包括:空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。

srs技术文档说明

srs技术文档说明

本文的目的是描述SRS技术文档,包括对SRS的解释说明、SRS描述规范以及规范的一个范例。

软件需求规格说明书(SRS,Software Requirement Specification)是为了软件开发系统而编写的,主要用来描述待开发系统的功能性需求和非功能性需求,以及系统所要实现的功能和目标,为项目开发人员提供基本思路,明确开发方向,节约时间提高开发效率,降低软件开发风险,节约成本。

SRS主要面向系统分析员,程序员,测试员,实施员和最终用户。

SRS是整个软件开发的依据,它对以后阶段的工作起指导作用,同时也是项目完成后系统验收的依据,还是《用户手册》和《测试计划》的编写依据。

以下是SRS的描述规范:1.功能需求按模块为单位描述功能需求,重复以下几点描述每一模块的功能需求。

1.1 模块1第一个模块。

每个模块用一个用例图表示,在写SRS时,名字使用能够表达模块功能的短语表示,而不用模块1表示。

1.1.1 用例图描述此模块的用例图。

一个用例图中有若干个Actor、用例及其关系,描述包括涉及到的所有Actor、用例及其关系。

其中,Actor是参与者;一个用例描述的是一个功能需求;关系是用例和用例之间的关系。

用例的名字使用能够表达用例目标的动词短语。

1.1.2 业务流程图用例应说明的是系统内发生的事件,而不是事件发生的方式和原因。

一个业务流程图是用来描述1.1.1用例图中的一个用例事件的业务流程操作。

下面是对业务流程图对应的这个用例的描述说明:以下是SRS描述规范的一个范例:1.功能需求1.1业务区管理1.1.1 用例图1.1.2 业务流程图业务区创建范例说明:以上范例是直放站统一通讯管理系统的SRS中的第三章节,是用来描述系统的功能需求的,其中,1.1小节描述了其中一个模块——业务区管理的功能需求。

其中包括了业务区管理这一模块的用例图,以及对这一用例图中由Actor带动的三个用例:业务区创建、业务区管理、业务区删除的业务流程图描述,列出了其中一个用例——业务区创建的业务流程图,以及对这个用例的简要说明、前置条件、后置条件、角色、触发条件、基本事件流、备选事件流、特殊需求等的描述。

需求规格说明书

需求规格说明书

需求规格说明书随着科技和信息时代的发展,软件行业也越来越重要,其影响范围越来越广泛。

在软件开发过程中,需求规格说明书是一个非常重要的文档。

它定义了软件开发项目中的需求,包括功能、性能、安全、可用性等。

本文将详细介绍需求规格说明书的定义和重要性以及编写需求规格说明书的一些问题。

一、什么是需求规格说明书?需求规格说明书(Software Requirements Specification,简称SRS)是一份详细的软件开发文档,记录了一个软件系统需要满足的功能和性能要求。

它是一个软件开发项目的重要组成部分,决定了开发团队将开发的软件系统的范围和特征。

同时,它也是开发人员、测试人员、业务人员、客户和管理者之间交流的重要媒介。

二、需求规格说明书的重要性1. 确定方向,避免偏差需求规格说明书定义了软件开发项目的范围和要求。

在软件开发的过程中,可能会面临许多决策,如果没有清晰的目标依据,可能会迷失方向,甚至出现开发偏差。

通过编写需求规格说明书,团队成员可以确保对整个软件项目有一个共同的理解,并避免对产品范围的混淆。

同时,它也为项目负责人提供了一个确定开发进程的准确方法。

2. 保持一致性需求规格说明书为所有软件开发项目参与者提供了一致性的参考点。

这将确保所有的团队成员,包括开发人员、测试人员和业务人员,都了解软件项目的目标。

这将确保开发团队按照相同的标准进行开发和测试,而不会出现任何混乱,导致项目时间表的延迟和麻烦。

3. 提高效率,控制开发成本在编写需求规格说明书的过程中,团队成员能够更仔细地审核项目需求。

这样可以避免在开发过程中对问题进行不必要的更改,从而提高团队的工作效率,缩短项目发布时间,同时减少软件开发过程中的成本。

三、如何发挥需求规格说明书的作用为了使需求规格说明书发挥它的作用并达到预期的效果,编写它时需要遵循以下原则:1. 明确而详细地概述需求规格说明书需要提供足够的细节和定义,以便团队成员在理解细节时可以有一个相同的基线。

软件工程中软件需求规格说明书编写研究

软件工程中软件需求规格说明书编写研究

软件工程中软件需求规格说明书编写研究软件工程是通过系统化、规范化和可量化的方式开发、操作和维护软件的一门学科。

在软件开发过程中,软件需求规格说明书(Software Requirements Specification,SRS)是一个关键的文档,用于明确、定义项目的功能、性能和其他需求。

它作为开发团队和客户之间的沟通桥梁,确保软件的设计和实现符合用户的期望。

本文将探讨如何编写合格的SRS,解释其重要性,并提供一些实践建议。

I. 软件需求规格说明书的重要性软件需求规格说明书在项目开发过程中起到至关重要的作用,它有以下几个方面的重要性:1. 建立共同理解:SRS为开发团队和客户提供了一个共同理解的基础。

通过清晰、精确地定义需求,可以避免误解和沟通障碍。

这有助于确保开发团队在设计和实现过程中忠实地满足用户的目标和期望。

2. 明确功能和性能需求:SRS中描述的需求对于定义软件的功能和性能至关重要。

它确保开发团队了解应用程序应该如何工作,以满足用户的需求。

同时,它也为测试团队提供了一个标准来验证软件是否按照预期工作。

3. 可追溯性:SRS为软件开发的全过程提供了可追溯性。

它使开发团队能够追溯每个需求是如何转化为设计、测试和实现的。

这对于后续的需求变更、错误修复和软件维护都非常重要。

II. 编写软件需求规格说明书的要点1. 描述业务需求:在SRS中,首先需要详细描述业务需求。

这包括对系统的整体目标和目的的说明。

同时,还要描述系统将如何与其他系统进行交互,以及如何满足用户需求。

2. 明确功能需求:在SRS中,应清晰地定义系统的功能需求。

这包括对系统功能、数据结构、输入和输出、算法和性能等细节的描述。

所有的功能需求应该是明确、无歧义的,以便于开发团队和测试团队理解和实现。

3. 考虑非功能需求:除了功能需求,SRS还应包含系统的非功能需求。

这包括性能要求、可用性、安全性、可靠性、可维护性和可扩展性等方面的需求。

这些需求是软件成功的关键因素之一,因此应在SRS中得到详细说明。

软件需求规格说明书

文档编号:sm/cmmi/1103/系统软件需求规格说明书<版本号>编写人:编写日期:部门:审核人:审核日期:1.引言SRS的引言部分应当提供整个SRS的概述,包括以下各条:a目的;b范围;c定义、简称和缩略语;d引用文件;e综述.1.1.目的本条宜:a描述SRS的目的;b说明SRS的预期读者.1.2.范围本条宜:a通过名称识别要生产/开发的软件产品;b必要时,说明软件产品将做或不做什么;c描述规定的软件的应用,包括相关的收益、目标和目的;d如果上层规格说明如,系统需求规格说明存在,与上层规格说明类似的陈述保持一致.1.3.定义、简写和缩略词本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义,这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供.在本节应对需求的编号规则进行约定.1.4.引用文件本条宜:a提供SRS引用的所有文件的完整清单;b标识出每个文件的名称、报告编号适用时、日期、出版组织;c标明可以获得引用文件的来源.这些信息可以通过引用附录或引用其他文档的方式提供.1.5.综述本条宜:a描述SRS的其余章条包含的内容;b说明SRS是如何组织的.2.总体描述本章宜描述影响产品及其需求的一般因素,而不叙述具体的需求.相反,它提供需求的背景并使它们更易理解,而在SRS的后续章节将详细定义这些需求.本章通常由以下6条组成:a产品描述;b产品功能;c用户特点;d约束;e假设和依赖关系;f需求分配.2.1.产品描述本条宜把产品置于其他有关产品的全景之下.如果产品是独立的和完全自我包含的,这里宜如实给予陈述.正如常出现的那样,如果SRS定义的产品是较大系统的组成部分,则本章宜将软件的功能性与较大系统的需求相联系,而且宜识别软件和系统之间的接口.使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的.本条也宜描述在各种不同的约束下软件如何运行.如,这些约束可包括:a运行环境;b用户界面;c接口;d运行模式;e现场适应性需求等.2.2.产品功能本条宜给出软件将执行主要功能的概要.例如,某个同城程序的SRS可在此部分关注业务发起、资金清算处理,而不涉及这些功能要求的大量细节.有时,本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明如果存在中摘录.为了清晰,应当注意:a功能说明应以使顾客或第一次阅读该文件的任何读者对功能列表容易理解;b可以使用文本或图示的方法,显示不同的功能及其之间的关系.这样的图示不必显示产品的设计,但简要显示功能之间的逻辑关系.2.3.用户特点本条宜给出软件产品预期用户的一般特征,包括部门、角色、权限等.本条所说用户包括系统的隐含用户,例如银行客户.2.4.需求分配本条宜识别可能推迟到系统将来版本的需求.3.具体需求本章宜包括足够详细的所有软件需求,使设计人员能够设计系统以满足这些需求,并且使测试人员能够测试该系统满足这些需求.贯穿本章,对于用户、运行人员或其他外部系统,每个规定的需求应当是外部可理解的.这些需求至少应当包括,每个系统输入激励、每个系统输出响应以及系统通过响应某个输入或支持某个输出所执行的所有功能.对软件功能应根据软件的特征对需求项目进行适当的组织.就面前我公司多数项目而言,应根据软件功能的层次进行组织.对每一项需求应进行唯一编号.主要需求项目编号规则如下:其他类型的需求可在节中定义后使用.对于有层级关系的需求,可用以下方式进行表示:FC_1…FC_2…具体需求分为以下几个部分:3.1.功能需求功能需求宜定义软件在接收和处理输入以及处理和产生输出中必须发生的基本动作.一般情况下使用“系统应……”的方式来陈述.这些包括:a操作的流程;b输入与输出,包括:1数据的来源及输入/输出方式2从输入到输出转换的处理过程3输入/输出界面格式如有的话,例如生成的报表的格式c对输入有效性的核查;d访问的数据对象如数据表及对数据的修改e异常情况响应,包括:1溢出;2错误处理和恢复;尽管将功能需求划分为子功能或子过程可能是适当的,但这并不意味着软件设计同样以这样的方式划分.3.1.1.业务功能1需求编号:FC_0001需求概述:本功能用于实现xxxxxxxx功能优先级:高/中/低3.1.1.1.业务规则以自然语言形式对需求项所必须遵循的处理原则进行说明.形式如:系统应该xxxxxxxxxxxxxxx如xxxxxxxxxxxx,则xxxxxxxxxxx3.1.1.2.前置条件指功能需求进入执行状态需满足的各种条件.以同城系统中“工作场次切换”为例,其前置条件为系统时间到达预先设定的场次终止时间.3.1.1.3.输入包括输入数据的来源、格式、数据要求等3.1.1.4.处理流程以自然语言或流程图、或两者结合的形式描述功能项的处理流程.对处理流程的描述应包括正常处理流程及各种可能的异常处理流程.3.1.1.5.输出完成处理后的数据输出.包括格式、数据要求等.3.1.1.6.后置条件当功能项处理流程结束后产生的处理结果.针对不同的处理流程正常/异常,应分别说明.3.1.1.7.用户界面用草图或屏幕快照的形式展现界面.尽可能使用连串图的形式.3.1.2.业务功能n3.2.性能需求本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求.静态数量化需求可能包括:a支持的终端数量;b支持同时运行的交易并发数量;c要处理的信息量和类型.有时,静态数量需求包含在命名为“能力”的独立部分.动态数量化需求可能包括,如,在正常和高峰工作负载条件,在某时段内处理的事务处理数、任务数和数据量.所有这些需求宜以可测量的方式规定.如:应在小于is内处理95%的交易量.而不是:操作方不需等待事务处理结束.注:适用于某个具体功能的数量化限制,通常作为该功能处理描述部分予以规定.3.3.系统可靠性及安全性需求有一些软件属性可以作为需求.规定所要求的软件属性是重要的,这样才能客观地验证属性的实现情况.具体包括以下内容:a可靠性本条宜规定要求的因素,以便建立在交付时软件系统所要求的可靠性.b可用性为了确保整个系统已定义的可用性程度,宜规定所要求的因素,如,检查点、恢复以及重启动.c安全保密性由于事故、恶意访问、使用、修改、破坏或泄露,本条宜规定需要保护软件的因素.这方面可能的具体需求包括:1使用某些密码技术;2保留某些特定数据组的历史或记录;3分配某些功能到不同的模块;4在程序的某些域间限制通信;5对于关键变量检查数据的完整性.d可维护性本条宜规定与软件本身维护简易性有关的软件属性.可以对模块化、接口和复杂性等有一定的要求.但不宜仅因为是良好设计实践就将其作为需求.e可移植性本条宜规定与软件移植到其他主机和/或操作系统简易性相关的软件属性.这可能包括:1依赖主机代码模块的百分比;2依赖主机代码的百分比;3已证明可移植语言的使用;4特定编译器或语言子集的使用;5特定操作系统的使用.每一项可作为一个小节3.4.其他需求。

软件需求分析说明书模板

保密级别: S资料编号: SRS- -版本: V .[产品型号名称(二号字体)][部件型号名称(可选、小二号字体)]软件需求分析说明书共14页编制:审核:审定:会签:批准:XXXXXXXXXX公司[****]年[**]月[**]日文档修改记录目录1引言 (2)1.1编写目的 (2)1.2范围 (2)1.3定义、首字母缩写词和缩略语 (2)1.4参考资料 (3)2项目概述 (4)2.1产品描述 (4)2.2产品需求 (4)2.2.1功能需求 (4)2.2.2性能需求 (5)2.2.3可服务性需求 (6)2.3用户及用户特点 (6)2.4一般约束 (7)2.5假设和依据 (7)3用例描述 (7)3.1用例1 (8)3.2用例2 (9)3.3用例n (9)4外部接口需求 (9)4.1用户接口 (9)4.2硬件接口 (9)4.3软件接口 (9)4.4通信接口 (10)5设计约束 (10)5.1其他标准的约束 (10)5.2硬件的限制 (11)6属性 (11)6.1可用性 (11)6.2安全性 (11)6.3可维护性 (12)6.4可转移\转换性 (12)6.5警告 (12)7其他需求 (12)7.1数据库 (12)7.2操作 (13)7.3场合适应性需求 (13)8附录 (14)1 [说明: 本模板中的蓝色字体与橙色字体为说明性文字, 在最终提交的文档中请删除这些说明性的文字。

]2 引言2.1 编写目的2.2 说明编写这份软件需求说明书的目的, 指出预期的读者范围。

2.3 范围a.说明:b.待开发的软件系统的名称;c.说明软件将干什么, 如果需要的话, 还要说明软件产品不干什么;1)描述所说明的软件的应用。

应当:2)尽可能精确地描述所有相关的利益、目的、以及最终目标。

2.4 如果有一个较高层次的说明存在, 则应该使其和高层次说明中的类似的陈述相一致(例如, 系统的需求规格说明)。

2.5 定义、首字母缩写词和缩略语列出本文件中用到的专门术语的定义和缩写词的原词组。

srs文档案例

srs文档案例SRS (软件需求规格说明书) 文档是一个重要的软件开发文档,用于明确软件系统的功能需求、性能要求、接口要求等,并提供一个明确的指导,以便软件开发团队能够正确地开发出满足客户需求的软件系统。

下面是一个SRS文档的案例:1. 引言1.1 目的目的是定义和描述一个在线电商平台的功能需求和性能需求。

1.2 范围该软件系统将包括用户注册、商品浏览、购物车管理、订单处理等功能,并且需要支持多用户同时在线访问。

1.3 定义、缩写和缩写表2. 总体描述2.1 产品透视图该系统将由一个后端服务器和一个前端网页应用程序构成,后端服务器负责处理用户请求并管理数据库,前端网页应用程序将提供用户界面。

2.2 用户特点主要用户是注册用户和游客,注册用户将享有更多功能,例如购物车管理和订单处理。

3. 功能需求3.1 用户注册3.1.1 注册表单:用户可以通过填写注册表单来注册账号。

3.1.2 验证机制:系统需要验证用户提供的信息,并确保其唯一性。

3.2 商品浏览3.2.1 商品分类:系统需要将商品按照不同的分类进行展示。

3.2.2 商品搜索:用户可以通过关键字搜索商品。

3.3 购物车管理3.3.1 添加商品:用户可以将商品加入购物车。

3.3.2 修改商品数量:用户可以修改购物车中商品的数量。

3.3.3 删除商品:用户可以从购物车中删除商品。

3.4 订单处理3.4.1 下单:用户可以将购物车中的商品生成订单。

3.4.2 支付:用户可以选择支付方式并完成支付。

4. 性能需求4.1 响应时间:系统需要在用户请求后的3秒内作出响应。

4.2 吞吐量:系统需要支持1000个并发用户同时在线访问。

5. 接口需求5.1 用户界面:系统将提供一个Web用户界面。

5.2 数据库接口:系统将与数据库进行交互。

6. 非功能需求6.1 可靠性:系统需要保证数据的完整性和一致性。

6.2 安全性:系统需要采用安全性措施,防止未经授权的访问和数据泄露。

软件需求模板SRS

XXXXXXXXXXXX设计 ——需求分析姓名:学号:邮箱:指导教师:2010年12月22日12:31:48目录1 文档概述1.1 编写目的1.2 背景1.3 定义1.4 参考资料2 任务概述2.1 目标2.2 用户特点分析2.3 相关事实与假定3 需求概述3.1 系统概述3.2 主题域13.2.1 概述3.2.2 业务事件3.2.3 报表4 具体需求4.1主题域14.1.1 用例模型4.1.2 领域模型5 总体设计5.1 项目规划5.2 系统功能结构图5.3 流程分析5.4 实体分析1 文档概述1.1 编写目的1.2 背景1.3 定义1.4 参考资料2 任务概述2.1 目标2.2 用户特点分析2.3 相关事实与假定3 需求概述3.1 系统概述3.2 主题域13.2.1 概述3.2.2 业务事件3.2.2.1业务事件1(1)业务流程分析(2)业务实体分析(3)用例分析3.2.2.2业务事件23.2.3 报表3.2.3.1报表1(1)概述部门/职位:目的:1.2.3.(2)数据内容(3)报表项3.2.3.2 报表24 具体需求4.1主题域14.1.1 用例模型4.1.1.1 UC_B_XX(用例)(1)概述【编号、名称、概述、相关Stakeholder】(2)事件流描述【前、后置条件,基本、扩展、子事件流】(3)相关需求与功能点(4)界面原型(5)规约与约束4.1.1.2 UC_R_xx(报表)(1)概述【名称、用户部门与职位、业务意图、相关场景】(2)报表内容【领域类图、数据项】(3)输入\输出格式(4)其他4.1.1.3 UC_I_xx(接口)(1)使用者【名称、业务目的、时机、频率】(2)内容与格式【交互过程、数据包说明】(3)设计与实现约束【性能要求、协议格式要求】4.1.2 领域模型4.1.2.1 XX领域类(1)概述【类名、别名】(2)数据窗口分析【涉及主题域、业务事件、各域数据】(3)数据组成与格式(4)其他5 总体设计5.1 项目规划5.2 系统功能结构图5.3 流程分析5.4 实体分析。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件名称 软件需求说明书
1
软件需求说明书提要(SRS)
1 前言
本章提供整个SRS综述。
1.1 目的

这一条包括下列内容:
 描述实际SRS的目的;
 说明SRS所预期的读者。
1.2 范围

 用一个名字标识被生产的软件产品。
 说明软件产品将干什么,如果需要,还要说明软件产品不干什么;
 描述所说明的软件的应用。应当:
 尽可能精确地描述所有相关的利益、目的、以及最终目标。
 如果有一个较高层次的说明存在,则应该使其和高层次说明中的类
似的陈述相一致(例如,系统的需求规格说明)。
1.3 定义、缩写词、略语

本条中必须提供全部需求的术语、缩写词及略语的定义,以便对SRS进行
适当的解释。这些信息可以由SRS的附录提供。也可以参考其他的文件。
1.4 参考资料

本条应包括:
 在SRS中各处参照的文件的全部清单,如经核准的计划任务书,上级机
关批文、合同等;
 列出其他参考资料,如属本项目的其他已发表的文件和主要文献等。每
一个文件、文献要有标题,索引号或文件号,发布或发表日期以及出版
单位;
 详细说明可以得到该参考文件的来源。这个信息可以通过引用附录或其
他文件提供。
软件名称 软件需求说明书
2
2 项目概述
本章应描述影响产品和其需求的一般因素,本章不说明具体的需求,而仅使
需求更易于理解。
2.1 产品描述

这一条是把一个产品用其他有关的产品或项目来描述。
 如果这个产品是独立的,而且全部内容自含,应在此说明;
 如果SRS定义的产品是一个较大的系统或项目中的一个组成部分,那么
本条应包括如下内容;
 要概述这个较大的系统或项目的每一个组成部分的功能,并说明其
接口;
 指出该软件产品主要的外部接口。在这里,不要求对接口详细地描
述,详细描述放在SRS其他章条中;
 描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。
在本条的描述中,用一个方框图来表达一个较大的系统或项目的主要组成
部分、相互联系和外部接口是非常有帮助的。
本条既不用来强迫进行方案的描述,也不是描述在解决总是时的设计约
束。本条应对在以后具体需求一章中说明的设计约束提供理由。
2.2 产品功能

本条是为将要完成的软件功能提供一个摘要。不必把功能所要求的大量的细
节描写出来。有时,如果存在较高层次的规格说明时,则功能摘要可直接从中取
得,这个较高层次的规格说明为软件产品分配了特殊的功能,为了清晰起见,请
注意:
 编制功能的一种方法是制作功能表,以便客户或者第一次读这个文件的
人都可以理解;
 用方框图来表达不同的功能和它们的关系也是有帮助的。但这样的图不
是产品设计时所需求的,只是一种有效的解释性的工具。
这一条不用作陈述具体需求,只是对后来SRS中具体需求一章中为会么要
描述的某些需求提供理由。
软件名称 软件需求说明书
3
2.3 用户特点
本条要描述影响具体需求的产品的最终用户的一般特点。
许多人在软件生存周期的操作和维护阶段与系统相关。而这些人中有用户、
操作员、维护人员和系统工作人员。这些人的某些特点,象教育水平、经验、技
术、专长等,都是施加于系统操作环境的重要约束。如果系统的大多数用户是一
些临时的用户,那么就要求系统包含如何完成基本功能的提示,而不是假设用户
已经从过去的会议或从阅读用户指南中了解到这些细节。
这一条的内容不能用来陈述具体需求或强加若干特殊的设计约束,本条应对
在SRS的具体需求一章之中的某些具体需求或设计约束的描述提供理由。
2.4一般约束

本条对设计系统时限制开发者选择的其他一些项作一般性描述。而这些项将
限定开发者在设计系统时的任选项。这些包括:
 管理方针;
 硬件的限制;
 与其他应用间的接口;
 并行操作;
 审查功能;
 控制功能;
 所需的高级语言;
 通信协议;
 应用的临界点;
 安全和保密方面的考虑。
本条不陈述具体需求或具体设计约束:而对SRS的具体需求一章中为什么
要确定某些具体需求的设计约束提供理由。
2.5 假设和依据

本条列出影响SRS中陈述的需求的每一个因素。这些因素不是软件的设计
约束,但是它们的改变可能影响到SRS中的需求。例如:假定一个特定的操作
系统是在被软件产品指定的硬件上使用的,然而,事实上这个操作系统是不可能
软件名称 软件需求说明书
4
使用的,于是,SRS就要进行相应的改变。
3 具体需求

3.1 功能需求
本条描述软件产品的输入怎样变换成输出。即软件必须完成的基本动作。
对于每一类功能或者有时对于每一个功能,需要具体描述其输入、加工和输
出的需求。这通常由四个部分组成:
3.1.1 引言
这部分描述的是功能要达到的目标、所采用的方法和技术,还应清楚说明功
能意图的由来和背景。
3.1.2 输入
这部分应包括:
1) 详细描述该功能的所有输入数据,如:输入源、数量、度量单位、时间
设定、有效输入范围(包括精度和公差);
2) 操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操
作员的位置。例如:当打印检查时,要求操作员进行格式调整;
3) 指明引用接口说明或接口控制文件的参考资料。
3.1.3 加工
定义输入数据、中间参数,以获得预期输出结果的全部操作。它包括如下的
说明:
1) 输入数据的有效性检查;
2) 操作的顺序,包括事件的时间设定;
3) 异常情况的响应,例如,溢出、通信故障、错误处理等;
4) 受操作影响的参数;
5) 降级运行的要求;
6) 用于把系统输入变换成相应输出的任何方法(方程式、数学算法、逻辑
操作等)。
7) 输出数据的有效性检查。
软件名称 软件需求说明书
5
3.1.4 输出
这部分应包括:
1) 详细描述该功能所有输出数据,例如:输出目的地、数量、度量单位、
时间关系、有效输出的范围(包括精度和公差)、非法值的处理、出错
信息;
2) 有关接口说明或接口控制文件的参考资料。
此外,对着重于输入输出行为的系统来说,SRS应指定所有有意义的输入、
输出对及其序列。当一个系统要求记忆它的状态时,需要这个序列,使得它可以
根据本次输入和以前的状态作出响应。
3.2 性能需求

从整体来说,本条应具体说明软件、或人与软件交互的静态或动态数值需求。
1) 静态数值需求可能包括:
 支持的终端数;
 支持并行操作的用户数;
 处理的文卷和记录数;
 表和文卷的大小。
2) 动态数值需求可能包括:欲处理的事务和任务的数量,以及在正常情况
下和峰值工作条件下一定时间周期中处理的数据总量。
3.3 设计约束

3.3.1 其他标准的约束
本项将指定由现有的标准或规则派生的要求。例如:报表格式、数据命名等
3.3.2 硬件的限制
本项包括在各种硬件约束下运行的软件要求,例如,应该包括:硬件配置的
特点,内存储器和辅助存储器的容量。
3.4 属性

软件的需求还有若干个属性,下面指出其中的几个:
软件名称 软件需求说明书
6
3.4.1 可用性
可以指定一些因素,如检查点、恢复和再启动等,以保证整个系统有一个确
定的可用性级别。
3.4.2 安全性
这里指的是保护软件的要素,以防止各种非法的访问、使用,修改、破坏或
泄密。这个领域的具体需求必须包括:
 利用可靠的密码技术;
 掌握特定的记录或历史数据集;
 给不同的模块分配不同的功能;
 限定一个程序中某些区域的通信;
 计算临界值的检查和。
3.4.3 可维护性
3.4.4 可转移/转换性
这里规定把软件从一种环境移植到另一种环境所要求的用户程序,用户接口
兼容方面的约束等等。
3.4.5 警告
指定所需属性十分重要,它使得人们能用规定的方法去进行客观的验证。
3.5 外部接口需求

3.5.1 用户接口
3.5.2 硬件接口
3.5.3 软件接口
3.5.4 通信接口
3.6 其他需求

相关文档
最新文档