第23章 处理非功能需求

不管你怎么称呼它们，往往都需要花费一些精力，来获得可应用于所构建的软件系统的非功能需求清单。

1．捕捉

我从事软件开发超过15年，其中大部分是在为客户构建软件的情况下做咨询工作。在这段时间，客户明确给出非功能需求信息的次数屈指可数。我当然接到过大量需求规格书或功能需求清单，但很少看到其中包括任何关于性能、伸缩性、安全性等信息。面对这种情况，你就得主动出击，自己去捕捉它们。

挑战就在这里。如果你问一个业务担保人，他们的系统想达到哪种级别的可用性，你可能会得到一个类似“100%”、“24/7/365”或“好的，全部”等回答。

2．提炼

一旦你开始问那些有关非功能需求的棘手问题，或你已经走运到能收到一些信息，就可能需要提炼它们。

有为数不多的几次，我接到功能需求规格书中确实包含一些非功能需求的信息，但通常都含糊无用。举个例子，我曾从潜在客户那里收到过一份125页的文档，详述了对软件系统的需求。其中功能需求的细节占据了文档的绝大部分，只有最后半页是留给非功能需求的。里面说道：

❑ 性能：系统必须要快；

❑ 安全性：系统必须安全；+ 可用性：系统的运行时间应该达到100%。

虽然不是很有用，但至少能展开一些讨论了。你可以根据交流对象变换问题，而不是问需要多少可用性，然后得到一个不可避免的“24/7”的答案。比如下面这些。

❑ “你能忍受的系统停机时间是多少？”

❑ “如果系统核心在朝九晚六的正常工作时间内出现故障，会发生什么？”

❑ “如果系统核心在正常工作时间以外出现故障，会发生什么？”

你现在要做的是探索需求，搞清楚驱动力是什么。为什么系统要可见？当我们谈论“高安全性”，要保护的是什么？我们的目标是获得一组特定的，理论上可以明确量化的非功能需求。比如下面这些。

❑ 系统平均应该支持多少并发用户？高峰时段呢？

❑ 多长的响应时间是可以接受的？系统各个部分都是如此，还是只是针对特定的功能？

❑ 为了保护系统安全，我们究竟该怎么做？我们真的需要对数据加密吗，受限访问足够了吗？

如果你能联想到一定数量的非功能性需求（如用户数、数据量、最大响应时间等），就能写一些验收标准并客观地进行测试。

挑战

记住这一点，如果问人们是否需要一个东西，无疑我们都知道他们会说“是的”。这就是为什么很难划分功能需求、用户故事等的优先级。不管你使用哪一种度量优先级的方法（MoSCoW，高/中/低，等等），只要尝试划分优先级，每件事最后都会变成“不可或缺”。你可以创建一个“一定不能少”的目录，但我们知道每件事都会上目录。

这就要换一种方法，提出成本的影响有助于集中注意力。比如下面这些。

❑ 架构师：“你需要一个正常运行时间为100%的系统。构建这个系统必须通过大量冗余来消除每一个故障点，我们所有的花费都需要翻一番，外加很多自动故障转移工程的工作。这个成本大概是100万美元。或者我们可以为你构建一个简单一些的系统，必须告诫你，某些组件可能需要进行监测，发生故障时需要手动重启，这样的成本大概是10万美元。您需要哪一种呢？”

❑ 担保人：“哦，如果是那样，我要便宜的方案。”

凡事皆有可能，但每件事都有代价。解释那些代价有助于找到给定语境中的最好方案。