需求是某种自然法则，需求活动不是编写需求文档。相反，它专注于理解业务问题并为之提供解决方案。
《掌握需求过程》论述了软件开发中的重要课题—如何得到正确需求，书中用一个接一个的步骤、一个接一个的模板、一个接一个的例子，向读者展示了经过业界检验的需求收集和验证过程。针对不同的敏捷环境，为精确地发现顾客所需所想提供了技巧和深刻见解。这是360百科上对这本书的介绍，相信每一次的阅读，都会发现书中的精华，吸取经验。本书一开始就告诉我们什么是需求，书中提到需求就是必须在构建产品之前发现的东西，如果在构建之后才发现，这将给我们带来无比巨大的麻烦，，所以本书要告诉我们的是如何发现这些需求并得知这些需求的正确性。
然后作者告诉了我们需求与系统分析，并说明需求收集与系统分析有一定程度的重叠。作者着重强调需求的重要性，好的需求收集与系统分析是非常必要的。这和老师在课堂上跟我们强调的一模一样。文中提到利用分析模型来描述需求过程，在需求过程发现的那些功能通过建模验证其正确性，并且需求会经过一些变化。需求包括功能性需求，非功能性需求，限制条件。而通过需求说明书可以发现许多关于编写需求和要收集需求类型的思考。而Volere需求过程可以帮我们成功的收集，验证需求并将需求文档化。
这两周读了前两章，在上学期的软件工程概论课上，我们接触到了项目的开发，做项目时，需求分析必是重要的第一步。但是在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但现如今越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。
需求，顾名思义，就其基本意义讲是需要与欲求的意思，是产品必须完成的事以及必须具备的品质。需求分为功能性需求，非功能性需求，限制条件。功能性需求是一个系统,软件所必须完成的功能.功能性需求定义了系统的行为,也就是系统的软,硬件组件在由输入得到输出的过程中,对输入所做的基本的处理和转换.。在软件工程领域,非功能性需求不是描述软件将做什么,而是描述软件如何完成这些功能.即它需要具备什么品质以及它应该多大和多快。限制条件是全局性的需求，要在需求收集工作进行之前确定下来。
需求规格说明书，之前也写过，一般都是照着一些模板左改右改，也没有固定的模板。书中提到的Volere需求规格说明书模板覆盖面广，是一个很好的框架。模板的内容对需求规格说明书作了分类，值得我们学习。
需求过后，就是项目启动，启动会议是一个联合应用开发会议，参与者把他们自己关在一起，共同工作直到达到启动会议的目标，即收集足够的事实以确保项目有一个有价值的目标，该目标可能达到，同时也要取得风险承担者关于承担义务的许诺。启动会议确定产品的目标，要确保小组一致同意该产品是有价值的，同时确保组织有能力构建和操作该产品。最后，要让所有的风险承担者对产品是否值得和可行达成一致意见，即决定继续还是终止。这是关键性的一步。启动会议结束后，就要开始网罗知识。启动会议中的风险承担着在确定工作范围时得到了工作上下文模型，以此作为工作的起点。把工作业务按业务事件进行划分，以便进行进一步更详细的研究。在此之后，还需要做原型和场景建模，原型是潜在产品的一个快速而不完整的版本，对我们来说，可以使用笔和纸画出原型，同时像写故事一样创建场景，用于显示完成特定部分工作所需的步骤，这项活动输出的是需求，要用一致的形式写下这些需求，这并不意味着这些需求就可以加入需求规格说明书，应该检查每项需求的完整性、相关性、一致性和其他一些质量属性，质量关存在的目的是将不好的需求拒之门外，但这只是一次只处理一项需求，必须进行规格说明书鉴定过程来确保需求规格说明书的完整。到这里还没有结束，事后分析相当重要，就算我们做了一件错事，事后也要进行检讨一样。