Requirements Engineering and Cost Estimation - Ziele

Anforderungen ermitteln

Die Basis des Requirements Engineering ist zu wissen, was überhaupt ‚erwartet‘ bzw. ‚gewünscht‘ ist. Chris Rupp spricht vom „Hellsehen für Fortgeschrittene“ und beschreibt den Umgang mit Anforderungen in Anlehnung an das bekannte Zitat von Mark Twain „Wer nicht weiß, was er will, darf sich nicht über das wundern, was er bekommt“ . Das Ermitteln von Requirements hat daher häufig weniger mit Sammeln zu tun, als mit danach ‚graben‘. Ein guter Requirements Engineer macht es den Stakeholdern schmackhaft, ihre Informationen und ihr Wissen herauszugeben und entlockt ihnen ihre Wünsche und Bedürfnisse. Anforderungen werden, wie gesagt, in den seltensten Fällen am Silbertablett serviert, noch weniger als strukturierte Forderungen, die auf das Knowhow über das zukünftige System und dessen Umfeld aufbauen.

Das Ziel dieser Phase ist es also, mit möglichst geringem Aufwand und angepasst an die Projektrahmenbedingungen und Ziele Requirements zu erfassen, um ein System zu entwickeln, das für die Stakeholder möglichst gewinnbringend ist. Dabei gilt es, einen effizienten Weg zwischen Risikominimierung und Kostenexplosion zu finden. Meistens gelingt dies, wenn die Stakeholder ‚verzaubert‘ und für eine möglichst reibungslose Kooperation mit professionellen Mitteln ins Boot geholt werden. Das Projekt und damit der Requirements Engineer sind auf das Wissen der Beteiligten angewiesen.

Am Anfang eines Projekts sind sich Stakeholder aber oft nicht klar, was sie sich genau von einem neuen System erwarten.

The most difficult part of requirements gathering is not the act of recording what the users want; it is the exploratory, development activity of helping users figure out what they want.

Im besten Fall kennen die Projektbeteiligten die bestehenden Geschäftsprozesse und, wenn vorhanden, das aktuelle System und können somit die Ist-Situation beschreiben. Die Herausforderung ist allerdings, die Soll-Situation herauszufinden, die die existierende Situation verbessert. Beim Bewusst- und Sichtbarmachen von Bedürfnissen und Wünschen unterstützt der Requirements Engineer als Moderator, um die zur Verfügung stehende Zeit optimal zu nutzen und so viel Wissen wie möglich und damit Anforderungen herauszufiltern. Dabei ist es essentiell, zum ‚richtigen‘ Zeitpunkt die ‚richtigen‘ Fragen zu stellen und aktiv zuzuhören. Welche Techniken und Herangehensweisen die geeignetsten sind, ist vom Projekt, den Rahmen­bedingungen, den einzelnen Stakeholdern und natürlich vom zuständigen Requirements Engineer abhängig. Grundlegende Vertrautheit mit Kommunikations­theorie sowie gängigen Coachingtechniken helfen die individuellen Situationen zu meistern.

Ein Requirements Engineer entwickelt mit seinen Fragestellungen und seiner Bereitschaft zuzuhören das Produkt entscheidend mit. Dementsprechend sind die kompetentesten Personen dieser Disziplin diejenigen, denen es gelingt, eine Brücke zwischen den soziologischen (menschliche Wesen und ihre Umwelten) sowie technischen Aspekten (präzise Spezifikationen) eines Projekts zu schlagen. Innovation entsteht dort, wo über die artikulierten Wünsche der Stakeholder hinaus entwickelt wird.

Weitere Herausforderungen, die das Zusammentragen von Requirements erschweren, sind der Umfang eines gewünschten Systems, die dafür nötigen Vereinbarung und die Unbeständigkeit der Anforderungen. Eine strukturierte Herangehensweise an die Ermittlung von Requirements hilft dem Requirements Engineer diese Schwierigkeiten zu bewältigen.

Anforderungsquellen

Für die Generierung von Anforderung kann auf verschiedene Quellen zurückgegriffen werden:

• Stakeholder

Personen oder Organisationen, die (in)direkten Einfluss auf Requirements haben, werden als Stakeholder bezeichnet, z.B. Auftraggeber, Systemnutzer, Systembetreiber, Architekten, Entwickler, Tester usw.

• Dokumente

Darin finden sich oft entscheidende Informationen, aus denen Anforderungen gestaltet werden können, u.a. Normen und Standards, Gesetzestexte sowie branchen-/organisationspezifische Unterlagen.

• Systeme im Betrieb

Dazu gehören Alt- bzw. Vorgängersysteme oder Systeme der Konkurrenz. Meist sind in solchen Fällen Erweiterungen und/oder Änderungen gewünscht. Um dabei innovativ sein zu können, ist es notwendig, eventuell auch gegen den Wunsch mancher Stakeholder Altes hinter sich zu lassen und über den Tellerrand hinauszuschauen.

Die Einbindung von Stakeholdern ist auch laut Standish Group mit Abstand für den Projekterfolg am entscheidendsten, weshalb eine zentrale Aufgabe des Requirements Engineer die Identifikation relevanter Stakeholder ist. Auch wenn Projektbeteiligte zum Teil widersprüchliche Ziele und Anforderungen verfolgen, ist es mit guten Beziehungen zu ihnen möglich, am raschesten an die relevanten Informationen zu gelangen. Darüber hinaus gewährleistet eine intensive Zusammen­arbeit, dass weniger Überarbeitung der Anforderungen notwendig ist, sich die Entwicklungsgeschwindigkeit im Projekt erhöht, geringere Reibung zwischen den Stakeholdern stattfinden und somit ein reduziertes Risiko für den Erfolg des Projekts. Unverzichtbar ist es, die Stimme der Kunden zu verstehen und bei ihnen eine angemessene Erwartungshaltung aufzubauen, denn „der größte Fehler im Projekt [besteht] häufig darin, dem Kunden das zu geben, was er braucht, und nicht das, was er will” .

Entscheidende Produktfaktoren

Um Anforderungen bewerten zu können, ist die Bedeutung dieser für die Zufrieden­heit der Stakeholder ausschlaggebend. Das von Dr. Noriaki Kano 1978 entwickelte Kano-Modell unterteilt dafür die entscheidenden Produktfaktoren in drei Kategorien: Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren.

Abb. 9: Kano-Modell

Basisfaktoren

Die sogenannten ‚Must-haves‘ werden unterbewusst als selbstverständlich voraus­gesetzt und beschreiben die Bedürfnisse sowie die Notwendigkeiten. Ohne deren Erfüllung entsteht bei Stakeholdern eine massive Unzufriedenheit. Gleichzeitig macht die Bereitstellung die Kunden noch nicht zufrieden. Basisfaktoren sind schwierig zu ermitteln, weil diese oft nicht artikuliert werden, sind sie doch auf gut österreichisch ‚eh klar‘. So gilt zum Bespiel für das Mobiltelefon, das vorausgesetzt wird, dass es sich dabei um ein tragbares Gerät handelt, mit dem telefoniert werden kann und mit dem der Benutzer überall erreichbar ist. Die Gefahr bei diesen Eigenschaften ist, dass Altlasten mitgeschleppt werden, ‚weil wir das immer schon so machen!‘. Auch deshalb bieten sich für ihre Entdeckung Beobachtungstechniken bzw. dokumentenzentrierte Techniken an.

Leistungsfaktoren

Leistungsfaktoren werden bewusst und explizit gefordert, handelt es sich doch um bekannte Wünsche und damit erstrebenswerte Merkmale. Diese stellen Kunden bei Erfüllung zufrieden, da sie die ‚Vollständigkeit‘ des Systems sicherstellen. Mit wenigen nicht erfüllten Eigenschaften sind Zielsysteme für Stakeholder meist noch akzeptabel, summieren sich jedoch fehlende Features erzeugt dies Unmut. Leistungsfaktoren sind meist die zuerst entdeckten Anforderungen, weil Stakeholder sie äußern. Zur Ermittlung eignen sich daher am besten Befragungstechniken sowie die Nutzung der Konkurrenz zur Inspiration.

Begeisterungsfaktoren

Unbewusste, weil den Kunden noch gänzlich unbekannte Features werden als Begeisterungsfaktoren bezeichnet und verkörpern Sehnsüchte. Sie erzeugen einen freudigen Überraschungseffekt bzw. bringen Kunden ins Schwärmen, wenn sie bei der Nutzung entdeckt werden. Ihr Wert wird für Stakeholder erst erkennbar, wenn sie von außen herangetragen werden. Solche innovativen Merkmale schaffen häufig den entscheidenden Vorsprung vor die Konkurrenz. Mit der Zeit werden aber Begeisterungsfaktoren durch Gewöhnung zu Leistungs- und schließlich sogar zu Basisfaktoren, wie z.B. heute Internet oder ein Touchscreen am Mobiltelefon. Derartige Charakteristika sind schwer zu ermitteln, weil sie noch nicht in der aktuellen Vorstellungswelt vorhanden sind. Eingesetzt werden meist Kreativitätstechniken, wobei Vorsicht geboten ist und rechtzeitig Analysen von Risiko, Machbarkeit, Nützlichkeit und Begeisterungspotential einbezogen werden sollten.

Ermittlungstechniken

Um an das Wissen der Stakeholder und damit die gewünschten Anforderungen zu gelangen, gibt es kein universelles Rezept. Viele unterschiedliche Techniken unterstützen die Ermittlung von Funktionen, Charakteristika, Einschränkungen und Erwartungen. Diese sind je nach Projekt, Rahmenbedingungen, Menschen und/oder Organisationskultur situativ anwendbar und bewusst auszuwählen. Die Ein­schätzung, welche Technik in der gegebenen Herausforderung die effizienteste ist, erfordert ‚Fingerspitzengefühl‘ und die Erfahrung des Requirements Engineer. Auch die sozialen, gruppendynamischen und kognitiven Kompetenzen der Stakeholder haben Einfluss auf die geeignete Ermittlungstechnik, ebenso wie die Frage, ob es sich beim zu erkundenden Wissen um unterbewusstes, bewusstes oder unbewusstes handelt.

Häufig werden verschiedene Techniken mit- und nacheinander eingesetzt, um die Risikofaktoren für das Projekt zu minimieren. Die Stärken und Schwächen der einzelnen Techniken lassen sich durch die Kombination verringern.

Kreativitätstechniken

Für die Generierung einer ersten Vision eines neuen Systems oder das Entwickeln von Innovationen und Begeisterungsfaktoren kommen meist Kreativitätstechniken zum Einsatz. Weniger geeignet sind sie für das Erheben detaillierter Anforderungen. Von den zahllosen Methoden und unterschiedlichsten Varianten seien hier nur einige exemplarisch genannt:

Brainstorming

In Gruppen von fünf bis zehn Personen werden in begrenzter Zeit ohne Zensur Ideen gesammelt und kommentarlos vom Moderator häufig in Form von Mindmaps festgehalten. Verrückte Vorschläge sind dabei erwünscht, da dank ihnen das Denken die gewohnten Bahnen verlässt. Teilnehmer bereichern die eigenen Vorstellungen durch die der anderen bzw. erweitern und verändern die bereits notierten. Die Analyse der Ideen erfolgt erst im Anschluss an die Kreativsession. Besonders erfolgreich ist diese Technik in Workshops mit sehr heterogenen Gruppen. Vorteile dieses Herangehens sind die Sammlung vieler Ideen in kurzer Zeit sowie das Finden neuer Lösungsansätze durch die wechselseitige ‚Befruchtung‘ und die unzensierten Ideen. Bei schwieriger Gruppendynamik oder starkem hierarchischen Gefälle ist Brainstorming weniger hilfreich, weil die Beteiligten sich wechselseitig blockieren.

Variante Brainstorming paradox

Eine hilfreiche Technik, um Risiken und geeignete Gegenmaßnahmen zu entwickeln, ist das Zusammentragen von Vorschlägen, die nicht erreicht werden sollen. Daraus können dann Aktivitäten erarbeitet werden, um die generierten Ideen zu verhindern.

Variante Brainwriting

Dabei sammeln die Teilnehmer gemeinsam in Ruhe und schriftlich ihre Ideen.

Methode 6-3-5

Sechs Teilnehmer formulieren gleichzeitig, schriftlich drei Ideen. Das Papier wird nach gewisser Zeit, etwa drei bis fünf Minuten, an den Nachbarn weitergereicht. Der Nächste greift die bereits genannten Ideen auf und entwickelt wiederum drei Ideen. Diese Weitergabe wird insgesamt fünfmal durchgeführt, bis jeder jedes Papier einmal bearbeitet hat. Mit dieser Methode entstehen innerhalb von 30 Minuten maximal 108 Ideen (6 Teilnehmer × 3 Ideen × 6 Runden). Bei komplexer Gruppendynamik bietet sich diese Technik an, da sie schriftlich und dadurch Konflikt vermeidend ist. Die vielen Ideen in relativ kurzer Zeit werden nicht zerredet, es gibt ein direktes Feedback und die Methode ist auch per email durchführbar. Gleichzeitig fordert sie eine genaue Anleitung und der starre Ablaufmechanismus stört gelegentlich die Kreativität. Auch der vorgegebene Arbeitstakt blockiert manchmal, weil er für manche Teilnehmer zu langsam und für andere zu schnell sein kann. Oft kommt es zu Redundanzen und im ungünstigsten Fall entstehen insgesamt nur drei Ideen.

Wechsel der Perspektiven

Edward de Bono präsentierte 1986 die heute bekannteste Technik zum Verändern des Blickwinkels. Bei seiner Sechs-Hut-Methode nehmen die Teilnehmer unterschiedliche Perspektiven ein, die durch verschiedenfarbige Hüte symbolisiert werden. Dieses ‚Rollenspiel‘ eignet sich besonders zur umfassenden Beleuchtung komplexerer Aufgabenstellungen sowie zur Bewertung und Optimierung von bereits erarbeiteten Lösungen oder Ideen. Je nach Gruppe ist die Herangehensweise nicht nur effizient, sondern auch unterhaltsam. Durch das in-eine-Rolle-Schlüpfen sind differenziertere Diskussionen möglich, vor allem wenn möglichst viele und ‚extreme‘ Denkmodi berücksichtigt werden. Je nach Temperament und Intro-/Extrovertiertheit der Teilnehmer, können Standpunkte überbetont bzw. theatralisches übersteigert werden. Empfohlen werden Vorübungen, um das thematische Vorwissen zu gewährleisten, bzw. wie bei andere Gruppentechniken eine Moderation.

Analogietechniken (Bionik/Bioziation)

Vorgänge in der Natur werden auf eine vorliegende, meist technische Heraus­forderung übertragen und daraus neue Lösungsmöglichkeiten und Ideen abgeleitet. Die Rückschlüsse aus den Betrachtungen, warum die Dinge in der Natur so sind oder so reagieren, erlauben ein Durchbrechen etablierter geistiger Routinen.

Mit Assoziationen sind gedankliche Verknüpfungen auf einer Ebene gemeint. Die Bisoziation verknüpft Begriffe aus zwei typischerweise nicht zusammengehörenden Ebenen miteinander.

Befragungstechniken

Die Anrufe irgendwelcher Umfrageinstitute beweisen, dass Befragungstechniken der Klassiker zur Informationsbeschaffung sind. Sie sind für alle Detaillierungsgrade von Requirements einsetzbar, solange diese klar artikuliert sind. Mit der entsprechenden Übung kann Befragung für die Erhebung von Leistungs- und Basisfaktoren verwendet werden, etwas schwieriger, aber dennoch möglich für nicht-funktionale Anforderungen. Vorsicht ist allerdings bei der Vorbereitung bzw. eventuell der Auswertung geboten, da die Formulierung von Fragen die Antworten beeinflusst.

Interview

Diese zielen darauf ab, im direkten Gespräch von den einzelnen Stakeholdern möglichst präzise und unverfälschte Auskünfte über deren Anforderungen zu erhalten. Die Befragten können bei Unklarheiten sofort Rückmeldungen geben oder Fragen stellen, woraus sich häufig unerwartete Aspekte ergeben, die ebenso dokumentiert werden können. Das Interview kann flexibel und individuell an das Gegenüber angepasst werden und durch die persönliche Durchführung werden Fragen meist tatsächlich beantwortet. Es besteht allerdings die Gefahr, dass sich das Gespräch unkontrolliert ausweitet oder abgleitet und ineffizient wird. Darüber hinaus wirken zusätzlich zur Formulierung Mimik, Gestik und Tonfall auf den Stakeholder.

Fragebogen

Dabei wird ein Katalog an geschlossenen und/oder offenen Fragen zur Ermittlung von Informationen herangezogen. Wenn Umfragen elektronisch durchgeführt und automatisiert ausgewertet werden, ist dies bei einer großen Zahl von Stakeholdern möglich. Die fehlende Interaktion macht diese Herangehensweise nur für Bewertungen bzw. zur Klärung von Fragen hilfreich, bei denen mutmaßlich das relevante Knowhow bereits bekannt ist, nicht für implizites Wissen. Eine professionelle Erstellung ist entscheidend, sonst sind Fragebögen meist wenig aussagekräftig.

Dokumentenzentrierte Techniken

Wenn diejenigen Mitarbeiter mit dem Wissen über ein jahrelang genutztes System nicht mehr im Unternehmen sind, sondern nur noch Systemnutzer, erlauben dokumentenzentrierte Techniken den Zugriff auf den gesamten Umfang der Funktionalität. Unter der Voraussetzung, das Vorgängersystem ist im Detail und in guter Qualität dokumentiert, kann so das unterbewusste Wissen erhoben werden. Dabei ist zu prüfen, welche (Basis)Faktoren tatsächlich noch gebraucht, welche weggelassen und welche Teile neu kreiert werden soll.

Systemarchäologie

Eine Technik, um Informationen für ein neues System aus der Dokumentation (oder Implementierung) eines Altsystems herauszuholen, ist die Systemarchäologie. Dank Extraktionstechniken kann speziell aus dem Benutzerhandbuch oder alten Testfällen Bekanntes ‚ausgegraben‘ und wieder umgesetzt werden. Diese aufwendige Vorgangsweise erlaubt nur Aussagen über das jeweilige Vorgängersystem, nicht das zu entwickelnde System. Bei schnelllebigen Systemen oder wenn die Dokumentation qualitativ minderwertig oder veraltet ist, lohnt sich diese Methode nicht.

Wiederverwendung

‚Re-Use‘ ist eine Technik, um einmal erarbeitete Anforderungen aus einem vergangenen Projekt an die jetzigen Gegebenheiten anzupassen. Wenn es gelingt, die richtige Anforderung ausfindig zu machen und diese eine gute Dokumentation aufweist, bringt die Wiederverwendung eine enorme Kostenersparnis. Zu beachten ist allerdings die Gefahr, Fehler aus dem vorherigen System zu übernehmen. Dementsprechend muss eine intensive Kontrolle qualitative Mängel ausschließen und die Requirements auf einen entsprechenden Stand bringen.

Beobachtungstechniken

Wenn die Fachspezialisten keine Zeit haben oder nicht in der Lage sind, ihr Wissen zu formulieren, kommen Beobachtungstechniken zum Einsatz. Mit ihnen kann unterbewusstes Wissen ermittelt werden und sie werden besonders für sehr detaillierte Requirements und Basisfaktoren verwendet. Ein Risiko ist, dass vor allem bei der Erhebung aus Vorgängersystemen, alte Technologien bzw. überholte Abläufe festgehalten werden. Der neutrale Beobachter kann aber auch solche Potentiale erkennen und für das Projekt nutzen. Wichtig ist, zu bedenken, dass ein Beobachter immer schon Teil des Systems ist und dieses dadurch verändert. Außerdem liefert Beobachtung nur eine Momentaufnahme und ist für schwer zu verfolgende Prozesse sowie selten auftretende Sonderfälle, z.B. in sicherheitskritischen Bereichen, nicht geeignet.

Feldbeobachtung

Diese Technik dient dazu, die Tätigkeiten, Zusammenhänge und Prozesse der Arbeit eines Stakeholders kennenzulernen und daraus Anforderungen besser ableiten zu können. In dieser Vorgangsweise besteht die Möglichkeit, nachzufragen und sich Einzelheiten erklären zu lassen. Besonders erfolgreich ist Feldbeobachtung bei automatisierten Arbeitsschritten bzw. um individuelle Herangehensweisen zu untersuchen, wenn eine Tätigkeit von verschiedenen Personen durchgeführt wird. Um nicht als Kontrolleur angesehen zu werden, bedarf es einer speziellen Achtsamkeit, vor allem wenn Videoaufnahmen zum Einsatz kommen. Falls die Beobachtung dem observierten Stakeholder unangenehm ist, verändert das nachteilig das Resultat.

Apprenticing

Um das Machtverhältnis zwischen fragendem Beobachter und antwortendem Stake­holder umzukehren, empfiehlt sich die Anwendung des Apprenticing (‚In die Lehre gehen‘). Dabei erlernt der Requirements Engineer die Tätigkeiten vom ‚Meister‘, gießt dieses Knowhow anschließend in Requirements und ist sogar in der Lage, Testfälle zu generieren. Aufgrund der ungeübten Durchführung des Beobachters können potentielle Fehlerquellen, die bei Routiniers selten auftauchen, früher entdeckt werden. Für die Technik sind Personen mit entsprechendem Fachwissen notwendig und vor allem für den ‚Lehrling‘ ist sie enorm zeit- und damit kostenintensiv.

Unterstützende Techniken

Zudem gibt es zahllose Vorgangsweisen, die Ermittlungstechniken ergänzen bzw. deren Schwächen ausgleichen, z.B. Mind Mapping, Workshops, Audio- bzw. Videoaufzeichnungen, Prototypen, Szenarien, Essenzbildung oder Use-Case Modellierung.

Für die praktische Umsetzung bietet Chris Rupp mit dem SOPHIST-REgelwerk eine weitere hilfreiche Technik. Die darin enthaltenen 18 Regeln sind beim Ermitteln und auch bei der Formulierung von Anforderungen hilfreich. Perfekte Kommunikation ist per se unmöglich und schon diese Erkenntnis kann Requirements Engineers das Leben leichter machen. Mit vertiefendem Knowhow bzw. Checklisten zur Kommunikation gestaltet sich das Arbeiten in der Praxis kompetenter und erfolgreicher.

Wahl der richtigen Ermittlungstechnik

Unterschiedlichste Faktoren wie Termin- und Budgetvorgaben beeinflussen die Wahl der richtigen Ermittlungstechnik. Auch die räumliche und zeitliche Verfügbarkeit von Stakeholdern, deren soziale, gruppendynamische und kognitive Fähigkeiten oder die Kategorisierung des zu ermittelnden Wissens nach dem Kano-Modell tragen dazu bei, welche Herangehensweise gerade geeignet ist. Weiters sind die Anforderungs­art, die Detailierungsebene sowie die jeweilige Erfahrung des Requirements Engineer und der Stakeholder mit einer Methode zu berücksichtigen. Auswirkungen zeigen sich ebenso, wenn es sich um eine Neuentwicklung oder Erweiterung eines Altsystems handelt, wenn der zu lösende Sachverhalt eine hohe Komplexität aufweist oder ein großer Systemumfang gegeben ist. Auch die Chancen und Risiken des spezifischen Projekts verursachen Kriterien, die für oder gegen Ermittlungstechniken sprechen.

Anforderungen dokumentieren

Im letzten Kapitel haben wir mit unterschiedlichen Techniken die Bedürfnisse und Wünsche der Stakeholder erarbeitet. An dieser Stelle geht es darum, das gesammelte Wissen dem Projekt entsprechend festzuhalten. ‚Anforderungen dokumentieren‘ ist somit eine weitere Kernaktivität des Requirements Engineering, die dazu dient, durch zusätzliche Informationen die Qualität der Anforderungen zu verbessern und die Kommunikation zwischen Stakeholdern zu erleichtern.

Dokumentieren wird deshalb oftmals mit Spezifizieren gleichgesetzt. Dieser Schritt beinhaltet die schriftliche Darstellung der gewünschten Systemmerkmale und ergibt dabei ein klareres Bild von Details sowie Zusammenhängen der Charakteristika.

Dokumentation dient dazu „Wissen, das in den Köpfen der verschiedenen Stakeholder steckt, zu Papier zu bringen“ . Dies betrifft nicht nur Anforderungen, sondern auch Geschäftsprozesse und Kontextinformationen.

Gründe für die Dokumentation von Requirements:

• Basis der Systementwicklung

Nur klar beschriebene Anforderungen können entsprechend entwickelt werden. Das heißt, von der Qualität der Dokumentation hängt maßgeblich der Erfolg von Softwareprojekten ab. Wenn sich widersprüchliche Informationen verteilen, führt dies über kurz oder lang zu Verwirrung und gefährden das Projekt. Ein gemeinsames Verständnis der Requirements ist daher essentiell, um Konflikte frühzeitig zu erkennen bzw. zu vermeiden.

• Rechtlich relevant

Meist sind Requirements in irgendeiner Form Bestandteil des Vertrags. Auftragnehmer wie Auftraggeber sind daran gebunden und nutzen diese für ihre wechselseitigen Forderungen. Die schriftliche Form erlaubt auch im Falle von Rechtsstreitigkeiten, diese zumindest rascher zu klären.

• Komplex

Um sich zu erinnern bzw. dem Vergessen Einhalt zu gebieten, wird in der Spezifikation das im Ermittlungsschritt gesammelte Knowhow festgehalten. Dafür ist je nach Projekt die relevante Detailtiefe festzulegen und konsistent zu erarbeiten. Nicht nur große Projekte umfassen unzählige Anforderungen mit vielschichtigen Relationen, weshalb es wichtig ist, den Überblick zu behalten. Die Menge an Requirements sowie an beteiligten Personen macht es notwendig, für die umfangreichen Informationen ein angemessenes ‚Speicher- und Arbeitsmedium‘ zu erstellen. Das menschliche Gehirn hat sich in Bezug auf diese Komplexität bzw. die Ausfallsicherheit als wenig nachhaltig herausgestellt, vor allem weil mit der Zeit Menschen, die Wissensträger sind, Projekte verlassen und mit der Materie noch nicht vertraute dazukommen.

• Zugänglichkeit für Beteiligte

Gerade weil es in Projekten unweigerlich zu inhaltlichen und personellen Veränderungen kommt, ist eine umfassende Beschreibung unumgänglich. Es erleichtert die Kommunikation zwischen Stakeholdern beträchtlich, wenn die aktuellen Informationen permanent und transparent für alle verfügbar sind. Viele Missverständnisse sind so leicht zu vermeiden und neue Personen können rasch an ‚Board‘ geholt werden.

• Einheitlichkeit der Dokumentation

Die Verschriftlichung von Informationen erlaubt eine weitere Synchronisie­rung der unterschiedlichen Menschen in der Kommunikation. Wenn verschiedene Auffassungen möglichst simpel und doch ausreichend abgebildet werden, kann sprachliche Unschärfe möglichst ausgemerzt werden und es minimieren sich Interpretationsspielräume. Die damit verbundene Reduktion von Inkonsistenzen vereinfacht notwendige Nacharbeiten und verhindert in der Folge Frustration sowie hohe Kosten.

Zu Beginn bestimmt der Requirements Engineer den Zweck und die Zielgruppe der Dokumentation. Davon hängt die Art und Weise der Spezifikation ab, um sie für die unterschiedlichen Stakeholder nachvollziehbar gestalten zu können. Ebenso gilt es, eine angemessene Detailebene und Darstellungsart auszuwählen, um auch Schnittstellen, Fachprozesse usw. abzubilden. Während der Dokumentation der Anforderungen erfolgt eine fortwährende Überprüfung hinsichtlich Zweck und Zielgruppe. Die Spezifikation ist schließlich nicht Selbstzweck, sondern ein Mittel, um das Projekt zum Erfolg zu führen. Es ist darüber hinaus wichtig, sich zu vergewissern, dass z.B. die Detailebene stimmig ist, denn Standards und Richtlinien können unterschiedlich interpretiert werden: Ein Extrem sind die berüchtigten 500 Seiten-Spezifikationen, ein anderes die minimalistischen User-Stories gemeinsam mit Diskussionen im agilen Setting.

Anforderungsdokumente

Für verschiedene Aktivitäten in Entwicklungsprojekten sind Anforderungsdokumente die Basis:

• Planung von Arbeitspaketen und Meilensteinen

• Entwurf der Systemarchitektur

• Implementierung

• Generierung von Testfällen

• Change Management

• Systemnutzung und -instandhaltung

• Vertragsgegenstand zwischen dem Vertragsnehmer und -geber

  1. === Typische Dokumentenstrukturen ===

Im Requirements Engineering sind keine typischen Dokumentenstrukturen vorhanden. Allgemeine Standards bieten zwar Vorlagen bzw. Orientierungspunkte , die detaillierte Struktur hängt aber vielmehr von der Organisation und/oder dem jeweiligen Projekt ab. Verschiedene Projektarten und Technologietypen erfordern individuell angepasste und dementsprechend kaum normierbare Dokumentations­strukturen. Große Organisationen gestalten für ähnliche inhaltliche oder organisatorische Projekte häufig Templates.

Anhaltspunkte bieten üblich wiederkehrende Elemente in Anforderungsdokumenten:

• Die Darstellung der Vision umfasst Ziel und Motivation des Projekts sowie Zweck und Zielgruppe des Dokuments.

• Auf der Überblicksebene sind die Verortung in der fachlichen Prozess- und IT-Landschaft bzw. dem Systemumfeld, die Kurzbeschreibung der wichtigsten Systemfunktionalität sowie die Nutzerrollen und technischen Schnittstellen zu anderen Systemen relevant.

• Bei der Dokumentation der detaillierten Anforderungen sind die Kurz­beschreibung der Systemfunktion, die Einzelheiten zu jeder Systemfunktion sowie die unterschiedlichen Arten der Requirements (funktionale Anforderungen, Qualitätsanforderungen, Randbedingungen) zu berück­sichtigen. In der Regel findet sich hier auch ein Glossar.

  1. === Qualitätskriterien für das Anforderungsdokument ===

Bei Anforderungsdokumenten ist auf folgende qualitative Aspekte zu achten:

• Eindeutigkeit und Konsistenz

• Klare Struktur

• Modifizierbarkeit und Erweiterbarkeit

• Vollständigkeit

• Verfolgbarkeit

  1. === Qualitätskriterien für Anforderungen ===

Ausgehend vom Stakeholder werden Anforderungen auf dem Weg zur Spezifikation gefiltert, analysiert, bewertet und priorisiert. Unter Bezugnahme auf Projekt- bzw. Unternehmensinterne Standards und Vorschriften soll mithilfe von Qualitätskriterien sichergestellt werden, die Dinge richtig zu tun. Dafür ist es notwendig, die aufbereiteten Requirements systematisch, in erster Linie manuell zu verifizieren und zu validieren. So können Spezifikationsmängel ausgeräumt und die Qualität verbessert werden, um schlussendlich separierte, lesbare und klar umsetzbare Anforderungen für den weiteren Prozess zur Verfügung zu stellen. Eine Orientierung, welche Qualitätskriterien ein systematisches Überprüfen der Requirements ermöglichen, bieten gängige Normen und Regelwerke. Hier sind die des IREB-Standards gelistet:

• Abgestimmt

Eine Freigabe der Anforderung ist durch alle Stakeholder erfolgt.

• Eindeutig

Die Beschreibung der Anforderung lässt keinen Interpretationsspielraum zu.

• Notwendig

Ohne die Anforderung ist die Abnahme des Zielsystems in Frage gestellt.

• Konsistent

Eine Anforderung muss in sich und zu anderen widerspruchsfrei sein.

• Prüfbar

Für die Abnahme ist die Anforderung test- bzw. messbar.

• Realisierbar

Technische Machbarkeit einer Anforderung und ihre Vereinbarkeit mit anderen Anforderungen bzw. Rahmenbedingungen (Budget, Zeitpläne usw) ist gewährleistet.

• Verfolgbar

Ein eindeutiger Identifikator macht eine Anforderung von ihrer Entstehung bis zur Abnahme nachvollziehbar.

• Vollständig

Eine Anforderung umfasst alle relevanten Informationen.

• Verständlich

Für alle Stakeholder, unabhängig vom unterschiedlichen Informationslevel und Ausgangsknowhow, ist die Anforderung konkret fassbar.

Zusätzliche Grundprinzipien der Verständlichkeit, wie kurze Sätze, überschaubare Absätze und maximal eine Anforderung pro Satz, erlauben eine Simplifizierung der Requirements und erhöhen die Lesbarkeit:

Dokumentationstechniken

Für die Beschreibung von Anforderungen an ein gewünschtes System werden in der Praxis die natürliche Sprache in Prosa sowie in strukturierter Form oder konzeptuelle Modelle benutzt. Wie schon bei den Techniken in anderen Phasen kommen oft Kombinationen zum Einsatz, um die Schwächen einzelner Heran­gehensweisen zu kompensieren.

Die Übersicht an dieser Stelle beschränkt sich auf die am häufigsten genutzten Techniken. Die unzähligen Unterkategorien bzw. ergänzenden Methoden finden sich detailliert in der Literatur .

Spezifikation in natürlicher Sprache

Die Dokumentation von Anforderungen erfolgt am häufigsten in Prosa. Vorteilhaft dabei ist vor allem die einfache Anwendung ohne (scheinbar) zusätzlichen Schulungs- und Lernaufwand für Stakeholder. Solange alle Beteiligten der verwendeten Sprache mächtig sind, gilt diese als leicht verständlich. Zudem ist sie vielseitig einsetzbar, unabhängig von Art der Anforderung oder dem jeweiligen Inhalt. Aufgrund des ‚alltäglichen Gebrauchs‘ kommt es allerdings oftmals zu Ungenauigkeit in der Formulierung bzw. ermöglicht die der Sprache inhärente Mehrdeutigkeit unzählige Interpretationen. Auf der Basis des individuellen und damit verschiedenen Vorwissens, Hintergrunds und der Erfahrung verfassen und verstehen Stakeholder Requirements unterschiedlich.

Darum ist es essentiell, auf die Eindeutigkeit Wert zu legen. Die Oberflächenstruktur (Requirement) ist sonst anders als die Tiefenstruktur, also das was im Kopf des einzelnen Menschen vorhanden ist. Sowohl beim Wahrnehmen also auch beim Darstellen von Information kommt es zu sogenannten Transformationsprozessen. Die fünf üblichsten sind:

• Normalisierung

Aus einem meist längeren Prozess, der durch ein Prozesswort dargestellt werden könnte, wird ein singuläres Ereignis und damit ein Substantiv, z.B. ‚übermitteln‘ wird zu ‚Übermittlung‘, ‚abnehmen‘ zu ‚Abnahme‘ usw.) Normalisierung ist nicht grundlegend ein Problem, solange der gemeinte Prozess umfassend bekannt und unmissverständlich ist. Hilfreich ist es, den Begriff eindeutig und interpretationsfrei im Glossar aufzunehmen. Sonst empfiehlt es sich, die Formulierung aufzudröseln.

• Substantive ohne Bezugsindex

Äußerst allgemeine Substantive wie ‚der Benutzer‘ oder ‚das System‘ bergen die Gefahr einer unvollständiger Spezifizierung in sich. Als Requirements Engineer ist es deshalb wichtig, Fragen wie ‚wer ist damit genau gemeint?‘ oder ‚was ‚macht‘ der/das im Detail?‘ zu stellen und beantworten zu lassen.

• Universalquantoren

Universalquantoren beschreiben Häufigkeiten und sind an Signalwörtern wie ‚alle‘, ‚nie‘, ‚immer‘, ‚kein‘, ‚jeder‘, ‚nichts‘ usw. zu erkennen. Sie werden verwendet, um ein bestimmtes Verhalten von einer Menge, also mehreren Objekten, zu schildern. Das Risiko dabei ist, dass das beschriebene Verhalten nicht für alle gilt, weshalb es entscheidend ist, zu hinterfragen, ob tatsächlich ‚immer‘, ‚jeder‘ usw. in dem Kontext zutreffen.

• Unvollständige spezifizierte Bedingungen

Wenn Bedingungen nicht umfassend beschrieben werden, ist von einer unvollständigen Spezifizierung von Zuständen und Ereignissen in Requirements die Rede. So ist häufig der Fall beschrieben, wenn ein Ereignis geschieht, hingegen ist in der Anforderung unberücksichtigt, was geschehen soll, wenn ein Ereignis nicht eintritt. Signalwörter sind hier ‚wenn ... dann‘, ‚falls‘, ‚im Falle von‘, ‚abhängig von‘ usw. Durch Entscheidungs­tabellen können fragmentarische Bedingungen verhindert werden.

• Unvollständige spezifizierte Prozesswörter

Einige Verben (Prozesswörter) benötigen mehr als ein Nomen für ihre komplett Darstellung, z.B. ‚übermitteln‘ verlangt nach der Klärung des ‚was‘, ‚von wo‘ sowie ‚wohin‘. Der Requirements Engineer sollte, wenn möglich, einen Bogen um derartige Passiv-Formen machen und besser auf aktive Formulierung zurückgreifen.

Natursprachliche Spezifikationen sind oft durch Skizzen, einfache Grafiken oder Tabellen ergänzt. Diese Kombinationen sind ebenfalls einfach und schnell zu erstellen, z.B. direkt in Workshops mit Stakeholdern. Nachteilig ist der meist große Interpretationsspielraum, da diese keine allgemein verständliche Semantik haben, weshalb es oft notwendig ist, bei der Entwicklung dabei gewesen zu sein, um die Darstellung umfassend zu verstehen. Übliche Anwendungsfälle, in denen natürliche Sprache genutzt wird, sind u.a. Szenarien oder Use-Case-Beschreibungen.

Um mit natürlicher Sprache strukturiert – wie mit einem Bauplan – Anforderungen zu formulieren, hilft die Konstruktion mittels Schablone (Requirements Template). Diese bietet eine Anleitung für die syntaktische Struktur eines Requirements und damit einen sich leicht anzueignenden Ansatz zur Reduzierung sprachlicher Effekte. Eine Schablone erhöht sowohl die Eindeutigkeit als auch die Qualität im Verhältnis zum zeitlichen und finanziellen Aufwand. Sie sollte allerdings nur verwendet werden, wenn die Stakeholder bereit sind, sich auf eine stark normierte Herangehensweise und starke Einschränkung der stilistischen Freiheit einzulassen. Laut IREB führen folgende fünf Schritte zur Formulierung einer Anforderung mittels Satzschablone  :

• Juristischen Verbindlichkeit festlegen

Dabei wird üblicherweise zwischen ‚rechtlich bindenden‘, ‚dringend empfohlenen‘, ‚zukünftigen‘ und ‚wünschenswerten‘ Requirements differenziert. Zum Ausdruck bringen das vor allem die Modalverben ‚muss‘, ‚sollte‘, ‚wird‘ sowie ‚kann‘.

• Kern der Anforderung (Prozess) bestimmen

Der Autor eines Requirements stellt die Aktivitäten oder Abläufe aktiv und mit Verben dar.

• Aktivität des Systems charakterisieren

Es erfolgt eine Klassifizierung in selbständige Systemaktivität, Benutzer­interaktion oder Schnittstellenanforderung.

• Objekt einfügen

Wenn notwendig, werden Prozesswörter ergänzt, um keine unvollständig spezifizierten Bedingungen zu generieren.

• Logische und zeitliche Bedingungen einfügen

Durch Konjunktionen wie z.B. ‚sobald‘, ‚während‘, ‚nachdem‘ oder ‚falls‘ und die dadurch erzeugten Nebensätze findet eine detailliertere temporale und konditionale Beschreibung von Anforderungen statt.

Dokumentation im agilen Umfeld

Anforderungen heißen im agilen Setting meist User-Storys (‚Anwendererzählung‘ oder ‚Nutzergeschichte‘) und werden in einem Product Backlog gesammelt (deshalb auch Product Backlog Item). Eine User Story beschreibt eine Anforderung bewusst kurz, aussagekräftig und umfasst in der Regel nicht mehr als zwei Sätze aus der Benutzerperspektive. Die Darstellungsform ist schablonenartig in Alltagssprache und baut zentral auf folgenden Satz auf:

Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.

Die Rolle gibt an, wer etwas anfordert. Idealerweise verfasst der zukünftige Nutzer des Systems oder der Nutznießer der zukünftigen Lösung die User Story.

Der Anforderer wünscht sich eine konkrete Funktionalität bzw. ein Systemverhalten. Je klarer und präziser der Wunsch in der User Story geäußert wird, desto hilfreicher ist das für die Realisierung.

Warum das Requirement für den Geschäftsfall wichtig ist, erklärt der (wirtschaftliche) Nutzen, indem er den jeweiligen Wert für den Benutzer oder Kunden darlegt.

Für die Spezifikation ist die ‚Definition of Ready’ von User Storys entscheidend. Wenn diese erfüllt ist, darf eine User Story grundsätzlich in die Umsetzung weitergereicht werden, weil sie als ‚vollständig‘ beschrieben gilt. In jedem Fall gilt für User Storys während ihres ganzen Lebenszyklus: ‚A story is a promise of a conversation‘, weshalb die direkte Kommunikation zwischen den Stakeholdern enorm hoch gehalten wird.

User Storys konzentrieren sich auf das Wesentliche und bewegen sich ausschließlich im Anforderungsraum. Sie bestimmen keine technischen Lösungen, sondern lassen den Spielraum für den Lösungsweg bei den Umsetzenden. Um die Qualität einer User Story sicherzustellen, ist das Akronym ‚INVEST’ hilfreich. Es steht für die Eigenschaften einer guten Nutzergeschichte, denn die sollte independent (unabhängig von anderen), negotiable (verhandelbar), valuable (nützlich), estimable (schätzbar), small (klein) und testable (testbar) sein.

Darüber hinaus beinhaltet eine User Story eine prägnante Beschreibung des Sachverhalts, wenn unbedingt nötig, und Akzeptanzkriterien. Diese stichpunktartigen Kriterien dienen als Checkliste und legen dar, woran erkannt werden kann, dass diese User Story ‚fertig‘ ist. Sind keine Akzeptanzkriterien vorhanden, ist unklar, wie und wann die Abnahme vonstattengehen wird. Die ‚Definition of Done‘ ist in der agilen Herangehensweise essentiell.

Dokumentationsmodelle

Alternativ oder zusätzlich zur Beschreibung mit natürlicher Sprache können Requirements strukturierter und formaler mit Hilfe von Modellen dokumentiert werden. Unter einem Modell wird „ein abstraktes Abbild einer existierenden oder einer noch zu schaffenden Realität“ verstanden. Zu den Eigenschaften von Modellen zählen daher, dass sie die Wirklichkeit abbilden, die Realität durch eine bestimmte Notation verkürzen sowie pragmatisch darauf zugeschnitten sind, was unbedingt dargestellt werden muss. Die Modellbildung kann, wie die Definition erwähnt, eine bereits existierende Realität beschreiben, dann ist von einem deskriptiven Modell die Rede. Dient das Modell als Vorlage für etwas, das noch nicht Realität ist, nennt man die Modellbildung präskriptiv. Bei der Verkürzung werden die Selektion und die Verdichtung unterschieden. In ersterem werden nur ausgesuchte Merkmale im Modell dargestellt. In der Verdichtung kommt es zu einer komprimierten Abbildung von Charakteristika des Gegenstandsbereiches.

Modelle sind im Gegensatz zur natürlichen Sprache nicht universell einsetzbar und erfordern sowohl vom Autor als auch vom Leser gewisse ‚Sprachkenntnisse‘, für die Stakeholder gegebenenfalls geschult werden müssen. Die kompakte Darstellung macht für mit der ‚Sprache‘ vertraute die Information allerdings verständlicher, reduziert den Interpretationsspielraum und damit die Möglichkeit von Missverständnissen. Die Kognitionsforschung bestätigt das Sprichwort ‚Ein Bild sagt mehr als 1000 Worte‘, dass also Menschen Bilder schneller wahrnehmen und sich besser merken als reinen Text. Zudem können Perspektiven in die Dokumentation einbezogen werden, wie z.B. bei einem U-Bahn- bzw. Stadtplan, die unter verschiedenen Blickwinkeln auf dieselbe Stadt schauen. Zudem bieten (bzw. fordern) Requirementsmodelle einen zweckabhängigen Grad der Abstraktion.

Üblicherweise werden im Requirements Engineering konzeptionelle Modellierungs­sprachen verwendet, die durch ihre jeweilige Syntax (Definition gültiger Modell­elemente und Kombinationen) und Semantik (Definition der Bedeutung einzelner Modellelemente) bestimmt sind.

Die Unified Modeling Language, oder kurz UML, ist eine vereinheitlichte grafische Modellierungssprache, die in der Softwareentwicklung zur Spezifikation, Konstruktion und Dokumentation genutzt wird. Entwickelt von der Object Management Group (OMG) eignet sich diese Standard-Notation für strukturelle als auch für verhaltensbasierte Modelle. Wie bei einer Sprache legt die UML Symbole bzw. Bezeichnungen für die meisten bei einer Modellierung wichtigen Begriffe fest und definiert potentielle Beziehungen zwischen diesen Begriffen.

Bei UML-Modellen wird zwischen Strukturdiagrammen, die statische Aspekte darstellen, und Verhaltensdiagrammen, die dynamische Aspekte abbilden, unterschieden. Letztere veranschaulichen das Verhalten des Systems, d.h. dessen Reaktion auf Reize von außen in Form von gewünschten Zuständen, Zustandsänderungen und generierten Ausgaben.

Zu den Strukturdiagrammen gehört neben vielen anderen das Klassendiagramm. In die Kategorie Verhaltensdiagrammen fallen unter anderem das Anwendungsfall­diagramm, das Aktivitätsdiagramm, das Sequenzdiagramm und das Zustands­diagramm.

Klassendiagramme

Diese sehr häufig verwendete Technik gehört zu den strukturellen UML-Diagrammen und bietet die wichtigste Grundlage für jede objektorientierte Lösung. Klassen­diagramme repräsentieren die statischen Strukturen eines Systems, wozu seine Klassen, Attribute, Vorgänge und Objekte gehören sowie die Beziehung zwischen den einzelnen Aspekten. Ein Klassendiagramm kann rechnerische oder organisatorische Daten in Form von Implementierungs- bzw. logischen Klassen darstellen, wobei es zu Überschneidungen kommen kann. Um komplexe Begriffssysteme von Fachgebieten strukturiert darzustellen, können ebenso Klassendiagramme verwendet werden.

Zu den wichtigsten eingesetzten Elementen gehören natürlich die fachlichen Klassen, oder auch Geschäftsobjekte genannt. In einer Klasse werden Objekte gebündelt, die ähnliche Charakteristika aufweisen. Ihre Illustration erfolgt durch ein Rechteck mit einem eindeutigen Namen zur Identifikation. Einer Klasse können Eigenschaften (Attribute) und Operationen (Methoden), die für das Objekt relevant sind, zugeteilt werden. Diese werden innerhalb des Rechtecks unter dem Namen hinzugefügt und jeweils durch waagrechte Striche von der Information darüber abgetrennt. Im hier verwendeten Beispiel gibt es unter anderem die Klasse Route mit den Charakteristika Fahrdauer und Länge. Mit Linien, auch als Kanten bezeichnet, werden Beziehungen zwischen Klassen und Unterklassen dargestellt. Die grundlegenden Relationen eines Klassendiagramms heißen Assoziationen und können mit einem Assoziationsnamen beschrieben werden, im Beispiel Prozesswörter wie berechnet oder gehört zu. Assoziationen zwischen Klassen haben meist Multiplizitäten und Rollen. Eine Multiplizität bringt die Anzahl möglicher Ausprägungen zum Ausdruck und wird mit einem minimalen und einem maximalen Wert versehen. In der UML wird dafür auch der Begriff Kardinalität verwendet. Die Multiplizitäten der Assoziation berechnet in der Grafik besagen, dass ein Navigationsgerät beliebig viele Routen berechnen kann und eine Route von beliebig vielen Navigationsgeräten abgerufen werden kann. Allerdings gehört immer ein Navigationsgerät zu jeweils einem Fahrzeug.

Abb. 10: Beispiel für ein Klassendiagramm

Die Aggregation und Komposition sind zwei spezielle Formen der Assoziation. Beide visualisieren die Beziehungen zwischen dem Teil und dem Ganzen, wobei die Klassen bei der Komposition eine stärkere Bindung haben als bei der Aggregation. D.h., ein Objekt, das Teil eines Ganzen ist, ist von der Existenz dieses Ganzen abhängig. Verschwindet das Ganze, löscht dies auch die Existenz des Objekts, das bis dahin Teil war. Diese Relationen werden wie eine Assoziation als Linie zwischen zwei Klassen dargestellt und bei der Aggregation zusätzlich mit einer kleinen, leeren Raute versehen, bei der Komposition mit einer gefüllten Raute. Laut Beispiel ist die Route eine Aggregation aus mindestens einem bis zu beliebig vielen Streckenabschnitten.

Ein weiteres Notationselement ist die Generalisierung, die eine gerichtete Beziehung zwischen einer allgemeinen und einer speziellen Klasse beschreibt. Dabei erfolgt die Vererbung aller Struktur- und Verhaltensmerkmale des Supertyps an Subklassen, ohne dass diese Eigenschaften bei der spezielleren Klasse explizit deklariert werden. Diese Beziehungen werden durch einen Pfeil ausgedrückt. So ist z.B. ein Navigationsgerät mit Stauumfahrung eine Unterkategorie der Superklasse Navigationsgerät und erbt als solche alle Eigenschaften der übergeordneten Klasse, im Beispiel das Attribut Identifikation.

Klassendiagramme basieren auf den Prinzipien der Objektorientierung und können aufgrund ihrer Vielseitigkeit in allen Projektphasen verwendet werden. In der Analysephase dient es als Domainmodell, um ein Abbild der Realität zu illustrieren und Anforderungen zu dokumentieren. Danach wird damit in der Designphase die Software gestaltet sowie in der Umsetzungsphase daraus der Code entwickelt. Klassendiagramme sind somit ein unentbehrlicher Bestandteil für die Anforderungsdokumentation sowie die Softwareentwicklung in Projekten. Im Requirements Engineering kommt das Klassendiagramm für statische Konzepte zum Einsatz, um Dinge (Geschäftsobjekte, Personen, Objekte, System) und deren Charakteristika, Relationen und Abhängigkeiten zu dokumentieren. Eine weitere Verwendungsmöglichkeit ist das Begriffsmodel, um Beziehungen zwischen den im Zielsystem verwendeten Begrifflichkeiten zu visualisieren. Als Ergänzung zum Glossar unterstützt ein Begriffsmodell das Verstehen des fachlichen Problems.

Klassendiagramme, ob nun für Objekte oder Begriffe, bieten Orientierung und gewähren einen detaillierten Einblick in die Struktur des zu entwickelnden Systems bzw. der Begriffsrelationen. Zu beachten gilt allerdings, dass Klassen keine Systemelemente sind, sondern Aspekte der fachlichen Umgebung. Deshalb finden sie nicht eins zu eins ihre Repräsentation im gewünschten Zielsystem. Simple Klassendiagramme sind mit etwas Vorwissen einfach und schnell zu lesen sowie mit der richtigen Software auch relativ unkompliziert zu erstellen. Dadurch sind sie eine ideale Basis für das Requirements Engineering von der ersten Visualisierung konzeptueller Inhalte über plattformunabhängige logische Modelle bis hin zu ‚Implementierungsbauplänen‘.

Die in der Folge dargestellten Dokumentationsformen gehören in die Gruppe der verhaltensbasierten UML-Diagramme:

Anwendungsfalldiagramm

Diese Form ist auch unter dem Namen Use-Case-Diagramm bekannt und beschreibt ein System, das in der Grafik durch das große Rechteck begrenzt wird, welches das System vom Außen trennt. Das System kann mit einem Namen versehen werden, im hier genutzten Beispiel handelt es sich um einen ‚Onlineshop‘. Im System außen finden sich Akteure, das sind zum einen Menschen, die mit dem System interagieren (z.B. der Kunde oder der Shop Manager), zum anderen (technische) Systeme, die mit dem Onlineshop kommunizieren, z.B. das Online-Bezahlsystem. Ein Use Case schildert eine typische Interaktion eines Users mit dem System, die zu einer angestrebten Reaktion des Systems führt. Die Akteure sind mit Linien mit den entsprechenden Aktivitäten verbunden, mit denen Kommunikation stattfindet. Jeder Punkt, an dem die Kommunikationsbeziehung die Systemgrenze kreuzt, ist ein Hinweis entweder auf eine Benutzerschnittstelle oder eine technische Schnittstelle.

Abb. 11: Beispiel für ein Use-Case-Diagramm

Anwendungsfalldiagramme nutzen die Spezifikationen eines Use Cases und modellieren die funktionalen Bestandteile eines Systems, also das geforderte, nach außen sichtbare Verhalten des Systems. Somit sind sie Teil der Anforderungen, die das zu entwickelnde System erfüllen soll. Ein Use-Case-Diagramm kann alle Anwendungsfälle eines Systems und deren Verbindungen zueinander grafisch abbilden oder nur eine Gruppe von Use Cases mit ähnlicher Funktionalität. Einzelne Use Cases sind aber als abgeschlossene Prozesse zu betrachten, die sich nicht überschneiden sollten.

Besonders gut geeignet sind Anwendungsdiagramme für die Dokumentation eines ersten Brainstormings mit den Stakeholdern zum gewünschten System, um sich einen Überblick über die geforderten funktionalen Anforderungen zu verschaffen. Darauf aufbauend kann die Spezifikation mit anderen Diagrammtypen und natürlicher Sprache fortgesetzt werden bzw. weiter in die Tiefe gehen. Use-Case-Diagramme zählen zu den Modellklassikern, weil sie sehr einfach zu erstellen und zu verstehen sind. Da die Geschehnisse aus der Perspektive der User dargestellt werden, ist ihr Einsatz in einer frühen Phase der Anforderungserhebung und -dokumentation hilfreich. Bereits für die Abbildung von Geschäftsprozessen oder eben von (Teil)Systemprozesse erweisen sich Use Cases als das Mittel der Wahl. Dank ihnen gelingt es unkompliziert, komplexe Themen grob herunterzubrechen und die essentiellen Funktionen herauszufiltern. Damit bieten sie eine perfekte Diskussionsgrundlage für den folgenden Projektverlauf sowie eine Basis für die weitere Aufschlüsselung und Detaillierung. Zu beachten ist, dass sich Anwendungsfalldiagramme nicht eignen, um systeminterne Abläufe zu dokumentieren oder Funktionen im Detail zu erläutern.

Zusammengefasst sind die Vorteile eines Use-Case-Diagramms, dass es für Stakeholder ohne umfangreiche Erklärungen nachvollziehbar ist und eine anschauliche Darstellung von Sachverhalten erlaubt. Damit können sich die Beteiligten einen Überblick über die wichtigsten Funktionen verschaffen und die weitere Requirementserhebung vereinfacht sich. So ist die Verwendung in Workshops besonders fruchtbar, um Anwendungsfälle und eine erste Skizze der zu entwickelnden Funktionalitäten zu erarbeiten. Allerdings bleibt diese Beschreibung noch ohne Details über das System selbst. Auch zur Bestimmung des Systemkontexts kann das Anwendungsfalldiagramm herangezogen werden. Nachteilig ist, dass häufig Redundanzen und Inkonsistenzen entstehen, da bei der Erstellung von Use Cases das Zielsystem funktional zerlegt und einzelne Abläufe in mehreren Anwendungsfällen relevant sind. Nicht geeignet sind Use-Case-Diagramme für nicht-funktionale Anforderungen. Ebenso stellen sie meist nur einen (oberflächlichen) Teil der Anforderung dar, weshalb es notwendig ist, noch auf andere Dokumentationsformen zurückzugreifen.

Häufig werden Anwendungsfalldiagramme durch Anwendungsfallbeschreibungen ergänzt. Dafür wird meist formularartig natürliche Sprache genutzt, wobei der Grad der Formalisierung von sehr schablonenhaft bis wenig vorgegeben variiert. Das Abfragen bestimmter Informationen schützt davor, wichtige Details zu übersehen und die strukturierte Aufbereitung ermöglicht ein rascheres, weil selektiveres Erfassen als in Prosatexten. Im Gegensatz zu den Anwendungsfalldiagrammen können auch nicht-funktionale Anforderungen in den Beschreibungen erfasst werden. Es gilt jedoch die Schilderungen generell möglichst knapp und präzise zu halten, da sonst das Risiko hoch ist, dass die Beschreibungen schnell ausufern und unübersichtlich werden. Use-Case-Beschreibungen können auch ohne ein entsprechendes Diagramm zum Einsatz kommen.

Aktivitätsdiagramme

Um Abläufe in Systemen und deren Regeln im Detail beschreiben, kommen in der Praxis häufig Aktivitätsdiagramme zum Einsatz, vor allem für komplexe Prozesse. Aufbauend auf Use-Case-Diagramme betrachten diese die Zerlegung der Schritte des Kontrollflusses in Aktivitäten, d.h. wenn alles nach Plan verläuft. Die Dokumentation der Ausführungsbedingungen von Hauptszenarien wird zudem durch Ausnahmen, mögliche Fehler bzw. zulässige Prozessalternativen ergänzt.

Je nach Einsatzzeitpunkt im Projektverlauf, kann der Detaillierungsgrad an die Gegebenheiten angepasst werden. Deshalb ist das Aktivitätsdiagramm sehr beliebt für grafisch darzustellende Geschäfts- oder Betriebsabläufe, um dort die Aktivität eines Teils oder einer Komponente im System zu veranschaulichen. Diese Art des Diagramms ist wie viele andere nicht unbedingt notwendig für die Spezifikation von Requirements. Es empfiehlt sich allerdings, die damit mögliche übersichtliche Darstellung einzubeziehen, wenn Entscheidungen, Alternativen und Ausnahme­situationen in Prozessen visualisiert werden müssen.

Aktivitätsdiagramme verwenden spezielle Formen, die mit Pfeilen verbunden werden. Zu den verwendeten Elementen in einem Aktivitätsdiagramm gehören Aktionen, die dafür stehen, was getan wird, und unterschiedliche Knoten. Die Namen dafür müssen eindeutig sein. Pro Aktivitätsdiagramm darf nur ein Startknoten, ein ausgefüllter, schwarzer Kreis, eingesetzt werden. Dieser repräsentiert das Ereignis, das den im Diagramm dargestellten Ablauf initiiert. Ein bis mehrere Endknoten sind möglich, die das Ende des Ablaufes anzeigen. Darüber hinaus gibt es Kontrollknoten, wie Entscheidungsknoten bzw. Synchronisationsknoten oder auch -balken, die die Regeln beschreiben, wann und wie Aktionen ablaufen können.

Die Beispielgrafik illustriert den Ablauf ‚zum Zielort navigieren‘ mit der Ermittlung einer Route eines Navigationsgeräts. Dabei kommt ein Entscheidungsknoten zum Einsatz, an dem sich die Frage stellt, ob Staus umfahren werden sollen oder nicht. Die Synchronisationsbalken zeigen gleichzeitig ablaufende Aktionen an. Als Fork wird eine Verzweigung in parallele Aktivitäten bezeichnet, Join heißt der Punkt, wenn die Stränge wieder zusammenkommen. Die Kanten, in Form von Pfeilen, verbinden die einzelnen Elemente und stellen die zeitliche bzw. logische Reihenfolge im Prozess dar. Aktivitäten laufen grundsätzlich nacheinander ab, d.h. erst wenn eine abgeschlossen ist, folgt die nächste. Darüber hinaus gibt es ein Hierarchisierungs­element, das wie eine Gabel aussieht, und im Beispiel in der Aktivität Verkehrsinfos erfragen vorkommt. Dieses verdeutlicht, dass eine andere Aktivität aufgerufen wird, die in einem weiteren Aktivitätsdiagramm dargestellt werden kann.

Abb. 12: Beispiel für ein Aktivitätsdiagramm

Im Requirements Engineering werden Aktivitätsdiagramme zur Verfeinerung und Detaillierung von Use Cases verwendet. Meist gibt es zu jedem Anwendungsfall­diagramm mindestens ein oder sogar mehrere Aktivitätsdiagramme. Diese dienen der Visualisierung von Prozessen mit fachlichen Ausführungsbedingungen sowie der Darstellung für Aktionen im Fehler- und/oder Ausnahmefall in Abläufen.

Das Aktivitätsdiagramm ist auch für Stakeholder häufig eine unaufwendig zu lernende und zu verstehende Technik. Prozessregeln können damit gut beschrieben werden und der Grad der Detaillierung kann je nach Bedarf gewählt werden. Daraus ergibt sich ein sehr breites Anwendungsspektrum. Auch wenn die Grundzüge von Aktivitätsdiagrammen einfach und ohne Vorwissen zugänglich sind, kommt es in der Tiefe zu beachtlichen Variationen der Modellierung. Wenn diese zur Anwendung kommen, führt das meist dazu, dass das Diagramm von Stakeholdern nicht mehr selbstverständlich erschlossen werden kann.

Zustandsdiagramm

Das Zustandsdiagramm, auch State (Machine) Diagram oder Zustandsautomat genannt, ist ein Verhaltensdiagramm, mit dem die Zustandsänderungen eines Objektes visualisiert werden. Es wird benutzt, um eine Abfolge von Zuständen, die ein Objekt während seines Lebenszyklus einnehmen kann, zu beschreiben. Diese Diagramme eignen sich zur Spezifizierung des ereignisgesteuerten Verhaltens eines Systems, eines Teilsystems oder einer Komponente sowie von Systemschnittstellen.

Besonderes Augenmerk liegt bei Zustandsdiagrammen auf den verschiedenen Zuständen des Systems, den Aktionen und zugehörigen Bedingungen, die zu einem Zustandswechsel führen, sowie den Auswirkungen des Systems auf dessen Umgebung. Ein Zustand meint einen Zeitraum, in dem ein System ein gewisses Verhalten aufweist bzw. auf das Eintreten eines festgelegten Geschehnisses wartet.

Abb. 13: Beispiel für ein Zustandsdiagramm

Die gleichen Symbole wie im Aktivitätsdiagramm beschreiben den Beginn des Lebenszyklus eines Objektes, der ausgefüllte Startpunkt, und das Ende, der schwarze Endpunkt mit dem zusätzlichen Ring außen herum. Die Zustands­übergänge, auch Transitionen genannt, verbinden jeweils einen Quell- und einen Zielzustand und werden durch Pfeile dargestellt. Ereignisse, sogenannte Trigger, lösen Transitionen aus. Dabei werden externe, z.B. der Leser gibt das Buch zurück, oder interne Auslöser, das Buch ist kaputt, unterschieden. Daran können als Guard oder Wächterausdruck bezeichnete Bedingungen geknüpft sein, deren Erfüllung Voraussetzung für einen bestimmten Zustandswechsel ist. Die Transition wird durch diese geschützt und der Zustandswechsel kann erst durchlaufen werden, wenn der Wächterausdruck erreicht, also ‚wahr‘, ist. In der Grafik kann dem Zustandsübergang diese schriftliche Verhaltensspezifikation wie eine Bemerkung zugeordnet werden. Die Beschriftung illustriert das auslösende Ereignis, die vorab zu erfüllende Bedingung und/oder die Aktivität (Operation), die beim Zustandswechsel ausgeführt wird. All diese Beschreibungselemente sind optional und können je nach Bedarf kombiniert werden. Obwohl im angeführten Beispiel kein Rautenelement verwendet wird, kann dieses für Kreuzungen bzw. Entscheidungen eingesetzt werden. Gelegentlich umfasst ein Zustand auch mehrere Unterzustände, so dass von einem zusammengesetzten Zustand die Rede ist.

Zustandsübergange können schlecht in natürlicher Sprache abgebildet und so verständlich veranschaulicht werden. Das Zustandsdiagramm unterstützt dabei, Inkonsistenzen zu identifizieren und klare Regeln zu definieren. Im Idealfall bildet es das gesamte Verhalten eines Zustandsautomaten ab, in manchen Fällen ist es jedoch sinnvoll, Details in weiteren Diagrammen aufzuschlüsseln. Dementsprechend kommt das Zustandsdiagramm dann zum Einsatz, wenn Lebenszyklen, von der Initialisierung bis zur Freigabe, oder fachliche Zustände von Geschäftsobjekten modelliert werden sollen. Sie eignen sich auch zur Dokumentation der Informationen, welche Aktivitäten in welchen Zuständen überhaupt erlaubt sind, wodurch das Verhalten eines Objekts sichtbar und nachvollziehbar wird. Zudem dient es als Ergänzung und zum Überblick zu komplexen Prozess- oder Ablaufdiagrammen. Auch eine Bildschirmmaske kann als Zustand angenommen werden. Mit Hilfe eines Zustandsdiagramms ist es möglich, benutzerseitig durch eine Klickabfolge eines Softwaresystems zu führen.

Zustandsdiagramme sind ein wertvolles Instrument zur Modellierung von Systemen, einzelnen Komponenten oder Objekten und ihrem möglichen Verhalten. Speziell um Reaktionen auf unterschiedliche Ereignisse und die Regeln für ein spezifisches Verhalten darzustellen, sind sie hilfreich. Es ist möglich, sowohl das Gesamtsystemverhalten zu visualisieren, z.B. wie mehrere Use Cases parallel und ineinandergreifend ablaufen, als auch viele Detailebenen darzustellen. Ebenso kann es als Analysemodell zum Prüfen von Requirements bzw. zur Dokumentation des Lebenszyklus eines Requirements herangezogen werden. Zustandsdiagramme lassen sich unkompliziert und in vielen Situationen verwenden, zumal selbst ungeübte Leser sie mit ein wenig Übung leicht nachvollziehen können. Viele Menschen liegt allerdings das Denken in Abläufen eher als das in Zuständen, weshalb es eventuell zu Widerständen von Stakeholdern in Bezug auf diese Technik kommt. Besonders detaillierte Zustandsdiagramme sind meist äußerst technisch und dementsprechend nicht für alle Stakeholder geeignet. Darüber hinaus erfordert es viel Erfahrung und Modellierungsexpertise des Requirements Engineers, um zweckmäßige und fruchtbare Zustandsdiagramme zu erstellen.

Auswahl einer Dokumentationtechnik

In diesem Skriptum ist nur von einer ganz kleinen Auswahl an möglichen Techniken die Rede, weshalb es entscheidend ist, bei der vorhandenen Fülle, die sinnvollste Methode zur Dokumentation auszuwählen. In manchen Fällen erscheint die Wahl einfach, speziell wenn ein bestimmtes Vorgehensmodell eine Technik vorschreibt oder diese sich traditionell bewährt hat. Grundsätzlich bestimmen aber viele unterschiedliche Faktoren die Auswahl. Schwierigkeiten sind zu erwarten, wenn die ausgesuchte Technik nicht zu den zu visualisierenden Inhalten bzw. Rahmenbedingungen des Projekts passt oder die Stakeholder die Spezifikation nicht annehmen bzw. verstehen. Daher ist es absolut notwendig, sich rechtzeitig Gedanken über die jeweiligen Vor- und Nachteile einer Methode zu machen. Je mehr verschiedene Techniken zum Einsatz kommen, desto höher ist der Aufwand für die Nachverfolgbarkeit und Konsistenz. Alle Dokumente müssen immer aktuell, miteinander verknüpft und ohne Widerspruch sein. Außerdem entsteht unter Umständen für die Schulung der Stakeholder für jede neue Technik weiteres Investment, ebenso wenn für die Abbildung in einer Technik ein weiteres Tool notwendig ist.

Einflussfaktoren auf die Wahl der Technik:

• Akzeptanz

Niemandem ist geholfen, wenn Stakeholder Anforderungen ignorieren oder ablehnen, weil sie mit der Dokumentationstechnik nicht umgehen können oder wollen.

• Notationskenntnis

Je nach Technik ist unterschiedliches Vorwissen notwendig. Der Requirements Engineer muss ermitteln, ob die Stakeholder, vor allem die Kunden und Nutzer, mit der ausgewählten Dokumentationstechnik vertraut sind und das geforderte Knowhow vorhanden ist.

• Spezifikationslevel

Nicht alle Dokumentationstechniken eignen sich für alle Beschreibungs­ebenen, weshalb es sinnvoll ist, vorab den benötigten Detailierungsgrad zu prüfen.

• Komplexität des zu beschreibenden Sachverhalts

Je nachdem wo die beschreibenden Personen die Schwerpunkte setzen, sind Dokumentationen häufig entweder für das gewünschte Ziel übertrieben und ausufernd oder sie entbehren jeder Vollständigkeit und reichen nicht, um die Komplexität des Projekts darzustellen. Unbedingt ist daher zu Beginn, die Angemessenheit der Dokumentationstechnik zu klären.

• Aufwand-Nutzen-Verhältnis

Aufwand und Nutzen einer speziellen Dokumentationsform müssen für die Beschreibung eines Sachverhalts adäquat sein.

• Konsistenz

Änderungen treten nicht nur nach der Fertigstellung der Anforderungs­dokumentation auf, sondern auch der Weg dorthin ist bereits ein durch­gängiger Changeprozess. Es gilt zu beachten, ob eine Technik sich rasch und unkompliziert adaptieren lässt, da schlussendlich die einzelnen Teile ineinandergreifen sollen.

• Eindeutigkeit

Je nach gewünschtem Detaillierungsgrad sind andere Techniken geeignet. Entscheidend ist, dass bei einer gewünschten simplifizierten Dokumentation nicht die Verständlichkeit auf der Strecke bleibt.

Voraussichtlich müssen in einem Projekt bei der Wahl der Dokumentationstechniken Kompromisse eingegangen werden, daher ist diese gründlich abzuwägen. Der Requirements Engineer hat dementsprechend zu klären, ob die Verwendung einer Technik einen Qualitätsgewinn bedeutet oder ob sie eher Verwirrung stiftet. Ebenso sollen Redundanzen aufgrund unterschiedlicher Herangehensweisen vermieden werden. Speziell wenn Diagramme oder andere formalisierte Dokumentationsformen zum Einsatz kommen, empfiehlt sich ein Leseleitfaden für die Spezifikation. Um von vornherein so wenig Raum wie möglich für Missverständnisse einzuräumen, werden darin alle verwendeten Modelle, die entsprechenden Notationselemente und deren Bedeutung erklärt.

In der Praxis kommen sehr häufig Mischung von Modellen und ausformuliertem bzw. strukturiertem Text zur Dokumentation zum Einsatz. Vorteilhaft ist daran, dass die Kombination die Schwächen der jeweiligen Dokumentationsformen ausgleicht. Dabei ist aber unbedingt darauf zu achten, dass zwischen den einzelnen Darstellungstechniken, vor allem bei der Überarbeitung, keine Inkonsistenzen entstehen.

Wichtig ist, egal bei welcher ausgewählten Technik, dass auf ökonomische Spezifikation Wert gelegt wird. Die am besten passende Dokumentationstechnik ist jene, die eine knappe und gleichzeitig präzise Dokumentation ermöglicht sowie den Aufwand soweit wie möglich minimalisiert. Die Kunst hierbei ist die richtige Balance zwischen Über- und Unterspezifizierung zu finden, also genau herauszufiltern, wie viel ‚genug‘ ist, um verständliche, im Detail korrekte und nicht ausufernde Darstellungen zu erhalten. Das passende Sprichwort an dieser Stelle lautet: So viel wie nötig, aber so wenig wie möglich!

Glossar

Jede Disziplin, jedes fachliche Umfeld hat seine eigene Sprache und sein eigenes Vokabular. Das Verständnis von Begriffen ist, wie bereits erwähnt, bei Menschen aus verschiedenen Gründen unterschiedlich. Je abstrakter Worte sind, desto höher ist die Wahrscheinlichkeit von Missverständnissen. So beschäftigt der Versuch einer Definition z.B. von Liebe, Familie, Heimat die ‚Philosophen‘ dieser Welt seit Jahrtausenden.

Um etwaige Missverständnisse in der Beschreibung der Anforderungen zu verhindern, ist es entscheidend, die für das Projekt relevanten Grundbegriffe zu definieren und in einem Glossar zu sammeln. Einerseits erweist sich das als hilfreich, wenn fachfremde Stakeholder beteiligt sind, andererseits beugt es auch in der eigenen Disziplin abweichende Interpretationen vor. Ein scheinbar harmloser und allgemein verständlicher Begriff wie ‚speichern‘ oder ‚archivieren‘ kann im Softwarekontext unterschiedlichste Deutungsweisen zur Folge haben.

Um eine konsistente Terminologie zu erreichen, empfiehlt es sich, frühzeitig alle in der Anforderungsdokumentation verwendeten Fachbegriffe und Abkürzungen aufzulisten, zu erklären und den Stakeholdern zugänglich zu machen. Ein Glossar zu erstellen, heißt allerdings nicht, das Rad neu erfinden zu müssen. In ähnlichen Kontexten, Organisationen und/oder Projekten zeigen sich häufig gleiche oder ähnliche Begriffe. Daher ist es sinnvoll, vorhandene Vokabularsammlungen wiederzuverwenden und zu ‚recyceln‘ bzw. sich schlau zu machen, da für manche Fachgebiete öffentlich zugängliche Definitionen vorhanden sind. Diese erlauben eine enorme Reduktion des Aufwands für Folgeprojekte.

=
Anforderungen prüfen & abstimmen =

Nach dem im letzten Kapitel beschriebenen Erstellen der Spezifikationen, handelt dieser Abschnitt von einer weiteren Kernaktivität des Requirements Engineering. Der zuständige Anforderungsanalytiker begutachtet, kontrolliert und bewertet alle erarbeiteten Requirements. Ziel dieses auf-den-Zahn-Fühlens ist es, der Lösung der Aufgabenstellung näher zu kommen und eine erste Synthese zu finden, den Gesamtkontext und damit die Relationen zwischen den einzelnen Anforderungen sichtbar zu machen. Zudem gilt es, dieses Bild mit den Stakeholdern abzugleichen und so zu einem gemeinsamen zu machen.

Mit dem Schritt des Analysierens und Vereinbarens ist ein rascher, aber nicht vorzeitiger Abschluss der bisherigen Phasen anzustreben. ‚Abgeschlossen‘ sind die vorbereitenden Phasen dann, wenn alle wichtigen Stakeholder die notwendigen Rahmenbedingungen und Anforderungen für das Projekt absegnen. Obwohl natürlich auch hier Gewissenhaftigkeit an den Tag gelegt werden muss, kann das agile Prinzip ‚Better done than perfect‘ zur Orientierung dienen. Denn übermäßiger Perfektionismus ist an dieser Stelle hinderlich, führt er zur Verzögerung des Projekts und kann Änderungen doch nicht vorbeugen. Entscheidend ist vielmehr, dass sich alle Beteiligten – eben spätestens in der Abstimmung – über folgende Tatsachen im Klaren sind:

• Anforderungen sind nicht stabil

Es ist weder möglich noch sinnvoll, Requirements zu Beginn der Umsetzungs­phase einzufrieren. Schon 500 v.Chr. soll der Philosoph Heraklit von Ephesus gesagt haben: „Die einzige Konstante im Universum ist die Veränderung“. Dementsprechend sollte der Requirements Engineer frühzeitig mit allen Stakeholdern ein nachvollziehbares Änderungs­management vereinbaren, um die sicher kommenden Veränderungen abbilden und bearbeiten zu können.

• zu ausführliche Analyse führt zur Paralyse

Besonders umfangreiche und/oder komplexe Projekte neigen dazu, bereits vor der Umsetzungsphase Lähmungserscheinungen aufzuweisen. Daraus resultieren Rückstände und Verschiebungen, die in der folgenden Software­entwicklung nie aufgeholt werden können, sondern sich meist drastisch verschlimmern. Pragmatisch kann das bedeuten, dass das Produkt den richtigen Zeitpunkt für den Markteintritt verpasst oder die zu hohe Komplexität die Chancen der Software am Markt minimiert.

• Je kürzer das Projekt, desto weniger Änderungen

Eine kurze Projektdauer und ein dementsprechend gut abgegrenztes Projekt führen automatisch dazu, dass die Fluktuation der Anforderungen und der involvierten Personen geringer ausfällt. Damit senken sich die Projektkosten, denn ausufernde sowie entbehrliche Veränderungen erhöhen unnötig das Budget und gefährden das Projekt.

Qualitätssicherung

Die verschiedenen Perspektiven, Sichtweisen und Ausgangslevel führen in der Kombination mit unterschiedlichen Fachsprachen sowie den Herausforderungen der Kommunikation generell zu Qualitätsmängeln. Um Anforderungen und ihren Nutzen sicherzustellen, ist es unerlässlich, diesen Prozess mit systematischen Qualitäts­sicherungsmaßnahmen zu begleiten.

Grundlagen der Prüfung

Das Checken der Qualität von Anforderungen ist ein essentieller Teil des Requirements Engineering. Dabei gilt es unter anderem in der Begutachtung mit Stakeholdern herauszufinden, ob es noch eine ‚Kluft‘ zwischen den fest­geschriebenen Requirements und den vorhandenen Bedürfnissen und Wünschen gibt. Im Zuge dessen fällt auch die Entscheidung, ob Anforderungen die geforderten Qualitätskriterien erfüllen und für den weiteren Entwicklungsprozess freigegeben werden können. Die dafür notwendigen Prüf- und Abnahmekriterien sollten bereits in der Ermittlungsphase abgefragt und definiert werden. Prüfgruppen bestehen im Idealfall und je nach Technik aus unterschiedlichsten Personen (Auftraggeber, Nutzer, Softwareentwickler, Tester usw.), damit die ‚fertigen‘ Anforderungen den verschiedenen Sichtweisen und Ansprüchen gerecht werden.

Die Überprüfungen dienen dazu, sicherzustellen, dass alle Requirements wider­spruchsfrei sind. Auf dem Weg dorthin müssen Fehler in Anforderungen (z.B. Mehrdeutigkeit, Unvollständigkeit oder Divergenz) entdeckt und korrigiert werden. Bereits zu Beginn dieser Lehrveranstaltung erfolgte der Hinweis auf die entstehenden Kosten je nach ihrem Entdeckungs- und Beseitigungszeitpunkt. Alle Unstimmigkeiten oder Mängel in Anforderungen, die erst in der Design-, Entwicklungs-, Implementierungs- oder gar Testphase sichtbar werden, verursachen einen vielfachen finanziellen Aufwand zur Behebung.

Die gesammelten Requirements werden während der ganzen weiteren Produkt­entwicklung referenziert. Mängel, die in den Anforderungsdokumenten bestehen, pflanzen sich logischerweise fort und beeinträchtigen das gesamte Projekt. Die sich daraus ergebenden Kosten wurden bereits erwähnt. Der Arbeitsaufwand und die damit verbundene Demotivation (durch z.B. Korrigieren des Codes und Test Cases bzw. im schlimmsten Fall das Teilen der Architektur) muss zusätzlich dazu gerechnet werden.

Die Prüfung der Requirements soll auch unangenehme rechtliche Folgen minimieren. Die Anforderungsdokumente sind meist auch Vertragsbestandteil, d.h. Mängel darin führen dazu, dass Vereinbarungen, z.B. Leistungsumfang, Zeitpläne, nicht eingehalten werden können.

Was ist Qualität?

Die gültige Norm des Qualitätsmanagement DIN EN ISO 9000:2015-11 definiert Qualität als „Grad, in dem ein Satz inhärenter Merkmale eines Objekts Anforderungen erfüllt“ .

Im Requirements Engineering ist damit gemeint, in wie weit eine Anforderung bzw. ein Anforderungsdokument den objektiv messbaren und definierten Qualitätskriterien entspricht. Aufgrund der Vielzahl an Qualitätskriterien ist schlussendlich entscheidend, was im jeweiligen Projekt garantiert, dass die Requirements die Bedürfnisse und Wünsche der Stakeholder an das zu erstellende System so dargestellt sind, dass in den folgenden Umsetzungsphasen entsprechend gearbeitet werden kann und das Ergebnis dem entspricht, was der Kunde bzw. die Nutzer brauchen.

Qualitätsaspekte

Bereits im Kapitel über die Dokumentation von Anforderungen befindet sich eine Sammlung von Qualitätskriterien zu Anforderungsdokumenten und einzelnen Anforderungen. Diese Kriterien lassen sich nach IREB in drei Qualitätsaspekte zusammenfassen und ermöglichen so eine strukturierte Überprüfung von Anforderungen. Die Freigabe von Anforderungen für den weiteren Entwicklungs­prozess findet statt, wenn alle drei Bereiche erfolgreich unter die Lupe genommen wurden.

Qualitätsaspekt ‚Inhalt‘

Fehlen die Ermittlung und Beschreibung im erforderlichen Detaillierungsgrad aller relevanten Requirements, sind inhaltliche Mängel vorhanden. Die Überprüfung gilt daher der Einhaltung spezifischer Qualitätskriterien für Anforderungen sowie für Anforderungsdokumente. Die Risiken von Mängeln in diesem Bereich sind eine ungenügende oder falsche Systemumsetzung aufgrund fehlerhafter Informationen bzw. die bereits erwähnten Fehlerfortpflanzungen.

Der Check von Requirements auf inhaltlicher Ebene ist dann erfolgreich, wenn folgende Fehlerarten ausgeschlossen werden können:

• Vollständigkeit der gesammelten Requirements
• Vollständigkeit der einzelnen Anforderungen
• Verfolgbarkeit
• Korrektheit/Adäquatheit
• Konsistenz
• Keine vorzeitigen Entwurfsentscheidungen/Trennung Anforderung & Lösung
• Prüfbarkeit
• Notwendigkeit

Qualitätsaspekt ‚Dokumentation‘

Ob die Dokumentation und Spezifikation der Requirements nach den geforderten Standards und Vorschriften durchgeführt wurde, behandelt der zweite Qualitäts­aspekt. Mögliche negative Folgen bei der Nichteinhaltung dieses Qualitätsaspekts sind, dass die Entwicklung wegen unzulässigen Dokumentationsformaten beeinträchtigt ist, Anforderungen aufgrund mangelnder Klarheit sowie fehlender Informationen nicht nachvollziehbar sind oder Requirements wegen einem falschem Dokumentationsort unauffindbar sind.

Die Überprüfung der Anforderungen auf Darstellungsmängel konzentriert sich auf folgende Punkte:

• Konformität mit Dokumentationsvorschriften (Dokumentationsformat, Dokumentenstruktur, Dokumentationsregeln)
• Verständlichkeit
• Eindeutigkeit

Qualitätsaspekt ‚Abgestimmtheit‘

Mängel in der Requirementsvereinbarung mit den relevanten Stakeholdern sind dann gegeben, wenn kein übereinstimmendes und ‚konfliktbefreites‘ Verständnis aller Beteiligten zu den Requirements vorhanden ist. Dieser Qualitätsaspekt gewährleistet eine vorläufige ‚Fertigstellung‘ der Anforderungen, im agilen Setting die ‚Definition of Ready‘, da zu diesem Zeitpunkt Adaptionen die folgenden Umsetzungstätigkeiten noch nicht beeinflussen.

Die Anforderungen werden dabei dahingehend überprüft:

• Erfolgte Abstimmung

• Erfolgte Abstimmung nach Änderung

• Aufgelöste Konflikte

  1. == Grundsätze der Anforderungsprüfung ==

Ein kontinuierlicher Qualitätssicherungsprozess während des gesamten Analyse­prozesses ist für den Requirements Engineer anstrebenswert. Schließlich soll sich ein an den Qualitätskriterien orientierendes, einheitliches Anforderungsdokument aus den vielschichtigen Informationen und Perspektiven der Stakeholder und Anforderungsquellen erstellen lassen.

Um die Qualität der Überprüfungsergebnisse von Anforderungen zu erhöhen, bewährt es sich, folgende Grundsätze zu berücksichtigen:

• Beteiligung der richtigen Stakeholder

Damit Qualitätsziele auch erreichbar sind, müssen diese frühzeitig definiert und mit allen relevanten Stakeholdern abstimmt sein. Zudem gilt es die Unabhängigkeit der Prüfer sicherzustellen. Ein Prüfer ist nicht die Person, die die Anforderung erstellt hat. Beim Lesen eigener Beschreibungen wird das Vorwissen abgerufen und macht ‚blind‘ für gewisse Fehler. Fehlendes wird unterbewusst ergänzt, Mängel werden überlesen und Unklarheiten, die für andere vielleicht nicht nachvollziehbar sind, fallen nicht auf.

• Prüfung aus unterschiedlichen Sichten

Je nach Blickwinkel einer Rolle bzw. einer bestimmten Person rücken andere Details in den Fokus. Ein Checken aus verschiedenen Perspektiven schafft ein vollständigeres Bild.

• konstruktive und analytische Qualitätssicherung

Schon von Beginn an werden konstruktive Qualitätssicherungsmaßnahmen durchgeführt. Damit ist der Einsatz von Hilfsmitteln und Techniken gemeint, um Auffälligkeiten und Fehler während der Ermittlung und Dokumentierung gar nicht erst aufkommen zu lassen. Anforderungen werden zudem durch analytische Qualitätssicherungsmaß­nahmen begleiten, sobald diese eine gewisse ‚Stabilität‘ vorweisen, um Auffälligkeiten und Fehler in der Dokumentation noch vor der Umsetzungs­phase zu erkennen und zu beseitigen.

• Trennung von Fehlersuche und Fehlerkorrektur

Prüfung und Mängelbehebung werden separiert, da es sich um zwei getrennt zu bearbeitende Abläufe handelt. In diesem Schritt liegt die Konzentration auf dem Aufspüren von Auffälligkeiten und deren Dokumentation, ohne sich bei einer Anomalie ‚festzubeißen‘ und weitere potentiell vorhandene und kritischere Mängel zu übersehen. Nach dem Festhalten besteht die Möglichkeit zu priorisieren und die zur Verfügung stehenden Ressourcen gezielt zum Einsatz zu bringen.

• Geeigneter Wechsel der Dokumentationsform

Wie bereits im Kapitel ‚Anforderungen dokumentieren‘ dargelegt, hat jede Dokumentationsform ihre Stärken und Schwächen. Bei signifikanten Anforderungen zahlt es sich aus einen Wechsel in der Darstellungsform durchzuführen, um Schwächen auszugleichen. Während einer solchen Beschreibungsveränderung zeigen sich häufig Unstimmigkeiten, und Anforderungsmängel können identifiziert und behoben werden.

• Konstruktion von Entwicklungsartefakten

Bei der Eignungsprüfung der Requirements für die Erstellung von Ent­wicklungsartefakten (z.B. Test Cases, Benutzerhandbuch usw.) werden einzelne Entwicklungsaktivitäten beispielhaft umgesetzt. Obwohl diese Herangehensweise äußerst aufwendig ist, lohnt sie sich bei kritischen Anforderungen, denn in der intensiven Auseinandersetzung treten oftmals Mängel wie Mehrdeutigkeit oder Unvollständigkeit zu Tage.

• Wiederholte Prüfung

Das Wissen über das zu erstellende System verändert sich im Entwicklungs­prozess ständig. Deshalb ist es entscheidend, Anforderungen zu unterschiedlichen Zeitpunkten erneut zu überprüfen. Ein mit aktuellem Kenntnisstand durchgeführter, erfolgreicher Check ist keine Garantie, dass ein Requirement im weiteren Projektverlauf ebenso den Qualitätskriterien entspricht. Besonders wenn das geplante System höchst innovativ ist, während des Requirements Engineering ein großer Informationswandel stattfindet oder in Projekten mit langer Laufzeit empfiehlt sich eine mehrfache Prüfung.

Mithilfe des Deming Cycle bietet Chris Rupp einen Qualitätssicherungsleitfaden, der wie ein roter Faden durch die systematische Planung, Durchführung und Reflexion des Qualitätssicherungsprozesses führt. Das in den 1930ern entwickelte iterative vierphasige Prozessmodel für Lernen und Verbesserung umfasst die Schritte Plan, Do, Check und Act, deshalb es auch häufig PDCA-Zyklus genannt wird.

Abb. 14: Phasen des PDCA-Zyklus

Besonders im agilen Umfeld ist dieses Modell ein ständiger Begleiter des Arbeitens und fungiert als essentieller Grundpfeiler der Qualitätssicherung. Das Konzept wird dank seiner schleifenartigen Struktur zur kontinuierlichen Verbesserung, auch innerhalb der Teams für den eigenen Arbeitsprozess, genutzt.

Prüftechniken

Die einzelnen Prüftechniken haben ebenso wie Ermittlungs- bzw. Dokumentations­techniken ihre Vor- und Nachteile und dementsprechend ihre ‚idealen‘ Nutzungs­varianten. Bei der Auswahl von Techniken sind die projektspezifischen Gegeben­heiten sowie die Erfordernisse der jeweiligen Anforderung zu berücksichtigen.

Reviews

Eine der am häufigsten zum Einsatz kommenden Prüftechnik für Anforderungen ist das Review. Folgende Formen lassen sich dabei unterscheiden:

Stellungnahme

Der Autor bittet für eine Stellungnahme eine andere Person, die Anforderung auf deren Qualität hin zu überprüfen. Dafür eignet sich sowohl eine möglichst fachlich kompetente als auch eine analytisch versierte, völlig fachfremde Person. Diese begutachtet die Anforderung und dokumentiert Auffälligkeiten.

Die wenig formale Technik lässt sich unkompliziert und rasch umsetzen. Das ‚Vier-Augen-Prinzip‘ ist besonders gut geeignet, um Lücken und Anomalien aufzudecken, Missverständnisse auszuräumen sowie Unvollständigkeiten zu beheben. Das Prüfergebnis hängt aber beträchtlich von den vorab definierten Prüfkriterien, der vorhandenen Zeit sowie dem jeweiligen Prüfer bzw. dessen Qualitätsbewusstsein ab.

Inspektion

Die Inspektion ist eine systematische, einem festgelegten Ablauf folgende Prüftechnik, für deren Durchführung unterschiedliche Rollen (z.B. Autor, Inspektions­leiter, Inspektoren) auszufüllen sind.

Die typischen Phasen einer Inspektion sind

• Planung (Festsetzen von Bedingungen wie Zielsetzung, Durchführungsart, Auswahl der Inspektoren usw.)
• Übersicht (Abgleichen der Bedingungen zwischen Autor und Inspektoren­gruppe)
• Fehlersuche (Überprüfung der einzelnen Punkte in der Gruppe und/oder einzeln)
• Dokumentation (Sammlung, Abstimmung und Aufzeichnung der Anomalien und Fehler in der Inspektionsgruppe)
• Fehlerkorrektur (Überarbeitung der Requirements)
• Kontrolle (Überprüfung der Korrekturen) und
• Reflexion des Inspektionszyklus.

Oftmals führt die Inspektion zur Erkennung von zahlreichen und vermeintlich unsichtbaren Anomalien bzw. Fehlern. Der formale Charakter der Prüfung ist effizient und sorgt für einen friktionsfreien Verlauf und Prozessstabilität. Das Verfahren erweist sich aus eben diesen Gründen allerdings als zeit- und kostenintensiv und die Erfahrungen des Inspektionsleiters sowie der Inspektoren wirken sich stark auf die Prüfergebnisse aus.

Walkthrough

In einem Walkthrough führt der Autor den bzw. die Prüfer schrittweise durch die zu prüfende Anforderung und erklärt deren Entstehung. Schon in dem Teil entdeckt oft der Autor selbst – durch das ‚laut Denken‘ – Auffälligkeiten und Fehler. Die Reviewer können dann, gegebenenfalls mit Unterstützung eines Moderators, Fragen stellen, Rückmeldungen geben bzw. durch gemeinsame Diskussion Qualitätsmängel aufspüren. Die identifizierten offenen Punkte und Probleme werden protokolliert und in Folge in das Requirement eingearbeitet.

Das Ziel eines Walkthroughs ist ein konsolidiertes Verständnis der Beteiligten bezüglich eines Requirements, um so Qualitätsmängel zu entlarven. Solche Besprechungen dienen der Verbesserung der Kommunikation sowie dem Informationsaustausch. Weiters helfen sie bei Entscheidungsfindungen sowie der Klärung von kleineren Konflikten. Damit Walkthroughs nicht aus dem Ruder laufen, ist es sinnvoll, einen zeitlichen Rahmen sowie Gesprächsregeln festzulegen. Wenn der Autor selbst durch diese Technik leitet, besteht die Gefahr, dass dieser Schwächen der Anforderung ‚versteckt‘. Die Kompetenzen der beteiligten Stakeholder bestimmen auch hier maßgeblich für das Ergebnis der Prüfung.

Prototyp/Simulationsmodell

Ein Prototyp gleicht einer ‚Vorschau‘ auf das gewünschte System oder Systemteile, um Anforderungen für die Prüfer erlebbar zu machen, indem einzelne oder mehrere Requirements zum Teil realisiert werden. Dadurch offenbaren sich zum einen Mängel in der Anforderungsbeschreibung, zum anderen auch Ungereimtheiten in der Funktionsweise des Zielsystems, die sonst erst in der abschließenden Testphase des fertigen Systems zu entdecken wären. Je nach Bedarf gilt es zwischen zwei Arten von Prototypen zu entscheiden: der evolutionäre Prototyp, der weiter gepflegt und verbessert wird, und der Wegwerf-Prototyp.

Die Anschaulichkeit bei komplexen Aufgabenstellungen bzw. für optische, haptische oder akustische Verhaltensweisen des Systems erleichtert gewisse Prüfungs­situationen, z.B. Walkthroughs mit Nutzern, immens. Die Erstellung von Prototypen ist allerdings äußerst zeitintensiv und aufwendig. Gelegentlich bilden sich bei Stakeholdern auch falsche Vorstellungen, wie das gewünschte System sein wird bzw. über dessen Fertigstellungsgrad. Letzteres ist besonders häufig bei Oberflächen­prototypen ohne Funktionalität der Fall, die scheinbar bereits fertig scheinen.

Testfälle

Oftmals kommen Testfälle bereits als Teil der Anforderungsspezifikation zum Einsatz, da sie eine klare Vorstellung vermitteln, wann eine Anforderung ‚gut‘ und ‚fertig‘ ist. Speziell im agilen Umfeld sind grobe Test Cases als Ergänzung zur User Story üblich. Schließlich bilden sie die Grundlage für das Testen des fertigen Systems sowie die Abnahme. Testfallersteller sind in der Regel äußerst gründlich in der Anforderungsprüfung. Der Anforderungsautor und der Ersteller der Test Cases sollten nicht dieselbe Person sein, um eine unvoreingenommene Prüfung zu gewährleisten.

Praktisch bei der Anforderungsprüfung mit Testfällen ist, dass diese im Testing weiterverwendet werden können. Der Wechsel der Darstellungsform bzw. das ‚4-Augen-Prinzip‘ machen viele Mängel sichtbar, weshalb Testfälle eine hohe ‚Erfolgsquote‘ beim Erkennen von Anomalien haben. Ihre Erstellung ist aber sehr zeitintensiv und meist nicht ohne umfassendes Knowhow bzw. Erfahrung möglich. Außerdem lassen sich nicht alle Qualitätskriterien (z.B. Notwendigkeit oder Konsistenz) damit abfragen.

Hilfsmittel bei der Prüfung

Zusätzlich zu den diversen Prüftechniken, aus denen jeweils die richtige zu wählen ist, kommen auch in Techniken eingesetzte Hilfsmittel zum Einsatz, um möglichst alle signifikanten Mängel vor der Umsetzung zu beheben.

Lesetechniken

Unter anderem in Reviewtechniken werden verschiedene Lesetechniken mit jeweils unterschiedlichem Fokus genutzt. Beispiele sind hierfür das Ad-hoc-Lesen, das ablauforientierte Lesen oder die schrittweise Abstraktion. Hilfreich beim Prüfen von Anforderungen ist auch das perspektivenbasierte Lesen, das sich multiplen Sichtweisen bedient, um eine umfassende, möglichst vollständige Darstellung zu erreichen. Möglichkeiten sind dafür ein Check aus dem jeweiligen Blickwinkel der Adressaten (z.B. von Kunde/Nutzer, Softwarearchitekt, Tester), der drei Qualitätsaspekte oder anderen vorstellbaren Perspektiven des spezifischen Projektkontexts.

Checklisten

Wenn bei einem komplexen Sachverhalt viele Aspekte berücksichtigt werden müssen und möglichst kein Aspekt vergessen werden soll, werden meist Checklisten eingesetzt. Neben vorgefertigten Checklisten in der Literatur oder im Internet, eignen sich als Quellen zur Erstellung eigener Listen z.B. die drei Qualitätsaspekte, die Qualitätskriterien für Anforderungsdokumente bzw. die jeweiligen Anforderungen, Fehlerstatistiken sowie die Erfahrung der Prüfer. Checklisten sollten dennoch nicht unreflektiert übernommen, sondern für den spezifischen Anwendungsfall angepasst werden.

Anforderungsschablone

Eine Vorlage für Anforderungen mit vorgefertigten Platzhaltern, die befüllt werden müssen, bietet beinahe eine Qualitätsgarantie für Anforderungen von Anfang des Generierungsprozesses an. Alle Stakeholder bekommen bereits einen festgelegten ‚Bauplan‘ für die Beschreibung von Requirements in die Hand, was die Einheitlichkeit und Vollständigkeit generell verbessert. Anhand einer solchen Schablone können Anforderungen auf viele Kriterien relativ leicht geprüft werden.

Abstimmung von Anforderungen

Projekte versammeln in der Regel unzählige Stakeholder, deren Anforderungen sich nicht immer decken. Die Abstimmung von verschiedenen Sichtweisen in der Anforderungskonsolidierung macht Widersprüche und Unstimmigkeiten sichtbar. Die Bandbreite geht dabei von fachlichen Auseinandersetzungen über gruppen­dynamische, eventuell projektpolitische Differenzen bis hin zu persönlichen Konflikten. Die Klärung einiger davon liegt in der Verantwortung des Requirements Engineer, andere lassen sich nur mit der Unterstützung von Spezialisten für Konflikt­management und Mediation lösen.

Um das geplante System zu realisieren, ist es notwendig, mit diesen Konflikten umzugehen. Denn die Absicht der Konsolidierung von Anforderungen ist es, ein gemeinsames, übereinstimmendes Verständnis der Requirements sowie einen realistischen Projektplan zu entwickeln, der ein für alle Stakeholder annehmbares Resultat ermöglicht.

Unbehandelte Konflikte gefährden das Projekt, weil die Akzeptanz des geplanten Systems dann meist nicht von allen Seiten gewährleistet ist. In der Praxis reiben sich Anforderungen wie Funktionalität, Performance sowie andere Systemcharakteristika fast immer mit den Vorstellungen bezüglich Kosten und Zeit. Wenn die Requirements mindestens eines Stakeholders nicht im geforderten Maß berücksichtigt werden oder ein ‚fauler‘, weil unbewusst eingegangener Kompromiss entsteht, kommt es zu einem ungelösten Konflikt. In dessen Folge unterstützt der betroffene Stakeholder das Projekt nicht weiter, was letzten Endes sogar zum Scheitern des Gesamtprojekts führen kann.

Konflikte sind aber immer auch eine Chance. Besprochene widersprüchliche Bedürfnisse und Wünsche können zu Lösungen führen, die gänzlich neue Ideen erfordern und ursprünglich ungeahnte Möglichkeiten hervorbringen. Die erfolgreiche Bearbeitung von Konflikten erhöht die Identifizierung mit dem Entwicklungsprojekt und damit die Annahme des Systems durch die Stakeholder, weil sie tiefer in die Materie eintauchen müssen. Ebenso ist die Auseinandersetzung mit Konflikten ein Motor für Innovation, denn heterogene, sich widersprechende Gruppen erzeugen die besten Ideen, auch wenn der Prozess zu Ergebnissen vielleicht anstrengender erscheint.

Die Validierung und Vereinbarung von Anforderungen passiert fortlaufend über den gesamten Entwicklungsprozess. Die jeweilige Intensität variiert, dennoch erzeugen diese Aktivitäten Aufwände, vor denen Unternehmen und ihre Mitarbeiter immer wieder zurückschrecken. Die Vorteile einer kontinuierlichen Prüfung und Konsolidierung, unter anderem nachhaltige Kostenersparnis, klar definierte und fehlerfreie Anforderungen, höhere Akzeptanz des geplanten Systems, innovativere Systeme, überwiegen in der Praxis bei weitem.

Was ist ein Konflikt?

Bezeichnender Weise besteht keine Einigkeit, was die Definition des Begriffs ‚Konflikt’ betrifft. Im Requirements Engineering verstehen wir unter einem Konflikt eine Unvereinbarkeit zwischen Anforderungsquellen (Stakeholder, Dokumente usw.) oder zwischen einer oder mehrerer Anforderungen des gewünschten Systems. Dem zugrunde liegen widersprüchliche Wahrnehmungen sowohl objektiver, als auch emotionaler Natur.

Beim Konfliktgegenstand handelt es sich im Requirements Engineering grundsätzlich um eine oder mehrere Anforderungen. Die Konfliktursachen sind hingegen facetten­reich. Nicht außer Acht zu lassen sind dabei soziale Konflikte, die parallel zu Konflikten zwischen Anforderungen in jedem Projekt auftreten können. Diese gehören nicht unbedingt in den Verantwortungsbereich des Requirements Engineer, allerdings hat sich in der Praxis ein gewisses Fingerspitzengefühl in der Rolle als zielführend erwiesen, um angemessen auf auftretende Differenzen zwischen Projektbeteiligten reagieren zu können. Soziale Konflikte sind ein enormes Risiko für Projekte und gefährden bei einer Eskalation auch die Resultate, für die Requirements Engineers beurteilt werden. Es empfiehlt sich also für Anforderungsmanager, auch in diesem Bereich Knowhow aufzubauen und schließlich folgende Haltung sowie Kompetenz zu erreichen: „To practise the process of conflict resolution, we must completely abandon the goal of getting people to do what we want.“

Erfolgreiches Konfliktmanagement heißt Maßnahmen zur Prävention einer Eskalation oder einer Ausweitung eines bestehenden Konflikts auswählen und durchführen zu können, mit dem vorrangigen Ziel einer systematischen Beschäftigung mit Konflikten zur Minimierung der verursachten Auswirkungen und Kosten. Ein Konflikt im Requirements Engineering gilt als gelöst, wenn sich die Stakeholder über kontroverse Requirements klar und einig sind.

Konfliktidentifikation

In allen Aktivitäten des Requirements Engineering und in jeder Projektphase können Konflikte ‚auftauchen‘. Aus verschiedensten Gründen sind sie manchmal unüber­sehbar, in anderen Situationen nicht augenscheinlich und sogar verborgen. Hinweise finden sich in der Kommunikation, weshalb für einen Requirements Engineer die Kompetenz des Zuhörens entscheidend ist. Die Fähigkeit, Zwischentöne wahrnehmen und sichtbarmachen zu können, unterscheidet einen herausragenden von einem durchschnittlichen Anforderungsmanager. Dabei geht es unter anderem darum, zu erkennen, wenn Projektbeteiligte verschiedene Begrifflichkeiten für Dasselbe oder einen Begriff mit unterschiedlichen Bedeutungen einsetzen. Auch ‚Reibereien‘ zwischen Stakeholdern, die sich wechselseitig unterbrechen und/oder korrigieren bzw. emotionale Ausbrüche, sollten aufgegriffen werden. Ebenso der Umgang mit Beteiligten, die sich schlagartig an eigene Aussagen nicht mehr erinnern können (Blitzverblödung) oder unangemessen viele Berichte fordern (Reportismus), will geübt sein.

Unstimmigkeiten zu Anforderungen finden sich auch in schriftlichen Quellen. Das Glossar kann dem Requirements Engineer dabei eine große Hilfe sein, vor allem bei unterschiedlichen Bezeichnungen. Grundbegriffe, die scheinbar allen vertraut sind, können eine beachtliche Interpretationsbreite umfassen. Hier eignen sich Reviews, Analysemodelle und Prototypen, mit deren Hilfe Abläufe mit mehreren Beteiligten durchgegangen werden können und so verschiedene Sichtweisen offenkundig machen.

Je früher Unstimmigkeiten entdeckt werden, desto eher können sie gelöst werden und desto weniger Folgeschwierigkeiten ziehen sie nach sich. Die Erkennung des Konflikts ist der größte Schritt, um diesen aus der Welt zu schaffen.

Konfliktanalyse

Wenn ein Requirements Engineer einen Konflikt wahrnimmt, liegt es an ihm, zuerst die eigene Haltung zu überprüfen. Nur mit einer neutralen Einstellung ist es möglich, der Ursache eines erkannten Konflikts auf den Grund zu gehen. Dafür sind Selbstreflexion zum persönlichen Konfliktverhalten und -umgang essentiell. Sonst läuft er Gefahr eigene Muster auf die Konfliktparteien zu projizieren und sich selbst in die Konfliktsituation zu verstricken.

Die Analyse eines Konflikts ist ein notwendiger Schritt für die folgende Auflösung. Dabei geht es unter anderem um die Bestimmung der Konfliktart sowie die Klärung des Anteils der Sachebene. Erst mit diesem Wissen ist es sinnvoll, über die weitere Vorgangsweise zu entscheiden. Bei einem Anforderungskonflikt mit hohem sachliche Anteil liegt die Lösung mit den Beteiligten in der Regel in der Verantwortung des Requirements Engineer. Wenn unverkennbar die Beziehungs­ebene involviert ist, erfolgt zuerst der Versuch die Ebenen zu trennen und den sachlichen Teil isoliert vom sozialen Konflikt zu klären. Steht der soziale Konflikt im Vordergrund und der Anforderungskonflikt ist unter Umständen nur ‚Platzhalter‘ für diesen, empfiehlt es sich die Unterstützung eines unabhängigen Experten heranzuziehen.

Bevor sich ein Requirements Engineer unüberlegt an die Lösung eines Konflikts wagt, ist es ratsam diesen erst in Ruhe zu analysieren. Ein einmal eskalierter Konflikt lässt sich wesentlich schwieriger wieder ‚einfangen‘, als eine Eskalation von vornherein zu verhindern. Als hilfreiches Analysetool empfiehlt Chris Rupp dazu den Konflikt­steckbrief, der eine systematische Herangehensweise fördert und bei der Dokumentation des Konflikts unterstützt.

Abb. 15: Konfliktsteckbrief

Zu Beginn hält der Requirements Engineer in diesem Dokument fest, worüber Unstimmigkeit herrscht: die strittige Anforderung, eine zugrundeliegende ‚Ursache‘ oder die hinter den Requirements versteckten Interessen. Im Laufe einer Auseinandersetzung mit einem Konflikt, vor allem bei Beziehungskonflikten, erweist sich manchmal der zu Beginn benannte Konfliktgegenstand als ‚Deckmantel‘ für einen anderen Konflikt, weshalb es notwendig ist, das an dieser Stelle niedergeschriebene immer wieder zu überprüfen.

‚Zum Streiten gehören immer zwei!‘ heißt es im Volksmund. In der Praxis sind mindestens zwei Parteien in einen Konflikt involviert, möglicherweise sogar mehr. Diese Konfliktbeteiligten gilt es, möglichst konkret zu identifizieren, d.h. idealerweise einzelne Personen namentlich festzuhalten. In der Analyse sammelt der Requirements Engineer Hintergrundinformationen zu diesen, die er mit der Stakeholderliste referenziert. Wenn dabei bestimmte strukturelle Relationen ins Auge fallen, u.a. bestimmte Machtverhältnisse, ist dies ein Hinweis auf einen Struktur­konflikt. Auch die Konflikthistorie sollte dabei berücksichtigt werden: entstanden die Differenzen zwischen den Stakeholdern aus einem ‚Erstkontakt‘ oder besteht bereits eine längere ‚Vorgeschichte‘? Menschliches Konfliktverhalten nimmt äußerst unterschiedliche Facetten an, von zurückhaltend bis aggressiv mit allen Zwischen­stufen. Empfehlenswert ist es, dies bei den einzelnen Parteien einzuschätzen, auch wenn es sich dabei klarerweise um eine Mutmaßung handelt. Dennoch erlaubt diese möglicherweise hilfreiche Rückschlüsse auf die Konfliktfähigkeit bzw. Lösungs­kompetenz von Konfliktteilnehmern.

Für das Ermitteln der Konfliktpositionen greift der Requirements Engineer, wenn möglich, auf die Befragung der Konfliktbeteiligten zurück. Deren Schilderung bietet eventuell schon Anhaltspunkte für Lösungsmöglichkeiten bzw. erlaubt in manchen Fällen, z.B. bei fachlichen Missverständnissen, dass der Konflikt bereits an dieser Stelle bereinigt werden kann.

Für die Analyse des Konflikts ist außerdem die Konfliktart entscheidend, wobei diese sich in der Praxis meist überschneiden. Eine gängige Auflistung ist die von Christopher W. Moore, der fünf verschiedene Konflikttypen unterscheidet:

• Sachkonflikt

Ein Sachkonflikt ist dann vorhanden, wenn sich Stakeholder zwar das Ziel betreffend einig sind, jedoch nicht über die dafür nötige Vorgehensweise oder die erforderlichen Mittel. Auch unterschiedliche Interpretation von Daten, Einschätzungen von Gegebenheiten oder Prioritäten sowie mangelnde oder falsche Informationen führen zu einem Sachkonflikt. Eine Unterform ist hier der Benennungskonflikt, wenn Konfliktparteien ein und denselben Begriff für unterschiedliche Dinge verwenden.

• Interessenskonflikt

Interessenskonflikte sind durch angenommene oder tatsächlich abweichende Interessen oder strategische Ziele der Stakeholder verursacht. Oftmals kommt dies aufgrund von Rollen, welche die Konfliktparteien innehaben und für deren Bedürfnisse und Wünsche sie Verantwortung tragen, zu Stande. Meist sind Interessenskonflikte sachlich mit Argumenten zu klären, außer es handelt sich um eine Vermischung von Konfliktarten, in dem Fall am häufigsten mit Wertekonflikten.

• Wertekonflikt

Aufgrund unterschiedlicher Einstellungen und Wertesysteme in Projekten entwickeln sich potentiell Wertekonflikte. Beeinflusst werden solche unter anderem vom jeweiligen kulturellen Background, dem Bildungsniveau und der Bildungsausrichtung, der Lebenserfahrung sowie individuellen Über­zeugungen. Dabei besteht durchaus das Risiko, dass Wertekonflikte über die sachliche Ebene hinausgehen und sich, infolge der persönlichen Betroffenheit einer oder mehrerer Konfliktparteien, mit den Möglichkeiten eines Requirements Engineer nicht mehr lösen lassen.

• Beziehungskonflikt

Beziehungskonflikte ergeben sich häufig aus wiederholten negativen Erfahrungen zwischen einzelnen Personen und/oder Unstimmigkeit über soziale und strukturelle Relationen. Für Beziehungskonflikte ist es bezeichnend, dass meist wenig bis keine Kommunikation zwischen den Streitparteien mehr stattfindet, Widersprüche und Stereotype überdeutlich wahrgenommen werden sowie offenkundig wenig Interesse besteht, die Probleme auszuräumen. Diese Konfliktart tritt oftmals zuerst unerkannt hinter Sach- oder Interessenskonflikten auf und lässt sich als Requirements Engineer nur insofern klären, wenn noch ein Sachanteil separiert und als solcher aufgelöst werden kann.

• Strukturkonflikt

Durch ungleiche Macht- und Autoritätsverhältnisse sind Strukturkonflikte bedingt, die häufig Ressourcenstreitigkeiten bzw. destruktive Verhaltens- und Interaktionsmuster nach sich ziehen. Ebenso wie für Beziehungskonflikte ist für die Lösung von Strukturkonflikten, außer der Extraktion des Sachanteils, die Zuhilfenahme von professioneller Unterstützung empfehlenswert.

Weitere Unterstützung beim Erkennen des Konflikttyps bietet das bereits genannte Kommunikationsquadrat von Schulz von Thun.

Im Konfliktsteckbrief finden sich außerdem die bereits eingetretenen Folgen des Konflikts. Üblicherweise handelt es sich dabei um widersprüchliche Requirements, die bei mangelhafter Prüfung aber bereits zu einem fehlerhaften System geführt haben können.

Um die Priorität eines Konflikts und seiner Bearbeitung einschätzen zu können, ist es notwendig das Risiko zu analysieren. Manche Konflikte stellen keine akute Gefahr dar und können unter Beobachtung vertagt werden. Andere müssen umgehend bearbeitet werden, um das Projekt keinen gravierenden Beeinträchtigungen auszusetzen. Möglicherweise verhindert der Konflikt jegliches konstruktive Arbeiten zwischen Stakeholdern oder blockiert die nächsten Entwicklungsschritte.

Konfliktursachen zu ergründen, kann äußerst herausfordernd sein, weil diese oft komplex und viele Aspekte ineinander verwoben sind. Ursprünglich angenommene Ursachen entpuppen sich vielleicht nur als Auswirkungen, versteckte Konfliktaspekte kommen erst nach intensiver Auseinandersetzung damit ans Licht. Um in der Analyse von und schließlich im Umgang mit Konflikten noch besser gerüstet zu sein, empfiehlt sich auch die Beschäftigung mit dem Konflikteskalationsmodell bzw. der Konfliktfieberkurve .

Konfliktauflösung

Eine umfassende Konfliktanalyse ist eine gute und oftmals essentielle Vorbereitung für die Auflösung eines Konflikts. In manchen Situationen empfiehlt es sich, mit einer Eindämmung des Konfliktes zu beginnen und zuerst eine Atmosphäre zu gestalten, in der der Konflikt zwar nach wie vor vorhanden ist, sich aber nicht mehr weiter ausbreitet. Eine neutrale, unvoreingenommene Haltung hinsichtlich Stakeholdern und Anforderungen ist eine grundlegende Voraussetzung für eine professionelle Konfliktbewältigung, die das Leben als Requirements Engineer erheblich erleichtern kann.

Wie ein Konflikt aufgelöst wird, beeinflusst die weitere Kooperationsbereitschaft der involvierten Stakeholder. Unabhängig von der jeweiligen Lösungstechnik ist es wichtig, alle Konfliktparteien an der Lösung zu beteiligen. Anderenfalls werden Perspektiven außer Acht gelassen bzw. fühlen Menschen sich ausgeschlossen. Dadurch lässt sich bestenfalls eine Teillösung erzielen, unter Umständen verschlimmert eine solche Herangehensweise sogar die Situation.

Konsolidierungstechniken

Das Ziel von Annäherungsmethoden ist es, gemeinsam mit den involvierten Konflikt­parteien einen Anforderungskonflikt zu klären. Diese Techniken sind aufwendig, die Ergebnisse allerdings häufig nachhaltig, da sich die betroffenen Stakeholder einbringen können.

• Einigung

Wenn die Bereitschaft zur Kooperation vorhanden ist können die Konflikt­beteiligten dialogisch eine Lösung aushandeln. Dabei kommt es unter Berücksichtigung aller Aspekte der Betroffenen zu einem Austausch von Informationen, Argumenten und Meinungen. Entscheidend sind die Fähigkeit, den Blickwinkel Anderer einnehmen zu können, sowie die jeweilige Überzeugungskraft. Am Ende steht eine Einigung auf eine Lösungs­alternative, z.B. eine Anforderungsbeschreibung.

• Kompromiss

Auch der Kompromiss erfordert eine kooperative Haltung. Dabei erzielen die Parteien in einem bestimmten Bereich eine Teileinigung, die weder das eine, noch das andere, sondern ein Drittes ist. Idealerweise beinhaltet sie eine Kombination der Vorzüge beider Varianten und völlig neue, kreative Lösungen sind möglich. Ein schlechter Kompromiss provoziert bei den Involvierten Unzufriedenheit und Folgekonflikte sind wahrscheinlich. Von einem faulen Kompromiss ist die Rede, wenn der größte Teil des Konflikts ungelöst bleibt.

• Variantenbildung

In diesem Fall gibt es keine Kooperation und der Konflikt wird umgangen. Manchmal ist die einzige zielführende Lösung, für jede Partei eine eigene Lösung zu erstellen. Dafür entstehen Systemvarianten durch Abwandlung und Kombination der Parameter in den jeweiligen Requirements, bis sie den unterschiedlichen Anforderungen der Stakeholder genügen.

Abstimmungs- und Weisungsmethoden kommen dann zum Einsatz, wenn eine rasche Entscheidung erforderlich ist und keine Chance zur Kooperation und Annäherung besteht.

• Ober-sticht-Unter

Die Entscheidung erfolgt durch die organisatorische Hierarchie, d.h. der höherrangige Stakeholder weist eine Lösung an oder bei ‚Gleichstand‘ die Delegation an der höheren Stelle. Diese Technik mit diktatorischer Lösungsfindung wird häufig als Last-Exit-Strategie genutzt, birgt allerdings den Vorteil, dass aufgrund der hierarchischen Gegebenheiten auch klare Verantwortlichkeiten gegeben sind.

• Abstimmung

Involviert der Konflikt viele Stakeholder, bietet sich eine demokratische Konfliktlösung durch Abstimmung an. Dabei werden den Beteiligten alle Informationen in einer Vorlage zugänglich gemacht, auf deren Basis durch ein geheimes oder offenes Votum die Mehrheit der Stakeholder eine Lösung bestimmt. Ungeeignet ist diese Methode bei Lagerbildung (z.B. Finanzen vs. Vertrieb) sowie sehr komplexen Themen, deren Details nicht umfassend allen Parteien nahegebracht werden können. Zudem besteht die Gefahr der Patt-Situation, für die bereits vor der Abstimmung eine Vorgangsweise festgelegt werden sollte.

Unterstützende Konsolidierungstechniken versuchen einerseits über eine analytische Herangehensweise, die Komplexität eines Konflikts zu zerlegen und überschaubarer sowie objektiver darzustellen. Andererseits bieten sie zwischenmenschliche Kommunikationspsychologische Ansätze, eine Auflösung herbeizuführen.

• Plus-Minus-Interesting

In einer klassischen Plus-Minus-Liste werden alle positiven und negativen Folgen der zur Wahl stehenden Lösungsansätze aufgelistet. Neutrale Auswirkungen oder Folgen, die noch nicht beurteilt werden können und gegebenenfalls weiter analysiert werden müssen, finden in der Kategorie ‚Interesting‘ ihren Platz.

• Consider-all-Facts (CAF)

Für diese Technik erfolgt zuerst die Sammlung möglichst aller Einfluss­faktoren, die im Anschluss nach ihrer Relevanz priorisiert werden. Auf dieser Grundlage kann nun entweder eine Entscheidung getroffen oder die Plus-Minus-Interesting-Methode angewandt werden.

• Entscheidungsmatrix

Aus einer Aufstellung aller Lösungsalternativen in den Spalten und den relevanten Entscheidungskriterien in den Zeilen ergibt sich eine Tabelle zur Konfliktauflösung. Daraufhin kommt es zur Bewertung pro Kriterium sowie eventuell einer Gewichtung. Die Entscheidung findet die über Spaltensummen bzw. die Punktewertung der jeweiligen Kombinationen statt.

• Kommunikations- und Fragetechniken

Als Requirements Engineer empfiehlt es sich wärmstens, Kommunikations- und Fragetechniken zur alltäglichen Toolbox zählen zu können. Zurückgreifen lässt sich unter anderem auf im systemischen Coaching übliche oder die von Marshall B. Rosenberg in der gewaltfreien Kommunikation dargelegten.

• Verhandlungstechniken

Auch Verhandlungstechniken sollten zum Repertoire eines Anforderungs­managers gehören. Bei der Suche nach dem geringsten Übel legen Stakeholder solange die strittigsten und damit ‚übelsten‘ Anforderungen ab, bis eine ‚(er)tragbare‘ Lösung übrigbleibt. Auch die Anwendung des bekannten Harvard-Prinzip kann in Konfliktsituation hilfreich sein.

Dokumentation der Anforderungskonsolidierung

Wenn der Anforderungskonflikt schließlich ausgeräumt und mit allen Konfliktparteien abgestimmt ist, erfolgt das schriftliche Festhalten der Konfliktsituation durch den Requirements Engineer.

Einerseits geht es dabei darum, die Nachvollziehbarkeit des Prozesses für die Involvierten bzw. auch für Außenstehende zu gewährleisten. Andererseits bietet die Dokumentation die Möglichkeit, besonders in langfristigen Projekten, zu einem späteren Zeitpunkt eventuell in Vergessenheit geratene Details des Konfliktverlaufs in Erinnerung zu rufen. Weiters beugt die Protokollierung vor, dass Konflikte sich wiederholen bzw. lassen sie sich abkürzen, wenn Unterlagen zur Analyse und Lösung bereits vorhanden sind. Heikle Anforderungen tendieren dazu, immer wieder Spannungen zwischen Stakeholdern oder mit anderen Requirements hervorzurufen, weshalb es sich auszahlt, eine einmal geklärte Konfliktschlichtung sowie die daraus resultierenden Erkenntnisse in der Spezifikation zu vermerken.

Falls im Zuge eines Projekts Zweifel an der Art und Weise der Konfliktauflösung entstehen oder Mängel festgestellt werden, unterstützt eine adäquate Dokumentation den Requirements Engineer, berechtigte von unangemessenen Beanstandungen zu trennen. Auch wenn eine Konfliktauflösung neu aufgerollt werden muss, ist die vorhandene Dokumentation hilfreich für die wiederholte Analyse und Abstimmung. Sonst kann lange Zurückliegendes leicht unbemerkt bleiben und eventuell Schwierigkeiten bei der Konfliktlösung bewirken.

=
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