Die Bedeutung und die Aufgaben der IT haben sich in den letzten Jahren sehr stark verändert. Immer mehr Unternehmen investieren deswegen in sogenannte ALM-Prozesse (Application Lifecycle Management), die die verschiedenen Phasen des Software-Entwicklungszyklus’, hauptsächlich Requirements Management und Änderungsmanagement, unterstützen. Die Herausforderung besteht nun darin, diese 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. Man versucht das ‚perfekte Tool’ unter den ganzen Stubenfliegen für Requirements Management zu finden, welches den gesamten Application Lifecycle unterstützt und unzureichendem Requirements Management entgegenwirkt. Ungenaue Anforderungsdefinitionen und die Unfähigkeit, Requirementsänderungen zu steuern, waren nur einige Gründe für mangelhaftes 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 sich natürlich auch Softwarefirmen zunutze gemacht und entsprechende Requirements Management Tools entwickelt, die das Requirements Management erleichtern und effektiv gestalten sollen. Diese Studie 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.

Textprobe: Kapitel 4.1.5, Multiuserfähigkeit des CaliberRM: In dem CaliberRM ist ein Rollenkonzept integriert, das bedeutet, dass vom Administrator beliebig viele Rollen vergeben werden können. Welche das sein können sind zum Beispiel in Abbildung 12: Benutzeransicht im CaliberRM Administrator und in Abbildung 13: Gruppenansicht im CaliberRM Administrator dargestellt. Der CaliberRM Administrator kann deswegen neue Benutzer und neue Gruppen erstellen. Jede von den Rollen hat ein eigenes Passwort, welches in regelmässigen Abständen geändert werden muss. Die Zugriffsrechte werden in CaliberRM auf Rollenebene vergeben und werden automatisch vererbt. Das bedeutet, das der Benutzer einer Rolle auch sämtliche Zugriffsrechte dieser Rolle erbt. Bevor der Benutzer mit der eigentlichen Eingabe und Bearbeitung von Requirements überhaupt beginnen kann, muss man als erstes im CaliberRM Administrator das Projekt definieren, beziehungsweise neu erstellen. In unserem Fall wird das in Kapitel 3.4 beschriebene Praxisbeispiel Adressbuch angewendet. Im Administrator werden Angaben wie, wer am Projekt beteiligt ist und welche Gruppen mitwirken dürfen, festgelegt. Hierzu stehen die folgenden Views zur Verfügung: Es gibt vier Ansichten, die in dem Menüfeld unter View oder Iconleiste hin- und herschaltbar sind: - Projektansicht. - Benutzeransicht. - Gruppenansicht. - Ansicht zum Überwachen von Benutzerverbindungen (Monitor). In der Projektansicht werden alle Projekte aufgeführt und die für ein ausgewähltes Projekt spezifischen Informationen angezeigt, beispielsweise allgemeine Projektinformationen (Project Info), die dem Projekt zugewiesenen Benutzer und Gruppen (Group Assignment), Projekt-Baselines und Projektintegrationen (External Traceability). 4.2.2, Die Software-Entwicklungsphasen im Polarion Requirements: Das Polarion Requirements unterstützt den Softwareentwicklungsprozess nicht in allen Phasen. Hauptaugenmerk liegt hier in der Analysephase die ganz abgedeckt ist. Planungsphase: Diese Phase wird von Polarion Requirements nicht unterstützt. Analysephase: Requirement Findung (Elicitation) ist Kernbestandteil des Requirements Management und deswegen von sehr hoher Bedeutung. Im Polarion Requirements werden Requirements definiert, festgehalten und gesammelt. Über Diskussionsforen können auch Feedback über Requirements abgegeben werden. Designphase: Diese Phase wird von Polarion Requirements nicht unterstützt. Implementierungsphase Die Codierung beziehungsweise die Implementierung der Software wird im Polarion Requirements nicht unterstützt. Testphase: Validierungskriterien können an den Anforderungen hinterlegt werden. Diese Kriterien können in Polarion Requirements zu Testspezifikationsanforderungen zusammengefasst werden. Die eigentliche Testspezifikation sowie Durchführung der Tests erfolgt jedoch nicht mehr im Polarion Requirements. Releasephase: Diese Phase wird im Polarion Requirements durch das Baselining unterstüzt, mit der Planung der Baselines sowie mit der Baseline Wartung ist die Zuordnung von Anforderungsversionen zu Baseline und die Zuordnung von Anforderungensversionen zu entsprechenden Releases in der Entwicklung möglich.

• Application Lifecycle Management

• IT

• Qualitätssicherung

• CaliberRM 2008

• Polarion Requirements 1.0.1

• Microsoft Visual Studio