常见非功能性需求的描述案例

Posted 2022-07-31 麦哲思科技任甲林

 非功能性需求是需求的一个重要组成部分，它影响了系统的架构设计，需要开发人员重点关注。但是在工程实践中，往往客户不会提出非功能性需求，需求人员在描述需求时不知道如何描述，在国际的各种标准中，对非功能性需求有定义，但是比较抽象。因此我整理如下常见的非功能性需求的描述案例，供需求人员进行参考。

1、性能需求描述案例：

响应时间：

在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。

定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。

在网络畅通时，拨号连接GPRS网络所需时间不得超过5秒。

在网络畅通时，电子地图刷新时间不超过10秒。

在推荐配置环境下：登录响应时间在2秒内，刷新栏目响应时间在2秒内，刷新条目分页列表响应时间2秒内，打开信息条目响应时间1秒内，刷新部门、人员列表响应时间2秒内。

在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。

业务量：

每日最大成交数3000笔业务。

平均交易并发数为20，最大交易并发数为50。

估计用户数为1万人，每天登录用户数为3000左右，网络的带宽为100M带宽。

系统可以同时满足10,000个用户请求，并为25,000个并发用户提供浏览功能。

系统容量：

支持3万用户，支持GB级数据。

数据库表行数不超过100万行，数据库最大容量不超过1000GB，磁盘空间至少需要40G以上。

精度：

定位精度误差不超过80米。

当通过互联网接入系统的时候，期望在编号和名称搜索时最长查询时间<15秒。

计算的精确性到小数点后7位。

资源使用率：

CPU占用率<=50%。

内存占用率<=50%。

2、安全需求描述案例：

严格权限访问控制，用户在经过身份认证后，只能访问其权限范围内的数据，只能进行其权限范围内的操作。

不同的用户具有不同的身份和权限，需要在用户身份真实可信的前提下，提供可信的授权管理服务，保护数据不被非法/越权访问和篡改，要确保数据的机密性和完整性。

提供运行日志管理及安全审计功能，可追踪系统的历史使用情况。

能经受来自互联网的一般性恶意攻击。如病毒（包括木马）攻击、口令猜测攻击、黑客入侵等。

至少99%的攻击需要在10秒内检测到。

3、可靠性需求描述案例：

对输入有提示，数据有检查，防止数据异常。

系统健壮性强，应该能处理系统运行过程中出现的各种异常情况，如：人为操作错误、输入非法数据、硬件设备失败等，系统应该能正确的处理，恰当的回避。

因软件系统的失效而造成不能完成业务的概率要小于5‰。

要求系统7x24小时运行，全年持续运行故障停运时间累计不能超过10小时。

系统缺陷率每1,000小时最多发生1次故障。

在1,000,000次交易中，最多出现1次需要重新启动系统的情况。

4、兼容性需求描述案例：

系统应支持ios，android , windows操作系统;

系统应支持Oracle, DB2 数据库系统;

最多只有5%的系统实现需要具体到特定的操作系统。

替换关系数据库系统的平均时间不超过2小时，并且保证没有数据丢失。

5、数据保密需求描述案例：

网络传递数据应经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。业务数据需要在存储时进行加密，确保不可破解。

6、环境需求描述案例：

	硬件	操作系统及其版本	应用服务器软件及其版本	应用软件及其部件
服务器	IBM RS6000	AIX 4.3.3	IBM HTTP Server、Apache、MS IIS5.0等；	DB2（7.2 EE以上版本）
			WAS（4.0以上版本）、Web Logic(7.0以上版本)等；	Oracle EE（9i EE以上版本）
浏览客户端	PII 800/64M/2G	Win98及以上	IE 5.0以上或Netscape同等版本以上
特殊客户端	PII 2G/64M/2G	建议配置Win2000及以上	IE 5.0以上或Netscape同等版本以上	MicroStrategy7i客户端

7、易用性需求描述案例：

在引入该产品的3个月内，60％的用户应该可以在45秒内用它来完成转账的任务，失败率控制在万分之一以内。

60％的用户在第一次看见该产品的5秒内，就会意识到这是**银行的网银。

80%的用户在接受一个2小时的系统介绍培训后，可以在5分钟之内成功预订房间。

8、可用性需求描述案例：

有些农村地区网络质量差，带宽小。在网络环境差的条件下保证系统的可用性等。

在95%的故障中，系统最多需要20秒重启。

提供数据备份和恢复功能，使得在由于系统的错误或其他原因引起系统的数据丢失或系统的数据被破坏时，能够及时恢复和还原数据（由硬件及第三方软件提供此功能）。

9 、可测试性需求描述案例：

一个模块的最大圈复杂度不能超过15。

交付的系统必须通过单元测试，并且是100%覆盖。

开发活动必须使用回归测试，并允许在12小时内重新进行完整的测试。

10、可维护性需求描述案例：

从接到修改请求后，对于普通修改应在1~2天内完成；对于评估后为重大需求或设计修改应在1周内完成。

90%的BUG修改时间不超过1个工作日，其他不超过2个工作日。

代码的圈复杂度必须在10以内。

任何对象的任何方法都不允许超过200行代码。

安装新版本必须保持所有的数据库内容和所有个人设置不变。

产品必须提供可跟踪任何数据库字段的工具。