# 產品常設要求與限制條件

軟體產品有不少要求會延續多個交付作業。例如，多語言使用者介面新增畫面後，仍須沿用產品既有的本地化設計；新增儲存或處理路徑時，資料管轄地規則仍然適用。無障礙、相容性、合約承諾、安全控制、可靠性要求和組織內部政策，也可能在多年交付期間持續約束彼此無關的變更。真正的問題在於，若每次交付都重新理解這些產品層級要求，一項作業可能從舊規格複製文字，另一項依賴團隊記憶，AI 程式開發代理則可能直接讀取上游政策或法規並自行解讀。久而久之，同一項義務便可能出現數個看似合理的版本，原本應跨作業維持一致的專業判斷反而失去穩定性。

近期需求工程研究清楚呈現了這個問題的上游部分。Nair 與 Anish 開發 Reg2Req，從法規文字辨識包含要求的條文，產生不依賴特定系統的軟體要求，並以白話說明內容且保留回到原始法律來源的追溯關係。他們以 398 條《一般資料保護規則》（GDPR）條文和 574 條《歐盟人工智慧法案》（EU AI Act）條文評估這套流程；人工評估對所產生要求的完整性與說明清晰度給予高分。另有 25 位實務工作者參與使用者研究，所有人都表示會把這套工具作為從法規推導軟體要求的起點。[^citation-01]

Reg2Req 已把法規來源向可用的軟體要求推進一步，但不依賴特定系統的要求仍位於個別產品的上游。同一項法規、組織政策、合約條款、無障礙標準或資料管轄地規則，會因產品用途、處理的資料、營運地點、適用能力，以及組織已核准的專業解讀而形成不同的軟體義務。AI 可以協助找出與推導要求；最終仍由負責相關決策的專業角色，決定產品實際必須滿足什麼。

規格優先交付把這些可長期重用的產品層級判斷記錄為**產品常設要求**。這些要求跨多項適用交付作業持續具有權威，直到具相應決策權的角色明確修訂為止。每份產品常設要求規格可以包含一項或數項彼此相關的要求，讓後續交付作業直接知道哪些義務必須保留、符合、驗證，或在有充分決策依據時作出修改。

反覆出現的專業判斷一旦整理成可重用的交付知識，後續工作便能直接採用。產品、法務、合規、安全、私隱、可靠性、營運、架構、工程及其他具決策責任的職能，可以把長期有效的決定整理成規格，讓未來工作直接採用，而不用每次從來源文件、會議或個人記憶重新還原。交付作業規格是這些常設知識的使用者；若某次交付發現常設要求遺漏、過時或互相衝突，[知識收斂](/zh-tw/hub/knowledge-convergence-across-the-increment-lifecycle)會把新知送回適當的決策負責人，形成之後工作可依賴的產品知識。

本文說明如何建立、使用、管理和演進產品常設要求。後續文章會分別把這套一般模型套用到安全與私隱要求，以及可靠性與營運要求。不同組織還可以建立其他專項類別，例如法規、資料管轄地、合約、供應商、無障礙或組織特有要求。規格優先交付定義的是這些知識如何成為可使用、責任清楚的交付輸入；要求的實質內容仍由擁有相關專業責任的職能決定。

## 1. 產品常設要求及其交付角色

產品常設要求保存會跨不同交付工作持續適用的條件。本地化政策、介面相容性、無障礙要求、產品整體 AI 行為、資料管轄地限制或對客戶承諾的合約義務，都可能同時影響很多後續作業。若每份功能規格或技術規格都重新寫一次相同判斷，文字和脈絡容易逐步分歧，實作也可能在沒有明確決策的情況下形成另一套解讀。

要求重用本身已有長期研究基礎。Palomares、Quer 與 Franch 的實務調查發現，實務工作者最常見的做法，是從既有要求複製文字後再手動調整；較系統化的重用方式仍未普遍採用。[^citation-02] 另一篇系統性文獻回顧整理了 69 項要求重用研究，涵蓋如何組織、搜尋、調整和整合可重用要求。[^citation-03] 因此，既有研究已充分涵蓋要求重用；產品常設要求進一步處理的是交付治理問題：要求在產品層級保持一份權威版本，適用的交付作業直接採用，作業本身的規格則集中記錄這次變更新增或改變的行為、設計、風險、例外與驗收條件。

兩類規格與決策紀錄的生命週期各有不同：

1. **產品常設要求規格**

   保存產品整體義務，並說明適用條件。適用的交付作業會反覆使用這份規格；只有長期要求本身改變時才需要修訂。

2. **交付作業規格**

   定義一項具完整範圍的產品變更所涉及的行為、設計、實作責任或證據，只在目前交付作業需要時建立或修訂。

3. **決策紀錄**

   保存建立、修改或核准偏離某項要求時的重要理由與決策權限，讓後續變更仍可追溯當時的決策依據與脈絡。

產品常設要求既可以描述產品必須達成的結果，也可以限制可採用的解法。例如，「使用者可見內容必須支援本地化」描述產品必須具備的條件；「這項能力所處理的個人資料只能留在獲核准的處理地點」則限制解法可使用的資料處理位置。規格優先交付以同一套模型處理這兩類內容：說明適用條件、決策權限，以及相關要求如何進入交付工作。

同一項產品關切事項下的多項要求，可以收在一份產品常設要求規格中。例如，本地化規格可同時涵蓋使用者可見字串、支援語系、翻譯缺漏時的替代行為，以及日期、數值或貨幣等依語系與地區設定而定的格式。規格範圍應以同一產品關切事項和決策脈絡為單位，不必把每一句要求拆成獨立文件。

大型產品可能會因要求數量、工具整合、監管證據或依賴關係複雜而採用穩定識別碼，以改善可追溯性；這是組織可自行選擇的做法。小型產品可以只維護一份有清楚標題的簡短 Markdown 規格，不需要要求識別碼；大型組織則可以由要求管理平台配發穩定識別碼。框架要求的是適用知識容易找到並能實際使用，追溯機制的複雜程度應與交付需要相稱。

> **常設知識跨交付作業持續有效**
>
> 每項交付作業使用與其範圍相關的產品常設要求；作業規格只記錄這次新增、修改、例外，或實作與驗收真正需要補充的內容。

## 2. 從上游權威來源形成產品層級要求

產品常設要求可以來自不同層級的權威來源。產品團隊可以訂定整體本地化政策；企業技術職能可以提出組織層級限制；客戶合約可能形成產品義務；法務或合規則可解讀法規，決定某項能力需要符合哪些條件。產品層級規格的作用，是把這些輸入整理成足以供日常交付直接使用的具體要求。

法規要求尤其突顯這個精煉過程的重要性。Breaux 與 Antón 把私隱與安全法規分析為以複雜、偶爾含糊的法律文字表達的權利與義務，並提出從這些規則抽取和精煉軟體要求的方法，清楚把法規文字放在要求分析與產品規格之前。[^citation-04] 另一項 Cisco 無障礙要求的產業個案研究，則比較 Section 508 法律要求與支援該合規目標的產品要求，顯示從法律來源走到可參與產品設計與測試的要求，仍需加入產品知識並進一步精煉。[^citation-05]

同樣的結構不限於法律。組織政策可規定某類資料只能留在獲核准的司法管轄地；供應商合約可限制資料保存或再散布方式；無障礙標準需要依產品情況形成具體要求；可靠性政策也可能按照服務類別訂出復原要求。上游來源在自己的層級提供權威依據，產品必須滿足的具體條件則經結構化討論形成。

```mermaid
flowchart TD
  accTitle: 從上游權威來源形成產品層級常設要求
  accDescr: 外部或組織來源經專業結構化討論形成產品層級常設要求，並以決策紀錄保留決策依據，再透過管治知識帶入交付作業。

  A[外部或組織權威來源]
  B[專業結構化討論]
  C[決策紀錄]
  D[產品層級常設要求]
  E[管治指示與 Skills]
  F[交付作業的結構化討論]
  G[交付作業規格]
  H[實作與驗證]

  A --> B
  B --> C
  B --> D
  C -. 決策依據 .-> D
  D --> E
  E --> F
  F --> G
  G --> H
```

日常交付應先取得已形成的**產品層級解讀**。產品常設要求直接告訴工程師或 AI 程式開發代理產品必須滿足什麼；管治指示和 Skills 則按工作情境，把參與者帶到相關要求。結構化討論需要檢視決策形成原因時，再沿決策紀錄追查更完整的依據與脈絡。

上游文件仍應保持可查閱。能存取知識系統的 AI 程式開發代理，技術上可以讀取法規、政策、合約或企業標準；日常的上下文路由應優先帶入產品層級要求，只有討論真的需要重新檢視上游依據時才載入這些材料。這延續了[按需分層載入上下文](/zh-tw/hub/shared-knowledge-system)的做法：更完整的證據一直可找到，但一般執行者毋須在每次交付時重新進行已完成的專業解讀。

假設一項產品使用生成式 AI 控制部分使用者介面，並向歐盟客戶提供服務，團隊便需要判斷 EU AI Act 是否以及如何適用於這項能力。法務、合規、產品及其他負責相關決策的參與者透過[結構化討論](/zh-tw/hub/requirements-increments-and-structured-discussion)，決定哪些義務適用，以及組織會如何滿足。如果核准後的解讀要求保留特定證據、安排具名人員審查、提供特定文件或加入其他產品控制，產品層級常設要求便應直接寫出該義務和適用條件。合規決策紀錄則保留 EU AI Act 的來源、組織採用的解讀、理由和決策負責人。後續交付作業平常只需使用已形成的常設要求；若產品層級要求仍留下重大法律或合規問題，執行者應把問題送回結構化討論，而不是在實作期間自行解讀法案。

這種權威關係可能跨越多個組織層級，例如集團政策先由業務單位具體化，再落到個別產品。AI 程式開發代理的日常路徑應以產品層級常設要求為主要終點，使用已核准、適用於該產品的解讀；若產品層級紀錄不完整或互相矛盾，再沿已指定的決策路徑升級處理。

## 3. 適用條件與交付作業如何使用常設要求

相關工作能找到並正確套用產品常設要求，這些要求才真正具有交付價值。**適用條件**說明一項要求在什麼情況下需要參與某項交付作業，例如：

- 所有使用者可見介面；
- 所有對外 API；
- 所有處理特定類別個人資料的能力；
- 所有部署在指定司法管轄地的工作負載；
- 所有建立或顯示金額的產品介面；
- 所有屬於特定法規或產品分類的 AI 能力；
- 對某個業務物件的所有修改；或
- 受指定供應商或客戶合約約束的所有整合。

適用條件可以很簡單，也可以取決於其他條件。本地化要求可在交付作業新增或修改使用者可見文字時適用；資料管轄地要求可能取決於資料類別與部署位置；相容性要求則可能只適用於公開介面。常設要求需要提供足夠資訊，讓相關參與者或上下文路由機制可以辨認何時應載入和套用。

交付系統應提供可靠路徑，讓人員與 AI 在提示、結構化討論、規格、實作與驗證過程中取得並考慮適用的產品常設要求。交付作業規格可以引用產品層級要求，再集中寫這次變更特有的行為、解讀、例外、實作責任或證據。這樣，會反覆使用的整體脈絡保留在知識系統中，交付作業只攜帶與本次工作真正相關的局部內容。

管治指示與 Skills 是其中一種實作方式。管治指示可以指出哪些情境需要專項知識；Skill 再載入產品常設要求規格、實作指引、參考資料和相關驗證程序。

以多語言使用者介面為例，使用者可以在不同語言之間切換，同時保留目前狀態，不會因切換語言而離開原本的功能流程。本地化在這裡是產品行為，不只是工程目錄約定。新增或修改 UI 時，使用者可見文字仍須由本地化系統提供；日期、數值等依語系與地區設定而定的值要依適用格式顯示；產品也必須能增加新的支援語言，而不要求每個功能的程式碼預先假設固定語言清單。

1. **產品常設要求規格**

   定義長期產品行為。使用者可見文字來自本地化系統，依語系與地區設定而定的值遵循產品格式規則，功能行為也能配合未來擴充支援語言。

2. **管治指示**

   規定新增或修改使用者可見文字的 UI 工作必須採用本地化指引，並考慮產品常設的本地化要求。

3. **本地化 Skill**

   說明程式碼儲存庫特有的實作細節，例如本地化介面與語系資源檔放在哪裡、資料夾如何對應 UI 結構、共用字串存放位置、應使用哪些輔助函式，以及需要執行哪些檢查。

4. **交付作業規格**

   定義這次功能新增或修改的專有名詞、警告、翻譯缺漏時的替代行為或其他本地化產品行為。

四層知識各自承擔不同責任：

- **產品常設要求**保存跨交付作業不斷延續的產品行為；
- **管治指示**決定哪類交付工作必須考慮相關知識；
- **Skill**提供程式碼儲存庫特有的實作程序；
- **交付作業規格**則記錄本次工作新增或修改的功能決策。

即使沒有程式碼儲存庫中的 Skills 也可以實現同一個模型。企業生命週期平台可以根據中繼資料判斷適用要求；要求管理工具可以提供篩選後的檢視；知識圖譜可以把工作範圍連到產品限制條件；團隊也可以在結構化討論中使用簡短檢查清單。工具和實作形式可以不同，重點是適用要求能可靠地進入實際交付工作。

有些適用條件本身便需要專業判斷。例如兩項權威要求看似互相衝突，或產品變更落在某個法規分類的邊緣，參與者應先把模糊之處和相關決策負責人清楚提出，再由結構化討論判斷適用範圍，或把問題交給具有相應權限的職能。規格優先交付要求每個重大衝突都有可找到的決策路徑；至於不同專業職能之間的優先順序與升級規則，則由各組織按照自身責任架構決定。

## 4. 產品常設要求規格與決策紀錄

產品常設要求規格回答的是**目前什麼要求具有權威**；決策紀錄保存的則是**為什麼建立、修改或核准偏離這項要求**。

把現行要求與決策依據保持連接、但分開維護，可以同時降低兩類維護負擔。常設要求規格可保持精簡，方便在每次交付中重用；決策紀錄則保存脈絡、曾考慮的選項、理由、上游來源的解讀及核准歷程，一般執行者不必在日常工作中載入全部歷史。

針對需求規格形成之前的可追溯性研究，已提供一套成熟方式描述這類決策來源問題。Mucha、Kaufmann 與 Riehle 回顧 77 篇文獻，研究要求如何連回其形成來源，包括利害關係人互動、會議紀錄和既有系統；這些研究關心的核心問題包括要求為何存在、為何改變，以及哪些人參與形成。[^citation-06] 即使目前的產品常設要求保持簡短，這些問題仍應能透過決策紀錄追查。

每份產品常設要求規格都應連到可實際查閱的決策依據。組織可以用獨立決策紀錄、已核准的結構化討論紀錄、要求管理平台、控制系統或其他受維護來源實現，不必採用單一工具或格式。

一份精簡的產品常設要求規格通常應交代：

- **目的與範圍：** 這份規格處理哪一項產品關切事項；
- **要求：** 目前具有權威的規範條件；
- **適用條件：** 這些條件適用於哪些產品介面、資料、能力、司法管轄地、系統介面或情境；
- **決策權限：** 哪個具明確責任歸屬的角色或職能可以建立或修訂要求；
- **驗證要求：** 適用的交付作業應提供什麼證據或採用哪種驗證方式，若需要另一種專業判斷則說明例外；以及
- **相關權威知識：** 在需要重新解讀、修改或檢視決策依據時，應前往哪份決策紀錄或其他產品知識。

這套參考結構可以按產品規模採用不同形式。簡單產品用幾段文字便可以涵蓋六項內容；受嚴格監管的組織則可能使用結構化欄位、核准狀態、穩定識別碼、追溯連結和證據系統。

決策紀錄的格式更應按專業領域調整。架構決策紀錄通常保存架構脈絡、選項和理由；安全決策紀錄可能需要威脅或控制脈絡；合規決策紀錄可能要保留法規來源與組織採用的解讀；可靠性決策紀錄則可能包含服務目標和營運證據。產品決策也可以有自己的格式。

規格優先交付只要求重大決策留下足以追溯的紀錄；各專業領域與組織可以自行制定適合其治理需要的範本。一項重大決策通常至少需要足夠資訊回答：

```text
決策
脈絡
理由
決策負責人
受影響規格
日期
```

相關專業職能或組織可再加入自己的權限、審查、控制、證據或取代流程所需欄位。後續文章會逐步把這個一般模型具體化：[架構知識的形成與治理](/zh-tw/hub/formation-and-governance-of-architecture-knowledge)會套用到架構決策與 ADR；安全與私隱、可靠性與營運文章則會在各自專業範圍中定義更合適的決策紀錄方式。

這種分工也令產品常設要求的變更模型更清楚。實質要求改變時，更新目前規格並建立或更新對應的決策紀錄；過往理由繼續可供追查，但不必把常設規格寫成按時間排列的歷史記事。

## 5. 要求、符合狀況、偏離與修正

產品常設要求取得權威後，現有產品未必已全部符合。既有系統新增一項要求、組織政策開始適用、標準更新，或團隊發現現有實作一直與既有要求不一致，都可能出現這種情況。

規格優先交付把三件事分開處理：

1. **要求：** 適用的產品行為或實作必須達到什麼條件；
2. **目前符合狀況：** 現有產品哪些部分已符合、哪些部分仍違反要求；
3. **修正工作：** 需要透過什麼交付工作處理已知不符合項目。

在適用範圍內，新增或修改的程式碼必須符合目前的產品常設要求；任何偏離都要先由具相應決策權的角色核准。現有不符合項目應成為明確可見的修正知識，而修正本身也是一項交付作業，要重新經過結構化討論、適用的規格體系、實作、驗證和驗收。

這種分工可避免現況實作反過來成為新的默認要求。假設組織訂定所有適用的使用者介面都必須符合目前的無障礙標準，但審查發現數個既有畫面尚未達標，產品常設要求仍可清楚寫出已核准的產品條件；目前符合狀況紀錄指出舊介面的缺口，再由獨立的修正交付作業決定何時以及如何把相關介面帶到合規狀態。

組織也可以把逐步採用本身作為正式的產品或合規決策。例如，決策負責人可要求所有新增和有重大修改的介面立即符合新標準，同時明確安排舊介面的修正工作。由於這項決定改變要求如何管治目前交付，它應反映在適用條件或決策紀錄中。實作團隊只能根據已核准的採用決策使用這項例外；既有程式碼只代表目前符合狀況，不能自行產生例外權限。

### 5.1. 偏離的審查與決策

某些交付作業確實可能需要偏離產品常設要求。只要偏離會改變產品在特定範圍內實際滿足的條件，它就是一項重大決策。

因此，與產品常設要求衝突的規格必須說明衝突，並連到已核准的決策紀錄。具相應權限的角色要決定：常設要求本身是否應改變、這次偏離是否屬於有明確範圍的例外，或原本提出的交付作業是否需要調整。永久且合理的排除條件可以寫入要求的適用條件；暫時或只限某一交付作業的例外，則保留為該範圍下的決策。

驗證沿用同一條權限鏈。產品常設要求應直接說明或指向適當的驗證方式：可確定判斷的要求可以用自動化測試；無障礙可能結合自動檢查與合資格人員審查；合約或法律要求可能需要專業確認和實作證據。若一般驗證規則不適用，也應明確說明例外，而不是硬套一種證據形式。

更完整的證據模型由[可信賴交付作業與驗收證據](/zh-tw/hub/trusted-increments-and-acceptance-evidence)處理。該文把常設知識和專項規格納入交付作業的驗收基礎；本文則提供驗收證據需要證明符合的長期要求。

### 5.2. 可選的符合狀況監測

自動化可以協助找出不符合項目，但監測本身不因此取得修正權限。

AI 程式開發代理或其他自動化工作可以定期比較實作證據與指定產品常設要求，輸出報告、電子郵件、GitHub issue、Jira 工作項目或其他工作路由紀錄。真正有用的結果，是把觀察到的可能不符合項目明確呈現，並連回相關要求和觸發判斷的證據。

```mermaid
flowchart LR
  accTitle: 可選的自動化符合狀況監測
  accDescr: 自動化檢查把產品證據與常設要求比較，報告可能的不符合項目，再把修正工作送入由人員承擔責任的交付作業。

  A[產品常設要求] --> B[自動化符合狀況檢查]
  B --> C[可能不符合]
  C --> D[issue、報告、電子郵件或工作項目]
  D --> E[結構化討論]
  E --> F[修正交付作業]
```

監測工作的權限只包括觀察與通報。任何程式碼變更或權威規格變更，都應透過正常交付流程，在明確的執行範圍與權限下開始；自動修正、提交程式碼、核准例外或修改產品常設要求，都需要另行授予清楚權限。

這只是其中一種可選做法。產品也可以採用人工審查、CI 檢查、合規平台、排程執行的 AI 程式開發代理、營運控制或其他合適機制。框架真正要求的是：已知且重大的不符合項目必須清楚可見，並交由有明確責任歸屬的交付流程處理。

## 6. 透過知識收斂逐步形成常設要求

團隊不必在採用框架前一次列出所有產品常設要求。實際交付會持續發現影響超過單一作業的長期義務，團隊可以從目前已知的重要常設知識開始，再隨真實工作逐步補足。

[交付作業生命週期中的知識收斂](/zh-tw/hub/knowledge-convergence-across-the-increment-lifecycle)已定義這個更廣泛的機制。包含產品常設要求在內的現況知識會先影響交付作業；實作和驗證又可能揭露缺失知識、互相競爭的解讀，或反覆出現的產品整體要求。只要新知會影響未來工作，組織就要確認其適用範圍、找到正確的決策負責人、與既有知識對齊，再把結果發佈為新的現況知識，讓之後的交付作業可以依賴。

交付作業使用現有常設要求，發現可重用的產品知識，送回適當專業權限形成決策，再把收斂後的結果提供給未來工作。



1. **使用目前常設知識**

   交付作業先採用目前已知、適用於其範圍的產品常設要求。

2. **發現可長期重用的新知**

   結構化討論、實作、驗證或審查揭露遺漏、不完整、過時或互相衝突的要求，而且影響超過目前作業。

3. **找到決策權限**

   參與者先把問題明確提出，再把專業問題交給具相應決策權的負責人。

4. **收斂要求**

   相關參與者透過結構化討論，確立產品層級要求、適用條件、決策及需要保留的決策依據。

5. **發佈現況知識**

   決策負責人發佈新增或修訂後的產品常設要求，以及適合該專業領域的決策紀錄。

6. **路由到未來工作**

   更新管治指示、Skills、索引、中繼資料或其他機制，讓未來適用的交付作業可以取得已收斂的要求。

這種逐步形成方式讓投入程度與實際需要保持相稱。團隊可以從已知的重要要求開始，透過真實交付持續改善知識系統；當一項候選要求的影響已超過本次局部變更，而且具相應權限的角色明確決定要讓未來工作重用，它才成為產品常設知識。

同一流程也可以淘汰過時要求。產品策略、法規解讀、合約、架構或營運模式改變，甚至長期累積的交付證據，都可能顯示某項產品常設要求需要調整。團隊先透過結構化討論形成變更，再由具相應決策權的角色核准並更新現行規格；決策紀錄保存變更原因，再讓受影響知識完成收斂，使未來工作採用新的權威狀態。

## 7. 產品常設要求的專項類別

產品常設要求是一類可擴充的產品知識。每個產品與組織都應依自己的領域、司法管轄地、合約、技術、營運模式和專業責任，建立真正需要的要求目錄。

常見類別包括：

1. **一般產品要求**

   跨不同能力或使用者體驗持續適用的產品整體條件。

   - **例子:** 本地化、無障礙、相容性、共用產品不變條件、支援市場或產品整體 AI 行為。
   - **常見決策權限:** 產品、設計、領域、無障礙或其他按議題承擔產品決策責任的職能。

2. **安全與私隱要求**

   適用交付作業必須持續保留並驗證的安全控制和資料處理義務。

   - **例子:** 授權條件、敏感資料處理、禁止行為、私隱控制、稽核要求或已核准信任模型。
   - **常見決策權限:** 安全、私隱、產品、法務或其他按決策承擔責任的職能。

3. **可靠性與營運要求**

   影響故障行為、復原、可觀測性、效能、部署和支援方式的產品整體營運要求。

   - **例子:** 復原目標、故障行為、監測要求、容量限制、支援條件或回退條件。
   - **常見決策權限:** 可靠性、營運、工程、產品或組織指定的服務負責人。

4. **法規與合規要求**

   經專業結構化討論確認後，對特定產品有效的外部義務解讀。

   - **例子:** 證據保存、必要控制、禁止處理、披露或適用於特定產品能力的審查條件。
   - **常見決策權限:** 法務、合規、風險、產品或其他具相關組織決策權的角色。

5. **資料管轄地要求**

   規定特定資料可在哪裡儲存、處理、傳輸、備份或複製的長期規則。

   - **例子:** 針對指定資料類別和部署情境形成的資料駐留或處理地點要求。
   - **常見決策權限:** 私隱、法務、合規、安全、資料治理或其他具相關決策權的組織職能。

6. **合約與供應商要求**

   由客戶、合作夥伴、供應商、授權條款或其他外部協議形成的產品義務。

   - **例子:** 相容性承諾、供應商標示、保存期限、允許用途、刪除義務、服務承諾或客戶特定控制。
   - **常見決策權限:** 產品、法務、商務、採購、工程或依合約安排承擔責任的負責人。

7. **組織特有要求**

   會實質限制產品、並跨多項交付作業持續適用的內部要求。

   - **例子:** 技術控制、內部資料分類、核准服務政策、產品組合要求或組織特有工程義務。
   - **常見決策權限:** 擁有相關政策的組織職能，以及負責把政策解讀為產品層級要求的產品角色。

不同類別可以在內容上重疊，但仍由不同專業職能擁有決策權。例如，資料管轄地要求可能同時源自私隱法、企業控制和客戶合約。產品層級常設要求保存交付工作應遵循的已核准義務，決策紀錄則保留相關來源、判斷與權限關係。

「準備知識系統」系列的文章次序也反映這種依賴關係。本文先建立可重用產品要求的一般機制；[架構知識的形成與治理](/zh-tw/hub/formation-and-governance-of-architecture-knowledge)再說明架構如何採用適用的產品、組織、安全、可靠性、營運、成本與實作輸入形成結構性決策；之後的安全與私隱要求、可靠性與營運要求，則分別把產品常設要求模型套用到各自專業領域。

## 8. 建立與驗證產品常設要求

產品常設要求需要一套可重複使用的工作方式，才能真正進入交付。團隊在首次發現長期產品義務、需要修訂既有要求，或某項交付作業揭露一項應進入現況知識的反覆要求時，都可以採用以下流程。

### 8.1. 建立產品常設要求

找出會跨交付作業持續存在的產品義務，由適當專業權限精煉後發佈為常設規格，連接決策依據，再路由到未來工作。



1. **找出反覆出現的產品義務**

   從要求、事故、審查發現、組織政策、法規、合約、產品決策或重複交付討論中，找出影響超過單一作業的內容。

2. **確認決策權限與證據**

   找出能決定產品層級要求的角色或專業職能，以及討論需要參考的來源、既有產品知識、實作證據和過往決策。

3. **進行結構化討論**

   把義務精煉成產品特定要求，說明適用條件，提出衝突，並按影響和模糊程度區分仍需專業決策的問題與實作選擇。

4. **發佈產品常設要求**

   在權威知識系統中記錄目前產品層級要求、適用條件、決策權限、驗證要求，以及前往相關權威知識的路徑。

5. **保留決策依據**

   維護適合該專業領域的決策紀錄，並與產品常設要求連接。

6. **路由到未來交付**

   更新管治指示、Skills、索引、中繼資料、要求管理工具或其他上下文路由機制，讓適用工作會考慮這項要求。

7. **驗證是否可用**

   以真實交付責任確認合資格參與者能找到要求、判斷何時適用、找到決策權限、理解所需證據，並在不依賴私人記憶的情況下處理模糊之處。

建立產品常設要求時採用的[結構化討論](/zh-tw/hub/requirements-increments-and-structured-discussion)，深度應與決策的模糊程度、後果和專業責任相稱。簡單產品決策可能只需簡短書面交流和精簡決策紀錄；法規解讀則可能需要法務、合規、產品、安全與工程共同參與，並提供更完整的證據。

### 8.2. 與需要相稱的可追溯性

可追溯性可以實質改善維護工作，但維護追溯關係本身也有成本。Mäder 與 Egyed 以 71 名受試者進行第三方軟體維護工作的控制實驗，發現能使用追溯連結的參與者平均快 24%，正確解法多 50%。[^citation-07] 實務研究同時說明為何追溯機制需要與需要相稱。另一項實務研究調查 55 位實務工作者並訪談其中 14 位；受訪者把追溯成本視為採用障礙，而且大部分可追溯性工作仍靠人工維護。他們也預期自動化應協助人員，而不是把人員完全移出追溯流程。[^citation-08]

因此，規格優先交付要求的是足以支援交付的追溯關係，工具與複雜程度由組織按需要選擇。產品應能回答：

- 這項工作適用哪一項產品常設要求？
- 目前哪份規格具有權威？
- 誰可以決定它的解讀或修訂？
- 需要檢視決策依據時，應去哪裡找決策紀錄？
- 判斷是否符合時需要哪種驗證或專業證據？
- 目前有哪些已知不符合項目？
- 要求改變後，哪些下游知識也必須更新？

小型產品可以用幾份互相連結的 Markdown 文件和清楚的管治指示回答這些問題。大型組織則可能使用識別碼、要求管理系統、自動產生的適用要求檢視、知識圖譜、政策引擎或可追溯性平台。只要工具能減少重複搜尋與維護成本，同時保留原本的決策權限模型，就有實際價值。

### 8.3. 以不熟悉產品的參與者驗證

當一名合資格但不熟悉產品的參與者，能沿著實際知識系統存取路徑完成一項適用的交付責任，產品常設要求這一層才算準備就緒。給參與者一項具代表性的擬議交付作業，並要求對方：

- 找出與工作相關的產品常設要求；
- 以產品層級規格作為正常參考，說明每項要求為何適用；
- 找出把相關知識帶入目前範圍的管治指示、Skills 或其他路由機制；
- 在需要檢視要求來源或解讀時找到決策紀錄；
- 找出有權處理模糊、衝突或偏離的角色；
- 說明驗證要求，或已獲解釋的例外；以及
- 分辨已知既有不符合項目，和新工作是否獲准重複該做法，是兩件不同的事。

對 AI 程式開發代理也使用同一測試，但必須沿它實際獲得的存取路徑和提示流程進行。一般實作期間，代理應直接取得產品層級常設要求，不必從上游來源材料重新還原專業判斷；若產品層級要求仍留下重大問題，代理應把問題提交給結構化討論。

通過這項測試，代表長期專業判斷已真正成為可重用交付知識。即使人員、團隊或 AI 工具更換，未來交付作業仍可使用同一份權威要求；需要重新解讀時有清楚的決策路徑，而新發現的知識則會經知識收斂回到產品現況。

[^citation-01]: Pavithra P. M. Nair and Preethu Rose Anish. “From Regulation to Requirements: An Automated Requirement Derivation and Explanation Pipeline.” arXiv preprint, presented in the Requirements Engineering 2026 Industrial Innovation Papers track (2026). [https://doi.org/10.48550/arXiv.2607.04448](https://doi.org/10.48550/arXiv.2607.04448).

[^citation-02]: Cristina Palomares, Carme Quer, and Xavier Franch. “Requirements Reuse and Requirement Patterns: A State of the Practice Survey.” *Empirical Software Engineering* 22, no. 6 (2017): 2719–2762. [https://doi.org/10.1007/s10664-016-9485-x](https://doi.org/10.1007/s10664-016-9485-x).

[^citation-03]: Mohsin Irshad, Kai Petersen, and Simon Poulding. “A Systematic Literature Review of Software Requirements Reuse Approaches.” *Information and Software Technology* 93 (2018): 223–245. [https://doi.org/10.1016/j.infsof.2017.09.009](https://doi.org/10.1016/j.infsof.2017.09.009).

[^citation-04]: Travis D. Breaux and Annie I. Antón. “Analyzing Regulatory Rules for Privacy and Security Requirements.” *IEEE Transactions on Software Engineering* 34, no. 1 (2008): 5–20. [https://doi.org/10.1109/TSE.2007.70746](https://doi.org/10.1109/TSE.2007.70746).

[^citation-05]: Travis D. Breaux, Annie I. Antón, Kent Boucher, and Merlin Dorfman. “Legal Requirements, Compliance and Practice: An Industry Case Study in Accessibility.” In *16th IEEE International Requirements Engineering Conference* (2008): 43–52. [https://doi.org/10.1109/RE.2008.36](https://doi.org/10.1109/RE.2008.36).

[^citation-06]: Julia Mucha, Andreas Kaufmann, and Dirk Riehle. “A Systematic Literature Review of Pre-Requirements Specification Traceability.” *Requirements Engineering* 29 (2024): 119–141. [https://doi.org/10.1007/s00766-023-00412-z](https://doi.org/10.1007/s00766-023-00412-z).

[^citation-07]: Patrick Mäder and Alexander Egyed. “Do Developers Benefit from Requirements Traceability When Evolving and Maintaining a Software System?” *Empirical Software Engineering* 20, no. 2 (2015): 413–441. [https://doi.org/10.1007/s10664-014-9314-z](https://doi.org/10.1007/s10664-014-9314-z).

[^citation-08]: Marcela Ruiz, Jin Yang Hu, and Fabiano Dalpiaz. “Why Don’t We Trace? A Study on the Barriers to Software Traceability in Practice.” *Requirements Engineering* 28 (2023): 619–637. [https://doi.org/10.1007/s00766-023-00408-9](https://doi.org/10.1007/s00766-023-00408-9).