在图2跟踪模型中,箭头代表的是跟踪的方向,模型表明,不仅在需求定义的领域跟踪需求,而且我们也在实现领域和测试领域跟踪需求。

  在系统定义领域,包括有三个方向的跟踪:从业务需求到产品特性的跟踪;从用例到产品特性的跟踪;从变更的需求到产品新特性的跟踪。对于每一种跟踪,我们都可以使用类似于如下的一个表格来管理。在实际项目中,要做好需求的跟踪管理并非易事,也许我们可以使用电子表格,办公软件来协助处理,确实,它们对于项目的管理非常有用。

  但是,表格的问题在于难于维护,特别是当项目较大,存在复杂的关联关系的情况,改变一个链接可能涉及到很多相关的链接,在这种情况下,维护成了一场噩梦。

  在这种情况下,我们要么简化需求跟踪处理,对大的模块进行跟踪;要么使用专门的需求管理工具。如果是大型项目,好使用工具来进行管理。这样,在我们面临需求变更的时候,才能有备无患。

  因时而变,做好需求变更控制

  如前文所述,变化总是避免不了的。变更天生是软件过程的一部分。在这种情况下,我们需要建立一个管理变更的过程,使得变更的工作得到控制,并能高效的发现变更,进行影响分析,将变更有效的集成到现有系统中。

  产生需求变更的因素包括内部因素和外部因素,不管需求变更来自哪里,都需要遵循一个既定的流程来提出变更请求。

  这样的渠道根据实际的企业情况有各自的方案。一般说来,如果是来自客户的变更,都需要遵照一个固定流程,通过一种正式的方式提交。即使客户口头的提出,那么也需要通过会议记录、文件交由客户签字确认后才正式进入变更流程。

  否则,如果在没有正式依据下进行需求变更,这样的项目将进入无休止的修改和维护状态。

  对于提出的变更请求,首先可以通过项目小组指派专人负责进行分析,包括该变更的可行性分析,对其他需求的影响分析,对项目进度的影响分析等。在这个过程中,需要利用前文中所述的各种需求跟踪表格。

  通过需求跟踪表格,列举出该变更所涉及需要修改的其他需求,影响的其他用例、测试用例、用例实现等。然后才可以对工作量进行估算,评估该变更的可行性以及对项目进度影响等。

  变更开发结束之后,也需要组织相关人员对变更进行评审,这样的评审往往能发现不少潜在的问题,比如有遗漏的需求没有修改等。只有评审通过后,才能进入下一阶段,对变更相关的文档、产品进行维护,使得需求文档、设计文档、产品保持一致性。至此,整个需求变更过程结束。

  需求变更管理是需求管理中的一个重要部分,只有有效的需求变更管理提才能高产品的可能性,并使终产品更接近于解决需求,提高了用户对产品的满意度,从而使产品成为真正优质合格的产品。从这层意义上说,需求变更管理是产品质量的基础。

  笔者通过对需求开发、需求跟踪和需求变更过程三个方面对需求的变更管理进行讨论。一方面希望能引起业界对需求管理的关注,另外也希望能借此抛砖引玉,引发各位方家对需求管理方面的讨论。

  管理变更步骤:

  ● 提出变更请求
  ● 变更分析
  ● 变更评审
  ● 制定变更计划
  ● 变更需求的开发
  ● 变更结果评审
  ● 维护变更

  跟踪需求变更的问题:

  ● 谁提出变更;
  ● 什么时候提出变更;
  ● 变更的内容是什么;
  ● 为什么变更;
  ● 变更处理意见;
  ● 变更执行结果。