需求跟踪矩阵RTM

假如说有如果

一、需求跟踪

在CMMI的需求管理过程域中，“专用目标1.4 维护需求的双向可跟踪性” 要求维护需求与工作产品之间的双向可追溯性，以保证完全处理了所有原始需求，以及所有低层需求都能够追溯到一个有效的源头。
但是在实际进行需求跟踪时，却存在很多问题：

• 维护工作量大。完整准确的写完一份需求规格说明已经很不容易了，有谁愿意把章节再拷贝粘贴到另一个文件里去；同理，设计说明和代码的规模更大，把模块名称也拷过去？过程中是不是还要维护？
  
• 跟踪关系复杂。用户需求跟踪软件需求、软件需求跟踪设计、设计跟踪开发等等，跟踪关系存在大量一对多、多对一、多对多的情况，即使使用自动化工具，建立复杂跟踪关系也是一项耗费精力的工作；
  
• 效益和必要性存疑。尽管保证原始需求被完全处理是非常重要的，但由于上述两条带来的管理成本，需求跟踪的效益究竟如何？当然需求跟踪对于评估需求变更的影响也十分有效，但由于很多组织内部对于需求变更的评估和控制同样做的也不到位，因此需求跟踪的必要性就更低了。
  

当然不能因噎废食，不能因为跑不了马拉松就连一米都放弃了。需求跟踪究竟实不实用？应该怎么用才能发挥最大化的效益？这需要根据组织实际情况制定切实可行的需求跟踪策略，在保证效益的同时用好这个有力的需求管理工具。
二、需求跟踪矩阵模板

下图是一个需求跟踪矩阵模板的示例。还是要多说一句，只有符合组织文化制度、管理理念、组织架构的方法和工具才是真正有效的，需求跟踪矩阵模板也是一样，仅仅依靠“拿来主义”是行不通的。



需求跟踪矩阵模板

需求跟踪从用户需求开始，跨越研制过程中的各个阶段，具体阶段及工作成果与选定的软件生命周期模型、研发流程有关，此处的阶段可以与WBS模板内的阶段保持一致。
用户需求可能来源于技术协议或者变更。功能性需求应保证在每个阶段都能跟踪到对应的工作成果，而非功能性需求至少应在一个阶段跟踪到工作成果。例如示例中“培训需求”就是一个特定的工作要求，只需要在验收交付阶段安排培训工作计划，形成培训签到表即可。跟踪到的工作成果应该在WBS中有对应的工作分解。
“一级分解”、“二级分解”：可以根据需求插入新列，增加下级分解；
“编号”：编号唯一，新增、删除、变更需求都不需要改变原始需求的编号；
“来源”：技术协议（或者任务书）、变更；
“需求状态”：只有已签署生效的技术协议或者已批准的变更申请中的需求才能列入需求跟踪矩阵；

• “已批准”：初始状态
  
• “进行中”：正在进行分析、设计、开发或测试
  
• “已测试”：已完成测试
  
• “已验收”：已通过外部验收
  

“变更状态”：原始、变更、新增、删除；
“工作成果（WBS）”：该工作成果在WBS中应有对应工作；
“名称”：各项工作成果中该用户需求所对应的需求分析内容、设计内容、代码模块、测试用例、验收测试用例的章节名称。
三、需求跟踪关系

一个较为完整的需求跟踪关系见下左图。用户需求双向跟踪软件需求与验收测试、软件需求双向跟踪软件设计与系统测试，软件设计双向跟踪软件开发与集成测试，软件开发双向跟踪单元测试，显然这个跟踪关系过于复杂了。



完整的以及简化的需求跟踪关系示例

简化后的需求跟踪关系见上右图。主要变化在于：

• 删除软件设计与软件开发跟踪集成测试与单元测试；
  
• 软件设计跟踪软件开发改为软件需求跟踪软件开发；
  
• 软件开发不再跟踪到软件代码而跟踪到软件开发计划或WBS即可。
  

实际上，简化的需求跟踪关系也可以采用分步推行的方式：首先保证用户需求跟踪到软件需求和验收测试；接着可以将软件需求跟踪到软件设计和系统测试；最后可以将软件需求跟踪到软件开发，并且只跟踪开发计划或WBS中是否安排了相应工作即可，不跟踪具体模块名称。



分步推行的需求跟踪

四、需求跟踪步骤

以前面的需求跟踪矩阵模板为例，需求跟踪的步骤为：

• 技术协议签署生效后，项目经理建立需求跟踪矩阵以及原始的用户需求；
  
• 在各阶段工作成果评审前，相应负责人填写对应的需求跟踪情况；
  
• 在阶段会议前，项目经理检查需求跟踪矩阵；
  
• 当发生需求变更时，项目经理更新用户需求情况；
  
• 在上述过程中，如果需求不一致，应及时上报问题。
  

需要说明的是，本文采用的模板示例主要用于用户需求层面的需求跟踪，要求写清楚每条用户需求，但跟踪到后续工作成果中，只需要写出对应章节号即可，因此在软件需求层面的跟踪控制粒度较粗。如果希望加强在软件需求层面的需求跟踪，则应该写清楚软件需求规格说明书中的每条软件需求，就不能只写章节号了，同时也应相应增加编号、需求状态、变更状态等字段。

槑槑

学习下