需求模式最主要的目的是帮助定义一个新系统需要做什么。即使是最敏捷的、不编写正规需求的开发人员，也可以使用模式——在这种情况下，需求模式可以直接作用于思考，而不是通过中间的需求分析步骤。在定义系统期间，有两种场合使用需求模式：
1）当定义需求时，看是否存在一个模式可以指导如何定义这种需求。然后这个模式就可以提供详细的建议，例如应该描述什么，如何描述，其他还要担心什么，还有考虑什么额外主题。一旦决定使用一个模式，就要通读整个模式（或者熟悉它描述的所有事情，这样可以不必每一次都阅读）。也就是说，熟悉面前的模式，按照他告诉的去做。
特别注意“额外需求”一节所说的，因为他可能深刻的影响系统的本质和质量。即使认识到模式建议的额外需求的价值，可能你不想马上就撤下主要的工作去处理他们。没问题：只要标记还有工作要做。还需要注意使用的模式依赖的每一个基础架构：把他加到需求规格的“基础架构”部分，并确信被合适的定义。
2）当考虑需求是否完全时，浏览主题覆盖的整套模式——看是否还有遗漏，或者是否需要添加什么东西。
其次，需求模式也可以在事后使用——也就是说，需求已经编写完成。事后使用是否方便，以及效果如何，要看定义需求时是否使用了模式，如果是，还要看对模式遵守的程度。需求已经编写完以后使用模式有几种主要方式：
3）当评审需求规格时，模式可以帮助检查需求的质量，确定还有那些主题没有定义，理解特定需求的意义和内涵。
4）当评估系统的规模以及开发所需的工作量时，基于需求，使用模式可以对实现的复杂性有更准确的感觉。
如果在以前项目中有记录一个特性所花的时间，就可以计算实现一种特定类型的需求需要的工作量——也就是说，可以记录每个模式的度量，这样可以快速估算基于模式的所有需求的工作量。
5）当实现需求的时候，模式可以使你更深刻的理解需求的意图。
6）当测试需求的时候。
使用需求模式有几个好处：
1）需求更容易阅读——因为为了建立一个模式投入了大量的思考，远比能投入在一个需求上的思考要多。
2）需求更容易与同样类型的其他需求比较——因为他们的结构相似。
3）可以判断是否有遗漏——因为对照模式可以知道是否需求缺少模式中的一些内容。
4）编写需求更容易——因为可以按照主题的检查列表思考。对于没有经验的分析师这是最大的帮助。
5）可以参考编写的模式获得更多的信息。
6）编写需求规格时可以参考模式——检查是否有任何类型的需求应该定义但是被忘记了。
使用需求模式有几个坏处：
1）可能被诱导疏于思考——因为如果机械的应用模式，特别是从模板复制文字然后填充空白，有可能没有充分的调动你的智力。
2）可能滥用模式——如果在不恰当的环境中使用模式。为了提防这个，确信你完全掌握了你使用的每个模式（特别是适合使用的情况），并且确信应用模式的需求适合这个环境。
3）很多需求可能措辞相似。
需求的措辞很大程度上取决于个人的偏好，我们不会过度的限制，因为这样可以使需求更生动，而不是华而不实的技术文档。措辞还要考虑组织的文化，还有，以客户的语言编写需求规格是并且永远是最重要的。由于这些原因，需求模式模板中使用的语言应该与使用模式的需求规格的语言一致。风格的突然改变会让读者感到突兀和不舒服。最坏的情况下，由于规格的一些语言来自组织外部，可能会损害作者的信誉。由于这些原因，有必要裁剪需求模式而不是设计模式。所以准备好做裁剪。模式的基础是一样的；裁剪只是对使用模式产生的需求做一些调整。有时候只是需要改变需求定义模板，然后修改例子反映对模板的修改。同时要检查其他的模式是否与修改的模板一致，并按照需要调整他。
不要轻率地对待一个新模式，或者说只是因为喜欢一个想法。只有新模式能够交付足够有用的价值时才去做。这是主观判断，可以基于定义这种类型的需求将会节省多少时间、有多少需求合适、每一个将节省多少时间，还有编写需求会得到多大的收益。