在我们当中，有不少人一厢情愿的任务：只要所开发的系统完成了用户期待的功能，项目就算成功了，但这不并不符合实际，忽视包括质量属性需求在内的非功能需求是很要命的。

为什么不少软件产品推出不久就要重新设计（美其名曰“架构重构”）？往往不是因为系统“不能用”，而是由于系统架构“太拙劣”--从难以维护、运行速度太慢 、稳定性差，甚至宕机频繁，到无法进行功能扩展、易遭受安全攻击等，不一而足。由此看来，软件的质量属性需求是不容忽视的，否则在大量的成本投入之后，很可能落得“失败”或“赔钱”的结果。

然而，软件的质量属性需求很“飘”，常常令架构师难以把握。如果缺乏足够的方法指导，即使勉强制定了设计决策也会觉得缺乏信心。

所以，解决问题的要害在于：如何使很“飘”的非功能目标“明确定义下来”。分析如下：

它就是场景技术 。

一句话，非功能目标的设计是以场景技术为核心手段、以目标-场景-决策表为思维工具，致力于支撑非功能目标的理性设计过程。

作为架构师，有了非功能目标设计环节相关方法的指导，将获得如下几点优势：

软件行业发展到今天，依然比较年轻。一个有趣的印证就是我们经常拿自己的行业和其他行业类比 -- 今天类比建筑行业，明天类比汽车行业，后台类比拍电影。

我并不能确定把架构师和哪个职业相类比最适合，但或许，架构师最嫉妒的职业是拳击。人家的目标永远正确：打到对方。而架构师，却要面对纠结在一起的“需求”--需求不是一个攻击目标，而是一堆攻击目标，而是一堆可能不够明确、相互矛盾的目标。昨天、今天、甚至明天，都会有相同的故事在上演：笼统界定的“非功能目标”让软件工程师深感困惑...... 这就是现状。

在这种状态之下，架构师不应“坐等”明确的需求，而是应该运用目标-场景-决策表等方法主动出击，设计成更有针对性的架构。

非功能需求支持是否到位，关键是靠场景思维的应用。归纳了场景思维在非功能目标设计中的重要性。

有著名厂商任务，架构设计的“第几步”应该是非功能考虑，这种观点是危险的。

非功能需求不可能是“速决战”，它必然是“持久战”，连编码都会影响到性能动能非功能属性，更何况概念架构设计和细化架构设计呢？所以架构师必须注意，非功能目标的考虑是纵穿架构师设计始终的环节。