非功能性需求是除开功能性需求外需要满足的系统要求，可以理解为系统的质量要求，一般包括性能、安全性、可靠性、可用性、可维护性、完整性、可测试性、有效性等。细分下来有很多，不过前辈们和一些权威机构帮我们做了很好的归类。
　　常见的软件质量模型有：
　　●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秒”来概括显然不合适。因此不同的项目因条件和要求不同，非功能性需求也有所不同。
　　另一个非功能性需求不好调研的原因是它更接近架构设计的范畴，是架构师考虑的事，刚好这些是需求分析师不擅长的，正因为这个不擅长也导致需求分析师经常选择性的忽略这部分内容。
　　那么应该如何调研非功能性需求呢？我认为可以从以下几方面出发考虑。
　　第一，时刻关注非功能性需求
　　在调研业务需求时，要时刻留意功能实现对非功能性指标所带来的影响，并在调研过程中有意识地了解系统运行的相关情况，例如客户提供的硬件设备，用户量，业务量，业务办理频率、峰值等问题。
　　第二，让架构师提前参与
　　对于一些客户明确提出的关键指标或可预见的问题，如大数据应用的性能问题，或者像可靠性、可用性等问题，需要让架构师提前考虑，在技术上给出解决方案。
　　第三，多总结
　　在工作中及时总结，记录问题和解决方案，并进行归类整理，在下一个同类的系统或项目时，做到提前考虑。