需求分析师如何做好非功能性需求

来源：https://blog.csdn.net/jjm1437/article/details/53911262

非功能性需求是除开功能性需求外需要满足的系统要求，可以理解为系统的质量要求，一般包括性能、安全性、可靠性、可用性、可维护性、完整性、可测试性、有效性等。细分下来有很多，不过前辈们和一些权威机构帮我们做了很好的归类。
常见的软件质量模型有：

● Jim McCall 软件质量模型（1977 年）
● Barry W. Boehm 软件质量模型（1978 年）
● FURPS/FURPS+ 软件质量模型
● R. Geoff Dromey 软件质量模型
● ISO/IEC 9126 软件质量模型（1993 年）
● ISO/IEC 25010 软件质量模型（2011 年）

我个人认为IBM的RUP里的“FURPS+”是比较好的方法，可以作为检查表来用，避免需求遗漏；而ISO的软件质量模型当然是最权威的了。下面简单说明一下这两个方法。

1.“FURPS+”模型

● 功能性（Functional）：特性、功能、安全性；
● 可用性（Usability）：人性化因素、帮助、文档；
● 可靠性（Reliability）：故障频率、可恢复性、可预测性；
● 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率；
● 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。
● “+”是指一些辅助性的和次要的因素，比如：
○ 实现（Implementation）：资源限制、语言和工具、硬件等；
○ 接口（Interface）；强加于外部系统接口之上的约束；
○ 操作（Operation）：对其操作设置的系统管理；
○ 包装（Packaging）例如物理的包装盒；
○ 授权（Legal）：许可证或其他方式。

2. ISO/IEC 25010 软件质量模型

在工作中，一般不会全部都考虑到，但一些常用的维度还是要有，如性能、可靠性、可维护性、安全性、可用性等，其中最为重要的无疑是“性能”这一点，效率上无法保障其他的都面谈，因此在功能设计上要时刻考虑对性能带来的影响。
但是对于需求分析师来说，调研非功能性需求比调研功能性需求难很多。其中一个原因是非功能性需求没有放之四海而皆准的通用标准。我们经常在写需规的时候都会复制粘贴一些常见的指标，如：

● 登陆时间≤5秒
● 页面间跳转时间≤3秒
● 精确查询（包括请求服务）响应时间≤1秒
● 模糊查询响应时间≤5秒
● 支持静态用户（注册用户）在50000以上
● 支持动态用户（在线用户）在1500以上
● 支持并发数300以上

但实际上非功能性需求很难做到具体的量化，例如同样是模糊查询，对固定需求分析师如何做好非功能性需求求也有所不同。
另一个非功能性需求不好调研的原因是它更接近架构设计的范畴，是架构师考虑的事，刚好这些是需求分析师不擅长的，正因为这个不擅长也导致需求分析师经常选择性的忽略这部分内容。
那么应该如何调研非功能性需求呢？我认为可以从以下几方面出发考虑。
第一，时刻关注非功能性需求
在调研业务需求时，要时刻留意功能实现对非功能性指标所带来的影响，并在调研过程中有意识地了解系统运行的相关情况，例如客户提供的硬件设备，用户量，业务量，业务办理频率、峰值等问题。
第二，让架构师提前参与
对于一些客户明确提出的关键指标或可预见的问题，如大数据应用的性能问题，或者像可靠性、可用性等问题，需要让架构师提前考虑，在技术上给出解决方案。
第三，多总结
在工作中及时总结，记录问题和解决方案，并进行归类整理，在下一个同类的系统或项目时，做到提前考虑。