Sie kennen 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.

Noch ein Anwendungsbeispiel. Laut Automotive SPICE muss jede Systemanforderung durch geeignete Verifikationskriterien qualifiziert sein. Es kann Sinn machen, die Verifikationskriterien im Anforderungsdokument zu spezifizieren, in einem separaten Abschnitt zum Beispiel, oder in einem eigens dafür eingerichteten Dokument; in jedem Fall werden die Anforderungs-WorkItems zu ihren Verifikationskriterium-WorkItems verlinkt, Link-Rolle zum Beispiel is dimensioned by.

​​​​​​Im Bild oben ist der Anforderungs-WorkItem ein rotes O, was für Own Requirement entsprechend Automotive SPICE SYS.2 steht, und der Verifikationskriterium-WorkItem das gelbe Buchstabenpaar VC, was für Verification Criterion steht. Man sieht unter den WoktItem Properties, dass der Anforderungs-WorkItem zum Verifikationskriterium-WorkItem verlinkt ist. Man sieht allerdings auch, dass es gar nicht nötig ist, dem Link zu folgen, sondern dass es genügt, mit der Maus über die Cross-Referenz zum Verifikationskriterium-WorkItem in der Description des Anforderungs-WorkItems zu hovern, um alle Inhalte des wo auch immer liegenden Verifikationskriterium-WorkItem zu sehen.