需求入门： 需求工程＝需求开发＋需求管理

上图是需求工程的组成部分，从图中可以看出，需求工程划分为两个部分：需求开发和需求管理。需求开发又分为需求获取（Elicitation）、需求分析（Analysis）、编写规约（Specification）和需求验证（Validation）。需求管理又分为基线管理、变更管理、需求跟踪。 下面我将分别介绍一下上面各个主要组成部分主要的工作内容，以便那些不熟悉需求的人员读后能够从总体上把握需求所涉及的工作内容。 需求开发 需求开发活动包括以下几个方面： 确定产品所期望的用户分类。 获取每类用户的需求。 了解实际用户任务和目标以及这些任务所支持的业务需求。 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 了解相关质量属性的重要性。 商讨实施优先级的划分。 将所收集的用户需求编写成规格说明和模型。 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 实际工作中很难一次性得到完全正确的需求，所以以上步骤并不是严格顺序执行到底的，它是一个不断反复的过程。这些步骤也不是完全顺序的，很可能需要迭代的进行。基于项目的产品需求开发过程可能如下图所示： 下面就需求开发每个活动进行简单介绍： 需求获取 在《软件需求的三个层次》中介绍了三个层次的需求，在需求获取中，这些需求都是我们需要获取的，我们需要收集问题域的描述，要求解决的问题列表，以及了解系统的行为或约束。 信息来源 客户（实际的和潜在的） 用户（实际的和潜在的） 已有系统及其文档 领域专家 相关技术标准和法规 获取技术 阅读背景资料 用户访谈、调研 需求讨论会 现场观摩 需求分析 需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。 不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析 交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材 编写规约 规格说明书是对需求分析结果的文档化过程 需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离 为需求规约定义统一的格式是一个很重要的工作 规约内容必须严谨、正确、无歧义 需求验证 不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更 提高需求质量的重要手段有：需求评审、需求确认和原型验证《需求方法之－原型开发》 需求管理 需求管理活动包括： 定义需求基线（迅速制定需求文档的主体）。 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 以一种可控制的方式将需求变更融入到项目中。 使当前的项目计划与需求一致。 估计变更需求所产生影响并在此基础上协商新的承诺（约定）。 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 在整个项目过程中跟踪需求状态及其变更情况。 软件需求的三个层次