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.