软件架构设计为什么这么难？因为架构设计并不是简单的处理“纯粹的技术问题”，而是要面对“技术与业务的关系问题”。最终，要求架构师不仅懂业务，而且能理顺复杂的技术和业务之间的关系。

从面向业务的需求，到最终的面向技术的软件系统，要跨很大的鸿沟。软件架构设计就是要完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁。软件架构师根据各种需求进行架构设计，最终的软件架构包含了结构、协作、技术等方面的重要决策，为系统化的开发活动建立了基础。

接下来，请大家思考如下几个问题：

为数不少架构师都认为自己是技术人员，职责是“知道需求之后设计出架构”。比如，老沈。

老沈是资深架构师，在某公司的设计部任职。一次，他首先的小魏充满虔诚的捧着几道题目来请教他。

老沈扫了一眼，皱起了眉头，语重心长的说：“小魏，你的理想不是要当首席架构师吗，怎么研究其需求来了？小伙子不要朝三暮四哟！”

小魏的表情充满了惊讶。稍过片刻，他鼓起了十二分勇气问道：“沈老师，你的意思是架构师不必深入研究需求？”

老沈道：“拜托，懂点儿软件工程好不好，现代软件工程讲究角色分工和团队合作，架构师不是需求分析师.....”

其实，除非特别简单的系统，否则架构师不能“吃透”需求，必然造成最终的系统无法很好的满足需求。但业界普遍存在的现实是：许多架构师的需求功底太差，输在架构设计的“起跑线”上。当然，架构师也是一大堆“苦衷”：

调侃归调侃（其实不无道理），但笔者一致认为：精通需求，是对架构师最基本的要求之一，不了解需求是现在许多架构师职业发展道路上的瓶颈。

值得强调的是，需求分析师和架构师这两个角色要掌握的需求知识并不完全一样。经典的观点是认为架构师应掌握的需求知识是需求分析师的一个子集，其实不然：

总之，架构师必须懂需求。虽然无须研究诸如需求捕获等技术，但需求类型、需求影响架构的原理、质量属性间的互相影响关系都是必须精通的。

小冯和小汪争得不可开交。小冯是项目经理，他说：“不要随意扩大需求的Scope，更不要搞需求镀金，因为这些不仅意味着成本增加，还可能造成工期延误。”“是的。可是......”小汪是架构师，他的话说了半截就被打断了。小冯抢着说：“所以，既然客户仅要求‘高可靠性’，我们就不能把它换成‘持续可用性’，更不应该随意扩大需求的范围，把安全性、可管理都加上。别忘了，成本超了、工期误了，可都是我这个项目经理扛着。”“像这种直接影响企业正常运营的系统，而不仅仅是‘可靠性’。”空气中已经有点火药味了，但小汪哪里肯退让，手指着培训教材上的一页继续坚持，“再请问，分布式的系统如果安全性差，可靠性怎么可能保证呢？！”

“《ISO 9216》的一级质量属性里就没有‘持续可用性’，而是‘可靠性’。” 小冯说。“国际标准就不会错吗？”小汪豪气冲天。“敢说ISO 9126不对，真牛......”

科幻故事总是轻松的，现实中的故事却或多或少让人感到压力。作为架构师，你是否认为：架构师重视需求 = 熟悉领域知识和业务？对，但不全面 -- 因为还要研究质量属性需求。那么，你是否又认为：懂质量需求 = 了解《ISO 9126》呢？

我们的观点：重视标准，但在一定程度上必然要对之进行调整、扩充以适应实践要求 。例如《ISO 9126》将质量属性描述成“树”，但实际上应该是“网”，安全性影响可靠性就是一例。

拿破仑说，“一只狮子率领一群绵羊的队伍，可以打败一只绵羊带领一群狮子的部队”。听到这话，许多软件企业可能觉得很高兴--因为不少公司都大量存在“一只狮子领导一群绵羊”这样的团队。

但是有这样的一个故事，就发生在“狮子带领一群绵羊”这样的团队。

但真的只是团队的水平不高吗？

为什么说，卢总的分析只对了一半呢？因为卢总要求的“灵活性”这个目标过于笼统，既然年轻的架构师水平偏弱，不能讲架构灵活的要求“落地”也就不奇怪了。

那么交流质量要求，如何做到“说的清楚、听得明白”呢？使用“场景化”描述。

例如，通过分析将“灵活性”更明确的诠释为“客户端既可以采用.NET实现 又可以用Java实现”等一系列具体场景，对“狮子领导的绵羊团队”有效开展架构设计工作是大有裨益的。

3个故事讲完了，呈现在我们面前的是层层递进的3个要求：

接下来，我们将着重介绍“场景”技术，以及“目标-场景-决策”表这种务实有效的、以满足非功能需求为目标的设计思维方法。