本书分为三大部分：
第一部分先介绍了一些基本的需求工程定义和一些优秀的需求分析所具有的特性。我希望你与你的重要客户能一起阅读第 2章（关于客户与开发者之间的伙伴关系）；第 3章介绍了许多需求开发和管理的改进熟练程度的好方法（良好的习惯做法）。第 4章有助于计划怎样将新的策略融入小组的开发过程中。方法是基于对附录中当前需求实践自我测试的回答。第 5章则介绍了一些通常与需求相关的项目风险。
第二部分介绍了许多关于需求开发的技术。首先是定义项目的业务需求，项目视图(vision)及涉及的范围(scope)。接下来的章节介绍怎样为项目寻找合适的客户代表，获取（elicit）用户需求，编写功能需求文档及质量属性文档。第 10章介绍了一些分析模型，这些模型可用于不同范围的需求分析。第 12章介绍了软件原型的结构和应用。第二部分中的其它章节还探讨了定义需求优先级的方法及验证需求分析是否正确的方法。
第三部分的主题是需求管理的原则和策略。这部分还特别介绍了处理需求变更和评价每项变更对项目影响的技术。第 18章介绍了怎样把需求跟踪能力和单个需求相关的内容需求来源到与需求相关的设计、代码等）联系起来。第三部分的内容包括一些商业工具的说明，这些工具能增强你管理项目需求的能力。
你一定知道：一个不能让你进行一项基本操作的软件产品是多么令人烦恼。你不会感谢开发者，尽管他最终会满足你主要的需求变更。但从开发者角度，你也知道，当用户在整个系统已经完成后，再提出一些功能要求是多么烦人的事。同时，由于修改系统的请求会打断你当前的项目，也是令人很不愉快的。而且往往这种修改请求还要求你优先处理。
其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误所带来的。
在软件工程中，所有的风险承担者（stakeholder）都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用下面提供的有效的需求分析过程。
（1）了解软件需求开发中使用的一些关键名词。
（2）警惕在软件项目中可能出现的与需求相关的一些问题。
（3）知道优秀的需求规格说明应该具有的特点。
（4）明白需求开发与需求管理之间的区别。
并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（Lawrence 1998）。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。
软件需求包括三个不同的层次——业务需求、用户需求和功能需求——也包括非功能需求。业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
在软件需求规格说明中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于软件部件。