Discoveryをつながった文書群としてレビューする

文書群を通して一つの要件を追う

このシナリオは、架空の備品申請サービスの続きです。最初の仕様では、マネージャーが申請を入力します。その後、チームは従業員自身による申請を追加します。

この変更は、一つの画面以上に影響します。従業員には、IDと自分の申請へのアクセスが必要です。マネージャーが閲覧できる範囲にも、明確な境界が必要です。データフローとセキュリティ分析は、両方の役割を反映する必要があります。

DiscoveryのContext、Conversation、Documentsの段階を使って、その意図を定め、確認します。インポートしたproductでは、会話をリポジトリ分析に置き換えます。別のインポートのワークフローに従ってください。

必須文書を把握する

仕様を含めて、必須文書は八つあります。

生成は、依存関係と公開の順序に従います。後の文書が使う前提条件を受け入れる前に、前段の文書をレビューします。生成されたDPIAは評価資料です。存在するだけで、法令への適合が成立するわけではありません。

Look & FeelとService Blueprintは任意です。画面として示したインターフェースの方向性や、サービスの説明が、チームによるproductの評価に役立つ場合に使います。

公開とレビューを区別する

仕様は、下書きとして始まります。後続の生成は、公開済みの版を使います。編集すると、新しい下書きができます。変更が後続に反映されるのは、新しい版を公開したときです。

他の文書には、公開とレビューの情報があります。Generate remainingは、不足する文書群を順に生成でき、それぞれの結果にレビューが必要です。生成の完了は、前提が正しいと人が判断したことを意味しません。

備品サービスでは、関連するすべての文書でアクセスルールを確認します。正しい仕様と古いデータフローの組み合わせは、整合した設計ではありません。

変更を意図して扱う

仕様を再公開すると、依存する生成文書がOutdatedになる場合があります。Taigaは、それらを黙って書き換えません。他の参照元文書への変更も、さらに後続の文書に影響する場合があります。

Discoveryが開いている間に、影響を受けた文書を再生成します。Generate remainingは、古くなった文書も対象に含めます。新しい結果を確認し、特に複数の文書にまたがって変わった前提条件を調べます。

Finish Discoveryを利用できるようにするには、必須の八つの文書をすべて公開する必要があります。Outdatedの文書があっても、完了は妨げられません。ボタンをすべてのレビューが済んだ証拠とみなさず、自分で整合性を確認してください。

完了すると文書群がロックされ、後続のproductワークフローが開きます。ロックされた文書群を変える必要がある場合は、文書からDiscoveryを再び開きます。

整合した意図を計画に渡す

計画の前に、現在のユーザーの役割、受け入れた制約、未解決の判断を示します。Initiativeの提案が、同じproductを説明する文書を参照していることを確認します。

有用なレビュー結果は具体的です。例えば、「従業員自身による申請が、フロー、認可設計、データフロー、脅威への対処に反映されている」と示します。続いて、initiativeで、その意図を作業に変えてください。