Zwei häufige Probleme im Requirements Engineering

Ein striktes Wasserfall-Vorgehen ist in Web-Projekten weder praktikabel noch gewollt: Es ist allen Beteiligten klar, dass sich die Anforderungen und Features der Lösung im Projektverlauf noch ändern werden.
Das allgegenwärtige, stark vom Wasserfall-Vorgehen geprägte Denkmuster, organisatorische Grenzen, vertragliche Konstrukte und inadäquate Arbeitsmittel führen daher allzu häufig zu einer Arbeitsweise, die nicht zur Realität passt.

Die Evolution der Lösung

Die folgende Illustration eines typischen Phasenplans zeigt die wichtigsten Zwischenergebnisse (Dokumente) und wie sich parallel dazu die Vision/Gestalt der Lösung entwickelt:

Projektphasen und Entwicklung der Lösungs-Vision/-Gestalt

Projektphasen und Entwicklung der Lösungs-Vision/-Gestalt

  1. Der Kunde startet ein Projekt und der Projektleiter erstellt ein Lastenheft mit Zielen, Anforderungen und Rahmenbedingungen.
  2. Basierend auf dem Lastenheft, Fragerunden, eigenen Überlegungen und weiteren Inputs erstellt der Anbieter eine Offerte mit Pflichtenheft.
  3. Der Dienstleister bekommt den Auftrag und arbeitet ein Grobkonzept aus.
  4. Ein Systemspezialist beschreibt in einer Spezifikation, wie das Vorhaben auf der ausgewählten Plattform genau umgesetzt werden soll.
  5. Die Lösung wird umgesetzt, getestet und als fertige Software ausgeliefert.

Die Probleme

Wie in der rechten Spalte der Skizze visualisiert wird die Lösung im Projektverlauf nicht nur konkreter (wie das im strengen Wasserfall-Vorgehen der Fall wäre), sondern sie verändert auch ihre Gestalt. Diesem Umstand trägt die stark wasserfall-geprägte Arbeitsweise nicht genügend Rechnung und es entstehen in der Praxis zwei Probleme:

  1. Die Arbeitsschritte bauen hauptsächlich auf dem Ergebnis des direkt vorangegangenen Schrittes auf. Die zusätzlichen Erkenntnisse aus Business Analyse, Anforderungserhebung und Beratung fliessen nur in Richtung des Projektziels. Die vorangegangenen Zwischenergebnisse werden nicht angepasst und werden schnell obsolet.
  2. Da der Arbeitskontext im Projekt immer technischer wird geraten die ursprünglichen Projektziele (strategische, wirtschaftliche) in Vergessenheit und es wird zu viel Energie in wenig relevante Bereiche gesteckt.

Die Folgen

Das erste Problem bewirkt, dass der Erkenntnisgewinn nur nachvollziehbar ist, wenn man die ganze Projekthistorie und alle Diskussionen nochmals durchgehen würde.
Wenn nach ein paar Jahren (in Webprojekten eher früher als später) ein Relaunch-Projekt startet, beginnt somit das Spiel von vorne und der Projektleiter startet auf der grünen Wiese. Wie würde er sich freuen, könnte er auf eine aktuelle Beschreibung des Systems auf fachlicher Ebene zurückgreifen.
Das mag nicht relevant sein für Projekte mit sehr hohem Innovationscharakter, die es so kein zweites Mal geben wird – aber für die 90% anderen schon.

Das zweite Problem bewirkt, dass in Detaildiskussionen Entscheidungen getroffen werden, die aus einer Gesamtprojekt-Sicht nicht optimal sind (z.B. wird Aufwand in wenig lohnende Features investiert).

Die Lösung?

Um die beschriebenen Probleme zu vermeiden, müssen wir die dokumenten-fokussierte Denkweise und inadäquate Werkzeuge wie Word & Excel (laut SwissQ Report 2016 immer noch die am häufigsten genannten Werkzeuge im Requirements Engineering) loswerden und mit einer integrierten Methode und entsprechenden Tools arbeiten. Und damit meine ich explizit nicht das Umschwenken auf agile Projektmethoden, denn aus verschiedenen Gründen sind diese oft nicht einsetzbar.

Es wurden schon viele Ansätze versucht, aber bisher bin ich auf keine überzeugende Lösung gestossen. Vielversprechend finde ich das Requirements Abstraction Model (RAM), welches ich aktuell in kleinem Rahmen teste. Der Praxistest ist nicht ganz einfach, weil ich erst durch den Einsatz einer optimierten Software wirklich sehen werde, ob es funktioniert. Ich arbeite deshalb mit einer eigens entwickelten, rudimentären Softwarelösung.
Ich hoffe, dass ich an dieser Stelle dereinst über positive Ergebnisse berichten kann und freue mich in der Zwischenzeit über jede frische Idee!

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>