上个月阅读的《软件需求最佳实践》中对软件需求的定义与解释非常详细明了，这个月开始要阅读《掌握需求过程》这本书，其中也很详尽的讲述了需求等知识。通俗的说，需求就是必须在开始构建产品之前要发现探索的东西。开始时，需求活动占主导地位，创建的仅有的分析模型是上下文范围图，也许还有探索性的数据模型，随着时间的推移和对产品深入地了解，工作重点逐渐转向系统分析。需求是产品必须完成的事及必须剧本的品质。需求中的功能性需求就是产品必须要完成的事，非功能性需求则是产品必须具备的属性或品质，限制条件是全局性的需求。每一条单独的需求都有一个结构，后边解释如何才能成功的收集、验证需求并将需求文档化。
这本书基于Volere需求过程和它相关的模版，该过程是一个一般的需求收集和规范化过程。启动会议是一个联合应用开发会议，参与者把他们自己关在一起，共同工作直到达到启动会议的目标，启动会议确定了产品的目标。启动会议结束后，就开始网罗知识，做原型和场景建模。原型是潜在产品的一个快速而不完整的版本，原型的意图是向用户表达需求的一种模拟。有两种方法来构建需求模型：高保真的和低保真的。场景是一些创建的故事，用于显示完成特定部分工作所需的步骤。不管使用哪种形式的原型，这项活动的输出是一些需求，也必须将这些需求记录下来。质量关是每项需求在成为需求规格说明书一部分之前必须通过的一个单点，建立质量关可以防止需求渗漏。
项目启动是一项突发性的活动，通过这个活动收集让项目启动所需的各种信息，启动阶段确定产品作为其一部分的工作，并确定产品要实现的准确目标。通过Icebreaker项目更好的展示了需求过程，这一部分老师在课堂上也重点讲到了。产品目标描述了构建产品的原因—产品将做哪些有助于工作的事情？产品目标是最高层次的顾客需求，是业务上的需求。在建立起产品的目标后，也需要保持项目朝着目标前进，质量关让每项需求通过一系列的检查，有一项检查确保其相关性。谁为产品付钱：客户和顾客。客户为产品的开发付费，顾客在产品开发完成后购买产品。用户是最终操作产品的人，确定用户的目的是理解他们所做的工作，知道用户的特点，可以写出正确的易用性需求，另外还存在很多潜在用户，还有很多可能会被遗忘或没有注意到。风险承担者是在产品中有既得利益的人、是对产品有一些要求的人。需求限制条件是全局性需求，包括：设计限制、开发时间限制、经费限制等。我们在项目开始阶段感兴趣的范围是工作的范围，设定工作的范围意味着决定在确定产品的需求之前有多少工作要研究，感兴趣的领域是主题相关的领域。工作上下文范围定义了要研究的工作，以及工作周围的其他系统，表现了工作和与之相连的工作，显示了工作的职责和相邻系统的职责起止之处，确定了我们研究过程的边界。
工作是客户的业务活动，为了理解工作，必须知道它与外界是怎样联系的，展示工作与外界联系最方便、最有用的方法就是使用上下文范围图。业务对事件做出响应，对每个事件的响应视为一个要研究的工作单元，业务事件的响应是通过数据流的到达来触发的。时间性的业务事件通过时间流逝来触发，当针对某事件的预先定义的时间到来时，工作的响应是完成输出所需要做的事情。相邻系统是为了工作提供信息和服务或从工作接收信息和服务的系统，一个相邻系统可能是一个组织、一个人、一种技术，或者三者的组合。
项目启动阶段是一个了解认知的过程：了解希望产品做什么、要花多少成本来构建它、了解要研究的工作范围以便为产品收集需求。通过引入业务事件的思想，可以合理的切出一部分工作，用于进一步的建模和研究。理解每个相邻系统对工作的影响，理解了产品范围的限制。通过对工作行为建模，得到了范围。