当项目里的需求越攒越多之后，光靠着文档和表格去维护它们之间的追踪关系，就会变得特别吃力。一条需求很可能会连着好几个用例、设计模块、测试用例，还有缺陷，要是背后没有一套统一的追踪机制，等到后面要去做变更影响分析，或者去查覆盖率的时候，都会耗掉大量的时间。Enterprise Architect这个工具，它支持从需求到设计，再到开发跟测试这一整条链路上的关联，通过关系连线、Traceability窗口，还有Relationship Matrix这些东西，来实现需求的追踪管理。

　　一、Enterprise Architect怎么管理需求追踪

　　需求追踪管理这件事，它的重点倒不是去建一大堆需求对象，而是要把上下游之间那些关系给完整地搭建出来。当需求被录进系统以后，应该尽快去把它跟分析、设计，还有测试这些对象之间的关联给建立起来。

　　1、把需求对象给创建出来

　　在项目浏览器里面，先选中那个打算用来放需求的目标包，然后点一下Add Element，去创建一个Requirement类型的元素，接着把需求的名称、编号、优先级，还有详细的说明内容都给填进去。如果项目的规模比较大，最好是提前就定好一套统一的命名规则，比如写成REQ_SYS_001、REQ_SW_001这样的格式，这样等到后面再去做检索和统计的时候，就会方便不少。

　　2、把需求之间的关联关系给建立起来

　　选中某一个需求对象之后，就可以去用工具箱里面的Trace、Realization，还有Dependency这一些关系连线，把它跟用例、设计阶段产生的类图、组件，或者是测试的对象给连接到一起。一般来说，系统的需求会往软件需求那边去建Trace这样的追踪关系，而软件需求呢，则往设计对象那一头去建Realization这种实现关系，这么一层一层地连下去，后面就可以沿着这条链路去逐层地追踪了。

　　3、利用Traceability窗口去检查整条链路

　　当你把某一个需求对象给选中的时候，去点一下Start菜单，然后顺着Explore找到Traceability，在这个窗口里面，就会显示出当前这个对象它向上的来源，还有向下的去向，这些关系里面会包含需求的来源、设计的实现、测试的验证，还有缺陷的关联。等到需求需要变更的时候，就可以很快地在这里看到，到底有哪些对象会受到牵连，在Enterprise Architect的官方功能说明里面，也是把Traceability这个视图，当成是做影响分析和覆盖率检查时一个很重要的工具。

　　4、把测试的关联也给建起来

　　等测试用例被创建好了之后，就可以通过Trace关系，或者是Verify这种验证关系，把它连到对应的需求对象上面去，这样做完的好处就是，等到测试执行的工作全部结束了以后，你就可以直接去查看，到底哪些需求是已经被验证过的，而哪些需求到现在还缺着测试覆盖。

　　二、Enterprise Architect需求追踪矩阵怎么生成

　　当项目的规模慢慢变大以后，光是去查看单个需求的追踪关系就已经不够用了，这个时候就需要通过矩阵这一种方式，去把整体覆盖的情况给统计出来。

　　1、把Relationship Matrix这个矩阵窗口给打开

　　在项目浏览器里面去选中需求所在的那个包，然后点一下Design菜单，顺着Impact找到Relationship Matrix，这个矩阵它能够把两类对象之间的关联关系给展示出来，比如需求跟用例之间的映射，需求跟设计之间的映射，或者是需求跟测试用例之间的映射情况。

　　2、去设置好源和目标的包

　　在矩阵的那个窗口当中，需要去指定一下Source Package和Target Package，源的那一侧一般会选需求包，而目标那一侧呢，就可以去选设计包、测试包，或者是其他跟分析有关的包，选好了以后，再去把需要统计的关系类型给勾上，比如Trace、Realization，或者是Dependency这些。

　　3、让它把追踪矩阵给生成出来

　　点一下Refresh按钮之后，矩阵里面就会自动去把关联的结果给显示出来，在这个矩阵当中，行代表的是源那一头的对象，列代表的是目标那一头的对象，要是行和列交叉的那个位置上冒出来了一个标记，那就说明这两个对象之间是有关系的，反过来说，那些还是空白的地方，就表示到现在为止，它们之间的追踪链路还没有被建立起来，用这种方式就非常适合去发现那些被遗漏的需求，还有缺失掉的测试。

　　4、把矩阵的结果给导出来

　　等到确认矩阵里面的内容都没有问题了，就可以通过它自带的导出功能，去生成一份Excel文件，或者是报告文件，这些材料可以直接拿去做评审，还有审计归档的时候用，通常在需求基线评审之前，都会把完整的追踪矩阵给导出一份来，拿来当作覆盖率的证明材料。

　　三、Enterprise Architect需求追踪结果怎么检查

　　当矩阵被生成出来了以后，还不能觉得里面只要有数据就万事大吉了，还得去检查一下这些追踪的质量到底怎么样，因为矩阵里面有东西，可不等于追踪就已经做完整了。

　　1、去检查一下有没有孤零零被丢在那里的需求

　　在矩阵里面去找一找那些根本就没有挂上任何关联的需求，如果某一条需求它既没有对应的设计去实现它，也没有测试去验证它，那通常就说明这条追踪链路上是存在着缺口的，得去把关联的关系给它补上。

　　2、去看一看有没有多余出来的关系

　　有一些需求在经过了好几轮的调整以后，会留下一些早就已经没有用了的设计关系，还有测试关系，这个时候就可以利用Traceability窗口，去一条一条地检查一下，把那些历史遗留下来的链路给找出来，免得它们干扰到后面的变更分析。

　　3、去核实一下覆盖率的统计情况

　　当需求的数量比较多了以后，就可以把Relationship Matrix和Model Search这两样东西结合起来用，去统计一下覆盖的具体情况，比如已经关联上了测试的需求有多少条、还没有关联上设计的需求有多少条，以及还没有被验证过的需求又有多少条，在评审之前最好是再去把矩阵刷新一遍，好确保那些最新加进来的对象也已经被统计进去了。

　　4、变更做完以后要重新去生成一次矩阵

　　每当需求、设计，或者是测试的对象发生了变动以后，原来那份矩阵是不会自己变成审计依据的，在每一次重大的版本发布、需求冻结，或者测试完成之后，都应该再去重新生成一次追踪矩阵，并且把对应版本的记录给保存下来。

　　总结

　　Enterprise Architect里面怎么去管理需求的追踪，以及需求的追踪矩阵又要怎么去生成，实际在操作的时候，应该是先去创建Requirement对象，然后再通过Trace、Realization，还有Verify这些关系，去把从需求到设计，再到测试的完整链路给建立起来，接着再利用Traceability窗口，去检查一下上下游之间的关系，最后通过Relationship Matrix，去把需求的追踪矩阵给生成出来，去发现那些覆盖的缺口和被遗漏的条目。平常还要记得定期去把矩阵给刷新一下，并且把各个版本的记录给留下来，这样做了以后，是能够大大提高需求变更分析的效率，还有审计检查的效率的。