Du kennst das Problem: Alle WorkItems eines bestimmten Typs sollen zu mindestens einem WorkItem eines anderen Typs verlinkt sein. Zum Beispiel jeder TestCase zur passenden Anforderung. Die Links zu setzen, ist mühsame Handarbeit. Zu überprüfen, ob jede Anforderung einen eingehenden Link hat und wenn, woher der kommt, ist noch mühsamere Detailarbeit sowohl im LiveDoc Editor als auch in speziellen Wikiseiten. Und außerdem würde man ja gern beim Lesen einer Anforderung im LiveDoc Editor mit einem Blick sehen wollen, wie sie getestet wird, und dafür nicht erst den WorkItem Properties Sidebar aufmachen und dann dort suchen müssen.

Technisch ist die Lösung natürlich einfach: Man verlinkt den TestCase mit der Anforderung und man setzt eine Cross-Referenz des TestCase-WorkItems in die Description der Anforderung. Organisatorisch ist das allerdings ein Alptraum: Kein Mensch kann garantieren, dass zu jedem Link eine Cross-Referenz eingetragen ist bzw. zu jeder Cross-Referenz ein Link existiert. Insbesondere in Zusammenhang mit Änderungen wird das Setzen oder Löschen des einen oder anderen schnell mal vergessen. Ein inkonsistentes System ist am Ende ein wertloses System.

Der Links Synchronizer schafft Abhilfe: In einem Polarion-Projekt legt man für das genannte Beispiel einmal fest, dass immer dann, wenn eine Cross-Referenz eines TestCase-Workitems in der Description eines Anforderungs-WorkItems auftaucht, ein Link einer bestimmten Link-Rolle, zum Beispiel tests, vom TestCase zur Anforderung gesetzt sein oder automatisch werden muss.

Damit verbunden ist die Festlegung, dass dann, wenn eine Cross-Referenz eines TestCase-Workitems in der Description eines Anforderungs-WorkItems nicht auftaucht, auch kein tests-Link vom TestCase zur Anforderung gesetzt sein darf, also gegebenenfalls gelöscht werden muss. Fazit: Man tut das, was der Transparenz im Projekt dient, nämlich die TestCases in den Anforderungen als Cross-Referenzen auflisten, den Rest macht der Links Synchronizer.