域

业务处理

逻辑

物理

这些层次的数量和范围是定义完善的：我们有四个不同的层次：公司黑盒子、系统黑盒子、系统内的逻辑设计以及物理实现。

每个层次内的多个视图：在这个简单示例中，我们在每个层次上展示了一个动态视图和静态视图。

必须保持层次间的一致性：如果对域模型作出了更改，则更改也一定会影响到较低层次。举例来说，如果零售商决定为其产品提供维护合同，分析师就会将MaintenanceContract 添加到域模型，并将其改进为其物理表现形式。对于维护大型系统来说，同步所有层次是很重要的。因为提交了增强请求，所以分析师执行对相应细节层次的影响评估。一些增强请求影响域层次（并且因此影响所有后续层次）。其他请求只影响物理层次。

域。域层次捕获项目的业务环境。

项目洞察力。项目洞察力对系统将会有的对企业的业务影响进行通讯。它以投资回报分析量化了这个影响。项目洞察力表示该项目的最高抽象层次。

业务处理。系统层次为公司内的业务处理建模。对于极其复杂的单位来说，这个层次可以再细分到子层次：部门、部门间以及部门内。

UI 规范。UI 规范设计了实现业务处理的用户界面。它是由 UI 设计文档和功能 UI 原型组成的。

详细要求。详细要求指定了系统要求的最低层次抽象。它包括诸如数据类型格式和详细业务规则等详细信息。它还包括专业性要求，例如，性能、可用性、安全性、国际化、配置、可扩展性和灵活性要求等。

体系结构。系统的体系结构被组织到六个视图中：

它将系统要求分离到三个不同的抽象层次：业务处理、UI 规范和详细要求。我们不会再用令企业用户感到不知所措的单个整体功能规范了。取而代之，我们在三个改进的详细层次中对系统要求进行通讯。

分析师和架构师可以将复杂性控制在一个单一的、集成的系统模型中。

架构师可以专注于系统的单个方面，并将那些决策集成到整个解决方案中。

抽象层次形成了系统产品的结构。举例来说，软件体系结构文档为每个视图专设了一个小节。

抽象层次提供从要求到设计再到实现的直接可跟踪能力。可跟踪能力使小组能够在评测更改请求时执行精确的影响评估。

在使用同一框架开发几个系统之后，会在每个抽象层次形成模式。单位可以编录这些模式和每个抽象层次内的其他最佳实践。这个最佳实践的目录会作为过程改进计划的基础。

正式标识层次，每个层次都有定义完善的范围。

将一个层次内的复杂性分开到多个视图。

在层次间保持一致性。

您当前的项目是否应用了抽象层次？

层次是否定义完善？

项目团队是否很好地理解了这些层次？

如果复杂性在一个层次中变得过大，团队是否将其分离到视图中呢？

团队是否在层次间保持一致性？

您的项目会从抽象层次中获益吗？