这本书并不涉及定义粗求的流程，分析技术以及需求管理，不关注任何特定的方法论、办法，或者定义软件的工工具。
需求开发是探险之旅，不只是简单的手机或抄写的过程。
这本书分为两部分，第一部分：准备开始，分为4章，第一章讲述了一些基本原则，对阅读本书之后的部分有帮助，第二章描述了需求规格包括的素材的类型，第三章解释了什么是需求模式：基本要素，每个模式包括什么，他们如何组织形成领域，以及相关概念。第四章解释了如何使用需求模式，以及如何编写自己的需求模式。第二部分：需求模式目录 十一组经常出现的需求类型的模式。
而我到现在只是看完了前四章，也就是第一部分（准备开始）。
需求是定义系统需要做什么而不是怎么做。需求定义了必须解决的问题：系统的目的是什么，以及为了达到目的系统需要的所有功能。需求不定义解决方案。需求中不止一个合适的细节层次。可以在不同的细节层次定义需求。需求最重要的是定义了系统必须做什么和它必须能完成的行为。
定义需求的一些基本原则：1.定义问题，而不是解决方案；2.定义系统，而不是项目；3.区分正式和非正式部分；4.避免重复。
不同方法了呢的区别主要在整个流程实用的规模的大小不同，可以大到是整个系统（传统方法），也可以小到时手头的一块编码单元（极限流程）。 传统的定义需求的方法是，有一个专门的需求阶段，交付一份详细的需求规格，然后开始设计和开发系统。
需求规格的内容可以分为四部分：“介绍部分”，“上下文部分”，“功能域部分”和“主要非功能要求部分”。介绍部分：系统目的、文档目的、需求格式、词汇表、参考书目和文档历史。上下文部分：组件、用户角色、范围边界和系统间接口（也可以加上通信链路、主要的数据存储）。功能域部分：对每一个功能逻辑编写一个高层描述（给予每种用户的兴趣），按照功能域命名每个小节（如：客户功能）。主要非功能要求部分：是适用于整个系统。很难固定这部分的内容，因为这很大程度以来系统的特征。
需求模式剖析：基本细节、适用性、内容、模板、实例、额外需求、开发考虑、测试考虑。需求模式之间的关系：引用和扩展。
什么时候使用需求模式：当定义需求时、当考虑需求是否完全时、当评审需求规格时、当实现需求时、当测试需求时。
使用需求模式的好处：需求更容易阅读；需求更容易与同样类型的其他需求比较；可以判断是否有遗漏；编写需求更容易；读者可以参考编写的模式获得更多的信息；编写需求规格时可以参考模式；
使用需求模式的坏处：可能被诱导疏于思考；可能滥用模式；很多需求可能措辞相似。