这本书的译者就在序中写到：“需求是平衡的艺术，既要对开发人员有指导意义，又要能帮助解决业务问题，如何在两者之间取得平衡，本书中的大量实例对此有自己的独特见解”。显然，需求分析就是连接客户和软件开发者，或者说，连接业务与软件的最关键的桥梁。需求是开发人员开发软件的基础，需求也是业务人员的业务目标。
首先，我们应该认识到的就是，什么是需求？需求应该是用最清晰的文字来阐明系统所必须具有的所有功能和其他能力，即需求定义了系统必须做什么和它必须完成的行为。本书中就定义了需求的一些基本原则：（1）定义问题，而不是解决方案。我们要理解问题的本质，在需求中明白问题是什么，而不是应该怎么做。（2）定义系统，而不是项目。需求所体现的是这个系统的功能，而系统就是一组目标，但是项目却是如何完成这一目标。（3）区分正式和非正式部分。我们应该从大量的需求信息中，通过背景知识、前后关系、流程以及结构来正确地认识到需求的正式组成部分，即系统必须做什么，而其他的都是非正式的。（4）避免重复。每一项信息应该只需要表达一次，重复会产生额外的工作而且加大了不一致的可能性。在认识和定义需求的同时，本书也为我们提供了一个典型的传统需求阶段的步骤：（1）准备。（2）收集信息。（3）编写需求规格草稿。（4）评审规格。（5）评审后修改。
在了解了什么是需求和需求阶段的步骤之后，我进一步学习了需求规格的内容。首先是介绍部分，系统规格的介绍部分有：系统目的、文档目的、需求格式、词汇表、参考书目以及文档历史。其实这六个主题的目的都是为了让开发者能够更清楚地认识到需求，才能更好地去开发软件。在我看来一个好的需求分析，应该让我们很清楚明白地认识到我们的系统本身的目的是什么，我们要使用更简洁明了的语言用来代替一些难懂的专业术语去描述每一个需求。所以介绍部分就是让我们更好地认识需求，才能使我们把握好开发系统的方向。其次是上下文部分，就在上课老师也让我们练习了这一部分的内容，即上下文图。在上下文图中我们需要展示组件、用户角色、范围边界、系统间的接口，在这之中，我们就需要对每一个是真的事情，清楚明确地声明为假设，同时也要把不需要的东西排除在外，最后我们要确定关键业务实体（即系统就是为了产生和操纵这些东西而开发的），然后构件基础架构（支持一个或多个需求所需的一组基础的能力）。然后就是定义系统的核心部分——功能域部分。我们需要在需求中详细地列举出系统的所有功能，将其分为大量的小节而更方便管理也更容易理解，然后需要根据功能的使用频率、发起者的相对重要性或者对业务的价值来区分不同的功能的重要性，并且从高到低依次排列。最后是主要非功能要求部分，我们需要筛选出系统功能中不重要的部分，把它们分配到规格内容的其他部分当中，而对于主题太大的不主要功能就加到“主要非功能要求”当中，并组织语言，定义最合适的标题。
通过本次的阅读，我比较清楚地认识到了需求就是阐明系统功能或者说定义系统行为的工具，而且也学习掌握了在编写需求文档时的一些规格内容，让我对软件需求在总体的分析和编写上有了大致的了解。
