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