Prozessgetriebenes Requirements Engineering für Produkte
22. April 2026
Große, unternehmensübergreifende Softwaresysteme zu bauen ist heute anspruchsvoll. Solution Architects müssen für bestehende Probleme die richtigen Lösungen so gestalten, dass die Nutzer des Systems echten Nutzen haben. Dieser Artikel stellt den FASD-Ansatz vor. FASD ist prozessgetrieben und eignet sich für technische wie nichttechnische Solution Architects. FASD entstand aus wissenschaftlichen und praktischen Erfahrungen in unseren JadenX Kundenprojekten. Es unterstützt bei Prozess- und Softwaredesign ebenso wie bei Managementaufgaben, etwa der Festlegung des Projektumfangs.
Große Unternehmenssysteme zu bauen ist heute anspruchsvoll. Die Systeme, mit denen wir arbeiten, erstrecken sich über mehrere Unternehmen, umfassen verschiedene Systeme und viele Interaktionen dazwischen. Für Solution Architects besteht die übergeordnete Aufgabe darin, die richtigen Lösungen für bestehende Probleme so zu schaffen, dass der Nutzer des Systems echten Nutzen hat. Requirements Engineering konzentriert sich darauf, Anforderungen von den möglichen Nutzern eines Systems zu erheben. Diese Anforderungen dienen als Input für viele Aufgaben im Softwaresystemdesign.
Dieser Artikel stellt FASD vor (Fast Guide to Process-driven Solution Design), unseren prozessgetriebenen Ansatz für schnelles Requirements Engineering. FASD kombiniert bestehende Ansätze für technische und nichttechnische Requirements Engineers. Im Fokus stehen die schnelle Erhebung von Anforderungen, ihre Strukturierung und daraus abgeleitete Designentscheidungen. FASD beruht auf unseren Erfahrungen mit komplexen Softwaresystemen. Der Ansatz eignet sich für die Bestandsaufnahme, das Interaktionsdesign und die präzise Abgrenzung großer Projekte. FASD liefert damit Erkenntnisse für technische Aufgaben (Softwaredesign, Schnittstellendesign) und nichttechnische Aufgaben (Prozessdesign, Projektmanagement).
Wer FASD anwendet, braucht ein Grundverständnis von Design Thinking und Geschäftsprozessmodellierung. Die folgenden Abschnitte geben einen kurzen Überblick über beide Konzepte.
Design Thinking ist ein praktischer und kreativer Ansatz zur Problemlösung. Ursprünglich entstand es aus der Verbindung verschiedener Disziplinen, darunter Architektur, Ingenieurwesen und Betriebswirtschaft. Konzeptionell stützt es sich stark auf die Methoden und Prozesse von Designern. Design Thinking ist domänenunabhängig und lässt sich auf jeden Anwendungsbereich übertragen. Das Paradigma ist stark nutzerzentriert. Der Ansatz will die Bedürfnisse von Menschen verstehen und wirksame Lösungen dafür finden.
Design Thinking umfasst viele Aktivitäten und Werkzeuge. Alle zielen darauf, Kunden oder Nutzer besser zu verstehen. Eine zentrale Aktivität in FASD ist die Erstellung von Personas. Eine Persona ist eine fiktive Figur, die einen Typ von Kunde oder Nutzer eines Service oder Produkts darstellt. Sie beruht auf Erkenntnissen über echte Kunden und Nutzer. Personas abstrahieren den „typischen Nutzer“ und vereinen Merkmale, die viele Nutzer gemeinsam haben. Ihre Erstellung ist stark forschungsbasiert und zielt darauf, Bedürfnisse, Verhalten, Erfahrungen und Ziele von Kunden und Nutzern zu verstehen. In FASD ist die Erstellung von User Personas einer der wichtigsten ersten Schritte.
Die zweite Zutat der FASD-Methode sind Geschäftsprozessmodelle. FASD ist von Grund auf prozesszentriert. A Geschäftsprozess ist eine Menge von Aktivitäten, die gemeinsam ausgeführt werden, um ein bestimmtes Geschäftsziel zu erreichen. Prozessmodelle sind eine visuell darstellbare Abstraktion eines Geschäftsprozesses.
Konzeptionell besteht ein Geschäftsprozessmodell aus Knoten und Kanten. Knoten stehen für Aktivitäten, Ereignisse und Gateways im Prozess. Kanten drücken Sequenz- oder Nachrichtenflüsse aus. Aktivitäten sind Arbeitseinheiten im Prozess: automatisierte Aufgaben, manuelle Aufgaben oder ganze Teilprozesse. Ereignisse zeigen, dass ein bestimmter Punkt erreicht ist, etwa Start-, End- oder Fehlerereignisse. Gateways wie Verzweigungen oder Zusammenführungen bilden Entscheidungspunkte oder parallele Abläufe ab. Kanten verbinden die Knoten. Sie können Sequenzflüsse (innerhalb einer Organisation) oder Nachrichtenflüsse (zwischen Organisationen) darstellen.
Viele Modellierungssprachen für Geschäftsprozesse stellen verschiedene Organisationen oder Organisationseinheiten mit Lanes oder Poolsdar. Prozesse, in denen mehrere Organisationen in einem gemeinsamen Workflow zusammenarbeiten, heißen kollaborative Geschäftsprozesse.
Die Business Process Model and Notation (BPMN) ist eine standardisierte Modellierungssprache. FASD empfiehlt BPMN, auch wenn grundsätzlich andere Prozessmodellierungssprachen möglich sind. Dieser Artikel ist kein BPMN-Tutorial. Für den Einstieg in BPMN empfehlen wir dieses Buch.
Dieser Abschnitt stellt die FASD-Methode vor, wie in der Abbildung unten dargestellt.
FASD verbindet technische und nichttechnische Rollen, um eine vollständige Gesamtlösung zu erreichen. FASD besteht aus drei Hauptphasen.
Phase 1 erfasst die Ist-Situation und definiert die Ziele. Dazu modelliert FASD Personas, identifiziert Rollen und modelliert den Ausgangsprozess. Auf dieser Basis werden Leitbilder und übergeordnete Schwerpunkte festgelegt. Sobald ein Überblick über die Ist-Situation besteht, werden nichtfunktionale Rahmenbedingungen identifiziert. Sie bilden die grundlegenden Anforderungen an das Soll-Prozessdesign, die Leistung und die Kosten.
In der Regel übernehmen nichttechnische Solution Architects diese Phase. Sie erheben die Anforderungen der künftigen Systemnutzer und ihrer Organisation in Interviews.
Phase 2 befasst sich mit dem Design der Lösung. Zuerst werden der Soll-Prozess und die darin enthaltenen Systemfunktionen modelliert. Das erfordert eine Feedbackschleife zwischen technischen und nichttechnischen Solution Architects, Nutzern und ihren Organisationen. Lösungsdesign ist von Natur aus iterativ.
Nach dem Prozessdesign werden Systeminteraktionen und Schnittstellen entworfen. Für die Systeminteraktionen arbeiten Solution Architects und Nutzer zusammen. Technische Solution Architects entwerfen die technischen Schnittstellen und legen fest, wie die bestehenden Systeme der Organisation mit der neuen Lösung zusammenspielen. Am Ende von Phase 2 steht eine Aufwandsschätzung für die einzelnen Systemteile.
Phase 3 legt den initialen Umfang der Umsetzungsphase fest. Dazu gehören die Priorisierung von Features sowie die Ressourcen- und Zeitplanung.
FASD lässt sich grundsätzlich mit jedem Projektmanagement-Paradigma kombinieren. Im Wasserfallmodell durchlaufen Solution Architects die Methode einmal. In einem agilen Vorgehen wird FASD iterativ eingesetzt, um Lösungen für Probleme zu entwerfen.
Dieser Artikel hat Ihnen im Überblick gezeigt, wie der FASD-Ansatz funktioniert. Wenn Sie mehr wissen, tiefer einsteigen oder eine Schulung machen möchten, nehmen Sie Kontakt mit uns auf. Sprechen wir darüber, wie wir Ihnen helfen können.
