qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

如何确定非功能需求?

非功能需求一般和系统的状态有关而与系统需要提供的功能无关。通常是系统的“ ilities”功能,比如可扩展性(scalability)、互操作性(interoperability)、可维护性(maintainability)、移植性(portability)、性能和安全性都包括在此类。敏捷团队经常纠结于定义和估算项目的非功能需求。
  Mike Cohn建议几乎所有的非功能需求都能以用户故事表述。他给出了几个例子展示非功能需求能够适用标准的用户故事模板
  幸运的是约束/非功能需求能很容易的按用户故事处理。这里给出几个例子:
  作为客户,我要在从Windows 95之后的所有版本的Windows上运行产品。
  作为CTO,我要(新)系统使用我们已有的订单数据库而不是创建新数据库,这样我们就不用再多维护一个数据库了。
  作为用户,我要网站在99.999%的时间是可访问的,这样我就不会感到沮丧并找其它的网站来用。
  然而,Mike也警告说用户故事模板只是用来作为一个思考工具。不应该用一个固定的模板来记录所有的非功能需求。
  Jason建议不要试图在用户故事级别记录非功能需求,团队应该把它们作为(项目)大图景的一部分。按照Jason所说,在他的团队,他们尝试过在每个单独的用户故事级别记录非功能需求,但是没起到作用。他提到:
  我喜欢把这些非功能需求(NFR)用户故事写在墙上并在工作区都能看到,这样可以提醒团队在给出估算时考虑这些约束的因素。
  Mike还提出一种明确的方法来估算非功能需求。按他所说,非功能需求与两个成本相关联
  初始遵循(非功能需求)成本——团队满足非功能需求所用的工作量。比如,在sprint 5花在性能测试上的工作量。
  持续遵循(非功能需求)成本——在以后的sprint中满足非功能需求的工作量。
  一旦团队接受非功能需求作为项目的一部分(就像我们团队在sprint 5中做的),他们需要把持续达到非功能需求作为项目的提示。我认为这种成本就像上税。进行性能测试(或者说遵从任何非功能需求)产生了一些额外的开支(税)。这种开支,或者说税,是必须定期付出的。
  为了估算,Mike认为这两种成本需要单独考虑。初始遵循成本应该和任何其它的用户故事或产品backlog中的任务一样被估算。持续遵循成本,团队和product owner需要决定多久要进行一次遵循验证工作。
  例如,假设团队和product owner同意每四个两周的sprint中进行一次性能测试。团队估算每次第四个sprint有六个点的工作要做。那就是大约每个sprint1.5点。如果团队的速度(velocity)是30个点,1.5点可以认为是大约5%的税。
  Nick Xldis对遵循成本进行了一次非常有意思的观察。据Nick所说,
  如果这种税持续增长,那你的架构或流程上就有问题了,需要格外关注。这是对于技术债的很好的晴雨表。
  Scott Ambler通过提升一个独立测试团队的能力分享了管理非功能需求的想法。
  Kassab、Olga、Maya和Alain介绍了NFR大小测量方法(NFSM)来减少估算非功能需求中的不确定性。
  因此,处理非功能需求可能不是痛苦的挣扎。关键是尽早处理它们并关注持续成本。
  注意:关于非功能需求这一术语的使用有很多想法和争论。Mike Cohn称其为约束而Tom Glib强烈建议称之为质量需求。

posted on 2014-08-27 10:33 顺其自然EVO 阅读(427) 评论(0)  编辑  收藏 所属分类: 测试学习专栏敏捷测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年8月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜