Die größten Hindernisse im Requirements Engineering

Requirements Engineering ist einfach und schwierig zugleich. Eigentlich geht es nur darum, Anforderungen von allen Beteiligten und Betroffenen – den Stakeholdern – zu ermitteln und daraus eine konsistente, qualitätsgesicherte Anforderungsspezifikation zu erstellen. Seine allgemeinen kommunikativen Fähigkeiten, analytische Präzision und gesunder Menschenverstand leiten den Anforderungsanalysten durch die Vielfalt an Methoden, Techniken und Praktiken des Requirements Engineerings. Aus Erfahrung und Fehlern lernt er und erbringt immer zielgenauer immer bessere Ergebnisse.

Trotzdem stellt sich in der Praxis immer wieder heraus, dass Anforderungsspezifikationen nicht nur Kommafehler enthalten, sondern schlichtweg das Thema verfehlen. Wesentliche Bedürfnisse werden nicht bekannt, Basisfunktionalitäten nie vorgesehen, unrealistische Erwartungen geweckt, ein zu komplexes System mit unnötigen Spielereien geplant, die Realität nicht korrekt abgebildet und nicht funktionstüchtige Geschäftsprozesse entworfen.

So etwas passiert nicht nur, wenn man die bekannten Best Practices des Requirements Engineering ignoriert. Wer nicht fragt, erhält auch keine Informationen. Wer sich nicht um eine frühzeitige, kompetente Machbarkeitsanalyse bemüht oder ohne Validierung durch die Zielgruppe eine eierlegende Wollmilchsau-Software entwirft, geht ein unkalkulierbares Risiko ein.

Aber man kann auch formal alles richtig machen und trotzdem inhaltlich daneben liegen. Bei einem Arbeitsprozess und einer Anforderungsspezifikation sind Form und Inhalt nicht automatisch gleich gut. Ohne einen sauberen Arbeitsprozess ist die Qualität des Ergebnisses Zufallssache, wenn auch nicht völlig unmöglich. Der perfekte Prozess sichert jedoch manchmal nur die Form, nicht den Inhalt; er schafft die Chance zur perfekten Spezifikation, aber keine Garantie dafür.

Zwei massive Schwierigkeiten der Praxis tauchen in Requirements Engineering Lehrbüchern kaum auf:

1. Nicht für jeden Stakeholder ist der Projekterfolg das oberste Ziel.
2. Sind denn auch alle Beteiligten kompetent genug für ihre Aufgabe?

 

Will jeder den Erfolg des Projekts?

Es ist ein Tabuthema, dass es in Projekten Stakeholder gibt, denen der Projekterfolg gleichgültig ist oder die ihn sogar ablehnen. Jeder verfolgt im Berufsleben auch eigene Ziele, manche sogar ausschließlich. Und bei welchem Projekt gibt es nur Gewinner? Oder in welcher Firma spielen nicht verschiedene Mannschaften gegeneinander? Manche versenken absichtlich ein Projekt, nur um jemandem eins auszuwischen, der ihnen karrieremäßig im Wege steht oder stehen könnte.

Genau darum macht der Profi eine Stakeholderanalyse. Dabei erfasst er nicht nur Namen und Telefonnummern, sondern liest auch zwischen den Zeilen, bekommt beim Rauchen oder Spazierengehen den einen oder anderen Tipp über diejenigen, die gegen das Projekt hetzen, sammelt Informationen über die Vorgeschichte und behält die Kritiker im Auge. Auch das Bauchgefühl weist auf Unstimmigkeiten hin.

Auch und gerade in einem politisch schwierigen Umfeld ist es die Aufgabe des Requirements Engineerings, von allen (!) Stakeholdern frühzeitig ihre wahren Absichten und Bedürfnisse zu erheben und eine Lösung für Konflikte zu finden. Hier ist es schwieriger. Gerade im Gruppen-Workshop kommen dann nicht alle Meinungen auf den Tisch. Einzelgespräche sind besonders dann ergiebig, wenn man das Vertrauen der Stakeholder erwirbt und inoffizielle Tipps entweder als vertrauliche Zusatzinformation behandelt oder zumindest deren Quelle schützt. Nach meiner Erfahrung reden sogar Projektsaboteure oft ganz gerne über ihre Gedanken und Befürchtungen. Gutes Zuhören und Nachfragen ist also eine wichtige Tugend im Requirements Engineering.

Ein Beispiel: Ich erfuhr nie, was dieser Mitarbeiter gegen das Projekt hatte. Er war schlichtweg zu beschäftigt, um mit mir zu sprechen. Ich telefonierte ihm zwei Wochen lang vergeblich hinterher, mehrmals pro Tag. Leider galt diese Person als die zentrale Quelle für technische Fakten, und allmählich wurde es dringend, gewisse Fragen von ihm beantwortet zu bekommen. Da beim Auftraggeber jeder davon ausging, er unterstütze das Projekt, sah es so aus als sei ich unzuverlässig und habe vergessen ihn zu kontaktieren. Indizien für eine Projektsabotage hätte ich nicht nennen können, konnte also auch nicht offiziell um einen anderen Ansprechpartner bitten. Auch als mir seine abweisende Art am Telefon deutlich wurde. Er fand nie Zeit für ein richtiges Gespräch und vergaß auch stets, die versprochenen Dokumente zu senden. Letztlich gibt es aber selten wirklich nur eine einzige Person mit Zugang zu den kritischen Fakten. Ich telefonierte mich also durchs Rechenzentrum und trug die nötigen Informationen mit Hilfe von mehreren hilfsbereiten Menschen zusammen, die entweder Zugriff darauf hatten oder ihren Kollegen einfach darum bitten konnten. Hartnäckigkeit ist bei so etwas immer hilfreich, denn meist wagt der Bremser doch nicht, in seiner Projektsabotage zu offensichtlich vorzugehen. Bei so einer Geschichte bleibe ich natürlich immer freundlich und mache ein unschuldiges, ahnungsloses Gesicht. So bleibt dem Saboteur der Weg zurück ins Team immer noch offen.

Fallstudien über Projektsaboteure finden Sie hier:

• Kottemann und Gietema: Das kleine Handbuch für den Projektsaboteur (Fallstudien aus der Praxis)
• Johann Rost: Political Reasons for Failed Software Projects (Bericht über eine Studie zu subversiven Stakeholdern)
• Johann Rost, Robert L. Glass: The Dark Side of Software Engineering: Evil on Computing Projects

Sind alle kompetent genug?

Natürlich sind alle Projektbeteiligten kompetent in irgendetwas, aber nicht unbedingt in der anstehenden Aufgabe. Das Requirements Engineering und dessen Teilaufgaben sind dermaßen komplex und voller Fußangeln, dass man auch bei bester Absicht erstaunlich viele Fehler machen kann. Gerade hier wird man durch Erfahrung klüger. Ohne Erfahrung ist man leider noch nicht so richtig gut. Da der Requirements Engineer derjenige ist, der den Prozess der Anforderungssammlung steuert, antreibt und überwacht, muss hier eine mit allen Wassern gewaschene Person her. Nicht nur Projektsaboteure, sondern auch die Komplexität der Aufgabe an sich erfordern einen souveränen Schachspieler, der mehrere Züge im Voraus überblickt. Fragen, die der Requirements Engineer nicht stellt, werden höchstwahrscheinlich nicht beantwortet, Konflikte, die er nicht entdeckt, lösen sich nicht von selbst und so weiter. Inhaltliches Wissen über die Anwendungsdomäne oder die verwendete Technologie sind weniger entscheidend, denn das tragen Experten bei. Vielmehr muss er das Handwerkszeug des Requirements Engineering und Stakeholdermanagements beherrschen.

Apropos Experten: Sowohl auf der Seite des Auftraggebers als auch auf der Seite des Auftragnehmers tragen zahlreiche Fachleute ihr Wissen zu dem Projekt bei. Die einen kennen die zu unterstützenden Geschäftsprozesse aus dem Effeff, andere können schon frühzeitig erfreulich (oder erschreckend) genau die Kosten einer Funktion vorhersagen oder scheinbar unlösbare technische Probleme bändigen. Manchmal gerät der Berater aber auch an Ansprechpartner, die selbst nicht ganz verstehen, wie sie zu dieser Aufgabe gekommen sind. Das Wichtigste ist, diesen Menschen nicht zu überfordern und eher als Vermittler zu nutzen. Hoffentlich kennt er seine eigenen Grenzen und behauptet nicht in überzeugendem Ton Dinge, von denen er keine Ahnung hat. Sicherheitshalber sollte der Berater stichprobenartig Behauptungen und Einschätzungen quer checken, also noch eine weitere Person dazu befragen. Es lässt sich ja fast alles anhand von Dokumenten, Gesprächen und Prototypen überprüfen. Besser man merkt es möglichst früh, wenn einem Irrtümer aufgetischt wurden.

Problem- und Lösungsräume im Requirements Engineering

Idealerweise sollte man sich mit Ansprechpartnern nur über die Bereiche austauschen, in denen sie kompetent sind. Hier hilft eine Unterscheidung zwischen Problem- und Lösungsraum. Grob gesagt kennt sich die Auftraggeber- bzw. Fachseite mit dem zu lösenden Problem aus, z. B. zu unterstützende Geschäftsprozesse, zu verwaltende Daten, einzuhaltende Gesetze. Technische Lösungen oder Benutzeroberflächendesign können diese aber nicht entwerfen. Trotzdem versuchen sie es gelegentlich. Das sollten sie schön den Auftragnehmern und Technikexperten überlassen. Besonders wichtig ist die Trennung zwischen Problem- und Lösungsraum bei der Neuentwicklung von Software auf der grünen Wiese. Da stehen technisch noch alle Möglichkeiten offen. Um diese nutzen zu können, darf die Fachseite erstmal nur das Problem vorgeben.

Gerne wird, um Zeit und Geld zu sparen, gar nicht der Endbenutzer befragt oder nicht alle Nutzergruppen. Stattdessen wendet man sich an einen Stellvertreter, im Englischen auch Proxy User genannt, neuerdings auch Product Owner. Man erwartet, dass diese eine Person die Anforderungen aller anderen Stakeholder liefern kann. Doch ist das wirklich so?

Ein Beispiel: In einem Workshop erklärte der Chef, mit welchem Arbeitsprozess in der Firma gearbeitet wird. Dieser war in einem Handbuch dokumentiert und so sollte er auch mit einer Software erzwungen werden. Ein Mitarbeiter schnaubte an dieser Stelle, verschränkte die Arme vor der Brust, lehnte sich im Stuhl zurück und sprach danach kein einziges Wort mehr. Bis ich ihn in der Pause unter vier Augen erwischte und fragte, ob irgendetwas mit diesem Arbeitsprozess nicht stimme. Er erklärte mir seine Bedenken. Bisher wurde schon nicht nach Handbuch gearbeitet, weil der Ablauf so nicht funktionierte bzw. viel zu lange dauern würde. Grundsätzlich klang seine Argumentation schlüssig. Bevor ich mich aber bemühe, die konkrete und klare Vorgabe von oben wegzudiskutieren, wollte ich mich versichern, dass ich nicht etwa einer projektschädigenden Finte aufsaß. Ich fragte zwei seiner Kollegen, mit denen ich schon länger zusammenarbeitete. Sie bestätigten mir die Bedenken und lieferten noch weitere Argumente. Die Lösung dieses Konflikts erwies sich als schwierig, aber wichtig.

Fazit

Auch der Requirements Engineer selbst muss seine Grenzen kennen. Macht er, um Zeit zu sparen, schnell mal eine Annahme, riskiert er damit, sich teuer zu irren. Genauso wenn er selbst Entscheidungen trifft oder als Proxy User agiert. Aber, wie Jakob Nielsen in seinem Buch Usability Engineering richtig schreibt: “Your best guess is not good enough”, “Designers are not users” und “Vice presidents are not users”. Aber auch: “The user is not always right”.

Seien Sie also immer vorsichtig und prüfen Sie alle Informationen, denn so können Sie am besten die Hindernisse im Requirements Engineering überwinden.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Alles Wichtige über Requirements Engineering auf 37 Seiten jetzt als Download zum Mitnehmen.

Dr. Andrea Herrmann hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.