Rational RequisitePro bieten Ihnen zwei Arbeitsbereiche (Workplaces):

• den Word Workplace zum Bearbeiten von Anforderungen in Microsoft Word Dokumenten, und
• den Views Workplace zum direkten Bearbeiten von Anforderungen in der Rational RequisitePro Datenbank.

Abbildung 2 verdeutlich den Zusammenhang.

Abbildung 2: Workplaces in Rational RequisitePro.

Wie Sie mit den Workplaces nun konkret Ihre Anforderungen verwalten können erfahren Sie in Kapitel 4.4.4.

Auch Rational RequisitePro arbeitet mit sogenannten Projekten. Damit ist der Speicherort aller Informationen, die Sie zur Durchführung des Anforderungsmanagements mit Rational RequisitePro benötigen, gemeint.   Ein solches Projekt enthält

• Anforderungen, die auf Anforderungstypen basieren,
• Attribute, die Anforderungen genauer beschreiben, und
• Dokumente, die auf Dokumenttypen basieren.

Klingt alles ziemlich einfach. Das die Struktur allerdings etwas komplexer ist, soll Abbildung 3 verdeutlichen.

Abbildung 3 Projektstruktur in Rational Requisite Pro

Mit Hilfe der im Rational RequisitePro Projekt gespeicherten Informationen, können Sie z.B. die Historie von Anforderungen nachzuvollziehen. Auch der Aufbau von Anforderungsstrukturen und damit die Durchführung von Impact-Analysen sind mit diesen Daten leicht machbar.   Es ist möglich, ein Rational RequisitePro Projekt auf verschiedenen Datenbankplattformen zu speichern. In der Version 2001 werden folgende Datenbankmanagementsystem unterstützt:

• Microsoft Access,
• Oracle, und
• Microsoft SQL Server.

Diese Möglichkeiten verdeutlicht Abbildung 4.

Als erster Arbeitsschritt muss in Rational RequisitePro ein Projekt angelegt oder geöffnet werden. Da wir ganz am Anfang stehen, haben wir noch kein Rational RequisitePro Projekt und werden deshalb ein neues Projekt definieren. Sie haben dabei die Möglichkeit, aus mehreren Projektvorlagen zu wählen. Auch die Möglichkeit aus einem Ihrer bestehenden Rational RequisitePro Projekte eine Projektvorlage für künftige Projekte zu machen, ist gegeben.
 nbsp;Als Beispiel für diese Buch wähle ich ein im Lieferumfang der Rational Suite AnalystStudio enthaltenes Beispiel. Dies gibt Ihnen die Möglichkeit zu versuchen, das Beispiel "life" nachzuvollziehen.
  Nachdem der Name, der Speicherort, die gewünschte Datenbankplattform und eine Beschreibung für das Rational RequisitePro Projekt eingegeben wurde (s. Abbildung 4), kann nun mit der eigentlichen Vorbereitung des Projektes begonnen werden.

Abbildung 4 Anlegen eines Rational RequisitePro Projektes

Zunächst ist die Definition von Anforderungstypen notwendig. In unserem Beispiel werden wir

• den Product Requirement Type für allgemeine Produktanforderungen,
• den Software Requirement Type für die konkreten Anforderungen an die eigentliche Anwendung und
• den Testing Requirement Type für Testanforderungen

definieren (s. Abbildung 5).   Neben diesen drei Anforderungstypen sind noch eine ganze Reihe anderer von Bedeutung (z.B: Use Case Requirement Type oder Business Requirement Type). An dieser Stelle sollen die drei definierten Anforderungstypen genügen, da sie den "Evolutionszyklus" von Anforderungen sehr gut wiederspiegeln: aus den allgemeinen Produktanforderungen werden die konkreten Anforderungen an die Anwendung und letztlicht auch die Testanforderungen entwickelt bzw. abgeleitet

Abbildung 5 Anforderungstypen

Die Abkürzungen PR, SR und TST in Abbildung 5 sind sogenannte Tags. Dies sind Kürzel, die zur Identifizierung des Typs einer Anforderung dienen und haben einen großen praktischen Nutzen. Näheres finden Sie in Kapitel 4.4.4.1.
  Zu jedem Anforderungstyp werden nun entsprechende Attribute definiert. Für jeden der drei Anforderungstypen sind dies:

• Priority zur Einstufung der Wichtigkeit der Anforderung. Somit sind Sie in der Lage, die Bearbeitungsreihenfolge der Anforderungen zu steuern und evtl. in zeitkritischen Momenten den Blick für das "Wesentliche" nicht zu verlieren. Wir beschränken uns hier auf die Prioritäten high, medium und low.
• Status, um jeweils den aktuellen Bearbeitungszustand erfassen zu können. Dies hilft Ihnen, den Überblick über Ihr Projekt aus Sicht der Anforderungen zu behalten. In dem Beispiel verwenden wir Proposed, Approved, Incorporated und Validated.
• Cost, um die Kosten, die für die Umsetzung der Anforderung angefallen sind, erfassen zu können. So behalten Sie auch hier den Überblick..
• Assigned To, um die Anforderungen einem Projektmitarbeiter konkret zuordnen zu können. Nichts ist schlimmer für ein Projekt, als wenn sich keiner der Projektmitarbeiter für etwas konkret zuständig fühlt.

Für Anforderungen des Typs Testing Requirement sind noch weitere Attribute sinnvoll (s. Abbildung 6).

Abbildung 6 Attribute von Testanforderungen

Hier spielt Rational RequisitePro erstmals sein Möglichkeiten voll aus. Wie Sie in Abbildung 6 sehen, können die Datentypen von Attributen frei vergeben werden. Dabei sind

• Listen,
• alphanumerische Texte,
• Zahlen,
• Datums- und Zeitangaben,
• URL Links, und
• die direkte Integration in Rational ClearQuest

als Datentypen möglich. Im Falle von Listen ist auch die Definition von möglichen Werten notwendig und sinnvoll (vgl. die möglichen Werte high, medium und low für das Attribut Priority).
  Als letzter Schritt bei der Definition eines Rational RequisitePro Projektes bleibt nun noch die Definition von Dokumenttypen. Da wir drei Anforderungstypen mit ausgesprochen unterschiedlichen Ausprägungen haben, werden wir auch entsprechende Dokumenttypen (s. Abbildung 7) benötigen:

• Product Requirement Document Type zur Beschreibung aller allgemeinen Produktanforderungen,
• Software Requirement Document Type zur Beschreibung aller konkreten Anforderungen an die Anwendung,
• Testing Requirement Document Type zur Beschreibung aller Testanforderungen, und
• Text Only für jedes weitere Dokument, das keine Anforderungen aber sonstige wichtige Informationen für das Projekt enthält.

Abbildung 7 Dokumenttypen

Speziell zu beachten dabei ist, dass Sie hier Ihre eigenen Microsoft Word Vorlagen zur Grundlage dieser Dokumenttypen machen können und sollten. Damit stellen Sie sicher, dass in Ihren Projekten jedes Dokument standadisiert und vom gleichen "look and feel" ist.
  Nun haben wir bereits ein relativ hartes Stück Arbeit hinter uns gebracht. Hätten Sie gedacht, dass die Definition eines Rational RequisitePro Projektes so komplex und schwierig werden würde? Sicherlich nicht, und ehrlich gesagt war die Umsetzung in Rational RequisitePro auch nicht schwierig. Schwierig war die theoretische und methodische Vorarbeit:

• die Definition von Anforderungstypen und derer Attribute,
• die Definition des Workflow, und
• die Erstellung der Microsoft Word Vorlagen.

Dies verdeutlicht abermals wie wichtig eine fundierte Grundlage für den Einsatz eines Werkzeuges und wie wertvoll in diesem Zusammenhang der Rational Unified Process mit seinen Workflows, Artefakten und Vorlagen ist.   An dieser Stelle erlaube ich mir den Hinweis, dass ich bereits einige Projekte, die zum Ziel die Einführung eines Anforderungsmanagements hatten, daran habe scheitern sehen, dass keine vernüftige methodische Vorarbeit vor dem Einsatz eines Werkzeuges gemacht wurde. Auch die besten Werkzeuge haben so oft keinerlei Chance und enden schließlich als "shelf ware", also auf dem Regal ungenutzt.   Aber wie werden denn nun Anforderungen mittels Rational RequisitePro erfasst? Dies wird das nächste Kapitel klären.