何时以及如何使用需求模式，需求模式的目的是帮助定义一个新系统需要做什么。即使是最敏捷，不编写正规需求的开发人员，也可以使用模式--在这种情况下，需求模式可以直接作用于思考，而不是通过中间的需求分析步骤。
使用模式的意图是减少工作量，尽可能做到更好，而不是机械的应用模式，系统越不独立，可以应用模式的需求的比例越低。
裁剪需求模式：
需求模式模板中使用的语言应该与使用模式的需求规格中的语言一致。风格的突然改变会让作者感到突兀和不舒服。裁剪只是使用模式产生的需求做出一些调整。有时候只是需求改变需求定义模板（因为它们是唯一一部分在实际的需求中需求引用），然后修改例子反映对模板的修改。同时要检查其他的模式是否与修改的模板一致，并按照需要调整它。每一次裁剪一个需求模式时要建立一个新的需求模式声明。模式的宗旨是“描述一种在我们周围反反复复出现的问题”。研究每一个目标需求并尽量对其分类，不要仓促的建立太细节的模式。编写需求模式时最好首先采用系统化的研究，而不是单独编写每一个。这样可以看到模式相互之间的联系，编写的模式也更一致。模式只有提供充分的价值才有存在的理由。不要是所有的需求都值得这样做。有些需求只是一次性的，可能再也不会出现。只有编写模式的工作量可以它的收益抵消，一个模式才是值得做的。这只能是在多次使用时才可能发生。因为只有使用模式节省的工作量要远于编写它的工作量时，模式才可能真正净收益。
如何编写需求模式：
①是否有足够的价值。判断模式的价值是基于经验的猜测，但是如果看上去没有希望，就不要继续了。
②建立模式的骨架
③编写模式的是“适应性”部分。如果感觉描述困难，这可能表明在头脑中还不像想象的完全清楚它的目的。继续之前先把它理清楚。
④收集需求实例⑤检查需求实例⑥描述可能包含的信息⑦编写需求模板⑧编写剩下的“讨论”和“内容”部分⑨开发潜在的额外需求实例的列表⑩确定额外需求的候选主题......
基础需求模式
①系统间接口需求模式
重视系统间接口，不能低估了它们的复杂性，这是非常重要的；着重强调他们，尽早把他们确定下来，给它们足够的分配的资源。每个系统规格应该包括一个系统上下文图，它应该是接近开始接口定义。接口适配器的引进，我感觉这个很像软件设计模式里面的适配器模式。
②系统间交互需求模式
适用性：使用系统间交互需求模式定义穿越系统间接口的特定类型交互