第23章 处理非功能需求

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

1.捕捉

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

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

2.提炼

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

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

性能:系统必须要快;

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

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

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

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

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

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

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

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

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

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

挑战

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

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

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

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

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