Tag-basierte Verfahren zur effizienten Nutzung von Videos im ...

Gottfried Wilhelm
Leibniz Universität Hannover
Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Software Engineering
Tag-basierte Verfahren zur effizienten Nutzung von
Videos im Requirements Engineering
Bachelorarbeit
im Studiengang Informatik
von
Michael Gaier
Prüfer: Prof. Dr. Kurt Schneider
Zweitprüfer: Prof. Prof. Dr.-Ing. Bodo Rosenhahn
Betreuer: Dipl.-Inform. Stefan Gärtner
Hannover, 4. Oktober 2012

Zusammenfassung
Die viedo-basierte Anforderungserhebung ist eine Ergänzung zur klassischen
Anforderungserhebung. Die in der klassischen Anforderungserhebung textuell beschriebenen
Szenarien, werden in Videosequenzen dargestellt. Diese Darstellungen sind besonders bei
Szenarien, die einen komplexen Sachverhalt schildern oder bei denen ein hohes Domänenwissen
erforderlich ist, oftmals leichter zu verstehen als eine reine textuelle Beschreibung. Da für den
Erfolg eines Projektes die Anforderungen eine große Rolle spielen, ist es wichtig diese verständlich
zu beschreiben um mögliche Interpretationsfehler zu vermeiden. Jedoch verursacht ein videobasiertes
Vorgehen zusätzlichen Aufwand und wird somit nur selten eingesetzt.
Um den Einsatz eines video-basiereten Vorgehens für eine größere Menge von Projekten
interessanter zu gestalten, schlage ich ein Empfehlungssystem, das den Aufwand beim
Zusammenstellen der Videosequenzen minimiert, vor. Dieses ist insbesondere bei Szenarien, die
sich nur in wenigen Abschnitten unterscheiden, hilfreich. Auf Basis zuvor erstellten
Videosequenzen werden dem Anforderungsingenieur beim Erstellen einer neuen Sequenz
Vorschläge für den möglichen Aufbau gemacht. Diese beschleunigt die Zusammenstellung und
ermöglicht es die begrenzte Zeit besser zu nutzen.

Inhaltsverzeichnis
1 Einleitung 3
1.1 Motivation.................................................................................................................................3
1.2 Zielsetzung................................................................................................................................4
1.3 Gliederung................................................................................................................................4
1.4 Rahmenbedingungen und Umfeld............................................................................................5
1.5 Einführung in das Beispielszenario..........................................................................................5
2 Grundlagen 7
2.1 Begriffserklärungen..................................................................................................................7
2.2 Suchmaschinen.........................................................................................................................8
2.3 Video-basierte Anforderungserhebung.....................................................................................8
2.4 Empfehlungen...........................................................................................................................9
3 Interne Repräsentation von Artefakten 11
3.1 Domain-Index.........................................................................................................................11
3.2 Bedingungen...........................................................................................................................15
3.2.1 Tag-Cloud-Bedingungen.................................................................................................16
3.2.2 Kausale-Tag-Bedingungen..............................................................................................18
4 Empfehlungssystem für die video-basierte Anforderungserhebung 19
4.1 Empfehlungsprozess...............................................................................................................19
4.1.1 Suche nach relevante Kanten..........................................................................................19
4.1.2 Ranking der relevanten Kanten.......................................................................................21
4.1.3 Suche passender Artefakte..............................................................................................23
4.1.4 Ranking der relevanten Artefakte....................................................................................23
4.2 Tag-Austausch.........................................................................................................................23
6 Umsetzung und Demonstration 26
6.1 Programmoberfläche...............................................................................................................26
6.2 Artefakt-Tagging.....................................................................................................................27
6.3 Empfehlungen.........................................................................................................................28
6.4 Tag-Austausch.........................................................................................................................31
7 Fazit und Ausblick 32
A Literatur Verzeichnis 34
B Abbildungsverzeichnis 35
C Inhalt der CD 36

1 Einleitung
1 Einleitung
1.1 Motivation
Beim Erstellen von Softwaresystemen ist eine enge Zusammenarbeit zwischen Kunde und
Anforderungsingenieur wichtig, um die Kundenwünsche und Ideen bestmöglich zu erfassen und im
späteren System umzusetzen. Eine mangelhafte Anforderungserhebung gefährdet den Erfolg des
Projektes [17]. Der Kunde möchte so wenig Zeit wie möglich in die Anforderungserhebung
investieren, da er dafür seine normalen Tätigkeiten unterbrechen muss. Der Anforderungsingenieur
muss in der zur Verfügung stehenden Zeit eine möglichst gute Erhebung durchführen.
Im bestmöglichen Fall hat der Kunde genaue Vorstellung, wie das spätere System auszusehen hat
und es gelingt ihm das System präzise und für den Anforderungsingenieur verständlich zu
beschreiben. In der Regel ist das aber nicht der Fall. Oftmals hat der Kunde nur eine vage
Vorstellung und benötigt die Unterstützung des Anforderungsingenieurs. Bei dieser
Zusammenarbeit entstehen einige Dokumente, die das gewünschte System beschreiben. Diese
Dokumente können für den einfachen Kunden schwer verständlich sein, da diesem oftmals die
benutzten Notationen fremd sind. Deswegen müssen die in den Dokumenten beschriebenen
Szenarien für den Kunden übersetzt werden. Damit dieser das erarbeitete Modell versteht und
mögliche Änderungen benennen kann.
Einfacher wäre es eine Notation zu finden, die sowohl einfach verständlich als auch für die weitere
Entwicklung nutzbar ist. Forschungen haben ergeben, das der Einsatz von Videos diesem Zweck
dienen kann [14]. Die in Videos dargestellten Szenarien sind für den Kunden leicht verständlich,
bieten aber auch dem Ingenieur genug Informationen um das gewünschte System zu erstellen.
Jedoch ist ein video-basiertes Vorgehen deutlich aufwendiger als die klassische Variante und somit
nur für wenige Projekte interessant [4]. Deswegen werden unterstützende Werkzeuge benötigt, die
den Zusatzaufwand mindern und somit die video-basierte Anforderungserhebung für eine breitere
Projektmenge einsetzbar machen.
1.2 Zielsetzung
Diese Arbeit beschäftigt sich weder mit dem Vorgang des Tagging noch mit dem genauen Ablauf
einer video-basierten Anforderungsanalyse. Sondern es werden Methoden untersucht, die den
Zusatzaufwand der video-basierten Anforderungserhebung gegenüber der klassischen
Anforderungsanalyse reduzieren und somit ein größeren Anreize für die Nutzung einer videobasierten
Anforderungserhebung bieten [4]. Die zwei wesentlichen für die Arbeit interessanten
Arbeitsschritte der video-basierten Anforderungserhebung sind das Drehen der einzelnen
Handlungen und die Generierung der abschließenden Videosequenz, die ein Systemmerkmal
beschreibt.
Die in dieser Arbeit vorgestellten Konzepte, unterstützen den Ingenieur bei der Generierung der
Videosequenzen. Ihm wird die lästige Suche nach benötigten Abschnitten abgenommen und somit
kann die gewonnene Zeit für wichtigere Zwecke genutzt werden.
Bei den vorgestellten Methoden handelt es sich zum einen um ein Empfehlungssystem, welches
automatisch Videoclips auf Grundlage zuvor erstellter Sequenzen aus der Bibliothek auswählt und
als mögliche Bestandteile der neuen Sequenz vorschlägt, zum anderen wird eine Möglichkeit
vorgestellt, mit der Abschnitte, die eine zuvor genannte Bedingung erfüllen, durch andere
Seite 4 von 37

1 Einleitung
ausgetauscht werden können. Dadurch können Sequenzen effizienter an neue Situationen angepasst
werden. Dieses ist insbesondere am Anfang der Anforderungserhebung interessant, wenn die
benötigten Videoclips noch nicht vorhanden sind. Anstelle der Videoclips können Skizzen und
Fotos als Platzhalter genutzt werden, die dann im späteren Verlauf einfacher durch die
vorgesehenen Videoclips ersetzt werden können.
1.3 Gliederung
Im ersten Kapitel wird diese Arbeit motiviert und es werden gewünschten Ziele genannt. Zusätzlich
wird kurz das Umfeld mit den vorhandenen Rahmenbedingungen beschrieben und eine Einführung
in das Beispielszenario gegeben. Das zweite Kapitel beschäftigt sich mit den Grundlagen, die für
das bessere Verständnis hilfreich sind. Im dritten Kapitel werden die benötigten Datenstrukturen
vorgestellt für die Methoden, welche im Kapitel 4 behandelt werden, vorgestellt. Das fünfte Kapitel
zeigt die Auswirkungen der Implementierung der in Kapitel 4 vorgestellten Methoden auf den
Vision Catcher und es werden anhand von Beispielen die Funktionsweise der Modifikation gezeigt.
Im letzten Kapitel wird ein Ausblick über zukünftige Forschung gegeben und die Ergebnisse
zusammengefasst.
1.4 Rahmenbedingungen und Umfeld
Diese Bachelorarbeit baut auf der Masterarbeit[9,12] von Kitzmann auf, in der ein Werkzeug für die
video-basierte Anforderungserhebung und Validierung entwickelt wurde. Bei diesem Werkzeug
handelt es sich um den Vision Catcher (siehe Abbildung 1). Der Vision Catcher ist im Vergleich zu
Xrave[4] besonders auf low-effort Ansatz zugeschnitten. Er ermöglicht es aus multimedialen
Elementen Artefakte zu erstellen, diese in Szenarien anzuordnen und wiederzugeben. Eine Gruppe
von Szenarien, die ein System beschreibt, wird in Projekten zusammengefasst. Zudem besitzt es
noch weitere Funktionen, die allerdings für das Verständnis dieser Arbeit nicht relevant sind. Dieses
Werkzeug wird um neue Funktionen, welche genauer in Kapitel 5 vorgestellt werden, erweitert.
Seite 5 von 37

1 Einleitung
Abbildung 1: Die GUI des Vision Catcher mit einem Beispielszenario vor der Modifikation
1.5 Einführung in das Beispielszenario
Die in den folgenden Beispielen zugrunde liegenden Szenarien stammen aus dem Bereich des
Bankenwesens. Insbesondere eignen sich die Szenarien aus dem Online-Banking, da diese
allgemein verständlich sind. Zusätzlich existieren im Online-Banking durch die Einführung der
neuen TAN-Verfahren eine Variation des Überweisungsvorganges, welche die Stärken des
Empfehlungssystem verdeutlichen.
Seite 6 von 37

2 Grundlagen
2 Grundlagen
2.1 Begriffserklärungen
Ontologie (Definition nach [8]) Eine Ontologie ist eine Menge von abbildenden Primitiven mit
denen eine Wissensdomäne modelliert wird. Die abbildenden Primitiven sind in der Regel Klassen,
Attribute und Beziehungen.
Szenario (Definition nach [9]) Ein Szenario ist eine Abfolge von Interaktionsschritten, die ein
konkretes Beispiel für die Erfüllung oder Nichterfüllung eines oder mehrerer Ziele darstellen.
Tag (Definition nach [10]) Ein Tag ist ein Term, der zu einer Information zugewiesen wird. Dieser
Term beschreibt die ihm zugewiesene Information.
Hinweis zur Notation: Tag werden in Abbildungen als Ellipsen dargestellt,
Artefakt (Definition nach [9]) Ein Artefakt ist ein mit Metadaten versehenes multimediales
Element (Audio, Video, Bild, . . . ). Metadaten bestehen aus Tags und den möglichen Beziehungen
zu anderen Artefakten.
Artefakte stellen die Interanktionsschritte im Szenario dar. Hinweis zur Notation: Artefakte werden
in Abbildungen als Rechtecke dargestellt, ∣Artefakt∣:= Anzahl der Tags des Artefaktes .
Tag-Klasse (Definition) Eine Tag-Klasse ist eine Gruppe von Tags, die gemeinsame Eigenschaften
teilen.
In dieser Arbeit wird sich auf den Einsatz der folgenden fünf unterschiedlichen Tag-Klassen, die die
unterschiedlichen Tags eines Artefaktes anhand des beschriebenen Elementes zusammenfassen,
beschränkt, da diese für die vorgestellten Konzepte ausreichend sind.
Klasse
Domäne
Tags der Klasse Domäne sind pro Artefakt einzigartig. Sie unterteilen die Menge aller
Artefakte in einer Bibliothek in Hauptkategorien. Zudem legen sie die Interpretation
der anderen Tags, insbesondere die Objekt- und Aktionstags, fest. Somit werden
Konflikte im Verständnis, die aufgrund von Mehrdeutigkeiten der Tags entstehen,
aufgelöst. Das Wort Bank zum Beispiel kann entweder eine Sitzgelegenheit oder ein
Geldinstitut bezeichnen. Es gibt noch eine Menge solcher Wörter die je nach Umfeld
eine andere Bedeutung annehmen. Jedes Artefakt muss einer Domäne zugeordnet
werden.
Subdomäne Die Subdomäne-Tags bieten eine Möglichkeit, die in Hauptkategorien unterteilten
Artefakt weiter zu verfeinern. Mögliche Subdomäne-Tags für den Bereich
Bankenwesen sind zum Beispiel die verschiedenen Geldinstitute.
Objekt
Objekttags stellen die im Artefakt auftauchenden Objekte dar.
Seite 7 von 37

2 Grundlagen
Beispiel: Login, Überweisungsformular
Aktion
Medientyp
Aktionstags beschreiben die im Artefakt durchgeführten Handlungen.
Beispiel: Anmelden(Einloggen), Überweisen
Medientyp-Tags beschreiben die Art des multimedialen Elementes eines Artefaktes.
Sie sind wie die Domäne-Tags pro Artefakt einzigartig und jedes Artefakt muss ein
solches Tag tragen.
Beispiel: Video, Abbildung, Skizze
Gerichteter Graph (Definition nach [11]) Ein gerichteter Graph G ist ein Tupel (V,E), wobei V
eine nicht leere Menge von Knoten und E⊆V xV eine Menge von gerichteten Kanten ist.
Information Retrieval (kurz: IR) (Definition nach [7]) Das Information Retrieval ist der
Vorgang des Findens von unstrukturiertem Material, das ein bestimmtes Informationsbedürfnis
befriedigt, aus einer großen Materialkollektion.
2.2 Suchmaschinen
Eine Suchmaschine ist ein System, welches eine große Menge an Daten für einen spezifischen Term
durchsucht und eine Liste zu dem Term passender Daten liefert [7]. Der Einsatz von Suchmaschinen
ist vor allem im Internet beliebt. Das Internet bietet eine riesige Menge an Informationen, deren
effiziente Nutzung ohne Suchmaschinen aufgrund der großen Datenmenge nicht möglich ist. Die
bekannteste Suchmaschine mit einem Marktanteil von über 80% ist Google [12]. Neben den
allgemeinen Suchmaschinen wie Google, deren Hauptaufgabe die Informationssuche ist, gibt es
noch spezielle Suchmaschinen. Diese werden auf Plattformen eingesetzt, die einen anderen Dienst
anbieten, aber aufgrund der großen Menge an Inhalt auf den Einsatz einer Suchmaschine
angewiesen sind. YouTube (http://www.youtube.com/), Flickr (http://www.flickr.com/), IMDb
(http://www.imdb.com/) oder Wikipedia (http://www.wikipedia.org/) sind nur einige Beispiele.
Die Funktionsweise einer Suchmaschine ist im Allgemeinen immer gleich. Jede Suchmaschine
besitzt eine Menge an Objekten, die Informationen enthalten. Diesen Objekten werden
Schlüsselwörter zugeordnet, die in der Regel aus den Objekten selbst extrahiert werden. Einem
Objekt kann mehr als ein Schlüsselwort zugeordnet werden. Besteht ein Informationsbedürfnis, so
kann durch die Angabe einer Kombination von Schlüsselwörtern die Objekte, die das
Informationsbedürfnis befriedigen, aus der Objektmenge selektiert werden.
2.3 Video-basierte Anforderungserhebung
Die video-basierte Anforderungserhebung ist eine Ergänzung zur Anforderungserhebung. Bei der
video-basierten Anforderungserhebung werden die Systemanforderungen und -merkmale des
gewünschten Systems nicht durch Texte beschrieben sondern in Videosequenzen dargestellt.
Insbesondere bei komplexen Systemmerkmalen ist die Darstellung in einer Videosequenz oftmals
leichter zu verstehen als eine textuelle Beschreibung [2].
Bei den eingesetzten Videos muss es sich nicht um konsistente mit hohen Aufwand erstellte
Sequenzen handeln. [14] zeigt, dass selbst ein schlichtes Video, das mit einem geringen Aufwand
Seite 8 von 37

2 Grundlagen
erstellt wurde, zum Verständnis des Systems beitragen kann. Zudem hat der low-effort Ansatz, bei
dem es nicht darauf ankommt eine einwandfreie Videosequenz zu erstellen, die auch zu
Werbezwecken eingesetzt werden kann, den Vorteil. Die Sequenzen werden aus vorhandenen
Abschnitten, welche unter anderem auch aus anderen Projekten stammen können. Damit wird die
Menge an benötigten Videoclips reduziert und es müssen nur noch die fehlenden Abschnitte neu
erstellt werden.
Insbesondere für dieses Vorgehen eignen sich die hier vorgestellten Konzepte.
2.4 Empfehlungen
Um möglichst wenig Zeit für die video-basierte Anforderungserhebung zu Nutzen ist es von Vorteil
Videoclips wiederzuverwenden und die benötigten Szenarien aus verschiedenen kleinen Clips, die
nur wenige Interaktionen zeigen, zusammenzusetzen. Dadurch entsteht eine Bibliothek mit vielen
Artefakten, die einzelne Handlungen oder Objekte darstellen, aus denen die gewünschten Szenarien
sich zusammensetzen lassen. Diese Bibliothek enthält eine große Menge an Artefakten, weil für
jede Handlung oder jedes Objekt, das in einem Szenario vorkam, mindestens ein Artefakt
vorhanden ist.
Betrachtet man alle möglichen Artefakt-Paare, die man in einer Bibliothek mit N verschiedenen
Artefakten bilden kann, so ist in der Regel die Menge aller logisch sinnvollen Paare deutlich
geringer, weil nicht auf jedes Artefakt jedes andere Artefakt folgt.
Es ist von Vorteil, wenn für das aktuelle Szenario unpassende Artefakte automatisch aussortiert
werden. Dadurch verkleinert sich die Menge an relevanten Artefakten und somit auch der zeitliche
Aufwand bei der Generierung eines Szenarios. Je besser das Selektieren der relevanten Artefakte
ist, desto mehr Zeit lässt sich einsparen.
Beispiel 1:
Gegeben sei eine Bibliothek mit 100 verschiedenen Artefakten, wobei jedes Artefakt 20 logisch
sinnvolle Partner besitzen soll. Gesucht wird der Aufwand, der als Anzahl der betrachteten
Artefakte bis zum Finden des gesuchten Artefakts, das für die Fortsetzung ein gegebenes Szenario
benutzt wird, gemessen wird, unter Berücksichtigung vier verschiedener Selektionsarten: keine
Selektion, optimale Selektion(nur die 20 sinnvollen Artefakte), fehlerhafte Selektion(die 20
sinnvollen +10% nicht sinnvolle Artefakte) und unvollständige Selektion(20 empfohlene Artefakte
und in 60%(Vergleichbarer Mean Avergage Precision von Suchmaschinen für die Top-20)[5] der
Fälle ist das gesuchte Artefakt unter den Empfehlungen).
Findet keine Selektion statt, so müssen für jedes Artefakt im Szenario im Mittel 50 Artefakte
betrachtet werden, wenn man davon ausgeht, dass die Wahrscheinlichkeit für das Finden des
gesuchten Artefaktes gleichverteilt ist.
Die optimale Selektion zeigt nur die 20 logisch sinnvollen Partner an und somit liefert diese
Selektionsart das beste Ergebnis mit 10 Artefakten im Mittel.
Die fehlerhafte zeigt die 20 logisch sinnvollen an. Hinzukommen noch zwei nicht sinnvolle
Artefakte. Insgesamt werden also 22 Artefakte vorgeschlagen, was einen Aufwand von 11
Artefakten entspricht.
Die letzte Selektionsart ist die unvollständige Selektion. Bei dieser Selektionsart gibt es zwei
Seite 9 von 37

2 Grundlagen
mögliche Fälle. Entweder das gesuchte Artefakt ist unter den 20 Empfehlungen, was auf 60% der
Fälle zutrifft, oder das gesuchte Artefakt ist nicht darunter und somit müssen die restlichen
Artefakte in der Bibliothek nach dem gewünschten Artefakt durchsucht werden. Im Mittel werden
bei dieser Selektionsart 26 Artefakte betrachtet bis das gesuchte Artefakt gefunden wird.
Keine Selektion Optimale Selektion Fehlerhafte Selektion unvollständige
Selektion
50 Artefakte 10 Artefakte 11 Artefakte 26 Artefakte
Durch den Einsatz einer der drei Selektionsarten lässt sich im Beispiel 1 eine 50-80%
Aufwandsminimierung erreichen.
Ist die Anzahl relevanter Artefakte nicht bekannt, was in der Regel der Fall ist, lässt sich dafür ein
Schätzwert nehmen. Im folgenden Beispiel 2 wird ein pauschaler Wert für die Anzahl relevanter
Artefakte angenommen und der Aufwand bei verschiedenen Trefferwahrscheinlichkeiten (das
gesuchte Artefakt befindet sich unter den Empfehlungen) untersucht. Die Wahrscheinlichkeit, dass
es sich bei einem Artefakt um das gesuchte Artefakt handelt, soll wie zuvor gleichverteilt sein.
Beispiel 2:
Trefferwahrscheinlichkeiten: p Formel für den Aufwand:
Anzahl empfohlener Artefakte:
γ f ( p)= p∗γ+(1− p)∗N
Anzahl Artefakte in der Bibliothek: N
Wie im Beispiel 2 soll die Bibliothek N =100 Artefakte beinhalten, die Anzahl empfohlener
Artefakte sei γ=20 und die Selektionsart ist die unvollständige Selektion.
Seite 10 von 37

2 Grundlagen
Aufwandsbetrachtung
Empfelungen vs keine Empfehlungen
Anzahl im Mittel betrachteter Artefakte
60
50
40
30
20
10
0
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1
Keine Empfehlungen
Empfehlungen
Trefferwahrscheinlichkeit p
Abbildung 2: Aufwand von Empfehlungssystemen bei verschiedenen Trefferwahrscheinlichkeit
In Abbildung 2 ist zu erkennen, dass für eine Trefferwahrscheinlichkeit von 60%, was für ein IR-
System ein erreichbarer Wert ist [5], eine Aufwandshalbierung einsetzt.
Empfehlungen verringern den Suchaufwand nach geeigneten Artefakten, die für die Fortsetzung ein
gegebenes Szenario benutzt werden können und somit wird weniger Zeit für das Erstellen der
Szenarien benötigt. In der Praxis ist eine optimale Selektion, die das beste Ergebnis liefert, nicht
erreichbar.
Seite 11 von 37

3 Interne Repräsentation von Artefakten
3 Interne Repräsentation von Artefakten
3.1 Domain-Index
Der Domain-Index repräsentiert die Artefakt-paare, die in den verschiedenen Szenarien eingesetzt
wurden. Er speichert zu einem gegebenen Artefakt die Artefakte, die als direkte Nachfolger in
einem Szenario benutzt wurden. Dabei werden nicht die Artefakte an sich indiziert, sondern deren
repräsentative Tags. Dieses schafft eine flexiblere Darstellung und die Indizes können von der
Bibliothek unabhängig eingesetzt werden. Zudem werden nicht alle Tags indiziert. Nur die Aktionsund
Objekttags, die den größten Änderungen innerhalb eines Szenarios unterliegen, werden
indiziert. Zusätzlich muss die Domäne beachtet werden. Die erstellten Szenarien weisen eine enge
Bindung zur Domäne auf und die gespeichert Information ergebt unter einer anderen Domäne
durchaus keinen Sinn. Dieses wird durch das Anlegen von verschieden Indizes, für jede Domäne
einen, gelöst. Dieses hat unter anderem auch den Vorteil, dass die Verarbeitung dieser Indizes auf
Grund der geringeren Datenmenge wesentlich leichter ist.
Am einfachsten lässt sich der Index als ein gerichteter Graph ohne weitere Einschränkungen
auffassen. Die Knoten des Graphen sind die Aktions- und Objekttags der Artefakte. Die Kanten
stellen die Übergangsbeziehungen der Artefakte in einem Szenario dar, dass heißt: Existiert eine
Kante im Graph von Knoten 1 zu 2, so ist in einem Szenario ein Artefakt, das mit 2 getaggt ist, der
direkte Nachfolger eines Artefaktes, welches das Tag 1 enthält.
Im folgenden wird ein Beispielszenario, bestehend aus zwei Artefakten und den entsprechenden
Graphen dazu an, betrachtet. (Hinweis zur Notation: Artefakte werden als Rechtecke und Tags als
Ellipsen dargestellt. Ist ein Artefakt mit einem Tag markiert, so befindet sich das Tag innerhalb des
Rechteckes.)
Beispiel 1:
Gegeben sei ein Szenario bestehend aus zwei Artefakten mit jeweils einem Tag. Im
Szenario(Abbildung 3) folgt auf das Artefakt A1, welches das Tag Objekt@Login enthält, das
Artefakt B2 mit dem Tag Objekt@Hauptseite.
Abbildung 3: Szenario bestehend aus den Artefakten A1 und B2
Abbildung 4: Graph zu dem Szenario in Abbildung 3
Wird der Graph aus Abbildung 4 um ein weiteres unabhängiges Szenario (Abbildung 3), das aus
Artefakt A1 und Artefakt B2 besteht, erweitert, so wird im Graph eine weitere Kante von
Seite 12 von 37

3 Interne Repräsentation von Artefakten
Objekt@Login nach Objekt@Hauptseite hinzugefügt. Um die Darstellung zu vereinfachen und die
Menge an Kanten zu beschränken, werden gleiche Kanten zusammengefasst und mit der Anzahl
beschriftet (Abbildung 5).
Abbildung 5: Graph aus Abbildung 4 nach hinzufügen von dem Szenario aus Abbildung 3
Da Artefakte in ihrer Menge an Aktions- und Objekttags nicht beschränkt sind, muss der Graph
auch Szenarien mit Artefakten, die mehr als ein Aktions- und Objekttags enthalten, abbilden können
(Abbildung 6 und Abbildung 7).
Beispiel 2:
Gegeben sei ein Szenario bestehend aus zwei Artefakten. Im Szenario folgt auf das Artefakt B1, das
die Tags Objekt@Login und Aktion@Anmelden beinhält, das Artefakt B2 mit dem Tag
Objekt@Hauptseite.
Abbildung 6: Szenario bestehend aus den Artefakten B1 und B2
Abbildung 7: Graph zu dem Szenario in Abbildung 6 mit Kantenmarkierung
Wie an den Beispielen 1 und 2 zu sehen ist, wird für die Erstellung eines solchen Indizes ein
Szenario mit mindestens zwei Artefakten, die jeweils mindestens ein Tag der Klasse Objekt
beziehungsweise Aktion besitzen, benötigt. Die gleiche Voraussetzung gilt auch, wenn Kanten im
Graphen modifiziert werden sollen. Das Modifizieren erfolgt analog zu dem Erstellen. Man sucht
die korrespondierenden Kanten im Graphen, entfernt die fehlerhaften Kanten und fügt die
modifizierten Kanten hinzu. Beispiel 3 zeigt zwei Modifikationen und deren Auswirkungen auf den
Graphen. Das gegebene Szenario (Abbildung 8) beschreibt im aktuellen System den Ablauf einer
Kontostandabfrage. Dieses soll an die neuen Kundenwünsche angepasst werden. Der Kunde will
Seite 13 von 37

3 Interne Repräsentation von Artefakten
dass der Kontostand direkt auf der Hauptseite angezeigt wird (Abbildung 12 nach Modifikation).
Als erstes wird das Artefakt B2 durch das Artefakt B4 (Abbildung 8 und 10) ersetzt und
anschließend wird das Artefakt B3 (Abbildung 12) aus dem Szenario entfernt. Eine Ersetzung
erfolgt immer in zwei Schritten. Erst wird das zu ersetzenden Artefakt aus dem Szenario entfernt
und anschließend wird das neue Artefakt an die Stelle des zu ersetzenden Artefaktes eingefügt.
Dabei ist die Kantenanzahl im Graph zu beachten.
Beispiel 3:
Gegeben sei eine Bibliothek mit den folgenden vier Artefakten:
Artefakt B1 mit den Tags Objekt@Login und Aktion@Anmelden
Artefakt B2 mit Objekt@Hauptseite
Artefakt B3 mit Objekt@Hauptseite, Objekt@Kontostand und Aktion@Abfragen
Artefakt B4 mit Objekt@Hauptseite, Objekt@Kontostand
Das Ausgangsszenario sei Artefakt B1 gefolgt von Artefakt B2 und Artefakt B3.
Abbildung 8: Szenario bestehend aus den Artefakten B1, B2 und B3 vor Modifikation
Abbildung 9: Graph aus Abbildung 7 zu dem das Szenario in Abbildung 8 hinzugefügt wurde
Abbildung 10: Szenario in Abbildung 8 nach Modifikation bestehend aus den Artefakten B1, B4
und B3
Seite 14 von 37

3 Interne Repräsentation von Artefakten
Abbildung 11: Graph aus Abbildung 9 nach dem Austausch von Artefakt B3 durch B4
Die Kanten, die mit e2 markiert sind, (Abbildung 9) wurden vollständig aus dem Graphen in
Abbildung 11 entfernt, da deren Anzahl nach der Modifikation null ist. Neu Hinzugekommen zum
Graphen in Abbildung 11 ist die Kante e4, die das Artefakten-paar B4,B3 darstellt.
Durch die Modifikation ist das Artefakt B3 unnötig geworden und wird in Abbildung 12 aus dem
Szenario entfernt.
Abbildung 12: Szenario bestehend aus den Artefakten B1, B4 und B3
Abbildung 13: Graph aus Abbildung 11 nach der Modifikation in Abbildung 12
Abbildung 13 zeigt den abschließenden Graphen, der genau zwei verschiedene Szenarien
beschreibt. Einmal das gerade erstellte Szenario (Abbildung 12 nach Modifikation) und einmal das
Szenario aus Abbildung 6. Im Allgemeinen ist es nicht möglich anhand des Graphen auf die
erstellten Szenarien zuschließen. Durch das Hinzufügen einer weiteren Kante zu dem obigen
Graphen, wird es nicht mehr möglich sein, die genauen Szenarien zu erkennen.
Betrachtet man den Graphen aus Abbildung 11, so lässt sich der gleiche Graph auch durch die
Seite 15 von 37

3 Interne Repräsentation von Artefakten
Zuhilfenahme zweier Szenarien (Szenario A: Artefakt B1, Artefakt B4 und Szenario B: Artefakt B4,
Artefakt B3) erstellen. Das liegt an der Unabhängigkeit der Kanten von den nicht unmittelbar
benachbarten Artefakten im Szenario.
3.2 Bedingungen
Bedingungen bieten zusätzliche Einflussmöglichkeiten, um die Wahl der Artefakte für ein Szenario
zu beeinflussen. Sie bieten zusätzliche Regelungen für den Aufbau von Szenarien. Mit ihnen lassen
sich die im Domain-Index gespeicherten Informationen um projektspezifische Aspekte erweitern.
Beispiel 2 zeigt einen solche projektspezifischen Aspekt am Beispiel „Bankwesen vs. Online-
Banking“. Grundsätzlich lassen sich Artefakte durch Bedingungen für die Wahl im Szenario
entweder ausschließen oder bevorzugen. Als Bedingung kann alles genommen werden, solange es
auswertbar ist. Ich beschränke mich auf Tag-basierte Bedingungen(kurz Tag-Bedingungen).
Tag-Bedingungen sind Bedingungen, die Tags als Voraussetzung haben. Dabei unterscheide ich
zwei grundlegende Arten, Kausale-Tag-Bedingungen und Tag-Cloud-Bedingungen.
3.2.1 Tag-Cloud-Bedingungen
Bei Tag-Cloud-Bedingungen handelt es sich um Bedingungen, die aus den Szenarien selbst
entstehen. Aus jedem Szenario lässt sich eine Liste aller vorkommender Tags generieren. Betrachtet
man diese Listen als Indikatoren, so lassen sich aus so einer Liste Bedingungen erstellen. Werden
Tags häufig gemeinsam in einem Szenario verwendet, so ist es wahrscheinlich, dass dieses in
weiteren Szenario fortgesetzt wird. Dieses kann dazu genutzt werden Artefakte für ein gegebenes
Szenario auszuwählen. Im Domain-Index ist diese Information nicht enthalten, da dieser nicht
zwischen Szenarien unterscheidet. Ob Kanten von Knoten 1 über 2 nach 3 in einem Szenario erstellt
wurden oder dafür zwei Szenarien benutzt wurden, wird im Domain-Index nicht abgebildet.
Dennoch kann diese Information für die Auswahl der möglichen Artefakte für eine Fortsetzung des
gegebenen Szenarios interessant sein. Diese Informationen werden durch die Tag-Cloud-
Bedingungen genutzt.
Beispiel 3:
Gegeben sei ein Szenario bestehend aus einer beliebigen Kombination der folgenden drei Artefakte:
Artefakt B1A mit den Tags Subdomäne@Online-Banking, Objekt@Login und Aktion@Anmelden
Artefakt B2A mit Subdomäne@Online-Banking und Objekt@Hauptseite
Artefakt B3A mit Subdomäne@Online-Banking, Objekt@Hauptseite, Objekt@Kontostand und
Aktion@Abfragen.
Abbildung 14: Szenario bestehend aus den Artefakten B1A, B2A und B3A
Seite 16 von 37

3 Interne Repräsentation von Artefakten
Die Tag-Liste zum Szenario in Abbildung 14 sieht folgendermaßen aus:
Tag
Subdomäne@
Online-Banking
Objekt@
Hauptseite
Objekt@
Login
Objekt@
Kontostand
Aktion@
Anmelden
Anzahl 3 2 1 1 1 1
Aktion@
Abfragen
Jedes Tag in der Tag-Liste ist ein Indikator für alle anderen Tags in der Liste. Mit Hilfe dieser Tag-
Listen lassen sich die Artefakte zu Clustern zusammenschließen und man kann davon ausgehen,
dass Artefakte, die dem gleichen Cluster zugehören, eher ein logisch sinnvolles Szenario bilden als
Artefakte aus unterschiedlichen Clustern.
Diese Art von Bedingungen findet den Einsatz bei Empfehlungen, da durch sie der
Informationsverlust, den die Kantenunabhängigkeit des Indizes verursacht, ausgeglichen wird.
3.2.1.1 Auswahl und Gewichtung
Beispiel 4:
Gegeben sei das Szenario aus Abbildung 14. Aus dem Szenario lassen sich folgende Tag-Listen
erstellen. (Hinweis zur Notation: Tag(f), f gibt die Häufigkeit an, wie oft das Tag sich in den Tag-
Liste des Knotens befindet.)
Knoten
Subdomäne@Online-Banking
Objekt@Login
Aktion@Anmelden
Objekt@Hauptseite
Objekt@Kontostand
Aktion@Abfragen
Tag-Liste
Objekt@Login(3), Aktion@Anmelden(3),
Objekt@Hauptseite(6), Objekt@Kontostand(3),
Aktion@Abfragen(3)
Subdomäne@Online-Banking(3), Aktion@Anmelden(1),
Objekt@Hauptseite(2), Objekt@Kontostand(1),
Aktion@Abfragen(1)
Subdomäne@Online-Banking(3), Objekt@Login(1),
Objekt@Hauptseite(2), Objekt@Kontostand(1),
Aktion@Abfragen(1)
Subdomäne@Online-Banking(6), Objekt@Login(2),
Aktion@Anmelden(2) , Objekt@Kontostand(2),
Aktion@Abfragen(2)
Subdomäne@Online-Banking(3), Objekt@Login(1),
Aktion@Anmelden(1), Objekt@Hauptseite(2),
Aktion@Abfragen(1)
Subdomäne@Online-Banking(3), Objekt@Login(1),
Aktion@Anmelden(1), Objekt@Hauptseite(2),
Objekt@Kontostand(1)
Seite 17 von 37

3 Interne Repräsentation von Artefakten
Es ist nicht ratsam für jede Kombination aus Knoten und Eintrag in der Tag-List eine Bedingung zu
erstellen. Diese würde eine große Menge an Bedingungen erzeugen, die eher wenig Aussagekraft
besitzen. Eine bessere Methode ist es, nur Tags zu nehmen, deren Auftrittshäufigkeit
ist.
f ≫ f Rest (1)
f (T )>1.5∗avg(L) (2)
Die Ungleichung (2) ist eine mögliche Funktion, die der Bedingung (1) genügt.
Da Artefakte mehrerer Tags enthalten, kann für jedes dieser Tags eine zutreffende Bedingung
existieren. Dieses sollte neben der Fehleranfälligkeit eines automatischen Verfahrens bei der Wahl
der Gewichtungsfunktion berücksichtigt werden. Darum schlage ich
g=h(T )÷max( L) (3)
als eine mögliche Gewichtungsfunktion vor. Das Beispiel 5 erstellt exemplarisch für den Knoten
Objekt@Login die möglichen Bedingungen und berechnet die dazugehörige Gewichtung
Beispiel 5:
Gegeben sei die Cloud-Liste für den Knoten Objekt@Login aus Beispiel 4.
Der 1.5 fache Durchschnitt der Cloud-Liste beträgt 2.5 und somit erfüllt nur das Tag
Subdomäne@Online-Banking mit einer Häufigkeit von drei die geforderte Ungleichung (2).
Das Gewicht nach (3) ist eins.
3.2.1.2 Auswertung von Tag-Cloud-Bedingungen
Tag-Cloud-Bedingungen bestehen aus einem Bedingungs-Tag, einem Ereignis-Tag und einem
Gewicht. Das Bedingungs-Tag wird auf dem aktuellen Szenario ausgewertet. Bedingungen, deren
Bedingungs-Tags nicht im Szenario vorkommen, werden nicht eintreffen und können aussortiert
werden. Von den vorhandenen Bedingungen bleiben dadurch nur noch die Bedingungen übrig, die
relevant für das gegebene Szenario sind. Für ein gegebenes Artefakt, für das die Bedingungen
ausgewertet werden sollen, werden alle Bedingungen, deren Ereignis-Tag nicht in den Tags des
Artefaktes enthalten sind, aussortiert. Diese einfache Art der Aussortierung ist nur unter der
Annahme, dass eine nichtzutreffende Tag-Cloud-Bedingungen keine Folgen für ein Artefakt hat,
möglich. Durch die beiden Selektionen bleiben von den gesamten Bedingungen nur noch die übrig,
die sich auf dem aktuellen Szenario mit dem gegebenen Artefakt positiv auswerten lassen. Zum
Schluss werden die Gewichtungen aller übriggebliebenen Tag-Cloud-Bedingungen aufsummiert.
Die Gesamtsumme G ist 0≤G≤∣Zutreffende Bedingungen∣ , da die Summanden s , die
nach (3) berechnet werden, 0

3 Interne Repräsentation von Artefakten
eine mögliche logische Inkonsistenz. Der Nachteil dieser Bedingungsart ist die Abhängigkeit von
dem modellierten System. Je nach gewollter Systemeigenschaft kann eine Kausale-Tag-
Bedingungen für ein System sinnvoll und für ein anderes völlig unsinnig sein (Beispiel 2). Wird die
Bedingung aus Beispiel 2 unter der Subdomäne Online-Banking betrachtet, erscheint sie als
sinnvoll. Als unsinnig erscheint sie hingegen, wenn die Subdomäne zum klassischen Bankwesen
geändert wird. Die meisten, wenn nicht alle, deutschen Banken verlangen bei der Abgabe eines
Überweisungsformulars keine Identifikation. Dennoch lässt sich eine Bank erdenken, in der vor der
Abgabe eines Überweisungsformulars erst seine Identitätsüberprüfung stattfindet. Für diese Bank
wäre diese Bedingung durchaus sinnvoll.
Beispiel 1:
Gegeben seien zwei Tags Aktion@Anmelden und Aktion@Abmelden.
Aus diesem Tag-Paar lassen sich die zwei Bedingungen, die aufgrund des kausalen
Zusammenhangs der Wörter Anmelden und Abmelden entstehen, bilden. Bedingung 1 „Vor
Aktion@Abmelden muss Aktion@Anmelden vorkommen“ besagt, dass eine Abmeldung nur dann
logisch möglich ist, wenn sich zuvor auch angemeldet wurde. Die zweite Bedingung 2 „Nach
Aktion@Anmelden muss Aktion@Abmelden kommen“ besagt, dass auf ein Anmelden ein
Abmelden folgen muss.
Beispiel 2:
Gegeben seien zwei Tags Aktion@Überweisen und Aktion@Anmelden und die Bedingung “Vor
Aktion@Überweisen muss Aktion@Anmelden kommen“.
4 Empfehlungssystem für die video-basierte
Anforderungserhebung
4.1 Empfehlungsprozess
Wie in 2.6 angedeutet kann ein Empfehlungssystem mit einem IR-System verglichen werden.
Denn wie eine Suchmaschine soll auch das Empfehlungssystem aus einer Menge von Artefakten für
das aktuelle Szenario relevante Artefakte heraussuchen. Dafür braucht das Empfehlungssystem eine
Möglichkeit relevante von nicht relevanten Artefakten zu unterscheiden. Aufgrund der hohen
Ähnlichkeit liegt der Einsatz eines Indizes nahe, der die Beziehungen zwischen den Artefakten
abbildet.
Für einen solche Index wird, neben den zu indizierenden Objekten, eine Methode benötigt, um für
ein gegebenes Objekt relevante von nicht relevanten Objekten zu unterscheiden. Für die Wahl der
zu indizierenden Objekte gibt es grundlegend zwei Möglichkeiten. Entweder werden die Artefakte
direkt indiziert oder es werden die Tags der Artefakte als Grundlage für den Index benutzt. Beide
Vorgehensweisen würden den Zweck erfüllen. Dennoch ist eine Indizierung der Tags vorteilhafter,
da Artefakte, bestehend aus Ton und Bild, komplexe Gebilde darstellen, deren Indizierung einen
höheren Aufwand darstellt, als eine Abstraktion des Inhaltes in Form von Tags. Ich möchte hier
nochmal darauf hinweisen, dass der Abstraktionsvorgang, auch Tagging genannt, nicht Bestandteil
dieser Arbeit ist. Diese Thematik wird in [19] behandelt.
Seite 19 von 37

4 Empfehlungssystem für die video-basierte Anforderungserhebung
Der Empfehlungsprozess besteht im Grunde nur aus zwei Funktionen: Suchen und Sortieren
(Abbildung 27). Als erstes werden die relevanten Kanten für ein gegebenes Artefakt aus dem
aktuellen Domain-Indexes herausgesucht. Dann werden die gefundenen Kanten mit Hilfe des
Relevanz-Ranking vorsortiert. Anschließend werden zu den sortierten Kanten passende Artefakte
aus der Bibliothek herausgesucht. Zum Schluss werden alle gefundenen Artefakte mit Hilfe von
Ranking-Funktionen nachsortiert und in aufsteigender beziehungsweise absteigender Reihenfolge
dem Benutzer als mögliche Empfehlungen präsentiert.
1. Suche Kanten
2. Sortiere Kanten 3. Suche Artefakte 4. Sortiere Artefakte
Abbildung 27: Empfehlungsprozess
4.1.1 Suche nach relevante Kanten
Für die Suche nach relevanten Kanten in einem Domain-Index werden die Objekt- und Aktionstags
eines Artefaktes benötigt, da nur diese Indiziert werden. Zu jedem Objekt- und Aktionstags des
Artefaktes, für welches eine Empfehlung benötigt wird, wird der Graph nach korrespondierenden
Knoten durchsucht und deren ausgehenden Kanten extrahiert. Die durch die Extraktion
entstehenden Kantenmengen werden anschließend nach Kanten, die in mindestens α Mengen
vorkommen, durchsucht und der relevanten Kantenmenge hinzugefügt. Durch die Wahl eine
geeigneten α wird die relevante Kantenmenge nach unten beschränkt.
Abbildung 15: Graph der aus der Kombination der drei Szenarien Abbildung 6, 14 und ein
Szenario, das einen fehlerhaften Anmeldeversuch darstellt, entsteht
Seite 20 von 37

4 Empfehlungssystem für die video-basierte Anforderungserhebung
Beispiel 1:
Gegeben sei der Domain-Index aus Abbildung 15, der nach relevanten Kanten für drei verschiedene
Artefakte durchsucht werden soll. Sei α=Anzahl Kantenmengen .
Für das Artefakt B2, das Objekt@Hauptseite als einziges Tag besitzt, ist die relevante Kantenmenge
{e2,e3}, die nur aus den ausgehenden Kanten des Knotens Objekt@Hauptseite besteht.
Für das Artefakt B1 mit den Tags Objekt@Login und Aktion@Anmelden sind die zwei
Kantenmengen, die jeweils aus den ausgehenden Kanten e1 und e5 bestehen, relevant. Diese sind
auch gleichzeitig die einzigen ausgehenden Kanten der Knoten Objekt@Login und
Aktion@Anmelden.
Für beide vorherigen Artefakte stimmen die relevanten Kantenmengen mit den Kanten der Knoten,
die die Tags repräsentieren, genau überein. Dieses ist für das Artefakt B3 mit Objekt@Hauptseite,
Objekt@Kontostand und Aktion@Abfragen nicht der Fall. Der Knoten Objekt@Hauptseite hat die
ausgehenden Kanten {e2, e3}, Objekt@Kontostand hat {e3, e4} und der Knoten Aktion@Abfragen
hat{e3}. Da nur die Kante e3 in allen Kantenmengen vorkommt und somit der Bedingung
α=Anzahl Kantenmengen genügt, wird nur diese zu der Menge der relevanter Kanten für das
Artefakt B3 hinzufügt.
Bedenkt man, dass Artefakte durchaus mit unzureichenden oder falschen Tags getaggt sein können,
ist die Wahl von α als Anzahl aller Kantenmengen nicht vorteilhaft, da dadurch potentielle
Kanten und somit auch Artefakte für die Empfehlung entfallen. Vorteilhafter ist es
1

4 Empfehlungssystem für die video-basierte Anforderungserhebung
sich mit steigendem β die Wahrscheinlichkeit, dass durch diese Kante ein für das gegebene
Szenario relevantes Artefaktes gefunden wird. Durch den Einsatz der maximalen Tag-Abweichung
kann der Wert für die untere Schranke als Anzahl Kantenmengen−β≤α≤ Anzahl Kantenmengen
gewählt werden. Da Kanten, die in weniger als Anzahl Kantenmengen−β Kantenmengen
vorkommen, bei der späteren Nachsortierung eine größere Tag-Abweichung als β aufweisen. Ich
schlage 0≤β≤2 und α=Anzahl Kantenmengen−β vor. Dadurch werden Artefakte, die ein
fehlerhaftes Tagging aufweisen berücksichtigt.
Zusammenfassend kann gesagt werden, dass eine Kante für ein gegebenes Artefakt relevant ist,
wenn deren Tag-Cloud (Menge der Tags der Start-Knoten aller gleich markierten Kanten) nicht um
einen gegebenen Wert β von der Tag-Cloud der Objekt- und Aktionstags des gegebenen
Artefaktes abweicht.
4.1.2 Ranking der relevanten Kanten
Ein Ranking der relevanten Kanten ist nur nötig, wenn die maximale Tag-Abweichung β≥1 ist,
weil dadurch die Menge an relevanten Kanten durch Kanten, die durch Artefakte, die dem
gegebenen Artefakt ähnlich sind, erstellt wurden, erweitert wird. Je ähnlicher die Tag-Cloud der
Kante der Tag-Cloud der Objekt- und Aktionstags des gegebenen Artefaktes ist, desto größer ist die
Wahrscheinlichkeit, dass unter den Artefakten, die mit Hilfe dieser Kante gefunden wurden, das
gesuchte Artfakt, mit dem ein gegebenes Szenario erweitert wird, ist. Somit ist es von Vorteil die
Ähnlichkeit einer Kante zum gegebenen Artefakts zu beurteilen. Das Relevanz-Ranking soll ein
mögliches Verfahren für die Bewertung der Ähnlichkeit darstellen.
4.1.2.1 Relevanz-Ranking
Das Relevanz-Ranking ist ein Verfahren basierend auf der Levenshtein-Distanz[6]. Es vergleicht
zwei Tag-Clouds und berechnet, wie viele Tags der einer Tag-Cloud hinzugefügt oder entfernt
werden müssen, um daraus die zweite Tag-Cloud zu erstellen. Dabei werden zwei Fälle
unterschieden. Entweder eine Tag-Cloud überdeckt die andere, dass heißt, dass die Tags einer Cloud
vollständig in der anderen enthalten sind, oder in beiden Tag-Clouds befinden sich Tags, die nicht in
der anderen Tag-Cloud vorkommen. Für beide Fälle werden unterschiedliche Ranking-Funktionen
verwendet, weil das Fehlen von Tags in einer der beiden Clouds, was durch das Vergessen eines
Tags bei einem Artefakt entsteht, als weniger gravierend angesehen wird als das Auftreten von
unterschiedlichen Tags in beiden Clouds, das auf ein fehlerhaft getaggtes Artefakt hinweist.
d =∣ArtefaktTag∪ KantenTags∣−∣ArtefaktTag∩KantenTags∣
δ=∣( ArtefaktTag∪KantenTags)∖( ArtefaktTag∩KantenTags)∣
t=∣ArtefaktTag ∖ KantenTags∣
r={11−2 d , für d≤β und δ=0
9−2 t
, für d≤β und 0

4 Empfehlungssystem für die video-basierte Anforderungserhebung
Beispiel 3:
Gegeben sei der Domain-Index aus Beispiel 1 und die folgenden Artefakte mit ihren relevanten
Kanten:
Artefakt B2 mit Objekt@Hauptseite
Artefakt B3 mit Objekt@Hauptseite, Objekt@Kontostand und
Aktion@Abfragen
Artefakt B6 mit Objekt@Kontostand und Aktion@Abmelden
Relevante Kanten
{e2,e3}
{e2,e3,e4}
{e1,e3,e4,e5}
Berechnung des Relevanz-Ranking mit maximaler Tag-Abweichung β=2 und δ=1 .
Kante e1 Kante e2 Kante e3 Kante e4 Kante e5
Artefakt B2 - 10 7 - -
Artefakt B3 - 7 10 9 -
Artefakt B6 7 - 0 0 7
Beispiel 3 zeigt die exemplarische Berechnung des Relevanz-Ranking für die drei verschiedenen
Artefakte und derer relevanten Kanten. Kanten, deren Relevanz-Ranking r≤0 ist, werden aus der
relevanten Kantenmenge, die für die Suche der Artefakten für die Empfehlungen benutzt wird,
aussortiert. Für das Artefakt B6 aus Beispiel 3 reduziert sich die Kantenmenge auf {e1, e5}.
4.1.3 Suche passender Artefakte
Mit Hilfe der in Abschnitt 4.1.1 gefundenen Kantenmengen können zu den Kanten passende
Artefakte gesucht werden. Dafür werden aus jeder Kante die Tags der Zielknoten extrahiert und in
Listen (im folgenden Such-Listen genannt) gesammelt. Jede Such-Liste stellt dabei mindestens ein
mögliches Artefakt dar, mit dem das gegebene Szenario fortgesetzt werden kann. Anschließend
werden Artefakte, die den Such-Listen genügen, aus der Bibliothek herausgesucht. Ein Artefakt
genügt einer Such-Liste, wenn
0=∣SuchListe∖ ArtefaktTags∣ (5)
ist. Aus den gefundenen Artefakten müssen noch diejenigen, deren Domäne-Tag nicht dem
aktuellen Index entspricht aussortiert werden. Wie bei der Suche nach relevanten Kanten so ist es
auch hier möglich die Bedingung (5) abzuschwächen. Ich rate jedoch
0≤∣SuchListe∖ ArtefaktTags∣

4 Empfehlungssystem für die video-basierte Anforderungserhebung
4.1.4 Ranking der relevanten Artefakte
Die gefundenen Artefakte könnten jetzt direkt als Empfehlungen angezeigt werden. Jedoch lässt
sich durch eine geschickte Platzierung der Artefakte der Suchaufwand für den Benutzer reduzieren.
Die benutzte Funktion für das Ranking sollte aus mehreren Faktoren zusammengesetzt sein um eine
möglichst gute Unterscheidung der Artefakte zu ermöglichen. Sie sollte die Relevanz der Kanten,
mit der das Artefakt gefunden wurde und deren Kantenhäufigkeit berücksichtigen. Zusätzlich
müssen die Auswirkungen der Bedingungen darin enthalten sein. Eine mögliche Funktion ist
Sie enthält neben dem Relevanz-Ranking r
pos=r∗(1+log(n))∗m∗b (7).
, die Kantenanzahl n , einen Match-Faktor
m= ∣SuchListe∩(ArtefaktObjekttags∪ArtefaktAktionstags)∣
∣( ArtefaktObjekttags∪ ArtefaktAktionstags)∣
der den Überdeckungsgrad des Artefaktes und der Such-Liste darstellt, sowie den Einflussfaktor
b=1+∑ Bedingungen
g (9),
wobei g nach (3) berechnet wird. Je höher der pos -Wert eines Artefaktes im Vergleich zu den
anderen ist, desto höher ist auch dessen Ranking.
4.2 Tag-Austausch
Besonders am Anfang der Anforderungserhebung bestehen die Szenarien nicht immer aus reinen
Video-Artefakten. Für einige Handlungen existieren vielleicht keine passenden Video-Artefakte in
der Bibliothek. Fotos oder Skizzen können als Platzhalter für diese Artefakte dienen. Besteht das
Bedürfnis diese dann im späteren Verlauf durch Videos zu ersetzten, bietet der Tag-Austausch eine
schnellere Lösung als das manuelle Austauschen veralteter Artefakte. Insbesondere ist diese
Methode bei Tags der Klasse Subdomäne und Medientyp nützlich. Beispiel 1 befasst sich mit einem
Austausch eines Platzhalters.
Beispiel 1:
Gegeben sei eine Bibliothek mit den folgenden vier Artefakten:
Artefakt B1 mit den Tags Subdomäne@Online-Banking, Objekt@Login, Aktion@Anmelden und
Medientyp@Video
Artefakt B2 mit Subdomäne@Online-Banking, Objekt@Hauptseite und Medientyp@Abbildung
Artefakt B3 mit Subdomäne@Online-Banking, Objekt@Hauptseite, Objekt@Kontostand,
Aktion@Abfragen und Medientyp@Abbildung
Artefakt B3N mit Subdomäne@Online-Banking, Objekt@Hauptseite, Objekt@Kontostand,
Aktion@Abfragen und Medientyp@Video.
Das Ausgangsszenario sei Artefakt B1 gefolgt von Artefakt B2 und Artefakt B3.
Das Tag Medientyp@Abbildung soll durch Medientyp@Video ersetzt werden. Durch den Ersatz
entsteht das neue Szenario: Artefakt B1, Artefakt B2, Artefakt B4.
(8),
Seite 24 von 37

4 Empfehlungssystem für die video-basierte Anforderungserhebung
Abbildung 16: Szenario bestehend aus den Artefakten B1, B2 und B3
Abbildung 17: Szenario bestehend aus den Artefakten B1, B2 und B4
Beispiel 1 zeigt den Austausch von dem Tag Medientyp@Abbildung durch das Tag
Medientyp@Video. Die betroffenen Artefakte sind Artefakt B2 und Artefakt B3, da nur diese das Tag
Medientyp@Abbildung enthalten. Da die Artefakt-Bibliothek nur aus den vier Artefakten besteht,
wurde für das Artefakt B2 kein passender Ersatz gefunden und somit wird dieses Artefakt nicht
ausgetauscht. Für das Artefakt B3 existiert ein passender Ersatz in Form von Artefakt B3N und der
Austausch wird durchgeführt. Analog zu diesem Vorgehen kann der Austausch von jedem im
Szenario vorhandenen Tag durchgeführt werden.
Die Umsetzung des Tag-Austausch ähnelt der Suche nach Artefakten aus dem
Empfehlungsprozesses (Abbildung 27). Es ist ein mehrstufiger Prozess. Aus jedem betroffenem
Artefakt werden die Tags extrahiert, das betreffende Tag ausgetauscht und in Listen gesammelt. Mit
Hilfe dieser Listen werden in einem mehrstufigen Verfahren Artefakte aus der Bibliothek
herausgesucht. Die erste Stufe sucht nach Artefakten, deren Tags mit den Tags in der Liste genau
übereinstimmen. Wird ein oder mehrere Artefakte gefunden, bricht der Vorgang ab und die
gefundenen Artefakte werden als Vorschlag für den Austausch angezeigt. Die Wahrscheinlichkeit,
das der Austausch ausgeführt wird ist groß. Wird kein passendes Artefakt gefunden, tritt die zweite
Stufe des Prozesses ein. In diesem Teil wird nacheinander die Menge an Tags aus der Liste, die im
Artefakt vorkommen müssen, reduziert, bis mindestens ein Artefakt gefunden wird. Wird mehr als
ein Artefakt gefunden, muss die Abweichung der Artefakte von der Liste, die für die Suche benutzt
wurde, bestimmt werden. Dieses kann zum Beispiel durch die Berechnung der Levenshtein-
Seite 25 von 37

4 Empfehlungssystem für die video-basierte Anforderungserhebung
Distanz[6] geschehen. Zum Schluss werden dem Benutzer die Artefakte zur Auswahl angeboten, die
die kleinste Distanz aufweisen. Dieser kann dann eines der vorgeschlagenen Artefakte für den
Austausch wählen oder den Vorgang abbrechen.
Beispiel 2:
Gegeben sei eine Bibliothek mit den folgenden Artefakten:
Artefakt B2 mit den Tags Subdomäne@Online-Banking, Objekt@Hauptseite und
Medientyp@Abbildung
Artefakt B7 mit Subdomäne@Online-Banking, Objekt@Hauptseite und Medientyp@Skizze
Artefakt B8 mit Subdomäne@Online-Banking, Objekt@Hauptseite, Aktion@Abmelden und
Medientyp@Video
Das Tag Medientyp@Abbildung im Artefakt B2 soll durch Medientyp@Video ausgetauscht werden.
Die Tags der Liste, für die Suche, sind Subdomäne@Online-Banking, Objekt@Hauptseite und
Medientyp@Video. Da die Bibliothek kein Artefakt enthält, das genau mit diesen Tags getaggt ist.
Wird die Anzahl der Tags, die im Artefakt vorkommen müssen, um eins reduziert. Dadurch genügen
die Artefakte B7 und B8 der Such-Liste. Für das Artefakt B7 beträgt die Editier-Distanz eins, da
lediglich das Label des Medientyp-Tags geändert werden muss und für das Artefakt B8 beträgt die
Editier-Distanz zwei. Somit wird das Artefakt B7 als möglicher Ersatz für das Artefakt B2
vorgeschlagen.
5 Umsetzung und Demonstration
In diesem Kapitel wird die Auswirkung der Umsetzung des Konzeptes im Vision Catcher gezeigt.
In Abschnitt 1 und 2 werden die Änderungen an der GUI vorgestellt. Abschnitt 3 stellt das
Empfehlungssystem am Beispiel einer Überweisung mit verschiedenen TAN-Verfahren vor. Der
Tag-Austausch wird in Abschnitt 3 demonstriert.
5.1 Programmoberfläche
Nach dem Start wird ein Projekt ausgewählt. Dabei wird entweder ein vorhandenes Projekt geladen
oder ein neues durch die Angabe von Namen und gewünschter Domäne erstellt (Abbildung 3).
Dieses kann durch das Schließen des Fensters abgebrochen werden. In dem Fall werden
Standardwerte genommen, für den Projektnamen „Unknown“ und für die Domäne „newIndex“.
Danach wird die gewohnte Programmoberfläche, die um einige neue Elemente erweitert wurde,
angezeigt (Abbildung 5). In den oberen Toolbars befinden sich die Buttons für das Einblenden der
Empfehlungen und den Aufruf der GUI für die Erstellung eines Indizes aus einer Menge an
gespeicherten Projekten (Abbildung 4). Dabei können gleichzeitig Indizes zu verschiedenen
Domänen erstellt werden. Diese kann auch dazu genutzt werden vorhandene Indizes zu erweitern.
Indem die aus den ausgewählten Projekten entstehenden Indizes in die Vorhandenen integriert
werden. Unten links befindet sich der Button für den Tag-Austausch.
Seite 26 von 37

5 Umsetzung und Demonstration
Abbildung 18: Programmstart Abfrage
Abbildung 19: Index aus Projekten erstellen
Seite 27 von 37

5 Umsetzung und Demonstration
Abbildung 20: Die GUI des Vision Catcher mit einem Beispielszenario
5.2 Artefakt-Tagging
Im GUI für die Änderung der Tags eines Artefaktes ist es möglich Tags nach ihren Klassen zu
sortieren. Somit wird das Finden eines Tags vereinfacht. Ist ein Tag nicht vorhanden, kann es wie
gewohnt hinzugefügt werden. Dabei kann auf die Angabe der Klasse verzichtet werden, diese lässt
sich in dem „Neues Tag hinzufügen“-Fenster auswählen. Bei Benutzung der Tag-Notation
Klasse@Tag-Label, wird die angegebene Klasse in dem „Neues Tag hinzufügen“-Fenster
automatisch ausgewählt. Wenn die angegebene Klasse nicht vorhandenen ist, wird die nächst
ähnliche Klasse selektiert. Das „Neues Tag hinzufügen“-Fenster kann durch die Benutzung der
internen Klassenbezeichner „domain“ für Domäne, „subdomain“ für Subdomäne, „object“ für
Objekt, „action“ für Aktion und „type“ für Medientyp übersprungen werden.
Seite 28 von 37

5 Umsetzung und Demonstration
5.3 Empfehlungen
Abbildung 21: Neues Tag zum Artefakt hinzufügen
Abbildung 7 zeigt das Basisszenario, welches mindestens im Index abgebildet sein muss, damit die
folgende Demonstration möglich ist. Es wird eine Überweisung im Szenario dargestellt. Das erste
Artefakt zeigt ein Überweisungsformular, das zweite die TAN Eingabe mittels smsTAN und das
dritte die im Erfolgsfall angezeigte Bestätigung. In Abbildung 8 wird das gleiche Szenario erstellt.
Jedoch an Stelle von der smsTAN wird die chipTAN benutzt. Die Position des gesuchten Artefakte,
kann je nach Größe und Form des benutzten Index und der Menge an Artefakten variieren. Wie in
Abbildung 9 zu erkennen ist, gleicht das erstellte Szenario dem Basisszenario in dem ersten und
letzten Artefakt. Das mittlere zeigt das chipTAN-Verfahren
Seite 29 von 37

5 Umsetzung und Demonstration
Abbildung 22: Vergleichsszenario
Abbildung 23: Ablauf einer Erstellung eines Szenario mit Hilfe der Empfehlungen
Seite 30 von 37

5 Umsetzung und Demonstration
Abbildung 23: Vergleich beider Szenarien. Erste Zeile Vergleichsszenario. Zweite Zeile
Ergebnis-Szenario aus Abbildung 8
5.4 Tag-Austausch
Abbildung 10 zeigt die Auswahl der Tags, die für den Austausch der Artefakte benutzt werden. Das
erste Tag wird durch das zweite ausgetauscht. Dabei können nur Tags, die der gleichen Klasse
angehören mit einander getauscht werden. Im unteren Teil wird angezeigt, wie viele Artefakte das
erste Tag enthalten und somit von dem Austausch betroffen sind. Abbildung 11 führt einen Tag-
Austausch vor. Zu beachten ist, dass das von dem Austausch betroffene Artefakt nicht verloren geht.
Abbildung 25: GUI des Tag-Austausches
Seite 31 von 37

5 Umsetzung und Demonstration
6 Fazit und Ausblick
Abbildung 26: Ablauf Tag-Austausch
Der Vision Catcher wurde für die video-basierte Anforderungserhebung nach [18] entwickelt und
verfolgt den Ansatz aus [14], indem die benötigten Videosequenzen mit möglichst geringem
Aufwand erstellt werden. Es wird versucht die Szenarien aus kleinen Videoeinheiten, die am besten
schon in der Bibliothek vorhanden sind, zusammenzusetzen. Die daraus entstehenden
Videosequenzen sind nicht konsistent, weil sie nicht an das gegebene Szenario angepasst sind.
Jedoch reichen sie für eine grobe Beschreibung eines Systemmerkmals aus. Einer der Nachteile
dieses Vorgehens ist die große Menge an Videoeinheiten, aus denen die für das Szenario benötigten
herausgesucht werden müssen. Das vorgestellte Konzept versucht diesen Suchaufwand zu
reduzieren, indem aus zuvor erstellten Szenarien bedingte Wahrscheinlichkeiten für das Auftreten
von Artefakten, die die Videoeinheiten darstellen, berechnet und diese für eine automatische Suche
nutzt. Wird ein Szenario erstellt, das einem oder mehreren zuvor erstellen Szenarien bis auf wenige
Ausnahmen gleicht, so liefert der vorgestellte Empfehlungsprozess gute Empfehlungen und das
gewünschte Artefakt, das für die Fortsetzung des Szenarios benutzt wird, ist mit hoher
Wahrscheinlichkeit unter den Empfehlungen. Werden hingegen Szenarien erstellt, die keine
Ähnlichkeit zu vorherigen aufweisen, ist der Empfehlungsprozess fehleranfällig und die
Wahrscheinlichkeit wesentlich geringer, dass das gewünschte Artefakt unter den Empfehlungen ist.
Die benutzten Parameter und Ranking-Funktionen bieten Ansatzpunkte für eine Verbesserung. Die
gewählten Werte und Funktionen sind nur mögliche Varianten. Es existieren durchaus Versionen,
die ein besseres Ergebnis liefern. Dieses kann in einer späteren Studie untersucht werden.
Zusätzlich zu den Parametern und Ranking-Funktion können Verbesserungen an den
Datenstrukturen untersucht werden. Es besteht die Möglichkeit das Indizierte Tupel (Artefakt,
nachfolge Artefakt) durch ein Tripel (Vorgänger, Artefakt, Nachfolger) zu ersetzen. Das Tripel
liefert mehr Informationen, die im Empfehlungsprozess genutzt werden können, um bessere
Ergebnisse zu erzeugen.
Von den zwei vorgestellten Bedingungen wurde nur die Tag-Cloud-Bedingungen umgesetzt, da die
Seite 32 von 37

6 Fazit und Ausblick
Bearbeitung der anderen den Zeitrahmen dieser Arbeit überschritten hätte. Neben den beiden gibt
es, wie in Kapitel 3.2 angedeutet, weitere mögliche Bedingungsarten. Zum Beispiel kann die
Struktur eines Szenarios eine mögliche Bedingungsart darstellen. Strukturen wie zum Beispiel
„Situation, Aktion, Situation“ treten häufig in den Videosequenzen auf. Diese können als eine
Kombination von Tag-Klassen ausgedrückt werden. Für die Struktur „Situation, Aktion, Situation“
entspricht es zum Beispiel „keine Aktion, Aktion, keine Aktion“, da nur Artefakte, die ein Tag der
Klasse Aktion enthalten eine Aktion darstellen. Welchem Zweck diese und weitere Bedingungsarten
dienen können, muss in einer weiteren Arbeit geklärt werden.
Zudem kann untersucht werden, ob die gewonnenen Informationen aus dem Domain-Index und den
Bedingungen für weitere Funktionen einsetzbar sind. Die Validierung von UseCase-Diagrammen ist
eine mögliche Anwendung.
Zu guter Letzt sollte die Darstellung der Artefakte in der GUI überarbeitet werden. Besitzt ein
Artefakt mehr als fünf Tags, ist die Darstellung als eine durch Kommata separierte Liste der Tag-
Labels unpraktisch. Der Vergleich der einzelnen Tags fällt schwer.
Seite 33 von 37

A Literatur Verzeichnis
A Literatur Verzeichnis
[1] Haesen, M., Luyten, K., & Coninx, K. (2009): Get your Requirements Straight?:
Storyboarding Revisited. Human-Computer Interaction – INTERACT 2009, 12th IFIP TC
13 International Conference, Uppsala, Sweden, August 24-28, 2009, Proceedings, Part II ,
ISBN: 978-3-642-03658-3, Seite 546-549
[2] Bruegge, B., Creighton, O., Reiß, M., & Stangl, H.(2008): Applying a Video-based
Requirements Engineering Technique to an Airport Scenario. 2008 Third International
Workshop on Multimedia and Enjoyable Requirements Engineering - Beyond Mere
Descriptions and with More Fun and Games (pp. 9–11). IEEE. doi:10.1109/MERE.2008.2
[3] Toderici, G., Aradhye, H., Sbaiz, L. Yagnik, J., & Pasca, M. (2010): Finding meaning on
youtube: Tag recommendation and category discovery. Computer Vision and Pattern
Recognition, Retrieved from http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5539985
[4] Creighton, O., Ott, M., & Bruegge, B. (2006): Software Cinema-Video-based Requirements
Engineering. 14th IEEE International Requirements Engineering Conference (RE’06) (pp.
109–118). IEEE. doi:10.1109/RE.2006.59
[5] Machill, M. & Beiler M. (2007): Die Macht der Suchmaschinen / The Power of Search
Engines . Köln: Herbert von Halem Verlag, ISBN 3-938258-33-0
[6] Wikipedia: Levenshtein-Distanz. http://de.wikipedia.org/wiki/Levenshtein-Distanz
(Zugriffsdatum: 02.10.2012)
[7] Christopher D. Manning, P. R. and H. S. (2008). Introduction to Information Retrieval.
Cambridge University Press, ISBN 0-521865-71-9 Retrieved from http://wwwnlp.stanford.edu/IR-book/
[8] http://tomgruber.org/writing/ontology-definition-2007.htm (Zugriffsdatum: 02.10.2012)
[9] Kitzmann, I. (2009). Konzept und Implementierung eines Werkzeugs für multimediale.
http://www.se.uni-hannover.de/pub/File/pdfpapers/Kitzmann2009.pdf (Zugriffsdatum:
02.10.2012)
[10] Wikipedia: Tag(metadata). http://en.wikipedia.org/wiki/Tag_%28metadata%29
(Zugriffsdatum: 02.10.2012)
[11] Stefer A. (2007): Diskrete Strukturen 1. Kombinatorik, Graphentheorie, Algebra.
Kapitel 2.5 p92 ISBN 978-3-540-46660-4
[12] Vince Vizzaccaro: Google - Global Market Share on.
http://marketshare.hitslink.com/report.aspx?qprid=5&qpcustom=Google%20-
%20Global&qptimeframe=M&qpsp=145&qpnp=25 (Zugriffsdatum: 02.10.2012)
[13] Fenzi, M., Dragon, R., Leal-Taixé L., Rosenhahn, B., & Ostermann, J. (2012): 3D
Object Recognition and Pose Estimation for Multiple Objects using Multi-Prioritized
RANSAC and Model Updating. 34th Annual Symposium of the German Association for
Pattern Recognition (DAGM)
[14] Brill, O., Schneider, K., Knauss, E.:Videos vs. Use Cases: Can Videos Capture More
Requirements Under Time Pressure?. Roel Wieringa and Anne Persson, Proceedings of the
16th International Working Conference on Requirements Engineering: Foundation for
Seite 34 von 37

A Literatur Verzeichnis
Software Quality (REFSQ '10), volume 6182 of LNCS, pages 30-44, Essen, Germany.
Springer, 2010
[15] Schneider, K.: Anforderungsklärung mit Videoclips, In Proceedings of Software
Engineering 2010, Paderborn, Germany, 2010
[16] Knauss, Eric und Boustani, Christian E. und Flohr, Thomas: Investigating the Impact
of Software Requirements Specification Quality on Project Success. In: Bo- marius (Hrsg.)
und Oivo (Hrsg.) und Jaring, P¨
[17] Kamata, Mayumi I. und Tamai, Tetsuo: How Does Requirements Quality Relate to
Project Success or Failure? In: 15th IEEE International Requirements Engineering
Conference, 2007. RE ’07 (2007), Oct., S. 69–78. http://dx.doi.org/10.1109/ RE.2007.31. –
DOI 10.1109/RE.2007.31. – ISSN 1090–705X
[18] Raphael Pham, Sebastian Meyer, Ingo Kitzmann, Kurt Schneider: Interactive
Multimedia Storyboard for Facilitating Stakeholder Interaction, In Proceedings of the 8th
International Conference on the Quality of Information and Communications Technology
(QUATIC 2012), 2012
[19] Gary Geisler and Sam Burns. 2007. Tagging video: conventions and strategies of the
YouTube community. In Proceedings of the 7th ACM/IEEE-CS joint conference on Digital
libraries (JCDL '07). ACM, New York, NY, USA, 480-480. DOI=10.1145/1255175.1255279
http://doi.acm.org/10.1145/1255175.1255279
[20] Mark Melenhorst, Marjan Grootveld, Mark van Setten, and Mettina Veenstra. 2008.
Tag-based information retrieval of video content. In Proceedings of the 1st international
conference on Designing interactive user experiences for TV and video (UXTV '08). ACM,
New York, NY, USA, 31-40. DOI=10.1145/1453805.1453813
http://doi.acm.org/10.1145/1453805.1453813
B Abbildungsverzeichnis
1 Die GUI des Vision Catcher mit einem Beispielszenario vor der Modifikation 6
2 Aufwand von Empfehlungssystemen bei verschiedenen Trefferwahrscheinlichkeit 11
3 Szenario bestehend aus den Artefakten A1 und B2 12
4 Graph zu dem Szenario in Abbildung 3 12
5 aus Abbildung 4 nach hinzufügen von dem Szenario aus Abbildung 3 13
6 Szenario bestehend aus den Artefakten B1 und B2 13
7 Graph zu dem Szenario in Abbildung 6 mit Kantenmarkierung 13
8 Szenario bestehend aus den Artefakten B1, B2 und B3 vor Modifikation 14
9 Graph aus Abbildung 7 zu dem das Szenario in Abbildung 8 hinzugefügt wurde 14
10 Szenario in Abbildung 8 nach Modifikation bestehend aus den Artefakten B1, B4
und B3
11 Graph aus Abbildung 9 nach dem Austausch von Artefakt B3 durch B4 15
12 Szenario bestehend aus den Artefakten B1, B4 und B3 15
13 Graph aus Abbildung 11 nach der Modifikation in Abbildung 12 15
14
Seite 35 von 37

B Abbildungsverzeichnis
14 Szenario bestehend aus den Artefakten B1A, B2A und B3A 16
15 Graph der aus der Kombination der drei Szenarien Abbildung 6, 14 und ein
Szenario, das einen fehlerhaften Anmeldeversuch darstellt, entsteht
16 Szenario bestehend aus den Artefakten B1, B2 und B3 25
17 Szenario bestehend aus den Artefakten B1, B2 und B4 25
18 Programmstart Abfrage 27
19 Index aus Projekten erstellen 27
20 Die GUI des Vision Catcher mit einem Beispielszenario 28
21 Neues Tag zum Artefakt hinzufügen 29
22 Vergleichsszenario 30
23 Ablauf einer Erstellung eines Szenario mit Hilfe der Empfehlungen 30
24 Vergleich beider Szenarien 31
25 GUI des Tag-Austausches 31
26 Ablauf Tag-Austausch 32
27 Empfehlungsprozess 20
20
C Inhalt der CD
Der Bachelorarbeit liegt eine CD bei, die folgende Daten enthält:
• Eine Version dieser Ausarbeitung im PDF-Format
• Quellcode der Implementierung als Visual Studio Projekt
• Eine Artefakt-Bibliothek mit Beispielartefakten
• Ein Beispiel Domain-Index für die Domäne Banking
• Das in der Arbeit verwendete Beispiel Projekt
Seite 36 von 37

Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit und die dazugehörige Implementierung
selbständig und ohne fremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenen
Quellen und Hilfsmittel verwendet habe.
Hannover, 04. Oktober 2012
Michael Gaier