当我们阅读一个新的章节了解新的知识时，首先要了解这一节究竟在讲述什么，这是第一个问题：
什么是Pre-architecture？
通过通读这一章节在我看来Pre-architecture就是架构设计的最前期阶段，其工作目标包括：理解需求、建立需求大局观、确定架构设计方向等。他对从事一线架构师工作的人员有着相当重要的地位，我们可以参照这本书的规则来确定如何出色的完成软件架构师的工作，相信在阅读了这一章节能对现在并不是一线架构师的我，理解软件架构师的工作准则。
如果我们现在正在从事软件架构师相关的工作，从一线架构师实现指南可以理解到，如果学习了这本书的这一章节，我们可以获得需求理解的大局观，并且可以获得有效处理互相矛盾的需求目标，在实践中也可以识别重大需求、特色需求、高风险需求；如果熟练掌握了这一章节内容，我们就可以在很短时间内完成软件架构的设计等等。
这一章节所讲述的内容可以大大降低架构失败风险；在架构师在需求的理解、权衡、取舍和补充这些方面能力严重不足的情况之下可以尽早开始架构设计，Pre-architecture阶段的好处就是能够在需求没有“全面完成”的情况下开始架构设计。为了尽早开始架构设计，需要做好：让架构师参与需求分析工作；不能被动地等待完善的《软件需求规则说明书》。
在架构师工作中只要满足下面3个条件就可以开始架构设计工作：
1.有了明确的业务需求：必须保证甲、乙双方就建设系统的目标达成共识，《愿景文档》经过正式评审，并且明确了投资、工期标准、整合等约束条件；
2.了解全面的用户需求：系统能帮助用户干什么、不能干什么已经非常明确。如果采用用例技术，表现为“用例图”比较完善，没明显遗漏；
3.有了典型的行为需求；如果采用用例技术，表现为核心功能的《用例约束》已经定义；
通过阅读这本书的这一章节我明白了明确架构设计的“驱动力”——在关注《软件需求规格说明书》之外，必须关注其他很多因素，最终理性地确定真正的架构设计“驱动力”。
这一章不仅讲到了Pre-architecture的理论方面，也讲了许多关于实践的要领：不同需求影响架构的不同原理，才是架构设计思维的基础，“需求决定架构”是对的，但不同需求影响架构的不同原理，才是架构设计思维的基础。
需求结构化
需求结构化可以将复杂的需求集合梳理得井井有条，为进一步分析不同需求之间的联系、识别遗漏的重要需求打下坚实的基础。
之前当提到软件架构师这个工作时，我经常会有一个疑问，需求结构化要怎么做？通过这一章节我找到了一些答案：
1.超越《软件需求规则说明书》
需求文档往往不够全面；需求经常变更，仅依赖需求文档往往使架构设计工作非常被动；架构师通过需求结构化真正全面地“鸟瞰”需求大局，就必须超越《软件需求规则说明书》；能够摆脱对《软件需求规则说明书》提交时间、文档质量、内容变更的“呆板依赖”；
想要确定关键质量，就要确定关键质量目标意义，指定错误的质量属性目标（包括遗漏重要的质量属性），将面临客户不满、项目返工、同事抱怨……
确定关键质量主要完成。
1.根据系统所在领域的特点及系统规模等因素，确定架构设计重点支持哪些质量属性（例如高性能、可扩展性…）
2.分析上述质量属性之间的制约关系，第一时间指定权衡折衷的具体策略（例如明确高性能是第一位，可扩展性和高性能相矛盾时应照顾高性能要求，是否引入支持可扩展性的涉及需经过架构组评审）
在阅读本章之后，我不仅了解了软件架构师的工作方法及准则，我还知道了确定关键质量的5大原则：分类合适+必要扩充、考虑多方涉众、检查性思维、识别矛盾+划定优先级、严格程度符合领域和规模特点，这一章节对于我以后可能会从事的软件架构师有着非常重要的作用，受益匪浅！