此模板描述了如何从多个角度来组织设计以使其易于理解。同时，它也提供了如何使用模式以及小的、可重要的交互来最小化冗余的建议。

重要的是不要认为设计就是“文档”。设计信息是值得保留一段时间的信息，必须有一个长期存在的形式。这些形式可能是某个可视化建模工具的存储、或者通过数码相机将白板上绘制的图形拍摄整理保存的文件目录，或者是实际的文档。

设计经常被组织成需求的实现。一个需求的实现是设计的一个部分，它展示了一个或多个需求是如何被实现的。

此模板描述了那些应该被传达的信息。通常，最好在某个抽象层次上通过图形来表达这些信息（无论是用UML还是其它确定的符号），或者至少使用文字。可以通过代码示例来增强这些信息，但是最好不要只在代码级别上表述设计。

下面是此模板建议的设计结构。

设计结构

[在最高的层次上描述设计。通常通过显示了分层架构的图形来描述。]

子系统

[子系统1]

[描述系统的一部分（某个包或者组件）。设计应该描述了静态和动态的视角。

当描述动态的行为是，寻找可重用的块或行为，以便可以通过引用来简化需求实现的设计。

可以将此章节拆分成多个子章节，来描述更低一层的内部子系统。]

模式

[模式1]

概述

[以某种一致方式用文字概要描述模式。模式概述可以包括目的、动机和适用性。]

结构

[从静态的视角描述模式。包括所有的参与者以及它们之间的关系，调用的数据和行为。]

行为

[从动态的视角描述模式。参与者如何协作以支持不同的场景。]

[通常，你可以通过某个具体的示例来更好的传达模式的本质。]

需求实现

[实现1]

参与者视图

[从静态的视角描述参与的设计元素，给出该实现相关的行为、关联关系、属性的细节。]

基础场景

[基本事件流，描述设计元素的实例如何协作以实现需求。如果使用UML，这可能是协作图（序列或通信图）。]

额外场景

[对于其它需要描述传达关于需求行为如何实现更多信息的场景，描述设计元素实例如何协作以实现需求。如果使用UML，这可能是协作图（序列或通信图）。]