需求跟踪系列 II - 初级阶段

     在很多经历过程改进的团队，如通过CMM/CMMI评级的团队都用某种方式费了不小的力气实现了需求跟踪这个关键的Practice，但往往评估师往往对会指出团队在需求管理/跟踪上还是有欠缺，还是可提高。

     问题出在哪里呢？

     需求跟踪无法有效的进行导致无法对整个开发活动进行准确掌控，总结下来，问题根源在需求信息关联关系的建立方式上。
    常见的建立关联的方式有两种：一种“隐式关联”，即需求关联信息是隐含在各个文档中的，隐式地表明了需求之间的关系。
     在对应的各个信息层次，项目团队用编号标识信息模块，如需求编号、系统功能点、子系统编号、测试用例编号等等；并在书写文档时，标识需求条目之间对应关系，如该系统功能点是对应满足哪个需求，或又如该测试用例是对应哪个系统功能点。
      在项目的前期，开发人员在书写文档时会对需求模块进行标识，同时也标识对应关系。令人痛苦的是维护这样的信息标识和信息之间关联关系：虽然各人维护各自的文档容易，但调整后要向所有相关人员准确通知修改内容的工作耗时耗力，很多开发人员不愿做，或者是“忘了做”；利用需求的关联关系也不容易，关联关系的标识是在各个文档内部，需要在一系列文档中进行查找才能保证需求跟踪的完备性。更何况当需求的关联关系由于上文提及的原因不能及时更新、不能准确反映项目实际时，需要跟踪的意义更小。  

      需求跟踪矩阵（Requirement Traceability Matrix）是另一个建立需求关联的方式，这是一种“显式关联”。它的前提条件也是将在需求链中各个过程的元素加以编号，例如：需求的实例号，设计的实例号等等。通过编号，客户可以以矩阵的形式将表示两种信息之间的关系：在相关行（如需求）和列（如设计）的交叉点做上标记表示需求的关联性。

      这种方法在一个地方集中地体现了需求及其衍生物的关系，带来的问题也是很明显的：一是当开发中大型项目时，行和列的数目将迅速增长，用户会迷失在一个个很大的矩阵中；二是由于需求的内容和需求的关联是存储在不同的文件中，例如通常我们在word文档中写需求，用Excel表格表示跟踪矩阵，当用户对需求文档进行调整时，需要用户到对应Excel文件进行跟踪关系的调整。我遇到相当数量的公司是这样来规定流程，但很遗憾的是，很少有公司的开发团队能真正遵循这样的规定。问题是同样的，开发人员不愿意或者“忘了”去执行更新需求跟踪关系的流程。

现实很简单：即使流程的本意是好的，但实现方法上出了问题，造成开发人员不愿执行或“忘了执行”，这样的流程也是值得商榷的。