Ausgangslage in der Praxis
Anforderungen werden in der Regel schriftlich, strukturiert und nach Priorität geordnet eingereicht. Der
Empfänger hängt vom Kontext ab. Im Arbeitsalltag sind es meist interne IT-Teams, das Produktmanagement
oder die Projektleitung, abgewickelt über Ticketsysteme wie Jira, Azure DevOps, ClickUp, ServiceNow oder
Asana.
Anforderungen für Prozessanpassungen, Change Requests, Bug-Fixes oder neue Initiativen sind in der Praxis
fachlich häufig schlecht beschrieben. Implizites Wissen wird vorausgesetzt, die Schnittstellen zwischen
Fachbereich und IT bleiben unklar, und Anforderungen werden oft als Lösung statt als Problem formuliert.
In agiler Softwareentwicklung wird zugunsten knapper User Stories häufig auf ausführliche
Spezifikationen verzichtet. Ohne saubere Akzeptanzkriterien und ohne fachliche Prozessmodelle wie BPMN
entstehen Missverständnisse. Beschrieben wird meist nur der goldene Weg, also der Idealfall. Seltene
Ausnahmen, Fehlerbehandlungen und Folgeprozesse bleiben ausgeblendet, was zu Lücken in der späteren
Systemanpassung führt.
Den Beteiligten fehlt zudem oft eine gemeinsame Sprache. Fachbereiche denken in Business-Begriffen, während
die IT logische und systemische Regeln benötigt. Wo das Bindeglied fehlt, typischerweise ein Business
Analyst, bleiben die Beschreibungen vage.
Workshops, Reviews und Refinements als etablierte Gegenmittel
Workshops, Reviews und Backlog Refinements sind die etablierten Praktiken, um Anforderungen nach der ersten
Einreichung zu verbessern. Eine klare Definition of Ready hilft, das Niveau dieser Formate zu sichern. Diese
Praktiken sind notwendig und wertvoll, setzen aber alle nach der Einreichung an, also zu einem Zeitpunkt, an
dem die Anforderung bereits in Umlauf gebracht wurde. Vertagungen, Nachschärfungen und Eskalationen sind
die häufigen Folgen einer solchen rein reaktiven Qualitätskontrolle.
Beitrag des Modells
Das Role-Based Decision & Process Simulation Framework setzt davor an. Durch die iterative Konsultation
virtueller Rollen entsteht ein konsolidierter Entscheidungsreport mit Governance-Status, Rollenkonflikten,
Risiko-Klassifizierung, Pattern-Empfehlungen, Architektur-Skizze und nächsten Schritten. Dadurch gelangt
die Anforderung in einem deutlich tragfähigeren Zustand ins Backlog Refinement. Auch dort, wo eine
Anforderung bereits Lösungsansätze enthält, die im Unternehmen akzeptiert sind, lassen sich
diese gegen die fachliche und technische Sicht der relevanten Rollen prüfen.
Hintergrund und Eigenanteil
Die Methode ist aus rund zwanzig Jahren Praxis in Prozess- und Requirements Engineering in agilen
Software-Entwicklungs-Kontexten entstanden, mit Schwerpunkten in Banking, Versicherung und Medien.
Konzeptioneller Bezugspunkt ist die Schwarmintelligenz-Idee aus offenen Multi-Agent-Engines wie MiroFish.
Die Implementierung, die Rollen-Spezifikationen, die Konsolidierungs-Logik und die domänenbezogene
Anwendung auf Enterprise-Entscheidungsvorbereitung sind eigene Arbeit.
Reife und bewusste Eingrenzung
Die hier gezeigte Schicht ist eine Präsentations- und Demonstrations-Schicht. Sie ist bewusst eingegrenzt
durch die Lesbarkeit für ein gemischtes Publikum und durch die Möglichkeiten der lokal betriebenen
Ollama-LLM-Runtime auf dem NAB9-Mini-PC. Höhere Ausbaustufen wie Ressourcen- und Kapazitäts-Bewertung
oder Cloud- und GPU-basierte Parallelisierung sind in der Roadmap angelegt, aber nicht Teil dieser Schicht. Die
weiter unten beschriebenen Anwendungsschichten sind Beispiele aus einem grösseren Spektrum, abhängig
von der Entwicklungsstufe des jeweiligen Unternehmens.
🔍 Vergrössern
