產品與使用者理解
說明產品需要達成的成果，以及這項變更是為誰而做。
- 產品意圖、優先順序、預期成果和非目標
- 使用者角色、需要、使用情境、旅程和例外情況
- 領域術語、業務規則和資料語意的詞彙表
- 產品專屬方法，包括會影響系統行為的計算方法
知識系統
從組織可信賴的知識開始撰寫規格。
知識系統是規格優先交付（Spec-First Delivery）的核心產物，將產品、領域、工程、品質、安全與營運知識隨軟體一併交付。它保留可持續沿用的產品知識，讓其他合資格的參與者在進行重要變更前無須重新摸索。
知識系統中應與軟體一同交付的組成部分。
在界定工作前，先整理規格撰寫者所需的知識。
並非每項變更都需要以下所有資料。變更負責人應明確指出哪些知識相關、哪些來源具有權威，以及哪些問題仍需要由適當的人作出決定。
組織脈絡
說明系統如何支援業務，以及誰對其業務意義和相關決策負責。
- 系統所支援的業務職能、流程、服務或能力
- 持份者、決策負責人，以及各職能承擔的責任
- 影響變更的政策、法律責任、內部控制和營運承諾
- 已知風險、事故、支援問題，以及從正式環境取得的經驗
架構與介面
充分描述現有系統，讓技術決策有可靠依據。
- 系統責任、架構決策和不可改動範圍
- 資料模型、生命週期規則、相容性要求和遷移需求
- 外部介面、契約、相依關係、處理次序和錯誤行為
- 既有測試、可觀測性、部署、回退和復原資訊
要求與限制
明確說明建議工作必須遵守什麼，以及不得變更什麼。
- 安全、私隱、可靠性、效能、無障礙和營運需求
- 必須保留的行為、相容性責任，以及不可改動的系統部分
- 已核准的技術選擇、程式碼儲存庫指引、工程標準和交付限制
- 驗收條件，以及具明確責任歸屬的角色在驗收成果前需要檢視的證據
討論與決策歷程
保留形成目前規格的推理過程，讓後續工作可以查閱。
- 記錄需求、問題、選項、假設及未解事項的討論文件
- 過往決策、曾被否決的替代方案、已核准偏差及其理由
- 較早的規格、驗收證據、實作歷程和交付所得知識
- 目前變更與其所依據知識之間的連結
程式碼
程式碼是判斷系統實際行為的最終依據。
- AI 程式開發代理需要存取程式碼，才能檢視現有行為和既有實作模式
- AI 程式開發代理需要存取程式碼，才能找出相依關係並評估建議變更可能帶來的影響
- 程式碼會影響討論、需求分析和規格撰寫。若無法檢視程式碼，文件中的需求可能根本無法實作
- 當 AI 程式開發代理以包含程式碼庫在內的完整知識系統撰寫規格時，它可以比較預期成果與現有系統，協助產生可實作的規格
撰寫規格
有效的規格會在猜測變成程式碼之前先把它減到最低。
以下做法適用於產品負責人、產品經理、專案經理、業務分析師、開發主管、架構師、軟體工程師、QA 工程師、安全工程師、可靠性工程師，以及任何撰寫重大需求或技術方向的人。
持續請 AI 提出問題，直到再沒有重大問題。
請 AI 對照相關知識檢視需求，找出正常與例外流程、假設、缺漏資訊、衝突、相依關係和驗收問題。目標是在任何人開始實作前，盡量減少猜測。
討論揭示新資訊時，同步更新知識系統。
把新確認的資訊記錄在適當的知識來源。若更新屬於另一職能負責的文件，應請文件負責人審查。產品行為、資料、安全、可靠性、營運或架構問題，應交給負責相關決策的同事處理。
逐行審查規格。
具明確責任歸屬的審查者應檢視每項陳述是否正確、完整，並核對工作範圍、限制、必須保留的行為、相依關係和驗收條件。他們需要消除模糊之處、找出尚未完成的決策，並記錄由誰作出決定。
清楚區分不同規格的責任範圍。
功能規格描述所需行為、使用者、業務規則、例外情況和驗收條件，並避免加入不必要的技術選擇。非功能規格可以說明安全、可靠性、效能、營運和技術需求，但不應代替軟體工程師作出實作設計決策，除非相關決策已經明確審查並指定負責人。
保留重大技術決策的完整歷程。
記錄重大技術選擇、曾考慮的替代方案、決策負責人、理由、後果，以及需要重新檢視決策的條件。後續撰寫者和審查者不應再花時間追查組織為何選擇目前做法。
規格成為知識
經核准的規格是可重用的組織知識。
經審查的規格會納入知識系統。它們協助工程師規劃實作、協助 AI 理解獲授權執行的工作、協助審查者判斷成果是否符合規格，也協助產品和品質角色判定成果是否符合已同意的條件。
交付後，產出的程式碼、決策、證據、偏差和營運所得知識都應更新同一套系統。這種延續讓另一位合資格的參與者可以繼續工作，而不必從個人記憶或只看原始碼重新拼湊關鍵意義。