通过阅读《掌握需求过程》前三章我们大致了解到什么是需求、需求准确性的重要性，以及需求分析中所需要的做得工作，怎样确定一个项目的业务问题的范围，这些都需要我们的学习和实践。
第一章基本事实中，作者讨论了需求的基本构成，并且对我们阐述了几个事实，需求并非在谈需求，对于软件产品、硬件产品、服务或任何你想构建的东西，需求就是它们要做的事或要成为的东西。如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值。如果想要构造的软件要满足要求那么我们必须要知道要求是什么，才能构造正确的软件。我们构造了软件，但构造的软件不一定就解决业务问题，这就需要我们与用户进行沟通交流来解决问题，因此我们最好在构建软件前就尽最大可能解决那些业务问题。需求不一定要写下来，但我们构建者必需知道它们，我们必须保证它的准确性这样才能减少将来的维护工作。需求包含功能需求、非功能需求、和限制条件，其中功能需求是产品必须完成的那些事，非功能需求是产品必须具有的属性或品质，限制条件是一个全局的问题，约束着所有的需求，不论限制是什么，限制条件都可以看成是另一种类型的需求。
第二章需求过程，探讨了需求收集过程，并讨论如何来应用它，不论是要构建用户定制的系统，还是构建组件集成的系统，或者使用商业上架销售的软件包，或者采用开源软件，或者将开发外包，或者对已有的软件进行改动，都需要发现、捕获和交流需求。要构建正确的产品，就必须发现正确的需求。为了发现正确的、完整的需求，需要某中有序的过程。要构建正确的产品，就要发现正确的需求。文中通过项目（IceBreaker）来解释什么是Volere需求过程，项目的启动，启动会议的主要目的是为接下来的需求发现工作奠定基础，并确保项目成功需要的所有东西都已就位。上下文范围模型针对要研究的工作范围，在风险承担着之间达成一致意见，最终的产品将为工作的一部分。我们在为新项目的将带来的好处而欢欣鼓舞之前，早一些了解项目的不利的方面（它的风险和成本）总是好的。在项目会议启动后，我们需要网罗需求，并进行快而不完美的建模，通过场景来展示业务过程的功能性，在这些之后为了避免误解，分析师必须以一种无二义性的方式写下来，确保质量关是需求传递给开发者的唯一通道，这样项目团队就能控制需求，没有绕过去的通道。在开始任何新项目前，浏览一下以前项目的规格说明书，寻找潜在可复用的东西，最终搞得复查需求是我们检查是否存在遗漏的需求，复查也为重新评估产品的费用和风险提供了一个机会。迭代和增量过程、需求反思、需求演进、模块、白雪卡、定制需求过程，我们从各种不同的项目中提炼我们的经验，提供一组适用于所有项目的基本活动和提交产物。
第三章确定业务问题的范围，确定要改变的业务领域，确保项目团队清楚的知道项目的目标，项目启动确定了工作领域的边界，产品将成为其中的一部分，同时也确定了产品要实现的目标。它也确定了利益相关者，即对产品的成功有兴趣的人。项目的启动的其他提交产物确定了项目的可行性，并为后续的需求发现活动的输入信息。正式性指南、设定范围，需要我们退后一步看看拥有者所重视的工作，确定工作范围。从环境中分离工作，为了实现拥有者的最佳价值，就要研究足够的拥有者的工作，以确定什么有价值。工作上下文范围展示了工作的职责和相邻系统的职责起止之处。项目启动阶段是一个了解认知的过程。了解希望该产品做什么，要花多少成本来构建它。了解要研究工作的范围，以便产品收集需求。这个范围最好以上下文范围图的方式展示确定了业务领域，其中的一部分将通过预期的产品实现自动化。