Özgür Hazar
Evaluierung von Requirement Management Systemen in der Software Entwicklung
ISBN: 978-3-8366-4501-0
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2010
Zugl. Fachhochschule Aachen, Aachen, Deutschland, Diplomarbeit, 2009
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2010
2
Inhaltsverzeichnis
Inhaltsverzeichnis...2
Abbildungsverzeichnis ...4
Tabellenverzeichnis ...6
Abkürzungsverzeichnis ...7
Vorwort...8
Abstract...9
Danksagung...10
1.
Einleitung ...11
1.1
Motivation ...12
2.2
Zielsetzung und Konzeption dieser Arbeit...13
2.
Requirement, Requirements Management und Requirements Engineering ...15
2.1
Requirements Management ...16
2.2
Requirements Engineering...16
2.3
Requirements ...17
2.3.1
Klassifizierung von Requirements ...17
2.3.2
Qualitätskriterien von Anforderungsspezifikationen ...20
3
Application Lifecycle Management ...23
3.1
Was ist ALM ? ...23
3.2
Nutzen von Application Lifecycle Management...27
3.3
ALM Lösungswerkzeuge ...29
3.4
Vorgehen der Evaluation...29
4
Die ALM Lösungswerkzeuge im Detail ...32
4.1
CaliberRM von Borland ...32
4.1.1
Allgemeines zu CaliberRM ...32
4.1.2
Die Software-Entwicklungsphasen im CaliberRM ...33
4.1.3
Architektur und Hardwareanforderungen des Borland CaliberRM ...35
4.1.4
Benutzeroberfläche des CaliberRM...37
4.1.5
Multiuserfähigkeit des CaliberRM...40
4.1.6
Anlegen eines Projektes...44
4.1.7
Requirements und Attribute...49
3
4.1.8
Änderungsmanagement im CaliberRM ...53
4.1.9
Traceability ...55
4.1.10
Import und Exportmöglichkeiten des CaliberRM ...58
4.1.11
Reports ...58
4.2
Polarion Requirements 1.0.1 von Polarion...59
4.2.1
Allgemeines zu Polarion Requirements...59
4.2.2
Die Software-Entwicklungsphasen im Polarion Requirements...60
4.2.3
Architektur und Hardwareanforderungen ...61
4.2.4
Benutzeroberfläche des Polarion Requirements ...63
4.2.5
Multiuserfähigkeit des Polarion Requirements ...68
4.2.6
Anlegen eines Projekts...74
4.2.7
Requirements und Attribute...77
4.2.8
Änderungsmanagement im Polarion Requirements...81
4.2.9
Traceability ...85
4.2.10
Import- und Exportmöglichkeiten...87
4.2.11
Reports ...88
4.3
Visual Studio Team System von Microsoft...89
4.3.1
Allgemeines zu Microsoft VSTS ...89
5
Zusammenfassung und Ausblick ...90
Anhang...100
Glossar...112
Literaturverzeichnis...113
4
Abbildungsverzeichnis
Abbildung 1: Chaos Report 1995 der Standish Group [STA-95]...13
Abbildung 2: Abgrenzung von Requirements Management, Engineering ...15
Abbildung 3: Requirements Engineering Process and Techniques [KOT-03, S.190] ...19
Abbildung 4: Application Lifecycle Management...24
Abbildung 5: Application Lifecycle nach ITIL [IBM-05] ...25
Abbildung 6: ALM Process Area [BOR-08] ...28
Abbildung 7: Benutzeroberfläche des CaliberRM Administrator ...38
Abbildung 8: Menüfeld und Iconleiste vom CaliberRM Administrator ...38
Abbildung 9: Haupt-Benutzeroberfläche des CaliberRM ...39
Abbildung 10: Menüfeld und Iconleiste des CaliberRM ...39
Abbildung 11: Projektansicht im CaliberRM Administrator...41
Abbildung 12: Benutzeransicht im CaliberRM Administrator ...42
Abbildung 13: Gruppenansicht im CaliberRM Administrator...43
Abbildung 14: User Monitor für Benutzerverbindungen ...43
Abbildung 15: User Monitor für Produktverbindungen ...44
Abbildung 16: Projektname eingeben ...45
Abbildung 17: Projektbeschreibung ...46
Abbildung 18: Gruppenauswahl ...47
Abbildung 19: Glossarauswahl...48
Abbildung 20: Projektauswahl im CaliberRM ...48
Abbildung 21: Requirement neu erstellen ...50
Abbildung 22: Use Case Data...51
Abbildung 23: Zuständigkeiten der Projektgruppen und - mitglieder ...51
Abbildung 24: Referenzen...52
Abbildung 25: Diskussion...52
Abbildung 26: E-Mail Benachrichtigung ...54
Abbildung 27: Historie des CaliberRM ...54
Abbildung 28: Abhängigkeiten im CaliberRM...55
Abbildung 29: Abhängigkeitsmatrix im CaliberRM ...56
Abbildung 30: Abhängigkeitsdiagramm im CaliberRM...57
5
Abbildung 31: Baseline-Erstellung in CaliberRM ...58
Abbildung 32: Benutzeroberfläche des Polarion Requirements...63
Abbildung 33: Portlet Projects...65
Abbildung 34: Portlet Shortcuts...66
Abbildung 35: Topics der Projects ...66
Abbildung 36: Views des Polarion Requirements ...67
Abbildung 37: Topics der Administration...67
Abbildung 38: Projektansicht aus der Administration Perspective ...69
Abbildung 39: Benutzeransicht in Polarion Requirements ...70
Abbildung 40: Gruppenansicht in Polarion Requirements ...71
Abbildung 41: Synchronize SVN Access File...72
Abbildung 42: Zugriffsrechte im Polarion Requirements...73
Abbildung 43: Monitor von Polarion Requirements...74
Abbildung 44: Projektort und Projekt ID ...75
Abbildung 45: Template ...76
Abbildung 46: Projektzusammenfassung...76
Abbildung 47: Repository des Polarion Requirements...77
Abbildung 48: Variante A: Requirement erstellen ...78
Abbildung 49: Variante B: Requirement erstellen ...78
Abbildung 50: Module Designer ...79
Abbildung 51: Table Configuration...80
Abbildung 52: Attribute bearbeiten...81
Abbildung 53: Requirement suchen...82
Abbildung 54: Requirement ändern ...82
Abbildung 55: Suspect Requirements...83
Abbildung 56: Beobachtung der Requirements ...84
Abbildung 57: Historie in Polarion Requirements...85
Abbildung 58: Abhängigkeitsmatrix im Polarion Requirements ...86
Abbildung 59: Baselines im Polarion Requirements ...87
Abbildung 60: Export im Polarion Requirements ...88
6
Tabellenverzeichnis
Tabelle 1: CaliberRM Kurzbeschreibung ...32
Tabelle 2: Phasen des Software-Entwicklungsprozesses bei CaliberRM...35
Tabelle 3: CaliberRM Software,-Hardwareanforderungen [BOR-08] ...35
Tabelle 4: Komponenten des CaliberRM [BOR-08] ...36
Tabelle 5: Polarion Requirements Kurzbeschreibung...59
Tabelle 6: Phasen des Software-Entwicklungsprozesses im Polarion Requirements ..61
Tabelle 7: Polarion Requirements Software- und Hardwareanforderungen [POL-08] ..62
Tabelle 8: Komponenten des Polarion Requirements [POL-08] ...62
Tabelle 9: Vergleich der unterstützten Betriebssysteme für den Client ...91
Tabelle 10: Vergleich der unterstützten Betriebssystem für den Server ...91
Tabelle 11: Vergleich der unterstützten Software-Entwicklungsphasen ...92
Tabelle 12: Vergleich der unterstützten Datenbanken ...92
Tabelle 13: Anpassung von Menü, Layout und Glossar ...93
Tabelle 14 : Vergleich der Abhängigkeiten-Darstellungsform ...95
Tabelle 15: Vergleich der unterstützten Dateiformate im Import...96
Tabelle 16: Vergleich der unterstützten Dateiformate im Export...96
Tabelle 17: Vergleich der unterstützten Graphikformate...96
Tabelle 18: Vergleich der Produktintegrationen ...97
Tabelle 19: Vergleich der unterstützten Sprachen ...98
Tabelle 20: Preisgestaltung der Produkte ...98
7
Abkürzungsverzeichnis
ALM
Application
Lifecycle
Management
BPMN
Business Process Modeling Notation
UML
Unified
Modeling
Language
CMMI
Capability Maturity Model Integration
LDAP
Lightwight Directory Access Protocol
TFS
Team
Foundation
Server
8
Vorwort
Die Bedeutung und die Aufgaben der IT haben sich in den letzten Jahren sehr stark
verändert. Immer mehr Unternehmen investieren deswegen in Steuerungsprozesse,
die die verschiedenen Phasen des Software-Entwicklungszyklus, hauptsächlich
Requirements Management und Änderungsmanagement, unterstützen. Diese
Prozesse oder Systeme werden als ALM-Prozesse (Application Lifecycle
Management) bezeichnet. Die Herausforderung besteht nun darin, diese ALM
Lösungswerkzeuge und Prozesse miteinander zu verbinden und insbesondere die
Kommunikation zwischen Fachabteilung, IT und Qualitätssicherung zu verbessern und
sicherzustellen, dass eingesetzte Werkzeuge im Unternehmen vorhandene Prozesse
abbilden können.
Jedoch gilt:
,,A fool with a tool is still a fool" und ,,Tool follows process" [STE-07]
9
Abstract
Software development organizations must improve business impact and
responsiveness. They also need to ensure that projects meet end-user demands.
Therefore they need a requirements management solution that enables IT to track
progress, communicate and manage changes to requirements, and focus resources
throughout the application lifecycle. For this many software companies offering
requirements management tools, for effectively manage Software Requirements
throughout the application lifecycle.
The aim of this diploma thesis is to give an introduction of requirements management
by concentrating on three tools and their providers available on the german market.
The products to be evaluated are CaliberRM 2008 from Borland, Polarion
Requirements 1.0.1 from Polarion and Microsoft Visual Studio Team System 2008 from
Microsoft.
This thesis investigates how these tools are capable of simplifying the process of
requirements management and if the statements of the providers concerning
requirements management hold true.
The tools will be evaluated using a real life example, also showing the usage of each
tool to be examined. Out of this analysis it is the aim of the diploma thesis to show the
applicability of these tools in the realm of requirements management and highlighting
possible improvements and enhancements.
10
Danksagung
An dieser Stelle möchte ich mich als erstes bei dem Initator dieser Diplomarbeit, Prof.
Dr. -Ing. Thomas Siepmann von der FH Aachen bedanken, der mich bei der
Ausführung dieser Arbeit unterstützt und motiviert hat. Mein weiterer Dank geht an die
Mitarbeiter der Firma Borland, Herrn Oliver Manojlovic und der Firma Polarion, Herrn
Achim Ruder, für die geduldige Beantwortung meiner unendlich vielen Fragen. Auch
bei Jost Graaf, dem Technical Writer der Firma Ericsson möchte ich mich für die
Korrekturen bedanken. Im Besonderen geht mein herzlicher Dank an meine ganze
Familie und im speziellen an meinen lieben Ehemann Ulas Hazar, der immer an mich
geglaubt und unterstützt hat. Nicht zuletzt möchte ich mich bei meiner Freundin, dem
Organisationstalent Mahsa Davachi herzlich bedanken, die über das gesamte Studium
mich motiviert und begleitet hat.
11
1. Einleitung
Immer mehr IT-Projekte sind zum Scheitern verurteilt. Sie werden nicht rechtzeitig
fertig, verbrennen mehr Geld als geplant und erfüllen nicht die ursprünglichen
Vorgaben. Die Ursachen waren laut mehrerer Studien (siehe hierzu Kapitel 1.1) von
gescheiterten IT-Projekten zum grössten Teil auf fehlendes, beziehungsweise
unzureichendes Requirements Management zurückzuführen. Ungenaue
Anforderungsdefinitionen und die Unfähigkeit, Requirementsänderungen zu steuern,
waren nur einige Gründe für unzureichendes Requirements Management. Hinzu
kamen fehlende Traceability
1
und unvollständige Versionierung
2
von Requirements.
Inzwischen ist das werkzeugunterstützte Requirements Management für
Entwicklungschefs und Projektleiter in den Unternehmen unerlässlich geworden. Dies
haben natürlich auch Softwarefirmen sich zum Nutzen gemacht und entsprechende
Requirements Management Tools entwickelt, die das Requirements Management
erleichtern und effektiv gestalten sollen. Die Herausforderung besteht jedoch nun darin,
das ,,perfekte Tool" unter den ganzen Stubenfliegen für Requirements Management zu
finden, welches den gesamten Application Lifecycle unterstützt.
Diese Diplomarbeit beschreibt das Vorgehen und die Ergebnisse des
Evaluationsprozesses zur Auswahl eines geeigneten Requirements Management
Tools. Unter genauere Betrachtung und Prüfung ihrer Einsatztauglichkeit wurden
hierbei das CaliberRM 2008 von Borland, das Polarion Requirements 1.0.1 von
Polarion und das Microsoft Visual Studio Team System 2005 genommen.
Als erstes wird in Kapitel 2 zunächst einmal mit den wichtigsten Begriffsdefinitionen
des Requirements Management begonnen. Anschliessend werden in Kapitel 3 das
Application Lifecycle Management und die Evaluationskriterien beschrieben, die in
Kapitel 4 auf die ausgewählten Kanditaten angewandt wurden. Diese Application
Lifecycle Management Lösungswerkzeuge werden in Kapitel 4 detailliert untersucht. In
diesem Kapitel werden die Werkzeuge nach den Kriterien, die in Kapitel 3 vorgestellt
wurden, einzeln einer Analyse unterzogen. Das Kapitel 5 widmet sich den Ergebnissen
der Evaluation und fasst noch einmal überblickend zusammen.
1
Zum Begriff Traceability siehe den Glossareintrag auf Seite 112
2
Zum Begriff Versionierung siehe den Glossareintrag auf Seite 112
12
1.1 Motivation
Durch länderübergreifende Geschäftsprozesse und neue Technologien steigen auch
die Anforderungen an die Entwicklung neuer Software. Selbst die einfachsten
Softwaresysteme sind heutzutage hochkomplex. Es schlagen immer noch eine große
Zahl an IT-Entwicklungsprojekten fehl. Die meisten Fehler passieren schon zu Beginn
eines Projekts, nämlich bei der Definition der Requirements an eine Software. Im laufe
des Entwicklungsprozesses kommt es zu Requirementsänderungen die durch
fehlendes Requirements Management ebenfalls zu massiven Fehlern führen.
Eine Studie der amerikanischen Firma The Standish Group
hat dieses häufige
Scheitern von IT-Projekten unter die Lupe genommen. Alle paar Jahre erscheint der
sogenannte CHAOS-Report der Standish Group über die Ursachen von gescheiterten
Projekten in der Software Entwicklung. Die Standish Group veröffentlicht periodisch
ihre komplexen Untersuchungen über Projekte in der IT-Branche. In diesen
sogenannten ,,CHAOS-Reports" wurden Daten von 365 Unternehmen und 8380
Software-Projekten ausgewertet. Die Studie wurde in den USA durchgeführt.In diesem
Report der Standish Group wird immer wieder darauf hingewiesen, dass nicht
bekannte oder im Projektverlauf geänderte Anforderungen zu den häufigsten Ursachen
für den vorzeitigen Abbruch oder Überschreitungen im Zeit- und Kostenrahmen von
Projekten zählen.
Der Standish Group Report aus dem Jahre 1995 [STA-95] berichtet, dass 52,7% der
Projekte zwar abgeschlossen wurden, aber das ursprünglich eingeplante Budget um
bis zu 189% überstiegen wurde. Dabei wurden durchschnittlich nur 42% der geplanten
Systemfunktionen implementiert. Nur bei 16.1% der Projekte wurden die Zeit- und
Kostenvorgaben eingehalten und sämtliche geplanten Systemfunktionalitäten realisiert.
In dieser Studie wurden die Projektbeteiligten gefragt, welche Gründe zu diesem
Scheitern der Projekte vorliegen könnten. Abbildung 1: Chaos Report 1995 der
Standish Group [STA-95] zeigt die von den Projektbeteiligten genannten Ursachen
jeweils zusammen mit der Häufigkeit der Nennung.
13
Chaos-Report der Standish Group:
Abbildung 1: Chaos Report 1995 der Standish Group [STA-95]
Diese Situation hat sich über die Jahre auch nicht wesentlich gebessert. Durch den
ständig wachsenden internationalen Konkurrenzdruck gewinnt nur der, der als erstes
mit seinem Produkt auf dem Markt ist. Hierbei bleibt allzu häufig das Requirements
Management auf der Strecke. Bereits die Studien der Standish Group belegen, dass
das Requirements Management zu den wichtigsten Disziplinen des Systems- und
Software-Engineerings gehört.
2.2 Zielsetzung und Konzeption dieser Arbeit
Die heutigen Software-Entwicklungsunternehmen müssen ihren Unternehmenseinfluss
und ihre Reaktionsfähigkeit stark verbessern. Sie müssen sicherstellen, dass Projekte
den Anforderungen des Endbenutzers entsprechen. Um das sicherzustellen benötigt
man eine Requirements Management Lösung, die es der IT Branche ermöglicht, den
Software-Entwicklungsablauf zu verfolgen, veränderte Requirements zu kommu-
nizieren und die Ressourcen auf den gesamten Anwendungslebenszyklus zu
konzentrieren. Hierzu bieten mittlerweile viele Softwarefirmen Requirements
23 %
12,8 %
12,3 %
11,8 %
7,5 %
7,0 %
6,4 %
5.9 %
5,3 %
unzureichende Partizipation der User
unvollständige Requirements
Änderungen der Requirements
mangelnde Managementunterstützung
technologische Inkompetenz
fehlende Ressourcen
unrealistische Erwartungen
unklare Ziele
unrealistische Zeitvorgaben
Neue Technologie
Sonstiges
4,3 %
3,7 %
14
Management Tools an, die den Unternehmen eine effektive Verwaltung von Software-
Requirements während des gesamten Anwendungslebenszyklus bieten sollen.
In dieser Arbeit wird eine Evaluation von ausgewählten Requirements Management
Tools vorgestellt. Ziel dieser Arbeit ist die Einführung in die Thematik des
Requirements Managements und schwerpunktmässig die genauere Betrachtung von
drei, derzeit auf dem deutschsprachigen Markt verfügbaren Werkzeuge und deren
Hersteller.
Bei den zu evaluierenden Produkten handelt es sich hierbei um das CaliberRM 2008
von Borland, Polarion Requirements 1.0.1 2008 von Polarion und dem Microsoft Visual
Studio Team System 2008 von Microsoft.
Die Arbeit untersucht anhand einer Evaluation, inwieweit diese Werkzeuge den
Requirements Management Prozess vereinfachen und ob die Herstellerangaben
bezüglich des Requirements Management halten, was sie versprechen.
Anhand eines Praxisbeispiels werden die Werkzeuge einer Anforderungsanalyse
unterzogen. Hierbei wird auch auf die jeweilige Funktionsweise der zu evaluierenden
Werkzeuge eingegangen. Ziel ist es aus dieser Analyse eine fundierte Aussage
betreffend der Eignung der Werkzeuge für den Einsatz im Requirements Management
zu treffen und eventuelle Erweiterungs- und Verbesserungspotentiale offen zu legen.
15
2. Requirement, Requirements Management und
Requirements Engineering
Requirements, im Deutschen auch als Anforderungen (an Systeme) bezeichnet, stellen
die Basis für die Entwicklung komplexer Systeme und von Software dar. Sie bilden
häufig die vertragliche Grundlage für die Realisierung dieser Systeme, neue oder
geänderte Anforderungen tauchen aber auch immer wieder über den gesamten
Lebenszyklus des Systems auf [ITE-07].
Abbildung 2: Abgrenzung von Requirements Management, Engineering
und ALM [ITE-07]
Requirements Engineering
Anforderung
geänderte
Anforderung
neue
Anforderung
neue
Anforderung
Problem
Fehler
Spezifikation
Analyse
Design
Umsetzung
Wartung
Application Lifecyle
Management
Requirements
Requirements Management
16
2.1 Requirements
Management
In der Literatur finden sich viele unterschiedliche Definitionen von Requirements,
Requirements Management und Requirements Engineering. Diese überschneiden sich
teilweise in ihren Definitionen. Ein Oberbegriff, der alle Aktivitäten rund um
Anforderungen zusammenfasst, wird aber nicht eindeutig festgelegt.
So definiert man zum Beispiel Requirements Management als:
,,Systematischen Ansatz, Anforderungen des Systems zu erheben, zu organisieren und
zu dokumentieren und einen Prozess, der eine Übereinkunft zwischen dem Kunden
und dem Projektteam etabliert und pflegt für die sich ändernden Anforderungen an ein
System." [LEF-99,S.16]
Requirements Management ist eine Managementaufgabe für die effiziente und
fehlerarme Entwicklung komplexer Systeme. Es umfasst das Requirements
Engineering sowie Maßnahmen zur Steuerung, Kontrolle und Verwaltung von
Anforderungen, also Risikomanagement, Änderungsmanagement
3
und Umsetzungs-
management. Damit ist gemeint, dass Prozesse definiert und implementiert werden, in
dem die Anforderungsdokumentation während des gesamten Projektverlaufs
aktualisiert wird und diese am Ende als Grundlage für die Erstellung von Testfällen
verwendet werden kann. Requirements Management zielt darauf ab, aus zunächst
undeutlichen oder sogar widersprüchlichen Anforderungen und Zielvorstellungen
sukzessiv eine vollständige und eindeutige Anforderungsdefinition zu erfassen, welche
aber auch von allen Beteiligten des Entwicklungsprozesses mitgetragen wird. Um das
zu realisieren, ist Kommunikation und Zusammenarbeit zwischen einer Vielzahl von
Personen in ihren unterschiedlichen Rollen unumgänglich. Bei den beteiligten
Personen handelt es sich dabei um Kunden, Projektmanager, Business Analysten,
Designern, Entwicklern und Testern [NET-08].
2.2 Requirements
Engineering
Das Requirements Engineering ist der Prozess der Spezifikation und Verfeinerung von
Anforderungen. Dieses steht typischerweise am Anfang von Entwicklungsprojekten.
Anforderungen werden an das zukünftige System erhoben, dokumentiert und
schrittweise verfeinert. Wichtig ist hierbei die saubere Methodik der Anforderungs-
erhebung und Anforderungsdokumentation.
3
zum Begriff Änderungsmanagement siehe Glossareintrag auf Seite 112
17
2.3 Requirements
Requirements stellen die Basis für die Entwicklung komplexer Systeme und von
Software dar. Sie sind eine Aussage über eine zu erfüllende Eigenschaft oder zu
erbringende Leistung eines Produktes, Systems oder Prozesses. Ebenso uneindeutig
wie das Requirements Management wird der Begriff Requirements in der Literatur
verwendet.
Das IEEE definiert beispielsweise Anforderung wie folgt [IEEE610]:
Eine dokumentierte Darstellung einer Bedingung oder Fähigkeit gemäß 1 oder 2:
1.
Beschaffenheit oder Fähigkeit, die von einem Benutzer zur Lösung eines
Problems oder zur Erreichung eines Ziels benötigt wird.
2.
Beschaffenheit oder Fähigkeit, die ein System oder Systemteile erfüllen oder
besitzen müssen, um einen Vertrag, eine Norm oder eine Spezifikation oder
andere, formell vorgegebene Dokumente zu erfüllen.
Darunter fallen beispielsweise keine Anforderungen an Personen oder Tätigkeiten, die
während der Systemerstellung eine Rolle spielen. Zum Beispiel, dass ein
Auftragnehmer ein Tool zur Anforderungsverwaltung einsetzen muss.
Eine umfassendere Definition lässt sich bei Rupp [RUP-07,S.13] finden:
Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung eines Pro-
dukts, eines Prozesses oder der am Prozess beteiligten Personen.
Um einen genaueren Einblick zu erhalten, was alles Anforderungen sein können, dient
die folgende Aufzählung und Erklärung zu Arten von Anforderungen im nächsten
Kapitel.
2.3.1 Klassifizierung von Requirements
Funktionale Anforderungen [RUP-07,S.16]
beschreiben Aktionen, die von einem System selbstständig ausgeführt werden sollen,
Interaktionen des Systems mit menschlichen Nutzern oder Systemen (Eingaben,
Ausgaben) und Anforderungen zu allgemeinen, funktionalen Vereinbarungen und
Einschränkungen.
18
Technische Anforderungen [RUP-07,S.16]
sind abgegrenzt zu den eher fachlich motivierten funktionalen Anforderungen. Dazu
zählen Hardwareanforderungen, Architekturanforderungen, Anforderungen an die
Programmiersprachen. Diese Anforderungen werden oft notwendig, weil ein System in
ein bestehendes technisches Umfeld eingebettet werden muss oder Verträge die
Nutzung einer bestimmten Infrastruktur vorschreiben.
Anforderungen an die Benutzungsschnittstelle [RUP-07,S.16]
sind Beschreibungen, die üblicherweise unter Mensch-Maschine-Schnittstelle einge-
ordnet werden, also Form und Funktion von Ein- und Ausgabegeräten, die dem
menschlichen Benutzer die Interaktion mit dem System ermöglichen.
Qualitätsanforderungen
sind Angaben über die Güte des Produktes. Manchmal werden sie auch Dienstgüte-
Anforderungen oder Dienstqualitäts-Anforderungen (quality of service requirements)
genannt. Die DIN EN ISO 66272 [DIN94] unterteilt die Dienstgüte beispielsweise in die
sechs Merkmale Zuverlässigkeit, Benutzbarkeit, Funktionsumfang, Effizienz, Änder-
barkeit und Übertragbarkeit.
Anforderungen an sonstige Lieferbestandteile [RUP-07,S.16]
definieren weitere oft nicht sofort sichtbare Produkte im Rahmen einer Entwicklung wie
Handbücher, Projektpläne oder Trainingsunterlagen. Nicht nur die Existenz eines
Installationshandbuches kann gefordert sein, sondern auch bestimmte Eigenschaften
des Handbuchs selbst.
Anforderungen an durchzuführende Tätigkeiten [RUP-07,S.16]
bestimmen, wie Aktivitäten im Rahmen der Systementwicklung oder Systemeinführung
abzulaufen haben. Zu nennen sind hier unter anderem Anforderungen an die
Vorgehensweise (Systemerstellung, Systemprüfung), anzuwendende Standards,
Hilfsmittel (Tools), die Durchführung von Besprechungen, von Abnahmetests (fachliche
Abnahme, betriebliche Abnahme) und die Festlegung von Terminen für z. B. die In-
betriebnahme. Eine andere Bezeichnung ist Projektanforderung (project requirement)
[IEEE830].
Rechtlich vertragliche Anforderungen [RUP-07,S.16]
sind Angaben zu Zahlungsmeilensteinen sowie zu Vertragsstrafen, zum Umgang mit
Änderungen der Anforderungen.
19
Nicht-funktionale Anforderungen [KOT-03, S.190- S.195]
beziehen sich auf das erwartete Systemverhalten. Sie beschreiben Eigenschaften, die
zunächst schwer quantifizierbar sind. Die nicht-funktionalen Anforderungen sind wie in
der folgenden Abbildung unterteilt:
Abbildung 3: Requirements Engineering Process and Techniques [KOT-03, S.190]
Non-functional requirements (Nicht-funktionale Anforderungen) sind im
Entwicklungsprozess früh zu berücksichtigen. Sie werden also parallel zu den
functional requirements erhoben. Man muss sich hier vom einfachen ,,drauflos-
programmieren" distanzieren. Die Entwickler sollen sich schon in der Planungsphase
Gedanken darüber machen, welche nicht-funktionalen Anforderungen neben den
funktionalen an die Software gestellt werden.
Die Process requirements sind die Nebenbedingungen an den Entwicklungsprozess
des Systems seitens der Kunden. Diese beinhalten die Lieferanforderungen (Delivery
requirements), Implementationsanforderungen (Implementation requirements) sowie
die Einhaltung von bestimmten Standards ( Standards requirements). Diese Art von
Non-functional requirements
Project
requirements
Delivery
requirements
Implementation
requirements
Standards
requirements
Product requirements
Usability requirements
Reliability requirements
Safety requirements
Efficiency requirements
Performance
requirements
Capacity requirements
External
requirements
Legal
constraints
Economic
constraints
Interoperability
requirements
20
Requirements sind typisch für Grosskunden, die ihre eigenen Standards, Praktiken und
technisches Personal haben.
Die Product requirements sind Requirements, welche die gewünschten
Charakteristiken, die das zu entwickelnde Softwaresystems besitzen muss,
spezifizieren. Hierzu gehört zum Beispiel die Zuverlässigkeit (Reliability requirements)
des Systems, die Benutzerfreundlichkeit (Usability requirements) und die Sicherheit
(Safety requirements) des Systems, um nur einige zu nennen. Die Performance
requirements sind Zeit- und Platzgrenzen oder auch die Überlebensfähigkeit einer
Software. Letztgenanntes Requirement stellt die Frage, ob zum Beispiel die Software
ein Feuer überleben kann.
Die External requirements sind Requirements, welche in Product requirements und
Process requirements ihren Platz haben. Sie sind aus der Umgebung, aus der das
System entwickelt wurde, abgeleitet.
2.3.2
Qualitätskriterien von Anforderungsspezifikationen
Um eine Anforderung messen zu können, ob sie qualitativ hochwertig ist, werden von
IEEE830 folgende Kriterien für einzelne Anforderungen festgesetzt:
Korrekt, eindeutig, vollständig, konsistent, bewertet, prüfbar, modifizierbar und
verfolgbar müssen Anforderungen sein.
Wichtig sind auch die Qualitätskriterien für eine Anforderungsspezifkation, d.h die zu
verwaltende Sammlung aller Anforderungen, die während der Anforderungsverwaltung
zu beachten sind. Eine Anforderungsspezifikation muss folgenden Kriterien genügen
[RUP-07,S.27-S.34]:
Angemessener Umfang und klare Struktur:
Die Anforderungsspezifikation bietet eine Momentaufnahme des Wissens zu einem
bestimmten Zeitpunkt. Um lesbar zu sein, ist sie in ihrem Umfang begrenzt und nach
Kriterien sortiert, die dem anvisierten Leserkreis das Lesen erleichtern. Leider lassen
sich bezüglich eines angemessenen Umfangs keine eindeutigen Messwerte angeben.
Eine Spezifikation mit einer guten Struktur, bei welcher der Leser die für ihn
interessanten Teile problemlos findet, kann umfangreicher sein als eine , von der man
erwartet, dass der Leser sie von vorne nach hinten durchliest.
Sortierbarkeit:
Anforderungsspezifikationen sollten es ermöglichen, die Anforderungen nach
verschiedenen Kriterien zu sortieren. Als mögliche Kriterien kommen dabei zum
21
Beispiel Wichtigkeit, Detaillierungsniveau, Teilsystemzugehörigkeit, Zugehörigkeit zu
einem Use Case oder Kapitel in Betracht. Diese unterschiedlichen Sichten auf
Anforderungsspezifikationen ermöglichen ein zielgerichtetes Lesen für alle
erdenklichen Stakeholder
4
.
Qualitativ hochwertig:
Eine exzellente Anforderungsspezifikation sollte natürlich exzellente Anforderungen
enthalten. Insbesondere in Projekten, bei denen viele Personen an einer
Anforderungsspezifikation schreiben, ist es notwendig, die Qualitätskriterien für
Einzelanforderungen vorab für das spezielle Projekt festzulegen und zu überprüfen.
Vollständigkeit:
Anforderungsspezifikationen müssen vollständig sein, das heißt, sie müssen alle
relevanten Anforderungen beinhalten. Für jede gewünschte Funktion des Systems
müssen alle möglichen Eingaben, eingehende Ereignisse sowie die geforderten
Reaktionen des Systems beschrieben werden. Auch Anforderungen bezüglich der
Qualität, der Reaktionszeiten, der Verfügbarkeit und Bedienbarkeit des Systems
müssen notiert werden. Zur Vollständigkeit tragen aber auch formale Gesichtspunkte
bei. Grafiken, Diagramme und Tabellen müssen beschriftet werden. Ein wichtiger
Punkt ist das Vorhandensein konsistenter Quellen- und Abkürzungsverzeichnisse.
Definitionen oder Normreferenzen, die Begriffe verbindlich werden lassen, sind
notwendiger Bestandteil einer jeden Anforderungsspezifikation. Die Vollständigkeit der
Anforderungsspezifikation stellt mitunter die größte Herausforderung der
Anforderungsanalyse dar. Häufig muss man einen Kompromiss zwischen verfügbaren
Zeitressourcen und Vollständigkeit treffen.
Traceability Verfolgbarkeit:
Eines der wichtigsten Kriterien einer Anforderungsspezifikation ist die Traceability, also
die Nachvollziehbarkeit von Zusammenhängen. Deutlich wird der Sachverhalt, wenn
man sich eine mehrere hundert Seiten umfassende Anforderungsspezifikation vorstellt.
Die Traceability hört allerdings nicht bei der Anforderungsspezifikation auf, sondern
erstreckt sich auf weitere Dokumente (zum Beispiel Geschäftsprozessmodell, Test-
oder Entwurfspläne), die in vorangegangenen oder späteren Entwicklungsphasen
erstellt werden.
Modifizier- und Erweiterbarkeit:
Anforderungsspezifikationen müssen erweiterbar sein. Es gibt Anforderungen, die
nachträglich geändert oder neu hinzugefügt oder entfernt werden. Gleichzeitig
bedeutet das aber auch, dass Struktur und Aufbau der Anforderungsspezifikation leicht
modifizierbar und erweiterbar sein müssen.
4
zum Begriff ,,Stakeholder" siehe den Glossareintrag auf Seite 112
22
Gemeinsame Zugreifbarkeit:
Wie bereits erwähnt, wirken in größeren Projekten mehrere Personen gleichzeitig an
einer Anforderungsspezifikation mit. Dies bedingt, dass in dem Dokument der Autor
eines jeden Eintrags vermerkt wird.
23
3 Application
Lifecycle
Management
Auch im Bereich des Application Lifecyle Managements wird man mit der Verwaltung
von Anforderungen konfrontiert. Hier bezieht es sich auf die allgemeine, übergeordnete
Verwaltung von Anforderungen über den gesamten Lebenszyklus eines Systems. Ein
Schwerpunkt bildet dabei die Aufnahme von Meldungen der Auftraggeber oder der
Benutzer. Dabei kann es sich um Probleme und/oder Änderungswünsche handeln. Auf
Projektseite müssen diese Probleme oder Wünsche klassifiziert werden. Bei den
Anforderungen kann es sich um neue oder geänderte Anforderungen handeln, die eine
Änderungsnachfrage (,,Change Request")
5
darstellen. Die Aufwandschätzung, Abstim-
mung und Release Planung stehen in einem ersten Schritt im Vordergrund. Erst dann
werden sie zur Umsetzung weitergegeben, was auch die Weitergabe an einen Verfein-
erungsprozess bedeuten kann.
3.1 Was
ist
ALM
?
Application Lifecycle Management steht für zwei Dinge [MIC-08]:
· Die Verbesserung des Zusammenspiels der einzelnen Aktivitäten und
Teilprozesse innerhalb des Herstellungsprozesses von Software.
· Für Softwareprodukte, die zu diesem Zweck eingesetzt werden.
Application Lifecycle Management (ALM) umfasst den gesamten Lebenszyklus einer
Softwarelösung. Dies bedeutet, dass die Application Development Phase (Anwen-
dungsentwicklungphase) und die Service Management Phase (Anwendungs-
betriebsphase) bereits in einem einzigen Lebenszyklus integriert sind. Das soll eine
reibungslose Integration der zu entwickelnden Applikation in die zukünftige System-
landschaft sicher stellen. Abbildung 4: Application Lifecycle Management soll das
näher veranschaulichen:
5
zum Begriff Change Request siehe den Glossareintrag auf Seite 112
24
Abbildung 4: Application Lifecycle Management
Die ALM-Plattform ermöglicht allen Beteiligten eines Softwareprozesses die Kommu-
nikation untereinander. Sie ist ganzheitlich zu betrachten und fordert hohe Flexibilität in
allen Teilbereichen des Softwareprozesses. Application Lifecycle Management
kümmert sich um die Koordination der einzelnen Teilprozesse und Aktivitäten innerhalb
eines Projektes. Sie stellt eine Beziehung zwischen verschiedenen Artefakten eines
Projektes her und verwaltet diese auch. Mit schlanken Prozessen und geeigneten
Tools zu deren Automatisierung lässt sich die Qualität der Anwendung über ihren
gesamten Lebenszyklus hinweg verbesseren. Welche Tools das sein können, werden
in Kapitel 4 vorgestellt.
In der praktischen Umsetzung wird im Application Lifecycle Management eine
Software, die sich noch im Stadium der Entwicklung befindet, sehr früh in den
Testbetrieb überführt. In der Abbildung 5: Application Lifecycle nach ITIL [IBM-05] wird
das näher veranschaulicht.
Project
Management
Requirements
Management
Design
Architektur
Quality Test
Software
Configuration
Management
Development
Ende der Leseprobe aus 117 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2009, Evaluierung von Requirement Management Systemen in der Software Entwicklung, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/227719
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare