查看 [技术-规格] 以理解设计任务的范围和对 设计 的期望。同利益相关人和分析人员一起，澄清那些模糊或遗失的信息。

如果需求未被表达成简短的场景形式（如非功能需求可能没有指定相关的场景），那么将需要仔细的考虑并适当的练习识别其场景。

如果需求不完整或不正确，那么需要和分析人员一起完善需求，可能需要提交相应的需求变更申请。

识别那些提供要求的行为而一起协作的元素。这可以从《架构备忘录》中识别的关键抽象，对需求进行设计、领域和对象分析开始，识别其中的设计元素。“Entity-Control-Boundary Pattern”为识别这些元素提供了一个好的开始。也可以参考指南：Analyze the Design。

检查已存在的设计元素，看看它们是否应该参与某个协作。试图在每次执行此任务的过程中创建所有的新元素，是一个错误。

通过贯穿场景为参与的元素分配职责，并确定在协作中这些元素的关联关系。

这些职责可能是对分配给这些元素的行为的简单描述，并不需要明确具体的操作规约和参数。类似的，可以此步骤中定义关联关系。此步骤是为了确保质量模型是被创建出来，并且足够健壮以支持那些需求。参见指南：Analyze the Design.

参考架构和之前的设计工作，创建一个一致的协作。和架构师一起，理解架构细节和动机。参考可重用的已存在行为和关系，或应用类似的结构，以简化整个系统的设计。更多信息，参见指南：Software Reuse。

在适当的层次上完善设计细节以驱动实现，并确保它符合架构。在此步骤中，可以考虑实际的实现语言和其它技术决策。当在较低的抽象层次上考虑这些细节时，如果必要，重新审视实现场景所识别的元素和它们之间的协作。同测试人员和架构师讨论可测试性问题，如设计元素是否难于被测试或有关键的性能问题。

在更大的上下文范围中，检查近期的变化，演进设计。并决定是否需要重构和重设计来改善健壮性、灵活性以及设计的可理解性。参见指南：Evolve the Design，获取有关特定的设计决策，以及在需要时的设计改进指南。

从架构中，合入架构机制。在其它部分的设计中，应用元素的一致结构、组织其行为，并使用在架构中识别的模式。

对大的、复杂的元素或某些复杂的元素，进行更多的细节设计。

这可能涉及到设计产生这些期望行为所需要执行的算法。为支持这些元素的期望，加入额外的操作、属性以及关系。

设计元素其生命周期中的状态，从而保证其在不同的环境中做出正确的行为。对于那些有复杂状态的元素，可能需要通过描述状态机来提供帮助。

和那些需要理解系统设计的人员进行沟通。虽然是在此任务将结束时描述此步骤，但沟通应该在整个任务中进行。协作的工作总是比在完成工作时进行评审要更好。

存在以下一些方式来沟通设计：

• 使用UML定义的正式模型
• 描述了静态结构和动态行为的非正式图形
• 为静态结构添加代码注释。这可以通过补充对跨代码模块的协作行为进行文本描述来进行。
• 描述了数据库样式的数据模型

以下是谁需要理解系统设计的示例：

• 基于设计实现解决方案的开发人员
• 评审设计以保证其符合架构或检查设计寻找改进架构机会的架构师
• 检查设计是否可以用于系统其它部分的其他设计人员
• 依赖于此步骤中的元素进行系统其它部分工作的开发人员或设计人员
• 评审设计是否符合质量要求和遵守规范的其他评审人员

Review《架构备忘录》以识别架构的变更和新增内容。参见指南：Evolve the Design 获得更多信息。如果不确定对架构相关部分的理解或设计策略的一致性，则向架构师询问。

如果在前一次的迭代中，架构没有任何变化，可跳过此步骤。

评估对象设计的耦合、内聚以及其它的质量设计度量。

从不同角度考虑设计，以保证其高质量、可沟通性。和其他技术团队成员进行此步骤，一个独立的团队可以提供新的视角。通过测试人员和架构师，提供设计质量和符合架构的视角。但是，当识别潜在的评审人员时记住，如果某人能通过评审提供价值，那么他们可以通过积极参与设计本身来提供更多的价值。如果识别了设计缺陷，修正它们改善设计。

更多信息，参见概念：Design、指南：Analyze the Design、指南：Evolve the Design。