軟體改變時，仍能追溯需求

描述可以驗證的行為

「建立現代化客戶資料匯出」留下許多未決事項。它沒有定義使用者、紀錄、欄位或失敗行為。代理程式只能提問或做假設，未記錄的假設則很難在之後審查。

使用邊界明確的虛構需求：已通過身分驗證的管理者，可以匯出自己組織的有效客戶資料。匯出內容包括客戶 ID 和顯示名稱，不包含聯絡資料與已封存紀錄。沒有管理者角色的使用者，不得取得匯出檔案。

這仍需要決定格式、資料量、回應時間和失敗處理方式。明確標示未知事項。有用的規格會揭露不確定性，不會用充滿自信的文字掩蓋它。

使用者需要以可用格式取得一組有權存取的紀錄。資料庫查詢、函式庫和端點結構，則是實作選擇。將它們連結到需求，但不要把每項現行選擇都當成永久業務需求。

記錄後果重大的決定，包括背景、替代方案和理由。例如，小量資料可能適合同步匯出；資料量增加後，可能需要背景工作與獨立的下載授權檢查。

盡可能保持需求穩定，同時為變更的決定保留版本。這能協助審查者區分：只是改了實作，還是對使用者的承諾也改了。

使用審查時仍容易理解的識別碼。在這個範例中，EXPORT-01 可以代表組織邊界。這只是示範名稱，並非必要的編號制度。

證據鏈必須指向真實證據。測試名稱含有需求 ID，不代表斷言真的驗證了該需求。檢查測試本身，以及它所執行的正式環境程式碼路徑。

NIST 的 SSDF 說明安全開發中的需求與驗證背景。運用可追溯性，讓這些活動可以接受檢查，不要只為產生文件而做。閱讀框架。

假設業務現在也需要已封存客戶。這項變更不只影響查詢旗標。檢查保留規則、授權、預期資料量、對使用者的說明，以及現有報表的意義。

將受影響文件與檢查標為待審查。保留先前決定，讓維運人員能解釋舊版本。不要悄悄改寫歷史，讓最新設計看起來像唯一必然的選擇。

代理程式可以協助找出引用並提出更新。負責人必須解決衝突需求，並接受變更後的行為。列出相符檔案只是起點，不是完整影響評估。

記錄影響實作、驗證和維運的決定。避免在許多互不相連的文件中重複同一需求，優先連結到一個持續維護的來源。

接受變更前，確認審查者能否從目的追到實際證據。開始維運前，確認服務負責人能否找到相關邊界與復原決定。這些是檢驗可追溯性是否有用的實際方法。