<<软件需求模式>>是我阅读的第三本书。我读到了第一部分。这本书的目的是帮助决定和定义新的软件系统需要做什么，建议添加哪些额外的特性，是系统更好或者更卓越。通过详细的指导如何定义一个需求，能够节省工作量。需求模式是技术的结晶，方便将来重用。这本书包括37个需求模式，每一种模式描述一种方法，解决在所有系统中反复出现的一种特定的情况，主要关注商务业务系统，任何系统都只有一小部分属于特定的业务范围，不管系统是做什么的，大部分是反复出现的，这些模式覆盖了一些系统中超过一半的需求。软件系统的需求定义它要解决的问题：它的意图和目的。如果需求遗漏或者做的很糟糕，系统就不可能是合适的，不管系统实现的如何完美。相当比例的计算机系统被认为是不合格的，很多甚至没有交付使用，更多的是延期或者超预算。很多研究都表明最大的一个原因就是拙劣的需求定义：没有完全地确定系统的意图和它必须做的事。甚至稍微改进需求就可能节省商业上浪费的大量投资。为了确保构造更好的系统，需要一系列的改进。几乎各个领域已经进行大量的投资。但是其中最基础的是需求本身表达什么。这点被忽略了，如果想定义一种特定类型的需求，需要写什么？如何着手。模式本身希望是脚踏实地和实用的多年以来积累的经验。
这本书分为两部分，第一部分是准备开始，包括四个解释性的章节，第二部分是需求模式目录。第一部分主要讲什么是需求。需求定义了必须解决的问题，系统的目的是什么，以及为了达到目的系统需要的功能。需求不定义解决方案。一个需求是系统必须满足的单一的，可测量的目标。最好使用清晰的文字来表达每个需求。一个系统的需求规格是一个文档，它陈述了系统的所有需求以及任何使文档更容易阅读和理解的背景材料。它需要定义系统必须具有的所有功能和能力。需求中不止一个合适的层次细节，恶意在不同的细节层次定义需求。一个相对概括性的需求可以理解为更明确的需求，以更清楚地阐明最初的含义，也可能在不同的层次编写多个需求规格。一些组织和专家通常将需求分为不同的层次，高层需求获取业务目标，详细需求说明为了完成业务目标系统需要的功能以及其他的能力。需求最重要的是定义了系统必须做什么和它必须能完成的行为。这些叫功能性需求，它包括非常广泛的主体，从性能，安全到系统必须遵从的标准。
定义需求的过程就是确定一个系统需要做什么的过程。每一个曾经被开发过的系统都定义过需求，不管需求是否被明确地说明。一个程序员决定什么是需要的，然后就开始编码，即使需求一闪而过，立刻被更令人兴奋的设计灵感所取代，他仍然做了闪电式需求规格过程。传统的定义需求是有一个专门的需求阶段，交付一份详细的需求规格，然后开始设计和开发系统。当且仅当真正需要的时候才做需求工作。这是应用增量方法的前提条件，前期做最少的需求工作，尽可能开始开发，这里有两件事要决定：需求应该详细到什么程度，什么时候定义每个需求。一种方式是写好完整的详细的需求规格，然后开始设计和开发工作，另外一种是把一个需求作为开发单元的一部分。这两种方式分别代表了前面描述的传统需求流程和极限需求流程。