1994 war ich verzweifelt: Bei einem Versicherungskunden stritten sich zwei benachbarte Abteilungen um das „richtige“ Objektmodell für die Schadenbearbeitung. Was die einen einbrachten, fanden die anderen falsch. Und umgekehrt. Zum Glück bekam mein Team damals einen Hinweis auf die Qualitätsnorm ISO 9000 [1]. Danach haben wir mit beiden Abteilungen nicht mehr über das Objektmodell gesprochen, sondern nur noch über ihre Anforderungen. Und wie sie mit Akzeptanzkriterien (AK = Beispiel = Testfall) prüfen wollen, ob ihre Anforderungen erfüllt sind. Problem gelöst.
Requirements bringen Messbarkeit
So haben Anforderungen das Projekt gerettet. Und Messbarkeit gebracht.
Präzise: Deshalb haben wir beim nächsten Kunden das Objektmodell mit OOA (objektorientierte Analyse) entworfen und in Smalltalk programmiert [2] (Java gab es noch nicht). Und das Modell anhand der Akzeptanzkriterien funktional überprüft (simuliert). Mit automatisierten Tests. Ebenfalls in Smalltalk. Danach wussten wir: Das Objektmodell ist richtig, weil es alle Anforderungen erfüllt. Dann wurde alles in COBOL programmiert, für einen Mainframe. Das Ganze hat drei Monate gedauert. Danach hatte die Gebäudeversicherung Baden-Württemberg (GVBW) eine Provisionsabrechnung für 2 Millionen versicherte Häuser. Ein ziemlich schnelles Projekt. Ohne Fehler im Produktionseinsatz. Ein völlig neues Gefühl bei Software: Zu wissen, dass alles richtig ist. Von Anfang an. Und warum.
Vollständig? Ob die Anforderungen auch vollständig waren? Das konnten wir damals nur hoffen, weil die vielen Beispiele (=AKs) das Thema Gebäudeversicherung von allen Seiten beleuchtet haben. Wir hatten aber Glück. Im Produktionseinsatz sind keine Lücken aufgetreten.
RE funktioniert gut bei 1 Wissensgebiet und n Stakeholdern
Damals hat sich gezeigt, dass Requirements gut geeignet sind, das Wissen von vielen Stakeholdern zum Wissensgebiet „Provisionsabrechnung für Elementar-Versicherungen bei der GVBW“ zusammenzutragen, zu dokumentieren und in einem Objektmodell zusammenzuführen. Weil dabei keine Widersprüche, Lücken oder Unsicherheiten aufgetreten sind, war das entstandene Objektmodell anscheinend eine präzise Beschreibung der Vorstellungen in den Köpfen der verantwortlichen Stakeholder. Gutes Bauchgefühl.
Vergleichbar mit einem Puzzle-Spiel, wenn jeder Stakeholder seine Puzzle-Teile auf den Tisch legt und anschließend alle gemeinsam die Teile zum ganzen Puzzle-Bild zusammenfügen. Das funktioniert gut. Doch es hat eine Voraussetzung: Das Projekt implementiert ein (i. W. eins) gemeinsames Wissensgebiet. Dazu weiter unten mehr, beim Stichwort „VUCA“.
Zero-Defect-Softwareentwicklung
In weiteren Projekten bei weiteren Kunden hat sich gezeigt: Das war kein Einzelfall. Das gezielte Zusammentragen von Requirements und AKs lässt sich verallgemeinern. Ebenso das Erstellen von Objekt-Modellen sowie deren Verifikation mithilfe der AKs und die Automatisierung aller Testfälle.
Besonders hilfreich waren die Fragen nach konkreten Akzeptanzkriterien. Sie haben zu gut dokumentierten Anforderungen geführt, die nachher von den Stakeholdern auch gerne verantwortet worden sind. Wer wirklich weiß, wovon er redet, der kann auch konkrete Beispiele geben für die manchmal sehr feinen Unterschiede zwischen richtig und falsch.
Die Fragen nach konkreten Akzeptanzkriterien haben uns auch die „Hubschrauber-Manager“ vom Hals gehalten (Einfliegen, Staub aufwirbeln, Abflug). Wir haben immer schnell die wirklichen Experten an den Tisch bekommen.
Anfangs wurde das Objektmodell noch „von Hand“ von Smalltalk nach COBOL übersetzt. In nachfolgenden Projekten konnten wir diesen Weg zunehmend automatisieren. Ein angenehmes „Abfall-Produkt“ war eine automatisierte Cross-Reference zwischen Anforderungen und den Elementen des Objektmodells [3]. Heute bietet sich KI (GenAI) zum Generieren an. Erste Versuche waren erfolgreich.
Verbindung zur Kognitiven Psychologie
Schon bald kam der Verdacht auf, dass Objektmodelle nicht nur den fachlichen Kern der zukünftigen Software beschreiben, sondern gleichzeitig auch die Vorstellung der Stakeholder über die Software.
Das war der erste Hinweis auf Digitale Zwillinge. Haben Sie, lieber Leser, schon einmal darüber nachgedacht, wie wohl der andere Zwilling aussehen mag, der nicht digitale? (Die Antwort finden Sie in der ISO-Norm 30173 [4]) Spoiler: Der andere, der Reale Zwilling ist laut ISO-Norm die Vorstellung in den Köpfen der Stakeholder. Die ISO nennt ihn „Target Entity“.
Eine weitere Folge war die Idee, dass Software möglicherweise so nah am Wissen, das heißt, an den Vorstellungen der Stakeholder erstellt werden kann, dass diese keine Abweichung mehr empfinden. Zwischen dem, was sie sich vorstellen, und dem, was sie als Verhalten ihrer Software wahrnehmen. Ich war damals so leichtsinnig, diese Wahrnehmung der Anwender als ein Indiz für „fehlerfrei“ zu bezeichnen. Das kam nicht gut an[5, 6].
Die kognitive Psychologie hilft auch bei vielen weiteren Fragen, die für uns alle damals noch offenbleiben mussten. Wie zum Beispiel: Sind die Anforderungen richtig? Vollständig? Noch aktuell? Wie merken wir frühzeitig, wenn sich Anforderungen ändern? Wie finden wir das relevante Wissen, die Hot-Spots in einer großen „gewachsenen“ Umgebung, einem sogenannten Brownfield [7]?
RE-Probleme bei >1 Wissensgebiet
Das bis hierher beschriebene Verfahren entfaltet seine beruhigende und vertrauensbildende Wirkung zunächst einmal innerhalb von Wissensgebieten.
Wenn für ein System aber mehr als 1 Wissensgebiet (WG) mit Requirements und AKs präzisiert werden soll, dann repräsentiert der zusammengetragene Berg von Anforderungen nicht mehr die Teile eines einzigen Puzzles, sondern eine Anhäufung von Teilen aus mehreren Puzzles. Die Puzzles hängen zwar irgendwie zusammen, doch jedes repräsentiert ein eigenständiges Wissensgebiet. In diesem Berg liegt nun aber alles durcheinander. Bunt gemischt.
Dabei ist es unerheblich, ob die weiteren Wissensgebiete (WGe) zur fachlichen Welt der Anwender gehören, zu technischen Teilen des Systems oder ob sie Wissen beschreiben, das beim Erstellen oder Benutzen des Systems beachtet werden muss (Box 1: „Vier Arten von Wissensgebieten“).
|
Der Klassiker sind (1) Wissensgebiete (WGe), die zur (fachlichen) Welt der Anwender gehören – eine Grundannahme beim Domain-Driven Design (DDD) nach Eric Evans. Beispiel: benachbarte Abteilungen. Seltener werden auch die (2) technischen WGe eines Systems mit RE präzisiert. Sie beschreiben (nicht fachliche) Techniken und deren Einsatz in einem System. Das wird zum Beispiel in „Evolutionary Architectures“ ([8], S. 10) beschrieben. Beispiele: Security, Latency, UX, Compliance, Cloud vs. On-premise usw. Zwei weitere Arten von Wissensgebieten, die für moderne Systeme wesentlich sind, werden bisher oft vernachlässigt, obwohl sie eigentlich sogar wichtiger sind als die ersten beiden; denn ohne den (3) Prozess für die Erstellung eines Systems gäbe es das System erst gar nicht. Und der volle Return für eine Investition in ein System entsteht erst dann, und auch nur dann, wenn alle Anwender alle (4) Nutzungsprozesse des Systems kennen und richtig befolgen. Wie wichtig Präzision bei diesen beiden Gruppen von Wissensgebieten ist, zeigt ein Projekt, über das im IT Spektrum schon berichtet wurde [7]: Von über 100 aufgedeckten Risiken lauerten 88 Prozent in den oben genannten Prozessen. Nur 12 Prozent in der Software. |
Wenn SW-Entwickler versuchen, einen solchen Berg von Anforderungen zu bewältigen, dann geht das selten gut aus. Der Frust, der daraus entstanden ist, hat mittlerweile sogar einen Namen: VUCA (Volatility, Uncertainty, Complexity und Ambiguity).
Hier eine kurze Vorstellung von VUCA, gleich mit Empfehlungen zum Vermeiden des Problems (siehe Box 2).
|
Google AI: „Das Konzept wurde ursprünglich vom US-Militär entwickelt und wird heute in Unternehmen und Organisationen verwendet, um auf die Notwendigkeit reagieren zu können, sich an eine sich schnell verändernde, unvorhersehbare und unklare Geschäftswelt anzupassen.“ Meine Meinung: Das Problem haben wir beim RE nicht. Es ist nicht die Aufgabe des RE, eine „Organisation an eine sich schnell verändernde … anzupassen“. Das ist die Aufgabe der Stakeholder (SH) aus dem Business. Wir im RE dokumentieren lediglich die Vorstellungen, die SH entwickelt haben, um die Organisation anzupassen, damit diese Vorstellungen präzise in die Systeme einfließen – in Software- und in Prozesssysteme. |
Den VUCA-Stier bei den Hörnern packen
Das Erste und Wichtigste ist: Wir erstellen nicht eine einzige große Anforderungssammlung, sondern jedes Wissensgebiet in unserem SW-System bekommt sein eigenes RE. Wie erkennen wir Wissensgebiete? Daran, dass die zugehörigen Stakeholder sich sofort untereinander verstehen. Und nicht lange über Begriffe und Details von Bedeutungen diskutieren.
Jetzt zu den Themen von VUCA:
Volatility: Ja, Anforderungen ändern sich oft schnell. Was dagegen hilft: Wir machen unsere Prozesse zum Verarbeiten von Anforderungen noch schneller. Am besten live. Das geht. Vielleicht auch mit KI. Probieren wir gerade aus.
Uncertainty: Stakeholder, die nicht wissen, was sie wollen, sollen sich entweder vom Projekt fernhalten oder akzeptieren, dass wir gemeinsam experimentell unterwegs sind. Und dafür auch das Budget bereitstellen. Und die Zeit. Unsicherheit verschwindet oft auch schon durch die getrennte, fokussierte Behandlung der verschiedenen Wissensgebiete. Ansonsten gilt: Wer nicht sagt, was er will, darf sich nicht wundern, was er bekommt. Bei KI heißen diese Fehler Halluzinationen.
Complexity: Für Stakeholder, die ihr Wissensgebiet verstehen, ist es niemals komplex (Cynefin-Framework). Höchstens kompliziert. Für Stakeholder, die es nicht verstehen: siehe oben unter Uncertainty. Zur Erinnerung: Wir versuchen hier nicht, eine (beliebig komplexe) Umgebung „richtig“ zu verstehen. Unsere Aufgabe beim RE ist, die vorhandenen Vorstellungen der Stakeholder zu dokumentieren. Und die können, weil jede von ihnen aus genau 1 Wissensgebiet kommt, höchstens kompliziert sein. Aber niemals komplex.
Ambiguity: Wenn wir die Wissensgebiete in unserem RE klar auseinanderhalten, dann tritt dieses Problem nicht auf. Wenn ein Stakeholder trotzdem uneindeutig bleibt: siehe Uncertainty.
Das größte Projekt, bei dem ich das RE verantwortet habe, hatte 100 Mitarbeiter, 4.000 Anforderungen und 11.000 AKs. Es war in 20 Wissensgebiete aufgeteilt und hat keins der VUCA-Symptome gezeigt. Nach seiner Fertigstellung ist es zur Grundlage des heutigen SAP-Hana-Moduls für die Immobilienverwaltung geworden. [3]
Zusammenfassung: VUCA beschreibt kein inhärentes Problem im RE, sondern die Symptome, die auftreten, wenn wir die Wissensgebiete eines Systems nicht klar auseinanderhalten, nicht getrennt bearbeiten und nicht präzise verbinden.
Große Systeme = n Wissensgebiete
Wenn wir akzeptieren, dass Software automatisiertes Wissen ist, das von Computern angewendet werden kann, wenn wir fordern, dass das Wissen in unserer Software bekannt, klar verantwortet und geprüft ist, dann liegt es nahe, dieses Wissen auch vollständig und präzise zu dokumentieren und seine Anwesenheit in der fertigen Software zu zertifizieren.
Dafür müssen wir unsere Prozesse anpassen:
- Wissensgebiete (WGe) einzeln (und im Zusammenhang) dokumentieren: Stakeholder, Anforderungen, AKs, Objektmodelle und Verifikation. (Nicht mehr 1x RE für alle Wissensgebiete gemeinsam; denn das führt zu VUCA)
- Integration der WGe nicht mehr auf Ebene der Requirements oder noch tiefer, in der Implementierung, sondern (kognitiv) auf der Ebene der Objektmodelle (= Wissensgebiete, s. u.).
Hierbei repräsentiert jedes Objektmodell ein WG innerhalb des Systems: für eine Software oder für einen Prozess. Aber passt dann alles noch korrekt zusammen? Arbeiten die Komponenten auch in der Summe „richtig“? Ein Bericht über den Nachweis der Korrektheit von zusammenwirkenden Komponenten stammt von der ECOOP 2003 [3].
Um 2000 herum hat Amazon die eigene IT nach ähnlichen Kriterien in Komponenten je Team gegliedert und die Komponenten über APIs verbunden [9]. Der Zugewinn an Flexibilität hat Amazons Weg vom anfänglichen Buch-Händler zum heutigen Alles-Händler erleichtert und beschleunigt.
Ungefähr zur selben Zeit hat die Depfa Systems, Mainz, mithilfe eines von mir geleiteten Teams ihre Immobilienverwaltung neu gestaltet [10]. Ebenfalls als abgeschlossene WGe, die einzeln implementiert und dann gezielt punktuell miteinander verbunden wurden.
Eine Frage, die in diesem Zusammenhang oft gestellt wird, betrifft das Risiko, dass wir auf diese Weise einige wichtige Verbindungen zwischen Wissensgebieten möglicherweise übersehen. Das haben wir bisher nicht beobachten können. Vielleicht deshalb nicht, weil sich die WGe durch ihre gegenseitigen Berührungspunkte von selbst zusammenfinden.
Gut geeignet für KI
Wenn man einer KI über gute Anforderungen, also genau genug und vollständig genug, mitteilt, wie die Ist-Situation aussieht und was erreicht werden soll, dann halluziniert sie praktisch nicht mehr. Und wenn es doch noch einmal vorkommen sollte, dann „fangen“ wir den Fehler sofort, weil ja alle Akzeptanzkriterien aller Anforderungen aus allen Wissensgebieten als automatisierte Tests vorliegen. Wenn wir dazu dann noch die Softwarearchitektur so gestalten, dass alle Tests in Millisekunden laufen, dann sind wir schon fast „live“ unterwegs. Ein Trend, den auch die „Evolutionary Architectures“ ([8], S. 69) beschreiben.
Wie oben bereits erwähnt, waren erste Versuche mit vier verschiedenen KI-Systemen bereits erfolgreich. Hier deutet sich eine Entwicklung an, die vermutlich noch an Dynamik gewinnen wird.
Copy & Paste-Codierung fällt weg
20 Jahre Erfahrung sind nicht dasselbe wie 1 Jahr Erfahrung, 19x wiederholt. Dieser Unterschied fällt auf, wenn KI im Haus ist. Denn bei Copy & Paste-Codierung ist KI einfach schneller und besser. KI ist ein fleißiger Kopierer, der Massenarbeiten gut erledigt. Doch ohne Hirn und ohne Plan. Beides, Hirn und Plan, müssen wir ergänzen, durch natürliche Intelligenz (NI).
„Computer machen die Arbeit, die kein Mensch verdient hat“. Mit diesem Spruch hat IBM schon 1976 in einer Mitarbeiterzeitschrift die eigenen Mitarbeiter beruhigt, wahrscheinlich, um sie gegen die beständigen Vorwürfe zu immunisieren, dass sie Arbeitsplätze wegrationalisierten.
Das ist kein neues Phänomen. Denn dasselbe gab es zum Beispiel auch schon vor 200 Jahren, als die Dampfmaschinen kamen. Auch damals wurden Produkte und Prozesse analysiert und aufgespalten. In automatisierbare Teile und andere, die NI brauchten:
- Die automatisierbaren Teile wurden automatisiert.
- Dadurch fielen Jobs weg.
- Die Preise sanken.
- Die Nachfrage stieg.
- Es wurde mehr produziert.
- Viele neue Jobs entstanden. Mehr als vorher weggefallen waren.
Dasselbe passiert jetzt in der IT, durch GenAI.
Fazit: viele neue Jobs, für SW-Architektur und Wissensdokumentation
Meiner Meinung nach werden von der heutigen SW-Entwicklung langfristig nur RE (Anforderungen und Akzeptanzkriterien = Tests) und Architektur bleiben. Ähnlich beschreibt es SAP. Doch RE wird irgendwann Wissensdokumentation heißen. Oder so ähnlich.
Dann wird RE nicht nur (wie 2025 noch üblich, z. B. bei DDD) für den fachlichen Kern von SW benutzt, sondern für alles. Für das Speichern von Daten, für das Benutzer-Erlebnis (UX), für Security, für die Nutzungsprozesse usw. Kurz: für alle Wissensgebiete, die bei SW und den Prozessen (vgl. Box 1) für ihre Erstellung und für ihre Nutzung eine Rolle spielen. Denn RE bringt Messbarkeit – bringt Präzision – bringt Qualität – bringt schnelle Produktion – bringt niedrige Preise – erhöht die Nachfrage nach individueller Software.
Deshalb werden – solange bei sinkenden Softwarepreisen die Nachfrage steigt – auch mehr Jobs für die Wissensdokumentation entstehen (heutiger Name: „Requirements Engineering“). Und für Architekten, die alle vier Arten von Wissensgebieten (s. o.) gestalten und miteinander verbinden.
Literaturangaben
[1] ISO 9000:1991 (Diese frühe Version der ISO 9000 hatte den Vorteil, dass Laien wie ich und mein Team sie direkt verstehen und umsetzen konnten. Neuere Versionen sind leider komplizierter)
[2] M. Rösch, Mit OOA die Qualität von Fachkonzepten verbessern, in: OBJEKTspektrum 2/94
[3] M. Rösch, Verification of Software Composed From Components, Workshop “Correctness of Model-based Software Composition (CMC)” zur European Conf. for OOP 2003 (ECOOP 2003), Datei als Volltext.pdf downloaden unter: https://publikationen.bibliothek.kit.edu/3152003/1533
[4] Digital Twins. https://www.iso.org/standard/81442.html. Liefert eine gute, weil kognitiv richtige Terminologie für das Beschreiben von Digitalen Zwillingen. Siehe auch: https://digitalezwillinge.com/re-literaturliste#iso30173
[5] M. Rösch, Muss Software wirklich Fehler haben?, in: OBJEKTspektrum 1/1998
[6] M. Rösch, Fehlerfreie Software durch wissensorientierte Softwareentwicklung, in: OBJEKTspektrum 1/2001
[7] M. Rösch, So wird ATAM schlank und schnell, in: IT Spektrum, 4/2023, siehe: www.sigs.de/artikel/so-wird-atam-schlank-und-schnell-vorwaerts-rueckwaerts-kontinuierlich/
[8] R. Parsons, P. Kua, N. Ford, Evolutionary Architectures, ThoughtWorks, 2017, siehe: https://nealford.com/downloads/Evolutionary_Architectures_by_Neal_Ford.pdf
[9] Amazon, The BIG Mandate. The Secret to Amazon's Success – Internal APIs, siehe: https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
[10] M. Wrede, O. Merkert, C. Szallies, Das Projekt “Blue Eagle”, in: OBJEKTspektrum 3/2001
Da einige der zitierten Quellen z.Zt. nicht im Internet veröffentlicht sind, finden Sie eine Zusammenstellung aller Quellen, mit Erläuterungen zu den einzelnen Quellen, unter digitalezwillinge.com/re-literatur/.
