产品项目非功能需求规格说明书

XX项目非功能需求规格说明书

文档创建信息

文档修订记录

修改类型分为A– ADDED（增加）M– MODIFIED（修改）D– DELETED（删除）

目录

1质量属性需求 (4)

1.1性能 (4)

1.1.1延迟 (4)

1.1.2吞吐量 (4)

1.1.3容量 (5)

1.2安全性 (5)

1.3可靠性 (6)

1.4可配置性 (6)

1.5互操作性（系统间集成） (7)

1.6可伸缩性 (7)

1.7可维护性 (7)

1.8可管理性 (8)

1.9可审计性 (8)

1.10可安装性 (8)

1.11可更改性 (9)

1.12可连续性 (9)

1.13可恢复性 (9)

1.14其它 (10)

2约束 (10)

2.1运行环境 (10)

2.1.1软件平台 (10)

2.1.2硬件平台 (10)

2.2设计约束 (11)

2.3业务规则 (11)

2.4法律约束 (12)

2.5其它约束 (12)

附录1：模版使用说明 (12)

附录2：模版修订记录 (12)

1质量属性需求

1.1性能

概念：

性能是指系统的响应能力——即对外部刺激（事件）做出反应所需要的时间或在某段时间内所处理的事件个数。性能这一质量属性经常用在单位时间内所能完成的处理数量或系统为完成一个处理所耗费的时间来表示。

描述系统的性能需求通常从以下几个方面进行：延迟、吞吐量、容量。

1.1.1延迟

概念：

延迟定义为从事件触发到对应响应之间的时间间隔。这个时间间隔定义了一个响应窗口（开始时间为最小延迟，结束时间为最大延迟）。

示例：

1.1.2吞吐量

概念：

吞吐量定义为在一个给定的观察时间段内，系统处理事件，然后产生的响应数量。通常需要指多个观察时间段，比如1分钟，30分钟，60分钟等。因为60分钟内处理120个事件并不意味着每分钟可以处理2个事件。

示例：

1.1.3容量

概念：

容量：容量是一个衡量系统可以处理的工作量数量的指标。比如在理想运行环境下，最大可达到的吞吐量，最大可支持的用户数量等。需要注意的是，即使在达到最大吞吐量的情况下，系统也不能违背延迟的性能需求。

示例：

1.2安全性

概念：

关于计算机信息系统安全性，国际标准化组织(ISO)给出如下定义：“为数据处理系统建立和采用的技术和管理的安全保护，保护计算机硬件、软件和数据不因偶然和恶意的原因遭到破坏、更改和泄露”。

1.3

可靠性

概念：

可靠性是指系统能够保持正常运行的能力。可靠性通常用平均正常运行时间（MTTF ,

mean time to failure ）来衡量。

与可靠性密切相关的一个概念是有效性。

有效性是指系统正常运行的时间比例。有效性是通过两次故障之间的时间长度或在系统崩溃的情况下系统能够恢复正常运行的速度来衡量的。系统处于稳定运行状态的有效性是系统正常运行的时间与全部时间之比，通常是以如下公式来定义的：

MTTR MTTF MTTF

+=

α

其中：MTTF （mean time to failure ）表示平均正常运行时间；MTTR （mean time to repair ）表示平均故障恢复时间。

示例：

1.4

可配置性

概念：

可配置需求的典型目标是确保应用或组件：

? 国际化，支持在相应的国家或地区使用； ? 个性化，支持特定用户的特定需求； ? 支持交付具有不同功能子集的产品；

1.5互操作性（系统间集成）

概念：

互操作性是一种衡量一组部件（构成一个系统）与另一个系统协作的能力。

示例：

1.6可伸缩性

概念：

可伸缩性是当事务负荷增加时，在保证服务质量的条件下容纳更多用户的能力。如果能够通过增加资源以满足不断增长的对性能和功能的要求，或者是通过缩减资源，以降低成本，从涵盖硬件和软件的角度上讲，我们可以把符合这种特性的计算机系统称作是可伸缩的。

1.7可维护性

概念：

软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。

概念：

软件可管理性即对软件执行管理、监控操作以及接收与这些操作相关的信息的难易程度。

1.9可审计性

概念：

可审计性是指系统进行适当的记录存储以：

●支持财经审计

●支持安全审计

●确定是否某些金融事务发生过

1.10可安装性

概念：

可安装性是衡量产品安装到运行环境难易程度的一项指标。

可安装性的目标是：

?确保应用或组件易于安装；

?确保在安装过程中不会产生时间或金钱上的浪费；

?提升安装工程师的士气；

?最小化安装的缺陷。

概念：

可更改性是与系统构架关系最为密切的一个质量属性。能够进行快速修改并使修改代价尽可能低的能力直接受构架的限制。对系统的更改一般是由于该系统的组织的商业目的发生了变化。从广义上看，这些变化主要包括：

?功能的扩展或改变。添加新的功能，改进已有的功能或修复系统中的缺陷。

?删除不再想要的功能。即优化或简化现有系统的功能。

?适应新的操作环境。例如处理器硬件、输入/输出设备或其它逻辑设备。这种能力也称为可移植性。

?结构的重新调整。例如为使系统的服务更为合理，模块划分更为科学或为优化系统而进行调整。

1.12可连续性

概念：可连续性是指在环境、资源、人员、流程与程序缺陷等影响下，有应对风险自动调整和快速反应的能力，所保证线上系统的连续运转。

1.13可恢复性

概念：可恢复性，就是把系统、应用以及数据库由存在故障的状态转变为无故障状态的过程。一般可以从系统恢复、应用恢复、数据恢复等方面进行考虑。

示例：

1.14其它

其它未列入上述需求或还未确定的内容。

2约束

2.1运行环境

描述软件的运行环境相关因素。包括硬件平台和软件平台的支持。

2.1.1软件平台

描述系统及各个模块运行所需要的操作系统平台、版本、其他的软件组件、应用程序、应用服务等环境支持。

示例：

短信系统基于以下软件支撑环境开发及运营：

●服务器操作系统：AS4.0 update2

●应用服务器：JBoss4.0.4GA或者JBossWeb1.0GA

●JDK：jdk1.5.0_09

●数据库：MySQL5.0.17c（认证版）

●客户端操作系统：

-Windows

Windows 98

Windows 98SE

Windows ME

Windows NT 4.0

Windows 2000

Windows XP (建议)

Windows Server 2003

-Linux

Linux kernel - 2.2.14 及以上

glibc 2.3.2 及以上

XFree86-3.3.6 及以上

gtk+2.0 及以上

fontconfig (也称为xft)

libstdc++5

2.1.2硬件平台

对硬件需求的描述可以描述为系统或模块中需要通过硬件实现的功能特性，以及实现这

些特性的硬件需求。

常见的硬件平台约束包括：网络带宽、工作站、服务器等等。

示例：

服务器运行硬件平台：

2.2设计约束

描述硬件平台及软件平台上影响开发人员自由选择的限制，这些限制可能包括：?必须使用或避免使用的技术、工具、语言、软件等；

?要求遵守的开发规范或标准；

?硬件限制（如：硬件集成由其他组织进行）

示例：

短线网关开发规范或标准：

[1]中国移动通信企业标准：互联网短信网关接口协议（版本号：3.0.0）.

[2]中国网络通信集团公司企业标准：PHS 短消息网关技术规范，第一分册短消息网关与服

务提供商（SP）接口规范（CNGP）V2.0。

[3]Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext

transfer protocol -- HTTP/1.1", RFC2068, January 1997.

[4]技术架构部, "技术架构设计规范", 版本：1.0, 技术架构设计规范.doc

[5]技术架构部, "框架设计规范", 版本：1.0, 框架设计规范.doc

[6]技术架构部, "基于ASF的服务器设计规范", 版本：1.0, 基于ASF的服务器设计规

范.doc

2.3业务规则

描述软件产品所要遵守的用户业务的行业规则。如果已经存在明确的行业规则文件，在此进行列表引用。

2.4法律约束

描述软件不能违背的政府法律或规章制度，可以从国家标准、行业标准、企业标准等方面考虑。

2.5其它约束

其它未列入上述约束的内容。

附录1：模版使用说明

1.模版中，黑色字体部分不可裁剪。在编写时，如果相对应的内容没有或不适用，

在相应的标题下写明即可，不能删除。

2.模版中，蓝色字体部分是对于文档内容的解释说明。在编写时，需要删除这些内

容。

3.对于模版中给出的示例，适用的可以保留并填入相关内容；不适用的直接删除。

4.本附录，在《非功能需求说明书》成文时需要删除。

附录2：模版修订记录

本附录，记录了本模版的修订历史信息。在《非功能需求说明书》成文时，需要删除。

修改类型分为A - ADDED M - MODIFIED D– DELETED