01产品项目非功能需求规格说明书模版.docx
- 文档编号:4682840
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:14
- 大小:24.97KB
01产品项目非功能需求规格说明书模版.docx
《01产品项目非功能需求规格说明书模版.docx》由会员分享,可在线阅读,更多相关《01产品项目非功能需求规格说明书模版.docx(14页珍藏版)》请在冰豆网上搜索。
01产品项目非功能需求规格说明书模版
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可维护性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延迟
概念:
延迟定义为从事件触发到对应响应之间的时间间隔。
这个时间间隔定义了一个响应窗口
(开始时间为最小延迟,结束时间为最大延迟)
示例:
编号
项
响应时间
抖动
优先级
备注
Perf丄.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封
概念:
容量:
容量是一个衡量系统可以处理的工作量数量的指标。
比如在理想运行环境下,最大可达到的吞吐量,最大可支持的用户数量等。
需要注意的是,即使在达到最大吞吐量的情况下,系统也不能违背延迟的性能需求。
示例:
编号
项
容量
备注
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,meantimetofailure)来衡量。
与可靠性密切相关的一个概念是有效性。
有效性是指系统正常运行的时间比例。
有效性是通过两次故障之间的时间长度或在系统崩溃的情况下系统能够恢复正常运行的速度来衡量的。
系统处于稳定运行状态的有效性是系统正常运行的时间与全部时间之比,通常是以如下公式来定义的:
MTTF
ot=
MTTF+MTTR
其中:
MTTFmeantimetofailure)表示平均正常运行时间;MTTRmeantimetorepair)表示平均故障恢复时间。
示例:
编号
项
值
Avai.1
在任意时刻邮件服务器正常运行的可能性
99.9%
Avai.2
邮件服务器平均正常运行时间
90天
Avai.3
邮件服务器平均故障恢复时间
43.2分钟
1.4可配置性
概念:
可配置需求的典型目标是确保应用或组件:
国际化,支持在相应的国家或地区使用;
*个性化,支持特定用户的特定需求;
*支持交付具有不同功能子集的产品;
示例:
编号
项
Conf.1
系统必须支持国际化以便在以下国家或地区正确工作:
美国
加拿大
英国
日本
韩国
台湾(地区)
香港(地区)
Conf.2
应用程序必须支持用户各性化定制用户界面,改变文字的颜色、个人图像,…
Conf.3
应用程序支持根据用户的权限显示合适的界面。
当用户的权限发生变化时,用户可见(可操作)的菜单、按钮也随之变化。
1.5互操作性(系统间集成)
概念:
互操作性是一种衡量一组部件(构成一个系统)与另一个系统协作的能力示例:
编号
项
Inte.1
即时通讯系统支持与短信系统互操作,将即时消息通过短信系统发送到用户的手机
Inte.2
即时通讯系统支持与邮件系统互操作,可以支持通过邮件客户端接收离线即时消息
1.6可伸缩性
概念:
可伸缩性是当事务负荷增加时,在保证服务质量的条件下容纳更多用户的能力。
如果能够通过增加资源以满足不断增长的对性能和功能的要求,或者是通过缩减资源,以降低成本,从涵盖硬件和软件的角度上讲,我们可以把符合这种特性的计算机系统称作是可伸缩的。
示例:
编号
项
Scal.1
邮件系统用户数年增长率为10万/年,目标总容量为1000万。
Scal.2
通讯系统客户数年增长率为5万/年,目标总容量为100万。
Scal.3
用户邮箱容量月增长率为10MB月,目标总容量为1GByte。
1.7可维护性
概念:
软件可维护性即维护人员对该软件进行维护的难易程度,具体包括理解、改正、改动和改进该软件的难易程度。
示例:
编号
项
Main.1
修复冋题1(包括回归测试及文档更新)的平均工作量必须小于1人周。
Main.2
完成一次小版本升级的平均工作量必须小于1人周。
Main.3
完成一次重大版本升级的平均工作量必须小于1人月。
1.8可管理性
概念:
软件可管理性即对软件执行管理、监控操作以及接收与这些操作相关的信息的难易程度。
示例:
编号
项
Mana.1
控制
通过改变系统的配置改变软件运行行为。
Mana.2
监视
捕获软件运行时事件和历史事件并报告或发出通知。
Mana.3
跟踪
软件运行状况信息的记录。
1.9可审计性
概念:
可审计性是指系统进行适当的记录存储以:
支持财经审计
支持安全审计
确定是否某些金融事务发生过
示例:
编号
项
Audi.1
短信系统母转发条短信都必须保存以下信息半年以上:
短信发送者
短信接收者短信发送时间短信内容
1.10可安装性
概念:
可安装性是衡量产品安装到运行环境难易程度的一项指标。
可安装性的目标是:
确保应用或组件易于安装;
*确保在安装过程中不会产生时间或金钱上的浪费;•提升安装工程师的士气;
最小化安装的缺陷
示例:
编号
项
Inst.1
一个经过良好训练的部署团队所需要的安装工作量不能超过15人日;
Inst.2
一个典型用户所需要的安装时间不超过15分钟;
1.11可更改性
概念:
可更改性是与系统构架关系最为密切的一个质量属性。
能够进行快速修改并使修改代价尽可能低的能力直接受构架的限制。
对系统的更改一般是由于该系统的组织的商业目的发生了变化。
从广义上看,这些变化主要包括:
功能的扩展或改变。
添加新的功能,改进已有的功能或修复系统中的缺陷。
•删除不再想要的功能。
即优化或简化现有系统的功能。
•适应新的操作环境。
例如处理器硬件、输入/输出设备或其它逻辑设备。
这种能力也称为可移植性。
•结构的重新调整。
例如为使系统的服务更为合理,模块划分更为科学或为优化系统而进行调整。
示例:
编号
项
Modi.1
数字通讯客户端在将来的版本中预计添加邮件、短信、日历等功能。
Modi.2
数字通讯客户端支持移植到PDA设备上。
1.12可连续性
概念:
可连续性是指在环境、资源、人员、流程与程序缺陷等影响下,有应对风险自动
调整和快速反应的能力,所保证线上系统的连续运转示例:
编号
项
Modi.1
系统需要7X24式的全天候运行。
1.13可恢复性
概念:
可恢复性,就是把系统、应用以及数据库由存在故障的状态转变为无故障状态的过程。
一般可以从系统恢复、应用恢复、数据恢复等方面进行考虑。
示例:
编号
项
Modi.1
系统可以进行数据备份,最近30日的业务数据、数据库数据全备份(30份,每日一份,保留2个月),每周周六进行数据完全备份一次(保留2个月),母月末最后日进行数据完全备份次(保田1年),母1小时业务数据、数据库数据增量备份一次。
重大故障需要在4〜8小时恢复服务的可用性,并在在24小时到72小时内恢复历史数据
1.14其它
其它未列入上述需求或还未确定的内容。
2约束
2.1运行环境
描述软件的运行环境相关因素。
包括硬件平台和软件平台的支持。
2.1.1软件平台
描述系统及各个模块运行所需要的操作系统平台、版本、其他的软件组件、应用服务等环境支持。
示例:
短信系统基于以下软件支撑环境开发及运营:
服务器操作系统:
AS4.0update2
应用服务器:
JBoss4.0.4GA或者JBossWeb1.0GA
JDKjdk1.5.0_09
数据库:
MySQL5.0.17c(认证版)
客户端操作系统:
-Windows
Windows98
Windows98SE
WindowsME
WindowsNT4.0
Windows2000
WindowsXP(建议)
WindowsServer2003
-Linux
Linuxkernel-2.2.14及以上
glibc2.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)接口规范(CNGPV2.0。
[3]Fielding,R.,Gettys,J.,Mogul,J.,Nielsen,H.andT.Berners-Lee,"Hypertexttransferprotocol--HTTP/1.1",RFC2068,January1997.
[4]技术架构部,"技术架构设计规范",版本:
1.0,技术架构设计规范.doc
⑸技术架构部,"框架设计规范",版本:
1.0,框架设计规范.doc
⑹技术架构部,"基于ASF的服务器设计规范",版本:
1.0,基于ASF的服务器设计规范.doc
2.3业务规则
描述软件产品所要遵守的用户业务的行业规则。
如果已经存在明确的行业规则文件,在此进行列表引用。
示例:
编号
项
Rule.1
短信网关只能通过固定的一个IP地址与运营商网关建立连接。
同一个短信网关可以与运营商网关之间建立多个连接。
但连接数量受限制,一般少于10个。
Rule.2
短信网关通过运吕商网关发送短信的吞吐量受限制,母秒不多于60条。
2.4法律约束
描述软件不能违背的政府法律或规章制度,可以从国家标准、行业标准、企业标准等方面考虑。
2.5其它约束
其它未列入上述约束的内容。
附录1模版使用说明
1.模版中,黑色字体部分不可裁剪。
在编写时,如果相对应的内容没有或不适用,在相应的标题下写明即可,不能删除。
2.模版中,蓝色字体部分是对于文档内容的解释说明。
在编写时,需要删除这些内容。
3.对于模版中给出的示例,适用的可以保留并填入相关内容;不适用的直接删除。
4.本附录,在《非功能需求说明书》成文时需要删除。
附录2:
模版修订记录
本附录,记录了本模版的修订历史信息。
在《非功能需求说明书》成文时,需要删除。
修改日期
修改的章节
修改类型
修改描述
修改人
审核人
版本号
修改类型分为A-ADDEDM-MODIFIEDD-DELETED
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 01 产品 项目 功能 需求 规格 说明书 模版
![提示](https://static.bdocx.com/images/bang_tan.gif)