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

1、xx 项目非功能需求规格说明书项目非功能需求规格说明书 文档创建信息文档创建信息 产品项目名称如：数商 3.0.2产品项目编号 产品经理项目经理 创建日期总页数 正文页数附录页数 文档修订记录文档修订记录 修改日期修改的章节修改类型修改描述修改人审核人版本号 修改类型分为 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可维护

2、性.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 1：模版使用说明：模版使用说明.12 附录附录 2 2：模版修订记录：模版修订记录.12 1质量属性需求质量属性需求 1.11.1性能性能 概念： 性能是指系统的响应能力即对外部刺激（事件）做出反应所需要的时间或在某段 时间内所处理的事件个数。性能这

3、一质量属性经常用在单位时间内所能完成的处理数量或 系统为完成一个处理所耗费的时间来表示。 描述系统的性能需求通常从以下几个方面进行：延迟、吞吐量、容量。 .1延迟延迟 概念： 延迟定义为从事件触发到对应响应之间的时间间隔。这个时间间隔定义了一个响应窗 口（开始时间为最小延迟，结束时间为最大延迟） 。 示例： 编号编号项项响应时间响应时间抖动抖动优先级优先级备注备注 perf.l.195%的x操作5秒2秒高 perf.l.2y操作10秒3秒中 perf.l.3z操作30秒10秒低 .2吞吐量吞吐量 概念： 吞吐量定义为在一个给定的观察时间段内，系统处理事件，然后产

4、生的响应数量。通 常需要指多个观察时间段，比如1分钟，30分钟，60分钟等。因为60分钟内处理120个 事件并不意味着每分钟可以处理2个事件。 示例： 编号编号项项吞吐量吞吐量备注备注 perf.t.1 登录用户在线状态更改频率每 10 分钟 1 次 perf.t.2 登录用户发送消息频率每分钟 1 条 perf.t.3 用户发送电子邮件频率每天 20 封 .3容量容量 概念： 容量：容量是一个衡量系统可以处理的工作量数量的指标。比如在理想运行环境下， 最大可达到的吞吐量，最大可支持的用户数量等。需要注意的是，即使在达到最大吞吐量 的情况下，系统也不能违背延迟的性能需求。 示例

5、： 编号编号项项容量容量备注备注 perf.c.1 邮件系统用户数=100，000 且 =500，000 活动用户指至 少每个月收发 一封邮件的用 户 perf.c.3 即时通讯系统用户数=100，000 perf.c.4 即时通讯系统用户的好友数量 =200 1.21.2安全性安全性 概念： 关于计算机信息系统安全性，国际标准化组织(iso)给出如下定义：“为数据处理系统 建立和采用的技术和管理的安全保护，保护计算机硬件、软件和数据不因偶然和恶意的原 因遭到破坏、更改和泄露” 。 示例： 编号编号项（系统数据项（系统数据/处理过程）处理过程） secu.1 在成功执行身份认证之前，系统必须允

6、许用户类别 x 的成员 | 客户端程 序 y执行操作 z 列表 。 secu.2 在成功执行身份认证之前，系统必须拒绝用户类别 x 的成员 | 客户端程 序 y执行任意操作|操作 z 列。 secu.3 当受到x 类安全攻击时，系统应该能够检测|阻止任何伪造的认证数据。 secu.4 应用程序必须扫描所有进入的或下载的数据及软件，以发现所有被公布的 知名计算机病毒、蠕虫及特洛伊木马。 secu.5 至少 99.9%以上的时间，系统能够保护用户之间传递的消息不被非授权增 加、修改和删除。 secu.6 系统必须防止任何非授权用户访问系统存储的用户帐号、邮件、即时消息。 1.31.3可靠性可靠性

7、概念： 可靠性是指系统能够保持正常运行的能力。可靠性通常用平均正常运行时间（mttf, mean time to failure）来衡量。 与可靠性密切相关的一个概念是有效性。 有效性是指系统正常运行的时间比例。有效性是通过两次故障之间的时间长度或在系 统崩溃的情况下系统能够恢复正常运行的速度来衡量的。系统处于稳定运行状态的有效性 是系统正常运行的时间与全部时间之比，通常是以如下公式来定义的： mttrmttf mttf 其中：mttf（mean time to failure）表示平均正常运行时间；mttr（mean time to repair）表示平均故障恢复时间。 示例： 编号编号项项

8、值值 avai.1 在任意时刻邮件服务器正常运行的可能 性 99.9% avai.2 邮件服务器平均正常运行时间90 天 avai.3 邮件服务器平均故障恢复时间43.2 分钟 1.41.4可配置性可配置性 概念： 可配置需求的典型目标是确保应用或组件： 国际化，支持在相应的国家或地区使用； 个性化，支持特定用户的特定需求； 支持交付具有不同功能子集的产品； 示例： 编号编号项项 conf.1 系统必须支持国际化以便在以下国家或地区正确工作： 美国 加拿大 英国 日本 韩国 台湾（地区） 香港（地区） conf.2 应用程序必须支持用户各性化定制用户界面，改变文字的颜色、个人图像， conf.

9、3 应用程序支持根据用户的权限显示合适的界面。当用户的权限发生变化时， 用户可见（可操作）的菜单、按钮也随之变化。 1.51.5互操作性互操作性（系统间集成）（系统间集成） 概念： 互操作性是一种衡量一组部件（构成一个系统）与另一个系统协作的能力。 示例： 编号编号项项 inte.1 即时通讯系统支持与短信系统互操作，将即时消息通过短信系统发送到用 户的手机 inte.2 即时通讯系统支持与邮件系统互操作，可以支持通过邮件客户端接收离线 即时消息 1.61.6可伸缩性可伸缩性 概念： 可伸缩性是当事务负荷增加时，在保证服务质量的条件下容纳更多用户的能力。如果 能够通过增加资源以满足不断增长的对

10、性能和功能的要求，或者是通过缩减资源，以降低 成本，从涵盖硬件和软件的角度上讲，我们可以把符合这种特性的计算机系统称作是可伸 缩的。 示例： 编号编号项项 scal.1 邮件系统用户数年增长率为 10 万/年，目标总容量为 1000 万。 scal.2 通讯系统客户数年增长率为 5 万/年，目标总容量为 100 万。 scal.3 用户邮箱容量月增长率为 10mb/月，目标总容量为 1g byte。 1.71.7可维护性可维护性 概念： 软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和 改进该软件的难易程度。 示例： 编号编号项项 main.1 修复问题 1（包括回

11、归测试及文档更新）的平均工作量必须小于 1 人周。 main.2 完成一次小版本升级的平均工作量必须小于 1 人周。 main.3 完成一次重大版本升级的平均工作量必须小于 1 人月。 1.81.8可管理性可管理性 概念： 软件可管理性即对软件执行管理、监控操作以及接收与这些操作相关的信息的难易程 度。 示例： 编号编号项项 mana.1 控制：通过改变系统的配置改变软件运行行为。 mana.2 监视：捕获软件运行时事件和历史事件并报告或发出通知。 mana.3 跟踪：软件运行状况信息的记录。 1.91.9可审计性可审计性 概念： 可审计性是指系统进行适当的记录存储以： 支持财经审计 支持安全

12、审计 确定是否某些金融事务发生过 示例： 编号编号项项 audi.1 短信系统每转发一条短信都必须保存以下信息半年以上： 短信发送者 短信接收者 短信发送时间 短信内容 1.101.10可安装性可安装性 概念： 可安装性是衡量产品安装到运行环境难易程度的一项指标。 可安装性的目标是： 确保应用或组件易于安装； 确保在安装过程中不会产生时间或金钱上的浪费； 提升安装工程师的士气； 最小化安装的缺陷。 示例： 编号编号项项 inst.1 一个经过良好训练的部署团队所需要的安装工作量不能超过 15 人日； inst.2 一个典型用户所需要的安装时间不超过 15 分钟； 1.111.11可更改性可更改

13、性 概念： 可更改性是与系统构架关系最为密切的一个质量属性。能够进行快速修改并使修改代 价尽可能低的能力直接受构架的限制。对系统的更改一般是由于该系统的组织的商业目的 发生了变化。从广义上看，这些变化主要包括： 功能的扩展或改变。添加新的功能，改进已有的功能或修复系统中的缺陷。 删除不再想要的功能。即优化或简化现有系统的功能。 适应新的操作环境。例如处理器硬件、输入/输出设备或其它逻辑设备。这种 能力也称为可移植性。 结构的重新调整。例如为使系统的服务更为合理，模块划分更为科学或为优 化系统而进行调整。 示例： 编号编号项项 modi.1 数字通讯客户端在将来的版本中预计添加邮件、短信、日历等

14、功能。 modi.2 数字通讯客户端支持移植到 pda 设备上。 1.121.12可连续性可连续性 概念：可连续性是指在环境、资源、人员、流程与程序缺陷等影响下，有应对风险自 动调整和快速反应的能力，所保证线上系统的连续运转。 示例： 编号编号项项 modi.1 系统需要 724 式的全天候运行。 1.131.13可恢复性可恢复性 概念：可恢复性，就是把系统、应用以及数据库由存在故障的状态转变为无故障状态 的过程。一般可以从系统恢复、应用恢复、数据恢复等方面进行考虑。 示例： 编号编号项项 modi.1 系统可以进行数据备份，最近30日的业务数据、数据库数据全备份（30 份，每日一份，保留2个

15、月） ，每周周六进行数据完全备份一次（保留2个 月） ，每月末最后一日进行数据完全备份一次（保留1年） ，每1小时业务 数据、数据库数据增量备份一次。 重大故障需要在48小时恢复服务的可用性，并在在24小时到72小时内 恢复历史数据 1.141.14其它其它 其它未列入上述需求或还未确定的内容。 2约束约束 2.12.1运行环境运行环境 描述软件的运行环境相关因素。包括硬件平台和软件平台的支持。 .1软件平台软件平台 描述系统及各个模块运行所需要的操作系统平台、版本、其他的软件组件、应用程序、 应用服务等环境支持。 示例：示例： 短信系统基于以下软件支撑环境开发及运营： 服务器

16、操作系统：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 (也

17、称为 xft) libstdc+5 .2硬件平台硬件平台 对硬件需求的描述可以描述为系统或模块中需要通过硬件实现的功能特性，以及实现 这些特性的硬件需求。 常见的硬件平台约束包括：网络带宽、工作站、服务器等等。 示例： 服务器运行硬件平台： 处理器 xeon3.0*2 内存 4g 硬盘20g 以上 网络情况带宽 4m 以上 2.22.2设计约束设计约束 描述硬件平台及软件平台上影响开发人员自由选择的限制，这些限制可能包括： 必须使用或避免使用的技术、工具、语言、软件等； 要求遵守的开发规范或标准； 硬件限制（如：硬件集成由其他组织进行） 示例：示例： 短线网关开发规范或标准：

18、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 的服