Wie wandeln Sie Ihre Ideen mit Requirements Engineering in eine IT-Lösung um?
Machen Sie bei einem Gedankenspiel zum Requirements Engineering mit: Schliessen Sie kurz die Augen und visualisieren Sie ein Objekt. Nehmen wir als Beispiel ein Haus. Überlegen Sie sich danach, wie Sie dieses Objekt einer anderen Person beschreiben würden. Es wird vermutlich einfach sein, das Objekt grob, in einem Satz zu erklären: «Das Haus ist weiss». Es wird jedoch viel schwieriger oder gar unmöglich sein, das Objekt im Detail zu beschreiben. Wenn Sie jetzt dieses Objekt bauen lassen möchten, bräuchten Sie eine Methode, um diese grobe Vorstellung zu schärfen. Dazu müssen Sie diese in konkret umsetzbare Elemente aufteilen. Im Fall des Hauses müssten Sie den Handwerkern alles bis hin zur Farbe und Form der Türen oder der Fenster vorgeben. Würden Sie als Vorgabe nur Ihre ursprüngliche grobe Vorstellung kommunizieren, würde das Resultat bestimmt nicht Ihrer Visualisierung entsprechen. Würden Sie versuchen, jedes Detail zu beschreiben, wären Sie schnell überfordert.
Was bedeutet Requirements Engineering?
Genau mit dieser Herausforderung sind unsere Kunden auch immer wieder konfrontiert. Am Anfang eines Vorhabens ist nur eine grobe Vorstellung des Endproduktes vorhanden. Dies gilt insbesondere auch bei der Entwicklung neuer Software und neuer Systeme. Damit am Ende ein Produkt entsteht, das einen Mehrwert generiert, muss die grobe Vorstellung für das Entwicklungsteam geschärft und greifbar gemacht werden. Das heisst, es muss von der Business- in die IT-Sprache übersetzt werden. Und das nennen wir «Requirements Engineering».
Abbildung 1: Requirements Engineering: Von der Idee zur IT-Lösung
Was macht diese Aufgabe so komplex? Unsere Übung oben zeigt, dass es für eine Person allein bereits eine fast unmögliche gedankliche Arbeit ist, ein einfaches Objekt präzise zu beschreiben. In der Realität entwirft man Lösungen nicht nur für sich selbst. Eine Gruppe von Personen konzipiert die Lösung fachlich, eine andere baut sie und für eine dritte Gruppe wird sie bereitgestellt. Sogar wenn man eine starke Kundenorientierung anstrebt, können Kunden ihre Bedürfnisse oft nicht klar artikulieren. Es gelingt oft erst dann, wenn gemäss dem vorherigen Bild bereits ein Teil des Hauses gebaut ist. Dies hat zur Folge, dass das Haus abgeändert werden müsste. Die Wand in einer anderen Farbe zu streichen, wäre dabei ein noch leicht abzuänderndes Element. Möchte der Endkunde und zukünftige Bewohner jedoch eine andere Raumeinteilung, kann man dies nur mit grossem Aufwand beheben.
Wie ändert sich das Requirements Engineering im Age of the Customer?
Hinzu kommt, dass sich die Erwartungen der Kunden an IT-Systeme immer schneller entwickeln. Die exponentielle Beschleunigung des technologischen Wandels zieht die Erwartungen der Kunden mit sich mit. Eine Lösung, die vor ein paar Monaten top war, könnte heute schon veraltet sein. Dies hat zur Folge, dass das Requirements Engineering zusätzlich an Bedeutung gewinnt. Um diese Herausforderung erfolgreich anzugehen, gilt es einerseits methodisch und strukturiert vorzugehen, anderseits das Problem so zu vereinfachen, dass es «managebar» wird. Wir unterscheiden zwischen dem fachlichen Design einer Lösung (Analysis and Design) und dem Aufsetzen der entsprechenden Prozesse (IT Projektmanagement).
Konkret heisst das, dass wir aus Design-Sicht die Anforderungen Schritt für Schritt erheben, zuerst grob und dann immer feiner und präziser. Um den roten Faden nicht zu verlieren, werden die Anforderungen immer aus Kunden-Sicht formuliert, sei es in der Visionierung, in der Erfassung der so genannten Customer Journey oder in den User Stories. Wir bauen möglichst schnell eine erste Version der Lösung, da es viel einfacher ist, an einem greifbaren Produkt zu arbeiten. Um «in Scope» zu bleiben, gleichen wir regelmässig die User Stories mit der Vision ab und passen gegebenenfalls entweder die Vision oder die Stories an. Dies stellt sicher, dass unsere Methodik kundenzentriert ausgestaltet ist.
Tests sind für uns auch ein Teil des Designs. Wird eine Lösung entworfen, sollte auch klar sein, was getestet werden soll. Die Anforderungen müssen zwingend mit dem Entwicklungsteam besprochen werden. Eine Anforderung ist erst dann zielführend spezifiziert, wenn damit im Team ein gemeinsames Verständnis geschaffen werden kann.
Klassisches oder agiles Requirements Engineering – was ist besser?
Aus Prozess-Sicht gibt es zwei Paradigmen. Im klassischen Requirements Engineering würde man zuerst die Anforderungen erheben und in einem zweiten Schritt die Entwicklung angehen. Der Vorteil dieses Ansatzes ist, dass der Scope und somit die Kosten im Voraus bekannt sind. Suboptimal ist bei diesem Ansatz, dass es – wie oben erläutert – fast unmöglich ist, präzise Anforderungen lange im Voraus zu erheben. Sogar wenn die Anforderungen zum Zeitpunkt der Erhebung sehr präzise wären, besteht die Gefahr, dass sie sich mit der Zeit verändern und somit mit teuren Change Requests das ursprüngliche Werk erweitert bzw. umgebaut werden muss.
Der andere Ansatz ist die «Agilität». In dieser Vorgehensweise wird ein gemischtes «IT/Business-Team» gebildet, das gleichzeitig die Anforderungen erhebt und die Lösung in kurzen taktierten Zyklen (Sprints) entwickelt. Der Vorteil ist, dass die Lösung sich entsprechend der Bedürfnisse des Kunden entwickelt. Der Nachteil ist, dass nur das Budget und eine Vision im Voraus bekannt sind, jedoch nicht der detaillierte Scope.
Geschwindigkeit und Kundenorientierung sind die zentralen Erfolgsfaktoren
Wir streben ein massgeschneidertes «Delivery Management» an, d. h. Prozesse, die optimal zur Organisation des Unternehmens und zum Vorhaben passen. Für ein kleines Projekt in einem Unternehmen ohne «agiles Mindset» macht es beispielsweise wenig Sinn, mit den agilen Methoden SCRUM oder SAFe zu arbeiten. Für grössere Unternehmen und Vorhaben kann Agilität die Kundenzufriedenheit und die Time-to-Market deutlich verbessern, jedoch auch nur, wenn die Rahmenbedingungen stimmen. Unabhängig von der gewählten Methodik gibt es Elemente, die man nie vergessen darf. Schnelligkeit in der Umsetzung und Kundenorientierung sind zentral. Wer zu viel Zeit benötigt, um auf den Markt zu kommen, und die Erwartungen der Kunden nicht proaktiv gestalten kann, wird seinen Marktvorteil verlieren.
Nur durch Agilität, Transparenz und Kommunikation in den Vorhaben kann man vermeiden, dass eine Lücke zwischen den Erwartungen der Kunden und ihrer Lösungen entsteht. Die zusammenarbeitenden Gruppen von Leuten können nur erfolgreich sein, wenn sie durch eine intensive strukturierte Kommunikation ihre Ideen und Vorstellungen über die Zeit in ein konsolidiertes kundentreues Bild verschmelzen lassen. Und nicht nur die Ideen sollen verschmelzen, auch die Gruppen sollen zum Team werden!
Das Requirements Engineering ist eine komplexe Aufgabe, die man leider allzu oft unterschätzt. Wir unterstützen Sie gerne bei Ihrem nächsten Projektvorhaben und freuen uns auf Ihre Kontaktaufnahme. Wenn Sie generell an den Herausforderungen an der Schnittstelle zwischen Business und IT interessiert sind, dann folgen Sie uns auf LinkedIn, um keine Beiträge zum Thema zu verpassen.
