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