非功能性需求是除开功能性需求外需要满足的系统要求，可以理解为系统的质量要求，一般包括性能、安全性、可靠性、可用性、可维护性、完整性、可测试性、有效性等。细分下来有很多，不过前辈们和一些权威机构帮我们做了很好的归类。
常见的软件质量模型有：
●JimMcCall软件质量模型（1977年）
●BarryW.Boehm软件质量模型（1978年）
●FURPS/FURPS+软件质量模型
●R.GeoffDromey软件质量模型
●ISO/IEC9126软件质量模型（1993年）
●ISO/IEC25010软件质量模型（2011年）
我个人认为IBM的RUP里的“FURPS+”是比较好的方法，可以作为检查表来用，避免需求遗漏；而ISO的软件质量模型当然是最权威的了。下面简单说明一下这两个方法。
1.“FURPS+”模型
●功能性（Functional）：特性、功能、安全性；
●可用性（Usability）：人性化因素、帮助、文档；
●可靠性（Reliability）：故障频率、可恢复性、可预测性；
●性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率；
●可支持性（Supportability）：适应性、可维护性、国际化、可配置性。
●“+”是指一些辅助性的和次要的因素，比如：
○实现（Implementation）：资源限制、语言和工具、硬件等；
○接口（Interface）；强加于外部系统接口之上的约束；
○操作（Operation）：对其操作设置的系统管理；
○包装（Packaging）例如物理的包装盒；
○授权（Legal）：许可证或其他方式。
2.ISO/IEC25010软件质量模型
在工作中，一般不会全部都考虑到，但一些常用的维度还是要有，如性能、可靠性、可维护性、安全性、可用性等，其中最为重要的无疑是“性能”这一点，效率上无法保障其他的都面谈，因此在功能设计上要时刻考虑对性能带来的影响。
但是对于需求分析师来说，调研非功能性需求比调研功能性需求难很多。其中一个原因是非功能性需求没有放之四海而皆准的通用标准。我们经常在写需规的时候都会复制粘贴一些常见的指标，如：
●登陆时间≤5秒
●页面间跳转时间≤3秒
●精确查询（包括请求服务）响应时间≤1秒
●模糊查询响应时间≤5秒
●支持静态用户（注册用户）在50000以上
●支持动态用户（在线用户）在1500以上
●支持并发数300以上
但实际上非功能性需求很难做到具体的量化，例如同样是模糊查询，对固定表的某个字段的模糊查询和全省资源库综合查询，其查询的资源都不在一个量级上，因此简单的用一项“模糊查询响应时间≤5秒”来概括显然不合适。因此不同的项目因条件和要求不同，非功能性需求也有所不同。
另一个非功能性需求不好调研的原因是它更接近架构设计的范畴，是架构师考虑的事，刚好这些是需求分析师不擅长的，正因为这个不擅长也导致需求分析师经常选择性的忽略这部分内容。
那么应该如何调研非功能性需求呢？我认为可以从以下几方面出发考虑。
第一，时刻关注非功能性需求
在调研业务需求时，要时刻留意功能实现对非功能性指标所带来的影响，并在调研过程中有意识地了解系统运行的相关情况，例如客户提供的硬件设备，用户量，业务量，业务办理频率、峰值等问题。
第二，让架构师提前参与
对于一些客户明确提出的关键指标或可预见的问题，如大数据应用的性能问题，或者像可靠性、可用性等问题，需要让架构师提前考虑，在技术上给出解决方案。
第三，多总结
在工作中及时总结，记录问题和解决方案，并进行归类整理，在下一个同类的系统或项目时，做到提前考虑。
