读完了这本书的第二部分，我感受颇深，总结了许多自己所不了解的知识。需求分析基本原则是 1 定义问题，而不是解决方案。需求定义“做什么，而不是怎么做”，意思是需求的目的不是企图定义任何的解决方案。这是重要的特点，是不可违反的规则。2 定义系统，而不是项目。需求定义了系统需要做什么：他们是一组目标。项目是在一段时间内动员一组人来完成这些目标。需求不涉及系统如何完成目标，这意味着不要涉及实现一个解决方案的项目的任何事情，而且编写每个需求规格应该是长期有效的，适用于多个系统，这些系统可能在不同的时间以不同的方式开发：需求可能被束之高阁，然后一两年后拿出来，或者几年时间内我们可能开发一个替代系统。3 区分正式和非正式部分。需求规格像一个合同，它定义了系统的供应商或开发者必须交付的东西。但是大量的合同约束声明远远不能让我们正确的理解它，它需要背景知识、前后关系、流程以及结构。这些材料都不是合同约束。它帮助把规格分为约束部分和非约束部分。需求本身由需求规格的正式部分组成，是系统必须做什么的正式定义。其他的都是非正式的。4 避免重复。如果可行，每一项信息只表述一次。重复产生了额外的工作而且加大了不一致的可能性。敏捷需求流程的原则：区分问题和解决方案是最重要的，定义需求后，一定要记录他以便别人可以找到。需求模式剖析：基本细节、适用性、内容、模板、实例、额外需求、开发考虑、测试考虑。需求规格的内容可以分为四部分：“介绍部分”，“上下文部分”，“功能域部分”和“主要非功能要求部分”。
需求模式提供的指导通常比只是“比如说这样”更深入。它可以深入洞察即将发生的问题。它可以帮助提出问题。在一些情况下，它可以引导编写一个（或多个）非常不同于第一印象的需求。解答一个大问题经常引出很多很小的问题。需求模式针对大问题给出答案以及化为更小的问题。一些需求模式要求或者鼓励定义一些额外需求：包括跟随性需求：扩展最初需求的需求，以及系统级普遍性需求：支撑模式本身的需求。这样可以检查每一个需求是否需要额外支撑需求，以及是否已经定义了他们。模式有不同的详细程度和价值。一些类型的需求可以定义得非常详细，它们的实例几乎一样。其他类型的需求虽然有一些普遍有价值的东西，但是这些需求如此多变甚至不能描述应该表达什么。这些变化是正常的。模式只需要证明自己是有价值的；它不必做模式可能做的所有的事。另一方面，反复遇到一种特别需求并不意味这种需求模式自然而然就有价值。如果很难概括这种需求的共性，就很难指导怎样定义这种类型的需求。接下来， 信息是商业系统活力的源泉，习惯称为数据处理，但信息有更广泛的含义，不仅仅是数据；两个名称都反映信息的核心本质——输入、存储、展示、报告等，在大多数的系统中，特别是在商业运营上有一定作用的系统，所以定义数据的需求以及如何处理他，在系统的定义中扮演至关重要的角色。 需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖，所以如果一个领域依赖另一个领域，那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。每个基础架构概述分成下列小节：1）目的 解释基础架构存在的理由，以及扮演的角色。2）调用需求 关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力。需要的功能可以被看作是基础架构提供给调用者的接口。3）实现需求 为了使基础架构站得住脚所需要的一些特性的想法。这些是比较简短的，只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。
