在管理需求的流程中，很多团队其实并不是不会写那些需求，而是写完之后，大家往往没办法说清楚这个需求是从哪里来的，具体由谁去负责做出来，要用什么测试来验证，以及变动以后会影响到哪些别的部分，这正是Polarion需求追溯这个功能需要去解决的问。因为Polarion这个系统本身就是把需求、变动、测试这些东西放在一起管的，所以需求、测试用例还有变更请求这些系统里的条目之间就可以建立起连接，从而能够支持从头到尾的追溯。

　　一、Polarion需求追溯怎么建立

　　想要把需求追溯建起来，这并不是简简单单地在两个条目之间加一个连接线，而是需要先把具体的追溯关系想明白，也就是说，到底哪些东西需要拉通来追，要追到哪一个层级，连接的关系叫什么名字，还有负责人平时怎么去管，这些事情都是需要提前定下来的。

　　1、先确定追溯对象

　　关于常见的追溯链，大家一般可以按照【客户需求】→【系统需求】→【软件需求】→【设计项】→【测试用例】→【测试执行结果】这个顺序去搭建，不过不同的项目也不一定非要完全一模一样，比如有些团队在实际操作时，还会把风险项、缺陷、变动请求以及代码提交记录这些东西也一起加进去；

　　2、设置条目类型和链接关系

　　在Polarion系统里面，大家常常用不同的条目来装需求、任务、测试用例和缺陷这些不同的东西，在建立追溯的时候，项目人员需要先去确认一下项目模板里面是不是已经自带了需求、系统需求、软件需求、测试用例还有缺陷这些分类；

　　同时，连接的关系也必须要统一起来，比方说，从上层需求到下层需求，大家可以使用派生或者是细化这类关系，而从需求到测试用例，则可以使用验证或者是被测试这类关系，至于需求到实现任务，就可以用实现来连接，这些具体的名称最后还是要看项目是怎么配置的，最关键的不是名字好不好听，而是团队内部每一个人都必须统一用一样的方法。

　　3、在文档或条目中建立链接

　　若是大家平时习惯在那种在线文档视图里维护需求，那就可以直接在文档页面里选中某个需求条目，然后再去添加它关联的其他对象，比较常见的做法是点进需求的具体细节页面，找到关联条目的区域，把目标需求、测试用例、任务或者缺陷加进去；

　　二、Polarion需求追溯链断开后怎么修复

　　在修复断开的链条时，大家要尽量避免“看到哪里缺了就随手补哪里”的做法，因为这种头痛医头的方法虽然短期内能看到效果，但长此以往只会把追溯关系越补越乱，正确的做法应该是先把断链的类型找出来，然后再按照定好的规则去批量地整理。

　　1、补齐缺失链接

　　要是确认了确实是需求没有关联到下层的东西，那大家就按照之前定好的追溯模型把它补齐，比方说客户需求要是少了系统需求，就把派生关系加上；软件需求要是少了测试用例，就把验证关系加上；需求做完了要是没有关联到开发任务，就把实现关系加上；

　　2、修正错误链接

　　要是发现连接的类型用错了，大家可以把那种普通的关联改成正确的验证、派生或者是实现关系，而要是发现连接的方向弄反了，那就需要先把错误方向的连接删掉，然后再重新去建立一个正确方向的连接，在这里大家千万不要只加一条对的却把错的也留着，不然以后在做影响分析的时候，系统就会出现重复的关系或者是给出误导人的结果；

　　3、建立定期检查机制

　　追溯链这种东西，可不是建完了之后就可以不管了的，因为需求的变动、测试用例的拆开、缺陷的关闭、还有版本的发布，这些动静都会影响到追溯的关系，所以项目里面最好要设置一些固定的检查时间点，比如在需求评审之前要检查上游的来源，测试设计做完了之后要检查测试的覆盖情况，发布之前则要检查从需求一直到验证结果的整条链路是不是完整的；

三、Polarion需求追溯链断开后怎么判断

追溯链断开的意思，并不一定代表着连接真的在系统里消失了，它也有可能是因为对象的状态变了，或者版本切换了，又或者是过滤的条件设错了，甚至是权限不够看不到，以及连接的方向弄反了才导致的，所以在动手修复之前，大家得先判断出来断开的地方究竟在哪里。

1、查看追溯矩阵是否缺项

大家可以通过追溯矩阵表格、在线报告或者是自己写查询语句去检查需求的覆盖情况，比如把所有的软件需求都筛选出来，看看这里面有哪些是没有关联测试用例的，有哪些测试用例是没有执行结果的，还有哪些系统需求没有对应到下层的软件需求；

2、检查链接方向和链接类型

有很多追溯断链的情况，并不是因为这两个东西没有关联，而是大家把连接的方向给做反了，比如本来应该由测试用例去验证需求的，结果大家在系统里却维护成了由需求去验证测试用例，虽然在页面上瞧着好像还有关联，但是当追溯报表按照固定的方向去查的时候，系统就查不出东西来了；

3、检查版本、分支和权限

如果项目里使用了基线、分支或者是集合这些功能，那么大家就必须要确认清楚自己现在看到的到底是哪一个版本，因为需求在某一个版本里面有连接，这并不代表在另一个版本里也能看到一模一样的链路，特别是在需求被复制了、或者是进行了分支开发、以及版本被冻结了之后，连接关系就很容易遇到“在当前视图里看不到”的尴尬情况；

　　总结

　　其实Polarion需求追溯的核心目的，就是把需求、设计、实现、测试、缺陷以及变更这些杂七杂八的东西都塞进同一条能够随时检查的链条里，大家在刚开始建立的时候要先定好追溯的模型，然后再把条目的类型和连接的关系统一起来。在修复的时候，则要把少了的关系补上、错了的关系改过来，并且把追溯检查这件事塞进平时的日常流程里，这样折腾好之后，关于Polarion需求追溯怎么建立以及Polarion需求追溯链断开后怎么修复这两个让人头疼的问题，以后才不会总是反反复复地冒出来了。