关键需求决定架构，其余需求验证架构

如果非要在[[用例驱动论的局限]]、[[质量决定论的局限]]、经验决定论三种流行观点之间三选一回答”什么决定了架构”，会陷入”都有理但都不全”的两难——真正的答案跳出了这个三选一框架：关键需求决定架构。这个立场成立有两重依据。一是现实依据：软件架构师没有时间对”所有需求”进行深入分析——大多数项目都面临工期压力，架构师必须在有限时间内定夺架构方案，否则团队后期开发会因为缺少足够的技术指导和分工限制而面临巨大风险。二是策略依据：软件架构师也没有必要对”所有需求”进行深入分析——把大部分时间和精力集中花在真正决定架构的那部分需求上，反而能让最终设计出的架构质量更高；如果试图对所有需求都做深入分析，结果往往是处处浅尝辄止，最终架构设计流于形式。这里的”关键需求”横跨功能需求、质量属性、约束三类需求，而不偏向任何一类——这正是关键需求决定论相对用例驱动论、质量决定论的根本优势：如果只考虑功能需求设计概念架构，概念架构会沦为”理想化架构”，这种脆弱架构很快会面临”大改”压力，甚至直接导致投标等工作失败。至于那些没有被划入”关键”范畴的其余需求，并非被彻底忽略，而是被用来验证架构——比如以架构方案评审的方式，从每一项非关键需求的角度对已经确定的架构方案进行走查，确认架构没有遗漏对这些需求的支撑能力。