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

真的没有银弹？

老哥提出了一个软件行业非常头疼的问题，切中要害，遗憾的是，好像业界还没有针对这个问题非常好的解决方法。

在软件工程领域，需求的分析还是局限在功能需求这一块，对于非功能需求方面，确实还是需要架构师猜测“神秘的共识”，但是共识到底有没有，都还是个问题。

业界对于代码、算法和UI，有很深入的研究和指标，例如时间复杂度空间复杂度和UI设计规范，客户对于业务，也有自己对于频度、易用性要求的认知，但是这两方面之间至今缺少一个可用的”翻译体系“。基于一个悲观的论断——客户永远“说”不出自己要什么，有的时候，干脆就鸵鸟策略，上线的时候，开发组上香求佛，业务组跳脚骂娘，等到工程款已结，那就逃出生天。

抱怨到这里，突然想到“敏捷”两个字，这种方法论这两年很热，“拥抱变化”听起来非常酷，深层次的思考一下，竟然是对于各种类型需求“否定之否定”的对立统一。

“世间武功，无坚不破，唯快不破”

以我万变之不变，对你不变之万变，感觉路子仿佛对头，就看软件开发技术以及工程工具能不能跟得上了。从这个思路往下走，重量级的、开发效率低的开发工具，慢慢走向末路，而动态语言逐渐显示出自己的优势，隐隐应和了这种“敏捷”的趋势，仿佛天生一对。

Without me ,you are nothing.

Without you,I am noting.

那么剩下的问题，就是计算资源的伸缩性要求了，越是强悍的计算能力，越是“敏捷”和“动态”的绝配。

好像跑题了，我们在谈“云”么？好像是。

打住。