同团队一起，特别是利益相关人和需求团队，Review 架构目标 和 架构关键需求 的状态，并根据需要完善它们。这可能导致出现新的架构关键需求，或者架构的目标和优先级发生变化。

到当前为止所执行的开发工作也将影响那些已定义的决策和目标。使用那些在当前设计和实现系统时所获得的信息，调整并完善所做的决策和目标。

识别具体的设计元素（如Component、类和子系统），并为它们命名并给出简要的描述。

以下是一些设计元素的来源：

• 架构关键需求。突出那些参与架构实现的需求。
• Key Abstractions
• 封装外部系统接口的组件。更对信息，参见指南：Representing Interfaces to External Systems。
• 实现了 架构机制 的组件
• 架构性的和关键设计Pattern。应用所选模式来定义一组符合模式的新的元素。

识别组件有助于隐藏系统的复杂性，并帮助你在较高的层次上工作。组件需要具有高内聚，并通过一个受限的接口来提供对外的服务。在此时，接口不需要进行详细的描述，但需要描述它们需要的、可使用的、以及依赖的元素。

识别组件可基于架构的层次、部署选择、或者关键抽象。问问自己这些问题：

• 哪些是逻辑或功能上相关的（如相同的用例或服务）？
• 哪些实体为他人提供服务？
• 哪些实体彼此依赖？强或弱？
• 哪些实体能够独立的和其它实体进行交互？
• 哪些将运行在同一个进程或网络节点中？
• 哪些部分受到了类似的性能需求的约束？

当识别了某个组件时，必须简要的概述分配给该组件的的功能。

完善架构机制，以支持设计的需要。例如，将某个分析机制完善成相应的设计机制，和/或将设计机制完善成实现机制。

确保定义了开发和测试架构。注意这些环境中的任何架构关键差异，并和团队一起制定策略来缓解可能出现的风险。

继续寻找更多的重用已有资产的机会。在合适的情况下，识别可以那些可以构建或使用的已存在的组件。

更多信息，参见指南：Software Reuse。

确认架构支持团队的需求和需要。

开发足够的可工作的软件以展示架构的可行性。这将为架构的适用性验证提供明确的基础。当迭代的开发软件时，可能需要不止一个增量构建来证明架构。在项目的早期阶段，提供不完整或原型感觉的软件是可以接受的，因为此时关注于建立架构基线，以为剩余的开发工作提供一个稳定的基础。

将架构关键设计元素映射到目标部署环境。同硬件和网络专家一起，确保硬件充分满足了系统需要，以及在需要时有新的硬件可用。

确保那些遵照架构工作的人们理解并能够依据架构进行工作。确保架构描述不仅仅清晰的描述了解决方案，还包括那些限制了架构的决策相关的动机和目的。这将使架构更容易被理解，并随时间进行调整。