Discovery als zusammenhängenden Dokumentensatz prüfen

Verfolgen Sie eine Anforderung durch den Dokumentensatz

Dieses Szenario setzt den fiktiven Dienst für Ausstattungsanfragen fort. Die erste Spezifikation erlaubt Führungskräften, Anfragen einzugeben. Das Team ergänzt anschließend die Selbstbedienung durch Mitarbeiter.

Diese Änderung betrifft mehr als einen Bildschirm. Mitarbeiter brauchen eine Identität und Zugriff auf ihre eigenen Anfragen. Die Sichtbarkeit für Führungskräfte braucht eine definierte Grenze. Datenfluss und Sicherheitsanalyse müssen beide Rollen abbilden.

Nutzen Sie die Discovery-Schritte Context, Conversation und Documents, um diese Zielbeschreibung festzulegen und zu prüfen. Bei einem importierten Produkt ersetzt die Repository-Analyse das Gespräch. Folgen Sie dafür dem eigenen Importworkflow.

Kennen Sie die erforderlichen Dokumente

Einschließlich der Spezifikation sind acht Dokumente erforderlich:

Die Generierung folgt Abhängigkeiten und Veröffentlichungsreihenfolge. Prüfen Sie ein frühes Dokument, bevor Sie seine Annahmen für spätere Dokumente übernehmen. Eine generierte DPIA ist Bewertungsmaterial. Ihr Vorhandensein allein belegt keine rechtliche Compliance.

Look & Feel und Service Blueprint sind optional. Nutzen Sie sie, wenn eine visualisierte Gestaltungsrichtung oder eine Dienstbeschreibung dem Team bei der Produktbewertung hilft.

Unterscheiden Sie Veröffentlichung und Prüfung

Die Spezifikation beginnt als Entwurf. Nachgelagerte Generierung nutzt die veröffentlichte Version. Bearbeitung erzeugt einen neuen Entwurf. Die Änderungen wirken nachgelagert, wenn Sie die neue Version veröffentlichen.

Andere Dokumente tragen Veröffentlichungs- und Prüfinformationen. Generate remaining kann den fehlenden Satz nacheinander generieren. Jedes Ergebnis braucht eine Prüfung. Der Abschluss der Generierung ist keine menschliche Feststellung, dass die Annahmen richtig sind.

Prüfen Sie beim Ausstattungsdienst die Zugriffsregel in allen relevanten Dokumenten. Eine richtige Spezifikation und ein veralteter Datenfluss ergeben keinen konsistenten Entwurf.

Bearbeiten Sie Änderungen bewusst

Wenn Sie die Spezifikation erneut veröffentlichen, können abhängige generierte Dokumente den Status Outdated erhalten. Taiga schreibt sie nicht stillschweigend um. Auch eine Änderung an einem anderen Quelldokument kann spätere Dokumente in der Kette betreffen.

Generieren Sie betroffene Dokumente neu, solange Discovery geöffnet ist. Generate remaining schließt veraltete Dokumente ein. Prüfen Sie die neuen Ergebnisse, insbesondere Annahmen, die sich in mehreren Dokumenten geändert haben.

Alle acht erforderlichen Dokumente müssen veröffentlicht sein, bevor Finish Discovery verfügbar wird. Ein Dokument mit dem Status Outdated verhindert den Abschluss nicht. Prüfen Sie die Konsistenz selbst. Die Schaltfläche belegt nicht den Abschluss aller Prüfungen.

Der Abschluss sperrt den Satz und öffnet den nachgelagerten Produktworkflow. Öffnen Sie Discovery aus einem Dokument erneut, wenn Sie einen gesperrten Satz ändern müssen.

Übergeben Sie eine schlüssige Zielbeschreibung an die Planung

Benennen Sie vor der Planung die aktuellen Nutzerrollen, akzeptierten Grenzen und offenen Entscheidungen. Prüfen Sie, ob die Initiative-Vorschläge Dokumente zitieren, die dasselbe Produkt beschreiben.

Ein nützliches Prüfergebnis ist konkret: „Die Selbstbedienung durch Mitarbeiter ist in Abläufen, Autorisierungsentwurf, Datenfluss und Bedrohungsbehandlung berücksichtigt.“ Fahren Sie mit Initiatives fort, um diese Zielbeschreibung in Arbeit umzusetzen.