Automatisch Anforderungen modellieren, ohne dass es jemand merkt

Anforderungen werden klassischerweise in natürlicher Sprache erfasst und sind damit Menschen zugänglich. Von Maschinen können sie jedoch nur begrenzt verarbeitet werden. Das bedeutet, dass für viele Aktivitäten immer noch ein Mensch die Anforderungen lesen muss. Und noch einmal. Und noch einmal. Oft arbeiten hochbezahlte Ingenieure Checklisten ab, um die sich auch ein Werkstudent kümmern könnte. Das treibt die Kosten hoch und frustriert das Team. Und funktioniert noch nicht einmal zuverlässig.

Anforderungsmodelle hingegen ermöglichen einen ganz anderen Grad der Automatisierung. Das Problem dabei: Vernünftige Anforderungsmodellierung ist sehr anspruchsvoll. Das Team muss mit der Modellierungssprache umgehen können, methodisch fit sein und die verwendeten Werkzeuge beherrschen. Und wenn das ganze nicht ordentlich aufgesetzt wurde und die initiale Architektur stimmt, kann die Arbeit schnell verpuffen.

Aber es gibt noch einen dritten Weg: Wir können bei der natürlichsprachigen Beschreibung bleiben, aber diese zusätzlich maschinell analysieren. Das Ergebnis der Analyse ist ein Anforderungsmodell. Aus diesem Modell kann das System Schwachstellen in der textuellen Beschreibung identifizieren, wie Lücken oder Widersprüche. Diese Liste können wir dann den Nutzern präsentieren. Die Nutzer müssen gar nicht wissen, dass es das Modell überhaupt gibt.

Im Folgenden zeige ich ein Beispiel, wie ein generiertes Modell aussehen könnte und wie wir damit Schwächen in den Anforderungen finden. Der Artikel ist werkzeugneutral. Am 19./20. Oktober werde ich diese Konzepte werkzeugspezifisch in zwei Webinaren (Englisch/Deutsch) präsentieren.

Anmeldung zum Webinar am 19.10.2022 in Englisch und am 20.10.2022 in Deutsch >>

Komplexität erfordert Umdenken

Durch steigende Komplexität und strengere Compliance-Anforderungen stehen viele Teams in der Produktentwicklung vor großen Herausforderungen. Viele der klassischen Maßnahmen (Team vergrößern, Training, Coaching, Consulting) sind personalintensiv, aufwändig, und brauchen viele Monate, bevor sich positive Ergebnisse abzeichnen.

Model-Based Systems Engineering (MBSE) ist ein vielversprechender Weg, um besser mit Komplexität umgehen zu können. Doch MBSE erfordert Umdenken und Weiterbildung. Mitarbeiter müssen quasi eine neue Sprache lernen, zum Beispiel SysML. Doch eine Sprache lernt man nicht von heute auf morgen — abgesehen davon, dass auch das methodische Wissen verinnerlicht werden muss. Und Experten mit langjähriger Erfahrung, die dabei helfen, sind Mangelware.

Noch schlimmer: Klassisches MBSE lagert die Kosten vor. Entscheider scheuen sich, mehr als notwendig erscheint in Vorleistung zu gehen. Dazu kommt, dass es genug Anekdoten von vor die Wand gefahrener Projekte gibt.

Aber genauso, wie wir heute schon Werkzeuge wie Google Translate benutzen, um fremdsprachige Texte zu lesen, so können wir KI einsetzen, um für uns zu Modellieren. Auch wenn KI-generierte Modelle heute noch vergleichsweise simpel sind, so haben diese für konkrete Anwendungsfälle heute schon einen hohen Nutzen.

Textuelle Anforderungen im Kontext analysieren

Es gibt inzwischen viele Werkzeuge, die Texte analysieren, einschließlich Anforderungen. Diese setzen in der Regel Natural Language Processing (NLP) ein. Doch zumindest die mir bekannten Werkzeuge ignorieren den Kontext und analysieren lediglich einzelne Anforderungen.

Das kann nützlich sein: Mit diesen Techniken können wir Satzstrukturen überprüfen, bestimmte Vollständigkeitskriterien einfordern, Weak-Words erkennen und einiges mehr. Doch wenn wir den Kontext mit einbeziehen, dann können wir wesentlich mehr relevante Kriterien prüfen. Dazu ein konkretes Beispiel:

Beispiel: Anforderungen aus der Gebäudesicherheit

Die hier gezeigten „Anforderungen“ stammen von einem realen Kunden aus der Gebäudesicherheit. Daher sind einige Satzteile ausgegraut, doch die sind für die folgende Diskussion nicht wirklich relevant. Weiterhin sind nicht alle Sätze Anforderungen.

Wie könnte nun ein hinter den Kulissen automatisch extrahiertes Modell aussehen und was können wir damit machen?

Anforderungen modellieren

Um es gleich vorweg zu sagen: Wir können sicherlich kein vollständiges Systemmodell auf Knopfdruck ableiten. Es macht mehr Sinn, einen relevanten Teilbereich zu modellieren um daraus einen Nutzen zu ziehen. Bevor ich das extrahierte Domänenmodell zeige, ein paar andere Möglichkeiten:

• Verhaltensmodell in der Form von Aktivitäten und Kontrollflüssen. Wir können so ein Modell nutzen, um Blockierungen oder Endlosschleifen zu identifizieren.
• Zustandsmodell in der Form von Zuständen und Zustandstransitionen. Mit so einem Modell könnten wir Datenblätter für Mikrochips analysieren.
• Schnittstellenmodell in der Form von Komponenten und Interfaces oder Ports. Damit können wir ungenutzte oder falsch verknüpfte Ports identifizieren.
• Parametrisierung in der Form von benannten Parametern und Maßeinheiten. Damit könnten wir Inkonsistenzen zwischen Anforderungen und Tests finden.

Extrahiertes Domänenmodell

Zumindest theoretisch enthält der gezeigte Text genug Information, um Entitäten und deren Relationen zu extrahieren. Das könnte folgendermaßen aussehen:

Auch wenn dieses Diagram von UML inspiriert wurde, ist es weit von einem vernünftigen Klassenmodell entfernt. Zum Beispiel geht aus dem Anforderungstext nicht hervor, ob es sich bei einer Entität um eine Klasse oder um ein Objekt handelt.

Dennoch können wir anhand von so einem Modell interessante Fragen stellen und basierend darauf die Anforderungen verbessern. Zum Beispiel:

• Was ist die Relation von „Fire Alarm“ zum Gesamtsystem? Fehlt möglicherweise eine Relation?
• Gibt es Gemeinsamkeiten zwischen „Smoke Alarm“ und „Heat Alarm“, die wir vielleicht nutzen können?
• Falls es bereits eine Systemarchitektur gibt, könnte mit Hilfe des Modells eine Zuordnung (Allocation) der Anforderungen auf das Modell teilautomatisiert werden.
• Mit Hilfe des Modells kann der Nutzer Anforderungen im Kontext analysieren, ohne eine explizite Traceability anlegen zu müssen.
• Das Modell kann die Basis für ein automatisch gepflegtes Glossar, bzw. Ontologie bilden.

Relevant ist hierbei, dass wir für all diese Anwendungsfälle die Nutzer nicht mit dem Modell konfrontieren, sondern mit den aus dem Modell gewonnenen Erkenntnissen in der Form von Kontextinformation, Verbesserungsvorschlägen oder Verständnisfragen (der Beantwortung die Anforderungen nachbessert).

Stand der Technik

Zu den hier vorgestellten Ideen gibt schon eine Menge Forschungsaktivität, aber erstaunlich wenig einsatzbereite Lösungen. Ich arbeite mit Semiant selbst an einer entsprechenden Lösung. Aktuell unterstützt diese einen einfachen Qualitätscheck sowie KI-gestützte Glossarextraktion und Einbindung in gängige Anforderungsmanagementwerkzeuge wie Polarion, DOORS Next oder Jama Connect.

Fazit

Das wichtigste ist, dass Nutzer nicht zwingend Modellierungssprachen lernen müssen, um von den Ergebnissen zu profitieren. Automatisierte Modellierung hat das Potential, Entwickler mit wertvollen Ergebnissen und Automatisierung von monotonen (aber wichtigen) Aufgaben zu unterstützen, damit diese sich auf die kreativen Aspekte der Entwicklung fokussieren können.

Mehr zum Modellieren von Anforderungen erzähle ich live am 19./20. Oktober im Webinar. Jetzt anmelden >>

Bildquelle: FreePik