产品项目非功能需求规格说明书模版样本.doc

资料内容仅供您学习参考，如有不当之处，请联系改正或者删除。

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

文档创立信息
产品项目名称
如: 数商3.0.2
产品项目编号

产品经理

项目经理

创立日期

总页数

正文页数

附录页数

文档修订记录
修改日期
修改的章节
修改类型
修改描述
修改人
审核人
版本号

l 修改类型分为 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 硬件平台 11
2.2 设计约束 11
2.3 业务规则 11
2.4 法律约束 12
2.5 其它约束 12
附录1: 模版使用说明 12
附录2: 模版修订记录 12

1 质量属性需求
1.1 性能
概念:
性能是指系统的响应能力——即对外部刺激( 事件) 做出反应所需要的时间或在某段时间内所处理的事件个数。性能这一质量属性经常见在单位时间内所能完成的处理数量或系统为完成一个处理所耗费的时间来表示。
描述系统的性能需求一般从以下几个方面进行: 延迟、 吞吐量、 容量。
1.1.1 延迟
概念:
延迟定义为从事件触发到对应响应之间的时间间隔。这个时间间隔定义了一个响应窗口( 开始时间为最小延迟, 结束时间为最大延迟) 。
示例:
编号
项
响应时间
抖动
优先级
备注
Perf.L.1
95%的X操作
<5秒
<2秒
高

Perf.L.2
Y操作
<10秒
<3秒
中

Perf.L.3
Z操作
<30秒
<10秒
低

1.1.2 吞吐量
概念:
吞吐量定义为在一个给定的观察时间段内, 系统处理事件, 然后产生的响应数量。一般需要指多个观察时间段, 比如1分钟, 30分钟, 60分钟等。因为60分钟内处理120个事件并不意味着每分钟能够处理2个事件。
示例:
编号
项
吞吐量
备注
Perf.T.1
登录用户在线状态更改频率
每10分钟1次

Perf.T.2
登录用户发送消息频率
每分钟1条

Perf.T.3
用户发送电子邮件频率
每天20封

1.1.3 容量
概念:
容量: 容量是一个衡量系统能够处理的工作量数量的指标。比如在理想运行环境下, 最大可达到的吞吐量, 最大可支持的用户数量等。需要注意的是, 即使在达到最大吞吐量的情况下, 系统也不能违背延迟的性能需求。
示例:
编号
项
容量
备注
Perf.C.1
邮件系统用户数
<=1, 000, 000

Perf.C.2
邮件系统活动用户数
>=100, 000且
<=500, 000
活动用户指至少每个月收发一封邮件的用户
Perf.C.3
即时通讯系统用户数
<=100, 000

Perf.C.4
即时通讯系统用户的好友数量
<=200

1.2 安全性
概念:
关于计算机信息系统安全性, 国际标准化组织(ISO)给出如下定义: ”为数据处理系统建立和采用的技术和管理的安全保护, 保护计算机硬件、 软件和数据不因偶然和恶意的原因遭到破坏、 更改和泄露”。
示例:
编号
项( 系统数据/处理过程)
Secu.1
在成功执行身份认证之前, 系统必须允许[用户类别X的成员 | 客户端程序Y]执行[操作Z列表] 。
Secu.2
在成功执行身份认证之前, 系统必须拒绝[用户类别X的成员 | 客户端程序Y]执行[任意操作|操作Z列]。
Secu.3
当受到[X类安全攻击]时, 系统应该能够[检测|阻止]任何伪造的认证数据。
Secu.4
应用程序必须扫描所有进入的或下载的数据及软件, 以发现所有被公布的知名计算机病毒、 蠕虫及特洛伊木马。
Secu.5
至少99.9%以上的时间, 系统能够保护用户之间传递的消息不被非授权增加、 修改和删除。
Secu.6
系统必须防止任何非授权用户访问系统存储的用户帐号、 邮件、 即时消息。
1.3 可靠性
概念:
可靠性是指系统能够保持正常运行的能力。可靠性一般见平均正常运行时间( MTTF, mean time to failure) 来衡量。
与可靠性密切相关的一个概念是有效性。
有效性是指系统正常运行的时间比例。有效性是经过两次故障之间的时间长度或在系统崩溃的情况下系统能够恢复正常运行的速度来衡量的。系统处于稳定运行状态的有效性是系统正常运行的时间与全部时间之比, 一般是以如下公式来定义的:

其中: MTTF( mean time to failure) 表示平均正常运行时间; MTTR( mean time to repair) 表示平均故障恢复时间。
示例:
编号
项
值
Avai.1
在任意时刻邮件服务器正常运行的可能性
99.9%
Avai.2
邮件服务器平均正常运行时间
90天
Avai.3
邮件服务器平均故障恢复时间
43.2分钟
1.4 可配置性
概念:
可配置需求的典型目标是确保应用或组件:
· 国际化, 支持在相应的国家或地区使用;
· 个性化, 支持特定用户的特定需求;
· 支持交付具有不同功能子集的产品;
示例:
编号
项
Conf.1
系统必须支持国际化以便在以下国家或地区正确工作:
l 美国
l 加拿大
l 英国
l 日本
l 韩国
l 台湾( 地区)
l 香港( 地区)
Conf.2
应用程序必须支持用户各性化定制用户界面, 改变文字的颜色、 个人图像, …
Conf.3
应用程序支持根据用户的权限显示合适的界面。当用户的权限发生变化时, 用户可见( 可操作) 的菜单、 按钮也随之变化。
1.5 互操作性( 系统间集成)
概念:
互操作性是一种衡量一组部件( 构成一个系统) 与另一个系统协作的能力。
示例:
编号
项
Inte.1
即时通讯系统支持与短信系统互操作, 将即时消息经过短信系统发送到用户的手机
Inte.2
即时通讯系统支持与邮件系统互操作, 能够支持经过邮件客户端接收离线即时消息
1.6 可伸缩性
概念:
可伸缩性是当事务负荷增加时, 在保证服务质量的条件下容纳更多用户的能力。如果能够经过增加资源以满足不断增长的对性能和功能的要求, 或者是经过缩减资源, 以降低成本, 从涵盖硬件和软件的角度上讲, 我们能够把符合这种特性的计算机系统称作是可伸缩的。
示例:
编号
项
Scal.1
邮件系统用户数年增长率为10万/年, 目标总容量为1000万。
Scal.2
通讯系统客户数年增长率为5万/年, 目标总容量为100万。
Scal.3
用户邮箱容量月增长率为10MB/月, 目标总容量为1G Byte。
1.7 可维护性
概念:
软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、 改正、 改动和改进该软件的难易程度。
示例:
编号
项
Main.1
修复问题1( 包括回归测试及文档更新) 的平均工作量必须小于1人周。
Main.2
完成一次小版本升级的平均工作量必须小于1人周。
Main.3
完成一次重大版本升级的平均工作量必须小于1人月。
1.8 可管理性
概念:
软件可管理性即对软件执行管理、 监控操作以及接收与这些操作相关的信息的难易程度。
示例:
编号
项
Mana.1
控制: 经过改变系统的配置改变软件运行行为。
Mana.2
监视: 捕获软件运行时事件和历史事件并报告或发出通知。
Mana.3
跟踪: 软件运行状况信息的记录。
1.9 可审计性
概念:
可审计性是指系统进行适当的记录存储以:
l 支持财经审计
l 支持安全审计
l 确定是否某些金融事务发生过
示例:
编号
项
Audi.1
短信系统每转发一条短信都必须保存以下信息半年以上:
l 短信发送者
l 短信接收者
l 短信发送时间
l 短信内容
1.10 可安装性
概念:
可安装性是衡量产品安装到运行环境难易程度的一项指标。
可安装性的目标是:
· 确保应用或组件易于安装;
· 确保在安装过程中不会产生时间或金钱上的浪费;
· 提升安装工程师的士气;
· 最小化安装的缺陷。
示例:
编号
项
Inst.1
一个经过良好训练的部署团队所需要的安装工作量不能超过15人日;
Inst.2
一个典型用户所需要的安装时间不超过15分钟;
1.11 可更改性
概念:
可更改性是与系统构架关系最为密切的一个质量属性。能够进行快速修改并使修改代价尽可能低的能力直接受构架的限制。对系统的更改一般是由于该系统的组织的商业目的发生了变化。从广义上看, 这些变化主要包括:
· 功能的扩展或改变。添加新的功能, 改进已有的功能或修复系统中的缺陷。
· 删除不再想要的功能。即优化或简化现有系统的功能。
· 适应新的操作环境。例如处理器硬件、 输入/输出设备或其它逻辑设备。这种能力也称为可移植性。
· 结构的重新调整。例如为使系统的服务更为合理, 模块划分更为科学或为优化系统而进行调整。
示例:
编号
项
Modi.1
数字通讯客户端在将来的版本中预计添加邮件、 短信、 日历等功能。
Modi.2
数字通讯客户端支持移植到PDA设备上。
1.12 可连续性
概念: 可连续性是指在环境、 资源、 人员、 流程与程序缺陷等影响下, 有应对风险自动调整和快速反应的能力, 所保证线上系统的连续运转。
示例:
编号
项
Modi.1
系统需要7×24式的全天候运行。
1.13 可恢复性
概念: 可恢复性, 就是把系统、 应用以及数据库由存在故障的状态转变为无故障状态的过程。一般能够从系统恢复、 应用恢复、 数据恢复等方面进行考虑。
示例:
编号
项
Modi.1
系统能够进行数据备份, 最近30日的业务数据、 数据库数据全备份( 30份, 每日一份, 保留2个月) , 每周周六进行数据完全备份一次( 保留2个月) , 每月末最后一日进行数据完全备份一次( 保留1年) , 每1小时业务数据、 数据库数据增量备份一次。

重大故障需要在4～8小时恢复服务的可用性, 并在在24小时到72小时内恢复历史数据
1.14 其它
其它未列入上述需求或还未确定的内容。
2 约束
2.1 运行环境
描述软件的运行环境相关因素。包括硬件平台和软件平台的支持。
2.1.1 软件平台
描述系统及各个模块运行所需要的操作系统平台、 版本、 其它的软件组件、 应用程序、 应用服务等环境支持。
示例:
短信系统基于以下软件支撑环境开发及运营:
l 服务器操作系统: AS4.0 update2
l 应用服务器: JBoss4.0.4GA或者JBossWeb1.0GA
l JDK: jdk1.5.0_09
l 数据库: MySQL5.0.17c( 认证版)
l 客户端操作系统:
- Windows
Ø Windows 98
Ø Windows 98SE
Ø Windows ME
Ø Windows NT 4.0
Ø Windows
Ø Windows XP (建议)
Ø Windows Server
- Linux
Ø Linux kernel - 2.2.14 及以上
Ø glibc 2.3.2 及以上
Ø XFree86-3.3.6 及以上
Ø gtk+2.0 及以上
Ø fontconfig (也称为xft)
Ø libstdc++5
2.1.2 硬件平台
对硬件需求的描述能够描述为系统或模块中需要经过硬件实现的功能特性, 以及实现这些特性的硬件需求。
常见的硬件平台约束包括: 网络带宽、 工作站、 服务器等等。
示例:
服务器运行硬件平台:
处理器
Xeon3.0*2
内存
4G
硬盘
20G以上
网络情况
带宽4M以上
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 业务规则
描述软件产品所要遵守的用户业务的行业规则。如果已经存在明确的行业规则文件, 在此进行列表引用。
示例:
编号
项
Rule.1
短信网关只能经过固定的一个IP地址与运营商网关建立连接。同一个短信网关能够与运营商网关之间建立多个连接。但连接数量受限制, 一般少于10个。
Rule.2
短信网关经过运营商网关发送短信的吞吐量受限制, 每秒不多于60条。
2.4 法律约束
描述软件不能违背的政府法律或规章制度, 能够从国家标准、 行业标准、 企业标准等方面考虑。
2.5 其它约束
其它未列入上述约束的内容。
附录1: 模版使用说明
1. 模版中, 黑色字体部分不可裁剪。在编写时, 如果相对应的内容没有或不适用, 在相应的标题下写明即可, 不能删除。
2. 模版中, 蓝色字体部分是对于文档内容的解释说明。在编写时, 需要删除这些内容。
3. 对于模版中给出的示例, 适用的能够保留并填入相关内容; 不适用的直接删除。
4. 本附录, 在《非功能需求说明书》成文时需要删除。

附录2: 模版修订记录
本附录, 记录了本模版的修订历史信息。在《非功能需求说明书》成文时, 需要删除。
修改日期
修改的章节
修改类型
修改描述
修改人
审核人
版本号

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