前面了解到什么事需求的 ，接下来就应该学习如何使用和编写需求模式。我们不仅到了解需求模式的含义，更要学会在什么情况下使用需求模式。在定义系统期间，有两种场合使用需求模式：
1.当定义需求时，看是否存在一个模式可以指导如何定义这种需求。
2.当考虑系统需求是否完全时，浏览主题覆盖的整套模式——看是否有遗漏，或者是否需要添加什么东西。
3.当评审需求规格时，模式可以帮助检查需求的质量，确定还有哪些主题没有定义，理解特定需求的意义和内涵。
4.当评估系统的规模以及开发所需的工作量时，基于需求，使用模式可以对实现的复杂性有更准确的感觉。
5.当实现需求时，模式可以使你更深刻地理解需求的意图。
6.当测试需求时，用于建议测试这种需求的方法。需求模式并不是能够满足所有的需求，使用模式只是尽可能的做到更好。
如何编写模式是我们更加关注和学习的。首先我们应该学会发现潜在的需求模式，在完成的需求中搜寻模式是捕获需求模式的第一步。有两种方法找到目标：系统化——有系统地彻查一个领域，检查大部分目标；机会化——捕获偶然发现的任何目标。书中还介绍了如何建立新领域，这一部分是编写需求模式的开端。所谓是万事开头难，这也是这么个道理。每件事情的开头总是最难的，但也是最重要的。好的开端是成功的一半。
编写模式的步骤：
1.是否有足够的价值；
2.建立模式的骨架；
3.编写模式的“适用性”部分；
4.收集需求实例；
5.检查需求实例；
6.描述需求可能包含的信息；
7.编写需求模板；
8.编写剩下的“讨论”和“内容”部分；
9.开发潜在的额外需求实例的列表；
10.确定额外需求的候选主题；
11.编写“额外需求”部分；
12.编写“开发考虑”部分；
13.编写“测试考虑”部分；
14.是否值得？
15.评审模式。
虽然编写需求模式的步骤有了，但是我们在实际项目中还是要视情况而定，不能照本宣科，也不要机械地照搬。需要每个阶段投入认真的思考。
书中介绍了37个需求模式。被分为8个领域。当编写需求规格时，列一个可以用于正在定义的这种系统的所有需求模式的名单时有用的，可以更方便的找到想要的。不是所有的模式都可以适用于所有的系统，所以建立一个只和自己的系统有关的模式的名单还是值得做的。