Refined Architecture这一阶段是相对于Conceptual Architecture而言的，它们是架构设计的两个层次，分别对应于“概念级”解决方案和“规约级”解决方案。
细化架构属于架构设计，不能与详细设计相混淆。并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，
也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。
这种情况下，不管是用DevCloud的Scrum项目模板还是看板项目模板，都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联，
而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，
因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。在此基础上这一架构涵盖了五种视图：
1、用例图-定义用户的需求和系统的功能，为整个技术架构的上线文环境
用例图通常是软件开发的起始点，完善的用例图可以展示出系统的全部功能。
2. 逻辑视图-用类的方式实现用例视图的内部逻辑结构
逻辑视图重点描述行为，属于需求分析阶段与开发人员沟通的建模
3. 开发视图-关注程序包，源程序的目录
4. 处理视图-处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题
5.物理视图-关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求
另外，架构师在参与需求分析工作时，不断运用ADMEMS矩阵等工具对需求进行大局的梳理，只要满足以下3个条件，就可以今早开始架构设计工作
1、有了明确的业务需求。必须保证甲、乙双方就建设系统目标达成了共识。
2、了解全面的用户需求。系统能帮助用户干什么、不能干什么，这个“需求的Scope”已经非常明确，如果采用用例技术，则表现为“用例图”比九完善，没有可以一楼的地方。
3，有了典型的行为需求，意味着，大量行为需求还没有明确定义，离提交《软件需求规格说明书》还很早，如果采用用例技术，表现为核心功能的《用例条约》已经定义。
面对需求的四步法：
需求结构化：
并不是说任何情况下都需要进行软件项目需求的结构化管理。如果只是事务性质的管理需求，也就是有需求了能记录、能跟踪状态、实现之后不需要继续跟踪、也不需要维护需求与需求之间的关联，那么不需要思考需求结构化管理这个问题。这种情况下，不管是用DevCloud的Scrum项目模板还是看板项目模板，都可以管理好需求和软件项目。只有在需求较多、且需求之间存在关联，而且即便是已经实现的需求也需要进行一定的管理、维护的情况下，我们才需要去思考需求结构化管理的问题，此时，我们需要使用DevCloud提供的Scrum项目模板，因为里面有Epic-Feature-Story的需求结构，以及需求规划功能可以辅助我们进行需求的结构化管理。
分析约束影响
对于架构设计而言，来自方方面面的约束性需求中潜藏了大量风险因素。所以，有经验的架构师都懂得主动分析约束影响，识别架构影响因素，以便在架构设计中引入相应决策予以应对。
同样，Pre-architecture阶段明确要求必须分析约束影响。背鳍下面是不是一条鲨鱼？约束性需求中，是不是潜藏了风险因素？如图4-3所示的隐喻，点明了分析约束影响的要义：尽早识别风险
确定关键质量
用户不仅关注功能，同时也需要质量，用户关注的质量可能包括易用性、性能、持续可用性、鲁棒性等，客户不一定是最终用户，比如超市销售系统的客户是超市老板，但最终用户可能是收银员或上货员，他们所关注的质量属性可能不一致。
确定关键功能
确定关键功能的4条原则：核心功能，必做功能，高风险功能，独特功能（覆盖上述未覆盖的职责）。“关键功能子集”的确定不存在“标准答案”，“关键功能所占比例”应灵活确定。