Traue keiner KI, die du nicht selbst trainiert hast!

Nichts ist für mich, als ausgebildeten Anforderungsingenieur, mehr verwirrend, als ein Referent auf einer Konferenz, der ein KI-gestütztes Werkzeug präsentiert und dabei mehrfach die Konformität zum INCOSE-Standard betont – obwohl er nahezu im selben Moment einen kapitalen Fehler als Qualitätsverbesserung verkaufen möchte. Unterstützt von dem entwickelten KI-Werkzeug schauen alle zu und keiner zweifelt es an, weil eine KI ja schließlich keine Fehler macht. Unglaublich ...

Der Schein trügt: Wenn das KI-Tool den Fehler zementiert

Das eigentliche Ziel war es den Zuhörern zu zeigen, wie einfach mittels des Einsatzes eines KI-basierten Werkzeugs die Qualität der Anforderungen bereits beim Schreiben verbessert werden kann. Doch im Grunde war genau das Gegenteil der Fall.

Der Referent nutzte hierfür ein einfaches Beispiel (analog zu dem hiergezeigten Beispiel in Siemens Polarion ALM):

Das gezeigte Element WI-440 vom Typ Anforderung ist nach dem INCOSE-Standard, aber auch nach jedem anderen etablierten Regelwerk, massiv verbesserungswürdig. Der Grund: Es handelt sich hierbei um ein Anforderungselement, das zwar formal einen Satz beinhaltet, inhaltlich aber eigentlich vier verschiedene Anforderungen versteckt.

Das KI-Werkzeug gab den Hinweis, diesen einen verschachtelten Satz aufzutrennen. Der Referent folgte der Empfehlung und hat aus dem ursprünglichen Satz vier einzelne Anforderungen formuliert.

Leider befanden sich die vier Anforderungen weiterhin in ein und demselben Anforderungselement WI-440 – und dazu noch in Aufzählung-Form. Das KI-Werkzeug des Referenten war hiermit bereits wunschlos glücklich.

Was soll ich sagen…? Vier unterschiedliche Anforderungen in einem einzigen Element, selbst wenn sie in unterschiedlichen Sätzen stehen, sind aus meiner Sicht genauso falsch wie vier Anforderungen in einem einzigen Satz. Warum?

Die Stolperfalle in der Praxis: Traceability und Test Coverage

Gehen wir einmal davon aus, dass wir zu jeder Anforderung mehrere Test Cases schreiben und diese mit der Anforderung verlinken. Das Ziel: Jeder Projektmitarbeiter, und ganz besonders der Qualitätsingenieur und der Projektleiter, sollen jederzeit den lückenlosen Nachweis der Traceability bzw. der Requirements Coverage sehen können.

Wenn es nun bei der Testdurchführung ausgerechnet zur letzten Anforderung – zum Beispiel dem Versand einer Bestätigungs-E-Mail – zu einem Fehler kommt, stehe ich vor einem Dilemma: Obwohl drei Teile von WI-440 erfolgreich erfüllt wurden, muss ich das gesamte Anforderungselement offiziell als „nicht erfüllt“ markieren.

Dies fühlt sich absolut seltsam und schräg an – und das ist es auch.

Die Lösung: Atomare Zerlegung statt Tool-Illusion

Nicht nur besser, sondern schlichtweg richtiger wäre es gewesen, wenn der Referent die Anforderungen konsequent in zusätzliche, eigenständige Elemente aufgeteilt hätte.

In einem sauberen Setup können sämtliche geschriebenen Testfälle direkt mit den konkreten Einzelanforderungen verknüpft werden. Dadurch wird die Nachverfolgbarkeit (Traceability) signifikant gestärkt.

Mehrnoch: Der INCOSE-Standard und bewährte Best Practices wären damit tatsächlich korrekt umgesetzt worden, und eine transparente Bewertung der Anforderungsqualität wäre für alleProjektbeteiligten jederzeit nachvollziehbar gewesen. Von der initial ohnehin unkorrekten und unvollständigen Formulierung wollen wir an dieser Stelle gar nicht erst sprechen.

Fazit & Grundregeln des Anforderungsmanagements

Ein eiserner Leitsatz des Anforderungsmanagements lautet:

JedeAnforderung besteht aus genau einem Satz. Sie ist testbar undeindeutig.

Um diesen Leitsatz in der harten Projektpraxis erfolgreich umzusetzen, helfen zwei bewährte Methoden:

1. Eine Anforderung pro Satz (Atomarität): Es werden keine verschachtelten Sätze mit Bindewörtern wie „und“, „oder“ sowie „aber“ genutzt. Enthält ein Satz mehrere Bedingungen, wird er konsequent in mehrere eigenständige Anforderungen aufgeteilt.
2. Satzschablonen (Master-Templates): Um die Eindeutigkeit und Testbarkeit zu garantieren, nutzen Requirements Engineers standardisierte Satzstrukturen (z. B. nach dem IREB-Standard).

Fazit: KI-Tools sind mächtige Assistenten, aber sie ersetzen niemals das fundierte Engineering-Wissen im Kopf des Menschen. Vertrauen ist gut,fachliche Validierung ist besser!

Ich bin Certified Professional for Requirement Engineering (CPRE Foundation Level) und mit Sicherheit nicht derjenige der die ganze Zeit mit einem Gesetzbuch unterm Arm unterwegs ist, aber ich denke an ein paar Regel sich zu halten und umzusetzen, kann die Qualität des Produktes merklich beeinflussen.

Ich selbst habe viele Jahre bei der Entwicklung von einem regelbasierten und KI-gestützen Werkzeugs für die Bewertung der Qualität von Anforderungen mitgewirkt. Insofern kenne ich mit IEEE830, IEEE29148, EARS und der Sophisten-Satzbauschablone ähnliche Standards wie den INCOSE-Standard und als Anwender von KI kenne ich die Schwierigkeiten die damit einhergehen.

Ich bin mir ganz sicher, dass mit CoPilot und selbst geschriebenen KI-Werkzeugen sich die Qualität beim Requirement Engineering deutlich verbessern lässt.

Ich nutze künstliche Intelligenz selbst super gerne für meine Arbeit zum Beispiel für die Code- und Texterstellung. Deshalb ist auch dieser Beitrag hier mit tatkräftiger KI-Unterstützung entstanden.

Seit November 2023 leite ich eine Beratungsfirma mit 6 Mitarbeitern.

Meine Kenntnisse konnte ich in stark regulierte Branchen wie Automotive, Luft- und Raumfahrt, Pharma und Medizintechnik gewinnen. Ein Teil unserer Kunden kommt zwar aus weniger regulierten Bereich wie Agrar oder Defense, aber der Großteil der Kunden kommt genau aus den oben genannten Bereichen.  

Ich bin versiert in Methoden, Normen und Standards und strebe innovative Lösungen an, die traditionelle Ansätze herausfordern, ohne grundlegende Regeln zu verletzen.

‍