您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 需求管理 > 正文

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

发表于:2017-08-07 作者:毛毛哥PM 来源:

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

 相关文章