需求模式：定义一种特定类型需求的方法。需求模式应用于单个需求，一次帮助定义一个单一需求。使用需求模式的好处：第一，需求模式提供指导：建议包含哪些信息、提出忠告、提醒常见缺陷以及指出其他应该考虑的问题。第二，需求模式节省时间：不需要从开头开始写每一个需求，因为模式给予了合适的出发点，以及开发的基础。第三，需求模式促进同种类型需求的一致性。其中提供指导是最有价值的。节省定义的时间和增加一致性固然很好，但是合理的指导可以获得更好的需求，避免后续工作中的巨大麻烦。
需求模式提供的指导通常比只是“比如说这样”更深入。它可以深入洞察即将发生的问题。它可以帮助提出问题。在一些情况下，它可以引导编写一个（或多个）非常不同于第一印象的需求。解答一个大问题经常引出很多很小的问题。需求模式针对大问题给出答案以及化为更小的问题。
一些需求模式要求或者鼓励定义一些额外需求：包括跟随性需求：扩展最初需求的需求，以及系统级普遍性需求：支撑模式本身的需求。这样可以检查每一个需求是否需要额外支撑需求，以及是否已经定义了他们。
模式有不同的详细程度和价值。一些类型的需求可以定义得非常详细，它们的实例几乎一样。其他类型的需求虽然有一些普遍有价值的东西，但是这些需求如此多变甚至不能描述应该表达什么。这些变化是正常的。模式只需要证明自己是有价值的；它不必做模式可能做的所有的事。另一方面，反复遇到一种特别需求并不意味这种需求模式自然而然就有价值。如果很难概括这种需求的共性，就很难指导怎样定义这种类型的需求。
需求模式需要描述什么时候使用模式以及基于模式如何编写需求。它还可以提示如何实现以及如何测试这种需求。每个需求模式包含如下的要素：1）基本细节2）适用性3）讨论4）内容5）模板6）实例7）额外需求8）开发考虑9）测试考虑。
需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖，所以如果一个领域依赖另一个领域，那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。每个基础架构概述分成下列小节：1）目的 解释基础架构存在的理由，以及扮演的角色。2）调用需求 关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力。需要的功能可以被看作是基础架构提供给调用者的接口。3）实现需求 为了使基础架构站得住脚所需要的一些特性的想法。这些是比较简短的，只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。
当几个需求模式有共同的特性，可以建立一个需求模式组，用于描述它们共同的方面，而不必在每个模式中重复。一个需求模式组不是一个需求模式：不能建立这种类型的需求。但是一个组可以包含下列出现在需求模式定义中的任何部分：“额外需求”、“开发需求”和“测试需求”。包括哪一部分而省略其他部分的原则是是否有一些事情值得说。任何时候如果某一部分出现在了需求模式组里，模式的相应部分应该包含一个注释，提醒参考需求模式组。
领域和需求模式组的区别在于领域中的模式共有一个主题，而在模式组中的模式有共同的细节特性。一个组中的模式不一定属于同样的领域。
当使用一个需求模式时，应该描述建立这种类型需求的需要知道的所有事。但是一个模式可能会因为一些原因引用其他模式。需求模式之间的关系存在两种基本类型：1）引用 一个需求模式可以在定义中提到另一个模式。2）扩展 一个需求模式以另外一个模式为基础开发。在面向对象的术语中，这是继承关系。除了扩展另外一个模式，需求模式可以扩展为需求模式组。
保持最初的需求，但是分割成多个部分，使他们变成附加需求，这就是提炼主要需求。每个提炼需求应该定义一个特别的方面。每个提炼应该定义它依赖的需求。