Institut für Softwaretechnologie
Universität Stuttgart
Universitätsstraße 38
D–70569 Stuttgart
Fachstudie Nr. 132
Werkzeuge für die
Anforderungsverwaltung
Désirée Graf, Ruben Mayer, Christian Sachers
Studiengang: Softwaretechnik
Prüfer: Prof. Dr. rer. nat. Jochen Ludewig
Betreuer: Dipl.-Inf. Holger Röder
begonnen am: 1. Februar 2011
beendet am: 3. August 2011
CR-Klassifikation: D.2.1

Inhaltsverzeichnis
1 Einleitung 7
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Zielsetzung der Fachstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Industriepartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Formale Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Aufbau des Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Sprachliche Konvention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Verlauf der Fachstudie 11
2.1 Teilaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Meilensteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Verwaltung von Anforderungen 15
3.1 Warum Anforderungen erfassen? . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Aufgaben der Anforderungsverwaltung . . . . . . . . . . . . . . . . . . . . . . . 15
4 Analyse 17
4.1 Ist- und Soll-Zustand bei TRUMPF . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Vorgehen bei der Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Ergebnisse der Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Marktübersicht über existierende Anforderungsverwaltungswerkzeuge . . . . 20
5 Erstellung der Short List 23
5.1 Definition der KO-Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Filterung der Gesamtliste anhand der KO-Kriterien . . . . . . . . . . . . . . . . 26
5.3 Short List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge 39
6.1 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Bewertungskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.1 Kriterium 1: Anforderungserfassung . . . . . . . . . . . . . . . . . . . . 41
6.2.2 Kriterium 2: Anforderungsverwaltung . . . . . . . . . . . . . . . . . . . 42
6.2.3 Kriterium 3: Änderungshistorie . . . . . . . . . . . . . . . . . . . . . . . 43
6.2.4 Kriterium 4: Testunterstützung . . . . . . . . . . . . . . . . . . . . . . . . 44
3
6.2.5 Kriterium 5: Rechtekonzept . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.6 Kriterium 6: Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2.7 Kriterium 7: Versionsplanung . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.8 Kriterium 8: Aufwandsbetrachtung . . . . . . . . . . . . . . . . . . . . . 46
6.2.9 Kriterium 9: Installation und Administration . . . . . . . . . . . . . . . . 47
6.2.10 Kriterium 10: Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.11 Kriterium 11: Usability nach ISO 9241 parts 110 . . . . . . . . . . . . . . 49
6.3 Detaillierte Bewertung der Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.1 Contour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.2 Rational DOORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3.3 ALM Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3.4 Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.5 IRQA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.3.6 Polarion RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.7 RTIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.8 TopTeam Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.9 TestTrackRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4 Zusammenfassung der detaillierten Bewertungen . . . . . . . . . . . . . . . . . 91
7 Empfehlung 93
7.1 Empfohlenes Anforderungsverwaltungswerkzeug - TestTrackRM . . . . . . . . 93
7.2 Alternative - Contour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8 Zusammenfassung und Ausblick 97
8.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Literaturverzeichnis 99
4
Abbildungsverzeichnis
5.1 Überblick über die evaluierten Anforderungsverwaltungswerkzeuge(1) . . . . 26
5.2 Überblick über die evaluierten Anforderungsverwaltungswerkzeuge(2) . . . . 27
5.4 Filterung der Gesamtliste anhand der KO-Kriterien . . . . . . . . . . . . . . . . 27
5.3 Überblick über die evaluierten Anforderungsverwaltungswerkzeuge(3) . . . . 28
5.5 Screenshot ALM Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Screenshot Polarion Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.7 Screenshot RTIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.8 Screenshot Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.9 Screenshot DOORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.10 Screenshot Contour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.11 Screenshot TestTrackRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.12 Screenshot TopTeam Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.13 Screenshot IRQA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1 Verteilung der Punkte auf die einzelnen Kriterien . . . . . . . . . . . . . . . . . 40
6.2 Wichtigste Aspekte im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3 Weniger wichtige Aspekte im Überblick . . . . . . . . . . . . . . . . . . . . . . . 91
6.4 Usability und allgemeiner Eindruck . . . . . . . . . . . . . . . . . . . . . . . . . 92
Tabellenverzeichnis
2.1 Meilensteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Short List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5

1 Einleitung
1.1 Motivation
Bisher wurden die Anforderungen bei der Software-Entwicklung im Hause TRUMPF nicht
mit einem geeigneten Werkzeug verwaltet. Dieser Zustand ist für die Zukunft nicht tragbar,
daher soll ein geeignetes Werkzeug zur Anforderungsverwaltung gefunden werden. Da in der
Abteilung gerade weitgreifende Umstellungen des gesamten Vorgehensmodells durchgeführt
werden, steht dem Unternehmen selbst keine Zeit zur Verfügung, ein geeignetes Werkzeug
zu finden. Daher soll eine Empfehlung für ein Werkzeug in dieser Fachstudie erarbeitet
werden, während beim Industriepartner eine einfache Excel-Lösung als Übergangslösung
eingesetzt wird.
1.2 Zielsetzung der Fachstudie
Das Ziel des Projekts ist, ein geeignetes Werkzeug zur Anforderungsverwaltung (im Fol-
genden „Anforderungsverwaltungswerkzeug“ oder kurz „Werkzeug“ genannt) für die
Softwareentwicklungsabteilung des Werkzeugmaschinenherstellers TRUMPF Laser- und
Systemtechnik GmbH (im Folgenden „Industriepartner“ oder kurz „TRUMPF“ genannt) zu
finden.
1.2.1 Industriepartner
Die Fachstudie wird in Zusammenarbeit mit der TRUMPF Laser- und Systemtechnik GmbH
in Ditzingen durchgeführt. Direkter Kunde ist eine Softwareentwicklungsabteilung (TW542)
mit ca. 100 Mitarbeitern, welche für die Weiterentwicklung der hauseigenen Software TruTops
zuständig ist.
1.3 Formale Aufgabenstellung
1.3.1 Hintergrund
An die Anforderungsverwaltung in Softwareentwicklungsprojekten werden vielfältige An-
sprüche gestellt: Anforderungen verschiedener Form und aus verschiedenen Quellen müssen
7
1 Einleitung
dokumentiert, geordnet und priorisiert werden, Abhängigkeiten zwischen Anforderungen
müssen erfasst und Änderungen nachvollzogen werden können. Gleichzeitig muss die
Konsistenz der verwalteten Anforderungen mit anderen Dokumenten sichergestellt wer-
den. Angesichts der großen Zahl zu verwaltender Anforderungen können diese Ansprüche
häufig nur mit Unterstützung durch eines oder mehrere Werkzeuge erfüllt werden. Die
Werkzeuge müssen dabei selbst zahlreichen Anforderungen genügen: die Interoperabilität
mit anderen eingesetzten Werkzeugen muss gewährleistet sein, die Einführungskosten (für
Lizenzen und Schulungen) müssen in einem angemessenen Verhältnis zum Nutzen stehen,
und schließlich sollten bestehende Arbeitsabläufe möglichst umfassend unterstützt werden.
Vor diesem Hintergrund stellt die Auswahl eines zu verwendenden Werkzeugs für die
Anforderungsverwaltung eine komplexe Entscheidung unter einer Vielzahl von Randbedin-
gungen dar, die sich nur auf Basis einer Analyse der bestehenden und geplanten Prozesse
im Entwicklungsumfeld fundiert treffen lässt.
1.3.2 Aufgabenstellung
Die Fachstudie wurde in Kooperation mit dem Industriepartner TRUMPF Laser- und System-
technik GmbH durchgeführt. Aufgabe der Fachstudie war der Vergleich kommerzieller und
freier Werkzeuge für die Anforderungsverwaltung unter Berücksichtigung unterschiedlicher
Nutzungsszenarien und Anforderungsprofile in der Softwareentwicklungsabteilung des
Industriepartners. In die Analyse sollten auch Lösungen auf Basis von Standardsoftware (z.
B. Tabellenkalkulation) einbezogen werden. Die Erarbeitung der Nutzungsszenarien und
Anforderungsprofile auf Basis von Interviews war ebenfalls Teil der Fachstudie.
1.3.3 Vorgehensweise
Zu Beginn der Fachstudie wurde ein Projektplan erstellt, in dem alle Meilensteine mit
Fertigstellungsdatum und Auflistung der Teilergebnisse definiert wurden. Darüber hinaus
wurden die Risiken, welche den Erfolg der Fachstudie bedrohen könnten, analysiert und
mögliche Gegenmaßnahmen gefunden.
Danach wurde ein Fragenkatalog erstellt, mit dessen Hilfe Interviews mit mehreren TRUMPF-
Mitarbeitern geführt wurden. Als Ergebnis dieser Befragung wurde eine Liste mit Anforde-
rungen erstellt, woraus die wichtigsten Anforderungen identifiziert und als KO-Kriterien für
eine erste Filterung der auf dem Markt existierenden Anforderungsverwaltungswerkzeuge
verwendet wurden. Dazu musste zuerst eine Marktübersicht erstellt werden.
Nach der Filterung durch die KO-Kriterien blieben noch neun Anforderungsverwaltungs-
werkzeuge, welche einer detaillierten Betrachtung unterzogen wurden. Dazu wurde ein
Bewertungskatalog erstellt, in welchem die einzelnen Anforderungen an das Anforderungs-
verwaltungswerkzeug kategorisiert und im Rahmen eines Workshops mit den TRUMPF-
Mitarbeitern priorisiert wurden. Nach der Bewertung aller Anforderungsverwaltungswerk-
zeuge anhand des Bewertungskatalogs wurden die Ergebnisse verglichen und eine Empfeh-
lung ausgearbeitet.
8
1.4 Aufbau des Dokuments
1.4 Aufbau des Dokuments
Dieser Bericht ist in folgender Weise gegliedert:
Kapitel 2 – Verlauf der Fachstudie gibt einen Überblick über den Verlauf der Fachstudie.
Kapitel 3 – Verwaltung von Anforderungen gibt einen allgemeinen Überblick zum Thema
Anforderungen und Anforderungsverwaltung.
Kapitel 4 – Analyse beschreibt das Vorgehen in der Analysephase und deren Ergebnisse.
Als Teil der Analyse wird außerdem auf die Marktübersicht eingegangen.
Kapitel 5 – Erstellung der Short List beschreibt die Erstellung von KO-Kriterien und deren
Anwendung auf die sogenannte Long List aus der Marktübersicht, um daraus eine
sogenannte Short List zu erhalten.
Kapitel 6 – Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge geht auf die
Erstellung des Kriterienkatalogs für die detaillierte Bewertung ein. Anschließend
werden die Werkzeuge bewertet.
Kapitel 7 – Empfehlung gibt eine abschließende Empfehlung für ein Werkzeug und zeigt
eine mögliche, vielversprechende Alternative auf.
Kapitel 8 – Zusammenfassung und Ausblick fasst die Ergebnisse der Arbeit zusammen und
stellt Anknüpfungspunkte vor.
1.5 Sprachliche Konvention
Immer wieder stellt die geschlechtsspezifische Rollenbezeichnung ein Problem dar. Wir sind
als gemischtes Team der Ansicht, dass es keinen Sinn ergibt, künstlich immer beide Formen
der Rollenbezeichnung zu verwenden. Auch eine abwechselnde Verwendung würde den
Lesefluss nur stören und den Leser verwirren. Wir benutzen daher Rollenbezeichnungen
in ihrer üblicherweise verwendeten Grundform, ohne dabei ein bestimmtes Geschlecht der
Person suggerieren zu wollen, die diese Rolle ausübt.
Die Frage der Verwendung von Anglizismen in der Softwaretechnik ist ebenfalls nicht ganz
problemlos. Die inflationäre Verwendung englischer Begriffe und Abkürzungen scheint in
der Softwaretechnik weit verbreitet zu sein, obgleich es für viele Sachverhalte deutsche
Wörter gibt. Wir bemühen uns daher, keine unnötigen Anglizismen zu verwenden, wo es ein
gutes deutsches Wort gibt. Jedoch ist es im Bereich der Softwaretechnik nicht immer möglich
auf englischsprachige Wörter zu verzichten. Wo es nötig oder sinnvoll ist, werden wir daher
auch englischsprachige Wörter verwenden.
9

2 Verlauf der Fachstudie
2.1 Teilaufgaben
Die Teilaufgaben der Fachstudie wurden in der Ausschreibung wie folgt definiert:
• Erstellung eines Projektplans mit Angabe von Meilensteinen
• Recherche zum Thema ‚Requirements Management‘ und zu RM-Werkzeugen
• Erstellung eines Marktüberblicks
• Auswahl näher zu betrachtender RM-Werkzeuge anhand von KO-Kriterien (Short List)
• Analyse des Ist-Prozesses beim Industriepartner
• Definition von Nutzungsszenarien und Anforderungsprofilen (Anforderungen an
RM-Werkzeuge in den jeweiligen Nutzungsszenarien)
• Definition eines Bewertungsschemas für RM-Werkzeuge
• Bewertung der RM-Werkzeuge für die verschiedenen Nutzungsszenarien und Erarbei-
tung einer differenzierten Empfehlung
• Dokumentation des Vorgehens und der Ergebnisse in einem Bericht
• Präsentation der Ergebnisse in einem Zwischen- und einem Endvortrag
Um die Aufgaben zu erfüllen, wurde ein Projektplan mit Meilensteinen und Zwischenergeb-
nissen erstellt. Die Meilensteine und Ergebnisse werden im Folgenden beschrieben.
2.2 Meilensteine
M1 - Projektplanung Es wurde ein Projektplan entwickelt, in dem wir unser Vorgehen in
der Fachstudie geplant und dokumentiert haben. Dies beinhaltet vor allem die Aufgaben-
und Terminplanung.
11
2 Verlauf der Fachstudie
- Meilenstein Teilergebnisse Datum
M1 Projektplanung Projektplan 28.01.2011
M2 Kick-Off Protokoll mit wichtigen Infor-
mationen
11.02.2011
M3 IST-Analyse,
SOLL-Analyse
Analysenotizen 31.03.2011
M4 Marktübersicht Liste mit verfügbaren RM-
Tools (Long List)
12.04.2011
M5 Definition von KO-Kriterien Liste mit KO-Kriterien 13.04.2011
M6 Filterung der Gesamtliste Short List von 9 Tools 24.04.2011
M7 Zwischenpräsentation Uni-
versität
- 05.05.2011
M8 Zwischenpräsentation
TRUMPF
- 10.05.2011
M9 Vorschlag von Bewertungskri-
terien
Vorschlag für Bewertungskri-
terien, ohne Gewichtung
15.06.2011
M10 Workshop beim Industriepart-
ner
Gewichtete Liste mit Bewer-
tungskriterien
18.06.2011
M11 Bewertung der Werkzeuge Bewertete Short List 15.07.2011
M12 Abschlusspräsentation Indus-
triepartner
Abschließende Empfehlung 27.07.2011
M13 Abschlusspräsentation Uni-
versität
Abschließende Empfehlung 03.08.2011
Tabelle 2.1: Meilensteine
M2 - Kick-Off Zum offiziellen Start der Fachstudie gab es eine Kick-Off-Veranstaltung beim
Industriepartner, bei der wir von leitenden Angestellten der Softwareentwicklungsabteilung
offiziell begrüßt wurden. Die Abteilung stellte die Firma vor und gab uns einen Einblick in
die Strukturen der an den Ergebnissen der Fachstudie interessierten Stellen. Als wichtiges
Ergebnis des ersten Treffens wurde der Personenkreis bestimmt, mit dem wir im Folgenden
Analyseinterviews führen sollten.
M3 - IST - und SOLL-Analyse Zur Analyse der Situation beim Industriepartner und der
Anforderungen an das gesuchte Anforderungsverwaltungswerkzeug führten wir Interviews
mit folgenden Personen:
• Matthias Wetzel
• Michael Meyer
• Maike Rehusch, QS. Sie ist für die Werkzeuglandschaft beim Industriepartner zuständig.
Zudem wünscht sie eine Unterstützung des gesuchten Werkzeugs für die Verwaltung
12
2.2 Meilensteine
von Testfällen, wenn dies mit den Anforderungen an die Anforderungsverwaltung in
einem Werkzeug vereinbar ist.
• Achim Balbach
Als Ergebnis der Gespräche haben wir den Ist- und Sollzustand erfasst und die Hauptanfor-
derungen an das gesuchte Werkzeug erarbeitet.
M4 - Marktübersicht In der Phase, die mit diesem Meilenstein abschließt, haben wir den
Markt der Anforderungsverwaltungswerkzeuge analysiert und eine Liste aller in Frage
kommenden Werkzeuge erstellt, sofern sie uns bekannt waren. Hierzu haben wir uns vor
allem an vorhandenen Bewertungslisten aus dem Internet bedient. Zusätzlich hat uns der
Industriepartner eine Dokumentation einer Analyse von Anforderungswerkzeugen aus einer
anderen Firma zur Verfügung gestellt, aus welcher wir die untersuchten Werkzeuge mit in
unsere Gesamtliste aufnahmen.
M5 - Definition von KO-Kriterien Wir haben aus den Analysenotizen des Meilensteins M3
und den Kenntnissen über Anforderungsverwaltungswerkzeuge, welche wir während der
Erstellung der Marktübersicht gewinnen konnten, sog. KO-Kriterien herausgearbeitet. Diese
haben wir dem Industriepartner zur Bestätigung vorgelegt.
M6 - Filterung der Gesamtliste der Werkzeuge Anhand der KO-Kriterien haben wir die in
der Marktübersicht gewonnene Gesamtliste der Werkzeug gefiltert. Als Ergebnis erhielten
wir die Short List von 9 Werkzeugen, die näher betrachtet werden sollten.
M7 - Zwischenpräsentation Universität Die Zwischenergebnisse haben wir an der Univer-
sität präsentiert.
M8 - Zwischenpräsentation Industriepartner Beim Industriepartner gab es eine zweite
Präsentation, die sich inhaltlich von der aus M7 kaum unterschieden hat.
M9 - Vorschlag von Bewertungskriterien Aus den Notizen der Analysephase und den
Erfahrungen bei der Überprüfung der Werkzeuge auf ihre Erfüllung der KO-Kriterien haben
wir mit Hilfe unseres Betreuers eine ungewichtete Liste von Bewertungskriterien erstellt, die
wir dem Industriepartner vorschlugen.
M10 - Workshop beim Industriepartner In einem Workshop beim Industriepartner haben
wir die vorgeschlagenen Bewertungskriterien diskutiert und schließlich die anwesenden
Mitarbeiter eine Gewichtung durchführen lassen, welche wir bei der Bewertung der 9
Werkzeuge der Short List berücksichtigten.
13
2 Verlauf der Fachstudie
M11 - Bewertung der Werkzeuge Wir haben die Werkzeuge der Short List schließlich
ausführlich getestet und anhand der gewichteten Liste von Bewertungskriterien bewertet.
M12 - Abschlusspräsentation Industriepartner Bei der Abschlusspräsentation haben wir
unsere Ergebnisse vorgestellt und eine Empfehlung für ein Werkzeug und einen Alternativ-
vorschlag ausgesprochen.
M13 - Abschlusspräsentation Universität Auch an der Universität gab es wieder eine
Präsentation, mit der die Fachstudie abgeschlossen wurde.
14
3 Verwaltung von Anforderungen
Die Aufgabe dieser Fachstudie ist das Finden eines geeigneten Anforderungsverwaltungs-
werkzeugs für den Industriepartner TRUMPF. Um dieser Aufgabe gerecht zu werden, ist
es wichtig zu klären, warum Anforderungen erhoben werden sollen und welche Aufgaben
ihre Verwaltung mit sich bringt. Dabei sollen bei der Erhebung der Anforderungen alle
qualitativen und quantitativen Eigenschaften einer Software aus Sicht des Kunden ermittelt
werden. Die Verwaltung der Anforderungen schließt zusätzlich die Steuerung und Kontrolle
der Anforderungen mit ein. [GH09]
3.1 Warum Anforderungen erfassen?
Mit die wichtigsten Informationen eines Software-Projekts sind die Anforderungen, welche
ein Kunde an die Software hat. Werden diese nicht verstanden und erfasst, muss damit
gerechnet werden, dass sie in der Software nicht vollständig umgesetzt werden und somit
die Ansprüche des Kunden an die Software nicht erfüllt werden. Daher ist die Erfassung
der Anforderungen eine der wichtigsten technischen Voraussetzung für ein erfolgreiches
Software-Projekt. [JL07]
3.2 Aufgaben der Anforderungsverwaltung
Eines der größten Probleme der Anforderungsverwaltung sind neben nicht oder falsch
erfassten Anforderungen nicht nachvollziehbare Änderungen an bereits erfassten Anforde-
rungen. Besonders in der Software-Branche ändern sich die Anforderungen oft. Gründe
hierfür sind unter anderem, dass der Kunde sich das Endprodukt nicht in allen Einzelheiten
vorstellen kann. Er merkt erst später, dass er Sachverhalte übersehen hat oder dass sich
das Zusammenspiel der Funktionen anders verhält als gedacht. Langzeitbeobachtungen
von Software-Projekten zeigen eine Änderungsrate aller Anforderungen von 30-50 % über
die Projektlaufzeit. [Ebe10] Daher ist es wichtig, dass Änderungen nachvollziehbar sind
und in die Projektplanung aufgenommen werden. Hierzu gehört auch die Versionierung
von Anforderungen, um sicherzustellen, dass jeweils der aktuelle Stand einer Anforderung
genutzt wird. Dazu sollte jede Version eine kurze Erklärung erhalten, um später die Relevanz
der einzelnen Version schnell zu erkennen. So ist zum Beispiel die Version der Korrektur
eines Rechtschreibfehlers wenig relevant und sollte auch als solches erkenntlich sein. [Ebe10]
Anforderungen müssen kontrolliert und verfolgt werden, um ihren Einfluss auf das
15
3 Verwaltung von Anforderungen
Projekt offenzulegen. Dazu gehört zum Beispiel das Verfolgen von Abhängigkeiten
zwischen Anforderungen, um zu erkennen, wie sie aufeinander aufbauen und welche zuerst
umgesetzt werden muss. Auch ist es sinnvoll, darzustellen, welche Testfälle sich auf welche
Anforderungen beziehen, um das Ergebnis eines Tests validieren und die Vollständigkeit der
Software überprüfen zu können. [Ebe10]
16
4 Analyse
4.1 Ist- und Soll-Zustand bei TRUMPF
4.1.1 Vorgehen bei der Analyse
Zu Beginn der Fachstudie haben wir versucht mit Hilfe von Interviews mit TRUMPF-
Mitarbeitern den Ist- und den Soll-Zustand bei unserem Industriepartner zu ermitteln.
Hierzu erstellten wir einen Fragenkatalog, welcher auf Basis der Ergebnisse der vorherge-
henden Interviews an die nächsten jeweils Interviewpartner angepasst wurde. Das erste
Interview führten wir mit Matthias Wetzel, um die Organisationsstruktur von TRUMPF im
Allgemeinen kennen zu lernen und wichtige Gesprächspartner zu erfahren. Als nächstes
sprachen wir mit Michael Meyer, welcher bei TRUMPF die Position der Leitung der Pro-
duktneuentwicklung innehat und Mitglied des Anforderungsgremiums ist. Er hat uns mehr
über den Anforderungsfluss und Arten der Anforderungen berichtet. Danach hatten wir ein
Gespräch mit Maike Rehusch, welche bei TRUMPF für die Qualitätssicherung und Admi-
nistration zuständig ist und gerne in dem Anforderungsverwaltungswerkzeug zusätzlich
zu den Anforderungen noch Testfälle verwalten möchte. Darüber hinaus beantwortete sie
uns Fragen zur bereits existierenden Werkzeuglandschaft. Der nächste Interviewpartner war
Achim Balbach, welcher als Leiter der Serienbetreuung und Mitglied des Anforderungsgremi-
ums aktiv mit dem Anforderungsverwaltungswerkzeug arbeiten wird. Zuletzt sprachen wir
mit Herrn Ebinger, der nach unserer Zwischenpräsentation bei TRUMPF ebenfalls Interesse
zeigte, das Werkzeug zur Anforderungsverwaltung in seinem Bereich einzusetzen.
4.1.2 Ergebnisse der Analyse
Ist-Zustand
Zum Zeitpunkt der Fachstudie befand sich TRUMPF gerade in einer Umstrukturierung der
Software-Abteilung. Die Umstrukturierung betrifft dabei zum Einen die Organisationsstruk-
tur und zum Anderen die verwendeten Prozesse. So löst nun ein Scrum-ähnlicher, agiler
Prozess das klassische Wasserfallmodell bei TRUMPF ab. Im Zuge dieser Umstrukturierung
soll die Erfassung von Anforderungen zukünftig kanalisiert in einem Anforderungsgremium
mit Hilfe eines Anforderungsverwaltungswerkzeugs stattfinden. Bisher hatte jede Entwick-
lungsgruppe für sich ihre Anforderungen in einer Excel-Tabelle erfasst. Die Weitergabe von
Anforderungen geschah auf Zuruf und es fehlte eine zentrale Stelle und ein definierter
Prozess für die Erfassung und Verwaltung von Anforderungen.
17
4 Analyse
Soll-Zustand
Anforderungen sollen in Zukunft zentralisiert erfasst und verwaltet werden. Diese Zentra-
lisierung soll durch die Einrichtung eines Anforderungsgremiums erreicht werden. Das
Gremium nimmt Anforderungen aus den verschiedenen Kanälen entgegen und pflegt sie
in das Anforderungsverwaltungswerkzeug ein. Die Anforderungen können dabei aus un-
terschiedlichen Kanälen kommen und sind relativ grobgranular. Mögliche Kanäle sind die
Marketingabteilungen oder der Support. Vom Support erfasste Fehler werden jedoch meist
direkt an die verantwortlichen Entwickler weitergeleitet. Das Anforderungsgremium nimmt
außerdem die Versionsplanung vor. Das heißt, dass auf Basis der zur Entwicklung der einzel-
nen Anforderung nötigen Kapazitäten die in einer Version zu entwickelnden Anforderungen
geplant werden. Die Anforderungen werden dann in einzelne, detailliertere Aufgaben zerlegt
und in den bereits eingesetzten Issue-Tracker JIRA eingepflegt. Wer genau das Einpflegen
vornimmt wurde noch nicht entschieden.
Anforderungen an des Anforderungsverwaltungswerkzeug
Folgende Anforderungen konnten wir aus den oben genannten Interviews erfassen:
• Jede Anforderung soll einer Version zugeordnet werden. Es soll auch möglich sein, nur
die zu einer bestimmten Version gehörenden Anforderungen angezeigt zu bekommen.
• Zu jeder Anforderung soll erfasst werden, wie viel Entwicklungsaufwand für die
Realisierung dieser Anforderung benötigt wird, um daraus zu ermitteln, mit wie viel
Entwicklungsaufwand in einer Version insgesamt gerechnet werden muss.
• Pro Anforderung sollen frei definierbare Attribute erfasst werden können. Zu diesen
Attributen gehören unter anderem: Aufwand, Priorität, Kosten geplant, Kosten Worst-
Case, Typisierung (Wunsch, Idee, Service-Fall), Quelle, Status, Produkt, Beschreibung,
Zielmaschine der Software.
• Es soll möglich sein, eine Anforderung mehreren Produktversionen zuzuordnen, da
es wahrscheinlich ist, dass eine Anforderung über mehrere Produktversionen hinweg
umgesetzt wird.
• Erfasste Anforderungen sollen geändert werden können und die Änderungen sollen
einsehbar sein.
• Das Anforderungsverwaltungswerkzeug sollte eine Exportmöglichkeit haben, um
externen Bereichen wie dem Kunden zu präsentieren, was in einer bestimmten Version
realisiert wird.
• Rechteverwaltung: Abteilungs- und Gruppenleiter sollen lesenden und schreibenden
Zugriff auf das Anforderungsverwaltungswerkzeug haben. Dabei handelt es sich
um eine Personengruppe von etwa 10 Personen. Hinzu kommen nochmals etwa 20
Personen, welche nur lesend auf das Anforderungsverwaltungswerkzeug zugreifen
sollen.
18
4.1 Ist- und Soll-Zustand bei TRUMPF
• Anforderungen sollen als Text mit Grafik erfasst werden können. Dabei sollen auch
Anhänge und Links zu einer Anforderung hinzugefügt werden können.
• Es sollen Abhängigkeiten zwischen Anforderungen angebbar sein, da die Realisierung
mancher Anforderungen von anderen Anforderungen abhängig sein kann.
• Traceability: Es soll möglich sein, eine Verlinkung zwischen einem JIRA-Issue und dem
Anforderungsverwaltungswerkzeug zu realisieren. Hierbei wäre es wünschenswert,
wenn in einem JIRA-Issue ein Link zu einer Anforderung gesetzt werden könnte, um
den Wartungsaufwand möglichst gering zu halten.
• Die Rechteverwaltung soll es ermöglichen, vielen Mitarbeiter Leserechte zu geben, die
Schreibrechte aber auf einen kleinen Kreis an Leuten einzuschränken. Die Rechte sollen
dabei an Personen gebunden sein.
• Das Anforderungsverwaltungswerkzeug soll eine Suchfunktion mit speicherbaren
Suchfiltern und AND/OR-Verknüpfungen bieten. Selbst angelegte Attribute sollen von
der Suchfunktion in die Suche einbezogen werden.
Nicht erwünschte Eigenschaften des Anforderungsverwaltungswerkzeug
Folgende Punkte soll/muss das Anforderungsverwaltungswerkzeug nicht unterstützen:
• Das Anforderungsverwaltungswerkzeug soll keinen Prozess aufzwingen.
• Eine Zerlegung von Anforderungen in einzelne Aufgaben soll nicht im Anforderungs-
verwaltungswerkzeug sondern in JIRA stattfinden.
Nutzungsszenarien
Aus den Gesprächen mit den oben genannten TRUMPF-Mitarbeitern konnten wir folgende
Nutzungsszenarien bzw. Nutzergruppen identifizieren:
• Anforderungsgremium:
Die Anforderungen aus verschiedenen Kanälen werden vom Gremium zentral ge-
sammelt und werden in das Anforderungsverwaltungswerkzeug eingegeben. Die
Mitglieder des Gremiums besitzen also Schreibrechte in dem Anforderungsverwal-
tungswerkzeug. Bei der Eingabe der Anforderungen spezifiziert das Gremium für jede
Anforderungen ihren Typ (Idee, Wunsch, Service-Fall, ...), ihre Quelle, ihre Priorität,
ihren Status, eine textuelle Beschreibung, die Zielmaschine und eventuell Links zu
relevanten Dokumenten.
Danach entscheidet das Gremium, welche Anforderung in welcher Produktversion
verwirklicht wird. Das Anforderungsverwaltungswerkzeug unterstützt das Gremium
bei dieser Entscheidung durch einfache Planungsfunktionen. So wird durch einfaches
19
4 Analyse
Aufaddieren errechnet, ob die zu verwirklichenden Anforderungen in der zur Ver-
fügung stehenden Zeit umsetzbar sind. Außerdem werden Worst-Case-Schätzungen
berechnet.
Sind die Anforderungen für eine Version festgelegt, so werden die Anforderungen in
JIRA eingepflegt. Dieser Schritt wird von den Entwicklern ausgeführt und wird nicht
direkt vom Werkzeug unterstützt.
Parallel zum Überführen in JIRA werden gegebenenfalls auch Zusammenfassungen der
Anforderungen exportiert, um Kunden oder anderen Abteilungen die Anforderungen
der nächsten Version zu zeigen. Hierbei werden vom Anforderungsverwaltungswerk-
zeug Sicherheitseinstufen beachtet, damit externe Kunden keine Anforderungen sehen,
für die sie nicht autorisiert sind.
• Qualitätssicherung:
Die Qualitätssicherung erfasst Testfälle und führt die im Anforderungsverwaltungs-
werkzeug verwalteten Testfälle aus. Schlägt ein Testfall fehl, so wird der entsprechende
Entwickler benachrichtigt.
• Entwickler:
Jeder Entwickler besitzt eentuell Leserechte. Er kann sich damit über die geplanten
Anforderungen und deren Änderungshistorie informieren. Außerdem übernehmen
die Entwickler das Übertragen von Anforderungen in JIRA. Dabei geben sie für jede
Anforderung in JIRA auch eine Referenz auf die entsprechende Anforderung in dem
Anforderungsverwaltungswerkzeug an.
Über die Frage, ob ein Entwickler auch Schreibrechte erhält, besteht Uneinigkeit. Die QS
wünscht sich Schreibrechte für Entwickler, damit diese Testfälle für ihre Anforderungen
erfassen können.
• Andere Abteilungen:
Andere Abteilungen werden mit dem Anforderungsverwaltungswerkzeug nicht di-
rekt in Berührung kommen. Sie bekommen jedoch eventuell Zusammenfassungen
der Anforderungen einzelner Versionen zu Informationszwecken. Dabei werden vom
Anforderungsverwaltungswerkzeug gegebenenfalls Sicherheitseinstufungen der Anfor-
derungen beachtet.
4.2 Marktübersicht über existierende
Anforderungsverwaltungswerkzeuge
Der Markt der Anforderungsverwaltungswerkzeuge ist vergleichsweise groß und unüber-
sichtlich. Es gibt die verschiedensten Werkzeuge von völlig unterschiedlichen Herstellern,
von der kleinen Software-Schmiede bis zum Weltkonzern. Aus diesem Grund haben
wir unsere Marktforschung auf einer schon vorhandenen Datenbank des „International
20
4.2 Marktübersicht über existierende Anforderungsverwaltungswerkzeuge
Council on Systems Engineering (INCOSE)“, einer Non-Profit-Organisation, die sich der
Verbesserung der Systementwicklung widmet, aufgebaut [INC]. Aus dieser Datenbank
stammen die meisten der untersuchten Werkzeuge. Weitere Quellen waren sowohl Hinweise
des Industriepartners auf bekannte oder in anderen Zusammenhängen untersuchte
Werkzeuge als auch eine weitere Werkzeugliste aus dem Internet [Too].
Diese Quellen haben wir schließlich zu einer Gesamtliste verdichtet, die wir auch
als Long List bezeichnen. In dieser Liste befanden sich schließlich 56 Werkzeuge, die wir
in den folgenden Phasen auf ihre Konformität zu den KO-Kriterien untersuchten. Die
untersuchten Werkzeuge sind:
• Accept Requirements
• Acclaro DFSS
• Accompa
• Aligned Elements
• Avenqo PEP
• Blueprint Requirements
Center
• Caliber-RM
• Cameo Requirements+
• Case Complete
• CASE Spec
• CodeBeamer
• Cognition Cockpit
• CORE
• Cradle
• Dimensions RM
• Enterprise Architect
• Envision VIP
• Excel
• GatherSpace
• GMARC
• IBM Rational DOORS
• IBM Rational Requisite-
Pro
• inteGREAT
• IRQA
• Jama Contour
• Kovair Global Lifecycle
• Leap SE
• Mac A&D and Win
A&D
• MagicDraw and SysML
Plugin
• MKS Integrity 2009
• MKS Requirements
• objectiF
• Open Source RM
• PACE
• PixRef Pro
• Polarion Requirements
• Project & Test Enginee-
ring System
• Projectricity
• Psoda
• Rally
• RaQuest
• ReqMan
• Reqtify
• Requirement Tracing
System
• Requirements Manager
• Requisite Pro
• RMTrak
• RTIME
• SoftREQ
• SpiraTest
• Team Foundation Ser-
ver
• Teamcenter Require-
ments
• TestTrackRM
• TopTeam Analyst
• TraceCloud
• TRUEreq
• What To Do Next
• workspace.com Requi-
rements Management
21

5 Erstellung der Short List
5.1 Definition der KO-Kriterien
Durch Interviews mit dem Industriepartner, eigene Erfahrungen mit verfügbaren Werk-
zeugen und Gespräche mit unserem Betreuer hat sich eine Liste von 9 sogenannten
„KO-Kritierien“ ergeben, die zur Vorauswahl geeigneter Werkzeuge verwendet wird.
KO-Kriterien sind als Minimalanforderungen zu betrachten, das heißt, ein Werkzeug
muss alle KO-Kriterien erfüllen, um in der Evaluation weiterhin berücksichtigt zu
werden. Werkzeuge, die mindestens eines der KO-Kriterien nicht erfüllen, werden für die
Einsatzzwecke des Industriepartners als nicht geeignet betrachtet und im weiteren Verlauf
der Untersuchung nicht mehr berücksichtigt. Durch dieses Vorgehen wird die enorme
Vielfalt an Anforderungswerkzeugen auf dem Markt rasch gefiltert und auf eine kürzere
Liste reduziert, die wir als „Short List“ bezeichnen.
Soweit zumindest die Theorie. In der Praxis hat sich herausgestellt, dass es nicht
immer sinnvoll ist, die KO-Kriterien zu hart anzuwenden. Manche der untersuchten
Werkzeuge haben einen ausgezeichneten Eindruck gemacht, „scheiterten“ dann allerdings
an einem KO-Kriterium, der Aufwandsbetrachtung. Wir haben uns daher entschlossen,
dieses Kriterium etwas aufzuweichen, um nicht vielversprechende Lösungen zu schnell
auszuschließen. Im Nachhinein hat sich dieses Vorgehen als sinnvoll erwiesen, da die als
KO-Kriterium aufgenommene Aufwandsbetrachtung bei der Gewichtung der Bewertungs-
kriterien letztlich doch nicht als allzu wichtig angesehen wurde. Auf der anderen Seite
ließen sich anhand dieses Kriteriums einige Werkzeuge ausschließen, die im Allgemeinen
keinen guten Eindruck gemacht haben, aber formal alle anderen KO-Kriterien erfüllten. An
diesem KO-Krtierium hat sich gezeigt, dass man sich bei der Evaluation von Werkzeugen
auf der einen Seite einen formalen Rahmen schaffen muss, sich auf der anderen Seite
allerdings nicht durch diesen Rahmen einengen lassen darf. Es sollte immer noch Platz für
eigene Entscheidungen und Ausnahmen sein. Das Ziel der Fachstudie ist, ein möglichst gut
geeignetes Werkzeug für den Industriepartner zu finden, und nicht das strikte Befolgen
selbst auferlegter Regeln und Kriterien.
Die Liste der KO-Kriterien ist:
1. Frei definierbare Attribute zu den Anforderungen
2. Berichte mit frei definierbaren Inhalten
3. Suchfunktion und Filter (speicherbar)
23
5 Erstellung der Short List
4. Versionsplanung
5. Aufwandsbetrachtung inkl. Worst-Case-Betrachtung
6. Verknüpfung zu JIRA
7. Änderungshistorie
8. Rechtekonzept
9. Betriebssystem Windows
Frei definierbare Attribute zu den Anforderungen Für die Anforderungsverwaltung soll es
möglich sein, neben den Standardattributen beliebige eigene Attribute zu einer Anforderung
zu definieren. Anlegbar, sofern nicht standardmäßig vorhanden, sollen dabei folgende
Attribute sein:
• Zeitaufwand
• Zeitaufwand im Worst-Case
• Priorität
• Typisierung
• Quelle
• Status
• Produkt
• Version im Produkt
• Links auf externe Dokumente
• Zielmaschine
Berichte mit frei definierbaren Inhalten Es sollen Berichte/Reports der Anforderungen
erstellt werden können. Diese Berichte sollen möglichst gut auf eigene Bedürfnisse anpassbar
sein, beispielsweise was die Menge der enthaltenen Anforderungen in einem Bericht angeht.
Auch soll es möglich sein, einzelne Attribute oder Anforderungen nicht in den Bericht
aufzunehmen.
Suchfunktion und Filter (speicherbar) Die Anforderungen sollen über eine Such- oder
Filterfunktion gefunden werden können. Suchfilter sollen dabei speicherbar sein, sodass sie
wiederverwendet werden können.
24
5.1 Definition der KO-Kriterien
Versionsplanung Den Anforderungen sollen Produktversionen zugeordnet werden kön-
nen, sodass das Werkzeug zur Versionsplanung genutzt werden kann. Es soll dabei auch
möglich sein, mithilfe von Filtern nur die Anforderung einer Version anzuzeigen. Sollte kein
entsprechendes Attribut standardmäßig vorhanden sein, so muss dieses anlegbar sein.
Aufwandsbetrachtung inkl. Worst-Case-Betrachtung Den Anforderungen sollen Aufwän-
de (beispielsweise in Entwicklungsstunden oder Mann-Tagen) zugeordnet werden können,
d.h. Schätzungen darüber, wie aufwändig die Umsetzung einer Anforderung für die Entwick-
lungsabteilung ist. Diese Schätzungen sollen über die Anforderungen in einer Produktversio-
nen oder einem Sprint summiert werden können, sodass die Gesamtzeit für die Umsetzung
der Anforderungen ersichtlich wird. Zudem soll möglichst eine weitere Schätzung abgegeben
werden können, die einen pessimistischen Wert enthält, um Worst-Case-Szenarien planen zu
können.
Verknüpfung zu JIRA Es soll möglich sein, zumindest in einer Richtung eine Verknüpfung
zu Issues im Issue-Tracking-System JIRA zu erstellen. Es soll entweder aus JIRA ein Link auf
eine Anforderung erstellt werden können, oder aus einer Anforderung heraus ein Link auf
ein JIRA-Issue. Dies wird benötigt, um später nachvollziehen zu können, welche Issues in
JIRA aus welcher Anforderung im Anforderungsverwaltungswerkzeug hervorgingen.
Änderungshistorie Da sich Anforderungen oftmals im Laufe der Zeit ändern, wird eine Än-
derungshistorie benötigt, mit welcher Änderungen an einer Anforderung gut nachvollzogen
werden können.
Rechtekonzept Der Zugriff auf die Anforderungen soll über die Vergabe von Rechten an
die Benutzer einschränkbar sein. Der Kreis der Personen mit schreibendem Zugriff wird
dabei sehr klein sein. Die Gruppe der Personen mit lesendem Zugriff wird tendenziell größer
sein. Möglicherweise wird die gesamte Abteilung lesenden Zugriff erhalten. Die Größe der
Gruppen ist dabei auch davon abhängig, ob eventuell weitere Bereiche, wie beispielsweise
die Testfallverwaltung, vom Anforderungsverwaltungswerkzeug unterstützt werden.
Die Rechte sollen direkt an Personen hängen. Eine zusätzliche Unterstützung von Gruppen
wäre jedoch wünschenswert.
Betriebssystem Windows Das Werkzeug muss clientseitig unter Windows 7 und dem
Internet Explorer 8 lauffähig sein. Serverseitig muss es unter Windows Server 2008 R2
laufen.
25
5 Erstellung der Short List
5.2 Filterung der Gesamtliste anhand der KO-Kriterien
Zur Filterung der 56 Werkzeuge der Gesamtliste anhand der KO-Kriterien wurde versucht,
zu jedem Werkzeug eine Evaluationslizenz zu erhalten, um die Kriterien auch tatsächlich am
Werkzeug überprüfen zu können. Dies hat in vielen Fällen auch in einer unbürokratischen
Weise funktioniert, es gab jedoch auch Hersteller, die auf Anfragen nicht reagiert haben. In
solchen Fällen haben wir versucht, anhand von vorhandener Dokumentation die Kriterien
zu überprüfen, was schlussendlich auch zum Ausschluss aller für uns nicht verfügbaren
Werkzeuge geführt hat. In den Abbildungen 5.2, 5.1, und 5.3 sind alle evaluierten Anfor-
derungsverwaltungswerkzeuge aufgeführt und es wird eine Auswertung zum detaillierten
Abschneiden bei den KO-Kriterien gegeben. !"#$%%$&
'$()$*&
!"#$ %&'()*+,-
!./,01).(
2$&'$,3$+45$/+&)'
65417 65417 65417 2$&'$,3$+45$/+&)'
8"+4,"11$,
!&9:4,$/;<114 !&9:4,$/;<114 !&9:4,$/;<114 6/;<114 !&9:4,$/;<114 !&9:4,$/;<114
2$&'$,3$+45$/+&)'
=),:"1> !&9:4,$/;<114 !&9:4,$/;<114
!&9:4,$/;<114
=),:"1> !&9:4,$/;<114 !&9:4,$/;<114 !&9:4,$/;<114
8.'?4&)'&$/4,'&9:4
6:$/,'$&' 6:$/,'$&' 6:$/,'$&' @$/#.41&9: 6:$/,'$&' @$/#.41&9: @$/#.41&9: 6:$/,'$&' 6:$/,'$&' A'($/$,B&$1C/.DD$
2$&'$,3$+45$/+&)'
!"#$ 2$&'$,3$+45$/+&)'
E$(&$'.'C,.'?1"/
2$&'$,3$+45$/+&)'
!&9:4,$/;<114 6:$/,'$&' A'($/$,B&$1C/.DD$
E$(&$'.'C,.'?1"/
$%&'( FGAHI 6/;<114 !&9:4,$/;<114 =)11,$/+$4J4,*$/($'
)'*'+,' !&9:4,$/;<114 K"4,("+,2/&4$/&.#,'&9:4,$/;<114
L
6/;<114 6/;<114,("+,2/&4$/&.#
@$/?'<D;.'C,
J*&+9:$',
%$/?J$.C,
.'(,MNOA
8/$&,
($;&'&$/>"/$,
A44/&>.4$,
=&9:4>"/?$&4,
;</,6PD)/4,
$&'+9:/Q'?$'
=.9:L,
;.'?4&)',.'(,
+D$&9:$/>"/$,
=.9:;&14$/
O$9:4$L,
?)'J$D4
@$/+&)'+L,
D1"'.'C
R'($/.'C+L,
:&+4)/&$
A.;*"'(+L,
>$4/"9:4.'C
%)/+4L0"+$L
E$4/"9:4.'C
=)'+4&C$,
A.++9:1.++C/<'($
-&&'./0
#'1234'5'+/60
7-&&'./089:;
-&&(<4=0>?@@
-&&=5.<
-(3*+',0$('5'+/6
-A'+1=0B$B
C(2'.43+/0
#'1234'5'+/60
!'+/'40D:E:
!<(3F'4G#H!
!<5'=0
#'1234'5'+/6I
!<6'0!=5.('/'!
!-@$0@.'&
!=,'C'<5'4
!=*+3/3=+0!=&J.3/
!4<,('
>35'+63=+60#H0
7>35#H;
$+/'4.436'0
-4&K3/'&/
$+A363=+0LMB
S'?1"/T,(",?$&'$,3$+45$/+&)',J./,@$/;<C.'C,)($/,%$/?$J.C,>$/$&4+,".+C$+9:&$($'
Abbildung 5.1: Überblick über die evaluierten Anforderungsverwaltungswerkzeuge(1)
Das Ergebnis der Überprüfung der KO-Kriterien ist in Abb. 5.4 in einem Tortendiagramm
veranschaulicht: Der Großteil der untersuchten Werkzeuge, 47 Stück, hat den Test nicht
bestanden, weil mehrere KO-Kriterien nicht erfüllt wurden, oder zwar nur das KO-Kriterium
der Aufwandsbetrachtung nicht erfüllt wurde, aber der sonstige Gesamteindruck nicht
positiv aus der Masse herausstechen konnte. Fünf Werkzeuge haben alle KO-Kriterien bis auf
die Aufwandsbetrachtung erfüllt, sind aber durch den positiven Eindruck, den sie bei den
ersten Evaluationsdurchläufen vermittelt haben, trotzdem in der Short List gelandet. Vier
Werkzeuge haben schließlich alle KO-Kriterien erfüllt, d.h. auch die Aufwandsbetrachtung
wurde hier explizit unterstützt.
26
5.2 Filterung der Gesamtliste anhand der KO-Kriterien
Tabelle1
Seite 1
Name Windows 7 
GatherSpace - Nicht erfüllt Erfüllt - Erfüllt - - - - - Erfüllt
GMARC - - - - - - - - - - Nicht erfüllt
Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt
Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Nicht erfüllt Erfüllt
- Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt - Erfüllt Erfüllt Erfüllt
IRQA Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Nicht erfüllt Erfüllt
Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Nicht erfüllt Erfüllt
ALM Studio Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt
- Nicht erfüllt - - - - Erfüllt - - -
Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt
Erfüllt Erfüllt Erfüllt Erfüllt Nicht erfüllt Erfüllt Erfüllt Erfüllt Nicht erfüllt Erfüllt
Erfüllt Erfüllt Erfüllt Erfüllt - Erfüllt Nicht erfüllt Erfüllt Nicht erfüllt Erfüllt
MKS Requirements - - - Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Nicht erfüllt -
- Nicht erfüllt Erfüllt Erfüllt Erfüllt - Erfüllt Erfüllt Erfüllt -
Open Source RM - - - Nicht erfüllt - - Erfüllt - - -
PACE Version 3 - Erfüllt Nicht erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt
Erfüllt Erfüllt - - Nicht erfüllt - Erfüllt Erfüllt - -
Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt Erfüllt
SQS Testprofessional Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt
- - - - - - - - - -
Zephyr - - - - - - - - - -
Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt Nicht erfüllt
Legende Nicht erfüllt Hat das Kriterium nicht erfüllt
- Unklar, da keine Testversion zur Verfügung oder Werkzeug bereits ausgeschieden
Erfüllt Erfüllt das Kriterium
Verknüpfung 
zwischen 
Werkzeug 
und JIRA
Frei 
definierbare 
Attribute 
Sichtbarkeit 
für Export 
einschränken
Such-
funktion und 
speicherbare 
Suchfilter 
Rechte-
konzept
Versions-
planung 
Änderungs-
historie 
Aufwands-
betrachtung
Worst-Case-
Betrachtung
IBM Rational 
DOORS
IBM Rational 
RequisitePro
inteGREAT  
Contour
Leap SE
workspace.com
Mac A&D and Win 
A&D 
MagicDraw and 
SysML Plugin
objectiF
PixRef Pro 
Polarion 
Requirements
QA 
Complete/Softwarepl
anner
Imbus Testbench
Abbildung 5.2: Überblick über die evaluierten Anforderungsverwaltungswerkzeuge(2)
Abbildung 5.4: Filterung der Gesamtliste anhand der KO-Kriterien
27
5 Erstellung der Short List
!"#$%%$&
'$()$*&
+",$ -(./012*3
4 4 5678%%) 4 5678%%) 4 5678%%) 5678%%) +(9:)*$678%%) +(9:)*$678%%)
!"#$%&'"(&(')* 4 4 4 4 4 4 4 4 4 4
!+#,-* 4 +(9:)*$678%%) 4 4 4 5678%%) 4 4 4 5678%%)
.-//) 4 4 4 4 4 4 4 4 4 4
.-01%+' 4 4 4 4 4 4 4 4 4 4
.%23-4*5%"+(#4*678 4 4 4 4 4 4 4 4 4 4
.%2'(9)* 4 4 4 4 4 4 4 4 4 4
4 4 4 4 4 4 4 4 +(9:)*$678%%) +(9:)*$678%%)
4 4 4 4 4 4 4 4 4 4
.3:"-;* 4 4 4 4 4 4 4 4 4 +(9:)*$678%%)
.:<3=* 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%)
>#9'.=0 4 4 4 4 4 4 4 4 4 4
>?("-:%+' 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) +(9:)*$678%%)
4 4 4 4 4 4 4 4 4 4
:%+':"-&;.3 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) +(9:)*$678%%)
:#?:%-@*A4-/)+' 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) 5678%%) +(9:)*$678%%)
:"-&%B/#1, +(9:)*$678%%) +(9:)*$678%%) 4 4 4 4 4 4 4 4
:.C="%2 4 +(9:)*$678%%) 4 4 4 4 4 4 4 4
4 4 4 4 4 4 4 4 4 4
!"#"$%" +(9:)*$678%%) ;")*/"2*<6()$6(=,*.(9:)*$678%%)
4 >.?%"6@*/"*?$(.$*!$2)A$62(0.*B=6*C$678D=.D*0/$6*-$6?B$=D*#$6$()2*"=2D$29:($/$.
5678%%) 5678%%)*/"2*<6()$6(=,
C$6?.8E7=.D*
B1(29:$.*
-$6?B$=D*
=./*FGHI
J6$(*
/$7(.($6#"6$*
I))6(#=)$*
'(9:)#"6?$()*
786*5KE06)*
$(.29:6L.?$.
'=9:7=.?)(0.*
=./*
2E$(9:$6#"6$*
'=9:7(%)$6
H$9:)$4
?0.B$E)
C$62(0.24
E%".=.D
M./$6=.D24
:(2)06($*
I=71"./24
#$)6"9:)=.D
-062)4N"2$4
O$)6"9:)=.D
!"#$%&'*D*:%+'*
=4E(4%%"(4E*>)+'%@*
F!:=>GH
.%21("%@%4'*:"-&(4E*
>)+'%@*
.%21("%@%4'+*3-4-E%"*
F.%3-H
:%-@&%4'%"*
.%21("%@%4'+
IJ-'*:#*K#*L%M'*
FI:KLH
Abbildung 5.3: Überblick über die evaluierten Anforderungsverwaltungswerkzeuge(3)
5.3 Short List
Tabelle 5.1 zeigt die Werkzeuge der Short List.
Name Hersteller
ALM Studio Kovair Software, Inc.
Polarion Requirements Polarion Software
RTIME QA Vantage
Workspace Workspace, Inc.
Rational Doors IBM
Contour Jama
TestTrackRM Seapine Software
TopTeam Analyst TechnoSolutions
IRQA Visure
Tabelle 5.1: Short List
Im Folgenden werden die Anforderungsverwaltungswerkzeuge kurz mit einer Beschreibung
und einem Screenshot vorgestellt.
28
5.3 Short List
ALM Studio
Das Anforderungsverwaltungswerkzeug ALM Studio1 von Kovair aus Kalifornien, USA,
erfüllt alle oben genannte KO-Kriterien. Ein Screenshot von ALM Studio ist in Abbildung
5.5 zu sehen. Die Stärken dieses Werkzeugs liegen vor allem in der Anpassbarkeit an
die eigenen Bedürfnisse sowie in der Aufwandsbetrachtung. So können zum Beispiel
die geplanten Aufwände pro Release schnell und übersichtlich betrachtet werden. Etwas
schlechter schneidet dieses Werkzeug dafür bei der Steuerbarkeit ab. Hier sind oft mehrere
Klicks nötig, um ein gewünschtes Ergebnis zu erreichen. Zudem ist es sehr langsam und
somit schwerfällig in der Benutzung.
Abbildung 5.5: Screenshot ALM Studio
1http://www.kovair.com/alm/index.aspx
29
5 Erstellung der Short List
Polarion Requirements
Polarion Requirements2 von Polarion mit Sitz in Nordamerika und Europa ist ein webbasier-
tes Werkzeug zur Anforderungsverwaltung. Ein Screenshot von Polarion Requirements ist
in Abbildung 5.6 zu sehen. Polarion bietet einige mächtige Funktionen, wie zum Beispiel
viele Exportformate und Templates für Exporte und Reports. Auch die Erfassung von
Anforderungen bietet alle gewohnten Funktionen und gute Formatierungsmöglichkeiten.
Außerdem gibt es einige verfügbare Adapter, unter anderem zu gängigen Testwerkzeugen.
Bei der Aufwandsbetrachtung und an einigen Stellen der Benutzeroberfläche müssen jedoch
Abstriche gemacht werden.
Abbildung 5.6: Screenshot Polarion Requirements
2http://www.polarion.com/products/requirements/index.php
30
5.3 Short List
RTIME
Das Anforderungsverwaltungswerkzeug RTIME3 vom Hersteller QA Vantage aus New
Jersey, USA, erfüllt alle KO-Kriterien. Insbesondere die Aufwandsbetrachtung inklusive
Worst-Case-Szenarien wird unterstützt. Das Werkzeug stellt auch einen Excel-Export zur
Verfügung, mit dem zwischen Excel und RTIME Daten ausgetauscht werden können. Es
sind also durchaus gute und interessante Ansätze vorhanden, die zu den Anforderungen des
Industriepartners passen, doch leider ist die Benutzeroberfläche nicht besonders ausgereift
und weist einige Fehler auf. Ein Screenshot von RTIME ist in Abbildung 5.7 zu sehen.
Abbildung 5.7: Screenshot RTIME
3http://qavantage.toolsforproductmanagement.com/index_files/rtimeE.asp
31
5 Erstellung der Short List
Workspace
Workspace4 von dem Unternehmen Workspace.com aus Owings Maryland, USA, bietet
die üblichen Funktionen im Bereich Anforderungsverwaltung und auch Funktionen für
verwandte Gebiete. Dabei ist es modular aufgebaut, sodass der Nutzer nur die für ihn
relevanten Teilbereiche bezahlen muss. Leider hat das Werkzeug in einigen Bereichen
Mängel, wie zum Beispiel beim Erzeugen von Reports, wo nur wenige Formate unterstützt
werden und der Inhalt der Reports nur in geringem Maße beeinflusst werden kann. Ein
Screenshot von Workspace ist in Abbildung 5.8 zu sehen.
Abbildung 5.8: Screenshot Workspace
4http://www.workspace.com/
32
5.3 Short List
Rational DOORS
Rational DOORS5 von IBM ist eins der erfolgreichsten Anforderungsverwaltungswerkzeuge
auf dem Markt. Ein Screenshot von DOORS ist in Abbildung 5.9 zu sehen. Mit diesem
Werkzeug ist es möglich, alle genannten KO-Kriterien zu realisieren, was jedoch teilweise
nur über die integrierte Skripting-Engine zu erreichen ist. Ein Beispiel hierfür ist vor
allem das KO-Kriterium Aufwandsbetrachtung. Durch das Implementieren eines solchen
Skripts ist DOORS an nahezu beliebige Anforderungen anpassbar, jedoch nur mit einem
beträchtlichen Mehraufwand im Vergleich zum klassischen Konfigurieren eines Werkzeugs.
Trotzdem sehen wir darin großes Potential und werden DOORS im Laufe dieser Arbeit noch
genauer betrachten.
Abbildung 5.9: Screenshot DOORS
5http://www-01.ibm.com/software/awdtools/doors/
33
5 Erstellung der Short List
Contour
Contour6 wird vom Hersteller Jama aus Oregon, USA, entwickelt. Ein Screenshot von
Contour ist in Abbildung 5.10 zu sehen. Dieses Anforderungsverwaltungswerkzeug erfüllt
alle KO-Kriterien bis auf das Kriterium Aufwandsbetrachtung vollständig, weshalb es in
die Kategorie „Ein KO-Kriterium nicht erfüllt“ fällt. Die Aufwandsbetrachtung ist nur über
den Umweg von Reports möglich und nicht direkt im Werkzeug unterstützt. Von diesem
Punkt abgesehen überzeugt es vor allem durch seine klare Struktur und einfache Bedienung.
Auch dieses Werkzeug bietet jede Menge Spielraum für individuelle Anpassungen und wäre
somit für TRUMPF sehr gut geeignet, weshalb es trotz des Mankos Aufwandsbetrachtung
einer genaueren Überprüfung unterzogen wird.
Abbildung 5.10: Screenshot Contour
6http://www.jamasoftware.com/contour/
34
5.3 Short List
TestTrackRM
TestTrackRM7 vom Hesteller Seapine Software aus Ohio, USA, besticht durch die
umfangreiche Unterstützung des Benutzers bei den typischen Standardaufgaben eines
Anforderungsverwaltungswerkzeugs: Das Anlegen und Verwalten von Anforderungen
bietet viele ausgereifte Features, die in einer gut bedienbaren Oberfläche integriert sind.
Die KO-Kriterien werden dabei bis auf die Aufwandsbetrachtung voll unterstützt: Hier
ist zwar eine Aufsummierung von geschätzten Arbeitsstunden möglich, auf eine weitere
Schätzung für Worst-Case-Szenarien gab es bei einem ersten Test aber keine Hinweise.
Da das Werkzeug sehr umfangreich und in vielen Aspekten anpassbar ist, können wir
allerdings auch nicht ausschließen, dass man das Werkzeug so konfigurieren kann, dass
Worst-Case-Szenarien ebenfalls ausgewertet werden können. In den Standardeinstellungen
wurde es aber nicht direkt unterstützt, sodass wir das Werkzeug in die Kategorie „Ein
KO-Kriterium nicht erfüllt“ aufnehmen. Ein Screenshot von TestTrackRM ist in Abbildung
5.11 zu sehen.
Abbildung 5.11: Screenshot TestTrackRM
7http://www.seapine.com/ttrm.html
35
5 Erstellung der Short List
TopTeam Analyst
Das Werkzeug TopTeam Analyst8 vom US-amerikanischen Hersteller TechnoSolutions hat
ebenfalls alle KO-Kriterien bis auf die Aufwandsbetrachtung bestanden, welche überhaupt
nicht unterstützt wird. Da das Werkzeug in den Standardaufgaben der Anforderungsverwal-
tung allerdings einen soliden Eindruck macht und gut bedienbar ist, wird es in die Short
List aufgenommen. Ein Screenshot von TopTeam Analyst ist in Abbildung 5.12 zu sehen.
Abbildung 5.12: Screenshot TopTeam Analyst
8http://www.technosolutions.com/topteam_requirements_management.html
36
5.3 Short List
IRQA
IRQA9 von Visure Solutions mit Niederlassungen u.a. in Deutschland erfüllt zwar
nicht alle KO-Kriterien (die Aufwandsbetrachtung wird hier nicht unterstützt), einige
Mitarbeiter von TRUMPF zeigten jedoch großes Interesse an diesem Werkzeug, so dass
wir es ebenfalls für eine detaillierte Bewertung aufnehmen. Es bietet neben vielfältigen
Formatierungsmöglichkeiten für Freitexte auch unterschiedliche Sichten auf Anforderungen.
Neben den unterstützten Sprachen Englisch und Spanisch ist die Homepage teilweise in
Deutsch verfügbar. Leider sind einige Funktionen in der Testversion nicht verfügbar. Ebenso
ist die Benutzerführung wenig überzeugend. Ein Screenshot von IRQA ist in Abbildung 5.13
zu sehen.
Abbildung 5.13: Screenshot IRQA
9http://www.visuresolutions.com/inicio
37

6 Bewertung der verbliebenen
Anforderungsverwaltungswerkzeuge
6.1 Vorgehen
Auf Basis der in der Analysephase geführten Interviews und der Erfahrungen, die wir bei
der Auswertung der KO-Kriterien gesammelt haben, wurden Kriterien gesucht, welche
eine Bewertung der Anforderungsverwaltungswerkzeuge und deren Vergleich ermöglichen
sollten. Hierzu erstellten wir eine Mindmap, die sowohl allgemeine als auch vom Industrie-
partner stammende Bewertungskriterien enthielt, wie z.B. die Usability und den Preis oder
den Umfang von Suchfiltern und die Aufwandsbetrachtung.
Aus dieser Sammlung von Kriterien wurden dann ein geordneter Katalog von Kriterien
erstellt. Nach Anfertigung und Ausformulierung der Bewertungskriterien hielten wir einen
Workshop bei unserem Industriepartner TRUMPF ab. Dort stellten wir die bereits gefunde-
nen Bewertungskriterien vor und nahmen weitere Vorschläge für Bewertungskriterien und
Verbesserungsvorschläge entgegen. Danach versuchten wir, eine Gewichtung der einzelnen
Kriterien zu erhalten, um deren Priorität zu erfahren. Dabei gaben wir allen acht anwesen-
den TRUMPF-Mitarbeitern ein Konto von 15 Punkten, welche sie über die im Folgenden
aufgeführten 11 Kriterien verteilen durften:
• Anforderungserfassung
• Anforderungsverwaltung
• Änderungshistorie
• Testunterstützung
• Rechtekonzept
• Reports
• Versionsplanung
• Aufwandsbetrachtung
• Installation und Administration
• Sonstiges
• Usability nach ISO 9241 parts 110
39
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Abbildung 6.1: Verteilung der Punkte auf die einzelnen Kriterien
Im Abschnitt 6.2 werden diese Kriterien genauer erläutert.
Bei der Punktevergabe mussten nicht alle Punkte vergeben werden und es waren Mehr-
fachvergaben möglich. Die Abbildung 6.1 zeigt die Verteilung der Punkte auf die einzelnen
Kriterien. Es konnten insgesamt 120 Punkte vergeben werden, wobei 2 Punkte nicht verteilt
wurden, wodurch sich die Summe der Punkte auf 118 beläuft.
Um die Anforderungsverwaltungswerkzeuge gut miteinander vergleichen zu können, benö-
tigten wir noch eine Priorisierung der Teilaspekte der einzelnen Kriterien. Dazu gingen wir
auf Vorschlag der TRUMPF-Mitarbeiter alle Unterpunkte durch, wobei diese die von ihnen
als sehr wichtig eingeschätzten Punkte durch Handmeldung anzeigten. So erhielten wir
nochmals eine Abstufung, welche Punkte besonders wichtig waren und daher im gesuchten
Anforderungsverwaltungswerkzeug gut umgesetzt sein sollten. Die genaue Priorisierung ist
im Abschnitt 6.2 in den Tabellen zu finden.
40
6.2 Bewertungskriterien
6.2 Bewertungskriterien
Im Folgenden werden die Bewertungskriterien, nach denen die Bewertung der Werkzeu-
ge stattfand, im Einzelnen beschrieben. Zur Bewertung der einzelnen Teilaspekte eines
Kriteriums wurden dabei folgende Skalen verwendet:
• Ja/Nein
• 4-Wertig (Sehr gut, Gut, Ausreichend, Ungenügend)
• Neutral für Eigenschaften, die nur erfasst werden. Beispielsweise der Preis.
Außerdem besitzen die Teilaspekte innerhalb ihrer Kriterien eine Wichtigkeit. Diese wurde
im vorher erläuterten Workshop erarbeitet.
6.2.1 Kriterium 1: Anforderungserfassung
Teilaspekt Skala Wichtigkeit
1.1 Attribute frei definierbar Ja/Nein 7
1.2 Kundenwünsche erfassbar 4-wertig 1
1.3 Freitextbeschreibung gut formatierbar 4-wertig 4
1.4 Abhängige Anforderungen unterstützt Ja/Nein 6
1.5 Anhänge zu Anforderungen Ja/Nein 8
Attribute frei definierbar Dieser Aspekt wurde bereits in den KO-Kriterien definiert und
geprüft. Er wurde nur der Vollständigkeit halber in der detaillierten Bewertung erneut
aufgeführt.
Kundenwünsche erfassbar Prüft, ob Kundenwünsche erfassbar sind. Kundenwünsche
sind Vorstufen von Anforderungen, aus denen später Anforderungen abgeleitet werden
können. Sollte die Erfassung von Kundenwünschen nicht möglich sein, so wird hier die
Note Ungenügend vergeben. Ausreichend ist die Erfassbarkeit unabhängig davon, ob sie
standardmäßig unterstützt wird oder durch selbst anzulegende Anforderungstypen reali-
siert werden muss. Sollte das Anforderungsverwaltungswerkzeug weitere unterstützende
Funktionen bieten, wird eine bessere Note gegeben.
Freitextbeschreibung gut formatierbar Die Unterstützung von Formatierungen im Freitext
ist bei den geprüften Werkzeugen stark unterschiedlich. Eine bloße Unterstützung der
Standardformatierungen Fett/ Kursiv/ Unterstrichen ist ausreichend. Für eine bessere Note
müssen weitere Formatierungsmöglichkeiten vorhanden sein. Beispiele wären Aufzählungen,
Links, Bilder und Templates.
41
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Abhängige Anforderungen unterstützt Es soll möglich sein, die Abhängigkeiten zwischen
Anforderungen zu erfassen. Damit soll z.B. erfasst werden können, dass eine von A abhängige
Anforderung B nicht vor Anforderung A entwickelt werden darf.
Anhänge zu Anforderungen Oftmals ist es nötig, zu einer Anforderung erklärende Doku-
mente, oder Skizzen anzugeben. Weiterhin könnte es nötig sein, die Dokumente anzugeben,
aus denen die Anforderung abgeleitet wurde. Dafür soll es möglich sein, Anhänge an
Anforderungen zu hängen.
6.2.2 Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Wichtigkeit
2.1 Anforderungen importierbar 4-wertig 4
2.2 API-Zugriff Ja/Nein 5
2.3 Anforderungen exportierbar 4-wertig 8
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig 5
2.5 Suchfilter (privat und öffentlich) 4-wertig 8
2.6 Traceability (zu JIRA) unidirektional Ja/Nein 0
2.7 Traceability (zu JIRA) bidirektional Ja/Nein 5
2.8 Hierarchie der Anforderungen Ja/Nein 3
2.9 Verknüpfung zw. Anforderungen verschiedener Projek-
ten
Ja/Nein -
Anforderungen importierbar Es wird erfasst, ob Anforderungen importierbar sind und in
welchen Formaten dies möglich ist.
API-Zugriff Es wird geprüft, ob ein Zugriff über eine API möglich ist. Dies würde das
Übertragen von Anforderungen aus anderen Systemen, beispielsweise dem bei TRUMPF
im Support eingesetzten Werkzeug SIS, in das Werkzeug erleichtern. Ebenso wäre die
Entwicklung eines Adapters zur Anbindung an den verwendeten Issue-Tracker JIRA möglich,
sofern ein solcher vom Werkzeug nicht ohnehin mitgeliefert wird.
Anforderungen exportierbar Die möglichen Exportformate für Anforderungen werden
erfasst.
Mehrere Sichten auf Anforderungen möglich Anforderungen können auf unterschiedliche
Weise dargestellt werden. Zwei verbreitete Sichten sind die Tabellensicht und die Dokumen-
tensicht. In diesem Teilaspekt soll geprüft werden, wie viele und welche Sichten von dem
Werkzeug unterstützt werden und wie gut diese an die persönlichen Bedürfnisse anpassbar
sind.
42
6.2 Bewertungskriterien
Suchfilter (privat und öffentlich) In diesen Teilaspekt werden die Möglichkeiten zur Su-
che untersucht. Positiv sind Merkmale wie das Suchen auf bestimmten Attributen, die
Möglichkeit zur logischen Verknüpfung mehrerer Suchkriterien und andere unterstützende
Funktionen. Außerdem soll die Suchanfrage speicherbar sein, um oft verwendete Suchkrite-
rien einfach und effizient nutzen zu können.
Traceability (zu JIRA) unidirektional Es soll die Möglichkeit geben, einer Anforderung im
Werkzeug ein Issue in JIRA zuzuordnen. Ob die Zuordnung über einfache Links oder über
spezielle Funktionen des Werkzeugs geschieht ist irrelevant.
Traceability (zu JIRA) bidirektional Es soll die Möglichkeit geben, einem Issue in JIRA eine
Anforderung im Werkzeug zu zuordnen. Die Art der Zuordnung ist auch hier irrelevant.
Hierarchie der Anforderungen Anforderung sollen in einer Hierarchie strukturiert werden
können.
Verknüpfung zwischen Anforderungen verschiedener Projekte Es soll möglich sein, diese
Verknüpfung auch über Projektgrenzen innerhalb der Abteilung hinweg zu erstellen.
6.2.3 Kriterium 3: Änderungshistorie
Teilaspekt Skala Wichtigkeit
3.1 Granularität der Änderungshistorie 4-wertig 4
3.2 Kommentar angebbar Ja/Nein 5
3.3 Erklärende Dokumente angebbar Ja/Nein 5
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig 6
3.5 Suche in alten Versionen Ja/Nein 1
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig 3
Granularität der Änderungshistorie Dieser Teilaspekt betrachtet die Granularität der Än-
derungshistorie. Es wird untersucht, ob sich nur die Änderungen des ganzen Projekts
betrachten lassen, oder auch einzelner Anforderungen oder gar noch detaillierter.
Kommentar angebbar Zu einer Änderung sollten Kommentare angebbar sein, um die
Änderung und gegebenenfalls ihren Grund zu beschreiben.
43
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Erklärende Dokumente angebbar Zu einer Änderung sollten Dokumente referenziert wer-
den können, um beispielsweise Dokumente, auf Basis derer die Änderung vorgenommen
wurde, anzugeben.
Unterschiede mehrerer Versionen anzeigbar Das Werkzeug sollte eine möglichst übersicht-
liche Funktion zum Vergleich verschiedener Versionen besitzen. Dabei wird unter anderem
betrachtet, ob der Vergleich nur die Änderung der Beschreibung betrachtet, oder auch die
der Attribute.
Suche in alten Versionen Es wird geprüft, ob die Suche auch alte Versionen berücksichtigt.
Dies erleichtert das Finden von Anforderungen anhand von Schlagworten, welche in einer
neueren Version eventuell ersetzt wurden.
Benachrichtigung bei Änderungen (Beobachtungen) Es wird untersucht, ob das Werkzeug
eine Funktion zum Beobachten von Änderungen besitzt. Wenn dies der Fall ist, so wird
ebenfalls untersucht, wie feingranular Beobachtungen definiert werden können.
6.2.4 Kriterium 4: Testunterstützung
Teilaspekt Skala Wichtigkeit
4.1 Testfälle erfassbar Ja/Nein 4
4.2 Testdurchführung unterstützt Ja/Nein 3
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein -
Testfälle erfassbar
• Die Testfälle müssen mit einzelnen, unterteilten Testschritten beschreibbar sein.
• Dabei müssen die Testschritte einzelnen dargestellt werden können, der Testfall darf
nicht nur als „Fließtext“ beschreibbar sein.
• Testfälle müssen als Testschritt in einen anderen Testfall eingefügt werden können.
• Testfälle müssen in allgemeiner Form mit Aufrufparametern definiert werden können
(ähnlich wie Funktionen in einer Programmiersprache).
Die genannten Punkte haben den Charakter von KO-Kriterien, d.h. sie müssen alle erfüllt
sein, damit das Werkzeug das Kriterium bestehen kann.
Testdurchführung unterstützt Konkrete Tests müssen aus den Testfällen durch Belegen der
Parameter mit realen Werten ableitbar sein.
44
6.2 Bewertungskriterien
Verknüpfung zw. Testfall und Anforderungen Es wird geprüft, ob eine Verknüpfung zwi-
schen einer Anforderung und einem oder mehreren Testfälle, welche die korrekte Umsetzung
der Anforderung überprüfen, möglich ist.
6.2.5 Kriterium 5: Rechtekonzept
Teilaspekt Skala Wichtigkeit
5.1 Granularität der Rechtevergabe Neutral 0
5.2 Unterstützung für Gruppen Ja/Nein 7
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein 1
Granularität der Rechtevergabe Es wird erfasst, wie detailliert die Rechte für unterschied-
liche Funktionen an unterschiedliche Personen vergeben werden können.
Unterstützung für Gruppen Es wird geprüft, ob Personen einer Gruppe zugeordnet werden
können, für welche dann gesammelt die gleichen Rechte vergeben werden.
Anbindung an bestehende Benutzerverwaltung (LDAP) Es wird geprüft, ob das Werkzeug
mit dem vorhandenen LDAP zusammenarbeiten kann, um so den Aufwand der Benutzer-
verwaltung gering zu halten.
6.2.6 Kriterium 6: Reports
Teilaspekt Skala Wichtigkeit
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig 5
6.2 Exportformate (weiterverarbeitbar) 4-wertig 7
6.3 Exportformate (nicht weiterverarbeitbar) 4-wertig 0
6.4 Druckfunktion Ja/Nein 0
Granularität der Sichtbarkeit (Templates) Es wird geprüft, wie detailliert Reports gestaltet
werden können. Die Bandbreite bewegt sich von Reports, die immer alle Anforderungen mit
deren Attributen enthalten bis hin zu sehr feingranularer Regelbarkeit bis auf Attributebene.
Ein Beispiel hierfür wäre ein Report, der alle Anforderungen mit höchster Priorität enthält.
Ebenso wird geprüft, ob Templates angelegt werden können.
Exportformate (weiterverarbeitbar) Es wird erfasst, welche weiterverarbeitbaren Formate
das Werkzeug bei Reports unterstützt.
45
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Exportformate (nicht weiterverarbreitbar) Es wird erfasst, welche nicht weiterverarbeitba-
ren Formate das Werkzeug bei Reports unterstützt.
Druckfunktion Es wird untersucht, ob das Werkzeug einen direkten Ausdruck von Reports
ohne Umwege über andere Programme unterstützt.
6.2.7 Kriterium 7: Versionsplanung
Teilaspekt Skala Wichtigkeit
7.1 Wird unterstützt Ja/Nein 0
7.2 Eindruck 4-wertig -
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein 7
7.4 Unterstützung für abhängige Anforderungen Ja/Nein 6
Wird unterstützt Es wird geprüft, ob eine Versionsplanung vom Werkzeug unterstützt wird.
Die Versionsplanung soll dabei nur auf der aus den KO-Kriterien bekannten hohen Ebene
unterstützt werden.
Eindruck Dieser Teilaspekt betrachtet den Gesamteindruck, den die Unterstützung der
Versionsplanung im Werkzeug macht.
Unterstützung für Entwicklung über mehrere Takte Bei der Versionsplanung soll die Ent-
wicklung von Arbeitspaketen über mehrere Takte unterstützt werden. Ein solcher Fall kann
zum Beispiel auftreten, wenn eine Anforderung zu groß ist, um in einem Takt umgesetzt zu
werden.
Unterstützung für abhängige Anforderungen Analog zum obigen Teilaspekt soll die Versi-
onsplanung Unterstützung für abhängige Anforderungen bieten.
6.2.8 Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Wichtigkeit
8.1 Wird unterstützt Ja/Nein 4
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein 4
8.3 Unterstützung für abhängige Anforderungen Ja/Nein 3
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein 8
8.5 Eindruck 4-wertig -
46
6.2 Bewertungskriterien
Wird unterstützt Es soll möglich sein, den Entwicklungsaufwand einer Anforderung an-
zugeben, um daraus die Summe über die Aufwände aller Anforderungen einer Version zu
berechnen.
Unterstützung für Entwicklung über mehrere Takte Bei der Berechnung der Summe der
Aufwände soll auch berücksichtigt werden, wenn eine Anforderung über mehrere Takte
verteilt entwickelt werden soll. Das heißt, dass der Aufwand entsprechend geringer in die
Summe einfließen muss.
Unterstützung für abhängige Anforderungen Abhängigkeiten zwischen Anforderungen
sollen bei der Aufwandsbetrachtung ebenso unterstützt werden. Der Aufwand einer Anforde-
rung A, die Vorraussetzung für eine andere Anforderung B ist, muss also bei Verwirklichung
von B auch mit in die Summe der Aufwände einberechnet werden.
Unterstützung für verschiedene Szenarien Die oben beschriebenen Berechnungen sollen
parallel zu den normalen Aufwänden auch mit einer Worst-Case-Schätzung der Aufwände
möglich sein.
Eindruck Dieser Teilaspekt betrachtet den Gesamteindruck, den die Unterstützung der
Aufwandsbetrachtung im Werkzeug macht.
6.2.9 Kriterium 9: Installation und Administration
Innerhalb des Kriteriums wurde keine Priorisierung der Teilaspekte vorgenommen.
Teilaspekt Skala Wichtigkeit
9.1 Installationsaufwand 4-wertig -
9.2 Archivierung von Anforderungen möglich Ja/Nein -
9.3 Integration mit anderen Werkzeugen Neutral -
9.4 Support Neutral -
9.5 Konfigurationsaufwand 4-wertig -
9.6 Aufwand der Benutzerverwaltung 4-wertig -
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral -
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral -
Installationsaufwand Es wird geprüft, wie aufwändig die Installation des Werkzeugs ist.
47
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Archivierung von Anforderungen möglich Nach Möglichkeit soll das Werkzeug eine Ar-
chivierungsfunktion besitzen, sodass alte Anforderungen zwar noch erhalten sind, aber nicht
mehr standardmäßig im Werkzeug angezeigt werden, um die Übersichtlichkeit auch nach
mehrjährigem Betrieb zu erhalten.
Integration mit anderen Werkzeugen Es werden die Möglichkeiten der Integration mit
anderen Werkzeugen erfasst. Insbesondere die Integration mit JIRA ist hier von Interesse,
aber auch die mögliche Integration mit Testfallverwaltungswerkzeugen.
Support Es wird erfasst, welche Supportmöglichkeiten vom Hersteller angeboten werden.
Konfigurationsaufwand Das Werkzeug sollte gut konfigurierbar sein. Daher wird der Auf-
wand der Konfiguration, um den gewünschten Funktionsumfang zu erreichen, bewertet.
Aufwand der Benutzerverwaltung Ebenso wie der Konfigurationsaufwand soll der Auf-
wand der Benutzerverwaltung bewertet werden.
Administrationsoberfläche als Web-Client verfügbar Es wird erfasst, ob die Administrati-
onsoberfläche als Web-Client verfügbar ist.
Administrationsoberfläche als Standalone-Client verfügbar Analog zum vorherigen Teila-
spekt wird erfasst, ob die Administrationsoberfläche als Standalone-Client verfügbar ist.
6.2.10 Kriterium 10: Sonstiges
Innerhalb des Kriteriums wurde keine Priorisierung der Teilaspekte vorgenommen.
Teilaspekt Skala Wichtigkeit
10.1 Sprache Neutral -
10.2 Kosten/Lizenzmodell Neutral -
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig 6
10.4 Projektbezogene Konfiguration 4-wertig 6
10.5 Anwendung ist als Web-Client verfügbar Neutral -
10.6 Anwendung ist als Standalone-Client verfügbar Neutral -
Sprache Das System muss mindestens Englisch und optional Deutsch unterstützen. Weitere
Sprachen werden ebenso erfasst.
48
6.2 Bewertungskriterien
Kosten/Lizenzmodell Es wird das Lizenzmodell und die durch das Werkzeug entstehenden
Kosten geprüft. Als Basis für einen Vergleich kann hier ein Betrieb von 15 Clients und einem
Server angenommen werden.
Weitere Entwicklung der Software wahrscheinlich Es wird abgeschätzt, wie wahrscheinlich
eine Weiterentwicklung des Werkzeugs in der Zukunft ist. Als Basis dafür können die Größe
der Firma, der Zustand der Homepage oder die Reaktion auf Anfragen dienen. Auch alles
andere, was sonst einen Eindruck von der Wahrscheinlichkeit der Weiterentwicklung des
Werkzeugs geben kann, wird beachtet.
Projektbezogene Konfiguration Das Werkzeug soll es ermöglichen, projektbezogene Kon-
figurationen zu erstellen. Jedes Projekt soll so erscheinen, als sei es völlig unabhängig von
allen anderen Projekten. Damit wird es möglich, das Werkzeug auch in anderen Abteilungen
einzusetzen, ohne dass sich die Abteilungen gegenseitig beeinflussen.
Anwendung ist als Web-Client verfügbar Es wird erfasst, ob das Werkzeug als Web-Client
zur Verfügung steht.
Anwendung ist als Standalone-Client verfügbar Analog zum obigen Teilaspekt wird er-
fasst, ob das Werkzeug als Standalone-Client zur Verfügung steht.
6.2.11 Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig -
11.2 Selbstbeschreibungsfähigkeit 4-wertig -
11.3 Steuerbarkeit 4-wertig -
11.4 Erwartungskonformität 4-wertig -
11.5 Fehlertoleranz 4-wertig -
11.6 Anpassbarkeit 4-wertig -
11.7 Erlernbarkeit 4-wertig -
Aufgabenangepasstheit Es wird geprüft, wie gut die Benutzeroberfläche auf den Anwen-
dungsbereich angepasst ist. Das Werkzeug sollte alles anbieten, was nötig ist, ohne unnötige
Arbeitsschritte einzuführen.
Selbstbeschreibungsfähigkeit Es wird geprüft, ob die Benutzeroberfläche so aufgebaut ist,
dass ein Benutzer sich möglichst einfach zurechtfinden kann. Die wichtigsten Funktionen
sollten schnell und ohne Studium einer Anleitung verstanden werden.
49
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Steuerbarkeit Es wird geprüft, ob der Benutzer jederzeit die volle Kontrolle über das
System hat, oder ob das System dem Benutzer Kontrollmöglichkeiten ohne ersichtlichen
Grund vorenthält.
Erwartungskonformität Es wird geprüft, ob die Benutzeroberfläche den Erwartungen des
Nutzers entspricht. Hierzu gehört beispielsweiße, dass übliche Elemente einer Benutzero-
berfläche die gleiche Funktion haben, wie allgemein üblich. Ein Negativbeispiel wäre die
Benutzung von Checkboxen als Radiobuttons.
Fehlertoleranz Es wird geprüft, ob das Werkzeug tolerant gegenüber fehlerhaften Eingaben
ist. Fehlerhafte Eingaben sollten entweder verhindert werden oder mit möglichst geringem
Aufwand erkennbar und behebbar sein.
Anpassbarkeit Es wird geprüft, ob die Benutzeroberfläche gut an die eigenen Bedürfnisse
anpassbar ist. Eine angepasste Benutzeroberfläche erleichtert dem Benutzer die Bedienung
des Programms, da nur benötigte Elemente angezeigt werden.
Erlernbarkeit Es wird geprüft, ob das Werkzeug den Bedienenden im Lernprozess unter-
stützt. Dazu gehören beispielsweiße geeignete Hilfefunktionen. Das Ziel ist eine möglichst
geringe Einlernzeit.
6.3 Detaillierte Bewertung der Werkzeuge
6.3.1 Contour
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig gut
1.3 Freitextbeschreibung gut formatierbar 4-wertig sehr gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Der Punkt „Kundenwünsche erfassbar“ wird zwar nicht
standardmäßig unterstützt, kann jedoch schnell hinzugefügt werden.
Bei den abhängigen Anforderungen kann hier unterschieden werden zwischen abhängigen
und verwandten Anforderungen, wobei dies alles in einer Übersicht anzeigbar ist.
50
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig sehr gut
2.2 API-Zugriff Ja/Nein Ja
2.3 Anforderungen exportierbar 4-wertig gut
2.4 Mehrere Sichten auf Anforderungen möglich (Anpass-
bar)
4-wertig gut
2.5 Suchfilter (privat und öffentlich) 4-wertig sehr gut
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Ja
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Ja
Anmerkungen/Besonderheiten Als Importformate bietet dieses Werkzeug Microsoft Word
und Excel sowie XML- und CSV-Importe. Exportiert werden können die Anforderungen
nach Microsoft Word und Excel sowie PDF und HTML.
Die verschiedenen Sichten auf eine Anforderungen sind hier mit einer übersichtlichen
Tabellen- oder Dokumentenansicht besonders schön gelöst.
Grundsätzlich existiert ein Plugin-System, um Contour zu erweitern. Es ist jedoch fraglich,
ob Eigenentwicklungen möglich sind.
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig sehr gut
3.2 Kommentar angebbar Ja/Nein Ja
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig gut
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig gut
Anmerkungen/Besonderheiten Bei der Änderungshistorie lässt sich durch einen Filter
regulieren, welche Änderungen angezeigt werden. Dabei gibt es diverse Filtermöglichkeiten,
wie z.B. nach einem bestimmten Attribut oder einem bestimmten Zeitraum. Dabei wird bei
den Änderungen direkt ein Vergleich angezeigt, was sich verändert hat. Es ist jedoch auch
möglich, verschiedene Versionen untereinander zu vergleichen, welche nicht direkt vor oder
nach der zu vergleichenden Version erstellt wurden.
51
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Contour hat zwar eine schöne und übersichtliche Möglich-
keit, Testfälle zu verwalten, jedoch erfüllt es einige KO-Kriterien, welche wir von TRUMPF zu
diesem Thema bekommen haben, nicht. Dazu gehört unter anderem, dass Testfälle nicht als
Testschritt in einen anderen Testfall eingefügt werden können, sondern dass ein Testschritt
aus Fließtext besteht. Des Weiteren ist keine Unterstützung für das Definieren von Testfällen
mit Aufrufparametern vorgesehen.
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral gut
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Ja
Anmerkungen/Besonderheiten Rechte können über alle Projekte hinweg, pro Projekt, pro
Unterprojekt oder pro Art der zu erfassenden Dokumente (zum Beispiel für Testfälle, Use-
Cases und Anforderungen in einem Unterprojekt) vergeben werden. Eine Rechtevergabe pro
einzelner Anforderung ist nicht möglich.
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig sehr gut
6.2 Exportformate (weiterverarbeitbar) 4-wertig gut
6.3 Exportformate (nicht weiterverarbeitbar) 4-wertig gut
6.4 Druckfunktion Ja/Nein Ja
Anmerkungen/Besonderheiten Es ist möglich, für die Reports eigene Templates zu er-
stellen, wodurch man viele Freiheiten beim Generieren von Reports hat. Auch stehen von
Anfang an Reports zur Verfügung, welche ein schönes Standard-Layout bieten. Als weiter-
verarbeitbare Exportformate stehen Microsoft Word und Excel zur Verfügung, für die nicht
weiterverarbeitbaren HTML und PDF.
52
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig gut
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten Die Versionsplanung ist standardmäßig vorhanden, wo-
durch man sich bequem alle Anforderungen einer Produktversion anzeigen lassen kann.
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Nein
8.5 Eindruck 4-wertig ausreichend
Anmerkungen/Besonderheiten Eine Aufwandsbetrachtung ist nur über Umwege durch
das Erstellen eines Reports möglich.
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig gut
9.2 Archivierung von Anforderungen möglich Ja/Nein Ja
9.3 Integration mit anderen Tools Neutral siehe An-
merkungen
9.4 Support Neutral siehe An-
merkungen
9.5 Konfigurationsaufwand 4-wertig gut
9.6 Aufwand der Benutzerverwaltung 4-wertig sehr gut
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Ja
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Nein
53
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Anmerkungen/Besonderheiten Folgende Werkzeuge können mit Contour integriert wer-
den: JIRA, Jive SBS, Enterprise Architecture, Atlassian Crowd. Dabei ist vor allem der JIRA
Connector wichtig, da Trumpf das Anforderungsverwaltungswerkzeug an das vorhandene
JIRA anbinden möchte.
Für den Support bietet Contour zwei verschiedene Modelle. Das Standardmodell bietet
unbegrenzten Support an Werktagen und ein 24-h-Ticketsystem. Das Premiummodell bietet
24/7 „Customized-Service“ sowie Unterstützung bei der Produktintegration, technische und
strategische Beratung und Endbenutzerschulungen.
Das Werkzeug bietet bereits eine zu den Anforderungen weitgehend kompatible Stan-
dardkonfiguration, sodass hier mit wenig Aufwand zu rechnen ist. Der Aufwand für die
Benutzerverwaltung ist ebenfalls gering, da man Contour einfach an das bereits vorhandene
LDAP anbinden kann.
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral englisch
10.2 Kosten/Lizenzmodell Neutral siehe An-
merkungen
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig gut
10.4 Projektbezogene Konfiguration 4-wertig gut
10.5 Anwendung ist als Web-Client verfügbar Neutral Ja
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Nein
Anmerkungen/Besonderheiten Die Kosten für Contour belaufen sich auf durchschnittlich
59 US-Dollar pro Benutzer und Monat. Dabei gibt es zwei verschiedene Modelle. Beim einen
zahlt man im Intervall von 3 Jahren immer weniger und ist dann auf einem günstigeren
Kostenlevel, während das andere Modell in jedem Jahr gleich viel kostet.
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig gut
11.3 Steuerbarkeit 4-wertig sehr gut
11.4 Erwartungskonformität 4-wertig gut
11.5 Fehlertoleranz 4-wertig gut
11.6 Anpassbarkeit 4-wertig sehr gut
11.7 Erlernbarkeit 4-wertig sehr gut
54
6.3 Detaillierte Bewertung der Werkzeuge
Anmerkungen/Besonderheiten Wie schon erwähnt ist einer der Stärken dieses Werkzeugs
die Usability. Es ist bereits nach kurzer Zeit möglich, alle Funktionen von Contour einzu-
setzen, da es einheitlich aufgebaut ist. Des Weiteren bietet es die Möglichkeit, Module oder
Bausteine nach den eigenen Anforderungen hinzuzufügen und zu entfernen.
6.3.2 Rational DOORS
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig gut
1.3 Freitextbeschreibung gut formatierbar 4-wertig gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten Allgemein ist zur Anforderungserfassung zu sagen,
dass hier nicht zwischen Textbausteinen wie Überschriften und echten Anforderungen
unterschieden werden kann.
Der Punkt „Kundenwünsche erfassbar“ wird nicht standardmäßig unterstützt, kann jedoch
recht schnell hinzugefügt werden.
Es ist möglich, Bilder zu einer Anforderung hinzuzufügen. Dokumente an Anforderungen zu
hängen ist nicht möglich. Jedoch ist es hier möglich, Links zu einem Dokument zu definieren.
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig gut
2.2 API-Zugriff Ja/Nein Ja
2.3 Anforderungen exportierbar 4-wertig sehr gut
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig gut
2.5 Suchfilter (privat und öffentlich) 4-wertig sehr gut
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Ja
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Ja
55
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Anmerkungen/Besonderheiten Als Importformate bietet dieses Werkzeug .txt, .rtf, .csv
und Framemaker. Exportiert werden können die Anforderungen nach Microsoft Word, Excel,
Powerpoint und Outlook sowie in die Formate .txt, .rtf, .csv, Framemaker und HTML.
Suchfilter können bei DOORS über eine umfangreiche Maske sehr komfortabel angelegt
werden. Auch Verknüpfungen zwischen einzelnen Filtern sind möglich. Ein weiteres Feature
ist eine statistische Auswertung über das Ergebnis eines Filters.
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig gut
3.2 Kommentar angebbar Ja/Nein Ja
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig gut
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig ungenügend
Anmerkungen/Besonderheiten Es gibt verschiedene Möglichkeiten, sich bei DOORS Ände-
rungen von Anforderungen anzeigen zu lassen. Zum einen kann man bei der Anforderung
selbst deren aktuelle Historie sehen. Hier kann gefiltert werden, in welchem Zeitraum oder
von welchem Benutzer die Änderung durchgeführt wurde. Eine andere Möglichkeit ist, zwei
Baselines zu vergleichen. Hier kann dann über einen Wizard eingestellt werden, welche
Änderungen man gerne sehen würde.
Bei der uns zur Verfügung stehenden Version von DOORS war es nicht möglich, sich Be-
nachrichtigung bei Änderungen zukommen zu lassen, so dass wir für diesen Punkt nur ein
Ungenügend vergeben konnten.
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten DOORS bietet direkt keine spezielle Unterstützung für die
Testfallverwaltung. Die Testfallverwaltung bietet die selben Funktionen wie die Anforde-
rungsverwaltung.
56
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral sehr gut
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Ja
Anmerkungen/Besonderheiten Rechte können bis runter auf die Anforderungsebene ver-
geben werden.
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig sehr gut
6.2 Exportformate (weiterverarbeitbar) 4-wertig sehr gut
6.3 Exportformate (nicht weiterverarbeitbar) 4-wertig gut
6.4 Druckfunktion Ja/Nein Ja
Anmerkungen/Besonderheiten Es ist möglich, aus einer Sicht einen Report zu erstellen.
Auch das Layout dieses Reports ist anpassbar. Die weiterverarbeitbaren Exportformate sind
.txt, .rtf, .csv, sowie Exporte nach Microsoft Word, Excel, Powerpoint und Outlook. Das nicht
weiterverarbeitbare Format ist HTML.
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig ausreichend
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten Es ist keine Versionsplanung standardmäßig enthalten, so
dass die Versionsplanung über ein selbst dafür angelegtes Attribut läuft. Dadurch gibt es
auch keine weitere Unterstützung zur Versionsplanung.
57
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Ja
8.5 Eindruck 4-wertig gut
Anmerkungen/Besonderheiten Es wird keine Aufwandsbetrachtung standardmäßig unter-
stützt. Da jedoch DOORS eine integrierte Skriptsprache hat, ist es möglich, darüber eine
Aufwandsbetrachtung zu realisieren.
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig ausreichend
9.2 Archivierung von Anforderungen möglich Ja/Nein Ja
9.3 Integration mit anderen Tools Neutral siehe An-
merkungen
9.4 Support Neutral siehe An-
merkungen
9.5 Konfigurationsaufwand 4-wertig ungenügend
9.6 Aufwand der Benutzerverwaltung 4-wertig sehr gut
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Ja
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Ja
Anmerkungen/Besonderheiten DOORS ist mit allen IBM-Rational-Produkten integrierbar.
Ansonsten gilt hier das Motto: DOORS integriert nicht, sondern wird integriert.
Die Installation gestaltet sich sehr schwierig und ist schlussendlich nicht mehr reprodu-
zierbar, wenn man es dann doch geschafft hat. Durch die integrierte Skriptsprache ist zwar
vieles in DOORS möglich, doch erst nach einem gewissen Implementierungsaufwand. Daher
gestaltet sich die Konfiguration aufwändig und bekommt nur ein Ungenügend.
Bei jeder neu erworbenen Lizenz bietet IBM kostenlos für 12 Monate Produktaktualisierun-
gen sowie technische Unterstützung per Telefon und online rund um die Uhr.
58
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral englisch
10.2 Kosten/Lizenzmodell Neutral siehe An-
merkungen
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig ausreichend
10.4 Projektbezogene Konfiguration 4-wertig gut
10.5 Anwendung ist als Web-Client verfügbar Neutral Ja
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Ja
Anmerkungen/Besonderheiten Die Kosten für DOORS variieren stark je nach Modell und
sind auch teilweise Verhandlungssache. Grob kann man sagen, dass man für eine Lizenz für
ein Jahr mit etwa 4500 – 11000 Euro rechnen muss.
Aus mehreren unabhängigen Quellen haben wir in Erfahrung gebracht, dass die Wahrschein-
lichkeit hoch ist, dass Rational DOORS von einem neuen IBM Produkt abgelöst wird. Daher
ist die Wahrscheinlichkeit der Weiterentwicklung der Software eher gering.
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig ausreichend
11.3 Steuerbarkeit 4-wertig gut
11.4 Erwartungskonformität 4-wertig gut
11.5 Fehlertoleranz 4-wertig gut
11.6 Anpassbarkeit 4-wertig gut
11.7 Erlernbarkeit 4-wertig gut
Anmerkungen/Besonderheiten Die Oberfläche wirkt etwas veraltet und ist unübersichtlich.
Viele Funktionen verstecken sich hinter Punkten, wo man sie nicht erwarten würde. Oft
muss man erst in der Hilfe nachschlagen, um eine Funktion zu finden, da die Menüs und
Bezeichnungen nicht intuitiv sind.
59
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
6.3.3 ALM Studio
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig ausreichend
1.3 Freitextbeschreibung gut formatierbar 4-wertig sehr gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Der Punkt „Kundenwünsche erfassbar“ wird nicht stan-
dardmäßig unterstützt, kann jedoch hinzugefügt werden. Dabei ergeben sich leider Encoding-
Fehler, weshalb hier nur ein Ausreichend als Bewertung gegeben wurde.
Besonders gut realisiert ALM Studio die Freitextbeschreibung. Hier können neben den
normalen Formatierungen, wie Ausrichtung, Textstil, etc., auch Formelzeichen, Microsoft-
Word-Dokumente und Filme eingefügt werden.
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig sehr gut
2.2 API-Zugriff Ja/Nein Ja
2.3 Anforderungen exportierbar 4-wertig sehr gut
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig sehr gut
2.5 Suchfilter (privat und öffentlich) 4-wertig gut
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Nein
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Ja
Anmerkungen/Besonderheiten ALM Studio kann Dateien von Microsoft Excel und Word
importieren und exportieren. Zusätzlich kann ein eigener Import und Export konfiguriert
werden, wodurch auch .csv, .txt und ähnliche Formate unterstützt werden.
Die Sichten auf Anforderungen können frei definiert werden. Standardmäßig gibt es
Dokument-und Tabellenansichten.
60
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig gut
3.2 Kommentar angebbar Ja/Nein Ja
3.3 Erklärende Dokumente angebbar Ja/Nein Ja
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig gut
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig ausreichend
Anmerkungen/Besonderheiten Bei ALM Studio kann man sich zu jeder Anforderung
deren Historie anzeigen lassen. Hier ist es auch möglich, nach Attributen zu filtern, welche
Änderungen man sehen möchte. Durch die Versionierung ist es auch möglich, Kommentare
und Dokumente zu einer Version anzugeben. Es fehlt jedoch eine globale Sicht, welche
alle Änderungen anzeigt. Dies ist nur über Baselines möglich. Benachrichtigungen bei
Änderungen können nicht direkt hinzugefügt werden, sondern müssen im Adminbereich
konfiguriert werden, was relativ komplex und unintuitiv ist.
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten ALM Studio enthält eine Unterstützung für Testfälle. Dabei
wird hier zwischen Testmenge, Testfällen und Testschritten unterschieden, wodurch sich
eine klare Hierarchie bildet. Es ist auch möglich, Testfälle als Testschritte einzufügen. Keine
Unterstützung gibt es bei der parametrisierbaren Testfalldurchführung, weswegen ALM
Studio für die Testfallverwaltung bei TRUMPF nicht geeignet ist.
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral gut
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Ja
Anmerkungen/Besonderheiten Die Rechtevergabe ist nur bis auf die Ebene der Untergrup-
pen Anforderungen, Testfälle etc. möglich.
61
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig sehr gut
6.2 Exportformate (weiterverarbeitbar) 4-wertig sehr gut
6.3 Exportformate (nicht weiterverarbeitbar) 4-wertig sehr gut
6.4 Druckfunktion Ja/Nein Nein
Anmerkungen/Besonderheiten Es können eigene Templates für Reports erstellt werden.
Um diese Arbeit zu erleichtern, steht dafür ein eigener Wizard zur Verfügung. Leider sind
die Default-Reports optisch nicht besonders ansprechend, so dass man hier auf jeden Fall
eigene Reports erstellen sollte.
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig gut
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten ALM Studio unterstützt standardmäßig die Versionspla-
nung. So können als Feature auch Grafiken zur aktuellen Version angezeigt werden, wie
zum Beispiel die Anforderungen einer Version als Kuchendiagramm nach dem Status
dargestellt.
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Ja
8.5 Eindruck 4-wertig gut
Anmerkungen/Besonderheiten Die Aufwandsbetrachtung lässt sich durch das Definie-
ren eines eigenen Attributs realisieren. Auf selbem Wege ist es möglich, eine Worst-Case-
Betrachtung durchzuführen.
62
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig gut
9.2 Archivierung von Anforderungen möglich Ja/Nein Nein
9.3 Integration mit anderen Tools Neutral siehe An-
merkungen
9.4 Support Neutral siehe An-
merkungen
9.5 Konfigurationsaufwand 4-wertig ausreichend
9.6 Aufwand der Benutzerverwaltung 4-wertig sehr gut
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Ja
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Nein
Anmerkungen/Besonderheiten ALM Studio kann mit folgenden Werkzeugen integriert
werden: IBM-Rational-Produkte, Microsoft Visual Studio Team System, Team Foundation
Server, MS Project, SharePoint, Excel und Word, HP Quality Center und QuickTestPro sowie
Eclipse, Subversion, Perforce, JIRA, Clarity, JUNIT und ANT. Hierzu steht ein Integration
Bus zur Verfügung.
Folgende Services und Unterstützung bietet ALM Studio: Prozess- und Werkzeugkonfi-
guration, Email- und Telefonsupport an Werktagen, wobei nach spätestens 24 Stunden
geantwortet wird, sowie Schulungen.
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral englisch
10.2 Kosten/Lizenzmodell Neutral -
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig gut
10.4 Projektbezogene Konfiguration 4-wertig gut
10.5 Anwendung ist als Web-Client verfügbar Neutral Ja
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Nein
63
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig gut
11.3 Steuerbarkeit 4-wertig ausreichend
11.4 Erwartungskonformität 4-wertig gut
11.5 Fehlertoleranz 4-wertig ausreichend
11.6 Anpassbarkeit 4-wertig sehr gut
11.7 Erlernbarkeit 4-wertig gut
Anmerkungen/Besonderheiten Die Benutzeroberfläche ist etwas überfüllt, wodurch es
schwierig ist, sich zurechtzufinden. Durch die umfangreichen Möglichkeiten, das Werkzeug
auf die eigenen Anforderungen anzupassen, normalisiert sich das wieder, da TRUMPF
nur einen kleinen Teil der angebotenen Module benötigt. Leider tauchen ab und zu Fehler
auf, welche nicht nachvollziehbar sind. Ein weiteres Manko ist die Geschwindigkeit des
Werkzeugs. Hier muss man pro Klick mehrere Sekunden warten, bis das gewünschte Fenster
bzw. die gewünschte Änderung erscheint.
6.3.4 Workspace
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig sehr gut
1.3 Freitextbeschreibung gut formatierbar 4-wertig sehr gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Nein
1.5 Anhänge zu Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Um Kundenwünsche zu erfassen, gibt es Change Requests.
Dort können neben einer Beschreibung auch Attribute, wie z.B. ein geschätzter Aufwand,
erfasst werden. Frei definierte Attribute und Anhänge werden ebenso unterstützt. Das
Erstellen einer Anforderung aus einem Change Request ist möglich.
Die Freitextfelder bieten sehr viele Formatierungsmöglichkeiten.
64
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig ausreichend
2.2 API-Zugriff Ja/Nein Nein
2.3 Anforderungen exportierbar 4-wertig ungenügend
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig ungenügend
2.5 Suchfilter (privat und öffentlich) 4-wertig Ja
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Nein
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Nein
Anmerkungen/Besonderheiten In diesem Bereich konnte Workspace nicht besonders über-
zeugen. Es wird nur Word als Exportformat unterstützt und hier auch nur die Versionen
2002 und 2003. Ebenso konnten keine Hinweise auf einen API-Zugriff gefunden werden.
Eine Verlinkung aus dem Tool auf ein Issue in JIRA ist zwar möglich, die andere Richtung
scheint jedoch nicht möglich zu sein. Obwohl es sich um einen Web-Client handelt, ließ sich
kein Link auf eine einzelne Anforderung generieren.
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig ausreichend
3.2 Kommentar angebbar Ja/Nein Ja
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig gut
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig ausreichend
Anmerkungen/Besonderheiten Die Änderungshistorie bewegt sich nur auf der Ebene
einzelner Anforderungen. Eine Betrachtung der Änderungen auf Projektebene oder auf
Attributebene ist nicht möglich. Zu einer Änderung kann ein Kommentar angegeben werden.
Benachrichtigungen bei Änderungen können abboniert werden, jedoch nicht für einzelne
Anforderungen, sondern nur auf höheren Ebenen wie „Benachrichtigung bei Änderung
(irgend)einer Anforderung“.
65
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Wie viele andere Werkzeuge ist auch Workspace hier an
den ersten beiden Teilaspekten gescheitert, da keine Parameter unterstützt werden. Ebenso
werden innerhalb eines Testfalls die einzeln durchzuführenden Schritte des Testfalls nicht
unterschieden, sondern können lediglich als Freittext angegeben werden.
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral gut
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Nein
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig ungenügend
6.2 Exportformate (weiterverarbeitbar) 4-wertig gut
6.3 Exportformate (nicht weiterverarbreitbar) 4-wertig ungenügend
6.4 Druckfunktion Ja/Nein Nein
Anmerkungen/Besonderheiten Der Inhalt von Reports ist nicht sehr flexibel einstellbar.
Die einzige Einstellungsmöglichkeit ist das Inkludieren oder Exkludieren von Kommentaren.
Unterstützte Formate sind HTML, Word und Excel.
Eine Druckfunktion gibt es nicht, hier müsste auf die Druckfunktion des Browsers zurückge-
griffen werden.
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig ungenügend
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
66
6.3 Detaillierte Bewertung der Werkzeuge
Anmerkungen/Besonderheiten Es gibt ein Attribut zum Eintragen der Version. Weitere
Unterstützung existiert nicht.
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Nein
8.5 Eindruck 4-wertig ausreichend
Anmerkungen/Besonderheiten Die Aufwandsbetrachtung kann nur umständlich über Re-
ports erstellt werden.
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig unbekannt
9.2 Archivierung von Anforderungen möglich Ja/Nein Nein
9.3 Integration mit anderen Tools Neutral -
9.4 Support Neutral unbekannt
9.5 Konfigurationsaufwand 4-wertig gut
9.6 Aufwand der Benutzerverwaltung 4-wertig gut
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Ja
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Nein
Anmerkungen/Besonderheiten Die Trialversion von Workspace war nur als Online-
Anwendung verfügbar, daher kann über den Installationsaufwand keine Aussage getroffen
werden.
Eine Archivierung ist nicht möglich. Hier muss der Umweg über Exports gegangen werden.
Die Benutzerverwaltung ist sehr einfach. Die Rechtevergabe erfolgt über Rollen.
67
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral englisch
10.2 Kosten/Lizenzmodell Neutral siehe An-
merkungen
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig gut
10.4 Projektbezogene Konfiguration 4-wertig ausreichend
10.5 Anwendung ist als Web-Client verfügbar Neutral Ja
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Nein
Anmerkungen/Besonderheiten Das Werkzeug ist stark modular aufgebaut. Es ist daher
möglich, nicht benötigte Module (Apps genannt) wegzulassen und damit nicht für unnötige
Funktionen zu zahlen. Jedoch werden für einige Funktionen, wie das Anhängen von Doku-
menten, zusätzliche Module benötigt. Die Homepage sieht gepflegt aus und es gibt keine
Hinweise darauf, dass das Projekt nicht gepflegt wurde. Auf der Homepage ließ sich jedoch
auch kein Datum der letzten Änderung finden. Projektbezogene Konfigurationen scheinen
nicht unterstützt zu werden. Das Anlegen mehrere Projekte ist zwar möglich, diese sind aber
nicht strikt voneinander trennbar. Ebenso ist die Rechteverwaltung projektübergreifend.
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig ausreichend
11.3 Steuerbarkeit 4-wertig gut
11.4 Erwartungskonformität 4-4-wertig gut
11.5 Fehlertoleranz 4-wertig gut
11.6 Anpassbarkeit 4-wertig gut
11.7 Erlernbarkeit 4-wertig gut
Anmerkungen/Besonderheiten Die Benutzeroberfläche machte einen guten Eindruck. Es
ist zwar durch die vielen Module nicht alles leicht zu finden, dies ließe sich aber durch das
Weglassen unnötiger Module etwas verbessern. Gleiches gilt natürlich für die Erlernbarkeit.
Von der Bedienung her verhielten sich alle Elemente wie erwartet und es waren praktisch
keine Falscheingaben provozierbar.
68
6.3 Detaillierte Bewertung der Werkzeuge
6.3.5 IRQA
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig ausreichend
1.3 Freitextbeschreibung gut formatierbar 4-wertig sehr gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Kundenwünsche könnten in IRQA über ein Feld „Konzep-
te “ abgebildet werden. Diese Möglichkeit wäre aber eher nicht zufriedenstellend. Sehr gut
schneidet IRQA jedoch bei den Formatierungsmöglichkeiten der Freitextbeschreibung ab.
Hier werden nahezu alle üblichen Formatierungsmöglichkeiten unterstützt.
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig sehr gut
2.2 API-Zugriff Ja/Nein Nein
2.3 Anforderungen exportierbar 4-wertig gut
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig gut
2.5 Suchfilter (privat und öffentlich) 4-wertig gut
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Nein
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Nein
Anmerkungen/Besonderheiten IRQA unterstützt Word und Excel bei Im- und Export.
Außerdem bietet es viele unterschiedliche Sichten auf Anforderungen. Die Sichten sind
jedoch nur wenig anpassbar. Ebenso sind Suchfilter nicht global speicherbar.
Eine Verlinkung von IRQA auf JIRA ist nur durch einen Link im Freitext möglich. Einen
Attributtyp für Links gibt es nicht. Eine Verlinkung in Gegenrichtung ist ebenso nicht
möglich.
69
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig gut
3.2 Kommentar angebbar Ja/Nein Ja
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig ausreichend
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig ungenügend
Anmerkungen/Besonderheiten Eine Änderungshistorie existiert zwar in IRQA, jedoch
erfasst sie nur Differenzen zwischen mehreren Baselines. Beim Vergleich mehrerer Versionen
werden die geänderten Attribute farblich hervorgehoben. Welche Teile des Inhalts eines
Attributs sich in welcher Form geändert haben, wird nicht angezeigt.
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten IRQA unterstützt das Anlegen aufeinander folgender Teil-
schritte innerhalb eines Testfalles. Auch Hierarchien von Testfällen und Verknüpfungen
zwischen Testfällen und Anforderungen werden unterstützt.
Nicht unterstützt wird das Einfügen von anderen Testfällen als Teilschritt und das Verwenden
von Parametern.
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral ausreichend
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Ja
Anmerkungen/Besonderheiten Rechte können nur auf Projektebene vergeben werden. Da-
bei wird zwischen Rechten für Anforderungen und Testfälle getrennt.
70
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig
6.2 Exportformate (weiterverarbeitbar) 4-wertig
6.3 Exportformate (nicht weiterverarbreitbar) 4-wertig
6.4 Druckfunktion Ja/Nein
Anmerkungen/Besonderheiten Reports waren in der Trialversion leider nicht freigeschal-
tet.
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig ausreichend
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Ja
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten Die Versionsplanung wird über ein selbst definiertes Attri-
but möglich. Die Entwicklung über mehrere Takte könnte unterstützt werden, indem man
das Attribut als „Multi Value “ anlegt. Es werden jedoch keine abhängigen Anforderungen
unterstützt. Der Gesamteindruck ist eher schlecht.
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Nein
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Nein
8.5 Eindruck 4-wertig ungenügend
Anmerkungen/Besonderheiten Es konnte keine Möglichkeit gefunden werden, eine Auf-
wandsbetrachtung zu ermöglichen.
71
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig gut
9.2 Archivierung von Anforderungen möglich Ja/Nein Nein
9.3 Integration mit anderen Tools Neutral Nein
9.4 Support Neutral unbekannt
9.5 Konfigurationsaufwand 4-wertig ausreichend
9.6 Aufwand der Benutzerverwaltung 4-wertig siehe An-
merkungen
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Nein
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Ja
Anmerkungen/Besonderheiten Die Benutzerverwaltung ist in der Trialversion nicht ver-
fügbar.
Eine Funktion zur Archivierung von Anforderungen ist nicht vorhanden. Ebenso sind die
Möglichkeiten zur Konfiguration sehr gering.
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral Englisch,
Spanisch
10.2 Kosten/Lizenzmodell Neutral
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig sehr gut
10.4 Projektbezogene Konfiguration 4-wertig gut
10.5 Anwendung ist als Web-Client verfügbar Neutral Nein
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Ja
Anmerkungen/Besonderheiten IRQA ist ein Englisch und Spanisch verfügbar. Die Ho-
mepage ist teilweise auch in Deutsch verfügbar, jedoch nicht vollständig. Mitunter sind
verschiedensprachige Inhalte auf einer Seite untergebracht.
IRQA bietet zwei unterschiedliche Lizenzmodelle: Computergebundene Lizenzen und
Floating-Lizenzen. Genaue Preise sind nicht bekannt.
Die Weiterentwicklung des Werkzeugs scheint wahrscheinlich. Die Homepage weist aktuelle
Einträge auf, die letzte große Ankündigung neuer Funktionen lag zum Zeitpunkt des Tests
weniger als ein halbes Jahr zurück. Die Firma hat außerdem einige große Kunden.
72
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig ausreichend
11.3 Steuerbarkeit 4-wertig ausreichend
11.4 Erwartungskonformität 4-4-wertig gut
11.5 Fehlertoleranz 4-wertig gut
11.6 Anpassbarkeit 4-wertig ausreichend
11.7 Erlernbarkeit 4-wertig ungenügend
Anmerkungen/Besonderheiten Bei der Benutzeroberfläche oritentiert sich IRQA an der
Benutzeroberfläche von Programmen wie beispielsweise etwas älteren Word-Versionen. Wie
üblich kann man dabei einzelne Werkzeugleisten ausblenden, weitere Anpassungsmöglich-
keiten scheinen nicht vorhanden zu sein.
Die Bedienung weist zwar keine Überraschungen im Sinne von unerwarteten Wirkungen
von Kontrollelementen auf, trotzem war die Bedienung des Werkzeugs sehr mühsam. Die
Einarbeitung dauerte sehr lange. Nach einer Pause von 1,5 Wochen dauerte es mindestens
30 Minuten, bis eine Möglichkeit gefunden wurde, Anforderungen zu editieren.
6.3.6 Polarion RM
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig ausreichend
1.3 Freitextbeschreibung gut formatierbar 4-wertig sehr gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Zum Erfassen von Kundenwünsche kann der Typ „Change
Request„ verwendet werden.
73
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig gut
2.2 API-Zugriff Ja/Nein Nein
2.3 Anforderungen exportierbar 4-wertig sehr gut
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig gut
2.5 Suchfilter (privat und öffentlich) 4-wertig sehr gut
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Nein
2.8 Hierarchie der Anforderungen Ja/Nein Nein
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Nein
Anmerkungen/Besonderheiten Als Importformate stehen Word und Excel zur Verfügung.
Beim Export werden sehr viele Formate unterstützt, unter anderem csv, xml und txt. Als
Sichten stehen Listen- und Dokumentensicht zur Verfügung.
Eine Verknüpfung zu JIRA ist möglich. Außerdem steht ein JIRA-Adapter als Extension zur
Verfügung 1. Eine Verknüpfung in die andere Richtung wäre theoretisch möglich, da es sich
um einen Web-Client handelt. Leider war es uns nicht möglich, einen Link auf ein einzelnes
Requirement zu generieren.
Eine API zum Zugriff auf das Werkzeug steht nicht zur Verfügung.
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig ungenügend
3.2 Kommentar angebbar Ja/Nein Nein
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig ungenügend
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig gut
Anmerkungen/Besonderheiten Die Änderungshistorie kann Anderungen nur global im
gesamten Projekt anzeigen. Der Vergleich mehrerer Versionen ist nur mit Kenntnis der
Revisionsnummer möglich. Ein Vergleich zwischen Head Revision und Revision 1 warf in
der Trialversion eine Null-Pointer-Exception. Danach tauchten öfters Fehler beim Betrachten
der Änderungshistorie auf.
1http://extensions.polarion.com/polarion/extensions/extension.jsp?extension=PE-138
74
6.3 Detaillierte Bewertung der Werkzeuge
Allgemein scheint der erzeugte Vergleich nicht sehr aussagekräftig und es sind keine Ände-
rungskommentare angebbar.
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Die Testverwaltung wird zwar nicht wie gewünscht unter-
stützt, da keine Parameter möglich sind, jedoch gibt es auf der Homepage des Herstellers
einige Extensions zur Integration mit Test-Werkzeugen.
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral sehr gut
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Nein
Anmerkungen/Besonderheiten Die Rechtevergabe ist sehr feingranular möglich, jedoch
nicht bis auf Attributebene.
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig gut
6.2 Exportformate (weiterverarbeitbar) 4-wertig sehr gut
6.3 Exportformate (nicht weiterverarbreitbar) 4-wertig gut
6.4 Druckfunktion Ja/Nein Ja
Anmerkungen/Besonderheiten Es kann auf Attributebene angegeben werden, was in den
Report aufgenommen werden soll. Jedoch lassen sich keine einzelnen Anforderungen vom
Report ausschließen. Als Formate werden neben vielen weiterverarbeitbaren wie XML, DOC
und XLS auch HTML und PDF unterstützt.
75
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig ausreichend
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten Zur Versionsplanung kann ein Attribut angelegt werden.
Eine Unterstützung für die Entwicklung über mehrere Takte wäre rudimentär möglich,
indem man das Attribut als Multi Value auszeichnet. In Berechnungen würde das jedoch
nicht einfließen.
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Nein
8.5 Eindruck 4-wertig ungenügend
Anmerkungen/Besonderheiten Es gibt zwar eine Möglichkeit, die Summe aus Feldern
zu berechnen, jedoch ist es uns nicht gelungen, dies auch so umzusetzen, dass man es
als Aufwandsbetrachtung nutzen könnte, so dass wir hier nur ein Ungenügend vergeben
konnten.
76
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig unbekannt
9.2 Archivierung von Anforderungen möglich Ja/Nein Nein
9.3 Integration mit anderen Tools Neutral siehe An-
merkungen
9.4 Support Neutral siehe An-
merkungen
9.5 Konfigurationsaufwand 4-wertig gut
9.6 Aufwand der Benutzerverwaltung 4-wertig gut
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Ja
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Nein
Anmerkungen/Besonderheiten Da die Trialversion auf einem Server des Herstellers instal-
liert ist, kann zum Installationsaufwand keine Aussage getroffen werden.
Zur Integration mit anderen Werkzeugen stehen auf der Webseite des Herstellers viele Er-
weiterungen zur Verfügung. Im Werkzeug steht außerdem ein Support-Link zur Verfügung,
um schnell Hilfe zu bekommen.
Der Konfigurationsaufwand hält sich in Grenzen, da die Administrationsmenüs sehr über-
sichtlich sind. Selbiges gilt für den Aufwand der Benutzerverwaltung.
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral Englisch
10.2 Kosten/Lizenzmodell Neutral
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig sehr gut
10.4 Projektbezogene Konfiguration 4-wertig gut
10.5 Anwendung ist als Web-Client verfügbar Neutral Ja
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Nein
Anmerkungen/Besonderheiten Als Sprache steht nur Englisch zur Verfügung.
Die Weiterentwicklung der Software halten wir für sehr wahrscheinlich, da die Homepage
gut gepflegt ist und für die Zukunft einige Workshops in Planung sind. Unter anderem
findet ein Workshop in Stuttgart statt.
77
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig gut
11.3 Steuerbarkeit 4-wertig gut
11.4 Erwartungskonformität 4-4-wertig gut
11.5 Fehlertoleranz 4-wertig gut
11.6 Anpassbarkeit 4-wertig ausreichend
11.7 Erlernbarkeit 4-wertig gut
Anmerkungen/Besonderheiten Die Oberfläche macht allgemein einen guten Eindruck.
Allerdings ist sie sehr platzfüllend, was zum Beispiel beim Editieren von Anforderungen
unangenehm ist, da nur wenig Platz für den Editorbereich übrig ist. Ebenfalls unangenehm
aufgefallen ist die Tatsache, dass bei einer Änderung in einer Anforderung nicht automatisch
die Liste der Anforderungen entsprechend angepasst wurde, sondern man einen „Refresh“-
Knopf manuell betätigen musste.
6.3.7 RTIME
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig ausreichend
1.3 Freitextbeschreibung gut formatierbar 4-wertig sehr gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Der Texteditor hat WYSIWYG-Unterstützung und bietet
die Möglichkeit, Text-Templates zu verwenden.
78
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig ausreichend
2.2 API-Zugriff Ja/Nein Nein
2.3 Anforderungen exportierbar 4-wertig gut
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig ungenügend
2.5 Suchfilter (privat und öffentlich) 4-wertig ausreichend
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Nein
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Ja
Anmerkungen/Besonderheiten Es gibt nur eine mögliche Sicht auf die Anforderungen
(Darstellung in Listen). Es ist keine bidirektionale Verknüpfung zu JIRA möglich.
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig gut
3.2 Kommentar angebbar Ja/Nein Nein
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig ausreichend
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig ungenügend
Anmerkungen/Besonderheiten Keine Unterstützung für E-Mail-Benachrichtigungen.
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Testunterstützung nur für textuelle Erfassung von Testfäl-
len.
79
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral ausreichend
5.2 Unterstützung für Gruppen Ja/Nein Nein
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Nein
Anmerkungen/Besonderheiten Keine frei definierbaren Rechte-Gruppen möglich.
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig sehr gut
6.2 Exportformate (weiterverarbeitbar) 4-wertig gut
6.3 Exportformate (nicht weiterverarbeitbar) 4-wertig gut
6.4 Druckfunktion Ja/Nein Ja
Anmerkungen/Besonderheiten Für Reports können Templates angelegt werden. Es ist eine
sehr detaillierte Filterung möglich, welche Anforderungen in den Reports berücksichtigt
werden sollen.
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig sehr gut
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Ja
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Versionsplanung und Aufwandsbetrachtung werden über
ein Excel-Dokument realisiert, mit dessen Hilfe ein Datenaustausch zwischen Excel und
RTIME ermöglicht wird.
80
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Ja
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Ja
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Ja
8.5 Eindruck 4-wertig sehr gut
Anmerkungen/Besonderheiten Versionsplanung und Aufwandsbetrachtung werden über
ein Excel-Dokument realisiert, mit dessen Hilfe ein Datenaustausch zwischen Excel und
RTIME ermöglicht wird.
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig gut
9.2 Archivierung von Anforderungen möglich Ja/Nein Nein
9.3 Integration mit anderen Tools Neutral siehe An-
merkungen
9.4 Support Neutral siehe An-
merkungen
9.5 Konfigurationsaufwand 4-wertig gut
9.6 Aufwand der Benutzerverwaltung 4-wertig ausreichend
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Nein
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Ja
Anmerkungen/Besonderheiten Integration ist möglich mit Excel, Word und Mindmanager
über die Export- und Importfunktionen. Den Support können wir nicht bewerten, da wir ihn
als Nichtkunden nicht in Anspruch nehmen können.
81
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral Englisch,
mit Recht-
schreibprü-
fung
10.2 Kosten/Lizenzmodell Neutral siehe An-
merkungen
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig ungenügend
10.4 Projektbezogene Konfiguration 4-wertig ungenügend
10.5 Anwendung ist als Web-Client verfügbar Neutral Nein
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Ja
Anmerkungen/Besonderheiten Es gibt die Möglichkeit, das System als SaaS zu mieten,
oder es als On-Premise-Lösung im eigenen Rechenzentrum zu hosten. Das Kostenmodell
wird nicht explizit beschrieben, sondern soll auf Anfrage verhandelt werden. Das Werkzeug
ist nicht besonders bekannt, wenn man es nach Treffern bei Google bewertet, und die
Umsetzung ist teils von schlechter Qualität, so dass die Weiterentwicklung nach unserer
Einschätzung eher fraglich ist.
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig ausreichend
11.2 Selbstbeschreibungsfähigkeit 4-wertig ausreichend
11.3 Steuerbarkeit 4-wertig ausreichend
11.4 Erwartungskonformität 4-wertig ausreichend
11.5 Fehlertoleranz 4-wertig ausreichend
11.6 Anpassbarkeit 4-wertig ungenügend
11.7 Erlernbarkeit 4-wertig gut
Anmerkungen/Besonderheiten Die GUI ist mit vielen Anzeigefehlern behaftet: So werden
längere Texte manchmal abgeschnitten, die Anzeige flackert beim Laden. Durch bestimmte
Aktionen kann man die GUI in einen Status versetzen, in dem nur noch ein Neustart des
Programms eine weitere Bedienung ermöglicht.
82
6.3 Detaillierte Bewertung der Werkzeuge
6.3.8 TopTeam Analyst
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig sehr gut
1.3 Freitextbeschreibung gut Formatierbar 4-wertig gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Umfangreiche Traceability-Unterstützung.
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig gut
2.2 API-Zugriff Ja/Nein Nein
2.3 Anforderungen exportierbar 4-wertig ungenügend
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig gut
2.5 Suchfilter (privat und öffentlich) 4-wertig sehr gut
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Nein
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Ja
Anmerkungen/Besonderheiten Es gibt keine Exportfunktion. Suchfilter sind detailliert
definierbar.
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig sehr gut
3.2 Kommentar angebbar Ja/Nein Ja
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig sehr gut
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig sehr gut
83
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Anmerkungen/Besonderheiten Änderungshistorie kann in verschiedenen Ansichten auf-
gerufen werden (Split View / Merged View).
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
Anmerkungen/Besonderheiten Nur rudimentäre Unterstützung durch textuelle Erfassung
von Testfallbeschreibungen.
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral sehr gut
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Ja
Anmerkungen/Besonderheiten Eigene Rechte-Gruppen können detailliert angelegt werden.
Es besteht die Möglichkeit der Anbindung über LDAP.
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig sehr gut
6.2 Exportformate (weiterverarbeitbar) 4-wertig gut
6.3 Exportformate (nicht weiterverarbreitbar) 4-wertig gut
6.4 Druckfunktion Ja/Nein Ja
Anmerkungen/Besonderheiten Unterstützung für Templates, um Reports zu generieren.
Weitere Filterung möglich.
84
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig gut
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Ja
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten Anforderungen können Releases zugeordnet werden.
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Ja
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Nein
8.5 Eindruck 4-wertig ausreichend
Anmerkungen/Besonderheiten Es wird in jeder Anforderung ein Feld für die Aufwands-
schätzung angelegt, über das für jeden Release-Zyklus aufsummiert werden kann.
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig gut
9.2 Archivierung von Anforderungen möglich Ja/Nein Nein
9.3 Integration mit anderen Tools Neutral siehe An-
merkungen
9.4 Support Neutral siehe An-
merkungen
9.5 Konfigurationsaufwand 4-wertig gut
9.6 Aufwand der Benutzerverwaltung 4-wertig sehr gut
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Nein
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Ja
Anmerkungen/Besonderheiten Integration mit Word und Excel über Import- und Export-
funktionen möglich.
85
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral englisch
10.2 Kosten/Lizenzmodell Neutral siehe An-
merkunken
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig gut
10.4 Projektbezogene Konfiguration 4-wertig ungenügend
10.5 Anwendung ist als Web-Client verfügbar Neutral Nein
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Ja
Anmerkungen/Besonderheiten Preis pro Nutzerlizenz: 995 US-Dollar.
Insgesamt macht der Hersteller einen seriösen Eindruck. Es wird Support per Inter-
net und per Telefon-Hotline angeboten.
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig gut
11.3 Steuerbarkeit 4-wertig gut
11.4 Erwartungskonformität 4-wertig gut
11.5 Fehlertoleranz 4-wertig gut
11.6 Anpassbarkeit 4-wertig gut
11.7 Erlernbarkeit 4-wertig gut
Anmerkungen/Besonderheiten Gut bedienbar, keine negativen Auffälligkeiten.
6.3.9 TestTrackRM
Kriterium 1: Anforderungserfassung
Teilaspekt Skala Bewertung
1.1 Attribute frei definierbar Ja/Nein Ja
1.2 Kundenwünsche erfassbar 4-wertig ausreichend
1.3 Freitextbeschreibung gut Formatierbar 4-wertig gut
1.4 Abhängige Anforderungen unterstützt Ja/Nein Ja
1.5 Anhänge zu Anforderungen Ja/Nein Ja
86
6.3 Detaillierte Bewertung der Werkzeuge
Anmerkungen/Besonderheiten Eigene Anforderungstypen können nach Belieben definiert
werden.
Kriterium 2: Anforderungsverwaltung
Teilaspekt Skala Bewertung
2.1 Anforderungen importierbar 4-wertig gut
2.2 API-Zugriff Ja/Nein Ja
2.3 Anforderungen exportierbar 4-wertig gut
2.4 Mehrere Sichten auf Anforderungen möglich (anpassbar) 4-wertig gut
2.5 Suchfilter (privat und öffentlich) 4-wertig sehr gut
2.6 Traceability (zu JIRA) unidirektional Ja/Nein Ja
2.7 Traceability (zu JIRA) bidirektional Ja/Nein Ja
2.8 Hierarchie der Anforderungen Ja/Nein Ja
2.9 Verknüpfung zw. Anforderungen verschiedener Projekte Ja/Nein Ja
Anmerkungen/Besonderheiten Es gibt zwei Sichten auf die Anforderungen: Eine Tabellen-
Sicht und eine Dokumenten-Sicht. Suchfilter sind detailliert anlegbar und speicherbar.
Kriterium 3: Änderungshistorie
Teilaspekt Skala Bewertung
3.1 Granularität der Änderungshistorie 4-wertig sehr gut
3.2 Kommentar angebbar Ja/Nein Nein
3.3 Erklärende Dokumente angebbar Ja/Nein Nein
3.4 Unterschiede mehrerer Versionen anzeigbar 4-wertig sehr gut
3.5 Suche in alten Versionen Ja/Nein Nein
3.6 Benachrichtigung bei Änderungen (Beobachtungen) 4-wertig sehr gut
Anmerkungen/Besonderheiten Sehr detaillierte Änderungshistorie verfügbar. Es ist aller-
dings auch möglich, sich eine verkürzte Fassung mit weniger Details anzeigen zu lassen.
Kriterium 4: Testunterstützung
Teilaspekt Skala Bewertung
4.1 Testfälle erfassbar Ja/Nein Nein
4.2 Testdurchführung unterstützt Ja/Nein Nein
4.3 Verknüpfung zw. Testfall und Anforderungen Ja/Nein Ja
87
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Anmerkungen/Besonderheiten Nur rudimentäre Unterstützung durch textuelle Erfassung
von Testfallbeschreibungen. Der selbe Hersteller hat ein Programm namens TestTrackTCM
im Portfolio, das der Testfallverwaltung dient. Dieses Werkzeug lässt sich mit TestTrackRM
kombinieren.
Kriterium 5: Rechtekonzept
Teilaspekt Skala Bewertung
5.1 Granularität der Rechtevergabe Neutral sehr gut
5.2 Unterstützung für Gruppen Ja/Nein Ja
5.3 Anbindung an bestehende Benutzerverwaltung (LDAP) Ja/Nein Ja
Anmerkungen/Besonderheiten Gruppen lassen sich detailliert anlegen und gut verwalten.
Anbindung an bestehende Systeme per LDAP und ActiveDirectory möglich.
Kriterium 6: Reports
Teilaspekt Skala Bewertung
6.1 Granularität der Sichtbarkeit (Templates) 4-wertig sehr gut
6.2 Exportformate (weiterverarbeitbar) 4-wertig ausreichend
6.3 Exportformate (nicht weiterverarbreitbar) 4-wertig ausreichend
6.4 Druckfunktion Ja/Nein Ja
Anmerkungen/Besonderheiten XSLT-Templates können angelegt werden. Export nur ins
HTML-Format möglich.
Kriterium 7: Versionsplanung
Teilaspekt Skala Bewertung
7.1 Wird unterstützt Ja/Nein Ja
7.2 Eindruck 4-wertig gut
7.3 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
7.4 Unterstützung für abhängige Anforderungen Ja/Nein Nein
Anmerkungen/Besonderheiten Anforderungen können Release-Versionen zugeordnet wer-
den.
88
6.3 Detaillierte Bewertung der Werkzeuge
Kriterium 8: Aufwandsbetrachtung
Teilaspekt Skala Bewertung
8.1 Wird unterstützt Ja/Nein Ja
8.2 Unterstützung für Entwicklung über mehrere Takte Ja/Nein Nein
8.3 Unterstützung für abhängige Anforderungen Ja/Nein Nein
8.4 Unterstützung für verschiedene Szenarien (Worst-Case) Ja/Nein Nein
8.5 Eindruck 4-wertig ungenügend
Anmerkungen/Besonderheiten Eventuell lassen sich Worst-Case-Szenarien über speziel-
le Einstellungen berechnen, das Werkzeug ist recht komplex und gut anpassbar. In der
Standardeinstellung wird aber nur ein Schätzwert unterstützt.
Kriterium 9: Installation und Administration
Teilaspekt Skala Bewertung
9.1 Installationsaufwand 4-wertig ausreichend
9.2 Archivierung von Anforderungen möglich Ja/Nein Nein
9.3 Integration mit anderen Tools Neutral siehe An-
merkungen
9.4 Support Neutral siehe An-
merkungen
9.5 Konfigurationsaufwand 4-wertig ausreichend
9.6 Aufwand der Benutzerverwaltung 4-wertig sehr gut
9.7 Administrationsoberfläche als Web-Client verfügbar Neutral Ja
9.8 Administrationsoberfläche als Standalone-Client verfüg-
bar
Neutral Ja
Anmerkungen/Besonderheiten Es gibt eine Web-Service-Schnittstelle (WSDL) und eine
LDAP-Anbindung.
89
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
Kriterium 10: Sonstiges
Teilaspekt Skala Bewertung
10.1 Sprache Neutral Englisch
10.2 Kosten/Lizenzmodell Neutral siehe An-
merkungen
10.3 Weitere Entwicklung der Software wahrscheinlich 4-wertig sehr gut
10.4 Projektbezogene Konfiguration 4-wertig ungenügend
10.5 Anwendung ist als Web-Client verfügbar Neutral Ja
10.6 Anwendung ist als Standalone-Client verfügbar Neutral Ja
Anmerkungen/Besonderheiten Es gibt die Auswahl zwischen benutzerbasierten Lizenzen
und Floating-Lizenzen.
Preis für eine benutzerbasierte Lizenz: 1194 US-Dollar einmalig. Support für ein
Jahr ist inbegriffen.
Weiterer Support: 199 US-Dollar / Jahr.
Preis für eine Floating-Lizenz: 2994 US-Dollar einmalig. Support für ein Jahr ist in-
begriffen.
Weiterer Support: 499 US-Dollar / Jahr.
Support beinhaltet neben der klassischen Hilfe bei Fragen und Fehlerfällen auch
die aktuellen Updates der Software, von denen nach Herstellerangaben ungefähr 4 Mal im
Jahr eines erscheint.
Kriterium 11: Usability nach ISO 9241 parts 110
Teilaspekt Skala Wichtigkeit
11.1 Aufgabenangepasstheit 4-wertig gut
11.2 Selbstbeschreibungsfähigkeit 4-wertig gut
11.3 Steuerbarkeit 4-wertig gut
11.4 Erwartungskonformität 4-wertig gut
11.5 Fehlertoleranz 4-wertig gut
11.6 Anpassbarkeit 4-wertig gut
11.7 Erlernbarkeit 4-wertig gut
Anmerkungen/Besonderheiten Gut bedienbar, keine negativen Auffälligkeiten.
90
6.4 Zusammenfassung der detaillierten Bewertungen
6.4 Zusammenfassung der detaillierten Bewertungen
Die im Folgenden aufgeführten Tabellen 6.2, 6.3 und 6.4 zeigen einen Vergleich der einzel-
nen Werkzeuge. Dabei wurden die Bewertungen der Teilaspekte der Kriterien jeweils auf
eine Gesamtnote für jedes Kriterium verrechnet. Die Verrechnung erfolgt dabei aufgrund
der Unterschiedlichkeit der Teilaspekte nicht mathematisch, sondern in Abwägung der
unterschiedlichen Wichtigkeit der Teilaspekte „von Hand“.
27. Juli 2011 Werkzeuge für die Anforderungsverwaltung 8/19
Bewertung – wichtigste Kriterien
Anforderungs-
verwaltung (26)
Anforderungs- 
erfassung (22)
Änderungs-
historie  (16)
ALM Studio Sehr gut Gut Gut
Polarion RM Gut Gut Ungenügend
RTIME Ausreichend Gut Ausreichend
Workspace Ausreichend Sehr gut Ausreichend
DOORS Sehr gut Gut Gut
Contour Sehr gut Sehr gut Gut
TestTrackRM Sehr gut Gut Sehr gut
TopTeam Analyst Ausreichend Gut Sehr gut
IRQA Gut Gut Ausreichend
Gesamteindruck: Gut
Mittel
Schlecht
Abbildung 6.2: Wichtigste Aspekte im Überblick
27. Juli 2011 Werkzeuge für die Anforderungsverwaltung 9/19
Bewertung – Nebenkriterien
Aufwands-
betrachtung (10)
Versions-
planung (8)
Reports (6) Rechte-
verwaltung (3)
ALM Studio Gut Gut Sehr gut Gut
Polarion RM Ungenügend Ausreichend Gut Sehr gut
RTIME Sehr gut Gut Gut Ungenügend
Workspace Ausreichend Ausreichend Ausreichend Gut
DOORS Gut Ausreichend Sehr gut Sehr gut
Contour Ausreichend Gut Gut Gut
TestTrackRM Gut Gut Ausreichend Sehr gut
TopTeam Analyst Ausreichend Gut Gut Sehr gut
IRQA Ungenügend Gut Ausreichend Gut
Gesamteindruck: Gut
Mittel
Schlecht
Abbildung 6.3: Weniger wichtige Aspekte im Überblick
91
6 Bewertung der verbliebenen Anforderungsverwaltungswerkzeuge
27. Juli 2011 Werkzeuge für die Anforderungsverwaltung 8/14
Bewertung – Usability und Eindruck
Usability (11)
ALM Studio Ausreichend
Polarion RM Gut
RTIME Ungenügend
Workspace Gut
DOORS Gut
Contour Sehr gut
TestTrackRM Gut
TopTeam Analyst Gut
IRQA Ausreichend
Abbildung 6.4: Usability und allgemeiner Eindruck
92
7 Empfehlung
In Tabelle 6.2 ist zu erkennen, dass in den 3 wichtigsten Kriterien Anforderungserfassung,
Anforderungsverwaltung und Änderungshistorie TestTrackRM und Contour am besten
abgeschnitten haben, gefolgt von Rational DOORS und ALM Studio. Daher legen wir im
folgenden Vergleich den Fokus vor allem auf diese Werkzeuge.
Dabei kann man in Tabelle 6.3 die Übersicht über die restlichen Kriterien sehen. Es
sind nur die Kriterien Rechtekonzept, Reports, Versionsplanung und Aufwandsbetrachtung
aufgeführt, da keines der Werkzeuge die KO-Kriterien für die Testunterstützung erfüllt und
die Punkte Installation und Administration und Sonstiges nicht im Detail gewichtet wurden.
Das bedeutet jedoch nicht, dass diese nicht in die Bewertung mit eingeflossen sind, soweit es
nötig war. Die Usability und damit auch der allgemeine Eindruck fließen, wie in der Tabelle
6.4 zu sehen ist, als eigener Punkt in den Vergleich ein. Man sieht in Tabelle 6.3, dass ALM
Studio hier am meisten Punkten konnte. Rational DOORS und TestTrackRM liegen hier
im Mittelfeld, wobei TestTrackRM besser abschneidet. Das Schlusslicht bildet Contour, da
hier die Aufwandsbetrachtung nur über Reports erreicht werden kann.
Schaut man jedoch auf die Usability (6.4) und damit auch auf den allgemeinen Ein-
druck, kann ALM Studio nicht überzeugen, auch wenn es in den beiden vorhergehenden
Punkten gut abgeschnitten hat. Besonders gut schneidet hier Contour ab. Da es ohne das
Kriterium Aufwandsbetrachtung Sieger wäre, schlagen wir dieses Werkzeug als Alternative
vor. Rational DOORS war wie erwartet überall im Mittelfeld, kann jedoch im Vergleich
mit dem noch verbleibenden Werkzeug TestTrackRM nicht mithalten. Die Gründe dafür
liegen auch in der sehr komplexen Installation und Konfiguration, sowie dem sehr hohen
Preis. Somit ist das empfohlene Werkzeug TestTrackRM, da es in allen Kriterien überzeugen
konnte.
7.1 Empfohlenes Anforderungsverwaltungswerkzeug - TestTrackRM
Nach Bewertung und Vergleich aller Werkzeuge kommen wir zu dem Schluss, dass Test-
TrackRM von Seapine Software die Anforderungen, welche TRUMPF an ein Anforderungs-
verwaltungswerkzeug hat, am besten erfüllt. Dieses Werkzeug konnte bei den wichtigsten
Kriterien gut abschneiden und unterstützt sowohl die Versionsplanung als auch die Aufwands-
betrachtung. Auch bei der Usability und dem allgemeinen Eindruck lässt sich nur Positives
berichten. Auch wenn andere Werkzeuge in dem ein oder anderen Kriterium bessere Noten
93
7 Empfehlung
bekommen haben, unterstützt TestTrackRM alle Anforderungen gut bis sehr gut und ist
daher das ausgewogenste Anforderungsverwaltungswerkzeug.
In den Kriterien Anforderungserfassung und Anforderungsverwaltung bietet TestTrackRM alle
benötigten Funktionen. Die Freitextbeschreibungen können gut formatiert werden und An-
hänge können zu Anforderungen hinzugefügt werden. Außerdem bietet es selbstverständlich
die Möglichkeit, eigene Felder zu definieren. Zum Betrachten der Anforderungen werden
zwei unterschiedliche Sichten angeboten, eine tabellenorientierte Sicht und eine Dokumen-
tensicht. Beide Sichten können gefiltert werden und eine Suche nach Anforderungen ist sehr
detailliert möglich. Anforderungen können untereinander verknüpft werden, um Hierarchien
von Anforderungen zu bilden.
Zur Zusammenarbeit mit anderen Komponenten gibt es mehrere unterstützende Funktionen.
Es gibt eine SOAP/WSDL-API und es können externe Links auf eine einzelne Anforderung
erstellt werden, um beispielsweise eine bidirektionale Verlinkung mit Issues in JIRA zu
ermöglichen. Außerdem werden einige Exportformate angeboten, welche teilweise weiterver-
arbeitbar sind und somit auch eine halbautomatisierte Übertragung von Anforderungen in
andere Werkzeuge ermöglichen.
Die Änderungshistorie der Anforderungen ist sehr übersichtlich und kann entweder alle
Details zeigen, oder eine Übersicht ohne Details. Baselines werden von TestTrackRM ebenfalls
unterstützt. Benutzer können sich außerdem bei Änderungen benachrichtigen lassen.
Bei der Rechteverwaltung überzeugt das Werkzeug mit sehr guten Einstellungsmöglichkeiten
und Unterstützung für Gruppen. Auch die Anbindung an LDAP wird unterstützt, was den
Einsatz beim Industriepartner erleichtern dürfte.
Die Versionsplanung und die Aufwandsbetrachtung werden ebenfalls unterstützt. Sehr gut
gelungen ist dabei die Aufwandsbetrachtung, da hier die Summe der Aufwände in einem
Schaubild übersichtlich angezeigt wird. Allgemein ist die Usability des Werkzeugs gut und
es wurden keine großen Negativpunkte gefunden.
Vom Preis her erscheint das Werkzeug angemessen. Im ersten Jahr sind Support und Updates
inbegriffen, für alle weiteren Jahre wird hier ein jährlicher Betrag fällig. Außerdem existiert
eine deutsche Vertretung der Firma.
7.2 Alternative - Contour
Als Alternative für TestTrackRM empfehlen wir Contour von Jama. Dieses Werkzeug hat
seine Stärken vor allem in den drei wichtigsten Kriterien Anforderungserfassung, Anforderungs-
verwaltung und Änderungshistorie. Es ist hier möglich, mehrere Sichten auf die Anforderungen
einzurichten. Vor allem die Dokumentansicht kann hier überzeugen. Zudem können sehr
bequem Hierarchien von Anforderungen angegeben und nachvollzogen werden. Auch ab-
hängige oder verwandte Anforderungen können über die Projektgrenzen hinweg angegeben
und übersichtlich dargestellt werden. Darüber hinaus ist hier eine bidirektionale Verbindung
zu dem Issue-Tracker JIRA möglich. Schön ist auch die Möglichkeit, Anforderungen zu
94
7.2 Alternative - Contour
duplizieren und zu synchronisieren, wodurch eine Anforderung in mehreren Projekten oder
Strukturen dargestellt werden kann. Die Synchronisation ist dabei nur unidirektional.
Bei den als weniger wichtig eingestuften Kriterien Rechtekonzept, Versionsplanung und Reports
konnte Contour gut abschneiden. So können für die Benutzer des Werkzeugs Gruppen
angelegt werden, wodurch sich der Verwaltungsaufwand reduziert. Auch ist ein Anbin-
dung an LDAP möglich, was ebenfalls den Aufwand reduziert. Die Versionsplanung ist
standardmäßig vorhanden und bietet eine gute Übersicht über alle zu einer Version zu-
geordneten Versionen. Reports können frei konfiguriert und in verschiedenen Formaten
wie HTML, PDF und als Microsoft-Word- und Excel-Dokumente exportiert werden. So
ist es auch möglich, sich einen Report zu generieren, welcher alle Aufwände pro Version
anzeigt und aufsummiert. Das ist jedoch die einzige Art, in Contour die Aufwandsbetrachtung
umzusetzen.
Auch in den Kriterien Installation und Administration und Sonstiges gibt es nichts Negatives
zu berichten. So ist es zum Beispiel mit einem durchschnittlichen Preis von 59 US-Dollar pro
Monat und Benutzer im preislichen Mittelfeld der bewerteten Werkzeuge.
In der Usability und dem allgemeinen Eindruck konnte Contour am meisten überzeugen.
Die größte Schwäche und der Grund, weshalb wir dieses Werkzeug nicht an erster Stelle
empfehlen, ist die geringe Unterstützung der Aufwandsbetrachtung. Wenn jedoch keine
Aufwandsbetrachtung nötig ist, wäre dieses Werkzeug absolut zu empfehlen.
95

8 Zusammenfassung und Ausblick
Zusammenfassend lässt sich sagen, dass die Fachstudie erfolgreich verlaufen ist. Wir
konnten das Ziel erreichen, die Anforderungen des Industriepartners an das gesuchte
Werkzeug zu analysieren und geeignete Lösungen auf dem Markt zu finden. Die Situation
bei TRUMPF stellte sich so dar, dass zunächst teilweise unterschiedliche Vorstellungen
und Visionen des Anforderungsverwaltungswerkzeugs bestanden. Zudem befand sich der
Prozess der Anforderungsverwaltung zur Zeit der Fachstudie in einem Umbruch, sodass
sich die IST-Analyse als schwierig herausstellte. Doch die Fachstudie war allen Beteiligten
wichtig, sodass man sich beim Industriepartner für uns Zeit genommen und uns mit allen
nötigen Informationen ausgestattet hat. So konnten wir schließlich die Anforderungen
ordnen und zusammen mit den beteiligten Mitarbeitern die Bewertungskriterien definieren
und gewichten. Die Anforderungen von TRUMPF konnten letztlich von einigen untersuchten
Werkzeugen recht gut erfüllt werden, die Vorstellungen und Anforderungen von TRUMPF
an das Werkzeug waren also weitgehend realistisch.
Das von Seiten der Universität vorgeschlagene Vorgehensmodell zur Bewertung der
Anforderungsverwaltungswerkzeuge hat sich als geeignet erwiesen. Die Filterung der
Gesamtliste durch KO-Kriterien war sinnvoll, die daraus extrahierte Short List war eine
gute Basis für die detaillierte Bewertung. Bei der Definiton der KO-Kriterien und deren
Anwendung auf die Werkzeuge mussten wir allerdings an manchen Stellen von der allzu
strikten Anwendung absehen, um nicht offensichtlich sehr gut geeignete Werkzeuge
vorschnell auszuschließen. Am Ende fanden sich dann auch bei beiden Werkzeugen - der
Empfehlung und der Alternative - Punkte, die zum Ausschluss anhand des KO-Kriteriums
der Worst-Case-Betrachtung hätten führen können.
Als problematisch erwies sich oftmals die Kommunikation mit den Herstellern der
Werkzeuge. Hier gab es eine sehr breite Streuung hinsichtlich der Hilfsbereitschaft und
Kommunikationsbereitschaft. Einige der Hersteller waren sehr bemüht, uns bei Problemen
zu helfen und uns Testversionen zur Verfügung zu stellen. Leider gab es auch Hersteller,
die nicht mit Studenten kooperieren wollten oder unsere Anfragen vollständig ignorierten.
Ebenfalls problematisch war die Tatsache, dass der Mailserver der Informatikfakultät
mehrmals Mails zurückgewiesen hatte, welche von den Herstellern an uns gesendet
wurden.
97
8 Zusammenfassung und Ausblick
8.1 Ausblick
Bei TRUMPF wird man sich die empfohlenen Werkzeuge genau anschauen und sich letztlich
eventuell für eines der beiden entscheiden. Unsere Fachstudie wird bei der Entscheidung
hoffentlich eine Hilfe sein und TRUMPF einiges an Arbeit ersparen. Die Integration des
neuen Werkzeugs in die Prozesse wird jedoch noch viel Arbeit erfordern. Im Bezug darauf
wurde seitens TRUMPF schon angedeutet, dass man für diese Aufgabe eventuell ein
Praktikum für Softwaretechnikstudenten ausschreiben will.
Zu guter Letzt bleibt zu sagen, dass unsere Arbeit vom Industriepartner durchweg
positiv aufgenommen wurde. Insofern hat diese Arbeit sicherlich einen Grundstein gelegt,
einerseits für zukünftige Kooperationen der Universität mit TRUMPF, andererseits eventuell
auch für unsere berufliche Laufbahn.
98
Literaturverzeichnis
[Ebe10] C. Ebert. Systematisches Requirements Engineering. dpunkt.verlag, 3. Auflage 2010.
(Zitiert auf den Seiten 15 und 16)
[GH09] W. P. Georg Herzwurm. Management von IT-Produkten. dpunkt.verlag, 1. Auflage
2009. (Zitiert auf Seite 15)
[INC] URL http://www.incose.org/productspubs/products/rmsurvey.aspx. (Zitiert
auf Seite 21)
[JL07] H. L. Jochen Ludewig. Software Engineering. dpunkt.verlag, 1. Auflage 2007. (Zitiert
auf Seite 15)
[Too] URL http://www.jiludwig.com/Requirements_Management_Tools.html. (Zitiert
auf Seite 21)
Alle URLs wurden zuletzt am 17.07.2011 geprüft.
99

Erklärung
Hiermit versichere ich, diese Arbeit selbständig
verfasst und nur die angegebenen Quellen
benutzt zu haben.
(Désirée Graf, Ruben Mayer, Christian Sachers)