Richtlinie: Anforderungsmanagementplan
Ein Anforderungsmanagementplan definiert in der Hauptsache Stakeholder-Anfragen und ihre Zuständigkeiten, Rückverfolgbarkeitselemente, Management von Anforderungsänderungen und anforderungsbezogene Berichte und Ermittlungen. Diese Richtlinie hilft Ihnen bei der Entwicklung eines vollständigen, effektiven Plans für das Anforderungsmanagement.
Beziehungen
Hauptbeschreibung

Beziehung zu anderen Plänen

Der Anforderungsmanagementplan enthält Informationen, die mehr oder weniger auch von anderen Plänen abgedeckt werden.

Anleitung zur Anpassung finden Sie in Anforderungsmanagementplan anpassen.

Organisation, Zuständigkeit und Schnittstellen

Wie im Whitepaper Applying Requirements Management with Use Cases beschrieben, ist das Anforderungsmanagement für den Projekterfolg ein wichtiger Faktor. Die am häufigsten genannten Gründe für das Scheitern eines Projekts sind:

  • Mangelnder Input von Benutzern
  • Unvollständige Anforderungen
  • Änderung von Anforderungen

Fehler in der Formulierung der Anforderungen sind gleichzeitig auch die, die am häufigsten auftreten und die die meisten Kosten verursachen.

Die richtige Beziehung zu den Stakeholdern kann bei der Lösung dieser Probleme helfen. Die Stakeholder sind die wichtigste Informationsquelle für die Definition von Anforderungen und für das Verständnis der Prioritäten von Anforderungen. Viele Stakeholder haben jedoch kein Bild davon, welche Kosten und Auswirkungen auf den Zeitplan ihre Anforderungen haben. Deshalb muss die Entwicklungsorganisation die Erwartungen der Stakeholder verwalten.

Eine Beziehung zu Stakeholdern aufzubauen, heißt Folgendes:

  • Sie müssen die Zuständigkeiten der Stakeholder definieren: Steht Personal vor Ort zur Verfügung, an das sich das Entwicklungsteam, möglicherweise zu bestimmten Zeiten wenden kann?
  • Sie müssen die Einsichtsmöglichkeiten der Stakeholder in die Projektarbeitsergebnisse definieren: Sollen alle Arbeitsergebnisse allgemein offen gelegt werden oder nur an geplanten Meilensteinen?

Rückverfolgbarkeitselemente identifizieren

Beschreiben Sie die Rückverfolgbarkeitselemente und definieren Sie, wie diese benannt, gekennzeichnet und nummeriert werden sollen. Informationen hierzu finden Sie in Anforderungstypen und Rückverfolgbarkeit.

Die wichtigsten Rückverfolgbarkeitselemente sind in Anforderungsmanagementplan entwickeln beschrieben.

Rückverfolgbarkeit angeben

Eine typische Rückverfolgbarkeit mit einer begrenzten Menge grundlegender Arbeitsergebnisse ist in Anforderungsmanagementplan entwickeln beschrieben.

Zusätzlich zu den Rückverfolgbarkeitsverbindungen müssen Sie die Kardinalität der Verbindungen angeben. Im Folgenden sind einige allgemeine Bedingungen beschrieben:

  • Jedes genehmigte Produktmerkmal muss mit einer oder mehreren ergänzenden Anforderungen und/oder einem oder mehreren Anwendungsfällen verbunden sein.
  • Jede ergänzende Anforderung und jeder Anwendungsfall muss mit einem oder mehreren Testfällen verbunden sein.

Eine ausführliche Beschreibung der Rückverfolgbarkeit finden Sie im White Paper Traceability Strategies for Managing Requirements With Use Case.

Beispielattribute

Im Folgenden sind einige Beispielattribute, zwischen denen Sie wählen können, sortiert nach den in Anforderungsmanagementplan entwickeln beschriebenen Anforderungstypen aufgeführt.

Bedarf eines Stakeholders

Quelle: Der Stakeholder, der die Anforderung eingereicht hat. (Dieses Attribut kann auch als Rückverfolgbarkeit zu einem Rückverfolgbarkeitselement "Stakeholder" implementiert werden.)

Beitrag: Zeigt den Beitrag des Problems zur Geschäftschance insgesamt bzw. zu dem Problem an, das vom Projekt adressiert wird. Prozentsatz (0 bis 100 %). Alle Beiträge dürfen in Summe nicht mehr als 100 % ergeben. Das folgende Pareto-Diagramm zeigt beispielsweise den Beitrag für jeden Bedarf eines Stakeholders.

Graph, der die relative Auswirkung von 5 Problemen auf die Gesamtgeschäftschance veranschaulicht

Features, ergänzende Anforderungen und Anwendungsfälle

Status: Zeigt an, ob die Anforderung von einer offiziellen Stelle geprüft und genehmigt wurde. Beispielwerte sind Vorgeschlagen, Zurückgewiesen, Genehmigt.

Es kann sich um einen Vertragsstatus oder einen Status handeln, der von einer Arbeitsgruppe definiert wurde, die bindende Entscheidungen treffen darf.

Vorteil: Die Bedeutung aus der Sicht der Stakeholder.

  • Kritisch (oder primär). Diese Anforderungen beziehen sich auf die Hauptaufgaben des Systems, seine grundlegende Funktion, die Funktionen, für die das System entwickelt wird. Wenn diese Anforderungen fehlen, kann das System seinen primären Auftrag nicht erfüllen. Sie treiben das Architekturdesign voran und werden in der Regel in Anwendungsfällen getestet.
  • Wichtig (oder sekundär). Diese Anforderungen beziehen sich auf die Unterstützung der Systemfunktionen, z. B. Kompilierung statistischer Daten, Berichtsgenerierung, Überwachung und Funktionstests. Wenn diese Anforderungen fehlen, kann das System trotzdem (für eine gewisse Zeit) seinen grundlegenden Auftrag erfüllen, wenn auch mit verminderter Servicequalität. In der Modellierung haben sie eine geringere Bedeutung als kritische Anwendungsfälle.
  • Hilfreich (wünschenswert). Dies sind "Komfort-Features", die sich nicht auf den primären Auftrag des Systems beziehen, aber nützlich für die Bedienung oder Marktpositionierung sind.

Aufwand: Geschätzter Aufwand in Tagen für die Implementierung der Anforderung.

Dies könnten Kategorien wie Niedrig, Mittel und Hoch sein, z. B. Niedrig = < 1 Tag, Mittel = 1-20 Tage, Hoch = >20 Tage.

Wenn der Aufwand definiert wird, muss klar angegeben werden, welche Zusatzaufwände (Management, Test, Anforderungen usw.) in die Schätzung einbezogen wurden.

Größe: Geschätzte Anzahl der Quellcodezeilen (SLOC, Source Lines of Code) ohne Kommentare, einschließlich Testcode.

Sie können zwischen neuen und wiederverwendeten SLOCs unterscheiden, um den Kostenvoranschlag besser berechnen zu können.

Risiko: Wahrscheinlichkeit in Prozent, dass bei der Implementierung der Anforderung massive, unerwünschte Ereignisse eintreten, z. B. Nichteinhaltung von Terminen, Kostenüberschreitung oder Projektabbruch.

Dies könnten Kategorien wie Niedrig, Mittel und Hoch sein, z. B. Niedrig = <10 %, Mittel = 10-50 %, Hoch = >50 %.

Eine weitere Option für Risiko ist die gesonderte Überwachung des Technologierisikos: Wahrscheinlichkeit in Prozent, dass bei der Implementierung der Anforderung aufgrund mangelnder Erfahrung in der Domäne und/oder den erforderlichen Technologien ernsthafte Schwierigkeiten auftreten. Anschließend kann das Gesamtrisiko als gewichtete Summe, basieren auf anderen Attributen wie beispielsweise Größe, Aufwand, Stabilität, Technologierisiko, Auswirkung auf die Architektur und Komplexität der Organisation berechnet werden.

Komplexität der Organisation: Kategorisierung der Kontrolle über die Organisation, die die Anforderung entwickelt.

  • Intern: Eigenentwicklung an einem Standort
  • Geografisch: Geographisch verteiltes Team
  • Extern: Externe Organisation innerhalb des Unternehmens  
  • Lieferant: Vergabe der Entwicklung oder Kauf extern entwickelter Software

Auswirkung auf die Architektur: Gibt an, welche Auswirkungen diese Anforderung auf die Softwarearchitektur hat.

  • Keine: Die vorhandene Architektur ist nicht betroffen.
  • Erweiterung: Die vorhandene Architektur muss erweitert werden.
  • Änderung: Die vorhandene Architektur muss geändert werden, um die Anforderung zu erfüllen.   

Stabilität: Wahrscheinlichkeit, dass die Anforderung sich ändert oder dass sich das Verständnis der Anforderung innerhalb des Entwicklungsteams ändert. (>50 % = Hoch, 10..50 % = Mittel, <10 % = Niedrig)

Ziel-Release: Das beabsichtigte Produkt-Release, in dem die Anforderung erfüllt wird. (Release1, Release1.1, Release2, ...)

Gefahrenstufe/Kritikalität: Die Möglichkeit, dass das System sich auf Gesundheit oder Wohlergehen auswirkt oder wirtschaftliche Konsequenzen hat, die darauf zurückzuführen sind, dass die Software nicht wie erforderlich funktioniert.

  • Vernachlässigbar: Das Risiko von Verletzungen des Personals oder Beschädigungen von Einrichtungen durch die Software ist im Prinzip nicht existent.
  • Marginal: Die Software kann kontrolliert werden, ohne dass Verletzungen von Personal oder größere Systembeschädigungen zu erwarten sind.
  • Kritisch: Die Software kann Verletzungen des Personals oder größere Systembeschädigungen bewirken oder erfordert eine sofortige Problembehebung, um das Überleben von Personal oder System zu gewährleisten.
  • Katastrophal: Die Software kann schwerwiegende, tödliche Verletzungen oder einen vollständigen Systemverlust bewirken.

Gefahren können auch als separate Anforderungstypen identifiziert und mit zugehörigen Anwendungsfällen verknüpft werden. Sie können auch die Gefahrenwahrscheinlichkeit, Problembehebung und/oder präventive Maßnahmen verfolgen.

Interpretation: In einigen Fällen, in denen die Anforderungen einen formalen Vertrag bilden, kann es schwierig und kostenintensiv sein, die Formulierung von Anforderungen zu ändern. Wenn die Entwicklungsorganisation ein besseres Verständnis für eine Anforderung entwickelt, kann es erforderlich sein, Interpretationstext anzufügen, anstatt einfach die offizielle Formulierung der Anforderung zu ändern.

Anwendungsfall

Es ist außerdem hilfreich, die folgenden Anwendungsfallattribute zu verfolgen:

Detaillierungsgrad in %: Der Grad, zu dem der Anwendungsfall ausgearbeitet wurde:

  • 10 %: Es steht eine Basisbeschreibung zur Verfügung.
  • 50 %: Die Hauptabläufe sind dokumentiert.
  • 80 %: Abgeschlossen, aber nicht geprüft. Alle Vorbedingungen und Nachbedingungen sind vollständig spezifiziert.
  • 100 %: Geprüft und genehmigt.

Testfall

Status: Verfolgt den Fortschritt während der Testentwicklung.

  • Keine Aktivität: Es wurden noch keine Arbeiten in Bezug auf die Entwicklung dieses Testfalls ausgeführt.
  • Manuell: Es wurde ein manuelles Script erstellt und als fähig befunden, die zugeordneten Anforderungen zu prüfen.
  • Automatisiert: Es wurde ein automatisiertes Script erstellt und als fähig befunden, die zugeordneten Anforderungen zu prüfen.

Allgemeine Attribute

Im Folgenden sind einige andere Anforderungsattribute aufgeführt, die allgemein gültig sind:

  • Geplante Iteration
  • Tatsächliche Iteration
  • Verantwortliche Partei

Attribute auswählen

Attribute werden verwendet, um (gewöhnlich für Status- und Berichtszwecke) Informationen zu verfolgen, die einem Rückverfolgbarkeitselement zugeordnet sind. Welche Verfolgungsinformationen bereitgestellt werden müssen, wird in den einzelnen Organisationen unter Umständen unterschiedlich gehandhabt. Vor der Zuordnung eines Attributs sollten Sie Folgendes berücksichtigen:

  • Wer stellt diese Informationen bereit?
  • Wer verwendet diese Informationen und warum sind sie hilfreich?
  • Rechnen sich die Kosten für die Verfolgung dieser Informationen?

Die wichtigen Attribute sind Risiko, Vorteil, Aufwand, Stabilität und Auswirkungen auf die Architektur. Auf Basis dieser Attribute können die Anforderungen für das Scope-Management nach Priorität sortiert werden und Iterationen zugeordnet werden. Die Attribute sollten zunächst in Leistungsmerkmalen und später in allen Anwendungsfällen und ergänzenden Anforderungen verfolgt werden.

Abgeleitete Informationen berücksichtigen

Zusätzlich zur direkten Verwendung von Anforderungsattributen können Sie durch Rückverfolgbarkeit zu anderen Anforderungstypen Informationen aus diesen Anforderungsattributen ableiten. Einige typische Muster für Ableitung sind:

  • Abwärtsableitung - Stellen Sie sich anhand der zuvor beschriebenen Rückverfolgbarkeit vor, dass ein Produktmerkmal ein Attribut "Ziel-Release" hat. Man könnte davon ableiten, dass jeder Anwendungsfallabschnitt, auf den dieses Produktmerkmal zurückverfolgt werden kann, vor bzw. zum angegebenen Ziel-Release auch verfügbar sein muss.
  • Aufwärtsableitung - Stellen Sie sich anhand der zuvor beschriebenen Rückverfolgbarkeit vor, dass ein Anwendungsfallabschnitt ein Attribut "Geschätzter Aufwand" hat. Die Kosten eines Produktmerkmals können geschätzt werden, indem der geschätzte Aufwand für die einzelnen Anwendungsfallabschnitte, auf die das Produktmerkmal zurückverfolgt werden kann, addiert werden. Gehen Sie hierbei mit Sorgfalt vor, da sich mehrere Produktmerkmale auf denselben Anwendungsfallabschnitt beziehen können.

Beachten Sie bei der Zuordnung von Anforderungsattributen zu Anforderungstypen Folgendes:

  • Welche abgeleiteten Informationen/Berichte möchten wir aus diesem Attribut generieren?
  • Auf welcher Ebene in der Rückverfolgbarkeitshierarchie sollen wir dieses Attribut verfolgen?

Abhängigkeit der Attribute

Einige Attribute sind möglicherweise nur auf einer bestimmten Entwicklungsebene anwendbar. Das Attribut "Geschätzter Aufwand" für einen Anwendungsfall kann beispielsweise durch Aufwandsschätzungen für die Designelemente ersetzt werden, sobald der Anwendungsfall vollständig im Design abgebildet ist.

Berichte und Messwerte

Im Folgenden werden einige Beispiele für anforderungsbezogene Berichte und Messwerte vorgestellt. Durch Auswahl der erforderlichen/gewünschten Berichte und Messwerte für Ihr Projekt können Sie die erforderlichen Attribute für den Anforderungsmanagementplan ableiten.

Beschreibung des Berichts/Messwerts Verwendet für
Entwicklungspriorität von Anwendungsfällen (Liste der Anwendungsfälle nach Risiko, Vorteilen, Aufwand, Stabilität und Auswirkungen auf die Architektur sortiert) Sie können separat sortierte Listen oder eine einzelne Liste verwenden, die nach einer gewichteten Kombination dieser Attribute sortiert ist. Diese Listen werden für die Aufgabe Anwendungsfälle nach Priorität sortieren verwendet.
Prozentsatz der Produktmerkmale in jeder Statuskategorie Dient der Fortschrittskontrolle bei der Definition der Referenzversion für das Projekt.
 - klassifiziert nach Ziel-Release  - verfolgt den Fortschritt auf Release-Basis
 - gewichtet nach Aufwand  - ermöglicht eine präzisere Messung des Fortschritts
Produktmerkmale nach Risiko sortiert  - identifiziert risikoreiche Produktmerkmale. Hilfreich für das Scope-Management und die Zuordnung von Produktmerkmalen zu Iterationen.
 - klassifiziert nach Ziel-Release mit Zusammenfassung der Entwicklungsrisiken für jedes Ziel-Release  - hilfreich für die Bewertung, ob risikoreiche Produktmerkmale früh oder spät im Projekt geplant wurden
Anwendungsfallabschnittet nach Stabilität sortiert  - wird verwendet, um zu entscheiden, welche Anwendungsfallabschnitte stabilisiert werden müssen
 - gewichtet oder sortiert nach Auswirkungen auf die Architektur  - hilfreich, um festzustellen, welche architektonisch relevanten und/oder mit hohem Aufwand behafteten Anwendungsfälle zuerst stabilisiert werden müssen.
Anforderungen mit nicht definierten Attributen Wenn Anforderungen vorgeschlagen werden, ordnen Sie gewöhnlich nicht alle Attribute unverzüglich zu (sondern verwenden z. B. den Standardwert "Nicht definiert"). Die Prüfliste für die Softwareanforderungsspezifikation verwendet diesen Bericht, um nach solchen nicht definierten Attributen zu suchen.
Rückverfolgbarkeitselemente mit unvollständigen Rückverfolgbarkeitsverbindungen Ein Bericht über ungültige oder unvollständige Rückverfolgbarkeitsverbindungen wird für die Prüfliste: Softwareanforderungsspezifikation verwendet.

Anforderungsänderungsmanagement Seitenanfang

Änderungen sind unvermeidlich und müssen eingeplant werden. Änderungen können aus folgenden Gründen auftreten:

  • Es gab eine Änderung bei dem zu lösenden Problem (z. b. aufgrund neuer Verordnungen, wirtschaftlichen Drucks, Technologieänderungen usw.).
  • Die Stakeholder haben ihre Meinung oder Auffassung in Bezug auf das, was das System leisten soll, geändert. Die Gründe hierfür können vielseitig sein, z. B. das verantwortliche Personal hat sich geändert, die Probleme werden besser verstanden usw.
  • Es wurden nicht alle Stakeholder berücksichtigt oder es wurden nicht die richtigen Fragen gestellt, als die ursprünglichen Anforderungen definiert wurden.

Wenden Sie für die Verwaltung von Anforderungsänderungen die folgenden Strategien an:

  • Erstellen Sie eine Referenzversion der Anforderungen.
  • Richten Sie einen zentralen Kanal für die Steuerung von Änderungen ein.
  • Verwalten Sie ein Änderungsprotokoll.

Referenzversion der Anforderungen erstellen Seitenanfang

Gegen Ende der Ausarbeitungsphase sollte der Systemanalytiker eine Referenzversion aller bekannten Anforderungen erstellen. Hierfür stellt er gewöhnlich sicher, dass alle Anforderungsarbeitsergebnisse unter Versionssteuerung stehen, und ermittelt die Arbeitsergebnisse und ihre Versionen, die Einzug in die Referenzversion erhalten.

Mit der Referenzversion wird nicht das Ziel verfolgt, die Anforderungen einzufrieren. Sie wird vielmehr dazu verwendet, um neue oder geänderte Anforderungen besser erkennen, kommunizieren, einschätzen und kontrollieren zu können.

Weitere Informationen hierzu finden Sie in Toolmentor: Referenzversion eines Rational-RequisitePro-Projekts erstellen.

Zentralen Kanal für die Steuerung der Änderungen einrichten

Bei einem Wunsch eines Stakeholders kann nicht davon ausgegangen werden, dass sich demzufolge Budget und Zeitplan offiziell ändern. Gewöhnlich muss ein Verhandlungs- oder Budgetabstimmungsprozess eingeleitet werden, bevor einer Änderung zugestimmt werden kann. Häufig müssen Änderungen gegeneinander abgewägt werden.

Es ist entscheidend, dass alle Änderungen über einen zentralen Kanal, das Change Control Board (CCB), gehen, damit die Auswirkungen der Änderungen auf das System bestimmt und offizielle Genehmigungsprozesse eingeleitet werden können. Für einen Änderungsvorschlag muss eine Änderungsanfrage eingereicht werden, die dann vom CCB geprüft wird.

Weitere Informationen hierzu finden Sie auf der Seite Aufgabe: Änderungsmanagementprozess einrichten.

Änderungsprotokoll verwalten

Es ist von Vorteil, ein Prüfprotokoll der Änderungen zu einzelnen Anforderungen zu verwalten. Mit diesem Änderungsprotokoll sind Sie in der Lage, alle vorherigen Änderungen an der Anforderung, Änderungen an den Attributwerten sowie die Begründung für die Änderung einzusehen. Dies kann bei der Bewertung der tatsächlichen Stabilität von Anforderungen und bei der Ermittlung von Fällen hilfreich sein, in denen der Änderungsmanagementprozess möglicherweise nicht funktioniert (z. B. es werden Anforderungsänderungen erkannt, die nicht ordnungsgemäß geprüft und genehmigt wurden).