Requirements Engineering als Gestaltungsdisziplin

Der Mensch gestaltet sein gesamtes Leben lang. Egal, ob es um das Beziehen einer neuen Wohnung geht, vielleicht sogar einen Hausbau, um den Besitz eines Gartens oder um die Planung des nächsten Wochenendes – immer wird gestaltet. Im besonderen Ausmaß gilt das auch für die Tätigkeit der Softwareentwicklung. Die Software hat ein bestimmtes Äußeres, eine Benutzerschnittstelle, sie bildet bestimmte Prozesse ab, realisiert Algorithmen – kurz gesagt, die Software hat eine bestimmte Gestalt – und die muss gestaltet werden. Es geht nicht anders.

Gestaltung im Software- Entwicklungsprozess

Aber wann und wo wird die Software gestaltet? Wer ist dafür zuständig? Um diese Frage zu untersuchen, ist in Abbildung 1 ein sehr einfacher Software-Entwicklungsprozess dargestellt. Dieser Prozess ist sehr rudimentär. Es fehlen viele Tätigkeiten und Rollen. So gibt es kein Projektmanagement, keinen Test und auch keine der agilen Rollen. Für die Zwecke des vorliegenden Artikels reicht er jedoch völlig aus.
Es gibt eine Stelle, die Software für die Erfüllung ihrer Aufgaben benötigt, sie hat einen Bedarf oder – in der Sprache des Requirements Engineering (RE) – Anforderungen. In Abbildung 1 ist diese Stelle als „Fachbereich“ bezeichnet. Deren Anforderungen werden vom Bereich in der Mitte – dem „Requirements Engineering“ – erhoben und dokumentiert. Die Anforderungen werden geprüft und unter den einzelnen Stakeholdern abgestimmt. Im Bereich rechts, schließlich, im „Development“, werden die Anforderungen in Code gegossen – die Software wird entwickelt.

Und wo passiert nun die Gestaltung? In obiger Beschreibung ist das Wort „Gestaltung“ nicht vorgekommen. Gibt es also gar keine Gestaltung? Jedoch: Man kann nicht nicht gestalten. Gestaltung passiert also zweifellos in jedem Software-Entwicklungsprozess. Es ist aber nicht geregelt, wo diese geschieht, es gibt keine klare Zuordnung der Gestaltungskompetenz. Gestaltung erfolgt zufällig.

Was ist „Gestaltung in der IT“?

Vor der nun folgenden Überlegung bezüglich der „richtigen“ Stelle für die Gestaltungskompetenz sei definiert, was unter „Gestaltung in der IT“ zu verstehen ist. Häufig wird nur der sichtbare Bereich als Objekt der Gestaltung betrachtet – in der Software also nur die Benutzeroberfläche. Gestaltung ist jedoch mehr. Für die Zwecke der weiteren Betrachtung soll unter „Gestaltung“ Folgendes verstanden werden: „Gestaltung in der IT ist der Entwurf der grundlegenden Strukturen, Prozesse und Schnittstellen für ein zu erstellendes oder zu änderndes IT-System, sodass dieses seinen geplanten Zweck erfüllen kann“. Im Folgenden wird untersucht, an welcher Stelle im Software-Entwicklungsprozess Gestaltung im oben definierten Sinne zweckmäßigerweise angesiedelt sein soll.

RE als Ort der Gestaltungskompetenz

Es bietet sich an, den Bedarfsträger – also den Fachbereich aus Abbildung 1 – als den richtigen Ort für die Gestaltungskompetenz zu sehen. Dort weiß man ja, was man braucht. In den dort formulierten Anforderungen kann auch schon die Gestaltung enthalten sein. Es gibt da allerdings das angebliche Zitat von Henry Ford: „Wenn ich die Leute gefragt hätte, was sie brauchen, hätten sie gesagt: schnellere Pferde“. Die Bedarfsträger tendieren dazu, sich ihr altes System zu wünschen – vielleicht in einem etwas moderneren Look und unter Bereinigung der größten Pain Points. Das liegt vor allem daran, dass die Information über neue technische Möglichkeiten nicht in ausreichendem Maße vorhanden ist, was in vielen Fällen echte Innovation verhindert. Wissen über die technischen Möglichkeiten, das ist auf der rechten Seite von Abbildung 1 – im Development – jedenfalls vorhanden. Ist es also zweckmäßig, die Gestaltungskompetenz dort anzusiedeln? Auch dafür gibt es starke Argumente. Hier ist man allerdings sehr weit von der fachlichen Problemstellung entfernt.

Meist fehlt es dann an der Kapazität, da und dort auch am Interesse, sich das entsprechende Wissen anzueignen. Und es ist auch verständlich. Um nur ein Beispiel zu nennen: Wenn man gerade dabei ist, einen Docker-Container einzurichten, ist es sehr schwierig, sich auch noch mit den Details des Umsatzsteuerrechtes auseinanderzusetzen (so es die aktuelle fachliche Problemstellung erfordert). Gleichermaßen Nähe zur fachlichen Problemstellung wie zu den technischen Möglichkeiten besteht in der Mitte: dort wo auch das Requirements Engineering beheimatet ist. Deshalb liegt es auf der Hand, dass hier auch die Gestaltungskompetenz ihre logische Heimat hat. Was jedoch nicht bedeutet, dass die Gestaltung hier isoliert und unbeeinflusst erfolgen kann. Selbstverständlich sind dabei die Anforderungen, Wünsche und Ideen des Fachbereiches einzubeziehen – genauso wie die technischen Möglichkeiten des Developments. Das geht in manchen Fällen so weit, dass sich die Gestaltungsaufgabe darauf reduziert, Moderator des eigentlichen Prozesses zu sein.

Verwaltungsdisziplin oder Gestaltungsdisziplin?

In den meisten Publikationen, wie auch im Lehrplan zum CPRE (Certified Professional for Requirements Engineering), sind die Aufgaben des Requirements Engineering definiert als [IREB]:

• Anforderungen erheben,
• Anforderungen dokumentieren,
• Anforderungen prüfen und abstimmen,
• Anforderungen verwalten.

Eine Gestaltungskomponente ist dabei im Allgemeinen nicht vorgesehen. Requirements Engineering wird als reine Verwaltungsdisziplin gesehen. Dem steht jedoch die tatsächliche Tätigkeit vieler Requirements Engineers entgegen, die sehr wohl – im Sinne der oben angeführten Definition von „Gestaltung“ – Strukturen, Prozesse und Schnittstellen entwerfen. Kann das Requirements Engineering – entgegen der überwiegenden Darstellung in der Literatur – auch als Ort der Gestaltung, als Gestaltungsdisziplin betrachtet (und gelebt) werden?

Eine Frage der Kultur

Ob Requirements Engineering als Verwaltungs- oder als Gestaltungsdisziplin gesehen und gelebt wird, ist eine Frage der Kultur. Was bedeutet das? Im Allgemeinen wird Kultur mit Begriffen wie Literatur, Oper, Theater verbunden. Es ist evident, dass das nicht der Begriff von Kultur ist, der hier gemeint ist. Etwas weiter bringt hier schon der Begriff „Unternehmenskultur“. Darunter ist zu verstehen: „Die Grundgesamtheit gemeinsamer Werte, Normen und Einstellungen, welche die Entscheidungen, die Handlungen und das Verhalten der Organisationsmitglieder prägen.“ [Lies20] In Anlehnung an diese Definition sei Requirements-Engineering-Kultur definiert als: „Grundgesamtheit gemeinsamer Ziele, Prämissen und Werte, welche die Entscheidungen, die Handlungen und das Verhalten im Requirements Engineering prägen.“ Drei Dimensionen sind prägend für die Frage, ob Requirements Engineering als Verwaltungs- oder als Gestaltungsdisziplin gesehen wird:

• Ziele: Was soll durch Requirements Engineering erreicht werden? Was ist dessen Output?
• Prämissen: Welche Grundannahmen über die Welt der Softwareentwicklung herrschen vor?
• Werte: Was ist wichtig bei der Ausführung des Requirements Engineering?

Je nachdem, wie diese drei Dimensionen ausgeprägt sind, herrscht im Requirements Engineering eine Verwaltungs- oder eine Gestaltungskultur vor. Im Folgenden werden die drei Dimensionen daraufhin untersucht.

Dimension Ziele

In einer Verwaltungskultur ist das angestrebte Ergebnis des Requirements Engineering eine vollständige und widerspruchsfreie Sammlung von Anforderungen. Vollständigkeit und Widerspruchsfreiheit stehen hier stellvertretend für verschiedene Qualitätskriterien von Anforderungen, wie sie in der Literatur zu finden sind (siehe Abbildung 2).

Damit dieses Ziel erreicht wird, sind folgende Schritte vorgesehen [IREB]:

• Erheben von Anforderungen,
• Dokumentieren von Anforderungen,
• Prüfen und Abstimmen der Anforderungen,
• Verwalten der Anforderungen.

In einer Gestaltungskultur spielen Anforderungen natürlich auch eine Rolle, sie haben aber eine andere Funktion: Hier sind sie nicht das Ziel der Aktivität, sondern sie sind gleichsam das Rohmaterial. Im Prozess des Requirements Engineering werden sie transformiert. Das Ziel der Tätigkeit ist der Entwurf eines IT-Systems. Zur Erreichung dieses Ziels führen folgende Tätigkeiten:

• Kommunizieren: vergleichbar mit dem „Erheben von Anforderungen“ in der Verwaltungskultur. Der Unterschied liegt darin, dass das Kommunizieren in beide Richtungen erfolgt. Der Gestalter teilt dem Bedarfsträger frühzeitig seine Gestaltungsideen mit, sodass dieser widersprechen oder auch seine Anforderungen weiterentwickeln kann.
• Konstruieren: das ist die eigentliche Gestaltungstätigkeit. Aus den abgestimmten Ideen, Wünschen, Anforderungen wird ein konsistentes System entworfen.
• Dokumentieren: Solange der Entwurf nur im Kopf des Gestalters existiert, ist er wertlos. Der Entwurf muss in eine Form gebracht werden, die es anderen Rollen ermöglicht, ihn einerseits zu überprüfen und andererseits – darauf aufbauend – das geplante Softwaresystem zu entwickeln.

Dimension Prämissen

Prämissen sind jene Annahmen, die man über die Welt hat. Hier interessiert natürlich nicht die Welt im Allgemeinen, sondern speziell die Welt der Softwareentwicklung. In einer Verwaltungskultur (siehe Abbildung 3) geht man davon aus, dass sämtliche Anforderungen bereits existieren.

Aufgabe des Requirements Engineering ist es, diese Anforderungen zu finden, sie aufzudecken. Sobald sie vollständig dokumentiert sind, ist auch das zu entwickelnde System determiniert. Eine Entwurfstätigkeit ist nicht erforderlich. Eine Gestaltungskultur hingegen geht davon aus, dass die expliziten Anforderungen nur einen Bruchteil des zu entwickelnden IT-Systems abdecken. Auch ist nicht jede Äußerung eines Stakeholders eine Anforderung im engeren Sinne. Häufig handelt es sich eher um Wünsche oder Ideen, bei denen es mehr oder weniger großen Gestaltungsspielraum für den Requirements Engineer gibt. Es liegt in der Verantwortung eines Gestalters (des Requirements Engineers) aus all diesen Anforderungen, Wünschen und Ideen ein konsistentes Gesamtsystem zu konstruieren. Am Ende dieses Prozesses steht dann der Entwurf des IT-Systems.

Dimension Werte

Unter Werte sollen Eigenschaften oder Fähigkeiten verstanden werden, die für die Ausübung der Tätigkeit wichtig sind. Eine Abgrenzung ist hier schwierig, weil jede Fähigkeit nützlich ist, egal ob man Requirements Engineering als Verwaltungs- oder als Gestaltungsdisziplin sieht. Trotzdem wird im Folgenden je ein Wert dargestellt, der für das jeweilige Paradigma besonders prägend ist. Für die Verwaltungskultur ist Genauigkeit (siehe Abbildung 4) der entscheidende Faktor. Eines der Qualitätsmerkmale für Anforderungen ist die Vollständigkeit. Es muss also sehr penibel darauf geachtet werden, dass keine Anforderung übersehen wird. Genauigkeit ist auch für die Attributierung der Anforderungen im Anforderungsmanagement wichtig. Ohne sagen zu wollen, dass Genauigkeit für eine Gestaltungskultur nicht wichtig ist, steht hier doch eine andere Eigenschaft im Vordergrund. Der Transformationsprozess von Anforderungen in einen Entwurf erfordert vor allem eines: Kreativität. Diesem Hauptcharakteristikum einer Gestaltungsdisziplin sind die folgenden Überlegungen gewidmet.

Kreativität als Hauptcharakteristikum der Gestaltungsdisziplin RE

Kreativität ist ein vielschichtiger Begriff. Grundsätzlich lassen sich die Formen der Kreativität in zwei Gruppen einteilen:

• ästhetische Kreativität: hier geht es darum, Wahres, Gutes, Schönes zu schaffen. Alle Formen der Kunst – Literatur, Musik, Malerei und vieles anderes – fallen darunter.

Davon zu unterscheiden ist die:

• problemlösende Kreativität: kreative Ideen führen zur Lösung von Problemen. Aus Anforderungen, Wünschen, Ideen einen konsistenten Entwurf zu machen, stellt den Gestalter (bzw. den Requirements Engineer) vor viele Probleme, die dieser problemlösenden Kreativität bedürfen.

Wenn man von der Gestaltungsdisziplin Requirements Engineering spricht, dann ist die wichtigste Eigenschaft beziehungsweise das entscheidende Soft Skill die Kreativität. Im Folgenden wird untersucht, wie die Kreativität gezielt für das Requirements Engineering eingesetzt werden kann.

Der Kreativitätsprozess

Ist Kreativität angeboren? Kann man Kreativität erlernen? Kann man kreative Ideen vielleicht sogar durch Einhaltung eines Prozesses generieren? Einer, der sich intensiv mit dieser Frage auseinandergesetzt hat, war Graham Wallas, ein englischer Sozialpsychologe und Erziehungswissenschaftler und Mitgründer der London School of Economics. In seinem Buch „The Art of Thought“ hat Wallas seine Theorie der Kreativität niedergeschrieben [Wall26]. Basis für seine Überlegungen waren Berichte der Wissenschaftler Hermann von Helmholtz und Henri Poincaré. Wallas zitiert zum Beispiel den deutschen Physiker von Helmholtz. Dessen Ideen seien ihm nicht an seinem Arbeitstisch gekommen, sondern „during the slow ascent of wooded hills on a sunny day“, also in einer Situation, in der er sich gerade nicht mit dem zu lösenden Problem beschäftigt hat. Diese Erfahrungen hat Graham Wallas zu seinem 4-Phasen-Modell der Kreativität verarbeitet (siehe Abbildung 5). Das sieht folgendermaßen aus:

• Preparation: Ideen kommen nicht aus dem Nichts – bei einer Waldwanderung. Auch Hermann von Helmholtz hat sich wohl lange an seinem Arbeitsplatz mit der jeweiligen Materie befasst. In der Phase der „Preparation“ beschäftigt man sich intensiv mit dem zu bearbeitenden Gegenstand, man sammelt Informationen, baut Wissen auf.
• Incubation: Der „Preparation“ schließt sich die Phase der „Incubation“ an. In dieser Phase lässt man all die Informationen, die man gesammelt hat, setzen. Man beschäftigt sich bewusst nicht mehr mit der Sache – sondern lässt das Unterbewusstsein die Arbeit tun.
• Illumination: Schließlich bildet sich die Lösung heraus – „during the slow ascent of wooded hills on a sunny day“, wie es Hermann von Helmholtz beschreibt. Das kann plötzlich sein – in der Form eines Geistesblitzes – oder auch in einem langsamen Prozess, in dem sich die Lösung langsam herauskristallisiert.
• Verification: Geistesblitze kann es viele geben. Die Idee muss aber auch einer rationalen Überprüfung standhalten. Und die Ideen müssen auch festgehalten werden. Solange der Geistesblitz nur im Kopf des Nachdenkenden ist, ist er anderen nicht zugänglich. Die Dokumentation des Ergebnisses des Kreativitätsprozesses ist ebenfalls Bestandteil der Verification-Phase.

Das Basismodell der Gestaltungsdisziplin RE

Auch die Gestaltung eines IT-Systems ist ein kreativer Prozess. Die Anforderungen, Wünsche, Ideen der Stakeholder – sowohl von fachlicher als auch von technischer Seite – müssen zu einem konsistenten Gesamtsystem zusammengefügt werden. Dazu kommt, dass nicht alles explizit als Anforderung formuliert wird, was zur Lösung der Aufgabenstellung benötigt wird. Der Transformationsprozess von den Anforderungen, Wünschen, Ideen zum Entwurf des Systems folgt den gleichen Prinzipien, wie sie Graham Wallas in seinem Kreativitätsprozess beschrieben hat. Basierend auf dessen 4-Phasen-Modell der Kreativität zeigt Abbildung 6 das „Grundmodell der Gestaltungsdisziplin Requirements Engineering“. Im Zentrum steht das „Denken“ – also die Phasen „Incubation“ und „Illumination“. Hier entstehen die Ideen, hier wird der Mehrwert des Requirements Engineerings erzeugt. Wenn diese Phasen auch die entscheidenden sind, so sind sie doch sinnlos ohne die Phasen des äußeren Kreises. Das Denken braucht Nahrung – und die wird in der Phase der „Preparation“ geliefert. Hier geschieht auch das, was als „Erheben der Anforderungen“ bezeichnet wird. Allgemeiner gesagt, hier wird das Wissen über das Fachgebiet aufgebaut, für das die IT-Lösung entwickelt werden soll.

Auf der anderen Seite steht die Phase der „Verification“. Einerseits werden hier die Ideen des Requirements Engineers mit den Stakeholdern abgestimmt, was auch zu einer Adaption oder zum völligen Verwerfen führen kann. Außerdem werden hier die Ideen dokumentiert, wofür verschiedene Methoden zur Verfügung stehen: von freiem Text bis zu verschiedenen Arten von Modellen.
Für die Ausübung dieses kreativen Prozesses steht dem Requirements Engineer eine unüberschaubare Anzahl von Werkzeugen zur Verfügung. Eine kleine Auswahl davon ist in Abbildung 6 dargestellt. Dazu zählen einerseits seine persönlichen Fähigkeiten, Soft und Hard Skills, andererseits aber auch Methoden und Werkzeuge für Kommunikation, Modellierung, Dokumentation. Das Grundmodell der Gestaltungsdisziplin Requirements Engineering besteht also aus:

• dem inneren Kreis – dem Nachdenken über die Lösung,
• dem äußeren Kreis, der besteht aus dem Aufbau des erforderlichen Wissens und der Verifikation und Dokumentation der gefundenen Lösung,
• einem möglichst gut bestückten Werkzeugkasten.

Warum Gestaltungsdisziplin RE?

Je nach Ausprägung der Kultur kann Requirements Engineering als Verwaltungsoder als Gestaltungsdisziplin betrachtet werden. Was sind aber die Vorteile, Requirements Engineering als Gestaltungsdisziplin zu sehen?

• Requirements Engineers entwerfen auch jetzt IT-Systeme. Sie sagen es nur nicht. Stattdessen sagen sie von sich selbst, dass sie „Anforderungen schreiben und verwalten“. Wenn Requirements Engineering als Gestaltungsdisziplin betrachtet wird, ist das also gar keine Änderung der tatsächlichen Arbeit.
• Das heißt, es gibt eine Lücke zwischen Theorie und Praxis. In der Praxis wird und wurde immer gestaltet. Wenn Requirements Engineering auch in der Theorie als Gestaltungsdisziplin gesehen wird, dann wird diese Theorie-Praxis-Lücke geschlossen.
• Es ermöglicht auch eine gezielte Aus- bildung der Gestaltungskompetenz im Requirements Engineering.
• Nicht zuletzt geht es auch um das Image des Berufsbilds. Gestaltung ist eine hochkreative Tätigkeit, die, wie oben dargestellt, von den Requirements Engineers ausgeübt wird. „Anforderungen schreiben und verwalten“ wird dieser qualitätsvollen Tätigkeit nicht gerecht. Nicht zuletzt deshalb kommt es – etwa in den agilen Ansätzen – zur Ansicht, dass diese Tätigkeit überhaupt verzichtbar ist. Diese Meinung ist insofern nachvollziehbar, als möglicherweise keine Rolle erforderlich ist, die Anforderungen sammelt und dokumentiert. Gestaltung aber passiert immer – und es ist vorteilhaft, wenn es eine Rolle gibt, die explizit dafür zuständig ist.
• Und schließlich wird dadurch eine klare Zuständigkeit für die Gestaltungskompetenz in einem IT-Projekt definiert. Gestaltung passiert nicht mehr zufällig, sondern planmäßig und gezielt.

Fazit

Man kann nicht nicht gestalten – auch und gerade in IT-Projekten. Umso erstaunlicher ist es, dass die Gestaltungskompetenz in der Softwareentwicklung so wenig thematisiert wird. Das Requirements Engineering ist aufgrund der Nähe sowohl zum fachlichen Problem als auch zur technischen Umsetzung prädestiniert für die Übernahme der Gestaltungskompetenz.
Obwohl viele Requirements Engineers in der Praxis diese Gestaltungsaufgabe übernehmen, steht in Literatur und Ausbildung das Schreiben und Verwalten von Anforderungen im Vordergrund. Hier wurde ein Ansatz aufgezeigt, der Requirements Engineering als geistigen, kreativen Prozess versteht – und somit einerseits den Gestaltungsbedarf in den IT-Projekten abdeckt, andererseits auch die tatsächliche Arbeit vieler Requirements Engineers besser beschreibt als andere Ansätze.

Literatur & Links

[IREB]
IREB Certified Professional for Requirements Engineering, Foundation Level, Lehrplan, 2017, siehe:
https://www.ireb.org/content/downloads/2-syllabus-foundation-level/ireb_cpre_syllabus_fl_de_v221.pdf

[Lies20]
J. Lies, Unternehmenskultur, in: Gabler Wirtschaftslexikon, siehe:
https://wirtschaftslexikon.gabler.de/definition/unternehmenskultur-49642#definition

[Rob13]
S. und J. Robertson, Mastering The Requirements Process, Pearson Education, 2013

[Rupp17]
J. Rupprecht, Der kreative Prozess unter der Lupe, siehe:
https://www.julia-training.com/blog/2017/2/27/der-kreative-prozess-unter-der-lupe

[Wall26]
G. Wallas, The Art of Thought, 1926