主题：【原创】非功能需求之“频度”——由《银行的事故》说开去 -- 看看

读河蚌的《银行的事故》，及至这段，略有感慨：

现如今在软件开发这一块，做应用系统的需求分析，主流是FURPS+。一般地，需求可分作两大块：功能需求和非功能需求。非功能需求中，又可分为性能、安全性、易用性、可用性、互操作性、可靠性、鲁棒性、可伸缩性，以及一些与开发相关，只有开发人员感兴趣的质量属性。这些东西，就是一个系统架构师在某个应用系统的开发中，所要关注的焦点，因为，它们决定了一个系统的架构。

从《银行的事故》中这一段所描述的情况看，很明显，这个系统的性能、可用性、可靠性、可伸缩性，都出现了一些问题。一般来讲，在这些方面出现问题的系统，其鲁棒性更是脆弱得提都不要提。就这个故事中的这个案例而言，所有这些质量属性上的问题，都与一个非功能需求相关联——频度。

这个故事非常完美地解释了，频度是怎样影响到系统的质量属性，从而反映出频度这一非功能需求对系统架构分析和设计的无比重要。那么，在我们的实际工作中，是不是对这一需求做到了足够重视呢？

去年的这个时候，我听取了一个系统的需求说明。讲解人是需求搜集整理者本人。令我感到奇怪的是，尽管文档标题是“软件需求规格说明书”，可是从头至尾，都只有反映功能需求的用例和业务流程，而一份完整的软件需求规格说明，应该是由功能需求和非功能需求两部分组成的。于是，待讲解完毕，我提了一个问题：

“请问，非功能需求在哪里？”

“非功能需求在设计文档里。”

这令我大为惊奇，不过，出于礼貌，我尽管心存疑虑，却也没有进一步追问。过了半年多，我才从这个项目的另一位需求搜集者那里得知原委。说来啼笑皆非，这仅仅是因为他们这些做需求的搞不懂非功能需求，也不知该如何搜集这方面的需求，不得不把这个问题交给设计人员去闭门造车。

可能是为了排除自己的尴尬，讲解人说：“其实这份文档里也是有非功能需求的，比如说，我们每个用例中，都有它的频度。”一边说，一边卷动文档。我看到在某些用例的“频度”一栏中，确实填得有内容：

“很高”

这算是什么呢？

对需求分析而言，一个很重要的原则是对产品的主观评价和客观指标要严格区分，这二者的区别在于，客观指标可以度量，而主观评价因人而异，也难以度量。如果主观评价不可避免，那么就要建立可以度量的客观指标，在主观评价与客观指标之间建立某种联系，并就这种联系与客户和开发人员达成一致。

“很高”无疑是一个主观评价。我们必须将其与一定的客观指标相关联，这个主观评价对于开发人员才有实际意义。比如，用例一天发生一次，这样的频度算不算高呢？然而，即便是同一个发生频率，对不同的应用而言，评价也截然不同。例如，对一个交互的用例而言，一天两次的发生频率是很低的了，象“订票”这样的用例，一个用户每天可能要执行成百上千例才算得上高；可是，对许多批处理应用来说，一天执行两次的频度相当地高，高到了想不出有什么必要这么“频繁”地运行这个程序。

所以，一般而言，我不推荐采用主观评价来做需求分析。当然，凡事都有例外，有些客观指标太专业，客户无法理解，这时，如何巧妙地将客观指标转换为客户可以理解的主观评价，并就此达成一致，就十分重要了。

可是“频度”不在此列。任何一个有着正常智力的客户都明白“一天一次”、“一次持续两小时”这样的描述的准确含义。那么，在与客户交流时，就直接使用好了。讲解人在这里暴露了这个组织在对需求的理解上的弱点，正是这个弱点导致了他们由设计人员在设计文档中编写非功能需求。他说：

“我们用这种方式（指高、中、低的主观评价）与用户交流没有任何问题。”

是啊，也许他与用户对于“很高”的理解是一致的，也许不是。可是，他丝毫也没有想过，需求不仅是与客户交流的工具，项目合同的凭证，也是软件进一步的分析与设计的基础。与客户的交流没有问题？那很好，可是与系统架构师的交流呢？

系统架构师看到这样的需求会无奈地苦笑，然后试图凭经验解析需求人员与客户之间达成的神秘“共识”。

一般而言，“频度”可以用间隔时间和持续时间来表述。但是，在某些情况下，这是不够的，它还与用例的表达有关。此外，它对质量属性的影响，也不限于在《银行的事故》中表现出来的那些，例如，它有可能会影响易用性。为说明这两点，我们来看一个例子。

需求搜集者：“我可以看看你要录入的单据吗？”

用户：“当然可以。”

（需求搜集者详细记录单据的各项条目，然后就这些数据的格式等问题咨询用户）

需求搜集者：“每天大概会有多少张单据呢？”

用户：“一百来张吧。”

（需求搜集者根据每天的工作时数估算录入单据的平均时间间隔，根据每张单据的数据量估算录入一张单据所需时间，他对此有足够的把握，没有就此向用户求证）

在随后的案头工作中，需求搜集者将这次访问整理成用例，他以录入一张单据的过程作为主成功场景来设计用例，在“频度”一栏写道：“每4～5分钟发生一次，持续1分钟”。

然而，这位需求搜集者所不了解的一个事实是，这些单据并不是每天陆陆续续地来到用户的手中的，而是由专人收集，每天集中送达用户，用户再行输入的。用户把每天输入这些数据看作“一次”，在他的眼中，频度是“每天一次，持续两小时”！

对于一个每4～5分钟发生一次的用例，用户有等待时间，他也许不会在乎每次输入时进行启动用例和退出用例的操作，也不会对各输入控件的tab顺序和对鼠标的依赖有任何抱怨。但是，如果是集中输入一批单据，用户无法容忍每输入一张单据都要执行一次启动和退出操作，还会抱怨时而鼠标、时而键盘的操作降低了他的工作效率。他需要的是自录入第一张单据起，到最后一张单据完毕，可以手不离键盘的操作，输入焦点在各输入控件之间的转换与单据的阅读顺序相一致。

这是一条被忽略了的易用性需求。然而，在“频度”的背后，我们可能失去的更多……

• 西河文萃 第21期 2009年4月1日 上
• 西河文萃 第21期 2009年3月1日