关键性的第一步是缩小范围……

—— 杰拉尔德·温伯格，《你的灯亮着吗》

很少有开发者能奢侈地拥有一个稳定的需求集，或者能够构建一个满足所有已知需求的系统。

—— Dean Leffingwell，《软件需求管理：统一方法》

功能、质量和商业需求的某个集合“塑造”了构架。我们把这些塑造需求称为“构架驱动因素”。……知道了构架驱动因素后，就可以开始构架设计了。

—— Len Bass，《软件构架实践（第2版）》

关键需求决定架构。简直是醍醐灌顶！

软件架构师没有时间对“所有需求”进行深入分析，这是现实——大多数项目都面临项目工期的压力，软件架构师必须在一定的时间内定夺架构设计方案；否则，没有软件架构所提供的对技术的足够指导以及对分工协作的足够限制，后期的团队开发将面临巨大风险。

软件架构师没有必要对“所有需求”进行深入分析，这是策略——把大部分时间和精力花在对决定架构最重要的一部分需求上，好钢用在刀刃上，最终你设计出的软件架构的质量反而会更高；否则，所有需求的分析都不够深入，导致最终设计出的软件架构可能会流于形式。

解释一下这两个隐喻。所谓“穷兵黩武”是指把所有需求彻底分析一遍从而设计出软件架构的做法，而“择战而斗”是指为了设计架构仅重点分析对软件架构起关键作用的一部分需求的做法。

读书犹如和作者交谈。本节的写作形式颇为轻松：我们假设把一些高人请到了一起，就“从软件需求到软件架构”问题展开一个“高峰论坛”（当然是虚拟的）。

13.1.1  需求是任何促成设计决策的因素

说到底，一个软件系统的软件架构最终设计成什么样，是由软件需求决定的。

咨询专家Brian Lawrence提出：“需求是任何促成设计决策的因素（Anything that drives design choices）。”

13.1.2  很少有开发者能奢侈地拥有一个稳定的需求集

“需求决定架构”。话虽这么说，但现实要复杂得多，因为软件需求本身会因需求背景的变化和项目人员的理解等问题发生变更。

正如《软件需求管理：统一方法》的作者Dean Leffingwell所说：“很少有开发者能奢侈地拥有一个稳定的需求集……”

13.1.3  关键性的第一步是缩小范围

勿在浮沙筑高台。倘若作为架构设计重要依据的软件需求变化了，你建起的软件架构这个“高台”岂不是要倒塌？

杰拉尔德·温伯格的话让人更深刻地体会到了“运筹帷幄”应有的含义，他说：“关键性的第一步是缩小范围……”

13.1.4  要择战而斗

穷兵黩武还是择战而斗，这或许不是问题，因为我们已经倾向于择战而斗了。但问题在于，择战而斗怎么个“择”法。

PeopleSoft公司的首席技术官Rick Bergquist说得精辟：“我的第一个老板John Grillos曾说过，要择战而斗。择战的标准如下：它们要具有重要性，它们要具有可能性，它们的数量要少。”

13.1.5  功能、质量和商业需求的某个集合塑造了构架

方向已经明确了，不是吗？软件架构师要着重深入分析的是软件需求的一个子集，再结合自己的经验，最终设计出软件架构。

卡内基梅隆大学软件工程研究所的Len Bass指出：“功能、质量和商业需求的某个集合‘塑造’了构架。我们把这些塑造需求称为‘构架驱动因素’。……知道了构架驱动因素后，就可以开始构架设计了。”