Status und API in der Systemanalyse kombinieren

Systemanalyse-Artefakte integrieren: Statusmodelle, Anwendungsfälle und APIs in einem einheitlichen Modell

In der Systemanalyse bilden User Stories (US) die Grundlage für alle Anforderungen. Daraus leiten Teams Statusmodelle, APIs und Anwendungsfälle ab. Die herkömmliche Vorgehensweise erzeugt jedoch fragmentierte Artefakte: Geschäftsanforderungen konzentrieren sich auf Szenarien, Entwickler auf Endpunkte und Testingenieure auf Testfälle. Unser vorgeschlagener Ansatz vereint alle drei Ebenen in einem einzigen, statusgesteuerten Modell mit expliziter API-Zuordnung – und liefert so allen Beteiligten eine kohärente, gemeinsame Sicht auf den gesamten Prozess.

Betrachten wir ein synthetisches Beispiel: ein Cloud-Infrastruktur-Miet-System. Ein Kunde schätzt Kosten ab, stellt eine Anfrage, durchläuft ein Risikoscore-Verfahren, zahlt und erhält anschließend die gewünschten Ressourcen.

Kern-User-Stories

Die Stakeholder liefern folgende User Stories:

| # | Titel | Beschreibung |

|---|-------|-------------|

| US-1 | Kostenabschätzung für Infrastruktur | Als potenzieller Kunde möchte ich die Kosten für Cloud-Infrastruktur für meine konkrete Workload abschätzen, um zu prüfen, ob dieser Anbieter mein Budget und meine technischen Anforderungen erfüllt. |

| US-2 | Anfrage basierend auf Abschätzung einreichen | Als registrierter und verifizierter Kunde möchte ich eine Infrastruktur-Bereitstellungsanfrage mithilfe einer zuvor generierten Kostenabschätzung einreichen – damit ich Parameter nicht erneut eingeben muss und schnell zur Zahlung übergehen kann. |

| US-3 | Automatisierter Scoring- und Freigabeprozess | Als Abrechnungssystem möchte ich neue Anfragen automatisch auf Risiken prüfen und entscheiden, ob eine manuelle Freigabe erforderlich ist – damit vertrauenswürdige Kunden schneller bearbeitet werden und das Risiko von Zahlungsausfällen minimiert wird. |

| US-4 | Rechnungserstellung und Zahlung | Als Kunde mit freigegebener Anfrage möchte ich eine Rechnung erhalten und diese per bevorzugter Zahlungsmethode begleichen – damit ich die bestellte Infrastruktur sofort aktivieren und nutzen kann. |

| US-5 | Automatische Infrastruktur-Bereitstellung | Als Cloud-Infrastruktur-Anbietersystem möchte ich Ressourcen automatisch nach bestätigter Zahlung bereitstellen – damit der Kunde sofort Zugriff erhält, ohne Verzögerungen oder manuelle Eingriffe.

Diese Stories definieren Akteure und Ziele – und bilden die Grundlage für das Statusmodell.

Prozess-Statusmodell

Basierend auf den User Stories identifizieren wir folgende Status im Lebenszyklus einer Anfrage:

• QUOTE_CREATED — Kostenabschätzung gespeichert; kommerzielles Angebot erstellt.
• ORDER_SUBMITTED — Anfrage eingereicht; wartet auf automatisches Risikoscore.
• UNDER_REVIEW — Anfrage wurde vom Vertriebsmanager zur manuellen Prüfung markiert.
• APPROVED — Anfrage freigegeben (automatisch oder manuell).
• REJECTED — Anfrage abgelehnt (mit Begründung angegeben).
• INVOICE_ISSUED — Rechnung erstellt und an den Kunden versandt.
• PAID — Zahlung erfolgreich eingegangen.
• EXPIRED — Rechnung nicht fristgerecht beglichen; Anfrage storniert.
• PROVISIONING — Infrastruktur-Bereitstellung läuft.
• ACTIVE — Infrastruktur ist live; Zugangsdaten wurden ausgegeben.
• FAILED — Bereitstellung fehlgeschlagen; Support-Ticket wurde automatisch angelegt.

Diese Status bilden das strukturelle Gerüst des Artefakts – und gruppieren logisch zusammengehörige Szenarien.

Anwendungsfälle und ihre Erweiterung

Anwendungsfälle fassen die funktionalen Fähigkeiten des Abrechnungssystems zusammen. Ihre Erweiterung bindet sie direkt an Statusübergänge und API-Endpunkte. Die Struktur des Artefakts umfasst:

• Geschäftslogik: Szenario-Schritte, zugeordnet zu Statusänderungen.
• Systemzustand: Das Statusmodell als zentrale Zustandsrahmen.
• Technische Umsetzung: Endpoint-Zuordnungen für jeden Anwendungsfall.

Beispielhafte Zuordnung: Der Übergang von ORDER_SUBMITTED zu APPROVED löst POST /score-order aus, gefolgt von PUT /approve-order.

Vorteile des einheitlichen Artefakts

Dieses Artefakt schließt die Abstraktionslücke zwischen Fachbereichen:

• Für Geschäftsanforderungen: Visueller Szenario-Fluss über Status – ideal für Workshops und Demos.
• Für Entwickler: Klare API-Kontextualisierung innerhalb des gesamten Lebenszyklus mit direkten Verknüpfungen zwischen Anwendungsfällen, Statusübergängen und Schnittstellenspezifikationen.
• Für Testingenieure: Sofort einsatzfähige Testfallgrundlage – abdeckend für Statusübergänge, Endpoint-Verhalten und alternative Abläufe.
• Für Projektmanager: Lebendige Implementierungscheckliste – zur Nachverfolgung fertiggestellter APIs und abgeschlossener Status.

Wichtige Hinweise

• Ein einheitliches Status-/Anwendungsfall-/API-Artefakt synchronisiert das Verständnis quer durch alle Disziplinen – ohne zusätzliche Tools oder Übersetzungsschichten.
• Das Statusmodell fungiert als tragende Säule, die Geschäftsprozesse und technische Endpunkte kohärent verbindet.
• Dieses Artefakt beschleunigt Testdesign, Entwicklung und Abnahme (UAT) – und reduziert Dokumentationsfragmentierung sowie Nacharbeit.
• Es ist besonders wertvoll bei Projekten mit komplexer Geschäftslogik – nicht als Ersatz für bestehende Artefakte, sondern als Verbindungselement zwischen ihnen.
• Praxiserfahrungen bestätigen seine Wirksamkeit in Stakeholder- und Teamalignment-Sitzungen.

Praktische Umsetzung

Erstellen Sie das Artefakt als strukturierte Tabelle oder Flussdiagramm in Tools wie Draw.io, Confluence oder Markdown. Beginnen Sie mit den User Stories, ergänzen Sie die Status und ordnen Sie dann Anwendungsfälle und zugehörige API-Endpunkte zu. In einem realen Projekt nutzte das Team das Artefakt zur Stakeholder-Ausrichtung: Sie öffneten das Dokument, durchliefen gemeinsam die Statuskette und markierten implementierte Komponenten. Subjektiv sank dadurch die Fehlausrichtung im Delivery-Team um 30–40 %.

— Editorial Team