一些类型的需求依赖于基础架构，就像错误！未找到引用源。错误！未找到引用源。中“错误！未找到引用源。“中讨论的。需求模式使我们有机会确定一种类型的需求所依赖的基础架构，而不必为某一个需求考虑。而且我们可以进一步讨论每一个基础架构——也就是当为系统需要的基础架构定义需求时必须记住的。但是它不可能非常详细，也不可能针对实际的需求，因为每个组织，每个系统的不同要求，会使需求差别极大。为了清楚起见，它们被称作基础架构概述。
不能指望让每一个需求模式描述它需要的任何基础架构，这个解释的责任被给予了模式所属的领域。这是因为每个基础架构一般都会被领域中的多个模式使用。为了避免重复，每种基础架构只在一个领域中描述。本书中的每一章的模式中包含一节关于该领域的基础架构。本书讨论了三个基础架构：信息存储（错误！未找到引用源。错误！未找到引用源。），用户界面，以及报表（都在错误！未找到引用源。错误！未找到引用源。）。这几个关键概念的相互关系如图所示。
Domain: 领域
Infrastructure: 基础架构
Requirement Pattern: 需求模式
Depends Upon: 依赖
图 3?2领域，需求模式，以及基础架构之间的关系
需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖，所以如果一个领域依赖另一个领域，那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。
基础架构概述应该说些什么呢？它的角色是指导和建议如何定义一个特定系统的基础架构的需求，提出需求需要覆盖的主题。最少，它应该陈述系统需要基础架构提供什么：它存在的目的是什么，它的主要功能。有些问题有很明显的替代解决方案，概述应该避免做判断。
每个基础架构概述分成下列小节：
1. 目的解释基础架构存在的理由，以及扮演的角色。 调用需求关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力（比如访问控制）。需要的功能可以被看作是基础架构提供给调用者的接口。 实现需求为了使基础架构站得住脚所需要的一些特性的想法（例如，查询，维护和配置功能）。这些是比较简短的，只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。
例如，对于报表基础架构，调用需求可能是很简单：只是让系统请求运行一个选定的报表的功能。而另一方面，实现需求则相当多，包括交付报告给用户的各种方式的复杂性，其他请求报告的方式，设计报告，等等。（这些主题在错误！未找到引用源。错误！未找到引用源。进一步讨论。）以建造房屋类推，我们需要的基础架构之一是电力供应。这种情况下，调用需求是每个屋子需要多少插座，实现需求处理的是看不见的部分，像是与电网的连线，遵守建筑质量法。