Transparentes Requirements Engineering von ReqPOOL

Viele Projekte im Requirements Engineering starten mit dieser Herausforderung. Die Projekte werden mit Basisinformationen vergeben und der Requirements Engineer zu einer Aufwandsschätzung aufgefordert. Die umfangreiche Dokumentation wird nach der Beauftragung vergeben und erweitert sich häufig im Laufe des Projektes durch zusätzliche Dokumente, System oder Stakeholder die mit in das Projekt einbezogen werden sollen.

Die klassischen Probleme ähneln sich in vielen Projekten. Der Umfang ist aus Sicht der Fachbereiche bereits vollständig oder sehr umfänglich in einem oder mehreren Vorprojekten beschrieben worden und „muss nur noch validiert und ergänzt werden.“ Als Teil der Bestandsdokumentation wird eine Liste der Stakeholder übergeben. Diese ist wie die Bestandsdokumentation meist veraltet oder unvollständig.

Im Zuge der Projektplanung werden die Dokumente analysiert und Basisinformationen extrahiert. Jedoch stellt sich in vielen Fällen heraus, dass die selbstbewusst formulierte Vollständigkeit der Dokumentation bereits im Vorprojekt nicht erreicht wurde.

Das Ergebnis: Rolling Wave Planning und Aufwandssteigerungen im Projektverlauf

Durch die unklare Ausgangslage sowohl auf Seiten der Stakeholder, der Projektverantwortlichen und des Requirements Engineering ergeben sich Unsicherheitsfaktoren die eine vollständige und valide Projektplanung häufig erschweren. Es wird mit Risikopuffern versucht die Unschärfe mit einzubeziehen, jedoch fällt meist mindestens die Zeitplanung der Unschärfe im Projektverlauf zum Opfer.

Im Zuge meiner täglichen Arbeit lassen sich vier klare Problemstellungen im Requirements Engineering erkennen denen entgegengewirkt werden sollte:

  • Stakeholder Management
  • Analyse von Bestandsdokumentation
  • Analyse der Kontextabgrenzung
  • Vermeidung einer „Big Bang“-Kundenabnahme

Wir bei ReqPOOL entwickeln Methoden und Vorgehensmodelle um unsere Prozesse im Requirements Engineering stets zu optimieren und weiter zu entwickeln.

Stakeholder Management

Nach IREB-Standard und den weit verbreiteten Projektmanagement-Standards ist die Identifikation , das laufende Management und die Betreuung der Stakeholder eine der Kernaufgaben für den Projekterfolg. Selbstredend, wenn ich als Projektmanager meine Stakeholder nicht kenne, kann ich für diese das Projekt auch nicht zum Erfolg führen. Und ein Projekt wird erfahrungsgemäß nur dann erfolgreich, wenn alle relevanten Stakeholder und Einflussfakten berücksichtigt wurden.

Wie also nun die Stakeholder herausfinden?

Häufig ist die Dokumentation über Stakeholder unvollständig. Die Gründe hierfür sind vielschichtig. Entweder haben sich seit der Erhebung die Strukturen verändert, oder implizites Wissen wurde nicht explizit erfasst oder falsch wahrgenommen. Es ist also unabdingbar mit Hilfe einer Checkliste mögliche Dokumentationsquellen abzufragen und zu validieren. Mögliche Dokumentationsquellen können die folgenden sein, wobei man diese Liste um viele weitere erweitern kann:

Stakeholder

  • Einflussnehmer
  • Benutzer des Systems
  • Mitarbeit die direkten Einfluss auf oder von dem System haben
  • Betreiber des Systems
  • Entwickler von Bestandsystemen
  • Entwickler der Neuentwicklung

Dokumentationen

  • Bestandsdokumentation
  • Definitionen von Geschäftsprozessen
  • Definitionen von Geschäftsstrukturen
  • Normen/Standards/Richtlinien/Gesetze
  • Interne Vorgaben
  • Interne Prozessrichtlinien

Systeme im Betrieb

  • Informationen zu Vorgängersystemen
  • Informationen zu Konkurrenzsystemen
  • Informationen zu Umfeldsystemen

Um die Stakeholder und die von ihnen erhaltenen Informationen bestmöglich und transparent zu verwalten empfehle ich die folgenden Schritte:

  • Eine transparente Abbildung der Quellendimension, welche Anforderung stammt von welcher Quelle, ist sehr hilfreich für die Diskussionsgrundlage im Projektverlauf
  • Eine Abnahme auf Vollständigkeit der Quellen und Stakeholder durch den Kunden verbessert ein klares Bild auf den aktuell bekannten Umfang und die Komplexität des Projektes
  • Eine möglichst umfassende Einbeziehung aller Stakeholder im Projektvorgehen unterstützt die Vollständigkeit der Informationen, verbessert die Qualität der Informationen und Entscheidungsgrundlagen und verringert das Risiko ungeplanter Verzögerungen im späteren Projektverlauf

Analyse von Bestandsdokumentation

Die Analyse von Bestandsdokumentation ist meist ein heikles Thema. Die Spannbreite der Kundenaussagen reicht von „alles Schrott was bisher da ist“ bis hin zu „eigentlich fertig und muss nur punktuell ergänzt werden“ und spiegelt immer „nur“ die Einschätzung des Kunden wieder.  

Auch hier ist eine Checkliste für einen Abgleich auf Vollständigkeit und Qualitätseinschätzung sinnvoll um sich einen strukturierten Überblick über den Umfang und die Qualität der Dokumentation zu machen. Aus diesen Informationen ist es möglich, eine Gap-Analyse durchzuführen und diese möglicherweise fehlenden Quellen einzufordern.

Mögliche Dokumentations- und Informationsquellen können sein:

  • Definierte Ziele des Projektes oder des Systems
  • Informationen aus Vorprojekten (neben „finalen“ Dokumenten auch die Arbeitsdokumentation um Entscheidungswege zu verstehen)
  • Dokumentation von Bestandssystemen
  • Technische Dokumentationen
  • Gesprächsprotokolle
  • Dokumentation über Geschäftsprozesse und Geschäftsstrukturen

Um die Analyse von Bestandsdokumentation so effektiv wie möglich zu gestalten, empfehle ich die folgenden Schritte:

  • Die Quellenangabe bei Anforderungen – welche Anforderung kommt von welcher Quelle - ermöglicht eine valide Diskussionsgrundlage
  • Der Kunde muss die Dokumentationsquellen auf Vollständigkeit abnehmen und während dem Projekt stets Einblick auf die Quellen erhalten
  • Die (relevanten) Informationen aus der Dokumentation müssen bestmöglich strukturiert und grafisch aufbereitet und dem Kunden präsentiert werden um eine Validierung zu erhalten. In vielen Fällen werden hier die entscheidenden Unterschiede erkennbar.

Kontextabgrenzung

Ein Kontextdiagramm definiert die Abgrenzung von System, Systemkontext und irrelevanter Umgebung, soweit so gut. Auch der Systemkontext muss dem Kunden bestmöglich grafisch dargestellt werden um die klaren Abgrenzungen durchführen zu können. Besonderer Wert ist hier meiner Meinung nach auf die abzugrenzenden Systeme und Faktoren um dem Kunden diese klar vor Augen zu führen. Ebenfalls sollten indirekte Beziehungen unbedingt einbezogen werden, eine Checkliste kann hier die entsprechende Prüfung auf Vollständigkeit unterstützen.

Abnahmeprozess(e)

In den meisten Projekten nehmen die Kunden die Spezifikation erst ganz zum Schluss ab, „da ja vorher noch so viele Abhängigkeiten“ bestehen. Ziel des Requirements Engineers muss es sein, eine strukturierte fortlaufende Abnahme der Spezifikation zu erhalten. Eine Abnahme ganz zum Schluss birgt das hohe Risiko von plötzlich entdeckten Zusatzthemen, die den Zeit- und Kostenplan außer Kontrolle bringen.

Wir von ReqPOOL führen mit dem Kunden eine strukturierte Abnahme herbei um beidseitig ein klares Bild für den Umfang und den Projektverlauf zu schaffen. Je nach Kunde und Projektkonstellation funktioniert das mal besser mal schlechter, jedoch ist beiden Seiten sehr geholfen, wenn das Bild für den Umfang klar definiert wird und ein Rolling Wave-Planning vermieden werden kann. Teilweise sind bidirektionale Abhängigkeiten unter den verschiedenen Projekt-Elementen, diese gilt es also auch bei der sequentiellen Abnahme zu berücksichtigen. Die Reihenfolge kann je nach Projekt unterschiedlich gewählt werden, jedoch gehen wir in den meisten Fällen wie nachfolgende abgebildet vor.

Abnahmeprozess im Requirements Engineering

Die Ziele eines Projektes geben viele Hinweise über mögliche notwendige Stakeholder, Dokumentationen, Geschäftsprozesse oder auch Systeme. Zu Beginn muss eine grobe Vollständigkeit hergestellt und abgenommen werden, damit in den Folgeschritten die tiefergehenden Informationen struktruriert abgearbeit werden können. Für jede der Ebenen muss mit den Kunden ein bestmögliches Bild zur Vollständigkeit beitragen, um den klaren Überblick über zu behandelnde Themen und Objekte zu erhalten. Wurde die Vollständigkeit der Themen hergestellt, so kann jedes Thema spezifisch behandelt und abgearbeitet werden. Durch diese Methode könnnen klassische Projektcontrollingmechanismen wie Earned Value Management im Requirements Engineering Prozess etabliert werden und helfen bei der Fortschrittskontrolle im Projektverlauf.

Ergeben sich bei der Erhebung im Prozess Änderungen die Auswirkungen auf abhängige Elemente haben, so müssen diese entsprechend aktualisiert werden und erneut vom Kunden abgenommen werden, das kann je nach Projekt recht formell einem Change-Request folgen oder durch eine formlose Abnahme durchgeführt werden. Ziel soll sein, den Kunden bestmöglich in den gesamten Prozess einzubinden um ihm auch die Abhängigkeiten und die Auswirkungen jederzeit transparent darstellen zu können.

Fachlicher Schnitt und Verwaltung von Anforderungen im späteren Projektverlauf

Einflussfaktoren für fachlichen Schnitt von Anforderungen

Eine Spezifikation wird immer mit dem Ziel erhoben ein System neu einzuführen, abzulösen oder zu verändern. Der Prozess des Requirements Engineering ist in den meisten Fällen unabhängig von der späteren Entwicklung, es sei denn diese wird über Projektziele oder Einflussfaktoren mit eingebunden. Wurde eine spezifikation erstellt und vom Kunden abgenommen so folgen die weiteren Schritte wie Beschaffung, Projektierung, Umsetzung, Testen, Abnahme und Einführung. In diesen Schritten kommt es häufig vor, dass die erstellte Spezifikation in unterschiedliche Schnitte geteilt werden muss. Das kann auf Grund von drei Einflussfaktoren oder einer Kombination dieser geschehen. Dadurch müssen Anforderungen in einer strukturierten Form erfasst werden um diese nachträglich in eine oder mehrere Reihungen bringen zu können. Die drei Stakeholder Sponsor/Geldgeber, Fachabteilung sowie die technische Umsetzung haben unterschiedliche Sichtweisen und Anforderungen an einen Schnitt der Anforderungen. Der Schnitt kann nach einer Zeitachse für die Umsetzung erfolgen (Releasing), der Sponsor kann Funktionsblöcke nach Kosten-Nutzenfaktor schneiden, oder der Fachbereich kann nach Priorität eine Reihnung oder eine Gruppierung durchführen. Der Umsetzungspartner freut sich sicher ebenso, wenn er die Informationen aus der Spezifikation in seine interne Entwicklungsumgebung überführen kann (z.B. Ticketsystem oder Testsystem).

Neben den fachlichen Schnitten muss die Form und Struktur der Spezifikation auch ermöglichen, Änderungen im späteren Verlauf durch Erweiterungen, Änderungen aufnehmen und verarbeiten zu können. Auch hier empfiehlt sich eine strukturierte Erfassung und Datenhaltung um die Änderungen beispielsweise an Hand von Metadaten transparent ausweisen und filtern zu können.

 

Erkenntnis: Der Markt ruft nach neuen ReqPOOL Produkten!

Die Entwicklung der ReqPOOL Suite soll den Kunden ermöglichen, die Spezifikation zentral und medienbruchfrei zu dokumentieren und zu verwalten. Jedoch sind viele Kunden sehr an die Produkte der Microsoft Office Suite gebunden und akzeptieren für die eigenen Prozesse keine Dokumentation in anderen projektbezogenen Produkten. Jedoch ist eine reine Dokumentation in einem Word-Dokument wie es in den meisten Vorprojekten bei den Kunden praktiziert wird, auf Grund der oben angeführten Anforderungen nicht praktikabel und bedeutet einen hohen manuellen Aufwand. Daher haben wir uns von ReqPOOL dazu entschieden zwei neue Produkte zu entwickeln, die dem Kunden ermöglichen, mit seiner vorhandenen und gewohnten Produktumgebung zu arbeiten, seine Daten lokal zu halten und trotzdem einen hohen Grad an Automatition zu erreichen. ReqPOOL hat hierfür den ReqPOOL Anforderungskatalog für die Erhebung und Verwaltung von Anforderungen in einem klaren strukturierten Prozess entwickelt. Für eine in manchen Fällen gewünschte Formatierung in ein vordefiniertes Microsoft Word Format wurde hierfür der ReqPOOL ReqCat entwickelt, welcher die Informationen aus dem Anforderungskatalog aufnimmt und in die gewünschte Word-Form transformiert. Somit sind die Vorteile beider Welten sinnvoll vereint und der Fokus kann wieder auf die fachliche Spezifikation gelegt werden. Wir sind stolz auf das bisher sehr positive Feedback der Kunden und freuen uns auf den baldigen großen Launch der neuen ReqPOOL Werkzeuge.

ReqPOOL Anforderungskatalog und ReqCat

Bild des Benutzers stefan

Stefan Hamann

Stefan Hamann ist gesamtverantwortlich für die technische und fachliche Produktentwicklung der softwaregestützten Werkzeuge von ReqPOOL, zusammengefasst in der ReqPOOL Suite. Durch seine Erfahrung im Bereich der Softwareentwicklungsprozesse, gepaart mit dem analytischen Requirements Engineering kann Herr Hamann seine Fähigkeiten gewinnbringend in der Entwicklung von neuen Funktionen und der Abwicklung des Softwareentwicklungsprozesses einbringen. Seine Kenntnisse und Erfahrungen im Bereich der Usability lassen Herrn Hamann unsere Produkte immer wieder kritisch auf den Prüfstand stellen und ihn nicht ruhen bis die Kunden zufrieden sind.