XXX项目
软件需求规格说明书
XXXX
20 年月日
文档信息
修订历史
文档编制、审核与批准
目录
1引言 (1)
1.1 目的 (1)
1.2范围 (1)
1.3定义、简写和缩略语 (1)
1.4引用文件 (1)
1.5综述 (2)
2总体描述 (2)
2.1产品描述 (2)
2.1.1系统接口 (2)
2.1.2用户界面 (2)
2.1.3硬件接口 (3)
2.1.4软件接口 (3)
2.1.5通信接口 (3)
2.1.6内存约束 (3)
2.1.7操作 (3)
2.1.8现场适应性需求 (4)
2.2产品功能 (4)
2.3用户特点 (4)
2.4约束 (4)
2.5假设和依赖关系 (5)
2.6需求分配 (5)
3具体需求 (5)
3.1外部接口 (5)
3.2功能 (6)
3.3性能需求 (7)
3.4数据库逻辑需求 (8)
3.5设计约束 (8)
3.5.1标准依从性 (8)
3.6软件系统属性 (8)
3.6.1可靠性 (9)
3.6.2可用性 (9)
3.6.3安全保密性 (9)
3.6.4可维护性 (9)
3.6.5可移植性 (9)
3.7具体需求的组织 (9)
3.7.1系统模式 (10)
3.7.2用户类型 (11)
3.7.3对象 (11)
3.7.4特征 (11)
3.7.5激励 (11)
3.7.6响应 (11)
3.7.7功能层次 (11)
3.8附加说明 (12)
4附录 (12)
1引言
本部分应当提供整个SRS的概述
1.1 目的
本条宜：
a)描述SRS的目的；
b)说明SRS的预期读者。
1.2范围
本条宜：
a)通过名称识别要生产／开发的软件产品(例如，宿主数据库管理系统(DBMS)、报告生成器等）；
b)必要时，说明软件产品将做或不做什么；
c)描述规定的软件的应用，包括相关的收益、目标和目的；
d)如果上层规格说明（如，系统需求规格说明）存在，与上层规格说明类似的陈述保持一致。
1.3定义、简写和缩略语
本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义，这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供。
1.4引用文件
本条宜：
a)提供SRS引用的所有文件的完整清单；
b)标识出每个文件的名称、报告编号（适用时）、日期、出版组织；
c)标明可以获得引用文件的来源。
这些信息可以通过引用附录或引用其他文档的方式提供。
1.5综述
本条宜：
a)描述SRS的其余章条包含的内容；
b)说明SRS是如何组织的。
2总体描述
本章宜描述影响产品及其需求的一般因素，而不叙述具体的需求。相反，它提供需求的背景并使它们更易理解，而在SRS的第3章将详细定义这些需求。
2.1产品描述
本条宜把产品置于其他有关产品的全景之下。如果产品是独立的和完全自我包含的，这里宜如实给予陈述。正如常出现的那样，如果SRS定义的产品是较大系统的组成部分，则本章宜将软件的功能性与较大系统的需求相联系，而且宜识别软件和系统之间的接口。
使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的。
本条也宜描述在各种不同的约束下软件如何运行。如，这些约束可包括：
a)系统接口；
b)用户界面；
c)硬件接口；
d)软件接口；
e)通信接口；
f)内存；
g)运行；
h)现场适应性需求等。
2.1.1系统接口
本条宜列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。
2.1.2用户界面
本条宜规定以下方面：
a)在软件产品与用户之间每个界面的逻辑特征。这包括完成软件需求所需要的那些配
置特征（例如，要求的屏幕显示格式、页面或窗口版式布局、任何报告或菜单的内
容、或者可编程功能键的设置）；
b)优化系统用户界面的所有方面。这可以简单地包括一个针对系统对用户的显示方式
系统将做什么和不做什么的清单。例如，可能是一项选择长或短的错误消息方面的
需求。如同所有其他需求一样，这些需求宜是可验证的，例如，“经过th培训后，4级打字员能够在Zrnln内执行功能X”，而不是“打字员能够执行功能X”（这也可
以在标题为使用方便性章条的软件系统属性中规定）。
2.1.3硬件接口
本条宜规定系统硬件各部件与软件产品之间每个接口的逻辑特征，包括配置特征
（端口数量、指令集等），同样也覆盖这些事项，如，支持什么设备、如何支持以及采
用什么协议。例如，相对逐行支持，终端支持可能规定为全屏支持。
2.1.4软件接口
本条宜规定对其他软件产品（例如，数据管理系统、操作系统、或数学软件包）的
使用，以及与其他应用系统（例如，账户接收系统和一般的会计记帐系统的链接）的接
口。对于每个要求的软件产品，宜提供：
a)名称；
b)助记符；
c)规格说明编号；
d)版本号；
e)来源。
对于每个接口，宜提供：
a)相对此软件产品，接口软件的目的的论述；
b)按照消息内容和格式对接口的定义，不必要详细描述任何已文件化的接口，但要求
引用定义此接口的文件。
2.1.5通信接口
本条宜定义不同的通信接口，如，局域网协议等。
2.1.6内存约束
本条宜规定对主存和辅存的任何适用特征和限制。
2.1.7操作
本条宜规定用户要求正常的和特定的操作，如：
a)用户组织的不同操作模式（如，用户引发的操作）；
b)交互操作的周期和无人值守操作的周期；
c)数据处理支持功能；
d)备份和恢复操作。
注：有时此条规定作为用户界面的一部分。
2.1.8现场适应性需求
本条宜：
a)对于给定的现场、任务或运行模式（如，网格数、安全限制等），为任何数据或启
动顺序定义需求；
b)针对软件适应特定的安装现场或任务，规定应当修改的特征。
2.2产品功能
本条宜给出软件将执行主要功能的概要。例如，某个会计程序的SRS可在此部分关注顾客账户维护、顾客财务报表及发票准备，而不涉及这些功能要求的大量细节。
有时，本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明（如果存在）中摘录。为了清晰，应当注意：
a)功能宜以这样的方式组织，以使顾客或第一次阅读该文件的任何读者对功能列表容
易理解；
b)可以使用文本或图示的方法，显示不同的功能及其之间的关系。这样的图示不必显
示产品的设计，但简要显示变量之间的逻辑关系。
2.3用户特点
本条宜给出软件产品预期用户的一般特征，包括教育程度、经验、专业技术情况。它不宜指出具体的需求，但宜给出SRS第3章中为何规定某些具体需求的原因。
2.4约束
本条宜给出将会限制开发人员选择的任何其他事项的一般描述。这些包括：
a)法规政策；
b)硬件局限（如，信号时间要求）；
c)与其他应用的接口；
d)并行操作；
e)审核功能；
f)控制功能；
g)高级语言需求；
h)信号握手协议(如，XON-XOFF、ACK-NACK)；
i)可靠性需求；
j)应用的关键性；
k)安全和保密安全考虑。
2.5假设和依赖关系
本条宜列出影响SRS规定需求的每个因素。这些因素不是软件设计的限制条件，但是，它们的任何变更可能影响SRS中的需求。例如，某个假设可能是软件产品指定的硬
件具有某个特定操作系统，如果事实上该操作系统不能使用，那么SRS将做相应的修改。2.6需求分配
本条宜识别可能推迟到系统将来版本的需求。
3具体需求
本章宜包括足够详细的所有软件需求，使设计人员能够设计系统以满足这需求，并
且使测试人员能够测试该系统满足这些需求。贯穿本章，对于用户、运行人员或其他外
部系统，每个规定的需求应当是外部可理解的。这些需求至少应当包括，每个系统输入（激励）、每个系统输出（响应）以及系统通过响应某个输入或支持某个输出所执行的
所有功能。由于这通常是SRS篇幅最大和最主要部分，以下原则适用：
a)规定的具体需求宜符合GB/T 9385-2008 4.4描述的所有特征；
b)具体需求宜引用较早的相关文件；
c)所有的需求宜是唯一可标识的；
d)宜注意需求的组织，使其具有最大的可读性。
在考察组织需求的具体方式之前，了解GB/T 9385-2008 5.4.1到5.4.7组成需求的各个不同项是有益的。
3.1外部接口
本条宜是软件系统所有输入和输出的详细描述。它宜是对GB/T 9385-2008 5.2的
接口描述的补充，不宜重复前面已有的信息。
宜包括以下内容和格式：
a)项的名称；
b)目的描述；
c)输入源和输出目的地；
d)有效范围、准确度和／或容限；
e)测量单位；
f)定时；
g)与其他输入／输出的关系；
h)屏显格式／组织；
i)窗口格式／组织；
j)数据格式；
k)命令格式；
l)结束消息。
3.2功能
功能需求宜定义软件在接收和处理输入以及处理和产生输出中必须发生的基本动作。一般情况下使用“系统应……”的方式来陈述。
这些包括：
a)对输入有效性的核查；
b)操作的准确顺序；
c)异常情况响应，包括：
1)溢出；
2)通信设施；
3)错误处理和恢复；
d)参数影响；
e)输入与输出的关系，包括：
1)输入／输出顺序；
2)从输入到输出转换的公式。
尽管将功能需求划分为子功能或子过程可能是适当的，但这并不意味着软件设计同样以这样的方式划分。
3.2.1信息流
3.2.1.1数据流图1
3.2.1.1.1数据实体
3.2.1.1.2有关的过程
3.2.1.1.3拓扑图
3.2.1.2数据流图2
3.2.1.2.1数据实体
3.2.1.2.2有关的过程
3.2.1.2.3拓扑图
:
3.2.1.n数据流图n
3.2.1.n.1数据实体
3.2.1.n.2有关的过程
3.2.1.n.3拓扑图
3.2.2过程描述
3.2.2.1过程1
3.2.2.1.1输入数据实体
3.2.2.1.2过程算法或公式
3.2.2.1.3受影响的数据实体
3.2.2.2过程2
3.2.2.2.1输入数据实体
3.2.2.2.2过程算法或公式
3.2.2.2.3受影响的数据实体
:
3.2.2.m过程m
3.2.2.m.1输入数据实体
3.2.2.m.2过程算法或公式
3.2.2.m.3受影响的数据实体
3.2.3数据构建规范
3.2.3.1构建1
3.2.3.1.1记录类型
3.2.3.1.2组成字段
3.2.3.2构建2
3.2.3.2.1记录类型
3.2.3.2.2组成字段
:
3.2.3.p构建p
3.2.3.p.1记录类型
3.2.3.p.2组成字段
3.2.4数据词典
3.2.
4.1数据元素1
3.2.
4.1.1名称
3.2.
4.1.2表示法
3.2.
4.1.3单位／格式
3.2.
4.1.4精确度／准确度
3.2.
4.1.5范围
3.2.
4.2数据元素2
3.2.
4.2.1名称
3.2.
4.2.2表示法
3.2.
4.2.3单位／格式
3.2.
4.2.4精确度／准确度
3.2.
4.2.5范围
3.2.
4.q数据元素q
3.2.
4.q.1名称
3.2.
4.q.2表示法
3.2.
4.q.3单位／格式
3.2.
4.q.4精确度／准确度
3.2.
4.g.5范围
3.3性能需求
本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求。静态数量化需求可能包括：
a)支持的终端数量；
b)支持同时运行的用户数量；
c)要处理的信息量和类型。
有时，静态数量需求包含在命名为“能力”的独立部分。
动态数量化需求可能包括，如，在正常和高峰工作负载条件，在某时段内处理的事务处理数、任务数和数据量。
所有这些需求宜以可测量的方式规定。如：
应在小于Is内处理95%的交易量。
而不是：
操作方不需等待事务处理结束。
注：适用于某个具体功能的数量化限制，通常作为该功能处理描述部分予以规定。
3.4数据库逻辑需求
宜规定将置于数据库的任何信息的逻辑需求。这可包括：
a)不同功能使用的信息类型；
b)使用频度；
c)访问能力；
d)数据实体及其之间的关系；
e)完整性约束；
f)数据保存需求。
3.5设计约束
宜规定可能由其他标准、硬件局限等引发的设计约束。
3.5.1标准依从性
本条宜规定来自现存标准或法规的需求。它们可能包括：
a)报告格式；
b)数据命名；
c)会计规程；
d)审核追踪。
例如，可以规定追踪处理活动的软件需求。为了最低满足法规或财务标准，对于某些应用这样的追踪是需要的。例如，审核追踪需求可能规定，对于支付薪金数据库的所有变更，必须在一个追踪文档中记录支付前后的数额。
3.6软件系统属性
有一些软件属性可以作为需求。规定所要求的软件属性是重要的，这样才能客观地验证属性的实现情况。GB/T 9385-2008 5.4.6.1到5.4.6.5给出了部分示例。
3.6.1可靠性
本条宜规定要求的因素，以便建立在交付时软件系统所要求的可靠性。
3.6.2可用性
为了确保整个系统已定义的可用性程度，宜规定所要求的因素，如，检查点、恢复以及重启动。
3.6.3安全保密性
由于事故、恶意访问、使用、修改、破坏或泄露，本条宜规定需要保护软件的因素。这方面可能的具体需求包括：
a)使用某些密码技术；
b)保留某些特定数据组的历史或记录；
c)分配某些功能到不同的模块；
d)在程序的某些域间限制通信；
e)对于关键变量检查数据的完整性。
3.6.4可维护性
本条宜规定与软件本身维护简易性有关的软件属性。可以对模块化、接口和复杂性等有一定的要求。但不宜仅因为是良好设计实践就将其作为需求。
3.6.5可移植性
本条宜规定与软件移植到其他主机和／或操作系统简易性相关的软件属性。这可能包括：
a)依赖主机代码模块的百分比；
b)依赖主机代码的百分比；
c)已证明可移植语言的使用；
d)特定编译器或语言子集的使用；
e)特定操作系统的使用。
3.7具体需求的组织
除了微小的系统之外，任何系统倾向有大量的详细的需求。由此，宜仔细考虑这些需求的组织方式，以最优化可理解性。对于所有的系统不存在单一的最优化组织方式。不同类型的系统SRS的第3章有不同的需求组织方式。GB/T 9385-2008 5.4.7.1到5.4.7.7描述了一些组织方式。
3.7.1系统模式
依赖于运行模式，某些系统的行为显著不同。例如,根据其运行模式:培训、正常运行或者应急,某
个控制系统可能具有不同的功能集合。当按照运行模式组织该部分时，宜采用第 A.1章或第A.2章的提纲。需求组织方式的选择取决于系统接口和性能是否依赖于运行模式。
3.7.2用户类型
有些系统对不同的用户提供不同的功能集合。例如，对于一般乘客、维护人员和消防人员，电梯控制系统显示不同的能力。当按照用户类别组织该部分时，宜采用第A．3章的提纲。
3.7.3对象
对象是现实世界中的实体，系统具有与其对应的部分。例如，在病人监控系统中，对象包括病人、传感器、护士、房间、医师、医药等。与每个对象相联系的是一组属性（对象具有的）和功能（对象执行的），这些功能也称之为服务、方法或过程。当按照对象组织该部分时，宜采用第A.4章的提纲。应注意，对象组可能共有某些属性和服务，要按照类别把这些组织在一起。
3.7.4特征
系统特征是从外部希望得到的服务，可能要求一系列的输入以产生希望的结果。例如，在电话系统中，系统特征包括本地话务、话务转接、以及会议话务。一般的，系统每个特征按照一系列激励一响应对的方式描述。当按照系统特征组织该部分时，宜采用第A.5章的提纲。
3.7.5激励
某些系统可以根据激励描述其功能的方式最佳地组织其需求。例如，飞机自动着陆系统的功能，可依照动力降低、风向切变、机身摇摆突变、垂直速度限值等，组织到相应的部分。当按照激励方式组织该部分时，宜采用第A．6章的提纲。
3.7.6响应
有些系统可以通过描述其支持产生某个响应的所有功能，最佳地组织其需求。例如，某个人员管理系统的功能，可按照与产生薪金支付有关的所有功能、与产生当前职员清单有关的所有功能，等等，予以组织到相应的部分。宜采用第A.6章的提纲（所有的激励之处由响应替代）。
3.7.7功能层次
当上述组织方式证明没有益处时，可按照共同的输入、共同的输出或者共同的内部数据访问，将系统总体功能性组织成为一个功能层次。数据流图和数据词典可以用来表示功能和数据之间的相互关系。当按照功能层次组织该部分时，宜采用第A.7章的提纲。
3.8附加说明
在编制新的SRS时，在GB/T 9385-2008 5.4.7.7给出的多种组织技术可能都是适用的。在这种情况下，宜依据该系统的特定要求所剪裁出的若干层次来组织特定的需求。例如，第A．8章组织形式结合了用户类别和系统特征。任何附加的需求，可以在SRS的结尾处放在一个独立的部分。
有许多现行可用于帮助需求文档化的符号、方法和自动化支持工具。就大部分而言，它们的有效性是组织的职能。例如，当按照运行模式组织时，限定的状态机或状态图表可能证明是有益的；当按照对象组织时，面向对象的分析可能是有益的；当按照系统特征组织时，激励一响应序列可能证明是有益的；当按照功能结构组织时，数据流图和数据词典可能证明是有益的。
在第A.1章到第A.8章给出的任何提纲中，称为“功能需求I”的那些条目可以用自然语言、伪码、系统定义语言、或用标题为引言、输入、处理、输出4个子部分予以描述。
4附录
附录并不总是实际的SRS的一部分或总是需要的。附录可以包括：
a)输入／输出格式示例，成本分析研究，或者用户调查的结果；
b)有助于读者理解SRS的支持或背景信息；
c)软件所解决的问题描述；
d)对代码和媒体的特殊包装说明，以满足安全、出口、初始装入、或其他需求。
当包括附录时，SRS宜明确地规定附录是否作为需求的部分。
XXX项目 软件需求规格说明书 XXXX 20 年月日
文档信息 修订历史 文档编制、审核与批准
目录 1引言 (1) 1.1 目的 (1) 1.2范围 (1) 1.3定义、简写和缩略语 (1) 1.4引用文件 (1) 1.5综述 (2) 2总体描述 (2) 2.1产品描述 (2) 2.1.1系统接口 (2) 2.1.2用户界面 (2) 2.1.3硬件接口 (3) 2.1.4软件接口 (3) 2.1.5通信接口 (3) 2.1.6内存约束 (3) 2.1.7操作 (3) 2.1.8现场适应性需求 (4) 2.2产品功能 (4) 2.3用户特点 (4) 2.4约束 (4) 2.5假设和依赖关系 (5) 2.6需求分配 (5) 3具体需求 (5) 3.1外部接口 (5) 3.2功能 (6) 3.3性能需求 (7) 3.4数据库逻辑需求 (8) 3.5设计约束 (8) 3.5.1标准依从性 (8) 3.6软件系统属性 (8) 3.6.1可靠性 (9) 3.6.2可用性 (9) 3.6.3安全保密性 (9) 3.6.4可维护性 (9) 3.6.5可移植性 (9) 3.7具体需求的组织 (9) 3.7.1系统模式 (10) 3.7.2用户类型 (11) 3.7.3对象 (11) 3.7.4特征 (11) 3.7.5激励 (11) 3.7.6响应 (11) 3.7.7功能层次 (11)
3.8附加说明 (12) 4附录 (12)
1引言 本部分应当提供整个SRS的概述 1.1 目的 本条宜： a)描述SRS的目的； b)说明SRS的预期读者。 1.2范围 本条宜： a)通过名称识别要生产／开发的软件产品(例如，宿主数据库管理系统(DBMS)、报告生成器等）； b)必要时，说明软件产品将做或不做什么； c)描述规定的软件的应用，包括相关的收益、目标和目的； d)如果上层规格说明（如，系统需求规格说明）存在，与上层规格说明类似的陈述保持一致。 1.3定义、简写和缩略语 本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义，这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供。 1.4引用文件 本条宜：
保密级别：S 资料编号：SRS-[产品代号] -[序列号] 版本：V[*].[*] [产品型号名称（二号字体）] [部件型号名称（可选、小二号字体）] 软件需求分析说明书 共11页 编制： 审核： 审定： 会签： 批准： XXXXXXXXXX公司 [****]年[**]月[**]日
文档修改记录
目录 1引言 (2) 1.1编写目的 (2) 1.2范围 (2) 1.3定义、首字母缩写词和缩略语 (2) 1.4参考资料 (2) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (3) 2.2.1功能需求 (3) 2.2.2性能需求 (4) 2.2.3可服务性需求 (4) 2.3用户及用户特点 (4) 2.4一般约束 (5) 2.5假设和依据 (5) 3用例描述 (5) 3.1用例1 (5) 3.2用例2 (6) 3.3用例n (6) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (7) 4.3软件接口 (7) 4.4通信接口 (8) 5设计约束 (8) 5.1其他标准的约束 (8) 5.2硬件的限制 (8) 6属性 (8) 6.1可用性 (8) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移＼转换性 (9) 6.5警告 (9) 7其他需求 (9) 7.1数据库 (9) 7.2操作 (10) 7.3场合适应性需求 (10) 8附录 (10)
[说明：本模板中的蓝色字体与橙色字体为说明性文字，在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义、首字母缩写词和缩略语 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
某银行 XX业务需求说明书 提出部门：xxxx部xxxx年xx月
文档修改记录
签署记录
目录 1.引言 (6) 1.1目的 (6) 1.2背景 (6) 1.3术语和定义 (7) 1.4业务规范与标准 (7) 1.5参考资料 (8) 2.需求目标 (9) 2.1用户描述 (9) 2.2业务价值 (9) 2.3业务现状 (10) 2.4业务目标 (10) 2.5约束和假设 (10) 3.需求范围 (11) 3.1范围概述 (11) 3.2功能范围 (11) 3.3数据范围 (11) 3.4区域/机构范围 (11) 4.功能需求 (12) 4.1功能1（适用于有流程的需求） (12) 4.1.1 功能概述 (12) 4.1.2 业务流程 (12) 4.1.2.1流程节点1 (12) 4.1.2.1.1输入 (12) 4.1.2.1.2处理 (12) 4.1.2.1.3输出 (12) 4.1.2.1.4业务规则 (13) 4.2功能2（适用于无流程的需求） (13) 4.2.1 功能概述 (13) 4.2.2 输入 (13) 4.2.3 处理 (13) 4.2.4 输出 (13) 4.2.5 业务规则 (13) 4.3功能3（适用于数据处理的需求） (13) 4.3.1 功能概述 (13) 4.3.2 输入 (14) 4.3.3 处理 (14) 4.3.4 输出 (14) 5.附件1 (17) 5.1非功能性需求 (17) 5.2数据要求说明书 (17)
5.3需求优先级 (17) 5.4表单及报表样例 (17) 5.5灾备等级评分指标 (17)
WORD文档可编辑 X X X X X X单位 X X X X X X X项目 软件需求规格说明书 金碧信息科技
目录 第一章引言 (5) 1编写目的 (5) 2软件需求分析理论 (5) 3软件需求分析目标 (5) 4参考文献 (6) 第二章需求概述 (7) 1.项目背景 (7) 2.需求概述 (7) 3.条件与限制(可选) (8) 4.移动办公系统结构 (8) 5.移动办公网络拓扑图 (9) 第三章系统功能需求 (10) 1.移动办公系统升级改造需求 (10) 界面显示要求 (11) 待办公文列表 (11) 待办公文列表排序 (11) 公文详细信息界面元素 (11) 网站信息审批 (12) 会议申请 (12) 意见录入 (12) 移动邮件 (12) 会议管理 (13) 通知通告 (13) 通讯录管理 (14) 2.车辆管理模块升级改造需求 (14) 系统功能架构 (14) 网络拓扑结构 (15)
3.电子公文预览需求 (15) 电子公文交换网络 (16) 电子公文交换流程 (18) 4.政务信息管理系统平台功能需求 (19) 第四章软硬件或其他外部系统接口需求 (21) 1.用户界面 (21) 2.硬件需求 (22) 3.网络需求 (22) 4.接口需求 (22) 5.通信需求 (23) 6.运行环境 (23) 第五章其他非功能需求 (24) 1.性能需求 (24) 2.安全设施需求 (25) 3.安全性需求 (25) 4.扩展性需求 (26) 5.可移植性需求 (26)
第一章引言 1编写目的 为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。 2软件需求分析理论 软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 3软件需求分析目标 软件需求分析的主要实现目标： 1)对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一 致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件 需求； 2)了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一 个基准； 3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员
深圳天源迪科信息技术股份有限公司 项目编号/BRS版本：X.X 状态： XXX系统 业务需求说明书 本文件属深圳天源迪科信息技术股份有限公司所有， 未经书面许可，不得以任何形式复印或传播。
文件建立/修改记录
目录 1 简介 (4) 1.1 目的 (4) 1.2 背景 (4) 1.3 适用范围 (4) 1.4 参考资料 (4) 1.5 术语 (4) 2 业务需求 (4) 2.1 <业务需求1> (4) 2.1.1需求来源 (4) 2.1.2需求描述 (4) 2.1.3角色 (4) 2.1.4解决方案 (4) 2.1.5优先级 (5) 2.1.6补充内容 (5) 2.2 <业务需求2> (5) 2.3 <业务需求3> (5) 3 附录 (5)
1简介 1.1目的 【列举说明编写业务需求说明书要达到的目的。】 1.2背景 【可能的相关背景知识介绍。】 1.3适用范围 【说明此文档所适用的范围。】 1.4参考资料 【编写业务说明书时参考的相关资料，需指明出处与时间。】 1.5术语 【对文档中使用到的相关术语、简称作以解释。】 2业务需求 2.1<业务需求1> 2.1.1需求来源 【说明提出此需求的单位及个人。】 2.1.2需求描述 【用户提出的需求简要说明，比如“管理业务”。】 2.1.3角色 【说明与此需求相关的角色。】 2.1.4解决方案 【说明针对用户的问题，所提出的解决方案。如果有多个，可以在此处都列出来。】
2.1.5优先级 【说明此项需求的优先级。】 2.1.6补充内容 【在上面5点之外需要描述的内容。】 2.2<业务需求2> …… 2.3<业务需求3> …… 3附录 【各种需要在本文档中补充说明的附录和附表。】
<教师报课系统> 需求规格说明书 作者：Mod4 完成日期：2015.10.16
修订历史记录
目录 1. 引言 (4) 1.1 目的 (4) 1.2 背景 (4) 1.3 定义 (4) 1.4参考文献 (4) 2. 项目概述 (5) 2.1 产品描述 (5) 2.2 产品功能 (5) 2.3 用户特点 (7) 2.4 一般约束 (7) 2.5 假设与依据 (7) 3. 具体需求 (7) 3.1 功能需求 (8) 3.1.1系统角色及登陆 (8) 3.1.2 学院负责人 (9) 3.1.3 系负责人 (17) 3.1.4 教师 (20) 3.2 外部接口需求 (23) 3.2.1 用户接口 (23) 3.2.2 硬件接口 (23) 3.2.3 软件接口 (23) 3.2.4 通信接口 (23) 3.3 性能需求 (23) 3.4 属性 (23) 3.4.1 可用性 (23) 3.4.2 安全性 (24) 3.4.3 可维护性 (24) 4. 验收验证标准 (24)
1. 引言 1.1 目的 该文档首先给出项目的整体结构和功能结构概貌，试图从总体架构上给出整个系统的轮廓。同时对功能需求、性能需求进行了详细的描述。便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据以及确认测试和验收的依据。 本文档面向多种读者对象： （1）项目经理：项目经理可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。 （2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。 （3）程序员：了解系统功能，编写《用户手册》。 （4）测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。（5）用户：了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。 在阅读本文档时，首先要了解产品的功能概貌，然后可以根据自身的需要对每一功能进行适当的了解。 1.2 背景 本次待开发的软件为教师报课系统。 用户通过使用该软件在移动终端完成报课相关操作。学院负责人通过导入报课信息，设定截止时间来开启报课。系负责人查看报课信息，进行审核修改。教师填写报课信息，预览报课信息等最终提交报课。 1.3 定义 1.4参考文献 [1] GB-T8567-2006，《计算机软件文档编制规范》[S] [2].（美）Roger S.Pressman著，郑人杰等译.软件工程[M].第七版.北京：机械工业出版社,2011.
标识：密级：版本： ××技术文件 {子系统名称} 软件需求规格说明 中国电子科技集团公司第十五研究所 二○一年月
{子系统名称} 软件需求规格说明 拟制： 审核： 会签： 质量保证： 批准：
文档修改记录
目次 1范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.2.1项目背景 (1) 1.2.2业务范围 (1) 1.2.3软件边界 (1) 1.2.4系统角色 (1) 1.3文档概述 (2) 1.4术语及缩略语 (2) 2引用文档 (2) 3功能需求/GN (2) 3.1功能概述 (2) 3.1.1 XX功能/XX功能标识 (3) 3.1.2 YY功能/YY功能标识 (3) 3.2用例 (4) 3.2.1 XX功能/XX功能标识 (4) 3.2.2 YY功能/YY功能标识 (4) 3.3需求动态关系 (5) 3.4用例与建模 (5) 3.4.1 XX功能/XX功能标识 (5) 3.4.2 YY功能/YY功能标识 (7) 4接口需求/JK (8) 4.1外部接口需求/JK-WB (8) 4.1.1接口标识和接口图 (8) 4.1.2人机交互界面接口 (10) 4.1.3 XX接口名称/标识 (10) 4.2内部接口需求/JK-NB (12) 4.2.1接口标识和接口图 (12) 4.2.2 XX接口名称/标识 (12) 5数据需求/SJ (12) 5.1入、出库单/SJ-IOL (12) 5.2数据需求名称/标识 (13)
6非功能性需求 (14) 6.1性能需求 (14) 6.1.1容量估算 (14) 6.1.2性能指标/XN (14) 6.2适应性需求/SY (14) 6.3安全性需求/AQ (14) 6.4保密性需求/BM (15) 6.5备份与恢复/BH (15) 6.6数据移植/YZ (15) 6.7标准需求/BZ (16) 6.8环境需求/HJ (16) 6.8.1硬件环境 (17) 6.8.2软件环境 (17) 6.8.3网络环境 (17) 6.8.4其他环境 (17) 6.9计算机资源需求/ZY (17) 6.10软件质量因素及可靠性/ZK (18) 6.10.1软件质量因素/ZK-YS (18) 6.10.2可靠性需求/ZK-KK (18) 6.11设计和实现约束/YS (18) 6.12需求的关、重程度 (18) 6.13人员需求 (19) 6.14培训需求 (20) 6.15软件保障需求 (20) 6.16验收、交付时的包装需求 (20) 7合格性规定 (20) 8与上级设计文档的可追溯性 (20) 8.1正向追溯 (21) 8.2逆向追溯 (21) 9附件 (21) 9.1界面需求 (21) 9.2导出文档/报表模版格式 (21)
软件需求说明书 （转载自国家计算机标准和文件模板） 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 1.引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1.2 背景 说明： a.待开发的软件系统的名称； b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； c.该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料，如： a.本项目的经核准的计划任务书或合同、上级机关的批文； b.属于本项目的其他已发表的文件； c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2. 任务概述 2.1 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说
明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束。 2.3 假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3. 需求规定 3.1 对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 3.2 对性能的规定 3.2.1 精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 3.2.2 时间特性要求 说明对于该软件的时间特性要求，如对： a.响应时间； b.更新处理时间； c.数据的转换和传送时间； d.解题时间；等的要求。 3.2.3 灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a.操作方式上的变化； b.运行环境的变化；
泵送零部件质量信息化之 自制大件钢印号管理需求分析说明书 Requirement Analysis Document 文档编号： 状态: ■草稿□发布□修改作者:寻浏平、王刚华
文档信息 修改记录
目录 1.引言 (4) 1.1编写目的 (4) 1.2项目背景 (4) 1.3术语定义 (4) 2.业务描述 (4) 2.1目标范围 (4) 2.2业务综述及总体流程 (4) 2.2.1业务流程图 (5) 2.2.2业务需求 (6) 2.3用户特性 (6) 2.4约定假设 (6) 3.功能需求 (7) 3.1 SAP新增自定义字段“钢印号”（F01） (8) 3.1.1功能模块流程图 (8) 3.1.2功能详细描述 (8) 3.2 MES下载订单主数据接口修改（F02） (10) 3.2.1功能模块流程图 (10) 3.2.2功能详细描述 (10) 3.3 MES终端钢印号报工功能修改（F03） (11) 3.4大件SAP/PDA收货功能（F04） (11) 3.5大件SAP/PDA出库钢印号记录功能（F05） (27) 3.6 MES返修订单质检功能（F06） (34) 3.6.1功能模块流程图 (34) 3.6.2功能详细描述 (35) 3.7 SAP大件（钢印号）可用库存查询功能（F06） (37) 4.业务编码规范 (41) 5.非功能性需求 (41) 5.1用户界面需求 (41) 5.2性能及压力需求 (41) 5.3安全需求 (41) 5.4环境需求 (41) 5.5产品质量要求 (42) 6. 批准确认 (42)
1.引言 1.1编写目的 将泵送制造本部钢印号管理业务需求转化为功能需求，为设计、开发、测试、实施人员提供参考依据。 1.2项目背景 目前泵送制造本部所有自制大件实物上都需打钢印号。实物上的钢印号编码是由制造部各工作中心根据既定的规则自行进行编码和打印钢印号的，MES系统只检验时才开始对钢印号与生产订单信息进行关联和记录。为加强对自制大件质量的管控，泵送质保部提出要对钢印号整个生命周期进行管控的需求。经泵送质保本部、泵送制造本部综合管理部、泵送制造本部物料管理部共同商讨决定对泵送自制大件实现从计划下达、生产制造、质量记录、生产返工、装配记录、售后质量追溯全生命周期的管理。 1.3术语定义 钢印号：为实现对自制大件生产过程质量追溯，自制大件组焊完成后在实物上打印的钢字码。钢印号一般包含以下信息：型号、生产日期、流水号等。 2.业务描述 2.1目标范围 泵送制造本部所有自制大件均需实现钢印号管理，先在转塔工作中心（转塔台和转塔座）实现和试用，优化完成后再推广到泵送制造本部其他大件。 2.2业务综述及总体流程 从整体描述项目业务需求及业务流程，相互关联，及总体流程图。
项目名称 软件需求规格说明
文档签署记录
文档修改记录
目录 1 引言 (1) 1.1 目的 (1) 1.2 项目背景 (1) 1.3 范围 (1) 1.4 参考资料 (1) 1.5 综述 (1) 2 总体概述 (2) 2.1 产品描述 (2) 2.2 产品功能 (2) 2.3 用户特点 (2) 2.4 设计约束 (2) 2.4.1 标准规范 (2) 2.4.2 软件开发语言 (2) 2.4.3 软件开发工具和环境 (2) 2.4.4 软件测试环境 (3) 3 具体需求 (4) 3.1 软件流程功能 (5) 3.1.1 流程1 (5) 3.2 功能需求 (7) 3.2.1 试验资源管理 (7) 3.2.2 试验过程管理 (9) 3.3 软件模块划分 (11) 3.4 系统集成接口 (12) 3.4.1 与管理系统的接口 (12) 3.5 性能需求 (12) 3.5.1 精度 (12) 3.5.2 时间特性要求 (12) 3.6 数据处理要求 (12) 3.7 软件质量要求 (13) 3.7.1 易用性 (13) 3.7.2 可靠性 (13) 3.7.3 安全性 (13) 3.7.4 可维护性 (13) 3.8 可靠性、安全性和维护性要求 (13) 3.8.1 软件安全性等级、可靠性指标 (13) 3.8.2 软件运行寿命 (13) 3.8.3 软件安全性要求 (13) 3.8.4 软件健壮性要求 (13) 3.8.5 软件不期望事件要求 (14) 3.8.6 软件维护性要求 (14) 4 运行环境规定 (14) 4.1 部署方案 (14) 4.2 系统运行的硬件环境要求 (14)
XXXXXX 单位
XXXXXXX 项目
软件需求规格说明书
龙子湖网络科技
项目 文档 文档 ID 说明 作者 最后更新时间
项目名称 软件需求规格说明书
V1.2 *** 2011-10-20
版本更新概要 版本号 V1.0
V1.1
V1.2
时间 2011-10-02
2011-10-20
2011-11-08
更新人
更新摘要 移动 OA、车辆管理模块
需求容 移动政务资源管理系统
平台需求容 根据业务需求，电子公
文在线预览
项目负责人审核与确认 供应商：
职位
审核时间
审核意见(签字)
客户方：
目录
第一章 引言 ................................................................... 5
1 编写目的 .................................................................. 5 2 软件需求分析理论........................................................... 5 3 软件需求分析目标........................................................... 5 4 参考文献 .................................................................. 6
第二章 需求概述................................................................ 7
1. 项目背景 .................................................................. 7 2. 需求概述 .................................................................. 7 3. 条件与限制(可选)........................................................... 8 4. 移动办公系统结构........................................................... 8 5. 移动办公网络拓扑图......................................................... 9
第三章 系统功能需求........................................................... 10
1. 移动办公系统升级改造需求.................................................. 10 界面显示要求 ........................................................... 11 待办公文列表 ........................................................... 11 待办公文列表排序 ....................................................... 12 公文详细信息界面元素.................................................... 12 信息审批 ............................................................... 12 会议申请 ............................................................... 12 意见录入 ............................................................... 12 移动 ................................................................... 13 会议管理 ............................................................... 13 通知通告 ............................................................... 14 通讯录管理 ............................................................. 14
2. 车辆管理模块升级改造需求.................................................. 14 系统功能架构 ........................................................... 14 网络拓扑结构 ........................................................... 16
［在此处键入］****系统 软件需求规格说明书Versio n 1.0
精品资料
修订历史记录
目录 1 引言 (5) 1.1 目的与范围 (5) 1.2 预期的读者 (5) 1.3 系统的范围 (5) 1.4 参考资料 (5) 1.5 术语、缩写词 (6) 2 当前系统 (6) 2.1 当前系统概述 (6) 2.2 当前系统存在的问题................................... 错误！未定义书签。 3 建议的系统 .............................................................. 错误！未定义书签。 3.1 建议系统概述......................................... 错误！未定义书签。 3.2 功能性需求概述....................................... 错误！未定义书签。 3.3 非功能性需求......................................... 错误！未定义书签。 3.3.1 用户界面与人员因素............................ 错误！未定义书签。 3.3.2 硬件考虑..................................... 错误！未定义书签。 3.3.3 性能特征..................................... 错误！未定义书签。 3.3.4 错误处理与极端情况............................ 错误！未定义书签。 3.3.5 系统接口..................................... 错误！未定义书签。 3.3.6 质量要求..................................... 错误！未定义书签。 3.3.7 物理环境..................................... 错误！未定义书签。 3.3.8 安全问题..................................... 错误！未定义书签。 3.3.9 资源问题..................................... 错误！未定义书签。 3.4 系统变更............................................. 错误！未定义书签。 3.5 约束( Constraints ) ................................................................................. 错误！未定义书签。 3.6 系统模型............................................. 错误！未定义书签。 3.6.1 用例模型 (6) 3.6.2 对象模型..................................... 错误！未定义书签。 4 附录 .................................................................... 错误！未定义书签。 4.1 NEMA 0183 格式简介 ................................... 错误！未定义书签。
软件需求规格说明书 文件编号：QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (4) 1.1目的 (4) 1.2背景 (4) 1.3术语 (4) 1.4预期读者与阅读建议 (4) 1.5参考资料 (4) 1.6需求描述约定 (5) 2.项目概述 (6) 2.1系统功能 (6) 2.2业务描述 (6) 2.3数据流程描述(可选) (6) 2.4用户的特点 (6) 2.5运行环境要求 (6) 2.6设计和实现上的限制 (6) 3.功能需求的描述 (6) 4.非功能需求 (7) 4.1系统性能要求 (7) 4.2系统安全及保密要求 (7) 4.3系统备份与恢复要求 (7) 4.4系统日志 (7) 5.外部接口说明 (7) 6.其他需求 (8) 7 需求变更识别 (8) 8.功能列表 (8) 9.附件 (8)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
组态建模工具需求规格说明书 西安电子科技大学 2011/5/19
目录
1概述 编写目的 指出编写《需求规格说明书》的目的。下面是示例： 编写此文档的目的是进一步定制软件开发的细节问题，希望能使本软件开发工作更具体。为了使用户、软件开发者及分析和测试人员对该软件的初始规定有一个共同的理解，它说明了本软件的各项功能需求、性能需求和数据需求，明确标识各项功能的具体含义，阐述实用背景及范围，提供客户解决问题或达到目标所需要的条件或权能，提供一个度量和遵循的基准。具体而言，编写软件需求说明的目的是为所开发的软件提出： a)软件设计总体要求，作为软件开发人员、软件测试人员相互了解的基础。 b)功能、性能要求，数据结构和采集要求，重要的接口要求，作为软件设计人员进 行概要设计的依据。 c)软件确认测试的依据。 编写依据 指明该《需求规格说明书》的依据。一般可以写依据XXX软件的方案书，策划书等。术语和缩略词
2软件概要 软件总体描述 从总体上描述该软件的情况，包括软件的形式（网站，运行时系统，插件等）和软件的主要的功能，使读者对该软件有一个整体的认识。一般一两段话即可。 软件设计约束及有关说明 软件设计的约束以及有关说明如下所示。 ●开发环境： ●编程语言： ●遵循的规范：软件的设计和开发过程需要严格按照合同要求，根据软件的设计方 案来进行。软件开发过程应遵循软件工程规范，对过程和版本进行管理和控制。 ●测试环境：可以写明在什么单位测试，测试单位使用的软硬件环境。 ●软件交付形式： ●软件交付日期： ●其他：见合同。 使用者特点 指明软件的使用者具有的特定。示例： 本软件主要在甲方工作环境中使用，使用者包括项目管理人员，开发人员及工程师等，使用者在计算机的应用、使用上不存在障碍，都在计算机的操作和使用方面得到过相关的培训。
软件需求规格说明书 文件编号： QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (2) 1.1目的 (2) 1.2背景 (2) 1.3术语 (2) 1.4预期读者与阅读建议 (2) 1.5参考资料 (2) 1.6需求描述约定 (2) 2.项目概述 (2) 2.1系统功能 (2) 2.2业务描述 (2) 2.3数据流程描述(可选) (2) 2.4用户的特点 (2) 2.5运行环境要求 (2) 2.6设计和实现上的限制 (2) 3.功能需求的描述 (2) 4.非功能需求 (2) 4.1系统性能要求 (2) 4.2系统安全及保密要求 (2) 4.3系统备份与恢复要求 (2) 4.4系统日志 (2) 5.外部接口说明 (2) 6.其他需求 (2) 7 需求变更识别 (2) 8.功能列表 (2) 9.附件 (2)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
软件需求规格说明(SRS) 1范围 1.1标识 本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。 1.2系统概述 本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。 1.3文档概述 本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。 1.4基线 说明编写本系统设计说明书所依据的设计基线。 2引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。 3需求 本章应分以下几条描述CSCI需求，也就是，构成CSCI验收条件的CSCI的特性。CSCI需求是为了满足分配给该CSCI的系统需求所形成的软件需求。给每个需求指定项目唯一标识符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。如果每个需求有关的合格性方法(见第4章)和对系统(若适用，子系统)需求的可追踪性(见5.a条)在相应的章中没有提供，则在此进行注解。描述的详细程度遵循以下规则：应包含构成CSCI验收条件的那些CSCI特性，
需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求的话，本条应如实陈述。如果某个需求在多条中出现，可以只陈述一次而在其他条直接引用。 3.1所需的状态和方式 如果需要CSCI在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式，状态和方式的例子包括：空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。状态和方式的区别是任意的，可以仅用状态描述CSCI,也可以仅用方式、方式中的状态、状态中的方式或其他有效方式描述。如果不需要多个状态和方式，不需人为加以区分，应如实陈述；如果需要多个状态或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其他的方法表示，也可在需求出现的地方加以注解。 3.2需求概述 3.2.1目标 a.本系统的开发意图、应用目标及作用范围(现有产品存在的问题和建议产品所要解决的问题)。 b.本系统的主要功能、处理流程、数据流程及简要说明。 c.表示外部接口和数据流的系统高层次图。说明本系统与其他相关产品的关系，是独立产品还是一个较大产品的组成部分(可用方框图说明)。 3.2.2运行环境 简要说明本系统的运行环境(包括硬件环境和支持环境)的规定。 3.2.3用户的特点 说明是哪一种类型的用户，从使用系统来说，有些什么特点。 3.2.4关键点 说明本软件需求规格说明书中的关键点(例如：关键功能、关键算法和所涉及的关键技术等)。
＜项目名称＞ 软件需求说明书 作者： 完成日期： 签收人： 签收日期：
版本情况记录：
目录 1 引言 (1) 1.1 编写目的 (1) 1.2 范围 (1) 1.3 定义 (1) 1.4 参考资料 (1) 2 项目概述 (2) 2.1 产品描述 (2) 2.2 产品功能 (2) 2.3 用户特点 (2) 2.4 一般约束 (2) 2.5 假设和依据 (3) 3 具体需求 (3) 3.1 功能需求 (3) 3.1.1 功能需求13 3.1.2 功能需求24 3.1.n 功能需求n (5) 3.2 外部接口需求 (5) 3.2.1 用户接口.. 5 3.2.3 软件接口.. 5 3.3 性能需求 (6) 3.5 属性 (7) 3.5.1 可用性 (7) 3.5.2 安全性 (7) 3.5.3 可维护性.. 7 3.5.5 警告 (8) 3.6 其他需求 (8) 3.6.1 数据库 (8) 3.6.2 操作 (8) 3.6.3 场合适应性需求 (9) 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。0.5
1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 项目概述 2.1 产品描述 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 产品功能