KI im Requirements Engineering: Das neue IREB Micro-Credential AI4RE

Bereits im Dezember 2025 hatten wir darüber berichtet, dass das International Requirements Engineering Board (IREB) die Pilotphase seines neuen Micro-Credentials AI4RE gestartet hat.
Damals standen bereits Syllabus, Study Guide und ein erstes Self Assessment zur Verfügung.

Jetzt steht fest der offizielle Start der Prüfungen zum Erlangen des Micro-Credentials ist der 1. März 2026. Wenn Sie die Prüfung erfolgreich ablegen möchten, unterstützen wir Sie gerne mit unserem KI-Training

Was ist das AI4RE Micro-Credential?

AI4RE ist ein kompaktes, praxisorientiertes Lernformat innerhalb des CPRE-Ökosystems, das sich gezielt auf den verantwortungsvollen und effizienten Einsatz von KI im Requirements Engineering konzentriert. In der Abbildung wird verdeutlicht, dass das Micro-Credential als Ergänzung der bisherigen Zertifizierungen existieren wird:

CPRE und Add ons (Quelle: IREB, https://cpre.ireb.org/de/concept, zuletzt aufgerufen 02.03.2026)
Abb 1: CPRE und Add ons (Quelle: IREB, https://cpre.ireb.org/de/concept, zuletzt aufgerufen 02.03.2026)

In unserem früheren Blogbeitrag hatten wir bereits über das Micro-Credential und dessen Inhalte berichtet.

Was bedeutet das Micro-Credential für RE-Praktikerinnen und -Praktiker?

Das Micro-Credential bietet einen ideal strukturierten Einstieg in die Welt der KI im Requirements Engineering. Es befähigt Sie, KI-Technologien gezielt, effizient und dennoch verantwortungsvoll in Ihren RE-Prozessen einzusetzen.
Damit passt es hervorragend in den aktuellen Wandel des Requirements Engineerings – ein Wandel, den wir bei SOPHIST nicht nur begleiten, sondern aktiv mitgestalten zum Beispiel durch unser Buch „KI im Requirements Engineering“.

So unterstützt Sie SOPHIST noch besser: Unser KI-Trainings

Während AI4RE eine ausgezeichnete inhaltliche Basis bietet, setzen wir bei SOPHIST in unserem praxisorientierten KI-Trainings bewusst dort an, wo viele REler im Alltag konkrete Unterstützung benötigen. Wir machen damit den Inhalt des Micro-Credentials praktisch erlebbar, zum Beispiel mit folgenden Themen:
• praktische Übungen zum Einsatz von KI
• methodische Hilfestellungen im Umgang mit KI-Tools
• Reflexion über Risiken, Verantwortlichkeiten und sinnvolle Einsatzgrenzen

Als Vorbereitung kann das Self-Assessment des IREB hilfreich sein. Dann haben Sie bereits eine Orientierung und können offene Fragen ins Training mitbringen.
Gerne gestalten wir mit Ihnen auch ein individuelles Training, das auf Ihre Bedürfnisse abgestimmt ist.
Unsere Trainingsadministration steht Ihnen dabei gerne zu Seite.
Mit unserem Training sind Sie also exzellent vorbereitet, um die Prüfung für das Micro-Credential erfolgreich zu absolvieren.

Für alle, die es noch genauer wissen wollen: Das KI-Buch von SOPHIST

Wenn Sie neben dem Micro Credential und unserem Training noch tiefer in die Materie eintauchen möchten, empfehlen wir Ihnen unser Buch: „KI im Requirements Engineering“.
Dort finden Sie:
• tiefgreifende fachliche Erklärungen von KI und deren Nutzen im RE
• methodische Leitlinien, wie KI effizient und verantwortungsvoll im RE eingesetzt werden kann
• Musterprompts und Einordnung der KI-generierten Ergebnisse
• Zugang zu einer Onlineplattform, damit Sie auf dem neusten Stand beim Thema KI bleiben

Wenn Sie das volle Potenzial von KI im Requirements Engineering ausschöpfen möchten, sprechen Sie uns gerne an. Wir freuen uns darauf, Sie auf Ihrem Weg zu unterstützen.

E-Mail: Vertrieb@sophist.de
Tel.: +49 (0)9 11 40 90 00

Wenn das Licht im Projektraum ausgeht – Teil 2

Wer entscheidet, was die KI sehen darf?

Im ersten Beitrag dieser Serie haben wir den dunklen Projektraum als Gedankenexperiment beschrieben. KI übernimmt operative Tätigkeiten im Entwicklungsprozess. Dokumente werden analysiert, Varianten verglichen, Anforderungen identifiziert. Der Raum wirkt leerer, obwohl intensiv gearbeitet wird.

Doch je mehr automatisiert wird, desto wichtiger wird eine andere Frage:

Wer setzt die Leitplanken?

Auch im dunklen Projektraum arbeitet KI nicht im luftleeren Raum. Sie braucht Orientierung. Welches System soll entstehen? Wo liegen seine Grenzen? Welche Rahmenbedingungen gelten? Ohne diese Einordnung entsteht schnell ein Ergebnis, das formal korrekt wirkt und gleichzeitig an den tatsächlichen Bedürfnissen der Stakeholder vorbeigeht.

KI arbeitet immer innerhalb eines bestimmten Kontexts. Und dieser Kontext entsteht nicht zufällig. Er wird gesetzt.

Nehmen wir an, in der Organisation wird entschieden, ein Fahrzeug für einen bestimmten Markt zu entwickeln. Diese Entscheidung kann im Business Case getroffen, im Entwicklungsauftrag dokumentiert oder im Gespräch mit dem Auftraggeber abgestimmt worden sein. Auf dieser Grundlage soll die KI regulatorische Anforderungen identifizieren.

Bleibt dabei offen, für welchen Markt und welchen Zeitraum das Fahrzeug vorgesehen ist, wird die KI mit allgemein bekannten oder global verbreiteten Regelwerken arbeiten.

Wird hingegen für die Entwicklung des Fahrzeugs klar festgelegt:

„Zielmarkt Europa, Markteinführung ab 2030“,

verändert sich auch das Ergebnis der Analyse. Die KI identifiziert nun vorrangig europäische Richtlinien, Typgenehmigungsverfahren sowie spezifische Sicherheits- und Umweltvorgaben. Vorschriften anderer Märkte treten in den Hintergrund. Zudem werden zeitliche Aspekte relevant wie etwa geplante Gesetzesänderungen bis 2030.

Das Ergebnis ist also nicht nur sprachlich präziser. Es enthält andere regulatorische Quellen, priorisiert andere Normen und macht andere Risiken sichtbar. Entsprechend entstehen andere Anforderungen an Architektur, Nachweisführung oder Tests.

Nicht die KI ist präziser geworden.

Der Kontext ist präziser geworden.

Es geht dabei weniger um „Prompt Engineering“, sondern um „Context Engineering“: Welche Rahmenbedingungen gelten? Welche Märkte sind relevant? Welche Annahmen sind verbindlich? Die Inhalte des Kontexts sind eine bewusste Entscheidung. Sie bestimmen, welche Aspekte der Realität berücksichtigt werden und welche nicht.

Kontext definiert damit den Gestaltungsraum eines Systems. Er legt fest, welche Funktionen vom System selbst umgesetzt werden sollen und welche als Bestandteil der Umgebung gelten. Er entscheidet, welche gesetzlichen Vorgaben verbindlich sind, welche Geschäftsprozesse unveränderlich bleiben und wo Gestaltungsspielraum besteht.Diese Abgrenzung ist keine technische Detailfrage, sondern eine fachliche und organisatorische Entscheidung. KI kennt diese Grenzen nicht. Sie kennt nur die Informationen, die innerhalb dieses gesetzten Rahmens verfügbar sind. Systemgrenzen ergeben sich nicht automatisch aus Daten. Sie werden auf Basis von Informationen bewusst festgelegt.

Die Idee der Dark Factory verdeutlicht dieses Prinzip: Hochautomatisierte Systeme produzieren keine beliebigen Produkte. Dass dort Autos gefertigt werden und keine Fahrräder, ist keine statistische Ableitung, sondern eine klare Zwecksetzung. Automatisierung bewegt sich immer innerhalb gesetzter Leitplanken. Im Requirements Engineering ist es nicht anders.

Kontext bedeutet auch Begrenzung

Kontext bereitzustellen heißt nicht nur, Informationen hinzuzufügen. Es heißt vor allem, bewusst etwas wegzulassen.

Aktuelle KI-Modelle unterliegen einem Tokenlimit1. Nur eine begrenzte Menge an Text kann gleichzeitig verarbeitet werden. Wer mit KI arbeitet, muss auswählen und priorisieren. Technische Grenzen machen sichtbar, was im Requirements Engineering schon immer galt: Nicht der gesamte Kontext des Produkts ist für jede Aufgabe relevant. Wer an der Bremssteuerung arbeitet, benötigt in der Regel nicht alle Detailanforderungen zur Gestaltung des Infotainment-Displays, sondern nur die Schnittstellen und Abhängigkeiten, die seine Aufgabe betreffen. Die bewusste Auswahl relevanter Informationen ist Teil der System- und Kontextabgrenzung und damit eine Kernaufgabe im Requirements Engineering.

Verfahren wie Retrieval-Augmented Generation (RAG)2 erweitern diesen Rahmen, indem Dokumente außerhalb des aktuell verarbeiteten Kontextes gezielt abgerufen und in die Bearbeitung einbezogen werden. Doch auch hier entscheidet jemand, welche Quellen angebunden werden und welche nicht. Die Auswahl bleibt eine fachliche Entscheidung.

Kontext umfasst dabei weit mehr als Dokumente. Er beinhaltet Begriffe, Schnittstellen, Rollen, Prozesse und Annahmen. In der klassischen Entwicklung entsteht dieses Verständnis häufig implizit. Ein Architekt kennt die Nachbarsysteme. Eine Produktverantwortliche kennt strategische Ziele.

KI kennt Kontext nur, wenn er explizit gemacht wird. Menschen hingegen erkennen Lücken. Sie merken, wenn Annahmen unsicher sind, und können entscheiden, ob sie nachfragen oder das Risiko bewusst tragen. Eine KI arbeitet mit dem gegebenen Ausschnitt, ohne zu wissen, ob er vollständig ist. Sie verarbeitet Informationen. Sie bewertet nicht, ob der gewählte Kontext der richtige ist.

Grauzonen verschwinden nicht automatisch Im Requirements Engineering bewegen wir uns häufig in Grauzonen. Anforderungen sind nicht immer eindeutig abgegrenzt. Begriffe wie „international einsetzbar“ oder „rechtssicher“ bleiben ohne Einordnung interpretationsfähig. Eine Grauzone entsteht, wenn unklar ist, was eigentlich Teil des Systems ist und was zur Umgebung gehört. Gehört eine Funktion ins System? Oder wird sie durch ein Nachbarsystem bereitgestellt? Ist eine Vorschrift wirklich relevant? Grauzonen sind kein Fehler. Sie sind Entscheidungsräume. Und sie müssen im Verlauf der Entwicklung bewusst geklärt oder zumindest transparent gemacht werden. Manche werden aufgelöst, andere werden als Risiko dokumentiert oder vorläufig akzeptiert. Nicht zu entscheiden ist ebenfalls eine Entscheidung.

Wenn unklar ist, ob eine Funktion intern entwickelt oder extern genutzt wird, geht es nicht nur um Modellierung. Es geht um Verantwortung, Kosten, Haftung und strategische Positionierung. Eine KI erkennt diese Tragweite nicht automatisch. Sie verarbeitet vorhandene Informationen und trifft eine statistisch plausible Annahme. Ob diese Annahme unternehmerisch gewollt ist, kann sie nicht wissen. Wer eine Grauzone nicht bewusst adressiert, überlässt die Entscheidung potenziell implizit dem Modell.

Genau hier liegt die Rolle des Requirements Engineer: Er entscheidet, welcher Ausschnitt der Realität relevant ist, welche Annahmen gelten und welche bewusst ausgeschlossen werden. Die eigentliche Frage lautet daher nicht, wie viel eine KI verarbeiten kann, sondern wer entscheidet, was sie verarbeiten soll.

Wie könnte sich das entwickeln?

Mit zunehmender Integration in z.B. Anforderungsmanagement-Tools, Architektur-Repositories oder Dokumentationssysteme könnten KI-Systeme künftig auf umfangreiche Entwicklungsdaten, Modelle und regulatorische Informationen zugreifen. Doch selbst wenn technische Grenzen weniger relevant werden, bleibt die entscheidende Frage bestehen:

Soll die KI alles wissen?

Nicht alles, was vorhanden ist, ist automatisch relevant. In vielen Organisationen sind Informationen bewusst getrennt – aus strategischen, rechtlichen oder politischen Gründen. Kontext ist daher nicht nur eine technische, sondern auch eine Governance-Entscheidung. Je leistungsfähiger KI wird, desto wichtiger werden klare Leitplanken.

Verantwortung wird sichtbarer

Je überzeugender KI-Ergebnisse wirken, desto leichter entsteht der Eindruck, sie seien objektiv oder vollständig. Doch KI kann nur innerhalb des Kontexts arbeiten, den wir definieren und der technisch überhaupt verfügbar ist (z.B. wegen der Limitierung von Tokens). Sie analysiert, strukturiert und bewertet – aber sie entscheidet nicht, welcher Ausschnitt der Realität gelten soll.

Wer Kontext nicht bewusst gestaltet, trifft dennoch eine Entscheidung – nur eben unbeabsichtigt.

Und je überzeugender KI-Ergebnisse wirken, desto weniger wird hinterfragt, auf welcher Kontextentscheidung sie beruhen. In unserem dunklen Projektraum verschwindet Verantwortung nicht. Sie wird sichtbarer. Bevor die KI arbeitet, wurde bereits festgelegt, welche Informationen sie erhält und welche nicht.

Und wie gehen Sie damit um?

Wie bewusst treffen Sie heute Kontextentscheidungen? Welche Märkte, welche Stakeholder, welche Annahmen gelten bei Ihnen – und welche nicht? Oder verlassen Sie sich darauf, dass die KI „schon das Richtige findet“?

Vielleicht liegt genau hier die eigentliche Verschiebung im Requirements Engineering:
Nicht die Formulierung von Anforderungen wird komplexer – sondern die bewusste Gestaltung des Kontextes, in dem KI arbeitet.

Wir sind überzeugt: Die Zukunft des Requirements Engineering liegt nicht nur in vollständiger Automatisierung, sondern auch in der klaren Verantwortung für den Kontext.

Sie sehen das anders? Oder möchten unsere Gedanken weiterdenken? Dann lassen Sie uns ins Gespräch kommen. Wir zeigen Ihnen gern, wie wir bei SOPHIST Kontextentscheidungen in realen Projekten strukturieren – und wie Sie Ihrer KI gezielt den richtigen Kontext vermitteln.
→ Gespräch vereinbaren

Wenn Sie tiefer einsteigen möchten, finden Sie im Buch „KI im Requirements Engineering – Werkzeuge und Techniken für den Einsatz in der Praxis“ eine systematische Einordnung entlang der klassischen RE-Tätigkeiten.

Zum Buch

Und wenn Sie KI im Requirements Engineering nicht nur diskutieren, sondern konkret erproben möchten: In unseren Trainings arbeiten wir praxisnah an genau diesen Fragestellungen.
Zu den Trainings

Im nächsten Beitrag dieser Serie betrachten wir, wie Anforderungen entstehen, wenn KI an der Ermittlung beteiligt ist – und warum Anforderungsermittlung weit mehr ist als das Extrahieren von Text

  1. Tokenlimit
    Sprachmodelle verarbeiten Texte nicht als Wörter, sondern als sogenannte Tokens. Ein Token kann ein Wort, ein Wortteil oder ein Satzzeichen sein. Die Anzahl der Tokens, die ein Modell gleichzeitig berücksichtigen kann, ist technisch begrenzt. Diese Begrenzung beeinflusst, wie viel Kontext in einer Anfrage verarbeitet werden kann.
     
    Eine verständliche Einführung bietet die OpenAI-Dokumentation:

    https://help.openai.com/de-de/articles/4936856-what-are-tokens-and-how-to-count-them ↩︎
  2. Retrieval-Augmented Generation (RAG)
     
    RAG ist ein Verfahren, bei dem ein Sprachmodell nicht nur auf sein internes Trainingswissen zurückgreift, sondern zusätzlich gezielt externe Dokumente abruft und in die Antwortgenerierung einbezieht. Dadurch können größere Wissensbestände dynamisch eingebunden werden, ohne dauerhaft im Modell gespeichert zu sein.
     
    Eine verständliche Erklärung findet sich in der OpenAI-Dokumentation:
     
    https://help.openai.com/de-de/articles/8868588-retrieval-augmented-generation-rag-and-semantic-search-for-gpts
      ↩︎

Ein Abend im VR-Universum: Unser Teamevent bei Sandbox VR

Manche Abende fühlen sich an wie ein Perspektivwechsel. Statt vertrauter Umgebung stand diesmal futuristische Weltraumaction auf dem Programm. Bei Sandbox VR Nürnberg in Stein tauchte unser Team in das Sci-Fi-Abenteuer Amber Sky 2088 ein – als Androiden mit einer klaren Mission: die Erde vor einer Alien-Invasion zu verteidigen.

Weiterlesen

Aus Alt mach Neu – Wie das DMS im Finanzbereich der BA modernisiert wurde

Wenn ein System in die Jahre kommt, fängt die eigentliche Arbeit oft erst an. So war es auch beim Projekt „DMS#finanzen“ der Bundesagentur für Arbeit. Ein Senior Berater, Christian Pikalek, durfte dieses Projekt als Lead-Analytiker begleiten – eine Freude und Herausforderung zugleich. Das Ziel war klar: Ein über Jahrzehnte gewachsenes Archivsystem im Finanzbereich – insbesondere im Inkasso – sollte abgelöst werden.

Weiterlesen

Wenn das Licht im Projektraum ausgeht – Teil 1 

Warum KI das Requirements Engineering nicht verdunkelt, sondern neu ausleuchtet 

In der industriellen Fertigung wird seit Jahren über sogenannte „Lights-out-Fabriken“ oder „Dark Factories“ diskutiert. Gemeint sind Produktionsumgebungen, in denen Maschinen nicht nur fertigen, sondern auch planen, optimieren und anpassen, weitgehend ohne menschliches Eingreifen.1 Was lange futuristisch klang, ist inzwischen Realität. 

Weiterlesen