Der Anforderungsmanagementplan enthält Informationen, die mehr oder weniger auch von anderen Plänen abgedeckt werden.
Anleitung zur Anpassung finden Sie in Anforderungsmanagementplan anpassen.
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?
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.
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.
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.
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 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.
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.
|
Ä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
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).
|