Large Language Models (LLMs) haben in den letzten Jahren beeindruckende Fortschritte gemacht und eröffnen neue Möglichkeiten in der Technologiebranche. In diesem Artikel beleuchten wir, was LLMs bereits leisten können, wo ihre Grenzen liegen und welche Auswirkungen dies auf das Requirements Engineering hat. Dabei unterscheiden wir bewusst zwischen dem oft als Marketingbegriff verwendeten “KI” und den tatsächlich genutzten LLMs.

Wie funktionieren LLMs?

LLMs basieren hauptsächlich auf statistischen Wahrscheinlichkeiten. Sie erzeugen Texte, indem sie den wahrscheinlichsten nächsten Token auswählen, ohne dabei über ein echtes Verständnis oder Bewusstsein zu verfügen. Logik oder ein echtes Gedächtnis haben sie nicht. Ihre Ausgaben können beeindruckend wirken, folgen jedoch stets den Wahrscheinlichkeiten der Daten, auf denen sie trainiert wurden – auch bei fortschrittlichen Modellen wie o1 (Strawberry) von OpenAI.

Ein interessantes Phänomen bei LLMs sind sogenannte emergente Fähigkeiten. Bei größeren Modellen treten plötzlich unerwartete Fähigkeiten auf, wie etwa einfache Berechnungen oder das Befolgen komplexer Anweisungen, die ursprünglich nicht explizit trainiert wurden. Diese Fähigkeiten entstehen durch die enorme Menge an Trainingsdaten und lassen die Modelle intelligenter erscheinen, als sie tatsächlich sind. Ein gutes Beispiel sind auch die aktuellen Bildgenerierungsmodelle. Man sieht, wenn man genau hinschaut, dass unter dem Schweif vom Fuchs noch eine Pfote herauswächst, da dieser dunkle Fleck in einem der letzten Iterationen „am wahrscheinlichsten“ eine Pfote war. Dass der Fuchs schon vier Pfoten hat, „weiß“ das Modell nicht.

LLMs im Requirements Engineering

Im Bereich des Requirements Engineering stellen LLMs keine Bedrohung für spezialisierte Arbeitsplätze dar. Vielmehr können sie bestimmte Aufgaben unterstützen, wie das Umschreiben und Umformulieren von Texten. Ein LLM könnte beispielsweise aus einem einfachen Satz eine ausführliche User Story generieren. Dennoch bleibt der Requirements Engineer unverzichtbar, da LLMs nicht in der Lage sind, implizites Wissen aus Erfahrung und Kontext zu erfassen.

LLMs bieten Vorschläge und unterstützende Texte, die anschließend von Fachleuten angepasst werden können. Sie können jedoch nicht eigenständig denken oder logische Schlussfolgerungen ziehen. Ihre Stärke liegt in grundlegenden Aufgaben: Sprache umformulieren, Texte strukturieren und ähnliche Tätigkeiten. Die finale Kontrolle und Entscheidung über die Vollständigkeit und Korrektheit von Anforderungen muss weiterhin dem Menschen obliegen – aus Sinnhaftigkeit und Haftungsgründen, sowie um dem EU AI Act zu genügen, der diese Kontrolle als Grundbedingung hat.

Einsatzmöglichkeiten und Grenzen von LLMs

LLMs haben mehr oder weniger das gesamte Internet „gelesen“ und können auf eine immense Menge an Textdaten zugreifen, einschließlich Wikipedia (was angeblich, in allen Sprachen und im gesamten Inhalt, ca. 3% der Trainingsdaten von GPT-4 ausmacht) und anderen Quellen. Dies ermöglicht es ihnen, beispielsweise User Stories in verschiedenen Sprachen zu formulieren oder Texte im Stil bestimmter Personen umzuschreiben.

Dennoch neigen Menschen dazu, die Fähigkeiten von LLMs zu überschätzen. Es ist wichtig zu verstehen, dass diese Modelle lediglich statistische Wahrscheinlichkeiten aneinanderreihen und nicht wirklich wissen, was sie sagen. Ein LLM kann Texte in User Stories umwandeln und ähnliche Geschichten hinzufügen, aber es kann keine logischen Schlussfolgerungen ziehen oder fehlende Informationen eigenständig ergänzen.

Mit einem kurzen Beispiel wollen wir zeigen, wie der Code aussieht, um sich bspw. Epics und Personas vorzuschlagen lassen – in einem automatisiert verarbeitbaren Format:

Die LLM wird hier angewiesen, in JSON-Format zu arbeiten, wodurch es in jeder Programmiersprache leicht weiter verarbeitbar wird. Das exakte Format wird noch vorgegeben – mit \n werden Zeilenumbrüche eingefügt, die der LLM (trotz des „Es ist ja nur eine Maschine“-Faktors) manchmal hilft, die Struktur zu verstehen. Die LLM versteht Platzhalter wie <name> in solchen Anweisungen sehr gut.

Als Ergebnis bekommt man dann sowas wie hier:

Die LLM gibt hier auch brav die Sätze aus, die sie „verwendet“ hat, um diese Epics und Personas zu erstellen. Das ist allerdings ein Trugschluss, da eine LLM kein Gedächtnis oder Working Memory hat – die „contained Sentences“ werden also nur aufgrund des momentanen Status der LLM ausgegeben, und dabei wird einfach wieder der wahrscheinlichste Weg gewählt. Wichtiges Fazit daraus: Man darf sich nicht darauf verlassen, dass diese Sätze wirklich die Sätze sind, die zu dieser Schlussfolgerung geführt haben. Das Stichwort dazu heißt Explainable AI, woran momentan stark geforscht wird, was aber in so großen Sprachmodellen (noch) nicht möglich ist.

Noch klassisches Beispiel sind Datenbankstrukturen. Fragt man ein LLM nach einer Datenbankstruktur für eine allgemeine App, mit der man zum Beispiel Essen bestellt, bekommt man ziemlich gute Antworten. Doch sobald die Frage spezifischer oder technischer wird, wird das Modell wahrscheinlich weniger präzise antworten. Es sei denn, man stellt den Kontext und detaillierte Informationen bereit, die vom LLM wieder in (vermutete bzw. probabilistische) Zusammenhänge gebracht werden können. Dabei hilft es, wenn man dem LLM als Output bspw. mitgibt, dass es Mermaid-Code ausgeben soll – eine einfache Art, Diagramme als Text zu beschreiben, die man dadurch aber auch noch leicht editieren kann. Es gibt einige Webseiten, wie bspw. https://mermaid.live/, mit denen man dann das Ergebnis ansehen und als Bild herunterladen kann.

Ein weiteres Beispiel sind Akzeptanzkriterien – diese sind oft entscheidend für die Abnahme beim Kunden. Man kann hier mit einfachen Prompts Vorschläge vom Modell erhalten und diese anpassen. Dazu benötigt es nur einen kurzen sogenannten „System Prompt“, der dem LLM erklärt, was es tun soll, bspw.: „Du bist erfahrener Requirements Engineer. Ich schreibe dir gleich eine allgemeine Beschreibung des Projekts und dann eine User Story. Bitte schlage mir im Aufzählungsformat einige Akzeptanzkriterien für diese User Story vor.“. Danach muss man nur mehr die Beschreibung vom Projekt (um der LLM mehr Kontext zu geben) und die User Story einfügen, und man erhält wirklich sehr brauchbare Beispiele.

Compliance und Datenschutz

Beim Einsatz von LLMs in Arbeitsprozessen bestehen oft Bedenken hinsichtlich Compliance und Datenschutz. Viele Unternehmen sind unsicher, wie sie mit diesen Technologien umgehen sollen. Dafür gibt Lösungen, wie das Hosting lokaler Modelle und die Anbindung an private Endpoints, sodass keine sensiblen Daten in die Cloud gesendet werden müssen. Es gibt auch datenschutzfreundliche Optionen über europäische Rechenzentren (z.B. nlpcloud, Azure Europe).

Gemäß den EU-Vorgaben müssen automatisierte Prozesse stets unter menschlicher Aufsicht ablaufen. Jede Automatisierung muss nachvollziehbar sein, um Risiken kontrollieren zu können. Generierte Bilder und Texte müssen zwar gekennzeichnet werden, aber nur, wenn ein KI-System benutzt wird das „[…] Text generiert oder manipuliert, der zu dem Zweck veröffentlicht wird, die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren“.

Im Requirements Engineering bedeutet dies, dass KI-unterstützte Prozesse möglich sind, aber die finale Entscheidung und Kontrolle beim Menschen verbleibt.

Warum haben wir das untersucht?

Anfänglich entwickelten wir, gefördert von Forschungsgeldern der FFG sowie später der AWS, eine eigene KI, die bereits gute Ergebnisse lieferte. Mit dem Erscheinen von GPT-3.5 erkannten wir jedoch, dass wir durch die Anbindung an externe LLM-APIs, wie die von OpenAI, noch bessere Resultate erzielen konnten. Heute kann man jede Menge LLMs anbinden – von LLama 3.2 zu Claude oder anderen, die auch on Premises, also im eigenen Netzwerk und unter eigener Aufsicht, benutzbar sind. Die Wahl des Modells ist nebensächlich – wichtig ist die strukturierte Ablage, die über Versionen und Verknüpfungen eine sinnvolle Verarbeitung erlaubt. Um das zu ermöglichen, haben wir eine Software namens storywise (https://storywi.se) gebaut, die eine sinnvolle Struktur mit den genannten LLM-Anbindungen (und mehr) verbindet.

Fazit

Der Einsatz von LLMs („KI“) dient als Unterstützung und Ergänzung, wobei die Verantwortung und das Gesamtverständnis beim Engineer verbleiben. Der EU AI Act verlangt: jede Automatisierung muss nachvollziehbar sein und ein Mensch muss jede „Entscheidung“ bzw. die Ausgabe einer LLM kontrollieren.

DI Simon A. T. Jiménez, MA hat Softwareentwicklung sowie Mediation, Negotiation & Conflict Management studiert und ist seit 20 Jahren selbstständig – und hat dabei immer wieder mit schlechten Anforderungen gekämpft. Als Techniker versucht er jetzt, ein Menschen-Problem mit Software etwas zu unterstützen und hat daher mit einen Mitstreitern die Software storywise gegründet.