Pre-architecture，直接翻译为【前架构】，是这本书的所描述的第一个部分，我自己对这写阶段的理解就是，一栋建筑物的形成过程，在正式架构之前，要了解这栋建筑的用途，居民楼？学生公寓？购物广场？政府大楼……，将情况了解清楚之后，才可以进行后续操作，要将这个头开好。将建筑替换成我们的软件，就是首先了解这个软件，这个系统各方各面的需求，将软件设计的开头部分做的扎实牢靠。
书中的这部分包括第2-5章，分别讲了Pre-architecture的故事、Pre-architecture总论、需求结构化与分析约束影响、确定关键质量和关键功能。
这一部分一开始就提到“没有风险的软件早就被开发完了，作为架构师，首先要面对的风险就是需求，既要关注功能需求，又要平衡相互矛盾的质量属性需求，还不能遗漏各方面的约束性需求……这，已成为合格架构师必需的基本功。”读到这几句话的时候我小小的震惊了一把，一个合格的架构师原来需要考虑这么多事情，成为一名软件架构师的路还有很长。
在第一故事外籍人员管理系统中，这个项目的架构师小周没有把需求询问清楚，造成了工作大半部分浪费，整个项目数据库的部分，需要推倒重开，项目组人员拼命加班。这就是身为架构师的小周轻敌的表现，没有考虑到系统的约束性需求。第二个故事嵌入式OS的裁剪，同样是没有考虑到约束性需求，这就能看出，约束性需求在架构时的重要性。这是，我就发觉，文章开头写的那两句名言的正确性了。
“所谓‘开始就是结局’，要达到什么样的解决取决于什么样的开始。结局就是开始的地方。”
“需求验证的目标是尽可能暴露问题，而不是证明无错。”
读到此处，我明白了前架构阶段的重要性，Pre-architecture就是架构设计的最前期阶段，其目标工作包括：理解需求、建立需求大局观、确定架构设计方向等。这里，指明，需要发现遗漏需求，确定关键功能，确定关键质量以及权衡质量属性之前的矛盾关系。那么这个阶段需要用的方法是什么呢，在往后面读的过程中，我发现，最重要关注的是三个需求方面，即业务需求、用户需求以及行为需求，因为不同的需求，对影响架构的原理不同。如下图：
将上述所说的内容柔和到一起，就形成了我们的二维需求观。
关键需求决定架构，其余需求验证架构，功能需求做减法。在所有功能中挑选一个“关键功能子集”，作为“架构设计驱动力”的第1部分。
质量属性需求做减法。根据系统所在领域的特点及系统规模等因素，确定架构设计重点支持哪些质量属性，作为“架构设计驱动力”的第2部分。
约束性需求做加法。充分考虑需求方及业务环境因素、用户群及使用环境因素、开发方及构建环境因素、业界当前技术环境因素等“4类约束”，将之作为“架构设计驱动力”的第3部分，并以“做加法”的思维分析约束影响、识别约束背后的衍生需求。
Pre-architecture阶段对整个架构设计工作非常重要，它担负着建立需求大局观、把握需求特点、确定架构设计驱动力的责任，并遵循4个步骤设计前架构这个阶段。如下图。
需求是有结构，并且分层次的，将过于零散的需求，从三个层次，三个角度出发将零散的需求缕清，绝对不能认为《软件需求规格说明书》就是需求的全部。绘制出ADMEMS矩阵（需求层次—需求方面矩阵），如下图：
需求层次-需求方面矩阵的存在有着很大的意义，业务级需求:包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。用户级需求:用户使用系统来辅助完成哪些工作?对质量有何要求?用户群及所处的使用环境方面有何特殊要求?开发级需求:开发人员需要实现什么?开发期间、维护期间有何质量考虑?开发团队的哪些情况会反过来影响架构?
可以看出，需求的三个层次，是站在“不同层次的涉众提出需求所站的立场不同”的角度，将需求划分为三种类型。其次，需求还必须从不同方面进行考虑。例如，一个网上书店系统的功能需求可能包括“浏览书目”、“下订单”、“跟踪订单状态”、“为书籍打分”等，质量属性需求包括“互操作性”和“安全性”等，而“必须运行于Linux平台之上”属于约束性需求之列。实践一再表明， 忽视质量属性和约束性需求，常常导致架构设计最终失败。于是，从“需求定义了直接目标还是间接限制”的角度，把需求划分为3种类型，这就是需求的3个方面:功能需求:更多体现各级直接目标要求。质量属性:运行期质量+开发期质量。.约束需求:业务环境因素+使用环境因素+构建环境因素+技术环境因素。