非功能性需求描述系统的质量（它是什么）而不是行为（它做什么）。Scott Ambler在Dr. Dobb’s 网站的一篇文章中提到：“Scrum 的产品功能清单可以容纳功能性需求，但是……对于非功能性需求和架构的约束来说，它就没那么好使了。”他的观点也引发了诸多讨论。
文章在Scrum Development Yahoo 讨论组上激起争论。人们分享了自己如何使用 Scrum 获取非功能性需求的经验。Ron Jeffries 提供了一个实例需求：系统要保证 99% 的正常运行时间，大家以此为中心展开了讨论。
针对该需求，有人建议将其转化为功能需求，这样就可以把它用时间盒限制起来，并对其进行测试了。这个需求就会变成：系统在［时间范围］之内，要保证 99% 的正常运行时间。这样就会带来附加的功能需求，比如创建监控和通知机制。
有些人建议使用其他方式，比如这类的需求可以放在团队的“完成定义”中。也就是说，除非保证每个故事的实现不会导致系统发生故障，否则故事就不能被视为完成。这可以通过诸如审查过程和 / 或负载测试来完成。
欢迎读者留下评论，分享您所了解的 Scrum 团队应对非功能性需求的经验。
注册/登录 InfoQ 发表评论