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