將 Discovery 視為互相關聯的文件組來審查

追蹤一項需求如何貫穿文件組

本情境延續虛構設備申請服務。第一版規格允許管理者輸入申請，團隊之後加入員工自助服務。

這項變更不只影響畫面。員工需要身分，以及存取自己申請的權限。管理者可見範圍需要明確邊界。資料流與安全分析必須反映兩種角色。

使用 Discovery 的 Context、Conversation 和 Documents 步驟，建立並檢查產品意圖。匯入產品則以儲存庫分析取代對話；請依獨立的匯入流程操作。

包含規格在內，共有八份必要文件：

生成依相依關係與發布順序進行。接受後續文件使用的假設前，先審查較早文件。生成的 DPIA 是評估材料；文件存在本身，不能證明符合法律。

Look & Feel 與 Service Blueprint 為選用文件。介面設計方案的渲染結果或服務說明，有助於團隊評估產品時，可以使用。

規格最初是草稿，後續生成使用已發布版本。編輯會建立新草稿；發布新版後，變更才對下游生效。

其他文件含有發布與審查資訊。Generate remaining 可以依序生成缺少的文件組，但每份結果仍需審查。生成完成，不代表人員已判斷假設正確。

針對設備服務，在所有相關文件檢查存取規則。正確規格加上過期資料流，不是一致設計。

重新發布規格時，相依的生成文件可能變成 Outdated。Taiga 不會悄悄改寫它們。其他來源文件變更，也可能影響相依鏈中更後面的文件。

在 Discovery 開放期間，重新生成受影響文件。Generate remaining 也會包含過期文件。檢查新結果，尤其是跨多份文件改變的假設。

八份必要文件都必須發布，Finish Discovery 才可使用。Outdated 文件不會阻止完成。自行檢查一致性，不要把按鈕視為所有審查已完成的證據。

完成後會鎖定文件組，並開放後續產品流程。需要變更已鎖定文件組時，可從文件重新開啟 Discovery。

規劃前，說明目前使用者角色、已接受限制和未決事項。檢查 initiative 提案引用的文件，是否描述同一個產品。

有用的審查結果很具體：「員工自助服務已反映在流程、授權設計、資料流與威脅處理中。」繼續閱讀initiatives，將意圖轉成工作。