如何用 AI 建立需求追溯矩陣？先凍結基準再做雙向追溯

要用 AI 建立需求追溯矩陣，先凍結已批准的需求基準，分配唯一 ID，並訂明矩陣容許哪些關係。只有 AI 能引述支持文字並指明出處時，才讓它提出候選關係；再由需求、設計、實作、測試、安全和合規負責人確認每項關係和結果。

需求追溯矩陣（RTM）是證據基礎設施，不是項目完結時一次產生的表格。它應支援正向追溯（由每項獲批需求追到設計、實作、驗證和證據）和反向追溯（由實作和測試追回獲授權的需求）。AI 能減少文書工作，但不得虛構需求、對應關係、測試結果、豁免或合規結論。

進度和依賴另用一份項目計劃管理。較全面的 AI 使用總指南說明如何限制模型權限，人工審批工作流程則可把批准綁定到有版本的矩陣匯出檔。

關鍵要點：

• 由已批准、有唯一識別碼、有版本的需求開始。
• 每項關係都要清晰，並有引述的證據支持。
• 把 AI 輸出視為候選對應，絕不當作已接納的事實。
• 同時追溯正向涵蓋和反向授權。
• 區分計劃中的驗證與已執行、已覆核的證據。
• 需求或下游產物改變時，隨時維護矩陣。

步驟 1：凍結基準和唯一 ID

確定權威來源：獲批規格、合約、政策、架構決定、規管詮釋或受控待辦清單。記錄基準版本、批准機構、日期、範圍和變更控制流程。保存唯讀副本，方便日後覆核區分「需求改了」和「對應改了」。

為每項需求分配唯一、固定的 ID，不要用排序後會改變的列號。記錄確切文字、出處位置、理由、負責人、已批准的優先次序或關鍵程度，以及目前的生命周期狀態。

NASA 的需求管理指引描述了在整個生命周期建立、控制、驗證、確認和追溯需求。［1］ 這個角度很重要：RTM 必須反映受控的變更，而非最新收集的一堆句子。

把需求與背景說明、目標、設計構思、假設和示例分開。AI 可指出某句看似需求，但只有獲授權的需求流程能接納它。未獲批准的候選放進收件隊列，不要悄悄分配需求 ID。

步驟 2：檢查原子性與可驗證性

對應之前，檢查每項需求是否只含一項有界的責任，主體明確、條件清楚、結果可驗證。以多個「並且」連接的複合陳述，可能需要經批准的拆分。保留父子關係和原文；不要讓 AI 改寫合約或受規管字句，好像改寫版才是權威。

提出以下問題：

• 執行者或系統界線是否清楚？
• 所要求的行為或質素是否可觀察？
• 觸發條件和例外是否已界定？
• 單位、門檻和容差是否毫不含糊？
• 是否有驗證方法可判定通過或失敗？
• 是否與另一項已批准需求衝突或重複？

NASA 的需求確認指引著重在下游依賴之前，確保需求格式恰當、清晰、完整、一致、可行並可驗證。［3］ 記錄缺陷後交需求負責人，不要只在矩陣內修補。

步驟 3：定義欄位和狀態

提取之前先選定欄位。一個有用的範本是：

需求 ID	來源	需求文字	理由	負責人	狀態	設計	實作	測試/證據	結果	版本
REQ-001	SPEC-3.2	準確獲批原文	獲批理由	產品負責人	已納入基準	DES-014	MOD-07	TP-031 / EV-031	已覆核通過	2.1

示例只說明格式。界定容許的數值，例如 candidate、reviewed、approved、implemented、verified、deferred 和 retired，並寫明誰可設定每個數值。避免籠統的「完成」：一項需求可能已實作但未驗證，或已測試但未通過。

以固定的產物 ID 加版本表示連結，而非非正式描述。設計文件或測試改變時，矩陣應能看出之前的覆核是否仍然適用。寫明確切的證據位置（章節、測試個案、結果記錄或受控 URL），讓其他覆核人能夠打開。

步驟 4：用 AI 建立需求追溯矩陣時只提取候選關係

只提供已批准或清楚標示的產物、詞彙表、欄位結構和關係規則。把大型來源集拆成可覆核的批次，同時保留產物 ID 和版本元數據。

一個受控的提示詞是：

為每項已批准需求提出與所提供產物之間的候選關係。交回需求 ID、目標產物 ID 和版本、關係類型、附位置的確切支持引文，以及簡短理由。只使用所提供的文字。如果支持含糊或欠缺，交回 UNRESOLVED。不要建立需求 ID、產物、測試結果、狀態、豁免或合規主張。

要求模型為擬議連結兩端都提供引文。只靠關鍵字重疊不足夠：提及「timeout」的測試未必驗證了所要求的逾時行為。由覆核人檢查目標是否真正實現或驗證了該項責任及其條件。

按獲批工具、存取、保留和資料存放位置的規定，保護敏感規格和保安設計。盡量減少提供的材料。NIST 的生成式 AI 風險概況指出虛構、私隱、資訊保安和資訊完整性等需要管治和人工監督的風險。［4］

步驟 5：處理含糊、重複和孤立項目

分小批覆核候選對應。每條連結選擇接納、拒絕、需澄清或需負責人處理，並記錄覆核人、日期、理由和矩陣版本。絕不把模型的信心分數當作批准。

特別留意：

• 沒有設計、實作、測試或證據的需求；
• 一項測試連結多項需求，卻未證明每個條件；
• ID 不同的重複需求；
• 互相衝突的需求或版本；
• 超出或違反已批准範圍的實作；
• 測試了沒有任何需求授權的行為；
• 只基於相似字眼的連結；
• 由計劃照抄、而非來自執行記錄的結果。

孤立項目是覆核訊號，並不自動證明失敗。新納入基準的需求或正等待設計；相反，沒有對應需求的實作，可能是必要的基礎設施、缺陷修正、未成文的需求或未經授權的範圍。交由負責人處理。

矩陣引用外部標準或主張時，使用事實核查流程的控制方法。AI 對標準的撮要，不能取代已批准的詮釋。

步驟 6：建立正向追溯

正向追溯要問：每項已批准需求是否都有合適的下游實現和驗證。沿着這條鏈：

1. 需求到架構或設計決定；
2. 設計到實作組件或設定；
3. 需求到驗證方法和測試程序；
4. 程序到執行記錄和證據；
5. 證據到已覆核的結果和處置。

別忽略「程序」與「結果」的分別。測試個案 ID 只證明測試已計劃；「通過」需要一份對應正確版本和環境的執行結果，並按項目流程覆核。

檢查、分析、示範或認證等非測試驗證，要清楚記錄方法和證據。連結到資料夾通常太籠統，應指明能證明該需求的產物和章節。

NASA 的雙向追溯指引強調，要把軟件測試程序追溯到需求，也要把需求追溯到測試程序，並在整個生命周期維護這些關係。［2］ 具體產物因項目而異，但兩個方向都應可覆核。

步驟 7：執行反向追溯

由設計、已實作組件、設定、測試程序和證據出發，逐一追問：哪項已批准需求授權或要求了這項產物？這能揭示鍍金功能、過時測試、未成文的行為和意外的範圍擴張。

AI 可以把未連結的產物分組並建議可能的負責人，但不得為了替它們找理由而建立需求。把每項歸類為：

• 已連結並確認；
• 有文件理由的共用基礎設施；
• 連繫到已批准問題或需求的缺陷修正；
• 等待批准的候選新需求；
• 已過時或超出範圍；
• 未解決。

請架構和實作負責人覆核反向追溯，因需求作者未必了解每項下游產物。安全攸關、資訊保安、受規管或受合約約束的工作，使用項目批准的追溯工具和相關範疇的覆核流程；本教學不能取代它們。

步驟 8：在變更時維護矩陣

為每項需求以及作為受控產物的矩陣本身指派負責人。界定覆核觸發條件：基準變更、設計修訂、程式碼改動、測試改動、測試失敗、豁免、發布候選或審計要求。

發生改變時：

1. 記錄變更要求和批准；
2. 建立產物的新版本；
3. 找出受影響的關係；
4. 酌情把之前的覆核標為需重新評估；
5. 重新執行正向和反向檢查；
6. 收集新證據；
7. 批准並匯出一份註明日期的矩陣快照。

自動化工具能標出過時連結、欠缺欄位、重複 ID 或無效狀態，但不能判定改變後的證據仍然足夠；這個決定由具名覆核人作出。

把維護流程整理成 SOP 與清單，包括存取控制、備份、覆核頻率和匯出格式。避免出現與受控矩陣逐漸分歧的私人副本。

除檢查完整性外，還要人手抽查：揀選幾項高關鍵度需求、幾項看似簡單的需求和幾項最近改動的產物，不依賴矩陣建立者重建每條鏈。抽查能揭示看似精確卻指向錯誤版本的連結，或未測試所需條件的證據。把樣本、覆核人、發現和糾正行動隨矩陣版本記錄。

批准檢查清單

在發布或正式評審前，確認：

• 已標明基準及所含版本；
• 所有需求 ID 唯一並已獲批准；
• 每條已接納的連結都有目標 ID 和覆核證據；
• 所有需求都有適當的正向處置；
• 反向追溯沒有發現無法解釋的實作或測試範圍；
• 計劃中的測試沒有被寫成已通過的結果；
• 失敗、延後、豁免和未解決的項目仍然可見；
• 敏感產物受到保護；
• 專家覆核人已批准必需的安全或合規詮釋；
• 匯出檔和批准記錄指向同一個矩陣版本。

常見問題

甚麼是需求追溯矩陣？

它是已批准需求與相關設計、實作、驗證、證據、結果、負責人和版本之間的受控對應。

AI 可以編寫需求嗎？

它可找出看似需求的候選文字，但只有獲授權的流程才能建立或批准需求。候選應放在已接納的基準以外。

甚麼是雙向追溯？

正向追溯檢查需求是否已被實現和驗證；反向追溯檢查設計、實作和測試是否有已批准需求或有記錄的理由支持。

一項測試可覆蓋多項需求嗎？

可以，前提是覆核人確認該程序和證據驗證了每個相關條件；別憑共同用詞推斷涵蓋。

連結測試計劃便足夠嗎？

不足夠。計劃只表示打算驗證，還要另行記錄執行結果、環境和版本、證據位置及已覆核的處置。

多久更新一次 RTM？

需求或相關產物改變時，以及在指定評審關口更新。只在審計前更新的追溯很可能已過時。

孤立需求怎樣處理？

指派負責人並訂定處置：需設計、需測試、延後、廢止、重複、無效或未解決。不要隱藏它，也不要讓 AI 虛構連結。

RTM 能證明監管合規嗎？

不能單獨證明。它能整理已批准的責任和證據，但是否合規由合資格專家和適用的保證流程判定。

來源

1. NASA, Requirements Management — https://www.nasa.gov/reference/6-2-requirements-management/
2. NASA Software Engineering Handbook, Bidirectional Traceability Between Software Test Procedures and Software Requirements — https://swehb.nasa.gov/spaces/7150/pages/16449898/SWE-072%2B-%2BBidirectional%2BTraceability%2BBetween%2BSoftware%2BTest%2BProcedures%2Band%2BSoftware%2BRequirements
3. NASA Software Engineering Handbook, Requirements Validation — https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695440/SWE-055%2B-%2BRequirements%2BValidation
4. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 8 月 29 日。

延伸閱讀

• 把現場檢查問題連繫至證據及要求
• 把已確認需求整理成網站結構