今天我开始阅读《软件需求模式》这本书的第3,4章，以下是从这本书中获得的一些知识。
其中第3章描述了需求模式扮演的角色，解释了每个模式的一些具体内容和具体结构。而第4章则介绍了何时以及如何去使用需求模式，如何从原有的模式创造出新的模式或者直接编写新的模式。
第3章首先为我们解释了需求模式的概念：定义一种特定类型需求的方法。需求模式就是为我们提供一种需求定义的方法，我们省去自己去从头定义需求的时间。我们使用需求模式可以1.合理利用它的指导，2.节省开发时间3.可以促进同类型需求的一致性。
而需求模式也是包含一定要素的：
1基本细节：包括模式声明，就是声明一些模式版本号，模式上次修改日期，需求方法等信息；所属领域，就是描述这个需求模式隶属于哪一个领域；相关模式，就是描述和其他相关模式之间的一些关系；预期频率：描述需求规格中这个模式可能需要用到多少次；模式分类，他就是列出模式覆盖的主要需求类型的分类；模式作者。
2适用性：描述需求模式的适用情况，它的语言必须是明确的，并且能够清楚的描述模式的适用环境。
3讨论：这部分主要考虑的如何编写这种需求，以及编写这种需求时需要注意的一些事情。
4内容：要求以条目的形式列出这种类型的需求必须传达那些信息
5模板：需求模板的目的是可以复制它作为需求描述的出发点。
6实例：每个模式必须包含至少一个或多个实例，用来演示在实践中如何使用模式
7额外需求：需求只说了必须要说的是不够的。还需要“额外需求”来描述那些需要额外考虑，以及在什么情况下需要考虑。其中额外需求有两种：跟随性需求，就是扩展原有需求，在原来的后面，定义一些附加的事情。普遍性需求，普遍性需求是适用这种类型的所有需求，并且针对整个系统只定义一次。
8开发考虑：这主要是帮助设计和实现软件的开发人员慢走这类型的需求，他提供了提示和建议，指出了开发人员不要忘记的一些事情。
9测试考虑：它主要是为了用户验收测试而编写，需要注意传达以下信息：评审这类需求需要注意的地方；总体上指导如何测试这种类型的需求；提醒一些需要注意的地方以及如何处理。
另外我们还要注意领域的概念。就是我们的需求模式不是整块的展现出来，我们需要给每一个需求模式分配一个领域，让领域内的所有模式共享它。而为了把需求描述的更清楚，我们则需要用到基础架构，它的角色是指导和建议如何定义一个特定系统的基础架构的需求。
当然当几个需求模式具有共同的特性时，可以建立一个需求模式组，描述他们共同的方面，而不必在每个模式中重复。
需求模式之间的关系主要有两种，引用：一个需求模式可以在定义中提到另一个模式。主要是这个需求可能包含有另一个需求的相关信息。扩展：一个需求可以以另一个需求为依据进行开发。
我们还要学会对需求进行分类，提炼需求，转移需求模式，分心需求模式用例等
第4章就是叫我们如何使用和编写需求模式
那么我们何时需要使用需求模式呢？1当定义需求时，看是否存在需求模式可以指导定义需求。2当考虑需求是否完全时，观察主题覆盖的整套模式，看看是否有遗漏或添加什么东西。3当评审需求规格时，模式可以帮助检查需求的质量，确定还有那些主题没有定义、理解特定需求的意义和内涵。4当评估系统的规模及工作量时，基于需求，使用模式可以对实现的复杂性有更准确的感觉。5当实现需求的时候，模式可以使你更深刻的理解需求的意图，其中“开发考虑”就是为开发人员设计，帮助开发人员更好的编程6当测试需求的时候，模式中的“测试考虑”就是为软件测试人员而写，帮助测试人员做测试。使用需求模式有以下好处：需求更容易阅读、需求更容易与同类型其他需求做比较、可以判断是否有遗漏、编写需求更容易、读者可以参考编写的模式获得更多的信息、编写需求规格时可以参考模式。但是还要注意一些问题：可能被诱导疏于思考、可能滥用模式、很多需求可能措辞相似。
接下来为我们讲的是裁剪需求模式，因为需求的措辞很大程度上取决于个人的偏好，因此没有过多的限制，而且以客户的语言编程编写需求规格是并且永远是最重要的。由于种种原因，需求模板中使用的语言应该与使用模式的需求规格中一致。由于这些原因，我们有必要对需求模式进行裁剪。需要注意的是，模式的基础是一样的：裁剪只是对使用模式产生的需求做一些调整，然后每一次裁剪一个需求模式时要建立一个新的需求模式声明。
编写新的需求模式：在工作中发现一些类型的需求总是反复出现，以一致的方式编写会受益，或者只是有时候定义的很糟糕，那就别再犹豫，不要畏惧为他们编写一个需求模式。
如何发现潜在的需求模式，系统化：研究每一个目标需求并尽量对其分类：是什么类型的需求？如果有模式可以适用，记录下来然后继续。如果现有的模式不是很合适，研究需求看是否可以设计一个新的，更专用的模式。机会化：当定义一个需求时，你可能意识到会有同样类型的需求出现，如果觉得编写这种需求很棘手，也许就值得编写一个模式帮助其他人解决类似的问题——并促进一致性。
如何编写需求模式：1是否足够的价值？在开始编写模式之前，一定要考虑努力是否有回报；2建立模式的骨架，骨架包括所有要求的标题和“基本细节”部分条目；3编写模式的“适用性”部分，描述模式是为了什么，必须尽可能精确。4收集需求实例，构造所有能找到的实例列表。 5检查需求实例，决定他们的共同之处，以及如何变化。 6描述需求可能包含的信息。提炼实例的内容组成一套独特的片段，给每一项信息一个简洁的描述性名称。7编写需求模板 ；8编写剩下的“讨论”和“内容”部分；9开发潜在的额外需求实例的列表；10确定额外需求的候选主题 ；11编写“额外需求”部分；12编写“开发考虑”部分；
13编写“测试考虑”部分；14是否值得；15评审模式。