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

1、.XX 项目非功能需求规格说明书项目非功能需求规格说明书.文档创建信息文档创建信息产品项目名称如：数商 3.0.2产品项目编号产品经理项目经理创建日期总页数正文页数附录页数文档修订记录文档修订记录修改日期修改的章节修改类型修改描述修改人审核人版本号修改类型分为 A ADDED（增加） M MODIFIED（修改） D DELETED（删除）.目目 录录1质量属性需求质量属性需求.41.1性能.41.1.1延迟.41.1.2吞吐量.41.1.3容量.51.2安全性.51.3可靠性.61.4可配置性.61.5互操作性（系统间集成）.71.6可伸缩性.71.7可维护性.71.8可管理性.81.9可审

2、计性.81.10可安装性.81.11可更改性.91.12可连续性.91.13可恢复性.91.14其它.102约束约束.102.1运行环境.102.1.1软件平台.102.1.2硬件平台.112.2设计约束.112.3业务规则.112.4法律约束.122.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吞吐量吞吐量概念：吞吐量定义为在一个给定的观察时间段内，系统处理事件，然后产生的响应数量。通常需要指多个观察时间段，比如1分钟，30分钟，60分钟等。因为60分钟内处理120个事件

4、并不意味着每分钟可以处理2个事件。示例：编号编号项项吞吐量吞吐量备注备注Perf.T.1登录用户在线状态更改频率每 10 分钟 1 次Perf.T.2登录用户发送消息频率每分钟 1 条.Perf.T.3用户发送电子邮件频率每天 20 封.3容量容量概念：容量：容量是一个衡量系统可以处理的工作量数量的指标。比如在理想运行环境下，最大可达到的吞吐量，最大可支持的用户数量等。需要注意的是，即使在达到最大吞吐量的情况下，系统也不能违背延迟的性能需求。示例：编号编号项项容量容量备注备注Perf.C.1邮件系统用户数=100，000 且=500，000活动用户指至少每个月收发一封邮件的用户

5、Perf.C.3即时通讯系统用户数=100，000Perf.C.4即时通讯系统用户的好友数量=2001.21.2安全性安全性概念：关于计算机信息系统安全性，国际标准化组织(ISO)给出如下定义：“为数据处理系统建立和采用的技术和管理的安全保护，保护计算机硬件、软件和数据不因偶然和恶意的原因遭到破坏、更改和泄露” 。示例：编号编号项（系统数据项（系统数据/处理过程）处理过程）Secu.1在成功执行身份认证之前，系统必须允许用户类别 X 的成员 | 客户端程序 Y执行操作 Z 列表 。Secu.2在成功执行身份认证之前，系统必须拒绝用户类别 X 的成员 | 客户端程序 Y执行任意操作|操作 Z 列

6、。Secu.3当受到X 类安全攻击时，系统应该能够检测|阻止任何伪造的认证数据。Secu.4应用程序必须扫描所有进入的或下载的数据及软件，以发现所有被公布的知名计算机病毒、蠕虫及特洛伊木马。Secu.5至少 99.9%以上的时间，系统能够保护用户之间传递的消息不被非授权增加、修改和删除。Secu.6系统必须防止任何非授权用户访问系统存储的用户帐号、邮件、即时消息。.1.31.3可靠性可靠性概念：可靠性是指系统能够保持正常运行的能力。可靠性通常用平均正常运行时间（MTTF, mean time to failure）来衡量。与可靠性密切相关的一个概念是有效性。有效性是指系统正常运行的时间比例。有

7、效性是通过两次故障之间的时间长度或在系统崩溃的情况下系统能够恢复正常运行的速度来衡量的。系统处于稳定运行状态的有效性是系统正常运行的时间与全部时间之比，通常是以如下公式来定义的：MTTRMTTFMTTF其中：MTTF（mean time to failure）表示平均正常运行时间；MTTR（mean time to repair）表示平均故障恢复时间。示例：编号编号项项值值Avai.1在任意时刻邮件服务器正常运行的可能性99.9%Avai.2邮件服务器平均正常运行时间90 天Avai.3邮件服务器平均故障恢复时间43.2 分钟1.41.4可配置性可配置性概念：可配置需求的典型目标是确保应用或组

8、件：国际化，支持在相应的国家或地区使用；个性化，支持特定用户的特定需求；支持交付具有不同功能子集的产品；示例：编号编号项项Conf.1系统必须支持国际化以便在以下国家或地区正确工作：美国加拿大英国日本韩国.台湾（地区）香港（地区）Conf.2应用程序必须支持用户各性化定制用户界面，改变文字的颜色、个人图像，Conf.3应用程序支持根据用户的权限显示合适的界面。当用户的权限发生变化时，用户可见（可操作）的菜单、按钮也随之变化。1.51.5互操作性互操作性（系统间集成）（系统间集成）概念：互操作性是一种衡量一组部件（构成一个系统）与另一个系统协作的能力。示例：编号编号项项Inte.1即时通讯系统支

9、持与短信系统互操作，将即时消息通过短信系统发送到用户的手机Inte.2即时通讯系统支持与邮件系统互操作，可以支持通过邮件客户端接收离线即时消息1.61.6可伸缩性可伸缩性概念：可伸缩性是当事务负荷增加时，在保证服务质量的条件下容纳更多用户的能力。如果能够通过增加资源以满足不断增长的对性能和功能的要求，或者是通过缩减资源，以降低成本，从涵盖硬件和软件的角度上讲，我们可以把符合这种特性的计算机系统称作是可伸缩的。示例：编号编号项项Scal.1邮件系统用户数年增长率为 10 万/年，目标总容量为 1000 万。Scal.2通讯系统客户数年增长率为 5 万/年，目标总容量为 100 万。Scal.3用

10、户邮箱容量月增长率为 10MB/月，目标总容量为 1G Byte。1.71.7可维护性可维护性概念：软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。示例：编号编号项项Main.1修复问题 1（包括回归测试及文档更新）的平均工作量必须小于 1 人周。Main.2完成一次小版本升级的平均工作量必须小于 1 人周。.Main.3完成一次重大版本升级的平均工作量必须小于 1 人月。1.81.8可管理性可管理性概念：软件可管理性即对软件执行管理、监控操作以及接收与这些操作相关的信息的难易程度。示例：编号编号项项Mana.1控制：通过改变系统的配置改变软件

11、运行行为。Mana.2监视：捕获软件运行时事件和历史事件并报告或发出通知。Mana.3跟踪：软件运行状况信息的记录。1.91.9可审计性可审计性概念：可审计性是指系统进行适当的记录存储以：支持财经审计支持安全审计确定是否某些金融事务发生过示例：编号编号项项Audi.1短信系统每转发一条短信都必须保存以下信息半年以上：短信发送者短信接收者短信发送时间短信内容1.101.10可安装性可安装性概念：可安装性是衡量产品安装到运行环境难易程度的一项指标。可安装性的目标是：确保应用或组件易于安装；确保在安装过程中不会产生时间或金钱上的浪费；提升安装工程师的士气；最小化安装的缺陷。示例：编号编号项项Inst

12、.1一个经过良好训练的部署团队所需要的安装工作量不能超过 15 人日；.Inst.2一个典型用户所需要的安装时间不超过 15 分钟；1.111.11可更改性可更改性概念：可更改性是与系统构架关系最为密切的一个质量属性。能够进行快速修改并使修改代价尽可能低的能力直接受构架的限制。对系统的更改一般是由于该系统的组织的商业目的发生了变化。从广义上看，这些变化主要包括：功能的扩展或改变。添加新的功能，改进已有的功能或修复系统中的缺陷。删除不再想要的功能。即优化或简化现有系统的功能。适应新的操作环境。例如处理器硬件、输入/输出设备或其它逻辑设备。这种能力也称为可移植性。结构的重新调整。例如为使系统的服务

13、更为合理，模块划分更为科学或为优化系统而进行调整。示例：编号编号项项Modi.1数字通讯客户端在将来的版本中预计添加邮件、短信、日历等功能。Modi.2数字通讯客户端支持移植到 PDA 设备上。1.121.12可连续性可连续性概念：可连续性是指在环境、资源、人员、流程与程序缺陷等影响下，有应对风险自动调整和快速反应的能力，所保证线上系统的连续运转。示例：编号编号项项Modi.1系统需要 724 式的全天候运行。1.131.13可恢复性可恢复性概念：可恢复性，就是把系统、应用以及数据库由存在故障的状态转变为无故障状态的过程。一般可以从系统恢复、应用恢复、数据恢复等方面进行考虑。示例： 编号编号项

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

15、服务等环境支持。示例：示例：短信系统基于以下软件支撑环境开发及运营：服务器操作系统：AS4.0 update2应用服务器：JBoss4.0.4GA 或者 JBossWeb1.0GAJDK：jdk1.5.0_09数据库：MySQL5.0.17c（认证版）客户端操作系统：WindowsWindows 98 Windows 98SE Windows ME Windows NT 4.0 Windows 2000 Windows XP (建议) Windows Server 2003LinuxLinux kernel - 2.2.14 及以上glibc 2.3.2 及以上XFree86-3.3.6 及以

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

17、开发规范或标准：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, 技术架构设计规范.doc5 技术架构部, 框架设计规范, 版本

18、：1.0, 框架设计规范.doc6 技术架构部, 基于 ASF 的服务器设计规范, 版本：1.0, 基于 ASF 的服务器设计规范.doc2.32.3业务规则业务规则描述软件产品所要遵守的用户业务的行业规则。如果已经存在明确的行业规则文件，在此进行列表引用。示例：编号编号项项Rule.1短信网关只能通过固定的一个 IP 地址与运营商网关建立连接。同一个短信网关可以与运营商网关之间建立多个连接。但连接数量受限制，一般少于10 个。Rule.2短信网关通过运营商网关发送短信的吞吐量受限制，每秒不多于 60 条。.2.42.4法律约束法律约束描述软件不能违背的政府法律或规章制度，可以从国家标准、行业标准、企业标准等方面考虑。2.52.5其它约束其它约束其它未列入上述约束的内容。附录附录 1 1：模版使用