Requirements Engineering and Cost Estimation - Anforderungen verwalten

Anforderungen verwalten

Eine weitere Kernaktivität des Requirements Engineering ist das Verwalten von Anforderungen. Dabei wird sichergestellt, dass Requirements so abgelegt sind, dass alle Stakeholder jederzeit das finden, was sie brauchen und Änderungen einpflegen können. Unter Requirements Management werden daher alle Maßnahmen verstanden, die helfen, Anforderungen während des Projekts nicht aus den Augen zu verlieren und gegebenenfalls anzupassen. Ein ‚nicht verwalten‘ ist unmöglich, sobald Anforderungen ermittelt und beschrieben sind. Die Herausforderung ist, ein durchdachtes, praktikables System dafür zu entwickeln und zu warten.

Eine Prämisse im Requirements Engineering ist, das Anforderungen sich ändern, weil, wie spätestens seit Heraklit bekannt ist, das Leben per se Veränderung bedeutet. Um ‚Unordnung’ in den Griff zu bekommen bzw. Chaos zu vermeiden, bieten sich Strukturen an. Diese sind das Gerüst jeder Verwaltung, wobei ausgereifte Strukturen stabilisieren, unzureichende ein Projekt gefährden. Im Idealfall hat alles in einem solchen System seinen Platz und kann damit jederzeit, rasch gefunden und angepasst werden. Damit das gewährleistet ist, sollte eine Struktur bewährt, belastbar und flexibel sein. Gliederungsstrukturen sollen einerseits Lücken sichtbar machen. So zeigen sich zum Beispiel bei einer frühzeitigen Erstellung eines ausgeklügelten Inhaltsverzeichnisses im Laufe des Befüllens, welche Teile noch fehlen und können eingefordert bzw. ergänzt werden. Andererseits soll eine Struktur Lücken erlauben, da sich selbst mit der besten Planung zu Beginn der Projektverlauf nicht völlig abschätzen lässt. Daher braucht es die Möglichkeit, Teile einzugliedern, ohne die gesamte Struktur über den Haufen zu werfen. Requirements Engineers können sich an Standardgliederungen bzw. den in Unternehmen üblichen Vorlagen und Strukturen orientieren.

Eine weitere Prämisse ist, dass Anforderungen weiterverwendet werden. Requirements werden nicht zum Selbstzweck generiert, sondern dienen der Entwicklung eines gewünschten Systems. Dabei lesen, bearbeiten, interpretieren usw. unterschiedlichen Personen Anforderungen und die Praxis zeigt, dass die Struktur von Spezifikationen oder deren Verwaltung nicht für alle Stakeholder gleich praktikabel ist. Die Verwaltungsstruktur ist daher etwas, das einer Abstimmung bzw. eines gewissen Knowhows und damit eventuell Schulung bedarf.

Eine dürftige Anforderungsverwaltung trübt das Bild des kompetenten Requirements Engineer und ist ein erhebliches Risiko für den Erfolg des Projekts. Wenn das Requirements Management gut funktioniert, sind zufriedene Kunden bzw. Stake­holder sowie eine geringere Projektlaufzeit und -kosten die Folge. Weiters simplifiziert es den Überblick und die Kontrolle von vielschichtigen Projekten in allen Phasen, bietet eine gute Kommunikationsgrundlage und schont die Nerven der Beteiligten.

Aufgaben des Requirements Management

Die Anforderungsverwaltung umfasst alle Maßnahmen, um Anforderungen zu strukturieren, für unterschiedliche Rollen aufzubereiten, konsistent zu ändern und umzusetzen. Nicht immer alle Aufgaben essentiell, sondern der Requirements Engineer ist gut geraten, abzuwägen, womit er wieviel Zeit verbringt.

• Austausch von Informationen: Wer gibt wann wem was?

Requirement Management fungiert als Single Point of Contact. Wobei damit nicht der einzelne Anforderungsmanager gemeint ist, schließlich soll das Projekt auch während dessen Krankheit weiterlaufen und die Ausfallsicherheit gewährleistet sein. Vielmehr geht es um eine zentrale Verwaltung, die allen Stakeholdern ermöglicht, zu jedem Zeitpunkt zu lesen und zu schreiben. Derartige Transparenz beschleunigt ein Projekt und minimiert das Auftreten von Mängeln.

• Steuerung von Abläufen: Wer darf wann was?

Selten ist es zielführend, wenn jederzeit alles von allen geändert werden kann. Zu gewissen Zeitpunkten ist es sinnvoll, Zugriffs- und vor allem Bearbeitungs­rechte zu beschränken und nur die aktuell relevanten Prozessschritte anzuzeigen. Das richtige Maß dabei zu finden und die Zustimmung aller Stakeholder dafür zu erreichen, ist in der Praxis durchaus ein Balanceakt.

• Verwaltung innerer Zusammenhänge: Was hängt wie mit was zusammen?

Die Komplexität von Relationen ist nie zu unterschätzen, dafür braucht es nicht einmal eine große Anzahl an Requirements. Wenn Verknüpfungen in der Dokumentation mit abgebildet sind, können bei Änderungen die dadurch betroffenen Anforderungen geprüft und gegebenenfalls ebenso adaptiert werden.

• Auswertung und Projektsteuerung: Wie läuft’s?

Dem Projektfortschritt bzw. den Ergebnissen gilt die berechtigte Nachfrage der Stakeholder. Vor allem Auftraggeber zeigen verständlicherweise daran ein großes Interesse. Requirement Management erlaubt ein Projektcontrolling, mit dem Meilensteine überwacht und eingehalten sowie Reports über den jeweiligen Status erstellt werden können. Profiteure sind davon gleicher­maßen der Requirements Engineer sowie die Stakeholder.

Attribute

Um für den Umgang und die Nachvollziehbarkeit bei großen Mengen von Anforderungen gerüstet zu sein, helfen zusätzliche Beschreibungsmerkmale, die als Attribute von Anforderungen ergänzt werden. Diese Metadaten dokumentieren alles, was man über die Anforderung wissen muss. Die Verwaltung erleichtern diese insofern, da diese Informationen nicht in unübersichtlicher Textform, sondern typischerweise separiert von den Inhalten der Anforderung dargestellt werden. Eine mögliche Herangehensweise ist über die tabellarische Struktur oder Schablone , in der die wichtigsten Metadaten zu Requirements abgefragt werden. Diese Attributtypen unterscheiden sich meist auch nach Anforderungsart, sind doch für funktionale Requirements die notwenigen Attribute anders als für Rahmen­bedingungen.

Attributierungsschema

Die Definition der Attributsstruktur, nämlich welche Attribute für eine Klasse von Anforderungen relevant sind, erfolgt idealerweise zu Beginn eines Projekts. In der Praxis hängt die Konkretisierung eines Attributierungsschema unter anderem stark von projektspezifischen Eigenschaften sowie den Rahmenbedingungen ab.

Folgende Aspekte sind daher bei der Festlegung einer Attributsstrukur zu beachten:

• Spezifische Merkmale des Projekts
• Vorgaben seitens des Unternehmens bzw. des Kunden
• Vorschriften des Anwendungsgebiets, z.B. Referenzmodelle, Modellierungs­vorschriften
• Randbedingungen und Restriktionen des Entwicklungsprozesses (z.B. Prozessstandards)

Attributierungsschemata sind für vergleichbare Projekte wiederverwertbar bzw. lassen sich daraus eventuell unternehmensweite Standards etablieren. Dementsprechend ist es sinnvoll, sich nach Vorlagen umzusehen sowie die eigene Struktur gewissenhaft zu gestalten. Neben Pflichtattributen gibt es auch optionale Attribute, wobei es wichtig ist, jeweils Aufwand-Nutzen-Überlegungen anzustellen, um ein angemessenes Ausmaß an Attributen zu finden.

Attributtypen

Attribute strukturieren die Beschreibung einer Anforderung auf einer Metaebene. Die zusätzlichen Informationen dienen zur einfacheren Verwaltung und bilden die Basis für verschiedene Sichten auf Anforderungen.

Wie Requirements generell können Attribute in unterschiedlichen Darstellungsformen auftreten, z.B. als Text oder Aufzählung. Entscheidend ist bei der Definition von Attributen, auch festzulegen, wer neue Attribute kreieren oder vorhandene löschen darf. Zielführend ist es außerdem, auf die allgemeine Verständlichkeit der Metadaten zu achten bzw. gegebenenfalls eine Legende dazu zu erstellen bzw. Abhängigkeiten der Attribute untereinander zu berücksichtigen.

Elektronische Tools zur Dokumentation und Verwaltung stellen meist vordefinierte Attribute zur Verfügung, vergeben zum Teil automatisch gewisse Attribute wie die ID und helfen durch eine Versionierung beim Nachvollziehen von Änderungen. Statt einer tabellarischen Struktur der Attribute greifen diese Werkzeuge meist auf eine modellbasierte zurück, in der meist auch Abhängigkeiten zwischen Attributtypen abgebildet und nachvollziehbar gemacht werden.

Typische Attribute von Anforderungen

• Identifikator (ID): eindeutiges Merkmal zur Wiedererkennung

• ‚sprechender‘ Name

• Kurzbeschreibung

• Version

• Autor

• Begründung, warum für das Zielsystem relevant

• Stabilität

• Kritikalität

• Priorität

• Quelle

• Zustand, z.B angelegt, analysiert, umgesetzt, getestet usw. Im agilen Kontext: planned, in progress, done

• Rechtliche Verbindlichkeit

• Release

Ansichten von Anforderungen

Nach dem Befüllen der Attribute mit Daten besteht die Möglichkeit, danach zu filtern und je nach Bedarf eine andere Ansicht zu generieren. Die Selektion ist bei komplexen Projekten mit vielen Anforderungen sowie Abhängigkeiten unverzichtbar. Je nach verwendetem Tool lassen sich mit ‚und-‚ bzw. ‚oder-Verknüpfungen‘ komplexe Suchabfragen starten. Damit steigt die Übersichtlichkeit der Spezifikation, vor allem da sich für einzelne Rollen in Projekten, z.B. Entwickler, Tester, Projektmanager usw., eigene Sichten erstellen lassen. Ein in der Praxis häufig genutzter Anwendungsfall entsteht, wenn ein Attribut vorhanden ist, das den Zustand von Requirements wiedergibt. So ist es für viele Stakeholder spannend, sich alle Anforderungen anzeigen zu lassen, die z.B. bereits ‚umgesetzt‘ bzw. im agilen Projektsetting ‚in progress‘ sind. Zu bedenken ist allerdings, dass ein Filtern nach Attributen, die nicht bei allen Anforderungen ausgefüllt sind, ein verzerrtes Bild liefert.

Neben der eben erwähnten selektiven Perspektive ist auch eine verdichtete Sicht möglich. Damit sind diejenigen gemeint, die eine Zusammenfassung von Daten anzeigen, die nicht direkt in der Anforderungsbasis enthalten sind. Das Tool generiert diese Informationen für die Ansicht und erstellt in der Praxis daraus häufig z.B. Balken- oder Kuchendiagramme. Ein möglicher Anwendungsfall ist eine Kulmination aller Anforderungen, um den Umsetzungsaufwand eines geplanten Release im Verhältnis zu den anderen aufzuzeigen. Diese Statistikfunktion ist üblicherweise ein Bestandteil moderner Requirement Management-Tools.

Verfolgbarkeit

Change Management erfordert, zu jedem Zeitpunkt zu wissen, wo sich Requirements oder andere projektrelevante Informationen im Prozess gerade befinden. Dementsprechend sollen Anforderungen über ihren gesamten Lebenszyklus im Projekt verfolgt werden können.

Voraussetzungen für Traceability

• Eindeutige Identifikation (ID) für jede Anforderung
• Klar definierte Ziele für die Nachvollziehbarkeit, um ein Ausufern der zu dokumentierenden Informationen zu verhindern
• Festlegen von Struktur und Inhalt der Verfolgbarkeitsdaten

Traceability ist das Fundament für ein funktionierendes Requirements Management. Laut IREB dient die Verfolgbarkeit von Anforderungen folgenden Zielen  :

• Nachweisbarkeit

Klarheit über die tatsächliche Umsetzung von Anforderungen, aber auch von Zielen usw. erlangen.

• Identifikation von unnötigen Merkmalen im System

Literatur spricht vom Ausfindigmachen von ‚Goldrandlösungen‘, also eigentlich nicht geforderten Funktionen.

• Identifikation von unnötigen Anforderungen

Anforderungen ohne Ziel herausfiltern, weil das Zurückgehen bis zur Quelle möglich ist.

• Auswirkungsanalyse

Relationen und Abhängigkeiten sind abgebildet, weshalb z.B. der Einfluss von Veränderung an Requirement A auf andere Anforderungen sichtbar wird.

• Wiederverwendung

Adaption von Anforderungen bzw. Artefakten (z.B. Komponenten, Testfälle usw.) für andere Projekte.

• Zurechenbarkeit

Realisierungsaufwand einer Anforderung bzw. einem Ziel zuordenbar.

• Wartung und Pflege

Bei Mängelbehebung zur Erforschung von Fehlerursachen bzw. zur Kalkulation des Korrekturaufwands.

Typen von Verfolgbarkeitsbeziehungen

Die Literatur nennt verschiedene Arten der Nachvollziehbarkeit von Requirements. Der IREB-Standard unterscheidet 3 Typen der Traceability  :

• Pre-RS (Requirements Specification) Traceability

Verbindung von Requirements zu Artefakten, die früher im Projektprozess zu verorten sind und diese daher geprägt haben, z.B. Ursprung oder Quelle.

• Post-RS Traceability

Im Gegensatz dazu Relationen von Anforderungen zu Artefakten, die ihren Platz später im Projekt haben, z.B. Komponenten, Implementierung oder Testfälle.

• Traceability zwischen Anforderungen

Beziehungen zwischen Anforderungen, z.B. Requirement B ist eine Weiter­führung von Requirement A und deshalb davon abhängig.

Arten der Verfolgbarkeit

Repräsentation der Verfolgbarkeit

Auch für die technische Umsetzung der Nachvollziehbarkeit bzw. das Sichtbar­machen vorhandener Verbindungen bestehen unterschiedliche Möglichkeiten:

• Textuelle Referenzen

Der Verweis auf das Zielartefakt befindet sich im Text der Ausgangs­anforderung. Eine eindeutige Identifikation des zu verknüpfenden Requirements ist dafür notwendig. Ebenso wird meist die Art der Relation benannt. Durch das Verborgensein textueller Referenzen im Dokument ist es allerdings nicht möglich, nach diesen zu filtern.

• Hyperlinks

In Verwaltungstools können häufig Hyperlinks gesetzt werden, um Requirements zu verbinden. Dabei werden meist zusätzliche Linkattribute wie Autor, Datum usw. mitgespeichert. Diese Verweise gehen allerdings fast immer verloren oder sind für Betrachter nicht sichtbar, wenn Informationen in ein anderes System überführt werden.

• Verfolgbarkeitsmatrizen

Weiters ist die Darstellung der Beziehungen von Anforderungen in einer Matrix möglich, in der Ausgangs- bzw. Zielartefakte abgebildet und über Einträge in der Tabelle verbunden werden. Diese Herangehensweise ist schwierig handhabbar und wartbar, wenn viele Anforderungen referenziert werden sollen.

• Verfolgbarkeitsgraphen

Die Repräsentation der Verfolgbarkeit erfolgt über ‚Knoten‘, die für die Anforderungen bzw. andere Artefakte stehen, sowie Linien, die die Verbindungen dazwischen darstellen. Je nach Attributtypen können unterschiedliche Symbole als Knoten bzw. Darstellungsweisen der Linien benutzt werden. In aktuellen Tools lässt sich meist die Darstellungstiefe definieren, damit danach selektiert werden kann. Diese Verfolgbarkeitsketten sind die Basis für Analysen der Abhängigkeiten im Changemanagement von Requirements.

Versionierung

Anforderungen sind ‚lebendig‘ und durchlaufen einen Lebenszyklus innerhalb eines Systems und damit verschiedene Zustände, von der Idee bis zur Inbetriebnahme.

Währenddessen werden sie verändert. Das betrifft nicht nur die einzelnen, sondern auch die Summe aller Requirements (Anforderungsbasis). Neue Anforderungen entstehen, vorhandene werden adaptiert oder überflüssig. Die Gründe dafür sind mannigfaltig, z.B. wächst das Knowhow der Stakeholder über das gewünschte System während eines Projekts und die Anforderungen ‚wachsen‘ oder ‚verblühen‘ mit.

Die Versionierung ermöglicht die Verfolgung der verschiedenen Änderungsschritte einzelner Requirements entlang ihres Lebenswegs. Damit nachvollziehbar bleibt, wer mit einer Anforderung was macht, ist es notwendig, diese Schritte zu dokumentieren. Eine Version zeichnet sich durch den zum jeweiligen Zeitpunkt signifikanten Inhalt aus und trägt eine eindeutige Versionsnummer. Versionierung bedeutet also ein systematisches Aufzeichnen der Historie von Anforderungen.

Anforderungsversionierung

Die Versionierung von Anforderungen wird – wie auch in der Grafik sichtbar – mittels Version und Inkrement dargestellt, z.B. Version 1.0. Das Inkrement wird um 1 erhöht, wenn es sich um eine kleine Änderung handelt. Bei einer großen Veränderung erfolgt eine Anhebung der Versionsnummer vor dem Punkt.

Anstelle der manuellen Wartung unterstützen viele Requirements Management-Tools die Versionierung automatisiert, in dem bei Änderungen diese inklusive einer aktualisierten Versionsnummer dokumentiert werden. Überarbeitete und damit eigentlich obsolet gewordene Version werden archiviert, bleiben bei professionellen Tools jedoch verknüpft. Im Falle von Unklarheiten kann so auf die vorhergehende Version ‚zurückgeblättert‘ werden.

Anforderungskonfiguration

Eine definierte Menge logisch zusammengehöriger Anforderungen wird in einer Anforderungskonfiguration summiert, wobei von jeder Anforderung jeweils nur eine Version darin enthalten sein darf.

Der IREB-Standard kennt folgende Eigenschaften von Anforderungs­konfigurationen  :

• Sachlogischer Zusammenhang der Anforderungen

• Konsistenz der Anforderungen innerhalb der Konfiguration

• Eindeutiger Indikator der Konfiguration

• Unveränderbarkeit der Anforderungen innerhalb der Konfiguration

• Grundlage für das Zurücksetzen auf frühere Versionen der Anforderungsbasis

Anforderungsbasislinien

Unter einer Anforderungsbasislinie, auch als Baseline bezeichnet, wird eine spezielle Auswahl an Konfigurationen verstanden, die stabile Versionen von Anforderungen enthalten. Zumindest für einen kurzen Augenblick wird der Stand der Spezifikationen fixiert, gleichsam ‚eingefroren‘. Dies sind oftmals auch die Auslieferungsstufen des Systems, sogenannte Systemreleases: „Testing a program is like walking on water, it only works if it’s frozen“ .

Nach jedem Frost taut es auch wieder und der Prozess beginnt wieder zu fließen. Nichtsdestotrotz ist es auch für die Weiterentwicklung des Zielsystems entscheidend, auf einer fundierten Basis weiter aufsetzen bzw. dieses zwischenzeitliche Fundament als Grundlage zur Planung von zukünftigen Releases verwenden zu können. Für und mit Stakeholdern erleichtert dieser kurzfristige ‚beständige‘ und ‚zuverlässige‘ Status die Kommunikation, da alle von einem Punkt ausgehen. Darüber hinaus lässt sich mit einer Anforderungsbasislinie der Realisierungsaufwand eines Release abschätzen sowie der Vergleich mit Konkurrenzprodukten herstellen.

Priorisierung

Jedes Entwicklungsprojekt befindet sich im Spannungsfeld zwischen den Bedürfnissen und Wünschen der Stakeholder auf der einen Seite sowie den Erfolgskriterien des entwickelnden Unternehmens, z.B. die vereinbarten Kosten, auf der anderen Seite. Die Praxis zeigt, dass die Liste der Anforderungen im Verhältnis zu den zur Verfügung stehenden Ressourcen immer zu lang ist, vor allem unter der Berücksichtigung der zu erwartenden Veränderungen sowie der immer ausbau­fähigen Prozessfähigkeit. Klassisch werden deshalb in Projekten Puffer eingeplant. Zudem unterstützen die Priorisierung von Anforderungen und eine inkrementelle Entwicklung den Projekterfolg. In agilen Kontext, z.B. Scrum, ist das Attribut Priorität grundlegend. Ein ‚Ranking‘ der Umsetzungsdringlichkeit der User Storys im Product Backlog ist die Voraussetzung des iterativen Entwicklungszyklus. Weitere typische Prioritäten sind der Wert für den Auftraggeber bzw. den Nutzer, der Beitrag zur Unternehmensstrategie, die Marktrelevanz, die Kosten-Nutzen-Kalkulation usw.

Vorgehensweise

An die Priorisierung von Anforderungen empfiehlt sich folgendermaßen heranzu­gehen:

1. Definition des Zieles (d.h. des Gegenstands) der Priorisierung
2. Dokumentation der Rahmenbedingungen wie der vorhandenen Ressourcen für die Priorisierung
3. Bestimmung der Priorisierungskriterien: Kosten, Risiko, Schaden bei Nichtumsetzung, Volatilität, Wichtigkeit, Zeitdauer
4. Verfügbarkeit der relevanten Stakeholder mit dem jeweils nötigen Expertenwissen
5. Auswahl der zu priorisierenden Artefakte

Dabei ist der möglichst gleiche Detaillierungsgrad zu beachten, da es sonst häufig zu mangelhafter Priorisierung kommt. Je höher das Abstraktionsniveau eines Requirements, desto höher ist üblicherweise die Priorisierung durch die Stakeholder.

6. Entscheidung für die passende Priorisierungstechnik

Priorisierungstechniken

Die Priorisierung von Anforderungen kann grundsätzlich durch zwei Arten von Techniken erfolgen, die sich vor allem durch den benötigten Aufwand bzw. das erforderliche Vorwissen der Durchführenden unterscheiden:

ad-hoc Techniken

• Ranking

Das Durchnummerieren der Requirements durch ausgewählte Stakeholder ist eine simple und dennoch schwierige Herangehensweise, wenn jede Nummer tatsächlich nur einmal vergeben werden darf. Die kleinste Nummer beschreibt meist die höchste Priorität. Vorteilhaft ist die klare, eindeutige Festlegung der Reihenfolge unter anderem für das Abarbeiten der Anforderungen in der Umsetzung.

• Top-Ten-Technik

Es wird eine definierte Anzahl x – häufig 10 – der bedeutsamsten Anforderungen für das gewählte Kriterium festgelegt und in eine Reihung gebracht.

• Ein-Kriteriumsklassifikation

Dabei erfolgt die Zuteilung von Requirements in drei Prioritätsklassen: Mandatory, Optional und Nice-to-have. Häufig dient diese Technik zur ersten Einschätzung der Wichtigkeit für den Projekterfolg bzw. bei der Kategorisierung einer großen Menge von Anforderungen. Eine abgewandelte Form ist die MoSCow-Methode, die in 4 Kategorien unterteilt: Muss (engl. Must), Soll (engl. Should), Kann (engl. Could), nicht umsetzen (engl. Won’t).

• Kano-Klassifikation

Wie bereits erwähnt wird hier zwischen Basismerkmalen, Leistungs­merkmalen und Begeisterungsmerkmalen unterschieden. Für eine Release­planung oder die Erstellung einer Roadmap ist diese Technik gut geeignet, weil sie auf die Marktwirksamkeit von Anforderungen eingeht.

analytische Techniken

• AHP (Analytical Hierarchy Processing)
• QFD (Quality Function Deployment)
• Wieger'sche Priorisierungsmatrix

In der Praxis kommen Priorisierungstechniken vor allem kombiniert vor. Zu beachten ist außerdem, dass Re-Priorisierung in den meisten Projekten regelmäßig und mehrfach durchgeführt werden muss. Priorisierungen verändern sich, oft sogar wöchentlich. Umso wichtiger ist, dass der Requirements Engineer die dafür notwendigen Techniken beherrscht und die Stakeholder dafür sensibilisiert. Nur so erhält er deren Bereitschaft, sich am Prozess der Re-Priorisierung zu beteiligen.

Changemanagement

Änderungen von Requirements ergeben sich aus unterschiedlichsten Gründen. Unvollständigkeiten und Mängeln erfordern Korrekturen, die Evolution des Projekts (z.B. Veränderungen von Wünschen der Stakeholder, Gesetzesänderungen, neue Technologien oder Produkte der Konkurrenz) bringt Neues mit sich oder das auf einem Anforderungsfehler basierende Fehlverhalten des Systems im Betrieb verlangt eine Adaptierung.

Grundsätzlich bedeuten Änderungen keinen Weltuntergang. Entstehen im Verlauf der Systementwicklung nur wenige Änderungswünsche, ist dies eventuell ein Hinweis auf ein geringes Interesse der Stakeholder an dem zu entwickelnden System. Zu viele Änderungen allerdings gefährden ein Projekt, weil die Abstimmung mit Stakeholdern sowie eine nachhaltige Entwicklung unmöglich werden. Änderungen verschlingen in der Praxis meist viele Ressourcen und haben deshalb einen schlechten Ruf, wie ein Kommentar aus dem Wall Street Journal veranschaulicht:

The software was late and far over budget; in fact, it almost didn’t make it out the door. And it bore little resemblance to their original plans… Most software-development stinks.

Ständige und umfangreiche Änderungen sind häufig auch ein Indiz für mangelhaftes Requirements Engineering bzw. unzureichende Prozessqualität. Ebenso gilt es sich vor kleinen, permanent auftretenden – quasi schleichenden – Änderungen in Projekten zu hüten, die konstante Planüberschreitungen zur Folge haben, wie Construx das beschreibt: „Our analysis found that the average requirements overrun on our projects is about 40%“ .

Professionelles Reqirements Management bedeutet, Änderungen strukturiert zu bearbeiten. Dazu gilt es, einen Prozess für Änderungen zu definieren, der beschreibt, ob, wie und wann Änderungen durchgeführt werden, und für alle zentral zugänglich ist. Ziel ist es, den störenden Impact auf den Entwicklungsprozess so minimal wie möglich zu halten. Dafür hat es sich bewährt, Änderungensanfragen zu dokumentieren und auf Kosten sowie Auswirkungen zu analysieren.

Change Control Board

Die Bearbeitung von Änderungswünschen geht meist über die Ressourcen und Kompetenzen eines Requirements Engineers hinaus, weshalb es sinnvoll ist ein Change Control Board (CCB) zu installieren. Es liegt in der Verantwortung des CCB, die Änderungsanträge für Anforderungen zu kanalisieren und dafür zu sorgen, dass Entscheidungen in einem systematischen Prozess getroffen, kommuniziert und dokumentiert werden.

Als verantwortliches Änderungsgremium sind die Aufgaben des Change Control Boards:

• Aufwandsbestimmung von Änderungsanträgen
• Beurteilung der Änderungen
• Definition von Anforderungsänderungen bzw. neuer Anforderungen
• Klassifikation von Änderungsanträgen
• Entscheidung über Annahme/Ablehnung eines Änderungsantrags
• Priorisierung der positiv beurteilten Änderungsanträge
• Zuordnung der angenommenen Änderungsanträge zu Änderungsprojekten

Die Leitung des CCB verantwortet ein Änderungsmanager, der vor allem kommunikative und dokumentative Tätigkeiten bewerkstelligt. Dabei geht es um die Vermittlung bei Konflikten, das Voranzutreiben von Freigaben zu Entscheidungen mit den Stakeholdern sowie das Sicherstellen, dass die dadurch entstehenden Informationen festgehalten werden.

Da in diesem Gremium umfassende Entscheidungen gefällt werden, sollten je nach Eigenschaften des geplanten Systems sowie Projektablaufs die passenden Stakeholder teilnehmen, z.B. Auftraggeber, Architekt, Entwickler, Tester, Kunden/Nutzer, Produkt- und/oder Projektmanager.

Änderungsantrag

Zwischen einem Änderungswunsch und der tatsächlich umgesetzten Veränderung liegt, neben vielen anderen Dingen, der Änderungsantrag, auch Ticket oder Incident genannt. Diese sind grob zu dokumentieren und zu sammeln, um strukturiert behandelt werden zu können. In der Praxis kommt es leider oft vor, dass Stakeholder Probleme ‚über den Zaun werfen‘, z.B. ‚XY funktioniert nicht‘. Es erfordert eventuell Geduld und Hartnäckigkeit des Requirement Engineers hier auf die Einhaltung von Prozessen zu pochen.

Hilfreich ist es außerdem, für Änderungsanträge eine Schablone zu erstellen bzw. essentielle Basisinformationen zu definieren. Wichtige Informationen eines derartigen Antrags sind ein Identifikator, der Titel, eine Beschreibung, die Begründung, warum die Änderung notwendig ist, das Datum, der Antragsteller für Rückfragen sowie die Priorität aus der Sicht des Antragstellers.

Im weiteren Bearbeitungsverlauf sollten noch zusätzliche Daten erfasst werden können, wie z.B. der Status der Auswirkungsanalyse bzw. der Entscheidung des CCB. Ebenso ist die Priorität der Prüfer oder die Information, in welchem System­release die Änderung implementiert werden soll, relevant. Vor allem wenn viele Stakeholder Tickets einmelden, ist der Einsatz eines Werkzeugs hilfreich.

Änderungsanträge können laut IREB-Standard folgendermaßen klassifiziert werden  :

• Korrektiv

Das bereits in Betrieb genommene System ist fehlerhaft und der Änderungsantrag erfolgt, weil der Mangel ursächlich in der Anforderung liegt.

• Adaptiv

Dabei handelt es sich um eine Änderung zur Anpassung des Systems, z.B. aufgrund einer Veränderung des Kontexts (neue Technologie).

• Ausnahme

Eine korrektive oder adaptive Änderung, die dringend und unausweichlich umzusetzen ist, nennt man Ausnahmeänderung oder auch Hotfix.

Je nach Klassifizierung ist eine andere Art der Bearbeitung sinnvoll. Ausnahme­änderungen sind meist zeitnah zu analysieren, zu bewerten und falls nötig zu implementieren. Adaptive Änderungen sind häufig nicht so zeitkritisch. Sie werden zuerst gesammelt und mit einem zukünftigen, regulären Release umgesetzt.

Metriken

Der Einsatz von Metriken erlaubt die Messung der Qualität von Requirements bzw. des Requirements Engineering Prozesses. Dies dient dazu, Probleme frühzeitig zu erkennen (u.a. auch weil messbare Anforderungen handlicher sind), Verbesserungs­potentiale auszuloten und den Projekterfolg zu sichern.

Eine Metrik bildet eine oder mehrere Eigenschaften durch einen Zahlenwert ab.

Anforderungen an Maße und Metriken:

• Einfachheit

Komplexität reduzieren, Informationen verdichten, wenig Interpretations­aufwand.

• Eignung

Eigenschaften adressatengerecht und inhaltlich geeignet abbilden.

• Stabilität

Unwichtige Änderungen haben keinen großen Effekt.

• Rechtzeitigkeit

Maß bilden, solange noch Einwirken möglich ist.

• Analysierbarkeit

Ermittelte Werte sind vergleichbar, weil möglichst objektiv.

• Reproduzierbarkeit

Ergebnis des Maßes hängt nicht vom Messenden ab und ist nicht manipulierbar.

Metriken kommen zur Qualitätskontrolle, dem Prüfen der Komplexität oder der Überwachung des Entwicklungsprozesses zu Einsatz. Sie dienen dem Schätzen und der Kontrolle von Aufwand, Kosten und Zeit, dem Nachkommen von Standards sowie dem frühzeitigen Identifizieren von Problemen.

Messen lassen sich die Qualität bzw. die Erfüllbarkeit sowie die Güte der Anforderungsmaße. Daraus ergibt sich, dass nicht alle Teile einer Spezifikation direkt messbar sind, z.B. Modelle, Bilder, Graphen.

Unterschieden wird zwischen Produktmetriken, die Produktmerkmale wie Umfang und Qualität der Requirements und der dazugehörigen Dokumente (z.B. Fehler in Anforderungen) messen, und Prozessmetriken, die Aufschluss über Qualität und Progress des Prozesses, z.B. Änderungsrate von Anforderungen, geben.

Metriken und Maße fungieren als Hilfsmittel, daher ist es entscheidend, nicht von messbaren Eigenschaften auf interessante Eigenschaften zu schließen. Auch ist es sinnvoll nur relevante Daten zu messen, da die Datensammlung sonst wenig zielführend ausufert.

Werkzeuge

In der Praxis kommen im Requirements Management unterstützende Werkzeuge zum Einsatz. Besonders große, komplexe Projekte wären anders kaum abzubilden oder zu verwalten. Tools bieten Unterstützung im täglichen Umgang mit Anforderungen und wenn gewünscht in allen Phasen des Lebenszyklus eines Requirements. Die Verwendung eines Werkzeugs ist allerdings kein Ersatz für die Auseinandersetzung mit der Disziplin Requirements Engineering, denn: „A fool with a tool remains a fool.“ Erst nach der Einführung von entsprechenden Vorgehensweisen und Techniken kann ein passendes Werkzeug ausgewählt werden: „When you throw technology at a business problem, it doesn’t always solve that problem“. Häufig vervielfachen sich eher die Ungereimtheiten, wenn unüberlegt Hilfsmittel eigesetzt werden.

Der Markt mit Angeboten von Requirements Engineering-Werkzeugen ist fast unüberschaubar. Weitere Informationen zu Tools, Kernfunktionen, Checklisten zur Auswahl sowie Hinweise zur Einführung finden sich in der Literatur.