主题：【原创】非功能需求之“频度”——由《银行的事故》说开去 -- 看看
读河蚌的《银行的事故》，及至这段，略有感慨：
现如今在软件开发这一块，做应用系统的需求分析，主流是FURPS+。一般地，需求可分作两大块：功能需求和非功能需求。非功能需求中，又可分为性能、安全性、易用性、可用性、互操作性、可靠性、鲁棒性、可伸缩性，以及一些与开发相关，只有开发人员感兴趣的质量属性。这些东西，就是一个系统架构师在某个应用系统的开发中，所要关注的焦点，因为，它们决定了一个系统的架构。
从《银行的事故》中这一段所描述的情况看，很明显，这个系统的性能、可用性、可靠性、可伸缩性，都出现了一些问题。一般来讲，在这些方面出现问题的系统，其鲁棒性更是脆弱得提都不要提。就这个故事中的这个案例而言，所有这些质量属性上的问题，都与一个非功能需求相关联——频度。
这个故事非常完美地解释了，频度是怎样影响到系统的质量属性，从而反映出频度这一非功能需求对系统架构分析和设计的无比重要。那么，在我们的实际工作中，是不是对这一需求做到了足够重视呢？
去年的这个时候，我听取了一个系统的需求说明。讲解人是需求搜集整理者本人。令我感到奇怪的是，尽管文档标题是“软件需求规格说明书”，可是从头至尾，都只有反映功能需求的用例和业务流程，而一份完整的软件需求规格说明，应该是由功能需求和非功能需求两部分组成的。于是，待讲解完毕，我提了一个问题：
“请问，非功能需求在哪里？”
“非功能需求在设计文档里。”
这令我大为惊奇，不过，出于礼貌，我尽管心存疑虑，却也没有进一步追问。过了半年多，我才从这个项目的另一位需求搜集者那里得知原委。说来啼笑皆非，这仅仅是因为他们这些做需求的搞不懂非功能需求，也不知该如何搜集这方面的需求，不得不把这个问题交给设计人员去闭门造车。
可能是为了排除自己的尴尬，讲解人说：“其实这份文档里也是有非功能需求的，比如说，我们每个用例中，都有它的频度。”一边说，一边卷动文档。我看到在某些用例的“频度”一栏中，确实填得有内容：
“很高”
这算是什么呢？
对需求分析而言，一个很重要的原则是对产品的主观评价和客观指标要严格区分，这二者的区别在于，客观指标可以度量，而主观评价因人而异，也难以度量。如果主观评价不可避免，那么就要建立可以度量的客观指标，在主观评价与客观指标之间建立某种联系，并就这种联系与客户和开发人员达成一致。
“很高”无疑是一个主观评价。我们必须将其与一定的客观指标相关联，这个主观评价对于开发人员才有实际意义。比如，用例一天发生一次，这样的频度算不算高呢？然而，即便是同一个发生频率，对不同的应用而言，评价也截然不同。例如，对一个交互的用例而言，一天两次的发生频率是很低的了，象“订票”这样的用例，一个用户每天可能要执行成百上千例才算得上高；可是，对许多批处理应用来说，一天执行两次的频度相当地高，高到了想不出有什么必要这么“频繁”地运行这个程序。
所以，一般而言，我不推荐采用主观评价来做需求分析。当然，凡事都有例外，有些客观指标太专业，客户无法理解，这时，如何巧妙地将客观指标转换为客户可以理解的主观评价，并就此达成一致，就十分重要了。
可是“频度”不在此列。任何一个有着正常智力的客户都明白“一天一次”、“一次持续两小时”这样的描述的准确含义。那么，在与客户交流时，就直接使用好了。讲解人在这里暴露了这个组织在对需求的理解上的弱点，正是这个弱点导致了他们由设计人员在设计文档中编写非功能需求。他说：
“我们用这种方式（指高、中、低的主观评价）与用户交流没有任何问题。”
是啊，也许他与用户对于“很高”的理解是一致的，也许不是。可是，他丝毫也没有想过，需求不仅是与客户交流的工具，项目合同的凭证，也是软件进一步的分析与设计的基础。与客户的交流没有问题？那很好，可是与系统架构师的交流呢？
系统架构师看到这样的需求会无奈地苦笑，然后试图凭经验解析需求人员与客户之间达成的神秘“共识”。
一般而言，“频度”可以用间隔时间和持续时间来表述。但是，在某些情况下，这是不够的，它还与用例的表达有关。此外，它对质量属性的影响，也不限于在《银行的事故》中表现出来的那些，例如，它有可能会影响易用性。为说明这两点，我们来看一个例子。
需求搜集者：“我可以看看你要录入的单据吗？”
用户：“当然可以。”
（需求搜集者详细记录单据的各项条目，然后就这些数据的格式等问题咨询用户）
需求搜集者：“每天大概会有多少张单据呢？”
用户：“一百来张吧。”
（需求搜集者根据每天的工作时数估算录入单据的平均时间间隔，根据每张单据的数据量估算录入一张单据所需时间，他对此有足够的把握，没有就此向用户求证）
在随后的案头工作中，需求搜集者将这次访问整理成用例，他以录入一张单据的过程作为主成功场景来设计用例，在“频度”一栏写道：“每4～5分钟发生一次，持续1分钟”。
然而，这位需求搜集者所不了解的一个事实是，这些单据并不是每天陆陆续续地来到用户的手中的，而是由专人收集，每天集中送达用户，用户再行输入的。用户把每天输入这些数据看作“一次”，在他的眼中，频度是“每天一次，持续两小时”！
对于一个每4～5分钟发生一次的用例，用户有等待时间，他也许不会在乎每次输入时进行启动用例和退出用例的操作，也不会对各输入控件的tab顺序和对鼠标的依赖有任何抱怨。但是，如果是集中输入一批单据，用户无法容忍每输入一张单据都要执行一次启动和退出操作，还会抱怨时而鼠标、时而键盘的操作降低了他的工作效率。他需要的是自录入第一张单据起，到最后一张单据完毕，可以手不离键盘的操作，输入焦点在各输入控件之间的转换与单据的阅读顺序相一致。
这是一条被忽略了的易用性需求。然而，在“频度”的背后，我们可能失去的更多……
本帖一共被 2 帖 引用 (帖内工具实现)
要件定义恐怕是系统开发最为关键的一步了，而后的工程是让人如入泥沼，还是准点过关，都从这里开始分岐。
其实最好和客户一起把当前的业务流程图整理出来，而后根据开发思路，未来趋向和客户一起讨论重新优化业务过程，大多数隐患消除后，再整理要件式样书就安心很多。这样需要的时间比较多，但磨刀不误砍柴功。
真的没有银弹？
老哥提出了一个软件行业非常头疼的问题，切中要害，遗憾的是，好像业界还没有针对这个问题非常好的解决方法。
在软件工程领域，需求的分析还是局限在功能需求这一块，对于非功能需求方面，确实还是需要架构师猜测“神秘的共识”，但是共识到底有没有，都还是个问题。
业界对于代码、算法和UI，有很深入的研究和指标，例如时间复杂度空间复杂度和UI设计规范，客户对于业务，也有自己对于频度、易用性要求的认知，但是这两方面之间至今缺少一个可用的”翻译体系“。基于一个悲观的论断——客户永远“说”不出自己要什么，有的时候，干脆就鸵鸟策略，上线的时候，开发组上香求佛，业务组跳脚骂娘，等到工程款已结，那就逃出生天。
抱怨到这里，突然想到“敏捷”两个字，这种方法论这两年很热，“拥抱变化”听起来非常酷，深层次的思考一下，竟然是对于各种类型需求“否定之否定”的对立统一。
“世间武功，无坚不破，唯快不破”
以我万变之不变，对你不变之万变，感觉路子仿佛对头，就看软件开发技术以及工程工具能不能跟得上了。从这个思路往下走，重量级的、开发效率低的开发工具，慢慢走向末路，而动态语言逐渐显示出自己的优势，隐隐应和了这种“敏捷”的趋势，仿佛天生一对。
Without me ,you are nothing.
Without you,I am noting.
那么剩下的问题，就是计算资源的伸缩性要求了，越是强悍的计算能力，越是“敏捷”和“动态”的绝配。
好像跑题了，我们在谈“云”么？好像是。
打住。