架构不仅仅是系统功能需求的结果 -- Len Bass, 《软件架构实践(第二版)》
在我们当中，有不少人一厢情愿的认为：只要所开发出的系统完成了用户期待的功能，项目就算成功了，但这并不符合实际。 -- 温昱,《软件架构设计》
《软件架构设计》一书中指出，“其实任何作为复合整体的复杂事物都有可能有架构，比如一本书”。“非功能目标的考虑”在ADMEMS方法中不是一个阶段，而是一个贯穿环节。
我们接下来讨论的重点是贯穿案例 -- PASS系统概念架构设计的第3步，考虑非功能需求。
10.1. 考虑非功能目标要趁早
概念架构 ≠ 理想化架构
- 重大需求塑造概念架构。这里的 “重大需求”应涵盖功能需求、质量及约束3类需求中的关键部分 。
- 概念架构是一个“架构设计阶段”，必须在细化架构设计阶段之前，针对重大需求、特色需求、高风险需求，形成稳定的高层架构设计成果 。
- 如果只考虑“功能需求”来设计概念架构，将导致概念架构沦为“理想化架构” ，这个脆弱的架构不久就会面临“大改”的压力，甚至直接导致投标等工作失败。
10.2. 贯穿案例
非功能需求往往非常笼统，而场景是一种明确性很强的技术。目标-场景-决策表 可以让架构师理性应对非功能需求。
通过场景，我们质疑ile可重用性的做法。为了避免开发多个孤立的“医生工作站嵌入单元”，引入的设计决策是 “分离出不变部分” ，将“PASS系统医生模块通用SDK”提炼出来（见 9.4.4. 引入通 ）
不要忘记了架构设计是质疑驱动的 --概念加过也经常经过多次循环的设计结果(如 7.4. 实践要领 提到概念架构实践要领)。现在我们来质疑PASS系统的持续可用性，它毕竟是用于辅助医院运营的系统。
根据上述基于目标-场景-决策表的思考，我们调整系统的原有架构图，经验告诉我们，考虑非功能需求会引起“架构中间设计成功”的调整！
下一节：如果一个项目的系统架构（包括理论基础）尚未定义，就不应该进行此系统的全面开发。 -- Barry Boehm, 《Software Engineering》
如果选择视图的工作没做好，或者以牺牲气体视图为代价，只注重一个视图，就会掩盖问题以及延误解决问题。 -- Grady Booch, 《UML用户指南》
从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略；再进行细化架构的设计，以保证为开发提供足够的指导和限制...这符合人类解决问题的规律，因此被广泛采用。
但在实际中，细化架构设计还存在很多差强人意之处，甚至经常被忽视。