Examiner Discovery comme un ensemble de documents liés

Suivre une exigence dans l’ensemble

Ce scénario poursuit le service fictif de demandes d’équipement. La première spécification permet aux managers de saisir les demandes. L’équipe ajoute ensuite le libre-service salarié.

Ce changement touche plus qu’un écran. Les salariés ont besoin d’une identité et d’un accès à leurs propres demandes. La visibilité des managers nécessite une limite définie. Les flux de données et l’analyse de sécurité doivent refléter les deux rôles.

Utilisez les étapes Context, Conversation et Documents de Discovery pour établir et examiner cette intention. Pour un produit importé, l’analyse du dépôt remplace la conversation ; suivez le parcours d’import distinct.

Connaître les documents requis

Huit documents sont requis, spécification comprise :

La génération suit les dépendances et l’ordre de publication. Examinez un document amont avant d’accepter les hypothèses utilisées par les suivants. Une DPIA générée fournit des éléments d’évaluation ; sa présence n’établit pas à elle seule la conformité juridique.

Look & Feel et Service Blueprint sont facultatifs. Utilisez-les lorsqu’une proposition visuelle d’interface ou une description du service aide l’équipe à évaluer le produit.

Distinguer publication et revue

La spécification commence comme brouillon. La génération en aval utilise la version publiée. Une modification crée un nouveau brouillon ; elle prend effet en aval lorsque vous publiez la nouvelle version.

Les autres documents portent des informations de publication et de revue. Generate remaining peut générer séquentiellement les documents manquants, chaque résultat nécessitant une revue. La fin de la génération n’est pas une conclusion humaine sur l’exactitude des hypothèses.

Pour le service d’équipement, examinez la règle d’accès dans tous les documents pertinents. Une spécification correcte et un flux de données obsolète ne forment pas une conception cohérente.

Traiter les changements délibérément

Lorsque vous republiez la spécification, les documents générés dépendants peuvent devenir Outdated. Taiga ne les réécrit pas silencieusement. Modifier un autre document source peut aussi toucher ceux situés plus loin dans la chaîne.

Régénérez les documents touchés pendant que Discovery est ouvert. Generate remaining inclut les documents obsolètes. Examinez les nouveaux résultats, surtout les hypothèses qui changent dans plusieurs documents.

Les huit documents requis doivent être publiés avant que Finish Discovery soit disponible. Un document Outdated n’empêche pas de terminer. Vérifiez vous-même la cohérence au lieu de traiter le bouton comme une preuve que toutes les revues sont terminées.

Terminer verrouille l’ensemble et ouvre le parcours produit suivant. Rouvrez Discovery depuis un document lorsque vous devez modifier un ensemble verrouillé.

Transmettre une intention cohérente à la planification

Avant la planification, indiquez les rôles utilisateurs actuels, les contraintes acceptées et les décisions non résolues. Vérifiez que les propositions d’initiatives citent des documents décrivant le même produit.

Un résultat de revue utile est concret : « Le libre-service salarié est reflété dans les parcours, la conception des autorisations, les flux de données et le traitement des menaces. » Poursuivez avec les initiatives pour transformer cette intention en travail.