# 需求、結構化討論與交付作業

軟件交付鮮有以一份完整而且前後一致的規格為起點。更常見的起點，是一項需要、義務、問題、機會、缺陷、風險或變更要求。有些需求本身已經十分明確，有些則只說清楚想達到甚麼結果。無論是哪一種，通常都要結合產品和組織的既有脈絡才能正確理解，包括目前行為、限制條件、架構、領域含義、依賴、決策歷程、業務流程和共用術語。

[規格優先交付](/zh-tw/hub/specification-first-delivery)把解讀需求視為工程交付的一部分。團隊要根據既有的[共享知識系統](/zh-tw/hub/shared-knowledge-system)理解需求，重大問題則交由具明確責任歸屬的角色決定。在一般交付流程中，需求會開啟一項交付作業，而結構化討論就是這次作業的第一項實質工作。

結構化討論亦可以建立持久知識，例如產品術語、架構立場或競爭者分析，即使目前未有軟件變更需要實作。這類討論同樣需要證據、審查和清楚的決策權限，直接成果則是為知識系統增添日後決策和交付可以沿用的內容。

本文先說明這兩種用途，再集中討論較常見的第一種：如何透過結構化討論界定一項交付作業、準備適用的專項規格，並為技術規格提供已確認的輸入。[可信賴交付作業與驗收證據](/zh-tw/hub/trusted-increments-and-acceptance-evidence)接續說明生命週期最後一部分，亦即驗證、符合性審查和具明確責任歸屬的驗收決定，如何共同確立交付後的產品狀態。

1. **開展交付作業**

   功能、缺陷修正、營運變更或其他交付需要會開啟一項交付作業。結構化討論用來釐清這項作業的意圖、範圍、決策、依賴、需要哪些專項規格、技術規格要承接哪些內容，以及日後如何驗收。

2. **建立知識**

   團隊可以在未決定實作任何變更前，調查並審查一項產品或組織問題。經審查的結果會成為持久知識，供日後的決策和交付作業使用。

## 1. 需求：定義、來源與權限

**需求**表達與產品有關的預期狀態、義務、限制條件或變更。它可以說明使用者需要甚麼行為、產品必須遵守甚麼規則、哪些營運特性必須保留、哪個缺陷必須修正，亦可以指出為了繼續履行產品義務而必須改變的技術條件。在這個階段，需求通常只需清楚表達提出需求一方真正需要的是甚麼，並把不屬於這項需要本身的實作決策留待後續處理。

需求可以由不同職能或事件引發，例如：

- 產品負責人提出新的使用者成果；
- 領域專家指出一項業務規則或例外情況；
- 架構師發現產品方向需要某項結構性改變；
- 安全專業人員因新發現的威脅或政策要求加入控制措施；
- 可靠性專家在營運事故後訂明系統應有的失效行為；
- 品質專業人員發現現有需求不足以一致判斷某項行為能否驗收；
- 工程師發現相容性問題或技術限制，需要產品層作出明確決定；
- 監管要求、合約、供應商或組織政策帶來新的外部義務；或
- 使用者和生產環境中的實際行為揭示缺陷或尚未滿足的需要。

在規格優先交付中，每項需求都是跨職能交付的輸入。需求來源提供最初脈絡，也指出誰有權確認這項需要。之後，結構化討論、適用的專項規格和技術規格會逐步釐清它對產品有甚麼影響，以及實作必須做到甚麼。例如，安全需求可能要求多重要素驗證，因而改變使用者流程；功能需求可能牽涉架構調整；技術限制亦可能反過來要求產品作出取捨。多個職能都可能要對同一項變更作出專業判斷，因此最初提出需求的一方，不會因此擁有所有後續決策權。

一項需求要在產品中成為權威依據，必須由具備相關決策權的角色根據適用知識加以確立或確認。工單、待辦清單、會議紀錄、提示或 AI 對話都可以記錄和傳達需求，但需求出現在這些地方，不代表它已經獲得決策權威。團隊亦要檢查它是否與其他權威來源衝突。

共享知識系統通常已經保存了一些跨多項交付作業都適用的要求。產品常設要求，例如資料保留義務、相容性規則、身分驗證限制條件或可靠性目標，只要仍在原有適用範圍內，而且未經具明確責任歸屬的決策修改，便繼續有效。之後的交付作業可以直接套用這些既有要求，毋須每次重新建立。

新需求會進入一個本身已有既定要求的產品。

> **新需求會進入既有產品狀態**
>
> 新需求會在既有知識系統之上提出或限制一項變更。使用者最直接看到的是軟件變更，而相應的知識系統更新則保存日後理解和延續這項變更所需的知識。程式碼審查會把相關的程式碼和知識變更一併檢視。

## 2. 需求脈絡與適用性

需求要放回適用的既有知識中解讀，團隊才知道這次交付真正需要處理甚麼。需求工程早已把脈絡視為需求解讀的一部分。Nuseibeh 與 Easterbrook 指出，需求工程需要理解持份者使用的術語、概念、觀點和目標，而且需求建模與分析不能脫離系統所處的組織和社會脈絡。[^citation-01] 規格優先交付透過共享知識系統保存這些脈絡，再在目前交付作業中按需要取用。

解讀需求所需的知識，也可能分散在組織不同位置。Curtis、Krasner 與 Iscoe 研究 17 個大型軟件專案後，指出領域知識分散、需求浮動或互相衝突，以及溝通樽頸，會在大型系統設計中互相影響。[^citation-02] 結構化討論把相關知識和決策負責人帶到目前需求之中，讓團隊共同判斷它對產品的實際影響。

共享知識系統可能已經包含產品意圖、使用者角色、穩定使用案例、領域語義、既有規格、架構、介面、管治指示、目前程式碼、以往決策，以及早前交付留下的證據。一項需求即使單獨看來合理，仍可能與產品已確立的脈絡衝突。

例如，有人提出「讓使用者在提交紀錄後仍可修改」。這句話看似簡單，但真正決定其含義的，可能包括以下既有知識：

- 產品意圖可能把草稿修正和提交後修訂視為兩件不同的事；
- 業務規則可能禁止在指定狀態轉換後直接修改資料；
- 審計要求可能規定必須建立新版本，而不能直接改寫既有紀錄；
- 外部介面可能把已提交的識別碼視為不可變；
- 目前程式碼之所以仍容許編輯，可能只是舊有 UI 控制項從未移除；
- 較早的決策亦可能已經否決直接編輯，原因是下游系統無法安全處理這種變更。

把這些知識放在一起後，團隊才能知道真正需要決定的是甚麼，以及哪些實作結果符合這項決定。

因此，理解需求時通常需要考慮以下幾類知識：

1. **產品意圖**

   要求的成果是否符合產品的目的和優先次序。

2. **既有行為**

   哪些目前行為是刻意設計、偶然形成、已經過時，或屬於必須保留的行為。

3. **相關規格**

   哪些既有規格適用於這項交付作業，以及它們已經訂明甚麼要求。

4. **領域知識**

   哪些規則、狀態、最終權威依據、計算方式或時間含義會影響需求的解讀。

5. **架構與介面**

   哪些系統責任、契約、依賴和相容性義務與這項變更有關。

6. **決策歷程**

   哪些以往決策解釋目前狀態，或限制表面上看來可行的其他方案。

7. **權限**

   每項重大條件應由哪個角色確立、否決或修改。

8. **證據**

   哪些既有觀察、事故、測試或紀錄會影響這次決策。

按需分層載入上下文讓這項檢視保持合適深度。參與者先讀取通常與這項變更有關的產品知識；當問題觸及更廣泛的組織或專業範疇時，再取用相應資料。

在下游規格承接需求之前，團隊應先把會實質改變其含義的既有知識納入解讀。

```mermaid
flowchart LR
    accTitle: 需求要結合適用的產品知識才能正確理解
    accDescr: 目前需求會開啟一項交付作業；結構化討論再把需求與相關共享知識和既有產品狀態放在一起理解。

    R[目前需求]
    I[開始交付作業]
    K[適用的共享知識]
    P[既有產品狀態]
    D[結構化討論]
    SP[專項規格，如適用]
    TS[技術規格]

    R --> I
    I --> D
    K --> D
    P --> D
    D --> SP
    SP --> TS
    D -. 不需要專項規格 .-> TS
```

這種做法亦可避免某一來源在未經明確決策下凌駕另一來源。如果新需求與一項權威架構決策衝突，具相應權限的角色可以決定修改架構；如果它與產品常設安全要求衝突，則可能要重新審視安全要求。無論最後採用哪種處理方式，衝突都會在實作建立新產品狀態前成為一項明確決策。

## 3. 結構化討論：定義、用途與權限

> **結構化討論，是由人與 AI 根據適用知識共同檢視一項交付需要或知識問題，找出會實質改變結果的不同解讀，並把由此產生的每項決策交由具相應權限的人員處理。**

結構化討論可以在會議中進行，也可以透過文件、議題或審查流程非同步進行，亦可以與 AI 系統合作，或混合使用多種方式。它的結構來自幾項做法：重大問題會被清楚提出，證據和不同方案可以受到質疑，而經審查的結果會以清楚的狀態和負責人記錄下來。框架本身不規定一種會議形式或文件範本。

把會實質改變結果的不同解讀明確提出來，是結構化討論的一項核心作用。Franch 等人訪問 12 家公司的 24 位從業員後，發現模糊、不完整和不一致是最常被提及的需求規格問題；受訪者亦提到，部分模糊之處會在其後迭代中逐步澄清。[^citation-03] 規格優先交付把這項澄清納入交付作業，並在下游工作依賴某個解讀之前，把經審查的結果記錄清楚。

### 3.1. 開展交付作業的討論

大部分結構化討論都用來開展或界定一項交付作業。功能要求、缺陷報告、營運問題或技術需要首先提出一項值得考慮的變更。團隊由此開始交付作業，把需求與知識系統和程式碼庫一併檢視，再決定這次作業要包括甚麼、不包括甚麼、哪些行為必須保留、需要哪些規格、如何驗證，以及最後要交付甚麼。

以「讓網站能顯示 Markdown 文件」為例，最初看來只是一項功能，但討論後可能發現它同時牽涉內容來源和本地化、metadata 與驗證、Markdown 編譯、無障礙閱讀體驗、瀏覽器路由、靜態 HTML 和 Markdown 發佈、探索檔案，以及由 manifest 驅動的伺服器內容傳送。這些彼此相關的決策合起來，才構成一項完整而一致的交付作業。之後，團隊可以把實作拆成共享內容模型、編譯器、閱讀器、路由、發佈和伺服器等多項互相協調的工作，但不應把這些工作誤當成多項獨立交付作業。

缺陷修正沿用同一模式，只是規模較小。例如，語言選擇器把讀者帶到不存在的翻譯版本，團隊可以由這個問題開展一項交付作業，討論並確認應該返回哪個路由、哪些既有行為要保留、哪個導覽契約受到影響，以及修正後需要甚麼證據。討論可以十分簡短，但仍然屬於這次交付作業本身。

### 3.2. 建立知識的討論

有些結構化討論並不立即導向軟件變更，而是為日後建立持久知識。主題可以是產品術語、領域解讀、產品常設要求、架構立場、市場問題，或任何日後交付需要一致理解的事項。

例如，一套專為企業對企業（B2B）食品銷售而設的客戶關係管理（CRM）系統，可以進行競爭者分析。團隊先找出相關競爭產品，再比較它們如何處理客戶帳戶結構、產品目錄、客戶專屬定價、銷售與訂單流程、食品追溯和系統整合。參與者收集最新資料來源，把已核實事實和策略解讀分開，記錄對產品方向的啟示，並設定重新檢視週期。經審查的分析便成為持久的組織知識。它日後可能影響產品策略、交付優先次序、合作關係或新的交付作業，即使目前沒有任何實作工作，仍然有獨立價值。

這兩種討論可以使用相同技巧，甚至共用同一種討論文件格式，但直接成果並不相同。用來開展交付作業的討論，會界定這次作業、整理適用專項規格所需的經審查輸入，並為其後的技術規格建立基礎；用來建立知識的討論，則產生可供日後多項決策和交付作業重用的經審查知識。

跨職能參與的重點，是在需要時把相關專業知識真正帶入目前的問題。Faraj 與 Sproull 把專業知識協調描述為知道專業知識在哪裡、何時需要，以及如何把所需知識帶入工作。[^citation-04] 在結構化討論中，產品負責人可以界定預期成果，架構師則指出對系統責任的影響；安全專業人員可能判定一條看似簡單的路徑需要額外授權；可靠性專家可能要求不同的失效方式；工程師亦可能發現要求與某項介面或不可違反的規則衝突。每個職能都在自己的專業責任範圍內，直接參與界定同一項變更。

結構化討論通常會處理以下幾類問題：

1. **意圖**

   釐清希望達到的結果、受影響的使用者或系統責任，以及為甚麼需要這項變更。

   - 預期狀態或產品狀態變更
   - 相關使用者、系統或營運成果
   - 需求來源和具責任歸屬的決策負責人

2. **適用性**

   判斷哪些既有產品知識、規格、依賴和組織義務與這項交付作業有關。

   - 適用的共享知識系統來源
   - 互相衝突或已被取代的知識
   - 需要補充的專業脈絡

3. **範圍**

   說清楚這項變更包括甚麼、不包括甚麼，以及哪些既有行為必須保留。

   - 包含的成果和受影響責任
   - 非目標
   - 必須保留的行為和相容性義務

4. **解讀**

   找出會實質改變交付結果的不同解讀、正常與例外情況，以及需要確認的假設。

   - 含義不清的術語或情境
   - 例外和無效狀態
   - 需要確認的假設

5. **影響**

   找出需求會改變哪些依賴、風險、介面、資料含義、營運安排和其他責任。

   - 上游和下游影響
   - 安全、可靠性、資料和營運方面的影響
   - 必須先具備的能力或決策

6. **權限**

   分清楚哪些問題現在就要決定，哪些應交由專項或技術規格處理，以及哪些可以留在獲授予的實作權限內判斷。

   - 決策負責人
   - 升級處理條件
   - 明確授權的專業判斷

結構化討論要把決策結構說清楚，讓日後參與者知道哪些事情已經定案、哪些仍然未決，以及誰有權處理。只要責任歸屬和影響清楚，部分問題可以交由指定的專項或技術規格處理，也可以留待交付作業之外再決定。

AI 可以廣泛參與這兩類討論。它可以檢視相關知識、找出遺漏情境、比較不同解讀、發現不一致之處、整理替代方案、記錄會議中的重要結論、維護討論紀錄，以及整理經審查的決策。對交付作業而言，AI 還可以準備專項規格和其後技術規格所需的候選輸入；對以建立知識為目的的討論而言，它可以協助比較資料來源和維護分析結果。這些都是有用的推理和資訊管理工作。

AI 可以提出答案，但組織的決策權限仍屬於具明確責任歸屬的角色。如果問題會改變產品行為、架構、安全、可靠性、領域含義、驗收條件，或其他有指定決策責任的事項，就必須由擁有該項決策權限的角色定案。

## 4. 交付作業模式

在規格優先交付中，結構化討論會開展並逐步界定整項交付作業。

**交付作業**（delivery increment，亦可簡稱作業）是針對一項連貫產品變更的完整交付迭代。它由最初需求開始，經過結構化討論、適用的專項規格、技術規格、實作、驗證、驗收，再到正式交付，最後形成一項經整體審查的結果。這項結果包括軟件變更，以及日後理解、操作和繼續修改這項變更所需的知識系統更新。新功能可能建立新的持久產品知識；小型缺陷修正則可能只需記錄修正過程中新發現的重要知識。如果既有知識仍然準確，也可能毋須額外更新文件。

一項交付作業可以由 Scrum Product Backlog Item、Kanban 卡，或一組互相關聯的工作項目來代表；一個 epic 亦可以包含多項交付作業。這些規劃工具用來識別和協調工作，而交付作業本身則指完整的交付循環和最終整合結果。

**作業循環: 從需求到正式交付**



1. **開始交付作業**

   記錄功能、缺陷修正、營運需要或其他擬議變更，包括其來源和最初的決策責任歸屬。

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

   把需求與知識系統和程式碼庫一併檢視，找出假設和不同方案，並釐清預期成果、範圍、非目標、依賴、必須保留的行為和驗收基礎。

3. **編寫專項規格並確認準備就緒**

   變更如有需要，分別編寫功能、架構、安全、可靠性、資料、整合、測試或其他專項規格，讓每個相關職能直接加入自己的專業判斷。

4. **編寫技術規格並確認準備就緒**

   把已界定的交付作業和經審查的專項規格轉化為可執行的技術工作，清楚列明範圍、權限、限制條件、依賴和驗收證據。

5. **實作並驗證**

   在已確認的範圍和權限內執行工作，產生協定好的證據；如果發現新問題，便帶回討論，而不是在實作中自行作出重大解讀。

6. **驗收並交付**

   根據協定好的證據作出驗收和發佈決定，再把實作、測試、規格、決策和所需現況知識作為一項完整結果一併交付。

**逐行確認**是規格的準備就緒關卡。相關的人類決策負責人首先確認適用的專項規格；過程中，他們可以與其他人或 AI 程式開發代理一起解決矛盾和重大問題，確保參與者對規格形成一致而且足以進入實作的理解。

之後，工程師要確認技術規格完整保留這些已定案內容，並把工作界定至可執行程度。AI 程式開發代理亦應在寫程式碼前說明自己如何理解技術指示，並提出歧義或衝突。當所需規格路徑已經沒有重大未決問題，實作才開始。如果實作期間發現新的重大問題，團隊會重新開啟討論，先更新受影響規格，再繼續執行。

並非每項開始討論的交付作業都會進入實作。團隊可能否決、延後、拆分或合併原有提案，因為討論顯示另一種處理方式更符合產品方向、決策權限、依賴或現有證據。交付紀錄會保存這個結果，成為決策歷程的一部分。

整個循環的深度要與變更本身相稱。對一項熟悉而局部的缺陷修正，團隊可能只需一份簡短討論紀錄，然後直接編寫一份技術規格，因為毋須額外建立專項規格。如果修正非常小，而既有知識系統已經充分限制工作範圍，工程師甚至可以直接用提示完成工作，不另寫獨立規格。相反，跨系統功能可能需要多份專項規格，再由多份技術規格承接。兩種情況的原則都一樣：只有當這次作業所需的規格路徑已經收斂，才開始實作。

AI 程式開發工具提高了單一 backlog item 或 epic 可以嘗試完成的變更量，也放大了誤解需求的後果。一個錯誤解讀可以很快散佈到程式碼、測試、設定和文件。交付作業的範圍應取決於團隊能否把這項變更作為一個整體來討論、規格化、審查、驗證和驗收，而不是 AI 一次可以產生多少程式碼。

一份技術規格通常只負責交付作業的一部分。小型交付作業可能需要三份技術規格，大型作業則可能需要二十份或更多。組織是在交付作業這個層次完成一次完整迭代，並根據整套規格和證據決定是否願意承擔交付後的產品狀態。

## 5. 討論紀錄與決策狀態

討論本身是暫時的，只有當重要結果成為持久知識，日後才可以安全重用。會議和 AI 對話本來就帶有探索性，當中會出現暫定想法、重複問題、後來放棄的解讀、例子、部分答案，以及只是用來比較後果的方案。這些內容在思考期間很有用；日後參與者需要的，則是一份經審查的紀錄，清楚區分提案、假設、已否決方案和未決問題，以及哪些決策已經取得相應權威。

當重大推理需要持久保存時，規格優先交付會使用**討論文件**。這是一份經審查的紀錄，涵蓋需求或問題、相關脈絡、證據、方案、假設、決策和未解決事項。它可以整合會議紀錄和 AI 工作成果，同時保留各項內容的狀態。簡短的討論文件已足以應付不少情況，框架不要求逐字稿或固定格式。

討論紀錄亦要保存正式規格形成前的需求來源和演變脈絡。Gotel 與 Finkelstein 把需求可追溯性分為規格形成前與形成後兩部分；前者處理需求如何產生和逐步修訂。他們亦指出，規格形成前的可追溯性不足，是許多實務追溯問題的重要來源。[^citation-05] 在規格優先交付中，討論文件會保存需求的來源和形成過程，以及日後規格正確理解這項需求所需的脈絡和決策狀態。

對交付作業而言，討論文件記錄這項變更如何成形，並把已確認的結果、限制條件和已分派問題整理成適用專項規格的輸入；經審查的專項規格再成為技術規格的來源。對建立知識的工作而言，討論文件本身也可以成為最終的持久成果。例如，競爭者分析可以保存資料來源、比較維度、已核實結果、策略解讀、重新檢視日期和監察條件，而毋須立即導向程式碼。

視乎情況，討論紀錄可以包含以下資訊：

1. **已確認需求**

   適當的決策負責人已經確立一項必須滿足的條件或成果。

2. **決策**

   具明確責任歸屬的角色已選定或確認某項解讀、方案或限制條件。

3. **規格輸入**

   經審查的結果、限制條件或已分派問題，必須由指定的專項或技術規格如實承接，而不能重新解讀其已確立含義。

4. **假設**

   目前工作依賴某項尚未成為權威結論的說法。

5. **非目標**

   與目前變更相鄰而看似合理的成果，已經明確排除在這次作業之外。

6. **已否決方案**

   團隊曾考慮某個方案，但明確決定不採用。

7. **未決問題**

   某項重大問題仍未解決，不得視為已經定案。

8. **已授權處理的問題**

   某項決策有意交由指定專項規格、技術規格，或在已定權限內由實作者運用專業判斷處理。

9. **依賴**

   另一項決策、能力、介面或交付作業必須先具備，相關工作才能繼續。

這些分類讓日後參與者分得清各項內容目前處於甚麼狀態。規格輸入可以已獲確認、已交由指定專項或技術規格處理，也可以清楚標示仍受某些條件限制。知識結論亦可以是已核實、屬於解讀、暫定，或已排期重新檢視。每項內容呈現的權威，都應與實際決策或證據所支持的程度一致。

例如，安全討論可能確認某項整合必須同時使用 OpenID Connect（OIDC）和用戶端憑證。這個經審查的結論便成為規格輸入。功能規格記錄受保護連線的所需行為，包括 OIDC 和用戶端憑證條件；安全規格則訂明控制措施、威脅考量和所需證據。技術規格之後界定獲授權的實作工作，例如建立一個從核准的憑證保管庫取得用戶端憑證的類別，以及使用該憑證的安全連線工具。功能、安全和技術規格各自在相應的責任層次表達同一項已審查決策。

討論紀錄可以防止看似合理的內容在未經適當授權下變成權威結論。例如，一段 AI 對話早期可能建議容許直接修改資料，之後團隊才正式決定採用版本化修訂。經審查的紀錄會清楚指出哪一個才是已接受立場，以及較早方案目前屬於甚麼狀態，讓日後檢索不會把兩者當成同等有效的指示。

團隊在工作中難免會依賴一些假設，當中甚至包括自己尚未察覺的假設。結構化討論配合 AI，可以較早把它們找出來。紀錄應該把假設與已確認需求或已核實事實清楚分開，指出甚麼情況會令假設失效，也要說明由誰決定失效後應如何處理。

討論紀錄亦支援決策歷程。很多被否決的小方案不值得長期保存，但有些決策很可能日後再次被提出。如果某項決策對未來仍有價值，便應記錄決策負責人、理由、曾考慮的方案和重新檢視條件，避免組織日後重做同一輪分析。管治指示亦可以要求影響整個產品的重大決策同步更新至持續維護的決策歷程紀錄，例如 `docs/decision-history.md`。

紀錄應有多詳盡，同樣要與問題相稱。熟悉的缺陷修正或範圍有限的知識問題，可能一份簡短紀錄已經足夠；影響較大的功能或策略分析，則可能需要更完整地記錄證據、方案、決策、不確定性和重新檢視條件。目的始終是保存重大推理，而不是保存人或 AI 說過的每一句話。

## 6. 需求如何界定交付作業

交付作業代表一項連貫產品變更的完整交付迭代。開始時通常只有初步範圍，之後由結構化討論根據相關需求和既有知識逐步調整。討論可能確認原有提案就是一項完整作業，也可能把它拆成數項作業、與其他需求合併，甚至在實作前停止。因此，需求和交付作業之間可以形成多對多關係。

同一項需求可能需要數項交付作業才能完成，例如先建立必要能力、分階段遷移、降低風險，或在每個階段維持可獨立驗收的產品狀態。另一方面，數項需求亦可能共同構成一項交付作業，因為它們合起來才定義出一項完整產品變更。經過討論，原來提出的需求亦可能被否決、延後，或納入既有交付作業。

```mermaid
flowchart LR
    accTitle: 需求與交付作業可以形成多對多關係
    accDescr: 多項需求可以共同構成一項連貫的交付作業；同一項需求亦可以因為交付次序或需要維持可獨立驗收的產品狀態，而分成多項作業完成。

    R1[需求 A]
    R2[需求 B]
    R3[需求 C]

    I1[交付作業 1]
    I2[交付作業 2]

    R1 --> I1
    R2 --> I1
    R2 --> I2
    R3 --> I2
```

以下是幾種常見關係。

### 6.1. 一項需求形成一項交付作業

如果是局部缺陷，預期行為已經清楚、依賴有限，而且驗收條件穩定，一項需求可以直接對應一項交付作業。由於變更本身已經足夠連貫，結構化討論可以十分簡短。相對簡單的產品中，一項範圍明確、只受少量產品常設要求限制的功能，也可能屬於這種情況。

### 6.2. 一項需求形成多項交付作業

例如，「更換驗證機制」可能先要有一項交付作業建立新的身分整合，再有一項遷移作業讓新舊機制暫時並存，最後才以另一項作業移除舊路徑。這些中間狀態各自都可以形成有意義而可驗收的產品狀態，讓驗證、回退和驗收保持可管理。

產品常設要求亦可以同時適用於多項交付作業，例如可靠性、安全或可支援性要求，因為同一項義務會持續限制多個產品變更。

### 6.3. 多項需求形成一項交付作業

有時數項需求其實只是同一項產品狀態變更的不同面向。例如，一個新的交易流程可能同時包括功能行為、審計義務、可靠性條件和相容性要求。把它們放在同一項連貫交付作業中，可以讓這些要求共同對應至最終由具責任歸屬角色驗收的產品狀態。

這種情況在成熟產品中尤其常見，因為功能需求往往會同時受到多項產品常設要求限制。

### 6.4. 需求被否決或延後

結構化討論可能發現某項需求與產品意圖衝突、重複既有能力、缺乏足夠決策權限、依賴尚未取得的證據，或應等待另一項變更完成後再考慮。這些情況下，團隊可以在實作前結束或延後已開啟的交付作業。

一項需求可以是合理的討論輸入，最後卻沒有形成獲驗收的軟件變更。討論紀錄應保存停止或延後的原因，讓日後參與者毋須重做同一輪判斷。

### 6.5. 需求改變產品常設知識

有些需求不只要求修改軟件，也會改變產品長期適用的知識。例如，新的監管義務可能改寫整個產品的資料保留要求；新的架構決策亦可能改變日後交付作業應視哪個介面為權威來源。具明確責任歸屬的負責人應先更新這些較廣泛知識，再讓目前或後續交付作業依賴它們。

實作工作可以首先發現需要建立產品層先例的問題，但產品層決策仍然需要由具相應權限的角色明確確立。

建立知識的結構化討論亦可以完全獨立於交付需求開始。例如，研究或術語檢討可能只產生持久知識。日後如果這項知識衍生出功能、政策變更或技術義務，組織再另開一項交付作業，並把已審查結論當成適用脈絡即可。

### 6.6. 連貫性、範圍與依賴

一項交付作業要足以代表有意義的產品變更，同時又要把規模控制在意圖、依賴、規格和驗收仍可作為一個整體保持一致的程度。

規格優先交付以團隊能否把一項產品狀態變更作為整體理解和驗收，來判斷交付作業的大小。適當規模會隨變更性質而不同，程式碼行數、story point、工單數量或日曆時間，都不能單獨決定一項作業是否連貫。

一項交付作業通常在以下情況下具有良好連貫性：

- 可以用一句清楚說法表達預期成果，而不需要把互不相關的目的硬放在一起；
- 所有相關需求都限制同一項變更或同一個驗收決定；
- 重大依賴可以被識別；
- 各項專項規格可以在技術規格開始定義實作前，收斂至同一個相容的預期狀態；
- 驗證工作可以判定變更是否符合所有適用要求；以及
- 驗收後產品會處於有實際意義的狀態，而不是只因組織分工而停在一個任意中間點。

如果一項提案包含可以獨立驗收的成果、明顯不同的依賴鏈、需要先建立的前置能力，或適合透過較早變更消除的不確定性，便可能需要拆分。即使長期產品目標相同，不同風險或推出條件亦可能值得分成不同交付作業。

相反，過度拆分亦會破壞連貫性。後端變更、前端變更、安全控制和測試更新，不會因為由不同團隊或職能執行就自動成為四項交付作業。如果它們合起來才產生一項可驗收行為，就應屬於同一項交付作業，即使實作層仍然拆成很多工作。

> **交付作業不應照搬組織交接方式**
>
> 交付作業的範圍應按產品變更本身是否連貫、有哪些依賴，以及如何驗收來決定。團隊架構可以影響誰負責執行，但前端、後端、產品、架構、安全和品質不會只因由不同人負責，就各自變成獨立交付作業。

依賴之所以屬於交付作業定義的一部分，是因為它們決定這項變更能否從目前產品狀態出發，得到完整規格並順利交付。依賴可以是另一項交付作業、外部介面、組織審批、共用 schema、遷移狀態，或一項尚未作出的重大決策。

交付系統要記錄每項依賴是否已經滿足、應納入目前作業，還是必須先另行處理。目前作業只需解決會影響自身準備就緒或驗收的依賴。

當多項交付作業並行規劃時，依賴是否清楚尤其重要。兩項作業即使各自連貫，也可能共同依賴同一個共享介面或決策。可執行工作的詳細協調屬於後續實作機制；在界定交付作業的階段，只需確保依賴清楚可見，避免之後的規格各自假設互不相容的狀態。

## 7. 規格準備就緒、決策權限與回饋

交付作業開始時，團隊對變更的理解通常仍會隨討論逐步清晰。結構化討論要消除那些可能令重大決策意外落到實作者手上的模糊之處，同時保留符合已審查規格的專業實作判斷空間。

### 7.1. 決策應放在哪裡，以及何時算準備就緒

有些問題直接決定這項交付作業究竟是甚麼。例如，一項能力是否在範圍內、使用者是否可以進行某個操作、哪項既有行為必須保留，或兩個成果是否必須同時交付。這些問題會改變組織正在考慮的變更本身，因此團隊應在結構化討論期間解決，然後才把作業視為連貫的整體。

另一些問題則應由專項規格處理。例如，需求可以先訂明資料必須保持加密，再由安全規格決定控制措施，由架構規格決定哪些系統元件承擔責任。界定交付作業時，這些細節可以暫時未有答案，前提是每個問題已有指定規格和決策負責人。專項規格必須在技術規格把已審查決策轉成實作工作前解決這些問題。

技術規格亦可能揭示新的工程問題。只要某個答案可能實質改變行為、風險、介面、限制條件、執行權限或驗收，就必須在實作前定案。只有在多個合理方案都符合所有上游規格時，相關局部選擇才應留在獲授予的實作權限內。

工程師和 AI 程式開發代理可以在獲授予的權限內選擇演算法、輔助結構、內部名稱和實作技巧，前提是各個合理方案都符合已審查規格和驗收條件。

| 決策處理方式 | 適用情況 |
| --- | --- |
| 在交付作業討論中解決 | 答案會實質改變預期成果、範圍、非目標、依賴、必須保留的行為，或具明確責任歸屬的交付承諾 |
| 交由專項規格和決策負責人處理 | 問題需要跨職能或專業判斷，而且必須先解決，技術工作才可以界定 |
| 在技術規格中解決 | 問題屬於可執行工程工作的設計，但必須在開始實作前定案 |
| 授權實作者決定 | 有多個合理答案，而且全部符合已確認規格和執行權限 |
| 留待交付作業之外處理 | 問題本身重要，但不影響目前變更，而且不得因此偶然變成產品先例 |

隨著理解加深，問題所屬的決策層次也可以改變。一個原本看似局部的實作問題，可能揭示共享架構後果；一項技術限制亦可能反過來暴露產品選擇。這時應把問題交由與其影響相稱的決策權限處理。

這與[交付作業生命週期中的知識收斂](/zh-tw/hub/knowledge-convergence-across-the-increment-lifecycle)所採用的原則相同：首先發現問題的人有責任把問題提出；答案是否應成為超越其執行範圍的權威決策，則由適當的決策負責人決定。

### 7.2. 與專項規格及技術規格的銜接

當組織已能清楚說明預期變更、適用需求和知識、已定案事項、仍需由指定負責人解決的問題，以及哪些專業範疇需要進一步處理，結構化討論便已把交付作業推進至可以開始編寫專項規格。如果沒有任何專項規格適用，則可由經審查的討論直接進入技術規格。這仍是同一項交付作業中的正常進展。

[規格優先交付](/zh-tw/hub/specification-first-delivery)把與一項交付作業相關的所有規格合稱為**規格體系**。功能、架構、安全、可靠性、資料、整合、測試和其他專項規格，會在相應範疇適用時，把各職能的專業判斷明確寫下來。這些規格可以並行發展、互相限制，也可以在發現重大衝突時把問題帶回結構化討論。

所需專項規格經審查後，工程師再把它們轉化成一份或多份技術規格。技術規格要把工作寫至可以執行，清楚列明實作範圍、權限、限制條件、依賴、必須保留的行為，以及證明規格符合性所需的證據。技術規格必須完整承接其所實作的專項決策，包括原有含義和決策權威。

同一個經審查的討論結果，可以同時影響多份專項規格，再共同限制其後的技術規格。例如，一項已確認要求可能規定連線必須同時使用 OpenID Connect 和用戶端憑證。這個決定會影響功能上的連線行為、安全控制和證據，以及架構責任。技術規格再負責界定如何實作這些已審查決定。

各層責任應保持清楚：

- 需求說明產品需要甚麼，或對變更加上甚麼限制；
- 結構化討論把交付作業界定清楚，與既有知識協調，並指出哪些專項規格適用；
- 專項規格把必要的跨職能和專業判斷寫清楚，並確保彼此一致；
- 技術規格把經審查的需求和專項決策轉化為可執行工作；
- 具明確責任歸屬的參與者確認實作前不再存在重大未決問題；以及
- 實作在已確認技術規格所訂的範圍、權限、限制條件和驗收條件內執行。

要達到準備就緒狀態，上游產品和專業決策必須在技術規格依賴它們之前確立。如果多個局部實作方案都符合專項規格，則應保留相應的專業判斷空間。

### 7.3. 交付作業內的回饋

交付生命週期容許後續發現把重大問題帶回先前的討論與決策。編寫規格時可能發現原有假設會改變作業範圍；架構分析可能顯示兩個成果不能分開交付；安全分析可能判定原有流程不可接受；可靠性分析可能發現需要先建立其他能力；實作亦可能揭示一項看似局部的變更其實影響共享介面。

只要新發現會實質改變原有變更，團隊就要回到結構化討論，更新需求、交付作業範圍或受影響規格。經修訂的上游決策再成為下游工作的依據。

```mermaid
flowchart TB
    accTitle: 重大發現會在交付作業內返回結構化討論
    accDescr: 需求開啟交付作業，結構化討論之後進入適用的專項規格和技術規格；如果後續階段發現重大問題，便返回討論，直到作業可以驗收和正式交付。

    R[需求或交付需要]
    I[開始交付作業]
    K[適用知識]
    D[結構化討論]
    SP[專項規格，如適用]
    TS[技術規格]
    C[準備就緒確認]
    X[實作與驗證]
    A[驗收與交付]
    U[更新後的知識系統]

    R --> I
    I --> D
    K --> D
    D --> SP
    SP --> TS
    D -. 不需要專項規格 .-> TS
    TS --> C
    C --> X
    X --> A
    A --> U

    SP -. 重大問題 .-> D
    TS -. 重大問題 .-> D
    X -. 實作所得知識 .-> D
    D -. 修訂範圍 .-> I
```

這個回饋機制讓規格持續吸收專業判斷和實作所得知識，並讓重大發現沿經審查的路徑回到交付作業。

## 8. 討論與規格詳盡程度的相稱原則

規格優先交付的相稱原則，同樣適用於結構化討論、討論紀錄和其後需要編寫的規格。

如果一項局部變更意圖清楚、適用知識明確、依賴有限、決策權限已知，而且驗收直接，討論便可以很簡短，之後直接編寫一份精簡技術規格，毋須額外建立專項規格。

重大的跨系統變更，則可能有多種合理解讀、不同專業義務、外部依賴、遷移狀態，以及對既有使用者的廣泛影響。團隊可能要先完成多份專項規格，再建立多份技術規格，才能開始實作。

建立知識的工作亦採用同一原則。確認一個產品術語，可能只需簡短紀錄並更新權威術語表；策略分析則可能需要審查多個資料來源、採用穩定比較框架、分開事實與解讀、由具明確責任歸屬的人確認結論，並訂明重新檢視週期。

需要多少深度，應考慮框架一直使用的幾項因素：

- **模糊程度**：如果存在會導致不同結果的解讀，就需要更明確地解決；
- **新穎程度**：新的行為或架構較少既有先例可以依賴；
- **依賴程度**：牽涉越多系統和責任，越需要處理彼此互動；
- **風險**：錯誤解讀可能造成安全、營運、財務、監管或產品損害；以及
- **後果**：影響越廣、維持時間越長的變更，越值得留下更完整的推理和審查紀錄。

結構不足，會把尚未解決的重大決策推到下游，最後由實作者或 AI 程式開發代理代組織決定需求究竟是甚麼、相鄰行為是否屬於範圍、哪項既有限制可以忽略，以及哪些例外可以接受。

結構過度，則會連本來可以安全交給專業判斷的事情都預先定死。這不但增加維護工作、減慢學習，也可能令討論紀錄變得更長，卻未有提高交付可靠性。

> **解決重大模糊之處，而不是預先決定每個實作選擇**
>
> 結構化討論應把會重大影響意圖、範圍、義務、依賴、權限或驗收的決策說清楚。只要多個實作方案都符合已同意的交付作業和規格，就應保留適當的專業判斷空間。

理想結果是只建立足以支援可信賴規格或持久知識的必要決策結構。

## 9. 運作成果

有效的結構化討論，最後應得出以下兩類清楚結果之一。

1. **已界定的交付作業**

   討論已把目前交付作業界定至可以進入適用專項規格、技術規格和後續交付；如果提案被拆分、合併、延後或結束，也會把原因記錄清楚。

2. **已建立的持久知識**

   經審查結論有清楚主題、資料來源基礎、決策權威、不確定性、維護負責人，以及在知識系統中的適當位置，即使之後沒有立即實作亦然。

如果交付作業會繼續進行，組織應能回答以下問題：

1. 哪些需求確立或限制這項擬議變更；
2. 哪些既有產品知識適用，以及是否需要修改任何權威來源；
3. 哪些重大問題已經定案、被否決、暫作假設、獲授權留待處理，或已交由指定專項或技術規格處理；
4. 誰負責界定交付作業，以及處理規格編寫期間仍未解決的問題；
5. 目前工作應視為一項連貫交付作業，還是應拆成多項；
6. 這項作業包括甚麼、不包括甚麼、依賴甚麼，以及哪些行為必須保留；
7. 哪些經審查的討論結果必須帶入各項適用專項規格；
8. 經審查的專項規格會如何限制實作前的技術規格；以及
9. 最終規格如何追溯至建立它們的需求和討論。

如果是建立知識的工作，組織則應能分辨哪些是已核實結果、哪些屬於解讀，知道由誰審查結論、結論適用於哪些情況，以及何時或因何需要重新檢視。日後的交付作業便可以直接把這些知識當成脈絡，毋須重演原有討論。

在主要交付路徑中，需求先開啟交付作業；結構化討論加入適用知識和具明確責任歸屬的專業判斷，把變更界定清楚；功能、架構、安全、可靠性、資料、整合、測試和其他適用專項規格，再把各項專業判斷明確寫下來；技術規格把已確認需求和決策轉化成可執行工作；實作按照技術規格完成後，具明確責任歸屬的參與者根據證據決定是否驗收和發佈，最後把軟件變更與所需知識更新一併交付。

另一條路徑由知識問題開始。結構化討論完成後，經審查結果直接成為持久知識，供日後任何相關決策或交付作業使用。兩條路徑都把快速分析和執行連接到經審查的解讀和決策權限，讓後續工作知道哪些內容已獲組織確認。

[^citation-01]: Nuseibeh, B., & Easterbrook, S. (2000). *Requirements Engineering: A Roadmap*. Proceedings of the Conference on the Future of Software Engineering, 35–46. [DOI](https://doi.org/10.1145/336512.336523).

[^citation-02]: Curtis, B., Krasner, H., & Iscoe, N. (1988). *A Field Study of the Software Design Process for Large Systems*. Communications of the ACM, 31(11), 1268–1287. [DOI](https://doi.org/10.1145/50087.50089).

[^citation-03]: Franch, X., Palomares, C., Quer, C., Chatzipetrou, P., & Gorschek, T. (2023). *The State-of-Practice in Requirements Specification: An Extended Interview Study at 12 Companies*. Requirements Engineering, 28, 377–409. [DOI](https://doi.org/10.1007/s00766-023-00399-7).

[^citation-04]: Faraj, S., & Sproull, L. (2000). *Coordinating Expertise in Software Development Teams*. Management Science, 46(12), 1554–1568. [DOI](https://doi.org/10.1287/mnsc.46.12.1554.12072).

[^citation-05]: Gotel, O. C. Z., & Finkelstein, A. C. W. (1994). *An Analysis of the Requirements Traceability Problem*. Proceedings of the IEEE International Conference on Requirements Engineering, 94–101. [DOI](https://doi.org/10.1109/ICRE.1994.292398).