产品软件需求规约SRS

软件需求规格说明软件需求规格说明(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，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）是一个关键的文档，用于明确、定义项目的功能、性能和其他需求。

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

本文将探讨如何编写合格的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.其他需求。

软件需求规格说明书（SRS）
第1章引言
1.1产品的目的
1.2文档约定
1.3风险承担者
1.4 产品的范围
1.5参考文献
第2章系统服务概述
2.1产品的前景
2.2产品的功能
2.3用户类和特征
2.4运行环境
2.5设计和实现上的限制
2.6假设和依赖
第3章外部接口需求
3.1用户界面需求
3.2硬件接口
3.3软件接口
3.4通信接口
第4章系统特性
4.1说明和优先级
4.2激励/响应序列（p173） 4.3功能需求
第5章其它非功能需求
5.1性能需求
5.2安全设施需求
5.3安全性需求
5.4软件质量属性
5.5业务规则
5.6用户文档
第6章其它方面的需求
附录A：术语表
附录B：分析模型
附录C：业务文档和表格
附录D：待确定问题的列表
系统设计阶段的结果是《系统设计报告》。

其主要内容包括：1.系统总体设计方案
•应用软件总体结构设计
•信息系统体系结构设计
•数据库设计
•系统运行环境和软件、硬件配置报告
•系统的网络与通信的设计
2.详细设计
•数据库设计（进一步细化）
•用户界面设计
•输入/输出设计
•处理功能设计
•程序设计说明书。

四川托普集团技术文档卷号：卷内编号：版多层体系政务框架平台之一行政服务中心政务平台软件产品需求规格说明书Software Product Requirements Specification项目承担部门：中央研究院应用产品开发中心撰写人（签名）：完成日期：本文檔使用部门：■主管领导■项目组□客户（市场）■维护人员□用户文档验交组（签名）：验交日期：评审负责人（签名）：评审日期：软件产品需求规格说明书Software Product Requirements Specification 1.引言1.1. 目的本节描述软件产品需求规格说明书（SRS）的目的是：定义软件总体要求，作为用户和软件开发人员之间相互了解的基础；提供性能要求、初步设计和对用户影响的信息，作为软件人员进行软件结构设计和编码的基础；作为软件总体测试的依据。

1.2. 定义Workflow ：工作流1.3. 参考资料行政服务中心政务平台白皮书行政服务中心政务平台项目审批表2.软件总体概述2.1. 软件标识软件全称：多层体系政务框架平台之一行政服务中心政务平台软件简称： XZFWZXZW版本号：2.2. 软件描述2.2.1. 系统属性行政服务中心是改革开放进程中一项新生事物，是实践江总书记“三个代表”重要思想的具体表现，是改善投资环境，扩大开放，吸收外来投资，加快发展的重要举措。

为了实现行政服务中心“一站式集中，一条龙服务”，为全社会提供平等竞争的市场条件和长期稳定的投资环境，塑造廉洁，规范，高效的政府形象的目标，充分利用信息化技术，建设先进实用的可扩展性强的行政服务信息系统，实现行政服务信息处理的智能化、网络化、“无纸化”成为一项迫切的工作。

为此，托普集团根据行政服务中心的业务需求，设计了行政服务中心政务平台。

2.2.2. 开发背景开发目的： 1、公众服务2、行政服务中心和各级政府部门应用目标：行政服务机构使用范围：行政服务机构，公众2.3. 软件功能 (共 12 个系统模块 )序号功能名称功能需求标识1 系统门户L12 办件管理L23系统管理L34 触摸屏查询L45 决策分析L56 考核管理L67 数据整合L78内部办公L89CA认证L910 收费管理L1011 网站发布L1112 流程自定义L12 优先级简要解释高用户操作的入口高是本系统的核心子系统，负责对网上受理和大厅受理的办件业务依据中心项目管理办法和办件规则进行报批、批复、办理。

软件需求说明书的规范样本一、编写目的软件需求说明书的编制是为了使用户和软件开发者双方对该软件的运行环境、功能和性能需求的初始规定有一个共同的理解，使之成为整个开发工作的基础，为概要设计提供需求说明。

二、主要内容及写作要求1、引言1.1 目的a. 说明开发本软件的目的；b. 说明编写本软件说明书的目的；c. 说明软件需求说明所预期的读者。

1.2 背景a．标识要开发的软件产品（名称，代码）；b．列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户；c．说明该软件产品与其它有关软件产品的相互关系。

1.3 参考资料a. 列出本项目经核准的任务书或合同和上级机关的批文；b. 列出编写本软件需求说明书时参考的文件、资料、技术标准以及它们的作者、标题、编号、发布日期和出版单位等。

1.4 术语列出本软件需求说明书中专门术语的定义以及英语缩写词的原词组。

2、项目概述2.1 被开发软件的一般描述描述被开发软件的主要组成，相互联系和外部接口，可用系统流程图的层次结构描述，如图1：图1 层次结构图示例2.2 被开发软件的功能简述被开发软件的功能，可用系统流程图的层次结构描述。

必须采用设计工具，如：PowerDesigner，来进行。

2.3 实现语言列出所采用的编程语言。

2.4 用户特点描述最终用户具有的受教育水平、工作经验及技术专长。

2.5 一般约束给出影响承办单位在设计软件时的约束条款和当需求发生变化时该软件对这些变化的适应能力即灵活性的需求。

3、具体需求3.1 功能需求用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。

对每一类功能，按下述四小节描述。

（必须采用设计工具，如：PowerDesigner来进行，报告可不遵从下面的格式）。

3.1.1 引言a. 描述该软件功能及使用方法；b. 列出与功能有关的背景材料。

XX 软件需求规格说明书拟制日期yyyy-mm-dd 评审人日期yyyy-mm-dd 批准日期yyyy-mm-dd 签发日期yyyy-mm-dd修订记录分发记录目录1简介 (6)1.1目的 (6)1.2范围 (6)2总体概述 (6)2.1软件概述 (6)2.1.1项目介绍 (6)2.1.2产品环境介绍 (6)2.2软件功能 (6)2.3用户特征 (7)2.4假设和依赖关系 (7)3具体需求 (7)3.1功能需求 (7)3.1.1功能需求1 (7)3.2性能需求 (9)3.2.1性能需求1 (9)3.3外部接口需求 (9)3.3.1用户接口 (9)3.3.2软件接口 (10)3.3.3硬件接口 (10)3.3.4通讯接口 (10)4总体设计约束 (11)4.1标准符合性 (11)4.2硬件约束 (11)4.3技术限制 (11)5软件质量特性 (13)6依赖关系 (13)7其他需求 (13)7.1数据库 (13)7.2操作 (13)7.3本地化 (13)8需求分级 (13)9待确定问题 (14)10附录 (14)10.1附录A 可行性分析结果 (14)10.2附录B 需求建模 (14)10.2.1数据流图 (14)10.2.2数据字典 (14)表目录No table of contents entries found.图目录No tableof contents entries found.XX 软件需求规格说明书关键词：能够体现文档描述内容主要方面的词汇。

摘要：缩略语清单：对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。

1简介1.1目的这部分要描述文档的目的。

应该指明读者。

说明本需求文档描述了哪个产品的软件需求。

1.2范围本节应描述文档所包括和不包括的内容。

2总体概述本节描述影响产品和产品需求的一般因素。

由以下4个部分构成。

有一点需说明的是本节不描述具体的需求，只是使那些将要描述的具体需求更易于理解。

需求分析中需求规格SRS模板SRS Template(Software Requirements Specification)推荐的SRS编写方法：1、自然语言描述的结构化文档2、图形化模型，比如Rose等UML本SRS模板给出结构化文档的建议格式目录1 引言91.1 目的91.2 产品范围91.3 预期的读者和阅读建议91.4 文档约定91.5 定义、首字母缩写词和缩略语91.6 参考文献102 整体说明102.1 功能概述102.1.1 主要功能102.1.2 其它功能122.2 分析模型132.2.1 用例图132.2.1 流程图132.2.1 状态图132.2.2 类图152.3 用户特征152.4 需求特殊要求162.5 假定和约束163 接口需求163.1 用户界面16（用户界面是解决方案，属于设计的范畴，不是需求。

但通过界面原型可以更好地理解需求）（界面原型，目的是概念、理解，实现时不一定遵循。

增强交流，但不对开发进行限制，也不要增加变更管理的负担）（建议用户界面的细节，写入一个独立的用户界面文档，不要写在需求规格中）3.1.2 主界面173.1.2.1 界面原型183.1.2.2 界面内容及说明213.2 硬件接口503.3 软件接口503.4 通信接口504 功能需求504.1 功能列表及优先级504.2 功能名514.2.1 说明和优先级514.2.3 用户特征524.2.4 [可选]业务流程524.2.5 [可选]业务说明524.2.6 [可选]用户动作/系统响应序列（用例的方式，如果必要的话。

并非所有功能需求都和用例对应）4.2.7 功能需求524.2.8 [可选]数据要素（只是相关的数据要素，不是数据结构，数据结构整体给出，否则容易引起不一致性、缺乏整体性等问题）5 非功能性需求665.1 系统需求665.1.1 硬件要求665.1.2 软件要求675.1.3 设计和实现上的限制675.2 性能需求67软件的“时间-空间”效率，而不仅是指软件的运行速度。