Pre-architecture就是架构设计的最前期阶段，工作目标：理解需求、建立需求大局观、确定架构设计方向。
Pre-architecture阶段能够帮助架构师建立需求理解的大局观，任何需求都可以定位于业务及需求、用户及需求、开发及需求这三个需求层次的某一层。同时也必须属于功能、质量、约束这三类需求的某一类，那么这个就是我们的脉络了。
Pre-architecture阶段的一个额外好处：能够再需求没有“全面完成”的情况下就开始架构设计。具体而言，为了尽早开始架构设计，软件企业最好做好以下两点：
让架构师参与需求分析工作
不能被动等待完善的《需求规格说明书》
架构师在参与需求分析工作时，不断运用ADMEMS矩阵等工具对需求进行大局的梳理，只要满足以下3个条件，就可以今早开始架构设计工作
1、有了明确的业务需求。必须保证甲、乙双方就建设系统目标达成了共识。
2、了解全面的用户需求。系统能帮助用户干什么、不能干什么，这个“需求的Scope”已经非常明确，如果采用用例技术，则表现为“用例图”比九完善，没有可以一楼的地方。
3，有了典型的行为需求，意味着，大量行为需求还没有明确定义，离提交《软件需求规格说明书》还很早，如果采用用例技术，表现为核心功能的《用例条约》已经定义。
面对需求的四步法：
需求结构化：
首先，并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用DevCloud的Scrum项目模板还是看板项目模板，都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。
分析约束影响
风险有个恼人的特点：一旦你忘了它，它就会找上门来制造麻烦。
对于架构设计而言，来自方方面面的约束性需求中潜藏了大量风险因素。所以，有经验的架构师都懂得主动分析约束影响，识别架构影响因素，以便在架构设计中引入相应决策予以应对。
同样，Pre-architecture阶段明确要求必须分析约束影响。背鳍下面是不是一条鲨鱼？约束性需求中，是不是潜藏了风险因素？如图4-3所示的隐喻，点明了分析约束影响的要义：尽早识别风险
确定关键质量
用户不仅关注功能，同时也需要质量，用户关注的质量可能包括易用性、性能、持续可用性、鲁棒性等，客户不一定是最终用户，比如超市销售系统的客户是超市老板，但最终用户可能是收银员或上货员，他们所关注的质量属性可能不一致。
确定关键功能
确定关键功能的4条原则：核心功能，必做功能，高风险功能，独特功能（覆盖上述未覆盖的职责）。“关键功能子集”的确定不存在“标准答案”，“关键功能所占比例”应灵活确定（大概占20%~30%