需求跟踪矩阵如何使用?

需求跟踪矩阵的具体使用方法是什么？当前大多的需求跟踪矩阵是从某个子需求关联到各个文档中的某模块（或者某章节）、代码行等，像这样比较难以操作，有没有更好的、相对简单的操作方法？ 

需求跟踪矩阵的作用

系统研发的困难在于其未知性，未知带来的麻烦在于任何结果，事实上都不可能在工作开始时被明确界定与理解，这就是为什么任何行业的研发工作实际上都十分强调验证与确认工作的主要原因，你必须对之前的假设做最终的确认。

如果某项未知性工作非常短促，则整个工作过程中的概念就得以保留在人们的大脑里，形成完整的概念图谱；但如果工作规模大、周期长，则概念极易丢失。在进行各种验证与确认工作时，实则再也无人可承担这份工作。

需求跟踪矩阵的目的便在于此：

1、作为各个环节的负责人沟通的桥梁；

2、作为一根线条将概念与最终的实现串联在一起；

3、作为一种检验的手段，确认需求是否被实现（虽然不能保证没有错误）。

需求跟踪矩阵的有效使用原则

关于如何使用需求跟踪矩阵，一成不变的方法是不存在的，一旦我们理解了需求矩阵作为一种方法所要达到的目的后，我们就能理解：

1、不同的项目类型，需求矩阵所要跟踪的内容项不尽相同。

如，在绝大多数的信息系统中，由于其实现主要是由大量Class和Interface组成，考虑到高内聚低耦合的原则，需求矩阵只要关联到相关的Class就可以了（哪一个Class对应了某一个需求的实现）。

考虑到，不是所有的代码都能写的那么完美，适当的跟踪到某一个Class的某一个Function或者Method也是可行的，但是如果大多数都要跟踪到这个级别，实际上已经反映出系统的设计存在问题。因为一个Class原则上所承载的功能应该是相当内聚的。

2、跟踪的颗粒度到达某个功能进入的入口即可。

实际的软件系统，一个功能的实现往往是通过众多的Class、Interface、Method等的互相调用来完成的。考虑到大多数程序工程师都更乐意直接去理解代码，因此作为一种良好的沟通工具，需求矩阵维护了系统功能所对应的代码的起始入口，从而使得每个功能的代码从哪里开始变得清晰明了，没有歧义。

3、跟踪需要注意成本效益原则。

对于那些通用模块，如基础Class、通用Method等，依据项目实际情况，如果这些它们是十分重要且意义重大的，则可列入特殊跟踪；否则，在大多数情况下，是没有必要去跟踪的。。

以上三者是有效使用需求跟踪矩阵的原则和要点。在需求跟踪矩阵的实际运用过程中，实效性是异常重要的原则，不应为了跟踪而跟踪，而应该将这些信息作为系统的重要资产，只有对系统的设计、开发等工作意义重大的才予以追踪，从实际需求出发也是CMMI过程改进的一贯出发点。