IBM Rational DOORS
Allgemein
Bei Doors (Dynamic Object Oriented Requirements System) handelt es sich um Tool zum Anforderungsmanagement des amerikanischen Unternehmens IBM. Das seit 1993 existierende Tool bietet die Möglichkeit große Mengen von Anforderungen angemessen und übersichtlich zu verwalten. Es wird daher von vielen Firmen genutzt und findet besonders in der Software-Entwicklung häufig Anwendung. Doors stellt Anforderungen grundsätzlich in tabellarischer Form dar. Dabei erhält jedes einzelne Element eine Reihe von Eigenschaften. Welche Eigenschaften dies sind, wird doch durch den Benutzer selbst festgelegt. Klassische Angaben, die fast immer verwendet werden sind:
- Inhalt des Requirements - Anmerkungen - Verantwortlicher für die Umsetzung und/oder Verwaltung der Anforderung - Aktueller Status (z.B. In Arbeit, Abgelehnt, Erledigt) - Letztes Änderungsdatum - Meilenstein / Abschlussdatum - Identifikationsnummer
Je nach Anwendungsfall können weitere Attribute hinzugefügt werden. In der Regel existiert ein Doors-Admin, der eine Vorlage mit allen für ein Projekt erforderlichen Anforderungseigenschaften erstellt. Diese Vorlage wird anschließend von allen Entwicklern für die Dokumente dieses Projekts genutzt, sodass sie nur die Spalten mit den festgelegten Eigenschaften ausfüllen müssen.
Doors bietet zur Verwaltung der Requirements die Möglichkeit Anforderungen, die in Verbindung miteinander stehen, zu verlinken. So lassen sich Anforderungen auch durch verschiedene Dokumente verfolgen. Abbildung "Verlinkungen in Doors" zeigt wie solche Links zu erstellen sind. Ein Element kann dabei unbegrenzt viele Links erhalten. Neben den Elementen, die verlinkt wurden, wird auch die Richtung des Links gespeichert. Damit lassen sich u.a. Abhängigkeiten untereinander darstellen.
In vielen Projekten existieren weit über 1.000 Anforderungen. Die Übersicht kann bei einer so enormen Anzahl an Requirements schnell verloren. Davon abgesehen ist es oftmals auch gar nicht sinnvoll alle Anforderungen zu betrachten. Beispielsweise würde es Sinn machen vor einem Meilensteintermin nur die Anforderungen zu betrachten, die auch zu diesem Termin abgeschlossen sein müssen. Hierfür bietet Doors eine Filter-Funktion, die in Abbildung "Filterfunktion in Doors" zu sehen ist. Grundsätzlich setzt sich ein Filter stets aus zwei Informationen zusammen. Ersteres ist das Attribut das gefiltert werden soll und die zweite Angabe ist der Wert bzw. der Inhalt dieses Attributs nach dem gesucht werden soll. Die einzelnen Filter lassen sich anschließend durch logische Operatoren verknüpfen, sodass es möglich ist zuerst nach allen Anforderungen zu suchen, die zu einem bestimmten Termin erfüllt sein müssen und aus diesen dann diejenigen herauszufiltern, die bisher noch nicht den Status "Erfüllt" besitzen.
Außerdem bietet Doors zahlreiche Schnittstellen zu anderen Tools, die ebenfalls in Verbindung mit dem Anforderungsmanagement genutzt werden können. Das ermöglicht einerseits das Exportieren eines Doors-Dokuments nach Word oder Excel. Andererseits lassen sich Anforderungen auch aus vielen verschiedenen Formaten in Doors übertragen. Dies ist in der Praxis ein großer Vorteil, da Kunde und Zulieferer nicht zwingend das gleiche Tool für ihr Anforderungsmanagement verwenden. Die umfangreichen Schnittstellen sorgen dafür wenig Zeit für das portieren der Informationen aufgebracht werden muss. In Abbildung "Export und Import in Doors" ist aufgezeigt wie ein Anforderungen aus Doors exportiert werden können.
Umsetzung von Lastenheft zu Pflichtenheft am Beispiel des SDE Praktikums
Das Lastenheft enthält die Anforderungen des Kunden bzw. Auftraggebers. Nach Projektvergabe und damit verbundenem Entwicklungsstart ist eine der ersten Aufgaben des Entwicklungsteams diese Anforderungen zu lesen und ein Pflichtenheft zu erstellen. Dieses enthält die Anforderungen an das Produkt aus Sicht der Entwickler und muss bevor mit der Umsetzung begonnen werden kann zusammen mit dem Auftraggeber nochmals durchgegangen werden, um Problemfälle zu klären und Missverständnissen vorzubeugen.
Das Lastenheft des Projektes lag in zwei Teilen, einem funktionalen und einem nicht-funktionalen, vor. Der erste Schritt bestand darin Anforderungen auf die Entwickler aufzuteilen, um so schneller ein Pflichtenheft erstellen zu können. Da das Entwicklungsteam thematisch in sechs Bereiche unterteilt war, wurden jedem Bereich die passenden Anforderungen aus dem funktionalen Lastenheft zugeteilt. Die nicht-funktionalen Anforderungen wurden anschließend ebenfalls verteilt. Die Anforderungen wurden dann untergliedert, sodass sie folgende Kriterien erfüllen:
- Eindeutigkeit - Testbarkeit - widerspruchsfrei - atomar
Zur Dokumentation der Arbeitsergebnisse dieses Schrittes wurde Doors verwendet. Die Aufteilung orientiert sich dabei am Lastenheft, sodass ebenfalls zwei Dokumente existieren, die einerseits funktionale andererseits nicht-funktionale Anforderungen enthalten. Eine Vorlage mit allen erforderlichen Attributen wurde erstellt und als Standart View für die Dokumente in diesem Projekt eingerichtet. Die einzelnen Attribute sind der oben aufgeführten Liste zu entnehmen.
Aus einer Anforderung im Lastenheft konnten bei diesem Verfahren mehrere Punkte im Pflichtenheft entstehen. Für jeden dieser Punkte wird ein Verantwortlicher festgelegt, der anschließend Angaben darüber macht zu welchem Meilenstein die Anforderung umgesetzt werden soll. Der Status der Anforderungen wurde während der Projektlaufzeit aktuell gehalten, sodass vor Meilensteinen stets ersichtlich war welche Arbeiten noch erledigen waren.
Um die Übersichtlichkeit zu erhöhen und um deutlich zu machen, dass alle im Lastenheft enthaltenen Anforderungen berücksichtigt wurden, wurden die Requirements des Pflichtenheftes auf das Lastenheft verlinkt. Wurde ein Element des Lastenheftes in mehrere Punkte aufgespalten wurden alle aus diesem entstandenen Punkte auf das Mutter-Requirement verlinkt. Dass auf diese Weise jede Anforderung aus dem Lastenheft mindestens einen Link erhalten hat, belegt, dass keine Anforderungen vernachlässigt wurden und das Anforderungsmanagement bis zu diesem Punkt konsistent ist.
Außerdem wurde ein Abhängigkeitsbaum erstellt, der die einzelnen Anforderungen enthält und hierarchisch darstellt. Ein solches Dokument ist sinnvoll, da das Nicht-Erfüllen einer Anforderung möglicherweise verhindert das weitere Punkte umgesetzt werden können. So würde es beispielsweise keinen Sinn machen eine Anforderung umzusetzen, die das Ausweichen bei Hindernissen verlangt, wenn nicht zuvor das Requirement erfüllt wurde, dass fordert Hindernisse überhaupt zu erkennen.