需求文档模板.docx

需求文档模板.docx

《需求文档模板.docx》由会员分享，可在线阅读，更多相关《需求文档模板.docx（9页珍藏版）》请在冰豆网上搜索。

需求文档模板

文档编号：

项目编号SRS流水号第版

分册名称：

第册/共册

项目名称（项目编号）

软件需求规约

XXXX有限公司

总页数

正文

附录

生效日期

编制

批准

变更履历

修改编号

版本

修改内容

修改人

修改日期

1.简介1

1.1目的1

1.2范围1

1.3参考资料1

1.4概述1

2.整体说明1

2.1产品总体效果2

2.2假设与依赖关系2

2.3系统运行环境2

2.3.1设备及分布2

2.3.2支撑软件2

3.具体需求2

3.1功能性3

3.1.1功能性需求13

3.2可用性3

3.2.1可用性需求13

3.3可靠性3

3.3.1可靠性需求14

3.4安全性需求4

3.4.1安全性需求14

3.5性能4

3.5.1性能需求15

3.6可支持性5

3.6.1可支持性需求15

3.7设计约束5

3.7.1设计约束15

3.8联机用户文档和帮助系统需求5

3.9购买的构件6

3.10接口/界面6

3.10.1用户界面6

3.10.2硬件接口6

3.10.3软件接口6

3.10.4通信接口6

3.11许可需求6

3.12法律、版权及其他声明6

3.13适用的标准7

4.界面原型7

5.需求优先级7

6.软件功能列表7

7.附件8

1.简介

[软件需求规约（SRS）的简介应提供整个文档的概述。

它应包括软件需求规约的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。

软件需求规约记录对系统或系统的一部分的完整软件需求。

?

以下是一个典型的软件需求规约概述，用于涉及用例建模的项目。

此工件由一个包组成，该包包含用例模型的用例、适合的补充规约以及其他支持信息。

文档的提示性语言请在报告完成时将提示文字删除。

]

1.1目的

[阐明此软件需求规约的目的。

软件需求规约应详细地说明所确定的应用程序或子系统的外部行为。

它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。

]

1.2范围

[简要说明此软件需求规约适用的软件应用程序、特性或其他子系统分组、与其相关的用例模型，以及受到此文档影响的任何其他事物。

]

1.3参考资料

[本小节应完整地列出此软件需求规约中其他部分所引用的所有文档。

每个文档应标有标题、报告号（如果适用）、日期和出版单位。

列出可从中获取这些参考资料的来源。

这些信息可以通过引用附录或其他文档来提供。

]

1.4概述

[此小节应说明软件需求规约其他部分所包含的内容，并解释文档的组织方式。

]

2.整体说明

[软件需求规约的这一节应说明影响产品及其需求的一般因素。

本节并不列出具体的需求，而只是提供在第3节中详述的各种需求的背景，以使这些需求便于理解。

]

2.1产品总体效果

[用技术性语言描述产品的总体需求]

2.2假设与依赖关系

[本节说明所有重要的技术可行性假设、子系统或构件可用性假设，或者可作为此软件需求规约所述软件可行性的基础的其他与项目有关的假设。

]

2.3系统运行环境

[详细说明系统的运行环境]

2.3.1设备及分布

[可以从以下方面进行描述：

1.主机类型

2.网络类型

3.存储器类型、容量

4.其他特殊设备

5.设备分布图]

2.3.2支撑软件

[可以从以下方面进行描述：

操作系统

数据库管理系统

其他支撑软件等]

3.具体需求

[软件需求规约的这一节应包含所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。

]

3.1功能性

[此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。

对于许多应用程序，此节会成为软件需求规约包的主体部分，所以应仔细考虑此节的组织方式。

此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。

功能性需求可以包括特性集、功能和安全性。

当利用应用程序开发工具（如需求工具、建模工具等）来获取功能性时，此节文档将引用获取相应数据的方法，并指出用来获取数据的工具的位置和名称。

]

3.1.1功能性需求1

[需求说明]

3.2可用性

[软件产品的可用性是产品使用方便且实用的程度。

也可定义为：

系统操作人员在给定的操作时间剖面、给定的操作时间内，不会遇到界面问题的可能性。

此节应包括所有影响可用性的需求。

例如，

1.指出普通用户和高级用户要高效地执行特定操作所需的培训时间

2.指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可用性需求

3.指出在符合公认的可用性标准（如IBM的CUA标准和Microsoft的GUI标准）方面的需求]

[可用性需求若用户没有提出需求，则指明按照事业部可用性规范执行，此处不用具体描写]

3.2.1可用性需求1

[在此给出需求说明]

3.3可靠性

[可靠性是指软件在用户可接受模式下持续、一致运行的能力。

对系统可靠性的需求应在此处说明。

以下是一些建议：

1.可用性—指出可用时间百分比（xx.xx%）、使用小时数、维护访问权、降级模式操作等。

2.平均故障间隔时间（MTBF）—通常表示为小时数，但也可表示为天数、月数或年数。

3.平均修复时间（MTTR）—系统在发生故障后可以暂停运行的时间。

4.精确度—指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。

5.最高错误或缺陷率—通常表示为每千行代码的错误数目（bugs/KLOC）或每个功能点的错误数目（bugs/function-point）。

6.错误或缺陷率—按照小错误、大错误和严重错误来分类。

需求中必须对“严重”错误进行界定，例如：

数据完全丢失或完全不能使用系统的某部分功能。

]

3.3.1可靠性需求1

[需求说明]

3.4安全性需求

[此节应包括所有安全性需求。

确定需要保护的数据；

确定各种数据所受到的安全威胁的类型，如

意外的损坏或破坏；

故意的损坏或破坏；

商业间谍行为；

欺骗；

黑客行为；

病毒]

3.4.1安全性需求1

[需求说明]

3.5性能

[此节应概述系统的性能特征。

其中需包括具体的响应时间。

如果可行，按名称引用相关用例。

对事务的响应时间（平均、最长）

1.吞吐量，例如每秒处理的事务数

2.容量，例如系统可以容纳的客户或事务数

3.降级模式（当系统以某种形式降级时可接受的运行模式）

4.资源利用情况，如内存、磁盘、通信等]

3.5.1性能需求1

[在此给出需求说明]

3.6可支持性

[支持性是指软件易于被修改、增强或修复的能力。

此节应列出将提高所构建系统的可支持性或可维护性的所有需求，其中包括可测试性（如在线状态测试），可扩展性（在线升级），可维护性（远程维护，维护时间），可配置性，可安装性，本地支持等等]

3.6.1可支持性需求1

[在此给出需求说明]

3.7设计约束

[此节应列出所构建系统的所有设计约束。

设计约束代表已经批准并必须遵循的设计决定，其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。

如有客户提供的技术、业务规范等文档需作为此文档的附件。

如果需要兼容遗留系统的数据，也需要在此说明，并附上对遗留系统数据的详细说明文档]

3.7.1设计约束1

[在此给出需求说明]

3.8联机用户文档和帮助系统需求

[如果存在对联机用户文档、帮助系统、关于声明的帮助等的需求，请在此说明。

]

3.9购买的构件

[此节说明在系统中使用的所有购入构件、所有适用的许可或使用限制，以及所有相关的兼容性及互操作性或接口标准。

]

3.10接口/界面

[此节规定应用程序必须支持的接口/界面。

它应非常具体，包含协议、端口和逻辑地址等，以便于按照接口/界面需求开发并检验软件。

]

3.10.1用户界面

[说明软件将实现的用户界面。

]

3.10.2硬件接口

[此节指出软件所支持的所有硬件接口，其中包括逻辑结构、物理地址、预期行为等。

]

3.10.3软件接口

[此节说明软件系统中与其他构件之间的软件接口。

这些构件可以是购入的构件、取自其他应用程序重新利用的构件，也可以是为此SRS范围之外的子系统开发，但该软件应用程序必须与之交互的构件。

]

3.10.4通信接口

[说明与其他系统或设备（如局域网、远程串行设备等）的所有通信接口。

]

3.11许可需求

[定义所有许可执行需求或软件将体现的其他使用限制需求。

]

3.12法律、版权及其他声明

[此节说明软件涉及的所有必需的法律免责声明、保证、版权声明、专利声明、字标、商标或徽标符合性问题。

]

3.13适用的标准

[通过引用，此节说明了所有适用的标准以及适用于所述系统的相应标准的具体部分。

例如，其中可以包括法律、质量及法规标准；业界在可用性、互操作性、国际化、操作系统相容性等方面的标准。

]

4.界面原型

[界面原型能让用户事先对界面产生直观的认知并提出重要的意见和建议，以避免事后弥补可用性和功能缺陷的高昂代价。

界面原型可以是手工绘制的草图、借助计算机绘制的图片、甚至可以模拟简单的操作。

在揭示问题的前提下，界面原型越简单越好。

]

5.需求优先级

[确定所有识别的需求（包括非功能性需求）的编号和优先级，提供优先级列表。

功能性需求编号为‘FUN-序号’，非功能性需求编号为‘SUPP-序号’;优先级用高中低表示。

优先级为高的需求为：

必不可少的，不满足这些需求就无法使系统满足客户的需要；优先级为中的需求为：

对于系统在大多数应用中的有效性及效率都较为重要的需求，如果遗漏了可能会影响客户或用户满意度；优先级为低的需求为：

在不太典型的应用中比较有用或者可以合理而有效地实现其替代需求，这些特性的使用次数将会相对较少，不会对客户满意度造成严重的影响。

]

需求编号

需求描述

优先级

FUN-1

高

FUN-2

中

FUN-3

中

SUPP-1

低

6.软件功能列表

[确定该软件产品具有的功能，对于产品升级项目，需要明确功能对应的产品的版本。

功能编号同功能需求编号，功能编号为‘FUN-序号’。

]

功能编号

功能描述

产品版本

FUN-1

1.0

FUN-2

1.0

FUN-3

1.0

FUN-4

1.1

7.附件

[后台系统建议提供规则性说明文档，如采集规则、预处理规则、计费规则等作为附件]