和团队一起描述剩余的架构目标，并识别哪些适合在当前迭代中处理。看看需求并询问其他人员确信他们理解了此次迭代的关键目标。这些目标将优先考虑，并且指导重要的技术决策的方法。

这很重要，在整个项目中定期Review这些目标的进展，以确保它们仍然有效且系统朝着交付它们良好的发展。

更多信息，参见概念：架构目标。

识别那些关键性的架构需求。浏览并完善那些在当前迭代中为了实现架构目标而必须实现的需求。参见概念：架构关键需求。

列出所有的架构约束以及对竞争性需求和资源之间的权衡。决定架构将如何满足这些问题。判断所做的每个决策捕获了此信息。定期Review约束列表以确保它们仍然有效，并没有新的约束出现。

更多信息，参见概念：架构约束。

识别系统需要处理的关键概念和抽象。需求是关键抽象的一个好的来源。在初始阶段，不要花费太多的时间来描述抽象的细节，因为存在风险，花费太多时间将导致识别了解决方案实际不需要的类和关联关系。

当识别关键抽象时，定义它们之间存在的任何易见的关联关系，可能会是有用的。这些关联关系可以通过表格或图形来表述（在工具或白板中）。通常，在设计的早期，不值得为了定义高度精细的关联关系而折腾。这些关联关系将在后续逐渐具体和细化，并且可能会修改这些早期的假设。

更多信息，参见概念：Key Abstractions。

调查、评估并选择可用资产。识别其它领域中可以在当前架构里重用的资源。更多信息，参见指南：Software Reuse。

决定如何划分软件，从逻辑和物理两个方面。划分系统有助于通过“分而治之”策略管理复杂性。通过将过程划分为更小且能够管理的片段，可以更容易的进行开发。

作为最低限度，至少决定：

• 在管理开发时如何划分软件（例如，使用分层策略）。更多信息参见指南：Layering。
• 在运行时，软件如何组成。

对每个软件划分，简要描述：

• 名称和目的
• 与其他划分的关联关系

在此处，不需要识别每个分区中的元素。相反，应该明确需要多少个分区，以及它们如何关联。在后续，通过设计活动，决定哪些元素将填充这些分区。

概述软件将如何部署到网络中的节点。和利益相关人，如网络支持与部署团队，共同工作，以保证该方法能够良好的适应广泛的技术环境。

整理一份列表，列出系统需要提供的技术服务，并在列表中描述每一项服务的基础信息。为项目整理一份需要的初始的所有机制列表，然后重点开发那些为实现架构目标所需交付的机制，这通常是个好主意。

在此处，通常只定义分析机制。然而，特定的架构约束可能意味着某些机制将作为设计机制进行描述（即使是在早期阶段）。

有关架构机制的进一步信息，参见概念：架构机制。

在这里，识别那些系统必须进行交互的外部系统。外部系统可能是当前系统将使用的软件或硬件设备，例如打印机、终端、报警设备以及传感器。

在高层描述这些接口，专注于那些必须在系统中传递的信息。

团队共同验证架构与需求的一致性，以及架构描述是完整、有意义且清晰的。

在 架构备忘录 中，捕获架构相关的重要决策，以备查。确保团队理解架构，并且能偶交付它。