Generative Künstliche Intelligenz (KI) erlebt aktuell einen massiven Aufschwung. Zahlreiche Unternehmen und Forschungsinstitutionen schöpfen aus dem enormen Potenzial dieser Technologie, insbesondere in Schlüsselbereichen wie der Generierung von Texten und Bildern, der automatisierten Übersetzung, der Softwareentwicklung sowie der allgemeinen Wissensarbeit.

Als zentrale Disziplin innerhalb des Softwareentwicklungsprozesses beschäftigt sie sich das Anforderungsmanagement mit der systematischen Erhebung, Analyse, Spezifikation, Modellierung und Verwaltung von Anforderungen, die den Rahmen für die Entwicklung komplexer Systeme bilden. Die hohe Komplexität von Systemen und der Vielzahl an Stakeholdern mit teils widersprüchlichen Interessen machen das Anforderungsmanagement zu einer besonders fehleranfälligen, zeitintensiven und damit kostenrelevanten Disziplin. Vor diesem Hintergrund liegt es nahe, neue Technologien zur Unterstützung einzusetzen.

Die vergangenen Artikel dieser Blogserie haben den Einsatz von generativer KI als unterstützendes Werkzeug in der Bewältigung der Aufgaben im Anforderungsmanagement beleuchtet und Stärken sowie Schwächen aufgezeigt. Dieser letzte Artikel fasst nun die wesentlichsten Erkenntnisse aus den Untersuchungen der Blogserie zusammen.

Vorgehen

Als Grundlage hat der Blogserie ein fiktives Warenwirtschaftssystem gedient, das aus drei Systemen besteht: einem Kassensystem für den Verkauf von Waren und Gütern, einem Filialensystem zur Verwaltung, Bestellung und Überwachung von Produkten sowie einem Unternehmenssystem zur Berichterstellung über mehrere Filialen hinweg. Als Eingabedaten werden unterschiedliche, manuell erstellte Dokumente genutzt, darunter Projektvorschläge, Beobachtungsprotokolle, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme sowie Mockups. Diese Dokumente liegen in verschiedenen Dateiformaten vor (z. B. DOCX, PNG, YAML, PDF) und werden ChatGPT als Grundlage für das Anforderungsmanagement übergeben. Die Ergebnisse werden in einem auswertbaren CSV-Format bereitgestellt.

Um die Ergebnisse möglichst objektiv bewerten zu können, sind für jede Teildisziplin spezifische Messkriterien entwickelt worden. Die Teildisziplinen sind einzeln bewertet worden und die Ergebnisse können in separaten Artikeln nachvollzogen werden. Die Resultate der Blogartikel werden anschließend in einem abschließenden Artikel aggregiert, mit dem Ziel, eine ganzheitliche Einschätzung des Potenzials generativer KI im Anforderungsmanagement zu treffen.

Abschließende Bewertung

Kritik am eigenen Vorgehen

Die Bewertung generativer KI im Anforderungsmanagement ist nicht frei von methodischen Herausforderungen. Objektivität lässt sich schwer erreichen, da auch bei klar definierten Bewertungsskalen Interpretationsspielräume bestehen. Zudem ist es problematisch, Messkriterien universell anzuwenden, da Anforderungen je nach Kontext unterschiedliche Eigenschaften besitzen und damit auch hier Raum für Interpretationen lassen. Darüber hinaus ist ein fester Katalog an Bewertungskriterien etabliert worden, der keinen Anspruch auf Vollständigkeit hat; weitere Dimensionen lassen sich jederzeit berücksichtigen. Auch die manuelle Überprüfung aller Anforderungen hat sich als arbeitsintensiv und fehleranfällig erwiesen. Schließlich hat sich gezeigt, dass die Eingangsdokumente stärker auf Soll- und Kann-Anforderungen hätten fokussieren sollen, um der KI eindeutige Signale zur Priorisierung zu geben. Ebenso hätten Signalwörter in den Eingabedokumenten eingesetzt werden können, aus denen die KI auf Bedingungen oder Auslöser für Anforderungen reagieren kann.

Zusammenfassung des Fazit

ChatGPT zeigt besondere Stärken bei der strukturierten und konsistenten Formulierung von Anforderungen. Es gelingt ihm, auch ohne vordefinierte Schablonen nachvollziehbare Dokumente mit vollständigen Metadaten zu erstellen. Positiv hervorzuheben ist die Fähigkeit, redundante Inhalte zu erkennen, sprachliche Konsistenz herzustellen und den Dokumentationsaufwand deutlich zu verringern. Auch im kreativen Bereich erweist sich die KI als hilfreich, da sie Ideen generieren und erste Modelle zur Diskussion anstoßen kann.

Dennoch werden Schwächen deutlich. Viele Anforderungen werden nicht atomar formuliert, sondern enthalten mehrere Funktionen. Uneinheitliche Benennungen führen zu Mehrdeutigkeiten und erzeugte Modelle erfüllen zwar formale Standards, sind inhaltlich jedoch reduziert oder unvollständig gewesen. Zudem neigt die KI dazu, Inhalte durch Platzhalter zu ersetzen. Implizite Bedingungen und Priorisierungen können nicht zuverlässig erkannt werden, sodass weiterhin menschliche Interpretation und Nacharbeit erforderlich ist.

Abschließendes Fazit

Aus den Beobachtungen lässt sich schließen, dass ChatGPT ein wertvolles Werkzeug zur Unterstützung im Anforderungsmanagement sein kann, insbesondere bei der Automatisierung repetitiver Aufgaben, der Strukturierung von Anforderungen sowie der sprachlichen Vereinheitlichung. Die KI trägt dazu bei, die Qualität der Dokumentation zu steigern und die Effizienz zu erhöhen. Gleichzeitig stößt sie an Grenzen, wenn es um die korrekte inhaltliche Priorisierung, die atomare Formulierung von Anforderungen, erkennen und wiedergeben impliziten Wissens sowie die vollständige Modellierung geht. Diese Bereiche erfordern nach wie vor die Expertise von Anforderungsspezialisten.

Empfehlung

Generative KI sollte im Anforderungsmanagement gezielt als unterstützendes Werkzeug eingesetzt werden. Ihre Vorteile liegen in der schnellen Erstellung strukturierter Anforderungsdokumente, der Reduzierung von Redundanzen, der Vereinheitlichung von Sprache sowie der Automatisierung von Routineaufgaben. Herausforderungen bestehen jedoch in der Sicherstellung von Präzision, Eindeutigkeit und Vollständigkeit.

Generative KI sollte nicht verwendet werden, um von der grünen Wiese aus die Arbeit eines Anforderungsspezialisten abzunehmen, sondern sie zu unterstützen. Die Anwendungsfälle sollen sich auch genau auf diese Unterstützung anlehnen, nämlich:

Um Schwächen der generativen KI abzufedern, sind klare Prompts notwendig, z.B. Grundlagen einzufordern, wie Atomarität von Anforderungen oder Änderungen an den Anforderungen durch die KI stets nachvollziehbar an den Anforderungen zu dokumentieren. Des Weiteren können Konzepte, wie das Einsetzen von Wissensbasen für konsistente Benennungen, hilfreich sein.

Im Rahmen dieser Blogserie hat es ein Release des 5er Sprachmodells von ChatGPT gegeben. Damit jedoch die Ergebnisse der einzelnen Artikel vergleichbar sind, sind die Prompts auf dem Modell in der Version 4o geblieben. Ob Ergebnisse mit dem aktuelleren Modell besser sind, ist spekulativ. Dennoch verspricht das neue Modell, weniger Halluzinationen zu haben, noch größere Datenmengen verarbeiten zu können als das Vorgängermodell und konsistentere Ausgaben durch bessere Selbst-überprüfungen zu generieren.

Werden diese Rahmenbedingungen geschaffen, kann GenAI die Arbeit von Anforderungsspezialisten nicht ersetzen, wohl aber erheblich erleichtern und qualitativ bereichern.

Der Beitrag Das Potenzial von generativer KI im Anforderungsmanagement – Teil 6 erschien zuerst auf Masoona Consulting.

Die Anforderungsmodellierung ist eine zentrale Disziplin des Anforderungsmanagements. Sie befasst sich mit der systematischen Erfassung, Strukturierung und Visualisierung von Anforderungen an ein Softwaresystem. Während die Anforderungserhebung vor allem auf das Sammeln und Dokumentieren von Informationen abzielt, konzentriert sich die Anforderungsmodellierung darauf, diese Informationen in formale oder semi-formale Modelle zu überführen. Ziel ist es, die Komplexität zu reduzieren, ein gemeinsames Verständnis zwischen Stakeholdern und Entwicklungsteams zu schaffen und eine Grundlage für weitere Entwicklungsphasen zu bieten.

Wichtig für eine erfolgreiche Anforderungsmodellierung sind insbesondere die Einhaltung etablierter Notationen (z. B. UML2), die Präzision der Darstellung sowie die Konsistenz und Vollständigkeit der Modelle. Nur so können die Modelle als belastbare Grundlage für Architektur- und Implementierungsentscheidungen genutzt sowie als Spezifikation für Umsetzung werden. Weniger formale Modelle dienen hingegen eher dem Zusammenfassen von Informationen in einer so geeigneten Weise, dass sich Anforderungsspezialisten, Stakeholder und Entwickler korrekt verständigen können.

Vor dem Hintergrund der wachsenden Bedeutung von Generativer Künstlicher Intelligenz (GenAI) stellt sich die Frage, inwiefern diese Technologien die Anforderungsmodellierung unterstützen können. Ziel dieses Beitrags ist es daher, das Potenzial von GenAI in diesem Kontext anhand eines konkreten Beispiels kritisch zu untersuchen.

Ausgangslage

Als Beispiel dient ein fiktives Warenwirtschaftssystem, das aus drei wesentlichen Bereichen besteht: einem Kassensystem für den Verkauf von Waren, einem Filialensystem zur Verwaltung, Bestellung und Überwachung von Produkten sowie einem Unternehmenssystem, das Berichte aus den Filialdaten erstellt. Grundlage der Untersuchung sind manuell erstellte, fiktive Dokumente wie Projektvorschläge, Beobachtungsprotokolle, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme und Mockups. Diese Dokumente liegen in unterschiedlichen Formaten vor (z. B. DOCX, PNG, YAML, PDF) und werden einem generativen KI-Modell (ChatGPT-4o) übergeben. Ziel ist es, zu evaluieren, ob und in welcher Qualität die KI aus diesen Eingaben verschiedene Modelltypen erstellen kann.

Vorgehen

Die Bewertung der Ergebnisse erfolgt anhand ausgewählter Kriterien. Zunächst werden unterschiedliche Diagrammtypen durch die KI erzeugt, darunter Komponentendiagramme, Klassendiagramme, Use-Case-Diagramme, Anforderungsdiagramme und Aktivitätsdiagramme. Alle Modelle werden durch die KI als Mermaid-Code generiert und anschließend visualisiert. Es handelt sich hierbei um sehr einfach lesbaren und interpretierbaren Code mit der Möglichkeit, diesen auszutauschen sowie zu visualisieren. Ebenfalls wird die KI auch aufgefordert, ein UML Modell als XMI auszugeben, da dieses einen hohen Spezifikationsgrad hat und sich damit als Grundlage der Softwareentwicklung versteht.

Die Analyse beider erzeugten Modelle erfolgt auf Basis folgender Kriterien:

Nach einer ersten Begutachtung werden die größten Schwachstellen identifiziert und die KI gebeten, Korrekturen vorzunehmen. Damit soll überprüft werden, inwiefern die KI auf Feedback reagiert und ihre Ergebnisse verbessern kann.

Ergebnisse

Die Modelle bzw. Diagramme, die mit Mermaid-Code erstellt worden sind, sind zur UML2 nicht konform, da zum einen nicht alle Diagrammtypen unterstützt werden und zum anderen Mermaid nicht für den Zweck einer Spezifikation geschaffen ist. Im Folgenden werden die Ergebnisse der einzelnen Diagrammtypen vorgestellt und verdeutlichen die Stärken und Schwächen von GenAI in der Anforderungsmodellierung.

Komponentendiagramm

Das von der KI erzeugte Komponentendiagramm als XMI entspricht dem UML2-Standard, ist aber sehr reduziert in der Darstellung der Abhängigkeiten. Das nicht UML2-konforme in Mermaid generierte Diagramm erlaubt jedoch einen Einblick in Abhängigkeiten der Module. Mehrere neue Module werden hinzugefügt, deren Existenz nicht in den Quelldokumenten belegt ist. Nachstehende Tabelle vergleicht Module in den Anforderungen und Module, welche sich im Diagramm wiederfinden:

Im Vergleich der identifizierten Module und der modellierten beziehen sich Lagerwirtschaft und Einkauf & Lagerorganisation vermutlich auf das identifizierte Modul Lager & Warenwirtschaft, ist aber nicht klar ersichtlich. Im Diagramm vereint die neue Modulbezeichnung Infrastruktur die zuvor in den Anforderungen identifizierten Module Systemarchitektur und Stammdatenverwaltung. Alle drei Bezeichnungen sind nicht aussagekräftig und verschleiern, welche Geschäftsbereiche sie abdecken. Bei Stammdaten ist auch nicht klar, ob die Daten der Mitarbeiter oder der Kunden gemeint sind. Da hierzu nichts in den Eingabedokumenten erwähnt ist, ist die Modellierung des Moduls Stammdatenverwaltung fraglich und muss geklärt werden. Auch nicht eindeutig übereinstimmend sind Business Analytics und Analytics & Marketing. Es ist anzunehmen, dass hier das gleiche Modul gemeint ist. Positiv ist hervorzuheben, dass viele Kernmodule korrekt identifiziert und miteinander in Beziehung gesetzt werden.

Use-Case-Diagramm

Sowohl für das UML2-konforme als auch das Mermaid-Modell gilt: Die Akteure werden zuverlässig erkannt, während die Use Cases dagegen unvollständig sind, denn 14 Anforderungen können keinem Anwendungsfall zugeordnet werden. Zu diesen nicht verknüpften Anforderungen zählen:

Vererbungsbeziehungen oder Extensions werden nicht modelliert – vermutlich, weil sich dies aus den gefundenen Anforderungen und den Quelldokumenten nicht ergibt.

Die KI wird zu einer erneuten Ausführung gebeten, um fehlende Zuordnungen von Anforderungen zu Anwendungsfällen zu ergänzen, was sie auch umsetzt. Insgesamt entsteht ein brauchbarer, aber nicht vollständiger Überblick über das Systemverhalten.

Das UML-Modell erfüllt zwar den Standard, enthält aber gegenüber dem Mermaid-Modell keine Beziehungen zwischen Akteuren und Anwendungsfällen. Der generierte Mermaid-Code hingegen kann nicht visualisiert werden, da Use Cases nicht als Diagrammtyp unterstützt sind. Hier kann nur die Bedeutung des Mermaid-Codes bewertet werden.

Klassendiagramm

Die Klassendiagramme, sowohl im Mermaid-Code als auch in XMI, sind syntaktisch korrekt und geben einen detaillierten Einblick in das System, besonders im Bereich Lager und Bestand.

Ein großer Unterschied beider Modelle ist allerdings, dass das Modell der XMI nur 8 Klassen mit 3 Assoziationen erzeugt, während der Mermaid-Code aus den gleichen Eingabedaten ein Modell mit 23 Klassen und zahlreichen sinnvollen Attributen, Methoden und Assoziationen mit Rollenbeschreibungen erzeugt. Letzteres sind Details an Assoziationen, auf die im UML-Modell verzichtet wird.

Bei weiterer Betrachtung des Mermaid-Modells ist zu erkennen: Vererbungen, Sichtbarkeiten und Multiplizitäten werden eingesetzt. Allerdings sind semantische Details problematisch: Manche Beziehungen sollten besser als Aggregation oder Komposition modelliert werden,  was die KI nicht leistet. Attribute und Methoden sind plausibel, teils jedoch spekulativ, sodass eine manuelle Prüfung und ein Hinterfragen dieser Angaben durch den Anforderungsspezialisten notwendig ist.

Aktivitätsdiagramm

Die erzeugten Aktivitätsdiagramme in UML und Mermaid zeigen die grundlegenden Abläufe. Besonders problematisch ist die fehlerhafte Modellierung von Entscheidungsknoten und Parallelisierungen. So haben Entscheidungen teilweise nur einen Alternativablauf und Parallelisierungen werden nicht korrekt synchronisiert. Manche Abläufe terminieren nicht im Ende der Aktivität. Insgesamt hat die KI zu viele Abläufe als relevant erachtet und versucht, in einem Ablauf zu modellieren. Grund hierfür ist der Prompt, welcher nach einem Diagramm mit relevanten Abläufen gefragt hat. Nach Feedback zu den Schwachpunkten und der Bitte um mehr Fokus auf einen bestimmten Ablauf kann die KI mit dem verbesserten Prompt das Diagramm verbessern, etwa durch die Einführung von Swimlanes und konsistentere Entscheidungsstrukturen. Dennoch bleibt die Darstellung in Teilen unsauber, z.B. wegen anhaltender fehlerhaft zusammengeführter Parallelisierungen oder unklare Aktivitätsbezeichnungen, wie „Alle Prozesse abgeschlossen“. Während nach dem Feedback an die KI das UML-Modell zwar konform zur Notation bleibt, zeigt es jedoch gegenüber des in Mermaid erstellten Modells keine Swimlanes und auch keine Guards an Kanten einer Entscheidung.

Anforderungsdiagramm

Die Anforderungsmodellierung der generativen KI in Mermaid hat jede Anforderung isoliert mit ID, Titel und Priorität modelliert und visualisiert, ohne Berücksichtigung von Beziehungen, Abhängigkeiten oder Testfällen. Diese Elemente fehlen oder können nicht aus den Eingabedokumenten abgeleitet werden. Obwohl das Diagramm korrekt ist, mangelt es ihm an Aussagekraft. Da kein Anforderungsdiagramm in UML2 existiert, wird keines generiert.

Fazit

Die Untersuchung zeigt, dass der Einsatz generativer KI in der Anforderungsmodellierung Chancen, aber auch klare Grenzen hat.

Darüber hinaus lassen sich weitere Schlussfolgerungen ziehen:

Insgesamt zeigt sich, dass generative KI in der Anforderungsmodellierung aktuell eher als unterstützendes Werkzeug und Ideengeber einsetzbar ist, nicht jedoch als Ersatz für menschliche Expertise.

Der Beitrag Das Potenzial von generativer KI in der Anforderungsmodellierung – Teil 5 erschien zuerst auf Masoona Consulting.

Das Anforderungsmanagement ist ein zentraler Bestandteil der Softwareentwicklung und umfasst alle Aktivitäten, die sich mit der Erhebung, Analyse, Dokumentation und Verwaltung von Anforderungen an ein System beschäftigen. Eine der wichtigsten Disziplinen innerhalb dieses Prozesses ist die Anforderungsspezifikation. Sie hat die Aufgabe, die ermittelten Anforderungen in einer strukturierten, nachvollziehbaren und überprüfbaren Form festzuhalten. Dabei ist entscheidend, dass Anforderungen verständlich, eindeutig, widerspruchsfrei und vollständig beschrieben sind, um spätere Missverständnisse, teure Korrekturen oder Projektabbrüche zu vermeiden.

Generative Künstliche Intelligenz (GenAI) eröffnet neue Möglichkeiten, diese Aufgabe zu unterstützen. Sprachmodelle können dabei helfen, unstrukturierte Eingaben zu analysieren, konsistente Anforderungstexte zu formulieren und die Dokumentation zu standardisieren. Ziel dieses Beitrags ist es daher, zu untersuchen, wie GenAI konkret bei der Anforderungsspezifikation eingesetzt werden kann und welche Chancen und Grenzen sich daraus ergeben.

Ausgangslage

Als Beispiel dient ein fiktives Softwaresystem aus dem Bereich der Warenwirtschaft. Dieses umfasst drei zentrale Komponenten:

Die Eingaben für die Spezifikation bestehen aus einer Vielzahl an manuell erstellten, fiktiven Dokumenten in unterschiedlichen Formaten, darunter Projektvorschläge (docx), Beobachtungsprotokolle (pdf), Schnittstellenspezifikationen (yaml), Mockups (png) sowie unvollständige Use-Case-Diagramme. Diese Daten werden einem generativen Sprachmodell (ChatGPT-4o) übergeben, um daraus Anforderungen in einem standardisierten, sowohl lesbaren als auch maschinell auswertbaren CSV-Format zu erzeugen.

Vorgehen

Um die Qualität der durch die KI erzeugten Anforderungen möglichst objektiv zu bewerten, werden etablierte Kriterien aus der Anforderungsanalyse herangezogen. Dazu zählen insbesondere:

Jede identifizierte Anforderung wird auf einer Skala von 0 (= nicht zutreffend) bis 2 (= zutreffend) in den genannten Kategorien bewertet und der Erfüllungsgrad in Prozent zu der jeweils maximal erreichbaren Punktzahl ausgedrückt. Anschließend wird die KI erneut eingesetzt, um erkannte Schwachstellen gezielt zu korrigieren.

Ergebnisse

Verständlichkeit

88 % der Anforderungen wurden als verständlich eingestuft. 

Korrektheit

95 % der Anforderungen gaben die Sachverhalte korrekt wieder.

Eindeutigkeit

73 % der Anforderungen werden als eindeutig bewertet.

Vollständigkeit

71 % der Anforderungen sind vollständig beschrieben.

Widerspruchsfreiheit

52 % der Anforderungen sind widerspruchsfrei.

Verfolgbarkeit

Die im Prompt geforderte Struktur (ID, Titel, Anforderungstext, Priorität, Kategorie, Modul, Status, Autor, Modelle, Quellen, Testfälle, Stakeholder und Änderungen) hat die generative KI eingehalten ist vollständig ausgefüllt ausgefüllt worden.

Erneuter Prompt für Verbesserungen

Betrachtet man die Anforderungsspezifikation im Lichte des Standards IEEE 830 – Recommended Practice for Software Requirements Specifications, so wird deutlich, dass die erzeugten Anforderungen noch weiter verfeinert werden sollten, um eindeutiger, überprüfbarer und verständlicher zu sein. Eine nach IEEE 830 strukturierte Spezifikation umfasst über die Anforderungen hinaus typischerweise:

Eine vollständige Umsetzung nach IEEE 830 ist im vorliegenden Szenario zwar nicht gefordert gewesen, dennoch zeigt sich, dass ein entsprechender Prompt, wie Anforderungen nach IEEE 830 aussehen würden, das Ergebnis erheblich verbessert. So erzeugt die KI bei explizitem Bezug auf den Standard bereits Vorschläge für Eingaben, Ausgaben, den Zweck einer Anforderung sowie mögliche Verifikationsmethoden. Allerdings bleiben diese Angaben auf einer sehr abstrakten Ebene, sind nicht vollständig oder frei erfunden. Zum Beispiel leitet die KI ab, dass die Verarbeitung des Verkaufs in weniger als 2 Sekunden abgehandelt sein soll. Eine nichtfunktionale Anforderung, die nicht aus den Quellen hervorgeht. Als Testfall hat die KI beispielsweise generiert, das ein Kassiervorgang mit Barzahlung erfolgreich abgeschlossen sein soll. Was jedoch den Erfolg hier kennzeichnet bleibt unkonkret. Jedoch fordern die generierten Testfälle den Anforderungsspezialisten heraus, die gefundenen Anforderungen zu hinterfragen und sie unter Umständen zu verfeinern.

Fazit

Die Ergebnisse zeigen, dass generative KI in der Lage ist, Anforderungen in einer gut strukturierten und konsistenten Form zu erzeugen, selbst ohne die Verwendung vordefinierter Textschablonen (z. B. nach den Sophisten). Funktionalitäten, Systeme oder Stakeholder können aus den strukturierten Texten leicht identifiziert werden. Zudem werden sämtliche Metadaten – wie IDs, Prioritäten, Kategorien, Herkunft und Quellen sowie Verknüpfungen mit Diagrammen oder Modellen – zuverlässig dokumentiert.

Herausfordernd bleibt jedoch, dass viele Anforderungen nicht atomar formuliert sind und Aufzählungen mehrerer Funktionen enthalten. Auch uneinheitliche Benennungen führen zu Mehrdeutigkeiten, welche die Verständlichkeit mindern.

Darüber hinaus lassen sich folgende weiterführende Erkenntnisse ableiten:

Insgesamt zeigt sich, dass generative KI ein wertvolles Werkzeug zur Unterstützung in der Anforderungsspezifikation darstellt, jedoch kein Ersatz für die fachliche Expertise und die kritische Bewertung durch Anforderungsspezialisten ist.

Der Beitrag Das Potenzial von generativer KI in der Anforderungsspezifikation – Teil 4 erschien zuerst auf Masoona Consulting.

Das Anforderungsmanagement beschäftigt sich mit der systematischen Erfassung, Dokumentation und Verwaltung von Anforderungen an ein zu entwickelndes System. Ziel ist es, sicherzustellen, dass das entstehende Produkt den Bedürfnissen und Erwartungen der Stakeholder entspricht. Eine zentrale Disziplin innerhalb dieses Prozesses ist die Anforderungserhebung, also die strukturierte Sammlung und Formulierung von Anforderungen aus unterschiedlichen Quellen, wie bereits im Überblicksartikel erwähnt worden ist.

Für die erfolgreiche Anforderungserhebung sind mehrere Faktoren entscheidend: Einerseits muss eine möglichst vollständige Sammlung relevanter Informationen gewährleistet sein. Andererseits kommt es darauf an, die erhobenen Anforderungen klar und präzise zu formulieren, um spätere Missverständnisse und Implementierungsfehler zu vermeiden.

Vor diesem Hintergrund stellt sich die Frage, wie Generative KI die Anforderungserhebung unterstützen kann. Insbesondere interessiert, ob sie in der Lage ist, aus den heterogene Eingabedokumente Anforderungen abzuleiten und konsistent zu formulieren, um so Arbeitsaufwand für Requirements Engineers zu reduzieren.

Ausgangslage

Im untersuchten Szenario ist  ein fiktives Warenwirtschaftssystem als Beispiel herangezogen worden. Dieses umfasst drei Ebenen:

Als Eingaben dienen manuell erstellte, fiktive Dokumente wie Projektvorschläge, Beobachtungsprotokolle, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme oder Mockups. Diese lagen in unterschiedlichen Formaten vor (z. B. DOCX, PNG, YAML, PDF). Die Dokumente sind einem generativen Sprachmodell (ChatGPT 4o) übergeben worden, um daraus Anforderungen in ein strukturiertes, auswertbares CSV-Format zu überführen.

Vorgehen

Um die Ergebnisse möglichst objektiv zu bewerten, werden die Ausgaben anhand definierter Kriterien untersucht. Zunächst erfolgt ein Abgleich der von ChatGPT erhobenen Anforderungen mit den manuell erhobenen Anforderungen. Anschließend wird die KI gebeten, identifizierte Schwächen zu korrigieren.

Vollständigkeit der Anforderungen

Die Vollständigkeit der durch die KI entdeckten Anforderungen wird mit einem Abgleich gegenüber zuvor händisch erhobenen Anforderungen erzielt. Dabei werden Abweichungen in der Formulierung oder ein gewisser Interpretationsspielraum toleriert, solange der Kerninhalt vergleichbar bleibt.

Sprache der Anforderungen

Ein weiterer Fokus liegt auf der sprachlichen Konsistenz der Anforderungen. Als Maßstab gilt eine Ähnlichkeit zwischen Anforderungspaaren, wenn für ein bestimmtes Konzept konsistent dieselben Begriffe verwendet werden. Abweichungen entstehen insbesondere dann, wenn die KI alternative Begriffe oder unspezifische Formulierungen einsetzt.

Ergebnisse

Die manuelle Erhebung ergibt insgesamt 72 Anforderungen. Die KI hat zunächst 40 Anforderungen extrahieren können, von denen 9 nicht korrekt aus den Quelldokumenten abgeleitet sind. Eine detaillierte Analyse ergibt mehrere Ursachen:

Im weiteren Verlauf zeigten sich Stärken und Schwächen in der Zusammenarbeit mit der KI:

Fazit

Das Experiment zeigt, dass Generative KI in der Anforderungserhebung ein wertvolles Assistenzwerkzeug sein kann, insbesondere bei:

Allerdings bestehen deutliche Einschränkungen:

Insgesamt lässt sich festhalten: ChatGPT und vergleichbare Modelle eignen sich weniger als autonome Anforderungserheber, sondern vielmehr als dialogorientierte Assistenten. Im Zusammenspiel mit menschlicher Expertise können sie das Requirements Engineering durch Strukturierung, Vorschläge und Validierung sinnvoll ergänzen, jedoch nicht ersetzen.

Der Beitrag Das Potenzial von generativer KI in der Anforderungserhebung – Teil 3 erschien zuerst auf Masoona Consulting.

Das Anforderungsmanagement ist eine zentrale Disziplin in der Softwareentwicklung. Es umfasst alle Aktivitäten, die notwendig sind, um Anforderungen an ein System systematisch zu erheben, zu dokumentieren, zu prüfen und im Entwicklungsprozess fortlaufend zu pflegen. Eine wesentliche Teildisziplin innerhalb des Anforderungsmanagements ist die Anforderungsanalyse.

Die Anforderungsanalyse hat das Ziel, die Bedürfnisse und Erwartungen der Stakeholder präzise zu erfassen und in verständliche, überprüfbare sowie konsistente Anforderungen zu überführen. Dabei spielen mehrere Faktoren eine Rolle: die Eindeutigkeit der Formulierungen, die Nachvollziehbarkeit der Prioritäten, die Vermeidung von Redundanzen sowie die klare Zuordnung zu Stakeholdern.

Im vorliegenden Beitrag – aus der Serie mehrerer Artikel – soll untersucht werden, wie generative KI, konkret ChatGPT, in der Anforderungsanalyse eingesetzt werden kann. Das Ziel ist es herauszufinden, in welchen Bereichen eine Unterstützung sinnvoll möglich ist, wo Grenzen bestehen und welche Schlüsse sich daraus für die zukünftige Praxis ziehen lassen.

Ausgangslage

Als Grundlage dient ein fiktives Beispielprojekt: Ein Warenwirtschaftssystem, bestehend aus

Als Eingabedaten stehen verschiedene Dokumente zur Verfügung, darunter Projektvorschläge, Beobachtungsprotokolle, Schnittstellenspezifikationen, unvollständige Use-Case-Diagramme und Mockups. Diese liegen in heterogenen Dateiformaten wie .docx, .png, .yaml oder .pdf vor.

Die Dokumente werden an ChatGPT (Version 4o) übergeben. Als Ausgabe wird ein CSV-Format gewählt, das sowohl menschenlesbar als auch in gängigen Tabellentools weiterverarbeitbar ist.

Vorgehen

Um die Ergebnisse möglichst objektiv beurteilen zu können, erfolgt die Bewertung anhand nachstehender definierter Kriterien. In einem zweiten Schritt wird die KI gezielt mit den erkannten Schwächen konfrontiert und gebeten, Korrekturen vorzunehmen.

Bewertung der Relevanz

Die Relevanz von Anforderungen wird anhand zweier Kriterien überprüft:

1. Stakeholder-Zuordnung: Jede Anforderung sollte einer Interessengruppe zugeordnet sein. Bewertet wurde auf einer Skala von 0 (keine Angabe) bis 2 (korrekte Stakeholder-Angabe).
2. Einschätzung der Wichtigkeit: Dies umfasst sowohl die Priorisierung in Muss-, Soll-, Kann-Anforderungen.

Bewertung der Redundanz

Um Redundanzen zu identifizieren, werden die Anforderungen paarweise miteinander verglichen und bewertet. Die Bewertung geschieht anhand der nachstehenden Kategorisierung. Demnach können Anforderungen

sein.

Ergebnisse

Relevanzbewertung

Die korrekte Stakeholder-Zuordnung hat ChatGPT in 66 % der Fälle erreicht. Fehler sind insbesondere dadurch entstanden, dass

Nach einer Korrekturschleife sind diese Mängel behoben worden. Die KI hat Namen durch passende Rollen ersetzt und Stakeholder für Dokumente ergänzt, in denen diese nur indirekt zu erkennen gewesen sind, etwa bei Schnittstellenspezifikationen oder Mockups.

Die Bewertung der Priorität ist deutlich schwächer ausgefallen: Nur 51 % der Anforderungen sind korrekt priorisiert. Häufige Probleme sind:

Auch nach weiteren Korrekturanweisungen bleibt die Qualität unbefriedigend. Die KI hat meist nur die Prioritätsstufen geändert, ohne die Anforderungstexte sprachlich zu präzisieren.

Redundanzbewertung

Bei der Redundanzanalyse zeigen die von ChatGPT genrierten Anforderungen deutlich bessere Ergebnisse. Von 1.225 möglichen Anforderungspaaren werden

Funktional gleiche Anforderungen stammen häufig aus unterschiedlichen Quelldokumenten, und werden daher mehrfach aufgeführt, ohne das bei bestehenden Anforderungen eine weiter Quelle ergänzt worden ist. Die ähnlichen Anforderungen lassen sich darauf zurückführen, dass Anforderungen nicht atomar formuliert gewesen sind und Aufzählungen von Eigenschaften des Softwaresystems enthalten haben.

Eine erneute KI-gestützte Prüfung hat zehn redundante Anforderungskandidaten identifiziert, welche die Anzahl funktional gleicher Anforderungspaare gesenkt hat. Die durch die KI entdeckten Redundanzen decken sich mit einer manuellen Überprüfung der von der KI identifzierten Anforderungen. Die KI Unterstützung ist in diesem Fall zuverlässig gewesen.

Fazit

Die Untersuchung zeigt, dass der Einsatz generativer KI in der Anforderungsanalyse sowohl Chancen als auch Grenzen mit sich bringt:

Weiterführende Überlegungen

Neben den genannten Aspekten ergeben sich weitere Schlussfolgerungen:

Zusammenfassend lässt sich festhalten: ChatGPT ist ein nützlicher Begleiter in der Anforderungsanalyse, insbesondere bei der Redundanzprüfung und in der Unterstützung bei Stakeholder-Zuordnungen. Schwächen bestehen vor allem bei der Priorisierung, da diese nicht allein aus Dokumenten abgeleitet werden kann. Generative KI ersetzt die Expertise menschlicher Analyst:innen nicht, bietet jedoch wertvolle Unterstützung, indem sie Routineaufgaben automatisiert und erste Analysen beschleunigt.

Der Beitrag Das Potenzial von generativer KI in der Anforderungsanalyse – Teil 2 erschien zuerst auf Masoona Consulting.

Christian, herzlichen willkommen bei masoona!

Wir freuen uns einen neuen Mitarbeiter bei uns begrüßen zu können: Christian Piegert verstärkt unser Team seit dem 10.11. Christian bringt langjährige Erfahrung im Prozessmanagement, in der Business Analyse, im Projektmanagement und in der Konzeptionierung und strategischen Positionierung von Digitalisierungsvorhaben mit. Wir wünschen einen guten Start und viel Erfolg bei der masoona!

Du suchst einen neuen Job? Dann bewirb dich bei uns – wir wollen unser Team weiter verstärken: masoona.de/karriere

Der Beitrag Christian, herzlich willkommen bei masoona! erschien zuerst auf Masoona Consulting.

Camunda 7 Community Edition (CE) End of Life

Was tun, was sind die Alternativen?

Einleitung

In unserem DigiLAB nutzen wir mehrere Business Process Management-Plattformen (BPM-Plattformen) zu Demonstrations- und Übungszwecken. Dazu gehört neben anderen auch eine Plattform, die auf dem Toolstack von Camunda 7 Community Edition (CE) basiert. Wir verwenden sie insbesondere um die Vor- und Nachteile offener Architekturen mit lose gekoppelten Komponenten, den Best of Breed- und den Better-Coding-Ansatz der Prozessdigitalisierung und -automatisierung zu demonstrieren. Camunda 7 vereint eine hohe Performance der Engines mit einer offenen Architektur, bereitgestellt als Open Source. Die BPM-Plattform umfasst eine Prozess- und eine Entscheidungsengine, eine Tasklist mit Basisfunktionalität für die Aufgabenverwaltung sowie das Camunda Cockpit zur Administration und Überwachung von Prozessinstanzen. Camunda Optimize – ein Tool zur Erhebung und Analyse von Prozesskennzahlen bleibt hingegen der Enterprise Edition vorbehalten, ebenso wie einige Funktionen des Cockpits¹.

Mit Camunda 8 ist eine neue Plattform verfügbar, die perspektivisch Camunda 7 ablösen wird. Der Support der Community Edition von Camunda 7 wird bereits im Oktober 2025 mit Camunda Version 7.24 enden. Danach werden für die Community Edition weder funktionale noch Sicherheitsupdates bereitgestellt. Für die Enterprise Edition wird Camunda gemäß der aktuellen Roadmap noch bis April 2030 vollen Support bieten, im April 2032 endet dann auch der erweiterte Support. Ab Oktober gibt es aber auch für die Enterprise Edition nur noch Sicherheitsupdates für kritische Bugs und die Kompatibilität mit den Laufzeitumgebungen wird gewährleistet. Funktionale Updates wird es nicht mehr geben.²

Grund genug uns einmal Alternativen anzuschauen, sie zu analysieren und für uns zu bewerten.

Alternativen und ihre Vor- und Nachteile im Überblick

Was kann also getan werden, wenn aktuell Camunda 7 CE eingesetzt wird und die BPM-Plattform nicht ohne Support seitens des Anbieters weiter betrieben werden soll? Die nachfolgende Tabelle zeigt die Alternativen:

Unsere Migration

In einem ersten Schritt haben wir die Migration auf einen Fork von Camunda 7 getestet, da es unser Ziel ist, mit der Plattform unsere Architektur und den Best of Breed- sowie den Better Coding-Ansatz für die Digitalisierung und Automatisierung von Prozessen zu demonstrieren. Dabei haben wir uns für die Plattform CIB seven entschieden – aus mehreren Gründen:

1. Die Plattform ist bereits in Version 1.1.0 öffentlich verfügbar. Die CIB stellt Maven Dependencies, eine ausführliche Dokumentation sowie Migrationsskripte zur Verfügung. Die Plattform ist Open Source.
2. Die CIB hat eine klare Roadmap für die Bereitstellung und die Weiterentwicklung der Plattform.
3. Die Plattform kann mit der Lösung CIB seven EE oder CIB flow kombiniert werden. CIB seven EE stellt analog zu Camunda 7 EE die Enterprise Feature inkl. Optimize und Long Term Support bereit. CIB flow ermöglicht den Einsatz von Low Code bei der Automatisierung von Prozessen in Ergänzung zum Better Coding-Ansatz.

Unser DigiLAB Workflow Management System ist modular aufgebaut. Die Prozess- und die Entscheidungsengine sind in einer als “ProcessApp” bezeichneten eigenständigen Komponente gekapselt. Diese Komponente besitzt Dependencies zu Camunda 7, die wir durch die entsprechenden Dependencies zu CIB seven ausgetauscht haben. Mit Suchen und Ersetzen ging das ebenso wie die Aktualisierung der Importe sehr schnell. Die bereitgestellten Migrationsskripte⁷ haben wir dafür gar nicht benötigt, sie sind aber sicher bei komplexen Applikationen sehr nützlich. Vor der Migration haben wir unser System noch auf die Version 7.22 von Camunda CE gehoben.

Wir benutzen das Camunda Community Keycloak-Plugin von Gunnar van der Beck, accso⁸. Das Plugin setzt auf der Camunda 7 Plattform auf und ist daher zunächst nicht mit CIB seven kompatibel. Aber auch hier ist die Migration schnell erledigt – im ersten Schritt und zu Testzwecken haben wir hier unseren eigenen Fork erstellt, die notwendigen Anpassungen an den Dependencies und Importen vorgenommen und als lokale Dependency für unsere Entwicklungsumgebungen bereitgestellt. Die CIB ist dabei, eine eigene Community für die Entwicklung und Pflege von Plugins aufzubauen. Inwiefern dann Migrationen von Plugins der Community auf CIB seven erfolgen bleibt abzuwarten, stellt aber sicher einen wichtigen Erfolgsfaktor dar.

Unsere ProcessApp haben wir anschließend als Container in unsere BPM-Plattform eingebunden und können nun wahlweise Camunda 7.22 CE oder CIB seven 1.1.0 verwenden – je nach Bedarf aktivieren wir den einen oder den anderen Container. Unsere Workflows sind in beiden Umgebungen uneingeschränkt lauffähig. Für die Administration und die Überwachung der Workflows verwenden wir weiterhin die Camunda Webapps Admin und Cockpit in einer eigenen gekapselten Komponente. Pendants von CIB seven stehen hier in der aktuellen Version 1.1.0 noch nicht zur Verfügung. Dies soll sich aber mit der Version 2.0 ändern. Wir sind gespannt.

Ausblick

Es stehen verschiedene Möglichkeiten zur Verfügung, dem Ende des Lebenszyklusses von Camunda 7 CE zu begegnen. Mit unserer Camunda- bzw. zukünftig auch CIB seven basierten BPM-Plattform wollen wir dessen offene Architektur verbunden mit dem Best of Breed- und dem Better Coding-Ansatz als eine Alternative für den Einsatz von BPM-Plattformen weiter verfolgen. Für andere Ansätze, bspw. einer stärker integrierten BPM-Plattform mit Komponenten aus einer Hand, nutzen wir die Produkte anderer Anbieter. Und so ist auch unser Zwischen-Fazit: CIB seven oder andere Forks sind für die Zukunft interessant, wenn der Philosophie von Camunda 7 CE treu geblieben und die Zukunftssicherheit des eigenen Systems mit geringen Migrationsaufwänden erhalten werden soll. Die Migration auf CIB seven 1.1.0 ist einfach und problemlos möglich – ggf. zunächst auch einfach mal zu Testzwecken.

Wie stehen Sie zu den Alternativen – sehen Sie ggf. weitere? Wenn Sie sich mit uns zu diesem Thema austauschen wollen – kommen Sie auf uns zu. Gerne diskutieren wir Ihre Fragen und Probleme hands on in unserem DigiLAB.

1. Zu den Unterschieden zwischen Camunda 7 Community Edition und Enterprise vgl. auch Camunda 7 Editions . Abruf am 25.04.2025 ︎
2. Support Announcements, Support Announcements | docs.camunda.org. Abruf am 15.04.2025 ︎
3. Zum Preismodell von Camunda 8 vgl. Preise. Abruf am 23.04.2025 ︎
4. CIB seven: CIB seven Open Source Camunda 7 Alternative – Migration. Abruf am 22.04.2025 ︎
5. Operaton: Operaton – Operaton. Abruf am 22.04.2025 ︎
6. Eximee BPMS: New stable open source Camunda 7 alternative | EximeeBPMS. Abruf am 25.04.2025 ︎
7. Migrationsskripte für die Migration auf CIB seven: GitHub – cibseven/cibseven-migration: Migration project from Camunda 7.22 to CIB seven 1.1, based on OpenRewrite. Abruf am 22.04.2025 ︎
8. Camunda Community Keycloak-Plugin: GitHub – camunda-community-hub/camunda-platform-7-keycloak: Camunda Keycloak Identity Provider Plugin. Abruf am 22.04.2025 ︎

Der Beitrag Camunda 7 Community Edition (CE) End of Life – Was tun, was sind die Alternativen? erschien zuerst auf Masoona Consulting.

Workflows oder Cases?

Wann setze ich welches Konzept ein

Einleitung

Die Digitalisierung und Automatisierung von Prozessen sind kritische Erfolgsfaktoren für die erfolgreiche Bewältigung der digitalen Transformation von Organisationen. Prozesse übernehmen Eingaben aus ihrer Umwelt und transformieren diese zielgerichtet mittels Aktivitäten in Outputs. Klassischerweise wird dabei angenommen, dass die Ablaufreihenfolge von Aktivitäten vor der Ausführung der Prozesse (zur sogenannten Buildtime) bestimmbar ist und spezifiziert werden kann. Dieser Typ von Prozessen wird auch als “strukturiert” bezeichnet. Im Ergebnis der Digitalisierung und Automatisierung dieser Prozesse entstehen Workflows. Nicht immer jedoch können die Ablaufreihenfolgen auch wirklich zur Buildtime bestimmt werden – wir sprechen dann von unstrukturierten Prozessen.

In diesem Beitrag beleuchten wir zwei Konzepte zur Digitalisierung von Prozessen und stellen sie einnander gegenüber: Workflows und Cases. Im Gegensatz zur Workflows dienen Cases der Digitalisierung und Automatisierung unstrukturierter Prozesse. Wir gehen zudem der Frage nach, wie Workflows und Cases zur Digitalisierung von Prozessen miteinander kombiniert und Workflows iterativ aus Cases heraus entwickelt werden können.

Workflows

Sind die Ablaufreihenfolgen von Aktivitäten bekannt bzw. können diese zur Buildtime von digitalen Prozesse ermittelt werden (strukturierte Prozesse), so können Prozesse als Workflows digitalisiert und so die Ablaufreihenfolge von Aktivitäten automatisiert werden. Mögliche Ablaufreihenfolgen von Aktivitäten werden dabei mit Hilfe einer grafische Workflowbeschreibungssprache, wie bspw. der Business Process Model and Notation (BPMN) der Object Management Group (OMG)¹, festgelegt. Entscheidungen, welcher Pfad zu wählen ist, können dabei auf unterschiedliche Arten getroffen werden:

Cases

Sind die möglichen Ablaufreihenfolgen von Aktivitäten zur Buildtime hingegen nicht bekannt oder der Aufwand zu deren Ermittlung sehr hoch (unstrukturierte Prozesse), so können diese nicht a priori beschrieben werden und zur Laufzeit automatisiert eine Reihenfolge gewählt werden. Dennoch ist es auch in diesen Fällen möglich, einen Prozess Ende-zu-Ende zu digitalisieren. Cases, deutsch auch Fälle genannt, stellen eine Alternative zu Workflows dar. Bei der Spezifikation von Cases zur Buildtime werden zwar die Aktivitäten analog zu Workflows modelliert, die Ablaufbeziehungen jedoch nicht oder nur teilweise. Hier bleibt es zur Runtime eines Cases den Prozessbeteiligten überlassen, die jeweils nächste Aktivität auszuwählen und zu starten. Dies bedingt das entsprechende prozedurale Wissen bei den Prozessbeteiligten, dafür sind jedoch die Freiheitsgrade bei der Festlegung einer konkreten Reihenfolge für einen Fall sehr viel größer. Beispiele für diese Art von Prozessen sind wissensintensive Prozesse, bei denen explorativ mehr und mehr über den konkreten Fall gelernt wird, wenn dieser bearbeitet wird. Auf Basis des erworbenen Wissens und des bereits vorhandenen Wissens aus anderen Fällen werden von den Prozessbeteiligten die jeweils nächsten Aktivitäten ausgewählt. Die Bereitstellung, die kontinuierliche Verbesserung und die adäquate Unterstützung der Fallbearbeitung mit IT-Systemen wird als Adaptive Case Management bezeichnet^2,3.

Für die Modellierung von Cases zur Buildtime und deren Ausführung zur Runtime steht ebenso wie für Workflows eine Notation zur Verfügung – die Case Management Model and Notation (CMMN) der OMG⁴. Für die Ausführung werden Case Engines verwendet. Alternativ, aber verbunden mit Einschränkungen, können hier auch ad hoc- oder Ereignis-Teilprozesse der BPMN verwendet werden.

Dennoch ist es auch mit Cases möglich, Ablaufreihenfolgen zwischen Aktivitäten zur Buildtime zu spezifizieren bzw. die Freiheitsgrade bei der Auswahl von konkreten Ablaufreihenfolgen durch Casebeteiligte zur Runtime einzuschränken. In Abhängigkeit vom Zustand eines Cases können gewisse Aktivitäten ausgeführt werden, andere jedoch nicht. Auch kann bspw. festgelegt werden, dass gewisse Aktivitäten ausgeführt werden müssen.

Kombination und Transformation

Beide Ansätze des Digitalisierung von Prozessen können miteinander kombiniert werden. Mehrere Anwendungsfälle sind dabei möglich:

Prozesse können in einem Digitalisierungsprojekt zunächst nur als unstrukturierte Prozesse digitalisiert werden. Grund ist, dass die Analyse der Ablaufreihenfolgen von Aktivitäten sehr aufwändig und zeitintensiv sowie mit großen Unsicherheiten behaftet, insbesondere bzgl. der Häufigkeit genutzter Pfade, sein kann. Das Minimum Viable Product (MVP) besteht dann zunächst nur aus Cases, bei denen die Prozessbeteiligten ihr Wissen nutzen müssen, um Aktivitäten in der richtigen Reihenfolge zu starten. Die tatsächlichen Ablaufreihenfolgen werden dann im Zuge aus den Casebearbeitungen durch die Prozessbeteiligten zur Runtime ermittelt und wo wirtschaftlich oder zur Verbesserung der Qualität sinnvoll werden die Cases iterativ in Workflows transformiert. Die Transformation von Cases in Worflows werden wir in einem weiteren Beitrag beleuchten.

Fazit

Für beide Arten von Prozessen – strukturierte und unstrukturierte – stehen Konzepte für deren Digitalisierung inkl. der hierfür benötigten Notationen und Plattformen zu deren Ausführung bereit. Beide Konzepte können zudem miteinander kombiniert werden. Durch gezielten Verzicht auf die Spezifikation von Ablaufbeziehungen zwischen Aktivitäten bei einer Prozessdigitalisierung kann zudem die Zeit bis zum ersten digitalen MVP verkürzt werden. Eine nachträgliche Transformation in einen Workflow kann dann sukzessive erfolgen um manuelle Aufwände in der Bearbeitung zu reduzieren.

So ist abschließend festzuhalten, dass es sich Workflows und Cases nicht gegenseitig ausschließen, wie der Titel des Beitrags ein wenig suggeriert. Vielmehr ergänzen sich beide und bedienen spezifische Anwendungsfälle bei der Digitalisierung von Prozessen.

Haben wir Ihr Interesse geweckt? Schauen Sie doch bei uns in unserem DigiLAB vorbei. Wir halten hier für Sie spannende Angebote bereit, mit denen Sie in die Welt der Workflows und der Cases eintauchen können:

1. Zur BPMN vgl. auch die Spezifikation der Object Management Group: About the Case Management Model and Notation Specification Version 1.1 . Abruf am 08.01.2025 ︎
2. Dr. Michael Jacob, Patrick Dohrmann: “Digitalisierung von Prozessen – Ein Lösungsansatz für das Prozessmanagement”. Veröffentlicht in “Der Prozessmanager”, 2019 ︎
3. BITKOM: “Adaptive-Case-Management” – Leitfaden und Nachschlagewerk. BITKOM, 2013 ︎
4. Zur CMMN vgl. auch die Spezifikation der Object Management Group: About the Case Management Model and Notation Specification Version 1.1 . Abruf am 08.01.2025 ︎

Der Beitrag Workflows oder Cases? Wann setze ich welches Konzept ein erschien zuerst auf Masoona Consulting.

Dem Backlog Item und seinen Akzeptanzkriterien treu sein

Ich beobachte häufig, dass Backlog Items im Sprint nicht fertig werden. Betrachtet man im Nachgang die Schätzungen im Verhältnis zur Umsetzung und befragt das Team, ob sie die Schätzung noch mal so machen würden, stellt man fest: „Wenn wir nur das gemacht hätten, was in dem Item steht, hätte die Schätzung schon hingehauen.“ Kleinigkeiten hier und da zu ergänzen oder noch mal was zu refactoren, kostet am Ende mehr Zeit, als man denkt. Teilweise verliert man sich in Details und Edge Cases. Währenddessen warten andere für den Sprint vorgesehene Items sehnsüchtig auf ihre Umsetzung.

Gut geschriebene Backlog Items sind unerlässlich

Ein häufiger Grund ist die unzureichende Beschreibung der Backlog Items. Wie detailliert und präzise beschrieben das Backlog Item sein muss, ist abhängig vom Team und dessen Lernprozess dazu. Selbstverständlich ist es unabdingbar, den Nutzen des Backlog Items zu formulieren, sodass die Erarbeitung der Akzeptanzkriterien wesentlich einfacher fällt. 

Dazu eignet sich hervorragend das sogenannte Connextra Template. Das Schema “Als (Persona/Anwenderrolle) brauche ich (Funktion), um/damit (Nutzen).” Damit ist nachvollziehbar, für wen, was wozu entwickelt werden soll. Zur Beschreibung der sich daraus ableitenden Akzeptanzkriterien kann man sich an den INVEST-Kriterien orientieren (s. Wikipedia). 

Man kann sich immer fragen: “Was wird benötigt, um den Nutzen für den Anwender zu erreichen?“. Ich plädiere hier vor allem am Anfang dieses Lernprozesses für „Mehr ist mehr“. Das Team sollte lieber ein Akzeptanzkriterium mehr als zu wenig erfassen. Und warum beschreibt man nicht mal das, was man nicht machen möchte? So wird die Aufgabe klar von weiteren Backlog Items abgegrenzt und es wird verhindert, dass man mehr umsetzt, als das Backlog Item vorsieht.

Dem Backlog Item treu sein

Nachdem das Backlog Item gut beschrieben ist und vom Team als „ready“ eingestuft wurde, muss das Bewusstsein geschärft werden, sich an dessen Inhalt zu halten. Ein Backlog Item sollte grundsätzlich immer als unveränderlich im Sprint behandelt werden. Vermutlich könnten einige nun sagen: „Das ist doch nicht agil! Alles kann sich jederzeit verändern und man muss darauf reagieren!“ 

Das Team hat sich zusammen auf einen Plan für den Sprint festgelegt. Wenn die Items währenddessen einfach geändert werden, kann man nicht mehr einschätzen, welcher Mehrwert in dem Sprint geliefert wird. Das kann negative Konsequenzen auf zugesicherte Liefertermine haben. 

Folgende Fragen sollte man sich stellen, wenn während der Umsetzung von der Anforderung abgewichen wird: Hat sich die Kundenanforderung geändert? Ist diese Mehrarbeit wirklich wertsteigernd? Muss die Mehrarbeit genau jetzt getan werden, oder reicht es auch, sie später umzusetzen? Wer bezahlt die kleinen Extras, die wir jetzt zusätzlich machen? Das ist natürlich nur eine Auswahl an möglichen Fragestellungen und Problemen, die auftreten können. 

Sofern auf diese Fragen keine zufriedenstellende Antwort gefunden wird, dann muss die Mehrarbeit vermieden werden. Andernfalls kann mit dem Product Owner oder im ganzen Team darüber gesprochen werden, um zu entscheiden, was passieren soll. Es ist immer möglich, während der Entwicklung im Sprint gewonnene Erkenntnisse in neue Backlog Items zu gießen, die zur Wertsteigerung des Produktes beitragen oder aufgrund von technischer Notwendigkeit entstehen.

Verlässlichkeit durch genaue Vorhersagen der Umsetzungen

Wenn man sich an das oben beschriebene hält, und nur das, was im Backlog Item formuliert ist, umsetzt, dann ist die Schätzung eines Backlog Items brauchbar. Es ist ungemein hilfreich für die Auswertung einer Velocity und das Planen von Releases, verlässliche Zahlen zu haben. So kann man dem Kunden letztendlich das liefern, was ihm zugesichert wurde. Zuverlässige Lieferung und ein qualitativ hochwertiges Produkt sind die Basis für eine vertrauensvolle und produktive Zusammenarbeit mit den Kunden.

von Carolin Neufert

Der Beitrag Dem Backlog Item und seinen Akzeptanzkriterien treu sein erschien zuerst auf Masoona Consulting.

Prozessdigitalisierung und -automatisierung sind für viele Kunden ein strategischer Baustein zur digitalen Transformation der gesamten Organisation. Masoona Consulting begleitet seine Kunden auf dem gesamten Weg von der Digitalisierung einzelner Prozessschritte bis hin zur integrierten und gesamtheitlichen Ende-zu-Ende-Automatisierung ihrer Geschäftsprozesse.

Wir fokussieren uns mit unseren Kompetenzen im Kontext des Business/IT- Alignments auf die Konzeption und Steuerung der digitalen Transformation. Die konkrete Umsetzung gestalten wir gemeinsam mit dem Kunden und unter Einbezug von ausgewählten kompetenten Partnern.

Aus konkreten Kundensituationen bei Digitalisierungsvorhaben unserer Kunden in diversen Branchen haben wir aus der Vielzahl von großen und kleinen Herausforderungen vier herausgeschält, die für uns besonders herausstechen und bei deren Bewältigung wir unsere Kunden unterstützen wollen.

In diesem Beitrag werde ich zwei dieser strategischen Herausforderungen und unsere Erfahrungen beim Umgang mit ihnen vorstellen, zum einen die Adaption und Beherrschung innovativer Technologien, zum anderen die Evolution der Fach- und IT-Architektur im Zuge der Digitalisierung von Prozessen.

Für die Ende-zu-Ende-Automatisierung eines Kernprozesses ist ein komplexer Mix innovativer Technologien notwendig. Es ist normal, dass die eine oder andere Technologie, wie bspw. Robotic Process Automation, Decision Automation oder Artificial Intelligence, für ein Unternehmen oder eine Behörde “Neuland” darstellt und die Fähigkeit zum effizienten und zielgerichteten Einsatz einer solchen Technologie (noch) nicht vorhanden ist. Heutzutage bieten sich zwei hier zwei Alternativen zur Lösung des Problems an: Outsourcing an einen externen Dienstleister ist die eine (1), Internalisierung von Produkten und des zur ihrer Nutzung benötigten Wissens die andere (2). Bei haben ihre Vor- und Nachteile: Während die erste Alternative davon befreit, neue Technologien in der eigenen Organisation zu adaptieren (im Extremfall mit PaaS – Process as a Service), bietet die zweite größtmögliche Freiheit und Flexibilität beim Einsatz der Technologien bzw. der sie implementierenden Produkte zur Unterstützung der eigenen Prozesse.

Beide haben jedoch ihre spezifischen Voraussetzungen: Ohne eine eigene leistungsfähige IT und die Bereitschaft in Softwareentwicklung zu investieren lässt sich Variante zwei nicht umsetzen. Was wie eine Binsenweisheit klingt, erleben wir leider sehr häufig: Auf der einen Seite besteht der Wunsch möglichst flexibel zu agieren und natürlich nur die am besten passenden Produkte, im Extremfall Eigenentwicklungen, in der eigenen Organisation einzusetzen. An einer adäquaten langfristig gesicherten Finanzierung, insbesondere auch zur Integration der einzelnen Komponenten miteinander, und dem Willen zu organisatorischen Änderungen mangelt es jedoch. Auch scheitert oft der Aufbau neuen Wissens und neuer Fähigkeiten in der eigenen Organisation – die langfristige Abhängigkeit von externem Know-how und damit einhergehende Kosten sind die Folge.

Eine weitere wichtige Herausforderung ist die Evolution, die Weiterentwicklung, der bestehenden Fach- und IT-Architektur. Prozessdigitalisierung beginnt nicht auf der grünen Wiese. Bestehende Digitalisierungsinseln in den Prozessen müssen miteinander verbunden, bestehende Prozessautomatisierungen zu einer Ende-zu-Ende-Digitalisierung und -automatisierung ausgebaut werden. Oder anders gesagt: Fach- und IT-Architekturen müssen mit dem Ziel einer Ende-zu-Ende-Digitalisierung und -automatisierung weiterentwickelt werden. Oftmals aber geschieht genau das nicht, sondern es werden entweder unpassende Tools, insbesondere Digitalisierungsplattformen, gekauft oder aber bestehende Inseln ausgebaut und mit bekannten, aber nicht geeigneten Technologien miteinander verbunden. Es wird lokal optimiert, die globale Steuerung fehlt und so werden auch die globalen Ziele verfehlt. Im Ergebnis bleibt die Prozessdigitalisierung und -automatisierung bruchstückhaft und große Nutzenpotenziale liegen weiterhin brach.

Wir unterstützen Sie dabei, diesen Herausforderungen zu begegnen. Mit unseren Erfahrungen aus konkreten Projekten unterstützen wir Sie bei Technologieauswahlentscheidungen, Pilotprojekten, bei der Internalisierung von Wissen und der Weiterentwicklung Ihrer Organisation. Gemeinsam mit Ihnen prüfen wir Ihre Ihre Fach- und IT-Architektur auf ihre Zukunftsfähigkeit, brechen Silos auf und entwickeln die Architekturen planvoll mit den Beteiligten unter Berücksichtigung der globalen Ziele weiter.

Habe ich Ihr Interesse geweckt? Sprechen Sie mich an! Sie erreichen mich per Mail unter michael.jacob@masoona.de. Gerne können Sie auch einen unverbindlichen Austauschtermin vereinbaren: https://calendly.com/michael-jacob-77/austausch

Der Beitrag Technologien und Architekturen in der Prozessdigitalisierung: Keine halben Sachen! erschien zuerst auf Masoona Consulting.