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

  1. === 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.

Abb. 16: 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.

Datei:Media/image19.png

Abb. 17: 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

  1. === 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

   1. === 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.

Cost Estimation

In vielen Standardwerken zu Requirements Engineering spielen Schätzungen gar keine Rolle, was insofern überraschend ist, da zu den ersten Fragen an Projekt­verantwortliche immer jene nach zeitlichem Aufwand und Kosten gehören. Als einige der wenigen räumen Ebert und Bergsmann dem Thema jeweils einige Seiten ein . Nichtsdestotrotz macht das sichtbar, dass Schätzung immer noch in der allgemeinen Literatur vernachlässigt wird. Dies wiederum erklärt, warum nach wie vor zahlreiche Witze über die Dauer bzw. Kosten von Softwareprojekten kursieren bzw. der Alltag viel zu viele IT-Projekte mit sich bringt, deren geschätzter Aufwand wenig bis nichts mit der Realität zu tun hat. Sehr häufig muss ab der Projektmitte zusätzlicher Bedarf angemeldet werden, obwohl das Team bereits mit vollem Einsatz und bis in die Nachtstunden hinein werkt, um den versprochenen Termin halten zu können. Dabei sei hier das Zitat berücksichtigt, das u.a. Karl Valentin, Mark Twain, Winston Churchill oder Niels Bohr zugeschrieben wird: ‚Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen.‘

Spätestens in der Phase Anforderungen prüfen und abstimmen sind grobe Schätzungen des Projektaufwand gefordert, auch um die Auswirkungen der einzelnen Requirements zu bewerten.

Was ist Cost Estimation?

McConnell definiert Aufwandsschätzung im Umfeld der Softwareentwicklung wie folgt: „Eine Schätzung ist eine Vorhersage darüber, wie lange ein Projekt dauert und wie hoch dessen Kosten sind“ . Das heißt, es handelt sich um eine Kalkulation bzw. Evaluierung des geplanten Resultats eines messbaren Projektteils, bevor dieses bekannt ist. Das Ergebnis einer Schätzung ist also weder etwas Endgültiges noch Fixes. Die Qualität einer Schätzung steigt, wenn sie während eines Projekts zu unterschiedlichen Zeitpunkten immer wieder erhoben wird. Je später im Projekt eine Schätzung durchgeführt wird, desto höher sind der Wahrheitsgehalt und die Aussagekraft, da immer mehr Informationen vorhanden sind und Unsicherheiten überschaubarer werden. Die vorliegenden Informationen, auf denen eine Schätzung beruht, prägen diese enorm.

In der Praxis sind Aufwandsschätzungen für IT-Projekte ein heißes Thema und die Definition muss durch Einflüsse des Unternehmens oder durch unterschiedliche Stakeholder erweitert werden. So wünschen sich Vertriebsmitarbeiter meist für ihre Kunden ein ‚gutes‘ Angebot und Führungskräfte erwarten eine verbindliche Aussage oder einen aussagekräftigen Plan, mit dem das Ziel erreicht wird. Die Schätzung darf aber auch nicht zu niedrig ausfallen, um das Projekt nicht zum Verlust zu machen. Der Requirements Engineer soll all diesen Wünschen Genüge tun und betriebs­wirtschaftlich interessante, konkurrenzfähige Aufwände nennen. Häufig sichert er sich mit einem ‚Managementpuffer‘ ab, da es immer wieder üblich ist, wie am Basar um Kosten bzw. Ressourcen zu feilschen. Trotz aller Ungewissheiten, wie diffuse Spezifikationen, Stakeholder mit widersprüchlichen Vorstellungen, technische Risiken, Ressourcenknappheit usw., eine sinnvolle Prognose abzugeben, auf deren Basis u.a. ein verbindliches Angebot erstellt werden kann, ist die Kunst der Aufwands­schätzung. Andernfalls enden Projekte aber meist desaströs.

Spätestens nach dem Angebot sind Liefertermin und Projektbudget eines IT-Projekts meist fixiert und der Kunde kümmert sich wie beim Autokauf nicht darum, wie der Prozess der Softwareentwicklung genau abläuft. Ihn interessieren nur die wichtigsten Funktionen, die Qualität und die Anwenderfreundlichkeit des gewünschten Systems. Dies ergibt ein magisches Dreieck mit den Eckpunkten Budget, Termin und Kernfunktionalität. Innerhalb diesem muss die Softwareentwicklung mit allen ihren unbestimmten Parametern Platz finden. Variabel bleiben dabei die Detailfunktionen, die Organisation des Projektteams und der Umgang mit Risiken und Unvorher­gesehenem. Im Gegensatz zur Kundenperspektive gibt es aus Entwicklersicht in der Praxis nie genug Budget oder Zeit. Die Schätzung muss da Balance schaffen und sicherstellen, dass zwischen den Eckpunkten genug, aber auch nicht zu viel Raum für das Projekt ist. Sonst kollabiert es womöglich und lässt sich bestenfalls durch zusätzliche Ressourcen wie Zeit, Geld oder Personal bewältigen, wenn es nicht gänzlich scheitert.

Wenn die zeitlichen und/oder finanziellen Wünsche der Stakeholder von vornherein für bare Münze genommen werden, kommt es zu einer Verwechslung von Aufwands­schätzung und Zielsetzung. Das Streben nach diesem Ziel ist vergebens, es erzeugt nur jede Menge Druck und Unzufriedenheit und bleibt immer unerreichbar. Eine Schätzung, die auf ein bestimmtes Ergebnis hin getrimmt ist, ist wertlos. Vielmehr handelt es sich bei einer gewissenhaft durchgeführten Schätzung um den Versuch, eine möglichst hohe Genauigkeit zu erreichen, um eine solide Basis für die Projektplanung zu liefern. Im Idealfall sollte diese daher vor der Projektplanung oder den Zielen erstellt werden. Dadurch minimiert sich das Risiko, dass diese Einfluss auf die Schätzung nehmen.

Wie schon besprochen handelt es sich bei Schätzungen im Softwarekontext eher um ‚Kunst‘ als um Wissenschaft. Von letzterem ist in der Regel dann die Rede, wenn mit höherer Mathematik versucht wird, die Abweichung von Schätzungen von ± 10 % auf ± 5 % zu reduzieren. In der Praxis der Softwareentwicklung gilt es Abweichungen von 100 % und mehr zu vermeiden, weshalb diese kaum im Bereich der Wissenschaft von Schätzungen angesiedelt sind.

Schätzungen als Aussagen zur Wahrscheinlichkeit

Häufig sind in Projekten Feststellungen wie ‚Das Projekt dauert 6 Monate‘ zu hören. Die Praxis zeigt, dass diese selten tatsächlich eintreten bzw. ist es auch nicht wahrscheinlich, dass eine solche Prognose hält. Es stellt sich also die Frage nach der Wahrscheinlichkeit. Die getätigte Aussage fällt in die Kategorie der Einpunkt­schätzungen, da sie einen einzigen Punkt als Ergebnis offeriert. Zudem finden derartige Schätzungen meist einmalig statt und geben keine zusätzlichen Informationen über deren Hintergrund, Annahmen und Hypothesen. Sie suggerieren mit voller Überzeugung eine 100 % Wahrscheinlichkeit, die allerdings unrealistisch ist. Unbedingt ist daher zu hinterfragen, ob es sich um eine Schätzung oder ein Ziel handelt. Einpunktschätzungen eignen sich dementsprechend in der Praxis nicht, um ein Projekt zu planen oder Aussagen über dessen Aufwand zu tätigen.

Entwicklungsprojekte sind voller nichtplanbarer Unsicherheiten. Eine seriöse Schätzung kalkuliert diese mit ein und versieht ein Projektresultat daher mit der wertvollen Information der Wahrscheinlichkeit. Die Grafik zeigt, dass in der Realität die Wahrscheinlichkeitsverteilung nicht einer regelmäßigen Glockenkurve gleicht, sondern, dass sie durch Beschränkungen, wie effektiv ein Projekt umgesetzt werden kann, verzerrt wird.

Abb. 18: Reale Verteilung der Wahrscheinlichkeit von IT-Projekten

Die strichlierte Linie repräsentiert das Normalergebnis, auch Median genannt. An dieser Stelle ist die Wahrscheinlichkeit jeweils 50%, dass das Projekt besser bzw. schlechter funktioniert. Auf der linken Seite der Grafik ist die minimale Aufwands­grenze ersichtlich, da einzelne Schritte nur bis zu einer gewissen Untergrenze optimiert und dann unabhängig von den eingesetzten personellen Ressourcen nicht mehr effektiver abgearbeitet werden können. Eine Obergrenze für den Aufwand ist nicht vorhanden, weshalb die Kurve auf der rechten Seite unendlich weiterläuft. Dies bedeutet, dass das Projekt eventuell nie abgeschlossen wird, was aber der Definition eines Projekts widerspricht, da dies einen definierten Beginn und ein ebensolches Ende haben muss.

Eine weitere Darstellungsmöglichkeit der Wahrscheinlichkeitsverteilung illustriert die folgende Grafik. Sie gibt die Wahrscheinlichkeit an, dass ein Projekt an einem bestimmten oder früheren Zeitpunkt bzw. mit einem bestimmten oder geringeren Aufwand abgeschlossen werden kann.

Abb. 19: Wahrscheinlichkeit der Fertigstellung eines IT-Projekts zu einem bestimmten Zeitpunkt

Diese Grafik illustriert, dass eine Behauptung wie ‚Das Projekt dauert 6 Monate.‘ wenig aussagekräftig und damit überflüssig ist. Prognosen wie ‚Das Projekt kann zu 80 % in 6 Monaten abgeschlossen werden.‘ oder ‚Das Projekt dauert voraussichtlich zwischen 8 und 12 Monaten.‘ sind hingegen viel informativer und machen deutlich, dass immer noch keine 100 % Garantie für das tatsächliche Eintreten des Projekt­abschluss in diesem Zeitraum möglich ist.

Eine ‚gute‘ Aufwandsschätzung erfordert die Investition von ausreichend Zeit in die Analyse und Requirements sowie ein umfassendes Verständnis des zu schätzenden Sachverhalts. Es ist für Balance zu sorgen, denn zu wenig Aufmerksamkeit führt zu mehr Ungewissheit und hohem Risiko. Bei einer zu intensiven Analyse wird die Projektzeit für die Schätzung und nicht das Liefern des zu entwickelnden Systems verbraucht. So gesehen ist eine Schätzung dann hilfreich, wenn die Entscheidungs­träger dadurch ausreichend Informationen erhalten, um das Projekt erfolgreich zu steuern und die Ziele zu erreichen.

Aufwandsschätzungen erfolgen kontinuierlich über den gesamten Projektzeitraum, wobei sich ihre Zielsetzung sowie Genauigkeit je nach Phase verändern. Je weiter ein Projekt fortgeschritten ist, umso mehr Informationen und umso weniger Unsicher­heitsfaktoren sind vorhanden, weshalb die Annahmen, auf denen die Prognosen für die Zukunft basieren, immer präziser werden sollten. In der Startphase sind Schätzungen wichtig, um ein grobes Verständnis für das Projekt zu erhalten. Allerdings muss dabei berücksichtigt werden, dass diese noch eine große Schwankungsbreite aufweisen können. Im Projektverlauf gilt es die ermittelten Richtgrößen zu beobachten und anzupassen. Entscheidend ist darum, den Aufwand nicht nur bei der Initialisierung zu schätzen, sondern diese Aktivität für eine fundierte Planung regelmäßig zu wiederholen.

Einflüsse auf die Aufwandsschätzung

Zahlreiche Einflussfaktoren spielen in der Aufwandsschätzung von Softwareprojekten eine Rolle und beeinflussen die Qualität und Aussagekraft einer Schätzung sowohl positiv als auch negativ. Relevante Faktoren sind unter anderem:

• Größe des zu entwickelnden Systems bzw. Projektgröße

Je größer ein IT-Projekt ist, desto mehr Personen sind meist daran beteiligt und desto höher ist der damit verbundene Kommunikationsaufwand. Die Anzahl der Kommunikationspfade steigt exponentiell, so dass ein 10 Personenteam bereits 45 Kommunikationspfade, also 4,5-mal so viele wie bei einem Team aus 5 Personen aufweist. Allerdings ist der Kommunikations­aufwand auch von der Organisationsform der Projektteams und des durchführenden Unternehmens abhängig, da meist nicht jeder mit jedem kommuniziert und im Idealfall auch strukturierte Kommunikationswege vorhanden sind, was die negativen Folgen des Größennachteils lindert. Nichtsdestotrotz muss bei Großprojekten der höhere Aufwand einkalkuliert werden, was häufig verabsäumt wird.

• Art des zu entwickelnden Systems

Je nachdem was für eine Projektart im Fokus des Vorhabens steht, z.B. Neuentwicklung oder Instandhaltung, lässt sich der potentielle Aufwand kategorisieren. Ebenso verursacht die Erstellung lebenswichtiger Systeme tendenziell einen höheren Aufwand als das hundertste Unternehmens­verwaltungssystem. Wenn hohe Anforderungen im Bereich der Sicherheit gegeben sind, steigt der zu erwartende Aufwand ebenfalls an.

• Persönliche Faktoren

Dazu zählen neben anderen Aspekten die Erfahrung und Qualifikation der Beteiligten, die Personalfluktuation, das projektrelevante Knowhow, die Fähigkeit zur Zusammenarbeit im Team, die Mitarbeiterproduktivität sowie ihre nicht fassbare Motivation.

• Eingesetzte Technik

Bei den im Requirements Engineering eingesetzten Techniken bestehen, wie schon an verschiedenen Stellen erwähnt, große Unterschiede in der Komplexität und damit im Aufwand. Dies gilt ebenso für Design, Implementierung oder Testing.

• Qualität

Besonders im Bereich der Qualität können unterschiedliche Forderungen zu gänzlich divergierenden Schätzungen führen, vor allem auch bei nicht-funktionalen Anforderungen wie Zuverlässigkeit, Performanz usw.

• Prozessreife des Unternehmens

• Systemkomplexität

• Einsatz von Werkzeugen

  1. == Überschätzung versus Unterschätzung ==

Grundsätzlich entstehen Schätzfehler bei jeder Schätzung und sind auf folgende Ursachen zurückzuführen:

• Unklarheit über das zu schätzende Projekt oder Objekt
• Unklarheit über die Fähigkeit des Unternehmens, das Projekt zu bewältigen
• Chaos im Projekt, d.h. ständige unstrukturierte Veränderung
• Ungenauigkeit aufgrund des gewählten Schätzverfahrens

Aufwand kann entweder zu hoch oder zu niedrig bemessen sein, wobei in der Praxis meist die Unterschätzung schwerwiegendere Konsequenzen nach sich zieht. Bei einer Fehlschätzung mit zu geringem Ergebnis steigen die negativen Folgen exponentiell. Hingegen verhalten sie sich beim Überschätzen linear und unterliegen zudem der Einschränkung, dass nur die möglicherweise einzusparende Differenz als Verlust eingestuft werden kann. Unterschätzung führt neben den ohnehin bereits zu knapp bemessenen Ressourcen zu ungeplanten Aktivitäten und Mängeln, die die Prognose weiter steigen lassen. Diese Effekte können sich wechselseitig hoch­schaukeln und ein Projekt schlimmstenfalls zum ‚Kentern‘ bringen.

Dementsprechend kann die Überschätzung meistens als das ‚geringere Übel‘ bezeichnet werden, da die Konsequenzen weniger gravierend sind. Wenn allerdings in Unternehmen oder Projekten kontinuierlich unterschätzt wird, scheitern auch diese.

Überschätzung

Ein Klassiker der Überschätzung ist das sogenannte Scotty-Prinzip, benannt nach dem Chefingenieur von Star Trek. Dieser schlägt, um seinen Ruf als ‚Miracle Worker‘ zu bewahren, auf seine Schätzungen hohe Reserven auf, dass diese selbst unter widrigsten Umständen eingehalten werden können. Diese an Kunden kommunizierten ‚Fantasieschätzungen‘ erlauben jede Menge Verhandlungsspielraum und machen ihn zum Helden, weil das Projekt nahezu immer schneller bzw. günstiger fertiggestellt werden kann. Allerdings sollte man sich nicht erwischen lassen oder zumindest eine geistesgegenwärtige Reaktion a la Star Trek auf Lager haben.

Wenn der Aufwand eines IT-Projekts überschätzt wird, besteht das Risiko, dass Zeit und Geld verschwendet werden. Studien zeigen, dass vorhandene Ressourcen immer aufgebraucht werden, unabhängig davon, ob es möglich gewesen wäre, die Aktivitäten auch mit weniger Zeit oder Kosten zu realisieren. „Work expands so as to fill the time available for its completion.” Dies nennt sich Parkinsonsches Gesetz und ist einer der wichtigsten Gründe, warum Projekte äußerst selten vor dem geplanten Zeitpunkt abgeschlossen werden. Zu entwickelnde Systeme werden also durch Überschätzen teurer, als sie eigentlich sein müssten. Zudem führt das Überschätzen der Kosten in der Regel zu einem im Vergleich zur Konkurrenz höheren Angebot, weshalb der Kunde das zu gewünschte System wahrscheinlich beim Mitbewerber bestellt. Sich zu sehr absichern wollen bzw. zu hohe Prognosen schaden somit der eigenen Auftragslage.

Unterschätzung

Aufgrund unzähliger Ursachen werden Projekte unterschätzt, einige Beispiele sind:

• Um dem Parkinsonschen Gesetz zu entgehen, steigern Kunden oder Ent­scheidungsträger den Druck im Projekt und fordern mehr Leistung von den Projektbeteiligten.
• Mit Vorsatz werden im Projektplan zu frühe Meilensteine eingerichtet, die den Eindruck von Dringlichkeit und Wichtigkeit erzeugen sollen.
• In der Praxis kommt Unterschätzung sehr häufig als Konsequenz von individuellen Expertenschätzungen auf der Basis ‚informeller Analogien‘ vor. Damit ist gemeint, dass die Prognose lediglich auf dem Vergleich mit der persönlich erinnerten Vergangenheit beruht. Üblich ist auch der Einsatz von Intuition und Raten, die beide eine Tendenz zu zu niedrigen Schätzungen aufweisen. Es halten sich in menschlichen Köpfen hartnäckig Vorstellungen wie ‚Diesmal sind wir sicher schneller.‘ oder ‚Da wissen wir, was auf uns zukommt‘.

Eine Konsequenz des Unterschätzens ist die verminderte Effektivität von Projekt­plänen, die so meist zu falschen Entscheidungen führen sowie den gewünschten Prozess des Projekts stören, wenn zwischen einzelnen Arbeitsschritten Wartezeiten entstehen. In zu gering geschätzten Projekten herrscht zudem häufig ein höherer Druck und es steigt die Fehleranfälligkeit, was statistisch die Wahrscheinlichkeit reduziert, dass das Projekt zeitgerecht abgeschlossen wird. Entscheidungsträger reagieren in solchen Situationen meist wenig hilfreich, in dem sie kurz vor Projektabschluss noch zusätzliche personelle Ressourcen hinzufügen. In einem bereits verspäteten Projekt verschlimmert eine Vergrößerung des Teams die Lage und führt zu weiteren Verzögerungen. Dieses Phänomen wird als Brooks‘ Law bezeichnet. Eine weitere Folge von Unterschätzung ist, dass die aufgrund der zu knapp bemessenen Ressourcen ungenügende technische Vorbereitung zu schlechten Resultaten führt. In späteren Phasen müssen dann Anforderungen bzw. bereits entwickelte Komponenten überarbeitet werden, was die Aufwände zusätzlich erhöht. In verzögerten Projekten herrscht meist aufgrund des Drucks eine unangenehme Atmosphäre und diese schädliche Dynamik verschlechtert einerseits die Produktivität bzw. erzeugt zusätzliche Diskussionen und Aktivitäten.

Schätzverfahren

„Der Prozess heißt Schätzung nicht Exaktifizierung“ , aber auch nicht Raten. Auf der Basis von Fakten und fundierten Informationen stehen zahlreiche gängige Schätzverfahren für eine seriöse Schätzung zur Verfügung. Der Unterschied besteht in erster Linie in der Art der Quelldaten sowie der Form der Generierung der Zieldaten. Die Techniken lassen sich in folgende Kategorien gliedern:

Top-Down

Bei der sogenannten Daumen * Pi-Schätzung überlegt sich der Schätzer grob die wichtigsten Schritte des zu erstellenden Projekts bzw. seiner Teile, wie Analyse, Design, Codierung und Test. Ohne die innere Struktur der Funktionalitäten zu kennen, trifft er aufgrund von Erfahrung und Intuition Annahmen für das zu entwickelnde System, einzelne Funktionen oder den jeweiligen Entwicklungsschritt. Die Festlegung von Größenordnungen ohne entsprechende Erfahrungswerte ist meist gänzlich aus der Luft gegriffen. Da sich diese Form der Expertenschätzung meist am einfachsten organisieren lässt, ist dieser Ansatz sehr verbreitet. Ebenso kommt die Top-Down-Methode zum Überprüfen von Resultaten anderer Vorgehensweisen zum Einsatz und unterstützt durch die Vogelperspektive, den Blick für das Ganze zu bewahren.

Analogieverfahren ziehen Zahlen von vergleichbaren IT-Vorhaben bzw. Komponenten der Vergangenheit heran, um Schätzungen für aktuelle Sachverhalte abzuleiten. Auf diese Weise kann in einem stabilen Umfeld häufig mit relativ geringem Aufwand eine stimmige Größenordnung erhoben werden. Alternativ ist die Ablage und Pflege der Schätzinformationen in einer Erfahrungsdatenbank möglich, wobei dieser Zugang mit wesentlich größerem Aufwand verbunden ist und meist die Ressourcen von kleinen und mittelständischen Unternehmen sprengt. Gleichzeitig kann eine solche Sammlung von Daten als Dokumentation für die Schätzungen des aktuellen Projekts dienen. Sollten keine direkt vergleichbaren Projekte oder Aktivitäten zur Verfügung stehen, können Teilaspekte im Prozess, in den Inhalten der Aufgabenstellungen oder in ähnlich gelagerten Projekten am Markt herangezogen werden. Zu berücksichtigen ist dabei, dass die entsprechenden Grundlagendaten für eine Schätzung vorliegen bzw. die wesentlichen Unterscheidungsmerkmale ebenso einbezogen werden müssen. Vergangene Werte sollten niemals blind 1:1 übernommen werden. Analogieschätzungen können bereits ermittelte Aussagen zu Aufwänden untermauern, weshalb sie für den Gegencheck der Ergebnisse anderer Techniken geeignet sind.

Bottom-Up

Im Vergleich zum Top-down-Zugang ist das Bottom-up-Verfahren wesentlich aufwendiger, bei gewissenhafter Durchführung aber auch um einiges präziser. Auf der Grundlage der jeweiligen Anforderungen bzw. der Detailplanung des Projekts werden alle Einzelteile bewertet. Für jeden Arbeitsschritt ist festzuhalten, wie hoch der Aufwand für dessen Erledigung ist bzw. wann welche Ressourcen dafür zur Verfügung stehen. Im besten Fall werden dabei schon Einschränkungen, in Bezug auf Personal z.B. Feiertage, Ferien, Krankenstände, einbezogen. Bei größeren Projekten erfordert ein solcher Detaillierungsgrad die Unterstützung durch ein Tool bzw. muss gut abgewogen werden, wann sich dieser Ansatz überhaupt rechnet. Da auch die Verantwortlichen für die einzelnen Arbeitsschritte in das Schätzverfahren eingebunden sind, erweist es sich als umfangreich und zeitintensiv. Um im möglichen Verhandlungspoker sicher zu sein, planen viele Experten zudem Reserven ein, weshalb der Umgang mit Puffern vorher geklärt sein muss bzw. die jeweiligen Schätzungen zu hinterfragen sind. Statistisch gesehen gleichen sich die üblichen Abweichungen der einzelnen Aufwandsschätzungen aus und liefern so ein brauchbares Ergebnis. Trotz der Bandbreite und Subjektivität sind Bottom-Up-Techniken substanziell, weil die Prognose auf fachlicher Diskussion und Präzisierung der einzelnen Anforderungen und/oder Arbeitsschritte beruht.

Mit dem Delphi-Verfahren wird eine systematische, mehrstufige Befragungstechnik mit Rückkopplung bezeichnet. Es handelt sich dabei um eine Expertenbefragung, in der mehrere Wissensträger auf der Grundlage der geplanten Arbeitsschritte oder Systemteile gemeinsam schätzen. Die erste Prognose wird ohne Diskussion verdeckt abgegeben, um unterschiedliche Sichtweisen zu erhalten und dadurch die Qualität des Resultats zu erhöhen. Nach der Zusammenfassung und Auswertung der Ergebnisse werden diese bei großen Unterschieden bzw. einzelnen Ausreißern diskutiert. Im besten Fall führt dies zu bisher unbedachten, eventuell sogar weniger aufwändigen Varianten. Nach dem Austausch kommt es zu einer erneuten Expertenbewertung. Es folgt eine Wiederholung dieses Ablaufs, in der Praxis selten mehr als zwei bis drei Runden, bis ein Konsens erreicht ist. Die Genauigkeit dieser Schätzungen ist erheblich höher als bei individuellen Prognosen, wenn die richtigen Personen einbezogen sind, und es können zudem alternative Lösungsansätze entstehen. Der Aufwand für dieses Verfahren multipliziert sich aufgrund der höheren Anzahl an Personen ebenso.

Die Drei-Punkt-Schätzung, auch PERT (Program Evaluation and Review Technique) genannt, berücksichtigt neben dem realistisch prognostizierten Aufwand für einen Arbeitsschritt eine optimistische (Best Case) und pessimistische Kennzahl (Worst Case). Nach deren Ermittlung werden sie gewichtet mit Hilfe von Funktionen der Wahrscheinlichkeitsrechnung miteinander in Relation gesetzt. Mit einer 50%igen Wahrscheinlichkeit liegt die kalkulierte Zahl, der sogenannte Erwartungswert, unter bzw. über dem zu erwartenden Aufwand. Der mathematische Zugang erhöht die Treffergenauigkeit der Prognose und erlaubt in der Kommunikation der Stakeholder das Beleuchten der Ungewissheiten und Aufwandstreiber.

Das vor allem in der agilen Herangehensweise beliebte Planning Poker ist ein effektives Verfahren zur relativen Aufwandsschätzung von User Storys in Teams. Die Komplexität einzelner Backlog-Items wird mithilfe einer vereinbarten Referenzgröße relativ zueinander in Bezug gesetzt. Das Fachwissen der einzelnen, im Idealfall möglichst heterogenen Personen wird verwendet, um einen Sachverhalt aus verschiedenen Blickwinkeln, Hintergründen und im Mehr-Augen-Prinzip zu bewerten. Es handelt sich um eine Expertenschätzung mit Konsensbildung unter den Teilnehmenden, d.h., Zweifel müssen dementsprechend ausgeräumt werden. Vorteile dieses Verfahrens sind das einfache Setup, das auch in verteilten Teams (z.B.: via Videokonferenz) eingesetzt werden kann, die Stärkung der Identifikation der Teilnehmenden mit den Requirements sowie die verschiedenen Perspektiven, die in der Schätzung berücksichtigt werden. Da die Schätzungsergebnisse abstrakte Einheiten sind, müssen sie für die Verwendung in der Kosten-, Zeit- und Risikoplanung umgerechnet werden. Diese Methode ist auch nur für die ideale Teamgröße, zwischen fünf und neun Personen, sinnvoll verwendbar. Zudem kann die Schätzung ohne ein entsprechendes fachliches Knowhow der Teammitglieder spekulativ werden.

Algorithmische Modelle

Mit Unterstützung von mathematischen Formeln kalkulieren algorithmische Techniken die Aufwände, in dem sie Relationen zwischen allen relevanten Einflussparametern erstellen. Die bekannteste Methode ist das COCOMO (COnstructive COst MOdel), das unter anderem verschiedene Softwaremetriken, z.B. der Anteil des wieder verwendbaren Programmcodes, bzw. die Erfahrung der beteiligten Personen einbezieht. Je nach Unternehmen können spezifische Faktoren in die zentrale Projektdatenbank aufgenommen und angepasst werden, damit sie in die Aufwandsschätzung einfließen. Aufgrund der vielen berücksichtigten Parameter sind sehr genaue Schätzungen möglich, allerdings hängt das Resultat wie bei allen Herangehensweisen von den eingegebenen Daten und der vorgenommenen Gewichtung ab. Das Vorhandensein vieler Stellschrauben erhöht durchaus die Komplexität und macht das Erreichen eines Ergebnisses nicht notwendigerweise einfacher. Dementsprechend erfordert das COCOMO mehr Aufwand in der Verwendung und eignet sich eher für große Projekte.

Mischformen

Das Function Point-Verfahren kombiniert die algorithmische Herangehensweise und die Analogieschätzung. Zuerst wird die Komplexität des zu entwickelnden Systems bzw. seiner Teile ermittelt, wobei Anforderungen und Arbeitsschritte in kleinste, aus der Anwenderperspektive sinnvolle Teile, die sogenannten Elementarprozesse, zerlegt und auf Grundlage vergleichbarer Elemente bzw. Komponenten bewertet werden. Dafür müssen wie bei allen Bottom-up-Techniken die Funktionalitäten des Systems bereits ausreichend bekannt sein. Das Ergebnis sind Function Points, eine abstrakte Messgröße. Um diese in Projektplänen einzusetzen, ist eine Umrechnung in betriebswirtschaftliche Kennzahlen notwendig.

Die Schätzung mit Story-Points erfreut sich aufgrund der Ausbreitung agiler Kontexte in den letzten Jahren immer größerer Beliebtheit. Dabei wird in Teams die Komplexität einzelner Anforderungen im Verhältnis zueinander bewertet. Da die dabei entstehende Messgröße eine ausschließlich teaminterne und dementsprechend nicht neutrale ist, lassen sich die Werte von verschiedenen Teams nicht miteinander vergleichen. Innerhalb eines eingespielten Teams können die Beteiligten Story Points meist recht treffend schätzen, für Außenstehende ist der jeweilige Basiswert sowie das Knowhow und die Erfahrungen des Teams, die zum Ergebnis führen, häufig nicht nachvollziehbar. Die Umrechnung in für Projektpläne verwertbare Kenngrößen gestaltet sich schwierig. Es empfiehlt sich für die Veranschaulichung des Projektfortschritts mit Burn-Down-Charts zu arbeiten.

Je nachdem wie Schätzverfahren eingesetzt werden, liefern sie gute oder schlechte Ergebnisse. Entscheidend ist als Requirements Engineer, die individuell passenden Verfahren zu nutzen, die im Idealfall auch im Unternehmen anerkannt und erprobt sind. Für ein qualitativ hochwertiges Resultat empfiehlt es sich, verschiedene Techniken miteinander zu kombinieren. Das unterstützt auch bei der Überzeugung von Stakeholdern, da eine Argumentation aus mehreren Perspektiven eher akzeptiert wird. Wichtig ist es, das Schätzverfahren an die Größe des ausführenden Unternehmens bzw. des jeweiligen Projekts anzupassen, um nicht unnötig Zeit und Ressourcen mit zu aufwendigen Techniken zu vergeuden oder eine der Komplexität des Projekts nicht angemessene Herangehensweise zu wählen. Mit einem systematischen Zugang und konsequentem Verhalten gelingt es, Licht in die Ungewissheit der Zukunft zu bringen und das Projekt zum Erfolg zu steuern. Regelmäßige Aufwandsschätzungen schaffen nicht nur beim Eintreten von Veränderungen ein aussichtsreiches, gut planbares Projekt.

Conclusio

Die Herausforderung ist, all die Praktiken des Requirements Engineering erfolgreich in die Praxis umzusetzen. Der Projektalltag erweist sich häufig als tückisch, vor allem wenn der hohe Druck oder Konflikte scheinbar keinen Raum für etwas anderes lassen, und die hilfreichen Techniken verstauben im Schrank. Manche Menschen motiviert das Argument, dass nach der Integration eines durchdachten Requirements Engineerings das sprichwörtliche Gras grüner sein wird. Andere brauchen den ‚Flächenbrand‘, um alternative Herangehensweisen einzubeziehen.

Abb. 20: Projektzustand?!

Der erste Schritt für Prozessveränderungen ist die Beobachtung, um den Ist-Stand zu ermitteln. Wenn Sie wissen, wo es in Ihrem Requirements Engineering bzw. Projekt brennt, sind Sie fast schon auf halbem Weg. So weitermachen wie bisher, weil es eben noch niemandem aufgefallen ist, dass etwas schief läuft, sollte dann keine Option mehr sein. Ein lernwilliges Unternehmen hat ein Interesse daran, dass die Ursachen für Schwierigkeiten erkannt und ausgemerzt werden, um nicht wieder und wieder dieselben Probleme zu reproduzieren.

Wenn Sie in Ihrem Unternehme die Requirements Engineering-Techniken verfeinern wollen, stoßen Sie wahrscheinlich auf Widerstände und Hindernisse. Stakeholder werden zuerst nicht unbedingt erfreut sein, mehr Aufwand in die Vorbereitung eines Projekts zu stecken, wenn es vermeintlich schon ‚losgehen‘ könnte. Nicht umsonst ist aber eine der wichtigsten Qualifikationen des Requirements Engineers Beständigkeit, die auch beim Implementieren von derartigen Prozessen immer wieder gefordert sein wird. Schrittweise neue Vorgehensweisen zu integrieren, ohne die herkömmlichen Methoden gänzlich zu verwerfen, kann hilfreich sein, um Stakeholder zu beruhigen sowie die Verbesserungen des Prozesses zu überprüfen.

Grundsätzlich wollen alle Beteiligten Verzögerungen oder gar das Scheitern eines Projekts verhindern, weshalb es durchaus sinnvoll ist, sich vergangene Projekte näher anzusehen und Potentiale im Requirements Engineering aufzuzeigen. Die Mehrkosten oder Zeitüberschreitungen von schlechtem Anforderungsmanagement sprechen meist eine Sprache für sich.

Abb. 21: Die Krux mit Kunden und ihren Wünschen