确定非功能需求

非功能需求一般和系统的状态有关而与系统需要提供的功能无关。通常是系统的“ 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 强烈建议称之为质量需求。

查看英文原文： Nailing Down Non-Functional Requirements