非功能性需求描述系统的质量（它是什么）而不是行为（它做什么）。 Scott Ambler 在 Dr. Dobb’s 网站的一篇文章中提到：“Scrum 的产品功能清单可以容纳功能性需求，但是……对于非功能性需求和架构的约束来说，它就没那么好使了。”他的观点也引发了诸多讨论。
文章在 Scrum Development Yahoo 讨论组上激起争论。人们分享了自己如何使用 Scrum 获取非功能性需求的经验。 Ron Jeffries 提供了一个实例需求：系统要保证 99% 的正常运行时间，大家以此为中心展开了讨论。
针对该需求，有人建议将其转化为功能需求，这样就可以把它用时间盒限制起来，并对其进行测试了。这个需求就会变成：系统在［时间范围］之内，要保证 99% 的正常运行时间。这样就会带来附加的功能需求，比如创建监控和通知机制。
有些人建议使用其他方式，比如这类的需求可以放在团队的“完成定义”中。也就是说，除非保证每个故事的实现不会导致系统发生故障，否则故事就不能被视为完成。这可以通过诸如审查过程和/ 或负载测试来完成。
欢迎读者留下评论，分享您所了解的Scrum 团队应对非功能性需求的经验。
暂无签名
最新发布
你的 Scrum 检查列表
2011-04-20
Apache 基金会主席 Doug Cutting 谈 Hadoop 和开源
2012-01-17
InfoQ 专访 eBay 系统架构总监 Tony Ng：聊聊电商网站的架构与安全
2011-12-06
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
跨集群、跨区域、跨多云的异构数据编排平台
数据回归用户：Apache Pinot在用户导向实时数据分析的实践
下一代微服务架构的实践与探索
评论