知道了软件架构的关键，面对有一定复杂与难度、或有竞争性目标的庞大需要的软件系统，没有一个好的设计策略，完全依靠设计师的经验与能力，往往会让设计师顾此失彼，无法保证软件系统的成功。
上面讲到，软件架构工程师没有时间也没有必要对所有需求进行深入分析；而功能或用例确定了软件架构的大的方向、几个关键的非功能需求与约束决定了软件架构的风格。因此软件架构设计的第一条策略是：让关键需求决定架构。关键需求决定架构有两个方面的涵义：一方面，功能需求与非功能需求数量众多，应该控制架构设计时需要详细分析的用例个数；另一方面，不同非功能需求之间往往具有相互制约性，应该权衡非功能需求之间的关系，找到影响架构的重点非功能需求。关键需求决定架构的策略有利于集中精力深入分析最为重要的需求。当架构工程师把全部精力扑在相对较少的关键需求上时，可以更为深入的分析这些需求，有利于得到透彻的认识，从而设计出合理的架构。
如何从众多的软件需求中准确找到关键需求呢？这就需要使用思维的发散与收敛原则，全面认识需求，分析所有需求之间的因果关系、特别是与软件系统的目的目标及核心业务间的因果关系。而且，软件架构强调的是整体，而整体性的设计决策必须基于对需求的全面认识；软件架构应该是稳定的，而遗漏了重要的需求的架构设计最终会面临返工的结局。因此软件架构设计的第二条策略是：全面认识需求。有人会问：前面说软件架构工程师没有时间也没有必要对所有需求进行分析，现在又说要全面认识需求，这不是自相矛盾的吗？需要注意的是，全面认识需求不是全面分析需求。全面认识需求要求：1、将所有需求从不同的级别(组织级、用户级、开发级)分层梳理列表归纳总结，建立跟踪矩阵，既避免因遗漏需求而造成软件系统达不到要求，也避免开发人员一厢情愿也为用户制造没有实际意义的无用功能，同时，有助于软件架构设计人员对软件系统要求有全面的认识，清晰理清需求之间、需求与软件系统目的目标与核心业务、商业理由间的因果关系。2、将所有需求划分为不同的类型(功能需求或用例、质量属性、约束与限制)进行梳理列表归纳总结，建立影响分析表，找出不同需求类型之间的相互支持、相互制约关系的影响，并在深思熟虑之后作出合适的需求权衡和取舍。
软件架构的目的是沟通，但沟通的对象不同，对软件系统的关注点也就不同；同时人类研究事物也是从不同的角度立场、横看成岭侧成峰的观察、了解、认知的。因此软件架构的第三条策略是：多立场、多视角探寻架构。一次只从某一立场、某一视角出发围绕少数概念和技术展开，并分析对其它部分、其它立场视角分析结果的关系与影响。
软件架构的第四条策略是：尽早验证架构。架构设计是现代软件开发中最为关键的一环，架构设计是否合理将直接影响到软件系统最终是否成功。毕竟软件架构中包含了关于如何构建软件系统的一些最重要的设计决策，而这些决策能否使最终开发出来的软件系统满足预期要求，都是悬而未决的重大风险，因此必须尽早验证架构。架构验证不可能全盘进行，必须精挑细选能够触发主要设计决策参与执行的、或有较高技术风险的、或最影响用户满意度的一些功能。
|
关键 |
问题 |
危害 |
策略 |
要点 |
|
是否遗漏了至关重要的非功能需求 |
对需求的理解不系统、不全面，对非功能需求不够重视 |
造成返工，项目失败 |
全面认识需求 |
从不同级别、不同类别梳理列表归纳总结，建立跟踪矩阵与影响分析表 |
|
能否驯服数量巨大且频繁变化的需求 |
对于时间和质量的矛盾，办法不足，处理草率 |
耗时不少，质量不高 |
关键需求决定架构 |
控制架构设计时需要详细分析的用例个数，权衡非功能需求之间的关系，找到影响架构的重点非功能需求 |
|
能否从容也设计软件架构的不同方面 |
架构设计方案覆盖范围严重不足，许多关键决定被延迟由实现人员仓促决定 |
开发混乱，质量不高 |
多立场、多视角探寻架构 |
一次只从某一立场、某一视角出发围绕少数概念和技术展开，并分析对其它部分、其它立场视角分析结果的关系与影响 |
|
是否及早验证架构方案并作出调整 |
假设架构方案是可行的，直到后期才发现问题，造成大规模返工 |
造成返工，项目失败 |
尽早验证架构 |
必须精挑细选能够触发主要设计决策参与执行的、或有较高技术风险的、或最影响用户满意度的一些功能进行验证 |
