Requirements Engineering and Cost Estimation - Anforderungen prüfen

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.

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.

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.