需要有架构和分层意识
Pre-architecture 阶段：ADMEMS 矩阵方法 PA 阶段的使命，可以概况为一句话：全面理解需求，从而把握需求特点，进而确定架构设计驱动力。 其中，ADMEMS 矩阵居于方法的核心。
Pre-architecture 阶段：ADMEMS 矩阵方法 PA 阶段的使命，可以概况为一句话：全面理解需求，从而把握需求特点，进而确定架构设计驱动力。 其中，ADMEMS 矩阵居于方法的核心。
Refined Architecture 阶段:落地的 5 视图方法 细化架构是相对于概念架构而言的。
需要有几个架构视角
- 数据架构
- 逻辑架构
- 运行架构
了解约束条件
小周被任命为这个项目的架构师。需求分析阶段，小周也参与了。几天之后，小周就开始“轻敌”了，他在一次项目会上说了这么一句话：“这个项目不就是一个 MIS 吗!”
接下来的工作比较顺利，项目组也算情绪高昂…
项目组的情绪急转直下，出现在项目接近尾声的一天，客户方的小崔，看着漂亮的“外籍人员信息录入”界面，弱弱的说了一句，“哦，外籍人员的信息，大部分都不是我们录入的，而是来自省局。”
这些问题大了，最棘手的问题是，项目定义的数据库 Schema 和省级系统的数据库 Schema 不一致。
若飙车不一致状态，就人为造成了数据格式的不兼容，这是典型的烟囱式应用的做法，为未来可能出现的更多整合要求埋下了障碍； 若参考省级系统的数据模型重新定义数据库 Schema，大量代码就必须重写，项目工期必然拖延。
Pre-architecture 阶段的 4 个步骤 Pre-architecture 阶段对整个架构设计工作非常重要，它担负着建立需求大局观、把握需求特点、确定架构设计驱动力的责任。
首先，将多而杂的架构影响因素梳理脉络、建立全面有序的理解。
然后，分别针对约束、质量、功能这 3 类需求开展相应工作。
分析约束影响，识别隐含需求 确定关键质量，明确关键质量之间的优先级 确定关键功能，便于更有针对性的分配有限的架构设计时间
需求层次分析和解释 业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求、以及要符合哪些标准、对哪些遗留系统进行整合等约束条件 用户级需求：用户使用系统来辅助完成哪些工作？对质量有什么要求？用户群及所处的使用环境有什么特殊要求? 开发级需求：开发人员需要实现什么？开发期间、维护期间有什么质量考虑？开发团队的哪些情况会反过来影响架构？
只有把握住涉众来源，才便于发现并归纳涵盖广泛的约束因素，也有利于针对性地进行交流，还可跟踪对约束的支持是否令涉众满意。
第一，来自客户或出资方的约束性需求 架构师必须充分考虑客户对上线时间的要求、预算限制，以及集成需要等非功能需求。 客户所处的业务领域是什么？有什么业务规划和业务限制。 是否需要关注相应的法律法规，专利限制？ … 第二，来做用户的约束性需求 软件将提供给何阶层用户？ 用户的年龄段？使用偏好？ 用户是否遍布多个国家？ 使用期间的环境有电磁干扰、车船移动等因素吗？ … 第三，来自开发者和升级维护人员的约束性需求 如果开发团队的技术水平有限（有些软件企业甚至希望通过招聘便宜的程序员来降低成本）、磨合程度不高、分布在不同的陈那个是，会又和影响？ 开发管理方面、源代码保密方面，是否需要涉及？ … 第四，也不能遗忘，业界当前技术环境本身也是约束性需求 技术平台、中间件、编程语言等的流行性认同度、优缺点等。 技术发展的趋势如何？ … 架构师应当直接或（通过需求分析员）间接的了解和掌握上述需求和约束，并深刻理解它们对架构的影响，只有这样才能设计出合适的软件架构。
在大型架构设计的早期比较注重识别重大需求、特色需求、高风险需求，据此来设计概念架构。
你的产品很好吗？不一定！只有满足客户需求的产品才是好的产品，所以做售前的决不能自我感觉良好。
胜利远远还没有”在望“，但端着茶杯楞一会儿神儿的老王已成竹在胸。
后天的重点不是在讲纯技术，而是抓住客户关系的价值和担心的问题，并在一个小时之内清晰的勾画出产品的相应策略。
概念架构一级的设计更重视”找对路子“，它往往是战略而不是战术，它必将策略化而未必全面，它必将强调重点机制而不一定非常完整。
Conceptual Architecture 阶段包含 3 个步骤：
第 1 步，初步设计。 第 2 步，高层分割。 第 3 步，考虑非功能需求。
18.2. “目标-场景-决策”表