Evaluierung von Requirement Management Systemen in der Software Entwicklung

Diplomarbeit von Özgür Hazar

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ößten 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 und unvollständige Versionierung 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.

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.

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.

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 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.

Inhaltsverzeichnis:

Textprobe:

Kapitel 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:

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 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.

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.

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.