Fortbildungen in der SYSTHEMIS Consulting
Experten der SYSTHEMIS und SYSTHEMIS Consulting arbeiten in verantwortungsvollen Positionen in verschiedensten Projekten. Um den Ansprüchen unserer Kunden gerecht zu werden, ist stetige Weiterbildung und die Optimierung unserer Abläufe unerlässlich. In einer zweitägigen Schulung mit der Expertin Sabine Zehnder-Samuels haben wir unsere Kenntnisse in diesem Bereich auf den neuesten Stand gebracht und auch unsere bewährten Prozesse auf den Prüfstand gestellt.
Was ist Requirements-Engineering?
Der Grundstein für den Erfolg jedes ambitionierten Projekts wird bereits ganz zu Beginn mit dem Erarbeiten der richtigen Anforderungen gelegt. Was will der Kunde? Weiß er überhaupt genau, was er will? Und sprechen alle Stakeholder dieselbe Sprache, wenn es um die Formulierung der gemeinsamen Ziele geht? Der Schlüssel zu all diesen Fragen ist das Requirements-Engineering. Zur grundlegenden Begriffsklärung werfen wir einen Blick in die Definition des International Requirements Engineering Board (IREB):
„Das Requirements-Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen: die Wünsche und Bedürfnisse der Stakeholder zu verstehen und das Risiko zu minimieren, ein Produkt, das nicht diese Wünsche und Bedürfnisse erfüllt, auszuliefern.“ *
Zu Beginn der Schulung gab ein differenzierter Blick auf die Dimensionen des Requirements Engineering als Disziplin bereits wichtige Erkenntnisse. Denn es ist dabei lange nicht getan mit reinem Anforderungsmanagement. Requirements-Engineering ist die Summe aus verschiedenen Teildisziplinen: wie erhebe ich Anforderungen, wie dokumentiere ich sie, wie manage ich sie und wie sichere ich Qualität? Dabei wird bereits in den ersten Schritten, der Erhebung und Dokumentation von Anforderungen, der Grundstein für ein gelungenes Projekt gelegt. Wenn in IT-Projekten Budgets oder Deadlines überschritten werden, liegt dies häufig daran, dass im Laufe des Entwicklungsprozesses noch Anforderungen überarbeitet werden müssen, weil sich herausstellt, dass bereits bei deren Erhebung und Dokumentation Missverständnisse entstanden sind, die dann durch die folgenden Projektphasen mitgeschleppt wurden.
Die Rolle des Requirements-Engineers
Das Entstehen solcher Missverständnisse im gesamten Projekt zu verhindern, ist Aufgabe des Requirements-Engineers. Dessen Rolle ist am ehesten als die eines Vermittlers zu sehen, der die Interessen und Wünsche aller Stakeholder jederzeit im Blick hat und der idealerweise die Sprache aller Beteiligter gleichermaßen zu sprechen vermag. Im innersten Kreis des Projektes arbeitet er mit absoluten Fachexperten zusammen, weiter außen sitzt die Projektleitung, dann folgen die Abteilungsleitung und letztlich ganz außen die Entscheider. Der Requirements-Engineer ist damit gewissermaßen die kommunikative Schaltzentrale des gesamten Projekts, wo alle Fäden zusammenlaufen. Er ist dafür verantwortlich, dass auch der Geschäftsführer versteht, wovon der innerste Kreis der Entwickler spricht. Diese Rolle lässt sich nicht herunterbrechen auf das bloße Abschreiben von Anforderungen: es geht um einen erheblichen Mehraufwand, der sich letztlich jedoch lohnt.
Deshalb ist größte Skepsis angebracht, wenn es von Kundenseite heißt: „Das macht der Projektleiter oder Produktmanager mit.“ Genau diese Herangehensweise führt nämlich häufig dazu, dass die Rolle stiefmütterlich behandelt wird. Es ist wichtig, sich bewusst zu machen, dass ein Projekt nicht mit dem Kickoff-Workshop beginnt. Die wichtigste Arbeit des Requirements-Engineers findet weit vorher statt.
Methoden
Um den Stakeholdern die für ihn relevanten Informationen zu entlocken, bedient sich der Requirements-Engineer verschiedenster Methoden, vor allem aus dem Bereich der Psychologie. Ob Fragebögen – wie beispielsweise die Delphi-Methode – Interviews oder Beobachtungstechniken: richtig angewendet liefern sie ihm zielgenau das gesuchte Wissen und helfen ihm, den Stakeholder, dessen Wissensstand und dessen Wünsche besser zu verstehen.
Das kann von Projekt zu Projekt komplett unterschiedlich aussehen. Möglicherweise bekommen wir bereits einen Use Case, den es zu erfüllen gilt, oder es besteht bereits ein Standardprodukt, auf dem wir aufbauen sollen. Es gibt aber auch Projekte, in denen die Stakeholder zu Beginn noch keine konkrete Vorstellung vom gewünschten Endprodukt haben. Bei einem solchen Start auf der grünen Wiese bieten sich Kreativtechniken wie Brainstorming oder Mind-Mapping an, um gemeinsam eine Vision zu entwickeln. Akkurate und zielgerichtete Kommunikation, kombiniert mit der Auswahl der richtigen kommunikativen Werkzeuge, sind das A und O des Requirements-Engineers.
Besonderheiten im Consulting
In unseren Projekten geht es meist um umfassende Fragestellungen, die häufig nicht nur Software, sondern auch Hardware und zahlreiche weitere Aspekte beinhalten. Bei der Einführung eines IT-Servicemanagement-Tools beispielsweise erheben wir die Anforderungen aller Fachbereiche unseres Kunden, müssen deren Prozesse vollständig verstehen. Das ist unerlässlich für die exakte Definition dessen, was das Tool letztlich können muss. Nach der initialen Erhebung und Verwaltung müssen im nächsten Schritt auch eine Bewertung und Priorisierung der einzelnen Anforderungen vorgenommen werden. Zu diesem Zweck lässt sich ein Punktesystem hinterlegen um Muss-Anforderungen von solchen zu differenzieren, deren Rollout vielleicht zunächst vernachlässigt werden kann.
Gerade die in der Schulung erlernten Fragetechniken lassen sich perfekt auf Organisationsuntersuchung und Prozessberatung anwenden wie wir sie betreiben. Es ist hilfreich, vom großen ins kleinteilige abzufragen, um spezifisch herauszufinden, welche Prozesse und Teilprozesse es beim Kunden gibt, wo Verantwortlichkeiten liegen, wo es Schnittstellen gibt.
Requirements-Engineering in unserem Arbeitsalltag
Wir haben festgestellt, auch durch die Erkenntnisse der Schulung, dass wir als Product-Owner, Projektleiter oder Organisationsberater in der Vergangenheit häufig Aufgaben eines Requirements-Engineers mit übernommen haben, obwohl die Rolle im Projekt so nur teilweise oder gar nicht vorgesehen war. Das zeigt, wie die Relevanz und Tragweite dieser Funktion immer noch massiv unterschätzt werden. Das umfassende Management von Anforderungen ist nichts, was man nebenbei machen kann. Eine klare Abgrenzung ist hier wichtig, schon allein aufgrund des großen Aufwands, den diese Rolle mit sich bringt. Es ist unrealistisch, zu erwarten, dass mit einem Workshop beim Kunden mal nebenbei Anforderungen erhoben werden können, die dann auch noch eindeutig sind und als Basis für das ganze Projekt ausreichen.
Deshalb haben wir beschlossen, diese Erkenntnisse in unsere laufenden und zukünftigen Projekte zu tragen und einen dementsprechenden Werkzeugkasten in der SYSTHEMIS und SYSTHEMIS Consulting einzuführen, aus dem wir uns alle bedienen können. Wir haben bereits Templates erarbeitet, die jetzt standardisiert werden. Das soll zu einem Best Practice führen, zu einem allgemeinen Leitfaden auf Basis eines Toolsets wie Confluence und Jira. Im Ergebnis wird es ein einheitliches und abgestimmtes Vorgehen geben, wie wir in bestehenden Projekten dahingehend nachsteuern können und wie wir neue Projekte aufsetzen.
* Rupp, Chris und die SOPHISTen: Requirements-Engineering und ‑Management. Das Handbuch für Anforderungen in jeder Situation, 7. Auflage, Nürnberg, Deutschland, Hanser, 2020, S.18.
