日期：2017年11月8日
一周前阅读完了《软件需求十步走》，对于怎样进行软件需求分析的流程有了大致了解。阅读本书希望可以通过学习需求模式对系统间的借口、文档需求、制定系统的可用性等具体方面有所收获。这些天读了《软件需求模式》的一部分。
需求模式概述：
除了无关紧要的系统，所有系统需求本质上彼此相似，或者它们出现在大部分系统中，而且可能数量众多。例如，可能有很多查询功能，每个功能都有自己特有的需求。当定义一个业务系统时，相当大比例需求归属相对少量的类型。以一致的方式定义同样类型的所有需求是必要的。因此我们引入需求模式的概念，描述使用需求模式的每一个需求应该怎样定义。
需求模式：定义一种特定类型需求的方法。
需求模式应用于单个需求，一次帮助定义一个单一需求。例如，对于某一种报表需求，可以使用报表需求模式帮助定义需求。一旦编写完需求（以及任何它引起的额外需求），模式的任务就完成了，可以把它放在一边继续工作。但是当软件设计人员或开发人员开始决定如何实现这个需求时，只要他们愿意，模式就可以给他们一些工作提示。测试人员同样可以使用模式获得如何测试的方法。
使用需求模式有什么好处？第一，需求模式提供指导：建议包含哪些信息、提出忠告、提醒常见缺陷以及指出其他应该考虑的问题。第二，需求模式节省时问：不需要从头开始写每一个需求，因为模式给予了合适的出发点，以及开发的基础。第三，需求模式促进同种类型需求的一致性。其中提供指导是最有价值的。节省定义的时问和增加一致性固然很好，但是合理的指导可以获得更好的需求，避免后续工作中的巨大麻烦。
需求模式提供的指导通常比只是“比如说这样……”更深入。它可以深入洞察即将发生的问题。它可以帮助提出问题。在一些情况下，它可以引导编写出一个（或多个）非常不同于第一印象的需求。解答一个大问题经常引出很多更小的问题。需求模式针对大问题给出答案以及化为更小的问题。
一些需求模式要求或者鼓励定义一些额外需求：包括跟随性需求：扩展最初需求的需求，以及系统级普遍性需求：支撑模式本身的需求（例如，这种类型需求都需要的一个基本特性）。因此知道自己使用了哪些模式是有用的（或许可以保留一个简单的名单），这样可以检查每一个需求是否需要额外支撑需求，以及是否已经定义了它们。