TraceabilityAutomatisierte Nachverfolgbarkeit von Anforderungen
Verfasser: Stefan Frankeerstellt am: 15. Januar 2008
letzte Anderung: 17. Februar 2008
Traceability 2
Abstrakt
Die Nachverfolgbarkeit von Anforderungen
ist schon einige Zeit als Methode des Re-
quirements Engineering bekannt. Fur si-
cherheitskritische Systeme ist es sogar un-
erlasslich, dass alle Anforderungen nach-
vollziehbar implementiert wurden und je-
des Codestuck auf eine gultige Anforderung
zuruckgefuhrt werden kann [WN94]. Auch
das US-Verteidigungsministerium verlangt
bei Projekten von den Softwareherstellern
die Nachverfolgbarkeit von Anforderungen
bis hin zum Quelltext. Die vorliegende Ar-
beit gibt im ersten Abschnitt einen Uber-
blick uber das Thema. So wird auf Verbesse-
rungen eingegangen, die durch den Einsatz
von Traceability erreicht werden konnen.
Zu dem werden grundlegende Begriffe de-
finiert. Im sich anschließenden Abschnitt
wird erlautert, wie ein automatisiertes Ver-
fahren funktioniert. Das wird das PN-
Modell sein. Der dritte Abschnitt beschaftigt
sich mit den Optimierungsmoglichkeiten,
die fur das PN-Modell vorgeschlagen wur-
den. In einem weiteren Abschnitt werden
die Vor- und Nachteile des Verfahrens und
der Nachverfolgbarkeit von Anforderungen
allgemein diskutiert. Abschließend wird in
Abschnitt funf eine Zusammenfassung der
Ergebnisse gegeben.
Diese Arbeit entstand im Rahmen des
Hauptseminars „Requirements Enginee-
ring” im Studiengang Softwaretechnik an
der Universitat Stuttgart.
1 Einfuhrung, Definition,
Anwendungsgebiete
Wie schon oben beschrieben, sind ins-
besondere bei der Entwicklung von si-
cherheitskritischen Systemen Traceability-
Techniken nicht wegzudenken. Aber auch
Unternehmen, die Auftragsprojekte abwi-
ckeln oder sonstige Software entwickeln,
mussen grundlegende Techniken zur Nach-
verfolgbarkeit von Anforderungen imple-
mentieren, wenn sie zum Beispiel die CM-
MI Stufe 3 oder hoher erreichen wollen
[CH06]. Mit Traceability-Techniken konnen
laut Watkins und Neal einige Aspekte der
Softwareentwicklung verbessert werden. So
legen sie dar, dass sich die Kosten ei-
ner Anderung besser abschatzen lassen, da
schneller ersichtlich ist, welche anderen An-
forderungen von der Anderung betroffen
sind [WN94]. Außerdem werden ihrer Auf-
fassung nach Punkte wie Verifikation, Ge-
samtkosten und Kundenzufriedenheit posi-
tiv beeinflusst. Nicht nur fur die Software-
entwicklung konnen Traceability-Techniken
nutzlich sein, sondern ebenso fur die War-
tung von Software. Ein Wartungsingenieur
kann durch Verknupfungen zwischen den
Entwicklungsdokumenten und dem Quell-
text schneller in der Lage sein, das System
oder Systemteile zu verstehen.
Nach diesen allgemeinen Aussagen zum
Nutzen von Traceability, soll der Begriff an
dieser Stelle definiert werden. Eine in der
Literatur oft herangezogene Definition wur-
Traceability 3
de von Gotel und Finkelstein in [GF94] ge-
geben. Sie lautet wie folgt:
Requirements traceability refers to the abili-ty to describe and follow the life of a requi-rement, in both a forwards and backwardsdirection.
Die Definition sagt zum einen aus, dass ei-
ne Anforderung uber ihren gesamten Le-
benszeitraum nachvollziehbar sein soll und
zum anderen, dass dies in Bezug auf den
Softwareentwicklungsprozess in beide Rich-
tungen moglich sein soll. Mit der ForwardTraceability ist dann auch das Nachverfol-
gen von Anforderungen in auf die Spezi-
fikation folgende Dokumente gemeint, z.B.
Entwurf, Implementierung etc. Der Begriff
Backward Traceability bezeichnet den um-
gekehrten Weg, denn hierbei wird fur einen
Teil der Entwicklungsdokumente (z.B. ein
Codestuck) gepruft, auf welche Anforde-
rung es zuruck geht. Durch beide Techni-
ken konnen Fehler in einem Softwaresys-
tem aufgezeigt werden. So kann zum Bei-
spiel der Quelltext darauf kontrolliert wer-
den, ob es Codestucke gibt, die sich auf keine
Anforderung zuruckverfolgen lassen. Diese
sollten dann genauer untersucht werden, da
es sich um toten oder schadhaften Code han-
deln konnte. Andererseits konnen die Anfor-
derungen dahingehend uberpruft werden, in
wie fern diese bei der Implementierung be-
achtet wurden.
Es wurde im Zusammenhang mit der War-
tung angeschnitten, dass fur die Requi-
rements Traceability eine Form von Ver-
knupfung benotigt wird, mit der beispiels-
weise ein Codestuck zu einer Anforde-
rung zugeordnet werden kann. Diese Ver-
knupfungen werden Traceability Links ge-
nannt und sind wie folgt definiert.
Traceability Links sind Verknupfungen, zwi-schen Anforderungen und Artefakten derEntwicklungsdokumente.
Solche Verknupfungen mussen wahrend der
Entwicklung erstellt werden, d.h. entwe-
der muss der Entwickler sie manuell einge-
ben oder sie werden automatisiert erzeugt.
Bei der manuellen Erzeugung benutzt der
Entwickler meist Tabellenkalkulationspro-
gramme und tragt zu jeder Anforderung die
Abhangigkeiten zu anderen Anforderungen,
zu Teilen des Entwurfs oder des Codes von
Hand ein. Dieses Vorgehen ist sehr zeit-
aufwandig und fehlertrachtig [TN97]. Ei-
ne weitere Moglichkeit der manuellen Er-
zeugung der Traceability Links ist der Ein-
satz von speziellen Werkzeugen, die das Er-
stellen per Drag’n’Drop, Listen oder ahnli-
ches zulassen. Hierbei muss dann jedoch die
Entwicklung nahezu vollstandig in diesen
Werkzeugen vorgenommen werden.
Bei der automatisierten Erzeugung von
Traceability Links muss der Entwickler
nicht von Hand alle Entwicklungsdoku-
mente durchgehen, um die richtigen Ver-
knupfungen zu finden, sondern er bekommt
eine sortierte Liste angezeigt, in der die Tei-
le der Entwicklungsdokumente (Artefakte)
oben stehen, die am Wahrscheinlichsten mit
der Anforderung, die der Entwickler gera-
Traceability 4
de betrachtet, durch einen Traceability Link
verbunden sind. Der Prozess zur automa-
tisierten Erzeugung von Traceability Links
ist in Abbildung 1 aufgezeigt. Einem Al-
gorithmus werden alle Entwicklungsdoku-
mente und die Anfragen, meist Anforde-
rungen, als Eingabe gegeben. Die Entwick-
lungsdokumente werden in Artefakte zer-
legt. Wie diese Zerlegung ablauft, wird im
nachsten Abschnitt erlautert. Die Ausgabe
ist die schon angesprochene sortierte Liste
der Artefakte. Ein Entwickler muss nun die-
se Liste durchgehen und die Artefakte mar-
kieren, die wirklich eine Verknupfung mit
der Anforderung bilden.
Abbildung 1: Vorgehen bei der automatisierten
Verfolgbarkeit
Tryggeseth und Nytro haben in [TN97] die
automatisierte und manuelle Erstellung der
Traceability Links gegenuberstellt. Wie Ta-
belle 1 zeigt, sind sie der Ansicht, dass
die Erstellungs- und Wartungskosten fur
die automatisierte Erzeugung niedrig sei-
en. Zumindest bei den Erstellungskosten
muss jedoch bedacht werden, dass bei vie-
len Traceability-Werkzeugen ein hoher Auf-
wand betrieben werden muss, um die Doku-
mente in die Werkzeuge einzugeben.
Cleland-Huang nennt in [CH+07] weite-
re Nachteile der manuellen Erstellung. So
spricht sie das Problem der Degenerati-
on der Verknupfungen an. Projektteams,
die unter Zeitdruck geraten, halten die-
se Verknupfungen womoglich nicht aktu-
ell. Außerdem weist sie auf Offshoring- und
Outsourcing-Effekte hin, wodurch es zusatz-
lich erschwert werde, Traceability Links
manuell zu erzeugen. Letztlich wurden auch
keine projektbegleitenden Dokumente, wie
Prasentationen oder ahnliches, mit einbezo-
gen, schreibt sie. Deshalb beschaftigen sich
Forscher heute mit Verfahren, die den Pro-
zess der Erzeugung von Traceability-Links
automatisieren.
2 Automatisierte
Nachverfolgbarkeit
(PN-Modell)
Um die Nachverfolgbarkeit von Anforderun-
gen zu automatisieren, mussen die mogli-
chen Traceability-Links zu einer Anforde-
rung aus den Entwicklungsdokumenten
herausgesucht werden. Da bei dieser Suche
genau die Artefakte herausgefiltert werden
sollen, die am Besten zur Anforderung
passen, werden Information-Retrieval-
Algorithmen eingesetzt. Neben dem im
Folgenden vorgestellten Probabilistic-
Network-Modell (PN-Modell) gibt es weitere
Ansatze, beispielsweise das Vector-Space-
Modell [LFOT06]. Bei allen Verfahren wird
versucht die Wahrscheinlichkeit einer Ver-
knupfung anhand der Haufigkeit und der
Traceability 5
Kriterium Manuell eingefugt Automatisiert erzeugt
Erstellungskosten Hoch Niedrig
Wartungskosten Hoch Niedrig
Korrektheit zu viele Verknupfungen fehlende Verknupfungen
Speicherplatz zusatzlicher Speicherplatz zusatzlicher oder kein Speicherplatz
Flexibilitat Hoch Hoch
Tabelle 1: Vergleich der Ansatze zur Traceability-Link-Erzeugung
Verteilung von Wortern oder Wortgruppen
in den Dokumenten zu berechnen. Dieses
Kapitel stutzt sich insbesondere auf die
Publikationen [CH+05a], [CH+05b] und
[CH+07] von Cleland-Huang et al.
Zunachst sollen an dieser Stelle die Be-
griffe Artefakte, Indexterme und Anfragen
beschrieben werden, da diese in der Fol-
ge oft verwendet werden. Artefakte sind,
wie schon oben angesprochen, Teile der Ent-
wicklungsdokumente, also zum Beispiel die
Anforderung ”The System shall display a
map of the district.“ Die Indexterme werden
aus den Artefakten gewonnen und reprasen-
tieren den Informationsgehalt der Artefak-
te. Anfragen sind Teile der Entwicklungsdo-
kumente fur die Traceability Links gefun-
den werden sollen.
Das PN-Modell wird am folgenden Beispiel
beschrieben werden. Bei dem Beispielsys-
tem handelt es sich um ein System zur Pla-
nung und Unterstutzung des Winterdiens-
tes. Es lasst sich grob in zwei Teile gliedern.
Zum einen befindet sich auf jedem Fahr-
zeug ein Monitor zur Navigation und In-
formationsanzeige und zum anderen befin-
det sich in der Zentrale des Winterdienstes
eine Kontrolleinheit, mit der beispielsweise
Arbeitsauftrage verschickt werden konnen.
Das Beispiel (in der Folge Winterdienstbei-
spiel genannt) besteht aus sieben Artefak-
ten:
d0 = ”All trucks shall display a map of the deicing route.“
d1 = ”A route shall be placed for each work order.“
d2 = ”The System shall display a map of the district.“
d3 = ”NetworkMap“
d4 = ”DistrictMap“
d5 = ”public void sendWorkOrder(Route deIcingRoute)“
d6 = ”public void displayDistrictMap(District district)“
Die ersten drei Artefakte sind Anforderun-
gen. Es folgen zwei Klassennamen und die
beiden letzten Artefakte stellen Methoden
aus dem Code dar. In einem ersten Schritt
werden die Indexterme aus den Artefakten
gewonnen. Bei diesem Prozess werden in
Textdokumenten sogenannte Stopp-Worter,
das sind haufig auftretende Worter, ent-
fernt. Im Beispiel waren das Worter wie
all, a, the, of etc. Außerdem werden in die-
sem Schritt die verbleibenden Worter in ih-
re grammatikalische Grundform gebracht.
Beispielsweise das Verb placed in d1 wird zu
place. Wenn es sich bei dem Dokument um
ein UML-Diagramm oder auch Codestuck
Traceability 6
handelt, dann werden Klassen-, Methoden-
oder Attributnamen aufgetrennt. Aus dem
Klassennamen NetworkMap werden dann
die Worter Network und Map. Dies kann je-
doch nur ausgefuhrt werden, wenn entspre-
chende Konventionen fur die Benennung ge-
nutzt wurden. Aus einem Quelltext werden
insbesondere Schlusselworte der Program-
miersprache entfernt, z.B. in Artefakt d5
und d6 die Worter public und void.
Das PN-Modell lasst sich als gerichteter,
azyklischer Graph darstellen. In der Abbil-
dung 2 ist der Graph fur die Artefakte d2
und d4 aufgezeichnet. Dabei sind die Kno-
ten Indexterme ti und Artefakte di. Die Kan-
ten gehen immer von Indextermen aus in
Richtung der Artefakte und stellen dar, dass
ein Indexterm in einem Artefakt enthalten
ist. Genau genommen sind die Kanten auch
gewichtet, da Indexterme in einem Arte-
fakt mehrfach auftauchen konnen, aber die
Indexterme paarweise disjunkt sein sollen
[CH+05b]. Am Beispiel (Abbildung 2) sieht
man, dass beispielsweise das Artefakt d2 aus
den Indextermen system, display, map und
district aufgebaut ist und d4 aus map und
district.
Abbildung 2: Beispielgraph fur PN-Modell
In einem nachsten Schritt konnen Anfra-
gen gestellt werden. Das Artefakt d0 aus
dem Winterdienstbeispiel wird im Folgen-
den als Beispielanfrage q herangezogen. Ziel
ist es, zu dieser Anfrage q eine sortierte
Liste der verbleibenden Artefakte zu finden
und zwar in der Weise, dass die Artefakte,
die mit der Anfrage am wahrscheinlichsten
einen Traceability Link bilden, in der Lis-
te weiter oben auftauchen. Cleland-Huang
bedient sich hierbei der Arbeit von Wong
und Yao. Sie geben in [WY95] eine Berech-
nungsvorschrift an, die die Wahrscheinlich-
keit zuruckgibt, in wie weit der Informati-
onsgehalt in einer Anfrage mit dem in ei-
nem Artefakt ubereinstimmt. Um den Grad
der Ubereinstimmung zu berechnen werden
die Indexterme genutzt. Die Gleichung lau-
tet wie folgt:
P (d|q ∩ T ) = P (d∩q∩T )P (q∩T )
Dabei ist d ein Artefakt, q die Anfrage und
T die Menge an Indextermen. Wong und
Yao geben eine Approximation an, um die-
se Wahrscheinlichkeit berechnen zu konnen.
Sie argumentieren, dass die Wahrschein-
lichkeiten fur d und q unabhangig von ein-
ander und nur unter Einbeziehung der In-
dexterme berechnet werden konnen.
P (d|q ∩ T ) ≈ P (d|T )P (q|T )P (T )P (q|T )P (T )
Des Weiteren wird nun die Menge der Index-
terme durch eine Summation uber die Men-
ge der Indexterme herausgezogen:
P (d|q ∩ T ) ≈Pk
i=1 P (d|ti)P (q|ti)P (ti)Pki=1 P (q|ti)P (ti)
(1)
Cleland-Huang nimmt diese letzte Definiti-
on fur ihren Algorithmus her. Sie definiert
die Wahrscheinlichkeiten P (d|ti), P (q|ti)
Traceability 7
und P (ti) uber die Auftretungshaufigkeit
der Indexterme in den Artefakten bzw. An-
fragen:
P (d|ti) = Anzahl der Vorkommen ti in dAnzahl an Indextermen in d
P (q|ti) = Anzahl der Vorkommen ti in qAnzahl an Indextermen in q
P (ti) = 1Anzahl an Artefakten in denen ti vorkommt
Die Wahrscheinlichkeiten P (d|ti) und P (q|ti)stellen also die relative Haufigkeit des Auf-
tretens eines Indexterms in einem Artefakt
bzw. einer Anfrage dar. Betrachtet man nun
den Zahler in Gleichung 1, so kann man
erkennen, dass fur alle Indexterme, die in
der Anfrage oder dem Artefakt nicht ent-
halten sind, der entsprechende Summand
Null wird. Haben Anfrage und Artefakt kei-
nen einzigen gemeinsamen Indexterm, er-
gibt sich der Zahler und damit die gesamte
Gleichung zu Null. Dies entspricht der In-
tuition, dass bei Ungleichheit aller enthalte-
ner Worter auch der Grad der Ubereinstim-
mung Null sein sollte.
Diese Berechnungsvorschrift soll nun auf
das Winterdienstbeispiel angewendet wer-
den. Dazu wird als Anfrage weiterhin q (”All
trucks shall display a map of the deicing rou-
te.“) verwandt und als Artefakt d4 (”District-
Map“). Wie oben beschrieben, mussen fur
den Zahler nur die Summanden berechnet
werden, fur die der Indexterm in Anfrage
und Artefakt vorkommen. In diesem Fall ist
das der Indexterm map.
P (d|map) = 12
P (q|map) = 15
P (map) = 15
Damit ergibt sich fur den Zahler ein Wert
von 150 (1
2 ·15 ·
15 ). Der Nenner wird berechnet
indem man fur jeden Indexterm das Produkt
P (q|ti)·P (ti) aufsummiert. Fur das Beispiel
ist der Nenner 3875 (1
5 · [1 + 12 + 1
5 + 12 + 1
3 ]). Zu-
sammengenommen ergibt sich so eine Wahr-
scheinlichkeit, dass das Artefakt d4 mit der
Anfrage q einen Traceability Link bilden
konnte von 0, 039 ( 150 ·
7538 ). Fuhrt man diesen
Algorithmus fur alle Artefakte des Winter-
dienstbeispiels aus, so erhalt man eine sor-
tierte Liste der Artefakte, welche in Tabelle
2 einzusehen ist.
In einem letzten Schritt muss ein Entwick-
ler manuell auswahlen, welches Artefakt
zusammen mit der Anfrage einen Tracea-
bility Link darstellt. Um diese Aufgabe zu
erleichtern, wird die Ergebnismenge auf ei-
ne uberschaubare Anzahl beschrankt. Da-
zu wird ein Schwellenwert definiert, der an-
gibt, ab welchem Wahrscheinlichkeitswert
Artefakte auf der Ergebnisliste angezeigt
werden. Wird dieser in unserem Beispiel
auf 0, 04 gesetzt, wurden die Artefakte d3
und d4 nicht mehr in der Ausgabe erschei-
nen. Ein solches Ausschließen von Artefak-
ten aus dem Ergebnis halt zum einen die Er-
gebnismenge klein, was es dem Entwickler
erleichtert, die richtigen Artefakte zu mar-
kieren, birgt auf der anderen Seite aber die
Gefahr, dass Artefakte, die trotz einer nied-
rigen Wahrscheinlichkeit einen Traceability
Link mit der Anfrage bilden, ausgeschlossen
werden.
Traceability 8
Artefakt Beschreibung P (di|q)d5 ”public void sendWorkOrder(Route deIcingRoute)“ 0,077
d2 ”The System shall display a map of the district.“ 0,069
d1 ”A route shall be placed for each work order.“ 0,066
d6 ”public void displayDistrictMap(District district)“ 0,055
d3 ”NetworkMap“ 0,039
d4 ”DistrictMap“ 0,039
Tabelle 2: Sortierte Ausgabeliste fur das Winterdienstbeispiel
Es werden bei den Information-Retrieval-
Algorithmen deshalb zwei Metriken zur Be-
wertung der Gute des Ergebnisses definiert.
Das ist einmal die Recall-Metrik, welche den
Quotienten aus der Anzahl der relevanten
Artefakte, die in der Ergebnismenge vor-
handen sind, und der Anzahl aller relevan-
ten Artefakte beschreibt. Diese Metrik ist
trivialerweise dann 100%, wenn alle Arte-
fakte im Ergebnis vorhanden sind. Die zwei-
te Metrik, die Precision-Metrik, ist der Quo-
tient aus der Anzahl der relevanten Arte-
fakte, die in der Ergebnismenge vorhanden
sind, und der Anzahl der Artefakte in der
Ergebnismenge. Diese Metrik ist trivialer-
weise dann 100%, wenn nur relevante Arte-
fakte im Ergebnis auftauchen.
Recall =Anzahl der relevanten Artefakte, die in der Liste vorhanden sind
Anzahl aller relevanten Artefakte
Precision =Anzahl der relevanten Artefakte, die in der Liste vorhanden sind
Anzahl der Artefakte in der Liste
Da bei allen Information-Retrieval-
Algorithmen das Ziel verfolgt wird, dass
die Ergebnismenge ausschließlich alle re-
levanten Artefakte enthalt, wird versucht
beide Metriken simultan zu maximieren. In
der Literatur wird bei einem Recall-Wert
von etwa 90% von einem Precision-Wert
von etwa 20% berichtet, d.h. ein Entwickler
wird in der Ergebnismenge unter funf an-
gezeigten Artefakten nur eines finden, dass
einen Link mit der Anfrage bildet.
3 Ergebnisoptimierung
Die Optimierung der Ergebnisse aus dem
Basisalgorithmus (vorheriger Abschnitt)
kann auf zweierlei Arten geschehen. Zum
einen kann man Verbesserungen an dem
Algorithmus selbst vornehmen und zum
anderen konnen die Eingabedaten, also
die Dokumente, so verandert werden, dass
der Algorithmus bessere Ergebnisse liefert.
Zunachst wird in diesem Kapitel auf zwei
mogliche Verbesserungen der Berechnung
eingegangen, welche von Cleland-Huang in
[CH+05b] vorgestellt wurden. Anschließend
werden einige Punkte angesprochen, die bei
der Dokumenterstellung beachtet werden
sollten. Diese sind dem Artikel [CH+07]
entnommen.
Traceability 9
3.1 Optimierung der Berechnung
Bei der Analyse der Wahrscheinlichkeiten,
die mit dem Basisalgorithmus errechnet
wurden, ist den Forschern aufgefallen, dass
bei hohen Wahrscheinlichkeiten in nahe-
zu jedem Fall ein Traceability Link zwi-
schen Anfrage und Artefakt vorliegt, genau-
so wie es bei sehr kleinen Wahrscheinlich-
keiten nicht der Fall ist. Der eigentlich pro-
blematische Bereich ist der Bereich dazwi-
schen. Um diesen abzugrenzen, fuhrt man
zwei Schwellenwerte ein, einen fur die ho-
hen Wahrscheinlichkeiten und einen fur die
niedrigen. Alle Artefakte mit Wahrschein-
lichkeiten uber dem hohen Schwellenwert
kommen direkt in die Ergebnismenge, al-
le unter dem unteren Schwellenwert wer-
den nicht weiter beachtet. Auf die Artefak-
te mit Wahrscheinlichkeiten zwischen den
Schwellenwerten wird fur die Optimierung
das großte Augenmerk gelegt, da Verbesse-
rungen an dieser Stelle den meisten Nutzen
fur das Gesamtergebnis bringen.
Prinzipiell laufen beide im Folgenden be-
schriebenen Verfahren so ab, dass zunachst
eine Anfrage mit dem Basisalgorithmus be-
arbeitet wird und dann die Artefakte mit
Wahrscheinlichkeiten zwischen den Schwel-
lenwerten in einem weiteren Schritt mit
dem erweiterten Algorithmus bearbeitet
werden. Fur diesen zweiten Schritt muss
dann wieder ein Schwellenwert definiert
werden, der die Artefakte trennt. Einmal
in die Menge, die zur Ergebnismenge dazu
kommt und die, die weggeworfen wird.
3.1.1 Hierarchische Erweiterung des
PN-Modells
Spezifikationen, Entwurfe und Implemen-
tierungen sind eigentlich immer hierar-
chisch gegliedert. In solchen Hierarchien
stecken in den meisten Fallen Informatio-
nen, die bei der Verfolgbarkeit von Anfor-
derungen wichtig sein konnen. Im Winter-
dienstbeispiel ist beispielsweise die Anfrage
q (”All trucks shall display a map of the dei-
cing route.“) mit dem Artefakt d1 (”A route
shall be placed for each work order.“) uber
einen Traceability Link verbunden. Mit dem
Artefakt d2 besteht keine Verknupfung, da
es sich bei d2 um eine Anforderung fur das
Kontrollsystem in der Zentrale handelt, die
jedoch einige Indexterme mit der Anfrage
gemein hat. Der Basisalgorithmus gibt da-
durch falschlicherweise an, dass das Arte-
fakt d2 eher als das Artefakt d1 ein Tra-
ceability Link fur q ist (vgl. Tabelle 2). In
dieser Situation kann durch das Einfugen
von Hierarchieinformation das Ergebnis op-
timiert werden. Seien folgende Hierarchien
im Winterdienstbeispiel vorhanden:
Onboard System
q = ”All trucks shall display a map of the deicing route.“
Onboard System
d1 = ”A route shall be placed for each work order.“
Control Center
d2 = ”The System shall display a map of the district.“
Nun kann der Algorithmus durch Ein-
beziehung der Hierarchie in die Berech-
Traceability 10
nung das Ergebnis dahingehend verbes-
sern, dass die Wahrscheinlichkeiten solcher
Anfrage/Artefakte-Kombinationen, die ahn-
liche oder gleiche Vorganger besitzen, sich
erhohen, wahrend sich die Wahrscheinlich-
keit fur Artefakte, deren Vorganger kei-
ne Ubereinstimmung mit den Vorgangern
der Anfrage hat, verkleinert. Im Beispiel
heißt das also, dass das Artefakt d1 einen
hoheren Wahrscheinlichkeitswert erhalten
wird und das Artefakt d2 einen niedrige-
ren. Die Berechnungsvorschrift des Basisal-
gorithmus muss dafur entsprechend erwei-
tert werden:
P (d|q ∩ T ) ≈Plg=pa(d)
Pki=1 P (d,g|ti)P (q|ti)P (ti)Pk
i=1 P (q|ti)P (ti)
Die Summe∑l
g=pa(d) geht uber alle El-
tern des Artefaktes d und bindet so die
Hierarchieinformationen in die Berechnung
ein. Ebenfalls werden die Berechnung der
beiden Wahrscheinlichkeiten P (d, g|ti) und
P (q|ti) in sofern angepasst, dass zusatzlich
die relativen Haufigkeiten des Indexterms ti
in den Vorgangern des Artefaktes d addiert
werden.
Cleland-Huang gibt in [CH+05b] die Recall-
und Precision-Metrik fur drei verschiede-
ne Systeme an, auf die der Basisalgorith-
mus und die hierarchische Erweiterung an-
gewandt wurden. Die Ergebnisse sind in
Tabelle 3 zusammengefasst. Alle Systeme
sind nicht besonders groß. Das großte (Ice
Braker System - IBS) hat gerade einmal
72 Klassen in 18 Paketen und 180 Anfor-
derungen. Dieses ist das Referenzsystem
von Cleland-Huang. Das Winterdienstbei-
spiel basiert auf diesem System. Das Event-
Based Traceability-System (EBT) kommt
auf 60 Klassen in 8 Paketen und 54 An-
forderungen. Mit 25 Klassen in 5 Paketen
und 36 Anforderungen ist das Light Control-
System (LC) das kleinste System.
Wie man in Tabelle 3 sehen kann, verbessert
sich die Precision-Wertung fur IBS und EBT
um elf bzw. ein Prozent. Jedoch tritt bei LC
eine Verschlechterung um etwa ein Prozent
ein, was leider von der Autorin nicht ange-
sprochen wird. Stattdessen werden die star-
ken Zuwachse bei IBS hervorgehoben und
zu EBT wird ausgefuhrt, dass die Hierar-
chieinformationen nicht sehr aussagekraftig
und Paketnamen unglucklich gewahlt sei-
en.
3.1.2 Clustering
Neben der Moglichkeit der Einbindung der
Hierarchie kann auch die Neigung der Tra-
ceability Links zur Clusterbildung zur Op-
timierung herangezogen werden. Eine An-
forderung hat oft Traceability Links zu ei-
ner Reihe von Artefakten, die eng bei einan-
der liegen (beispielsweise ein Unterkapitel
im Entwurf). Ebenso hat auch ein Artefakt
oft Links zu einer Reihe von Anforderungen,
die logisch zusammengehoren. Diese beiden
Richtungen bezeichnet Cleland-Huang als
artefaktseitiges und anforderungsseitiges
Clustering. Die logischen Cluster mussen je-
doch definiert werden. Entweder geschieht
Traceability 11
Algorithmus IBS EBT LC
Recall Precision Recall Precision Recall Precision
Basis 90.47% 20.43% 90.97% 17.75% 90.11% 37.61%
Hierarchisch 90.48% 31.72% 90.87% 18.30% 90.11% 36.77%
Clustering 90.00% 30.20% 89.77% 14.99% 90.11% 37.61%
Tabelle 3: Recall- und Precision-Werte bei verschiedenen Systemen
dies per Hand oder automatisch. Fur die
automatische Erzeugung schlagt Cleland-
Huang vor, die Hierarchie zu nutzen. In-
wieweit sich das Clustering dann noch vom
hierarchischen Ansatz abhebt, lasst sie of-
fen.
Die Vorgehensweise bei der Methode ist
relativ einfach. Fur alle Artefakte, deren
Wahrscheinlichkeit mit dem Basisalgorith-
mus im Optimierungsbereich liegt, wird
der Durchschnittswert aller Artefakte in
dem jeweiligen Cluster genommen und ge-
gen einen gesonderten Schwellenwert ge-
pruft.
If pr(dj|q) > ThresholdHigh then
retrieve pair dj,q
else
if pr(dj|q) > ThresholdLow
and sum[pr(dk|q)]/Nk >
ThresholdEnhanced then
retrieve pair dj,q
else
reject pair dj,q
end
end
Auch bei diesem Algorithmus reagiert IBS
am Starksten (Tabelle 3), namlich mit zehn
Prozent. Hier wird der Precision-Wert von
EBT geringer, was die Autorin wieder un-
kommentiert lasst. Der Wert fur LC andert
sich uberhaupt nicht. Cleland-Huang gibt
noch einige allgemeine Probleme mit den
Systemen an, die zu niedrigen Werten
gefuhrt haben sollen. Beispielsweise werden
im EBT-System gleiche Worte mit mehreren
verschieden Bedeutungen verwendet.
3.2 Verbesserung der Dokumente
Cleland-Huang beschreibt in ihrer Publika-
tion [CH+07] unter anderem einige Best
Practices zur Erstellung von Entwicklungs-
dokumenten, die sich positiv auf die auto-
matisierte Verfolgbarkeit auswirken. So be-
schreibt sie in einem ersten Punkt, dass ein
wohldefiniertes und in allen Dokumenten
eingesetztes Begriffslexikon aus Sicht der
Traceability hochst wertvoll sei. Wenn ein
Wort in den Dokumenten mit verschiede-
nen Bedeutungen genutzt wird, dann kann
ein automatischer Prozess den Bedeutungs-
unterschied nicht erkennen. Des Weiteren
sollen Anforderungen korrekt, nicht mehr-
deutig, vollstandig, konsistent, uberprufbar,
verstandlich, identifizierbar etc. sein. Be-
Traceability 12
sonders hebt sie die Vollstandigkeit und die
Pragnanz hervor.
Bezogen auf die hierarchische Erweiterung
des PN-Modells fordert sie schließlich auch,
dass eine aussagekraftige Hierarchie in den
Dokumenten eingefugt werden solle. Außer-
dem geht sie noch auf die semantische Dis-
krepanz zwischen verschiedenen Domanen
der Projektbeteiligten ein. So sprechen und
schreiben Kunden, Entwickler, Marketing
und Management uber den gleichen Sach-
verhalt mit vollig unterschiedlichem Voka-
bular. Sie schlagt hier eine Art Matcher vor,
der das domanenspezifische Vokabular mit
dem einer anderen Domain verbindet.
4 Bewertung der automatisierten
Nachverfolgbarkeit
Die Ergebnisse in Tabelle 3 sind in gewis-
ser Hinsicht ernuchternd, zeigen sie doch,
dass in der Ergebnismenge gerade einmal
zwischen 15 und 40 Prozent der Artefak-
te einen wirklichen Link mit der Anfrage
bilden, d.h. ein Entwickler muss aus einer
großen Menge an Artefakten eine kleinere
Menge herausfiltern. Dass sich dabei auch
Fehler einschleichen, bleibt unvermeidlich.
Da hilft auch die Tatsache nicht, dass die
Precision-Metrik uber die Ergebnismenge
nicht gleichverteilt ist. Die oberen 5% der
Liste haben einen Precision-Wert von uber
50% [CH+07], wahrend der Wert fur den
Rest weit darunter liegt. Es werden an die-
ser Stelle noch weitere Optimierungen des
Verfahrens benotigt, um die Precision-Werte
weiter zu verbessern und es so dem Ent-
wickler zu erleichtern, die richtigen Artefak-
te herauszufiltern.
Im Zusammenhang mit den Ergebnissen
fallt auch auf, dass die bisherigen Optimie-
rungen nur auf ein System Wirkung gezeigt
haben. Wie sich dadurch zeigt, ist die au-
tomatisierte Verfolgbarkeit derzeit ebenso
von der Gute der Entwicklungsdokumente
abhangig, wie vom Algorithmus selbst. Dar-
aus folgt unweigerlich, dass automatisier-
te Traceability-Techniken nur in Projekten
sinnvoll eingesetzt werden konnen, die ein
Mindestmaß an strukturierten, vollstandi-
gen und wohldefinierten Entwicklungsdo-
kumenten pflegen. Eine miserabel gefuhr-
te Dokumentation verwehrt sich durch
schlechte Precision-Resultate einer automa-
tisierten Losung. Aber auch dem ersten Ein-
druck nach fur gut befundene Dokumen-
te konnen Probleme auslosen. Beispielswei-
se durch mehrere Bedeutungen eines Wor-
tes oder grundverschiedene Blickpunkte auf
das System in verschiedenen Entwicklungs-
dokumenten. Sollen also in einem Projekt
automatisierte Traceability-Techniken zum
Einsatz kommen, dann muss der Doku-
mentation besondere Aufmerksamkeit gege-
ben werden, um gute Ergebnisse zu erzie-
len.
Die mit dem PN-Modell und dessen Erwei-
terungen gewonnenen Precision-Ergebnisse
decken sich mit den Ergebnissen anderer
Traceability 13
Information-Retrieval-Algorithmen, zum
Beispiel dem schon angesprochenen Vector-
Space-Modell. Wie De Lucia und Kollegen in
[LFOT06] beschreiben, erreicht dieser Algo-
rithmus ebenfalls etwa 25% Precision, wenn
der Recall-Wert bei 90 Prozent liegt. Gene-
rell wird heute davon ausgegangen, dass ein
Precision-Wert zwischen 15 und 40 Prozent
mit verschiedenen Techniken erreicht wer-
den kann [CH+05a],[HDSH04],[LFOT06].
Wie schon argumentiert werden Verfahren
benotigt, die bessere Ergebnisse liefern. De
Lucia sieht hier jedoch kaum Moglichkeiten
und rat eher zu einer Diskussion, wie-
viele Traceability Links wirklich benotigt
werden.
Ganz abgesehen von Bewertungen mit den
Metriken stellen sich weitere Fragen, die ei-
ne Beantwortung verlangen. Ein in der For-
schung haufig ubersehenes Problem besteht
darin, dass sich Entwickler sehr ungern von
Werkzeugen, mit denen sie vertraut sind,
losen wollen. Viele heutige Traceability-
Werkzeuge verlangen, dass die Entwicklung
komplett mit diesen Werkzeugen durch-
gefuhrt werden muss. Es gibt nur wenige
brauchbare Importmoglichkeiten. Im Zwei-
felsfall mussen sogar von Hand Daten ein-
gefugt werden. Dass zudem Dokumente so
redundant vorliegen und gepflegt werden
mussen, wird von den Werkzeugerstellern
kaum beachtet oder angesprochen. Insofern
mussen sich neue Implementierungen in die
heterogene Werkzeuglandschaft einer Orga-
nisation einbetten lassen.
Die automatisierte Verfolgbarkeit von An-
forderungen lasst sich zusammenfassend
als eine Technik charakterisieren, die die
manuelle Erstellung von Traceability Links
zwar nicht ersetzt aber unterstutzt, in dem
fur eine Anforderung eine Menge nahe-
liegender Artefakte herausgefiltert werden,
mit denen diese verknupft sein konnte. Al-
len beschriebenen Unzulanglichkeiten zum
Trotz ist das schon eine Verbesserung zum
komplett manuellen Vorgehen.
5 Fazit
Softwaresysteme werden in Zukunft immer
komplexer. So wird es in der Entwicklung
und insbesondere in der Wartung schwieri-
ger, solche Systeme im Ganzen oder in Tei-
len zu verstehen. Traceability kann an die-
ser Stelle helfen, in dem Codestucke mit
den Entwurfsdokumenten und diese wieder-
um mit den Anforderungen verknupft sind.
Speziell die automatisierten Techniken, die
in dieser Arbeit vorgestellt wurden, konnen
Entwicklern helfen, diese Traceability Links
einfacher zu finden. Dennoch sind die Er-
gebnisse noch nicht gut genug, um automa-
tische Losungen zu implementieren. Es wird
in der Zukunft noch einige Arbeit auf die-
sem Gebiet notwendig sein, damit die Vor-
teile, die Requirements Traceability bietet,
flachendeckend bei der Softwarebearbeitung
genutzt werden konnen.
Traceability 14
Literatur
[CH+05a] CLELAND-HUANG, J. u. a.: Goal-Centric Traceability forManaging Non-Functional Requirements. In: Procee-dings of the 27th IEEE International Conference on Soft-ware Engineering (2005), Mai, S. 362ff.
[CH+05b] CLELAND-HUANG, J. u. a.: Utilizing Supporting Evi-dence to Improve Dynamic Requirements Traceability.In: Proceedings of the 13th IEEE International Confe-rence on Requirements Engineering (2005), September, S.135ff.
[CH06] CLELAND-HUANG, J.: Just Enough Requirements Tra-ceability. In: 30th Annual International Computer Soft-ware and Applications Conference 1 (2006), September, S.41ff.
[CH+07] CLELAND-HUANG, J. u. a.: Best Practices for AutomatedTraceability. In: IEEE Computer 40 (2007), Juni, Nr. 6,S. 27ff.
[GF94] GOTEL, O. ; FINKELSTEIN, A.: An Analysis of the Re-quirements Traceability Problem. In: Proceedings of theFirst International Conference on Requirements Enginee-ring (1994), April, S. 94ff.
[HDSH04] HAYES, Jane H. ; DEKHTYAR, Alex ; SUNDARAM, Sent-hil K. ; HOWARD, Sarah: Helping Analysts Trace Re-quirements: An Objective Look. In: Proceedings of the12th IEEE International Conference on Requirements En-gineering (2004), September, S. 249ff.
[LFOT06] LUCIA, Andrea D. ; FASANO, Fausto ; OLIVETO, Rocco ;TORTORA, Genoveffa: Can Information Retrieval Techni-ques Effectively Support Traceability Link Recovery? In:Proceedings of the 14th IEEE International Conference onProgram Comprehension (2006), Juni, S. 307ff.
[TN97] TRYGGESETH, E. ; NYTRO, O.: Dynamic TraceabilityLinks Supported by a System Architecture Description.In: International Conference on Software Maintenance(1997), Oktober, S. 180ff.
[WN94] WATKINS, R. ; NEAL, M.: Why and How of RequirementsTracing. In: IEEE Software 11 (1994), Juli, Nr. 4, S. 104ff.
[WY95] WONG, S. ; YAO, Y.: On Modeling Information Retrievalwith Probabilistic Inference. In: ACM Transactions onInformation Systems (TOIS) 13 (1995), Januar, Nr. 1, S.38ff.