Referenzprojekt: Interne Serviceanfragen

Dieses Referenzprojekt ist fiktiv. Es veranschaulicht das SHAPE Framework anhand einer internen Anwendung zum Einreichen und Prüfen von Serviceanfragen. Das Szenario ist bewusst so klein, dass der Zusammenhang zwischen geschäftlicher Absicht, Spezifikationen, Implementierung und Verifikation sichtbar bleibt.

Das Beispiel schreibt weder einen Technologiestack noch UI-Design, Datenbankarchitektur oder Deployment-Modell für Unternehmen vor. Reale Projekte müssen ihren eigenen freigegebenen Standards folgen.

Mitarbeiter reichen interne Serviceanfragen derzeit über uneinheitliche Nachrichten ein. Das empfangende Team kann schwer feststellen, wer eine Anfrage verantwortet, ob Informationen vollständig sind und ob eine Entscheidung mitgeteilt wurde. Die Organisation wünscht einen grundlegenden Ablauf, in dem Anfragen eingereicht und von autorisierten Prüfern ausdrücklich genehmigt oder abgelehnt werden können.

Die erste Veröffentlichung soll den Zustand einer Anfrage für Antragsteller und zugewiesenen Prüfer verständlich machen. Sie versucht nicht, Erfüllung, Service-Level-Vereinbarungen, Beschaffung oder produktive Benachrichtigungsinfrastruktur zu automatisieren.

Ziel: Einen nachvollziehbaren Weg zum Einreichen und Entscheiden interner Serviceanfragen bereitstellen.

Vorgesehene Benutzer: Mitarbeiter als Antragsteller; benannte Beschäftigte als Prüfer; gegebenenfalls eine administrative Rolle zur Pflege der Prüferzuweisungen.

Im Umfang: Anfragen erstellen und einreichen, Pflichtinformationen validieren, Anfragestatus anzeigen, eingereichte Anfragen prüfen, mit dokumentierten Entscheidungen genehmigen oder ablehnen, Aktionen rollenabhängig beschränken und Antragstellern das Einsehen des Ergebnisses ermöglichen.

Außerhalb des Umfangs: Erfüllung genehmigter Anfragen, finanzielle Verpflichtungen, automatisierte Zuweisungsoptimierung, Zugang externer Kunden, Analyse-Dashboards und Verfahren für Produktionsreleases.

Anfängliche fachliche Zustände: Entwurf, Eingereicht, Genehmigt, Abgelehnt. Bedeutungen und erlaubte Übergänge werden in der Funktionsspezifikation gepflegt.

Der Product Engineer befragt mehrere Antragsteller und Prüfer. Antragsteller wünschen eine Bestätigung der Einreichung und ein klares Ergebnis. Prüfer benötigen vollständige Informationen und einen verlässlichen Entscheidungsnachweis. Der Product Engineer identifiziert offene Fragen: Wer darf Anfragen prüfen? Dürfen Prüfer über eigene Einreichungen entscheiden? Ist eine Ablehnungsbegründung verpflichtend? Wer darf eingereichte Anfragen ändern?

Der Geschäftsverantwortliche bestätigt die Entscheidungen für die erste Veröffentlichung: Prüfer werden durch eine freigegebene Rolle zugewiesen; Antragsteller dürfen eigene Einreichungen nicht prüfen; eine Ablehnung erfordert eine Begründung; und eingereichte Anfragen können zunächst nicht geändert werden. Diese Entscheidungen werden Inhalt der Spezifikation statt Ermessensannahmen des Coding-Agenten.

UX-Ausrichtung: Der Designer definiert die zentralen Nutzungspfade: Anfrage erstellen und einreichen; ihren Status einsehen; eine eingereichte Anfrage prüfen und entscheiden. Er nutzt freigegebene Interaktionsmuster und plant, die funktionierenden Abläufe später zu prüfen.

Technische Grundlage: Der Architekt bewertet freigegebene Plattform, Starter-Repositories, Bibliotheken, Komponenten und Berechtigungsmodell der Organisation. Er definiert Grenzen, Datenflüsse, Integrationen, Verantwortungstrennung und Repository-Struktur und koordiniert technisch durchgesetzte Agentenausführungsbeschränkungen mit den Umgebungsverantwortlichen. Projektspezifische Vorgaben sind über agent_instructions/ und eine minimale zentrale AGENTS.md verfügbar.

Spezifikationsarbeit: Der Product Engineer erstellt die folgende beispielhafte Funktionsspezifikation.

Kennung: SPEC-001
Titel: Interne Serviceanfrage einreichen und prüfen
Zweck: Einem Mitarbeiter ermöglichen, eine Serviceanfrage einzureichen und eine nachvollziehbare Entscheidung eines autorisierten Prüfers zu erhalten.

Akteure: Antragsteller; Prüfer.

Verhalten:

1. Ein Antragsteller darf eine Anfrage im Zustand Entwurf mit Titel, Kategorie und Beschreibung erstellen.
2. Eine Anfrage darf nur von Entwurf zu Eingereicht wechseln, wenn alle drei Felder vorhanden und gemäß vereinbarten Feldregeln gültig sind.
3. Der Antragsteller kann den aktuellen Status selbst erstellter Anfragen einsehen.
4. Ein Prüfer darf eingereichte Anfragen seines zugewiesenen Prüfbereichs einsehen.
5. Ein autorisierter Prüfer darf eine eingereichte Anfrage genehmigen; Prüferidentität und Entscheidungszeitpunkt werden erfasst.
6. Ein autorisierter Prüfer darf eine eingereichte Anfrage erst nach Angabe einer nicht leeren Ablehnungsbegründung ablehnen; das Ergebnis erfasst Prüfer und Entscheidungszeitpunkt.
7. Antragsteller dürfen eigene Einreichungen nicht genehmigen oder ablehnen, auch wenn sie ansonsten Prüfberechtigungen besitzen.
8. Sobald eine Anfrage eingereicht ist, kann sie in der ersten Veröffentlichung nicht mehr bearbeitet werden.
9. Ein Antragsteller kann Entscheidung und gegebenenfalls Ablehnungsbegründung seiner eigenen Anfrage einsehen.

Akzeptanzbedingungen:

• AC-01 Ein Entwurf kann ohne Titel, Kategorie oder Beschreibung nicht eingereicht werden.
• AC-02 Erfolgreiches Einreichen setzt die Anfrage auf Eingereicht und macht ihren Status für den Antragsteller sichtbar.
• AC-03 Nur ein autorisierter Prüfer darf eine zugewiesene eingereichte Anfrage genehmigen oder ablehnen.
• AC-04 Ein Prüfer darf seine eigene Anfrage weder genehmigen noch ablehnen.
• AC-05 Ablehnen ohne Begründung wird verhindert; eine gültige Ablehnung erfasst Begründung, Prüfer und Entscheidungszeitpunkt.
• AC-06 Eine eingereichte Anfrage kann nicht bearbeitet werden.
• AC-07 Ein Antragsteller darf die Entscheidung seiner eigenen Anfrage sehen, aber ohne gesonderte Autorisierung keine privaten Details anderer Antragsteller.

Abhängigkeiten und offene Fragen: Die Prüferzuweisung wird durch das Zugriffsmodell der Organisation definiert. Jede Benachrichtigung über das Anzeigen des Anfragestatus hinaus liegt außerhalb der ersten Veröffentlichung.

Dieser Auszug legt beobachtbares Verhalten fest; ein reales Projekt muss zusätzlich notwendige Feldbeschränkungen, Datenverarbeitungsrichtlinien und Integrationen im Rahmen seiner freigegebenen Architektur definieren.

Während der parallelen Grundlagenarbeit prüft der Architekt die entstehenden Anforderungen auf folgenreiche technische Auswirkungen, wählt freigegebene Unternehmensbausteine, klärt Systemgrenzen und stimmt geeignete Ausführungsberechtigungen mit den zuständigen Verantwortlichen ab. Der Product Engineer pflegt die ersten Funktionsspezifikationen und stellt sicher, dass der Coding-Agent Projektanweisungen findet. Der UX-Designer legt die wesentliche Interaktionsrichtung fest.

Diese Aktivitäten schaffen ausreichend gemeinsamen Kontext und technische Vorbereitung für sinnvolle Implementierung. Wesentliche Ausnahmen folgen bestehenden Unternehmensrichtlinien. Das SHAPE Framework verlangt kein zusätzliches formales Architecture Readiness Review vor Phase 3; die beiden geplanten Prüfungen implementierter Software durch den Architekten finden in Phase 4 und 7 statt.

Der Product Engineer bittet den Coding-Agenten, SPEC-001 mit den freigegebenen Projektanweisungen, Bibliotheken und Mustern zu implementieren. Er erprobt repräsentative Entwurfserstellung, Einreichung sowie normale Genehmigungs- und Ablehnungsabläufe, bestätigt den funktionierenden Kernablauf und identifiziert gewöhnliche Korrekturen für den Agenten.

Die erste Implementierung erscheint für die Architektenprüfung bereit, doch der Product Engineer hat die Ablehnung mit leerem Grund nicht erprobt. Dieser Negativpfad bleibt fehlerhaft: Die Anwendung erlaubt weiterhin die Ablehnung ohne Begründung und verletzt damit AC-05. Das Versäumnis gilt weder als akzeptables Verhalten noch als Anlass, die Spezifikation anzupassen.

Der Architekt prüft die Implementierung vor umfangreicher Stakeholder-Prüfung. Er erkennt ein wesentliches Problem: Die Prüfberechtigung wird nur in der Benutzeroberfläche geprüft. Dies reicht nicht aus, weil das Verbergen eines Bedienelements keine Berechtigungen für die zugrunde liegende Aktion durchsetzt. Der Product Engineer steuert die Korrektur mit dem freigegebenen Autorisierungsansatz des Unternehmens. Der Architekt bestätigt den Schutz der relevanten Aktion, bevor die Kundenprüfung fortgesetzt wird.

Antragsteller und Prüfer erproben die Hauptabläufe. Ein Prüfer wünscht einen Kommentar bei Genehmigung. Der Geschäftsverantwortliche entscheidet, dass Genehmigungskommentare nützlich, aber optional sind. Der Product Engineer aktualisiert SPEC-001 und die Akzeptanzbedingungen und lässt den Coding-Agenten die vereinbarte Änderung implementieren. Die aktualisierte Spezifikation wird zum dauerhaften Nachweis, nicht allein die Diskussion bei der Demonstration.

Ein gesonderter Verifikationsagent oder -kontext liest die aktuelle eingecheckte Spezifikation einschließlich der während der Stakeholder-Prüfung ergänzten oder verfeinerten Akzeptanzbedingungen. Er leitet unabhängig repräsentative Positiv- und Negativprüfungen ab und erprobt das verfügbare Anwendungsverhalten. Da die Tests auf der Spezifikation statt früheren Entscheidungen des Implementierungsagenten beruhen, prüft der Verifikationskontext den bei den ersten Prüfungen des Product Engineers übersehenen Fall einer Ablehnung mit leerem Grund.

Das Ergebnis enthält folgende beispielhafte Befunde:

Der Product Engineer weist den Fehler bei AC-05 dem Implementierungsagenten zu, bestätigt die unveränderte Anforderung und veranlasst eine Korrektur. Der unabhängige Verifikationskontext wiederholt die Prüfung mit leerem Grund und bestätigt, dass Ablehnung ohne Grund nun verhindert wird, während gültige Ablehnung weiterhin gelingt und die erwarteten Details erfasst.

Die blockierte Datenschutzprüfung AC-07 zählt nicht als bestanden. Vor einer Meldung abgeschlossener Verifikation stellt das Team entweder geeignete Testidentitäten bereit und wiederholt die Prüfung oder dokumentiert ausdrücklich eine offene Einschränkung zur Behandlung gemäß Abnahme- und Risikorichtlinien der Organisation. Das Beispiel darf nicht behaupten, alle Prüfungen seien bestanden, solange eine blockiert bleibt.

Der Architekt prüft die überarbeitete Implementierung, bestätigt die Behebung des Autorisierungsbefunds aus Phase 4, berücksichtigt den unabhängigen Verifikationsbericht und bewertet technische Folgen des neuen optionalen Genehmigungskommentars. Er dokumentiert die technische UAT-Bereitschaft vorbehaltlich der üblichen Richtlinien der Organisation.

Die Prüfung berücksichtigt auch den korrigierten und unabhängig nachgeprüften Befund zum Ablehnungsgrund aus AC-05. Der UAT-Bericht unterscheidet behobene Fehler von etwaigen offenen Einschränkungen der Datenschutzprüfung AC-07.

Fachliche Stakeholder testen Einreichungs- und Prüfabläufe und treffen die Abnahmeentscheidung nach dem üblichen UAT-Verfahren der Organisation. Neue Fehler oder vereinbarte Änderungen gehen zurück in die Spezifikations- und Implementierungsschleife. Dieses Beispiel endet beim UAT; Release- und Betriebsprozesse des Unternehmens werden durch den SHAPE-Entwicklungszyklus nicht abgedeckt.

Nach Inbetriebnahme wünschen Stakeholder, dass Antragsteller eine eingereichte Anfrage zurückziehen können, bevor ein Prüfer entscheidet. Der Product Engineer ergänzt den Spezifikationsbestand um folgendes vereinbarte Verhalten:

Änderung: Ein Antragsteller darf seine eigene eingereichte Anfrage zurückziehen. Das Zurückziehen setzt den Zustand auf Zurückgezogen, erfasst Person und Zeitpunkt und verhindert spätere Genehmigung oder Ablehnung. Prüfer dürfen nicht stellvertretend für Antragsteller zurückziehen, sofern keine gesonderte ausdrückliche Autorisierungsentscheidung getroffen wird.

Der Agent implementiert die Erweiterung innerhalb bestehender Projektstandards. Unabhängige Tests prüfen autorisiertes Zurückziehen, Verweigerung für andere Benutzer und Abweisung einer verspäteten Prüfentscheidung zu einer zurückgezogenen Anfrage. Der Architekt prüft die Änderung, wenn ihre Sicherheits- und Ablaufauswirkungen die Schwellenwerte der Organisation erreichen. Anschließend führen fachliche Stakeholder den UAT durch. Der Product Engineer behält die Verantwortung für Funktion und zugehörige Spezifikationen.

Das Projekt veranschaulicht die SHAPE-Unterscheidung zwischen gesprächsbasierter Discovery und gepflegten Spezifikationen; zwischen funktionierender Oberfläche und durchgesetzten Berechtigungen; zwischen Implementierung durch den Coding-Agenten und unabhängiger Verifikation; zwischen Architektenfreigabe und fachlicher Abnahme; und zwischen erstem Produktzyklus und späterer Erweiterungsarbeit.

Es zeigt außerdem, warum dauerhafte Spezifikationen nach der Veröffentlichung wichtig sind: Die Erweiterung zum Zurückziehen muss bereits im ursprünglichen Produkt festgelegtes Verhalten und Zustandsübergänge berücksichtigen.