# 穩定使用案例 [產品意圖](/zh-tw/hub/product-intent)記錄產品為何存在，以及哪些成果和優先次序應引導產品決策。[使用者角色與參與者](/zh-tw/hub/personas-and-actors)則記錄哪些人會實質影響產品判斷，連同他們的目標、責任、權限和營運條件。在這些知識之上，交付團隊還要清楚知道：這些人經常要藉產品完成甚麼，而且產品演進後仍應達到甚麼成果。每項**穩定使用案例**就記錄其中一個持久目的。它可以引導多項交付作業；至於個別變更的詳細行為和驗收條件，則由後續規格界定。 ## 1. 定義與知識責任 **穩定使用案例**是一項可長期沿用的產品知識。它記錄一個或多個使用者角色的恆常產品用途、即使產品演進後仍可辨識的成果，以及維持該成果意義所需的產品層面條件。 每項紀錄由三項核心內容構成。 **恆常產品用途**說明使用者角色經常需要產品協助完成甚麼。Cockburn 提出的使用者目標層次，正好提供一個實用參考：它關注主要參與者希望透過系統達成的目標。Cockburn 指出，系統所支援的使用者目標，已能扼要概括系統功能。[^citation-01] 這個層次既能表達實質產品價值，也能把較細的步驟和技術子功能放在目標之下處理。 **可辨識成果**說明成功完成這項用途後，使用者應得到甚麼結果。即使介面、工作流程、服務拆分方式或基礎技術已經改變，受影響的使用者角色仍能清楚辨識這項成果。 **產品層面不變條件**列明哪些條件必須持續成立，才能保留用途和成果的原有意義。成果本身若可能容許幾種實質不同的產品解讀，紀錄便要列明相關條件；個別交付作業的規格再把適用行為寫得足夠精確，供團隊實作、驗證和驗收。 兩項判斷可以確認上述元素是否處於穩定使用案例應有的層次。 **內容不依賴實作方式**，表示恆常用途、可辨識成果和產品層面不變條件，在介面和實作方式大幅更換後仍然成立。Constantine 和 Lockwood 所說的本質使用案例，是以使用者意圖和系統責任為核心，抽象、概括而且不受技術限制的敘述；具體的使用者介面設計屬於另一個描述層次。[^citation-02] 穩定使用案例沿用同一原則。控制項、API 呼叫、畫面次序和實作模組通常屬於當前設計；只有代表重新設計後仍須保留的產品層面不變條件，才會寫進持久紀錄。 **紀錄可以長期沿用**，表示它一般可以橫跨多項交付作業。產品策略、使用者角色的恆常目標、案例所反映的運作模式、適用的不變條件或其他產品層面決策一旦改變紀錄的原有意義，團隊便應修訂紀錄。「穩定」描述的正是這兩項判斷共同形成的紀錄特質。 1. **恆常產品用途** 記錄一個或多個使用者角色經常需要產品協助完成的事情。 2. **可辨識成果** 說明即使介面和實作方式改變，使用者成功完成這項用途後仍應得到甚麼結果。 3. **產品層面不變條件** 列明維持恆常用途和可辨識成果意義所需的條件。 4. **不依賴實作方式** 持久紀錄只保留在不同控制項、工作流程、服務和實作技術下仍然成立的產品知識。 5. **可長期沿用** 紀錄可供多項交付作業沿用，直至產品層面決策改變紀錄的原有意義。 ## 2. 與產品意圖、使用者角色及參與者的關係 產品意圖、使用者角色與參與者，以及穩定使用案例，處理的是三個層次不同但彼此相連的問題。 1. **產品意圖** 說明產品為何存在，並以成果、優先次序、範圍和產品特質作為產品取捨的依據。 - **主要問題:** 產品為何存在，產品層面的決策應以甚麼為依據？ - **一般需要實質修訂的情況:** 產品目的、受眾、優先次序、範圍或產品特質有所改變。 2. **使用者角色與參與者** 記錄哪些人員和角色會實質影響產品判斷，連同他們的目標、責任、權限、限制條件和營運現況。 - **主要問題:** 誰會使用產品或以其他方式影響產品，他們在甚麼條件下工作？ - **一般需要實質修訂的情況:** 目標、責任、權限、工作流程、限制條件、痛點或營運現況有所改變。 3. **穩定使用案例** 記錄產品需要長期支援的恆常用途和可辨識成果，讓個別功能和實作方式改變後，這些用途仍然清晰可辨。 - **主要問題:** 產品應長期支援哪些恆常用途，甚麼成果足以辨識每項用途？ - **一般需要實質修訂的情況:** 使用者角色的恆常需要、可辨識成果、產品層面不變條件或參與案例的使用者角色有實質改變。 穩定使用案例**把相關的使用者角色目標整理成持久產品知識**。不過，使用者角色還記錄專業知識、權限、工作量、限制條件、痛點、依賴和其他營運脈絡。這些資料都可能影響交付，卻未必各自代表一項需要產品長期支援的用途。 目標導向設計以使用者角色推演情境，正好說明兩者如何連接。Cooper、Reimann、Cronin 和 Noessel 所說的脈絡情境，是一段廣泛而概略的故事：它描述使用者角色如何運用未來產品追求目標，並在進入詳細互動設計前，交代相關的環境和組織條件。[^citation-03] 因此，重點既包括使用者想完成甚麼，也包括哪些實際情況會影響他們達成目標。使用者角色在需求工程中的用途也不限於情境設計。一項涵蓋 78 項相關研究的系統性映射研究發現，使用者角色有助理解持份者、進行以人為本的需求工作，以及支援多類需求工程活動；建立、驗證和實際採用使用者角色，則仍有不少挑戰。[^citation-04] 穩定使用案例從這些人員脈絡中抽取需要長期支援的用途，無須在每項案例重複整份使用者角色紀錄。三者因而各有清晰責任：產品意圖確立方向，使用者角色反映實際營運情況，穩定使用案例則記下後續交付仍須認得的恆常用途和可辨識成果。 ```mermaid flowchart LR accTitle: 產品意圖、使用者角色和穩定使用案例構成互相連接的持久產品知識 accDescr: 產品意圖界定產品目的，營運使用者角色呈現有實質差異的人員和工作情況，穩定使用案例則把他們經常要完成的事情記錄成持久成果。 PI[產品意圖] P1[營運使用者角色 A] P2[營運使用者角色 B] U1[穩定使用案例 1] U2[穩定使用案例 2] PI --> U1 PI --> U2 P1 --> U1 P1 --> U2 P2 --> U1 ``` 後續交付作業可以同時載入相關使用案例和使用者角色。參與者既能看見產品必須繼續達到的成果，也能了解使用者的實際工作情況會如何影響當前需求的解讀。 ## 3. 使用者角色可追溯性與知識一致性 穩定使用案例與營運使用者角色之間是多對多關係。一個使用者角色可以參與多項案例；同一項案例也可以適用於多個工作情況有實質差異的使用者角色。 規格優先交付訂明一項明確的一致性要求： > **每項穩定使用案例都必須可追溯至至少一個營運使用者角色。** 一項恆常用途要成為穩定使用案例，至少要有一類使用者確實需要它，而這類使用者也要在知識系統中有所記錄。如果擬議案例找不到適用的使用者角色，結構化討論便要查明缺少了哪一部分產品知識。可能是使用者角色庫漏掉了真實使用者或工作情況；也可能所謂「使用案例」其實只是一項擬議功能、方便實作的安排，或已經過時的假設，背後沒有持久的使用者需要。 反過來檢查使用者角色，也會發現另一類缺口：某個重要目標可能沒有對應的穩定使用案例。部分目標本來就不屬於目前的產品意圖，或可在產品以外滿足；其餘目標則可能是知識系統一直漏記的恆常用途。 這類關係本身就能用來分析產品知識。Sim 和 Brouse 的概念開發流程，把使用者角色連接至觀點、情境、任務、目標和需求，藉此加深對使用者的理解，並及早找出遺漏的需求。[^citation-05] 使用者角色不再是各自孤立的文件，彼此關係也成為可以檢查的資料。穩定使用案例採用同一道理：缺少一項應有的連結，便會形成一個具體的產品問題，再交由有權決定的人處理。 ```mermaid flowchart LR accTitle: 使用者角色與穩定使用案例之間的可追溯關係是多對多關係 accDescr: 每項穩定使用案例都可追溯至至少一個營運使用者角色；一個使用者角色可以參與多項使用案例，而一項使用案例也可以服務多個使用者角色。 P1[使用者角色 A] P2[使用者角色 B] P3[使用者角色 C] U1[穩定使用案例 A] U2[穩定使用案例 B] U3[穩定使用案例 C] P1 --> U1 P1 --> U2 P2 --> U1 P2 --> U3 P3 --> U3 ``` 如何實作，可按產品規模決定。小型產品用連結或識別碼可能已經足夠；大型平台則可採用索引、導向 Skill、知識圖譜、需求工具，或按既定程序維護文件之間的關係。無論採用哪種方式，團隊都要能夠檢查使用者角色與使用案例的連結，並知道相關決定由誰負責。 ## 4. 具代表性情境與可辨識成果 研究、客戶支援、日常營運、現有工作流程、需求和領域知識，往往會帶出許多具體情況。團隊可用這些情況建立和檢驗穩定使用案例。幾個情況若都反映同一恆常用途、可辨識成果和產品層面不變條件，便可保留為同一案例下的具代表性情境。 情境式需求工程為這種做法提供了實用模型。Sutcliffe、Maiden、Minocha 和 Manuel 把情境視為使用案例中一條可能出現的行為路徑，再沿着路徑發掘更多需求。[^citation-06] 具體情境因而可以暴露遺漏的條件、例外、假設和差異，卻不必改變持久使用案例本身的抽象層次。 以 **AI 旅程規劃工具**為例。研究和營運資料可能提到惡劣天氣、交通取消、場地關閉、固定活動、分批抵達，或小組分途出發。產品團隊首先要問：這些情況分別反映哪些恆常用途？答案確定後，再把每個具體情況放到相應的穩定使用案例之下，作為具代表性情境。 1. **外在干擾發生後重新規劃部分行程** 外在事件打亂既定行程後，旅客需要重新安排受影響的部分。 - **參與案例的使用者角色:** 獨立旅客和團體旅程統籌員。 - **恆常用途:** 外在事件令既定計劃的部分內容失效時，恢復一個可行的行程安排。 - **可辨識成果:** 旅客取得一份連貫的修訂行程，妥善處理原有行程中受干擾的部分。 - **產品層面不變條件:** 未受影響的固定安排繼續保留；旅客在確認前能了解重要後果；修訂後的行程對參與旅客仍然連貫。 - **具代表性情境:** 惡劣天氣、交通取消、場地關閉，或其他令部分行程失效的外在事件。 2. **圍繞固定安排規劃行程** 某些安排的時間或參加者不能改動，旅客需要圍繞這些安排編排可靈活調整的活動和交通。 - **參與案例的使用者角色:** 獨立旅客和團體旅程統籌員。 - **恆常用途:** 圍繞時間或參與安排固定的活動，編排可靈活調整的行程部分。 - **可辨識成果:** 旅客取得一份可行計劃，彈性行程與固定安排互相配合。 - **產品層面不變條件:** 固定安排繼續清楚記錄；調整彈性部分時，仍保留固定活動所需的時間和參與安排。 - **具代表性情境:** 會議環節、演唱會、典禮、已預訂活動或有固定時間的會面。 3. **團體會合與分流** 各有不同路線的旅客需要會合同行一段，其後再分開前往不同目的地。 - **參與案例的使用者角色:** 團體旅程統籌員，以及各有本身行程部分的旅客。 - **恆常用途:** 協調旅客會合、同行和分流期間的共同及個別行程。 - **可辨識成果:** 每位旅客都有一份連貫計劃，清楚交代共同和個別行程。 - **產品層面不變條件:** 會合和分流地點繼續清楚記錄；共同路段有變時，每位旅客的個別固定安排仍獲保留。 - **具代表性情境:** 抵達城市不同、分批抵達、小組分途出發或回程目的地不同。 這些紀錄只確立日後仍須認得的恆常用途和可辨識成果。如何搜尋替代方案、顯示衝突、計算取消費用或讓旅客確認變更，留待有需要的交付作業處理，再由適用的功能規格、架構、專項規格、技術規格或測試規格作出具體決定。 要檢查紀錄是否不依賴實作方式，可以設想產品換上完全不同的介面和實作方式。恆常用途、可辨識成果和產品層面不變條件在替換後仍然成立，便代表紀錄處於穩定使用案例應有的層次。目前的控制項、服務呼叫、畫面次序和詳細錯誤路徑，則應由更具體的規格處理。 ## 5. 結構化討論與決策權限 團隊透過[結構化討論](/zh-tw/hub/requirements-increments-and-structured-discussion)建立穩定使用案例。討論時，參與者把使用者角色目標和具代表性情境，與產品意圖、現有行為、領域知識及目前需求互相對照，再判斷哪些恆常用途值得長期記錄。 討論應確立： - 要記錄哪項使用者角色目標，以及哪些使用者角色共有該目標； - 哪些已觀察情況屬於同一恆常用途、可辨識成果和產品層面不變條件； - 哪些差異已實質改變恆常用途或可辨識成果，需要另立穩定使用案例； - 要保留哪些產品層面不變條件，才足以維持用途或成果的意義； - 紀錄是否通過「不依賴實作方式」的檢查； - 紀錄是否包含應由後續規格負責的目前實作細節； - 每項擬議使用案例是否都有適用的使用者角色；以及 - 重要的使用者角色目標是否揭示遺漏的使用案例或另一項產品決策。 具體情境為討論提供可供檢驗的材料，決策權限則決定誰可以確認結論。某項恆常用途是否屬於產品，通常由產品負責人、產品經理或同等的產品決策負責人決定。領域參與者帶來營運知識，工程人員指出實作假設和技術後果，各專業職能則在本身的權限內作出判斷。 AI 可以整理候選情境、找出相關使用者角色、標示可追溯性缺口、比較成果，並草擬修改建議。哪些內容可成為權威產品知識，仍由具明確責任歸屬的人員決定。任何參與者都可以指出不一致之處；背後的產品或專業決定，則交由具備相關權限的角色處理。 ## 6. 與個別交付作業規格的關係 穩定使用案例先確立持久脈絡，個別交付作業的規格再據此處理當前變更。大部分交付作業都會改動與一項或多項穩定使用案例相關的行為，因此結構化討論要先以適用案例解讀擬議變更。功能規格其後界定當次要支援的行為、正常和例外路徑、無效狀態、使用者可見成果及驗收條件。其他專項規格按各自的專業責任補充決定；技術規格和測試規格則把經審查的條件寫成可執行、可驗證的內容。提案若會實質改變案例的恆常用途、可辨識成果、產品層面不變條件或參與案例的使用者角色，便須接受產品層面審查。 1. **生命週期** 兩項工作產物的修訂頻率不同。 - **穩定使用案例:** 可供多項交付作業反覆使用的持久產品知識。 - **功能規格:** 當一項交付作業需要具體功能行為時建立或修訂。 2. **目的與行為** 穩定使用案例先確立用途，功能規格再說明產品要支援的具體行為。 - **穩定使用案例:** 產品要長期支援的恆常用途、可辨識成果和適用的產品層面不變條件。 - **功能規格:** 正常路徑、例外、無效狀態、詳細的使用者可見成果，以及適用的行為條件。 3. **情境** 同一個具體情況，在兩項工作產物中有不同作用。 - **穩定使用案例:** 以具代表性情境檢查案例所述的恆常用途、可辨識成果和產品層面不變條件是否充分。 - **功能規格:** 把適用情境界定得足夠精確，以說明交付作業支援的行為。 4. **規則與不變條件** 產品的持久意義由穩定使用案例保存；個別交付作業所需的精確行為則寫入功能規格。 - **穩定使用案例:** 產品層面的不變條件；失去這些條件，便會實質改變使用案例的意義。 - **功能規格:** 足以用於交付和驗收的精確行為規則與條件。 5. **與實作的關係** 兩項工作產物都只保留必要的實作細節，但對行為細節的要求不同。 - **穩定使用案例:** 不依賴實作方式，用來指引產品方向。 - **功能規格:** 把行為寫得足夠明確；只有行為本身有所要求時，才指定技術實作方式。 6. **驗收責任** 個別交付作業負責訂明驗收細節；穩定使用案例保存恆常用途和可辨識成果。 - **穩定使用案例:** 不包含可執行的驗收條件。 - **功能規格:** 為交付作業提供具體驗收條件，以及驗證所需的資料。 早期使用案例方法也曾處理同一難題：既要保留使用者目標的整體視角，又要容許團隊逐步交付。Jacobson、Spence 和 Kerr 為此發展 *Use-Case 2.0*。完整使用案例保留系統應支援甚麼的整體視角；「使用案例切片」則選出一次交付可以實作的部分行為，並連接架構、設計、測試和使用者體驗。[^citation-07] 對穩定使用案例而言，值得借鑑的是持久產品脈絡與單次交付工作的分工。恆常用途、可辨識成果和產品層面不變條件保存在穩定使用案例；當次交付所需的行為、專業職能、技術和驗證決定則寫入規格體系。 在規格優先交付中，穩定使用案例的知識責任更為集中：它跨多項交付作業保存恆常用途、可辨識成果和產品層面不變條件；每項交付作業的規格體系則負責具體的功能、專業職能、技術和驗證決定。以 AI 旅程規劃工具為例，「重新規劃部分行程」可以一直沿用同一項穩定使用案例，而鐵路服務取消處理、取消費用預覽和全新行程介面，則可由不同交付作業逐一加入。 ## 7. 建立與維護程序 團隊可以直接從現有產品知識着手，無須先建成完整目錄。第一步是記錄目前交付真正依賴的使用者角色和恆常用途，形成足夠的持久脈絡。往後每次結構化討論發現重要缺口，再逐步補充和整理。 **準備穩定使用案例: 從使用者角色目標到持續維護的持久產品知識** 1. **識別適用的使用者角色目標** 從產品意圖和使用者角色庫着手，找出使用者經常需要產品協助達成的目標。 2. **收集具代表性情境** 從研究、客戶支援、日常營運、現有需求、工作流程、目前行為和領域知識收集具體情況。 3. **區分恆常用途** 多項情境若指向相同恆常用途、可辨識成果和產品層面不變條件，便歸入同一案例；用途或成果有實質差異時，才另立一項案例。 4. **寫明可辨識成果和不變條件** 說明成功完成這項用途後應得到甚麼結果，並列出維持該成果意義所需的產品層面條件。 5. **檢查是否不依賴實作方式** 設想以完全不同的介面、工作流程、服務和實作技術取代現有設計，確認恆常用途、可辨識成果和產品層面不變條件仍然成立。 6. **建立使用者角色可追溯性** 把每項穩定使用案例連接至至少一個營運使用者角色，並檢查重要的使用者角色目標是否都有對應案例或產品決定。 7. **確認權限並發佈紀錄** 由適當的產品決策負責人解決重大問題，完成審查後，再把紀錄放到人員和 AI 都能找到的知識路徑。 8. **按交付所得知識持續維護** 新情境、已驗收的交付作業、產品決定或營運轉變一旦改變原有意義，便重新審查受影響的使用者角色和使用案例，讓紀錄可以長期沿用。 整理紀錄時，較短期的決定應放進真正負責該項知識的工作產物。UI 控制項、工作流程次序、API 決定、模型提示、實作模組、錯誤訊息、門檻和可執行的驗收檢查都可能十分重要，但應由相應規格或實作文件處理。 恆常用途、可辨識成果、產品層面不變條件或適用的使用者角色若有實質改變，便要交由對應的產品或領域決策負責人處理。這項修訂門檻讓紀錄得以跨多項交付作業長期沿用。若新知識來自交付本身，則可透過[交付作業生命週期中的知識收斂](/zh-tw/hub/knowledge-convergence-across-the-increment-lifecycle)，把經確認的結果更新至權威現況知識。 ## 8. 參考表示方式 穩定使用案例可以採用不同格式。只要讀者能清楚查看恆常用途、參與案例的使用者角色、可辨識成果、產品層面不變條件、決策權限和相關連結，便符合規格優先交付的要求。 ```text 穩定使用案例識別碼： 標題： 恆常用途： 參與案例的使用者角色： 可辨識成果： 產品層面不變條件（如適用）： 具代表性情境： 相關產品意圖： 決策負責人： 選填情境群組： 選填來源資料： - 提出者： - 觀察或討論日期： - 參考資料： ``` `恆常用途`、`可辨識成果`和`產品層面不變條件`讓三項核心內容一目了然。`參與案例的使用者角色`建立必要的可追溯關係，一項案例可以列出多個角色。`具代表性情境`用具體情況檢查案例是否充分，同時保留案例本身的抽象層次。`相關產品意圖`指出案例服務哪項產品成果或優先次序；`決策負責人`則說明誰有權確認重大的解讀或修訂。團隊以三項核心內容檢查紀錄是否不依賴實作方式，再透過產品層面的修訂權限，確保紀錄可以長期沿用。`選填情境群組`只適用於已採用這層分類的大型目錄。 來源資料可按需要選填。穩定使用案例用來指引產品方向，並不承擔後續驗收證據的責任。不過，若記下誰提出案例、何時討論，以及案例源自哪項研究、支援個案或營運觀察，日後接手的人會較容易還原當時的脈絡。 以 AI 旅程規劃工具為例，紀錄可以寫成： ```text 穩定使用案例識別碼：travel-partial-replan 標題：外在干擾發生後重新規劃部分行程 恆常用途： 當外在事件令既定計劃的部分內容失效，讓旅客可以恢復可行行程。 參與案例的使用者角色： - 獨立旅客 - 團體旅程統籌員 可辨識成果： 旅客取得一份連貫的修訂行程，妥善處理原有行程中受干擾的部分。 產品層面不變條件： - 未受影響的固定安排會繼續保留。 - 旅客在確認前能夠了解重要後果。 - 修訂後的行程對參與旅客而言仍然連貫。 具代表性情境： - 交通取消 - 惡劣天氣 - 場地關閉 相關產品意圖： 即使實際旅遊情況改變，行程規劃仍然清晰易明並可靈活調整。 決策負責人： 產品負責人 選填情境群組： 行程受阻與復原 ``` 日後的功能規格可以另行決定如何偵測問題、選擇替代方案、計算費用、處理無法提供服務的情況，以及確認變更。只要這些細節沒有改變案例的恆常用途、可辨識成果、產品層面不變條件或參與案例的使用者角色，原有紀錄便可以繼續沿用。 ## 9. 驗證與就緒條件 驗證穩定使用案例，就是檢查現有知識是否足夠。合資格參與者應能從紀錄掌握產品要長期支援的用途，也要知道遇上哪類問題時，必須請相應的決策負責人作出更具體決定。 1. **恆常用途與使用者角色可追溯性** 每項穩定使用案例都列明一項恆常產品用途，並連接至至少一個適用的營運使用者角色。團隊亦會檢查重要的使用者角色目標，確認它已有對應案例，或已有產品決定把該目標列於目前產品意圖之外。 2. **可辨識成果** 同一案例下的具代表性情境都應對應同一項可辨識成果；用途或成果有實質差異時，便另立一項穩定使用案例。 3. **產品層面不變條件** 紀錄列出維持用途和成果意義所需的條件，內容既不重複成果，也不提前寫入個別交付作業的行為細節。 4. **不依賴實作方式** 即使目前的畫面、工作流程、服務和實作技術全部換成另一套設計，恆常用途、可辨識成果和產品層面不變條件仍然成立。 5. **長期沿用與修訂權限** 紀錄可供多項交付作業沿用；核心內容或參與案例的使用者角色有實質變動時，由紀錄所列的產品或領域決策負責人審查。 6. **與規格的分工** 紀錄保存恆常用途、可辨識成果和產品層面不變條件；詳細功能行為和可執行的驗收條件，由個別交付作業的規格負責。 7. **使用案例庫組織方式** 小型目錄保持簡單；只有當獨立檔案、情境群組或導向 Skill 確實有助查找和維護，大型目錄才加入這些結構。 8. **可查找性** 人員和 AI 參與者都能沿知識系統的一般路徑，找到權威紀錄及其決策負責人。 這些檢查把[不熟悉產品的參與者測試](/zh-tw/hub/knowledge-system-readiness-for-specification-first-delivery)延伸至穩定使用案例。一位沒有相關產品經驗的合資格參與者，閱讀產品意圖、適用的使用者角色和穩定使用案例後，應能說明產品服務哪些人、哪些恆常用途最重要、日後交付必須繼續達到哪些成果、維持哪些產品層面條件，以及重大不一致之處應由誰處理。 通過這項審查，代表紀錄已清楚交代足夠的持久脈絡。日後的交付作業可以從已確立的恆常用途出發，無須再從目前實作反推產品原意。新情境可能為現有案例補充證據，也可能揭示遺漏的使用者角色或使用案例；如果產品的根本需要已經改變，團隊便要實質修訂相關紀錄。 ## 10. 擴展穩定使用案例庫 一開始只需採用最簡單、又足以查找和審查的形式。小型產品可以把整份目錄放在 `docs/use-cases.md`，每項使用案例用一段簡短而清晰的紀錄，列出參與案例的使用者角色、恆常用途、可辨識成果、產品層面不變條件、具代表性情境和決策負責人。 目錄逐漸增長後，不同使用案例可能有各自的負責人、證據、審查歷程或載入需要，這時分拆檔案會更容易維護。團隊可以把 `docs/use-cases.md` 改成 `docs/use-cases/` 目錄，以 `docs/use-cases/README.md` 作為總索引和導向入口，再為每項穩定使用案例建立獨立的 Markdown 紀錄。 當案例多得難以用單層索引瀏覽，團隊可以加入**情境群組**。它把同一產品使用範疇的多項穩定使用案例歸在一起，方便查找；每項案例仍各自保留恆常用途、可辨識成果、產品層面不變條件、使用者角色可追溯性、權限和生命週期。情境群組只是一個選用的整理層，不是穩定使用案例定義的必要部分。 早期使用案例方法也有相近的分層方式。Cockburn 把使用者目標層次的使用案例，與更高層的摘要使用案例分開；摘要使用案例把多個使用者目標連接起來，提供較完整的脈絡。[^citation-01] 情境群組的責任更輕，只協助讀者和 AI 在大型知識系統中找到相關案例，既不新增產品需求，也不取代群組內的紀錄。 例如，AI 旅程規劃工具可以把「外在干擾發生後重新規劃部分行程」、「錯過接駁交通後恢復可行行程」和「替換未能提供的已預訂活動」，歸入「行程受阻與復原」群組。若產品只有幾項使用案例，維持單層索引反而更直接。 大型使用案例庫也可以採用[按需分層載入上下文](/zh-tw/hub/shared-knowledge-system)。當單靠檔案搜尋已不敷應用，團隊可選用 `use-case-directory` Skill，列出精簡摘要、情境群組和載入路徑。AI 代理先讀索引，再載入與當前問題相關的穩定使用案例，無須一次讀取整個目錄。 導向索引可以保持精簡，例如： ```md # 穩定使用案例索引 ## 行程受阻與復原 - `travel-partial-replan` – 在外在干擾後修改受影響的部分行程 - 載入：`docs/use-cases/travel-partial-replan.md` - 適用於：干擾處理、恢復行程、保留未受影響的固定安排 - `travel-missed-connection-recovery` – 錯過接駁交通後恢復可行行程 - 載入：`docs/use-cases/travel-missed-connection-recovery.md` - 適用於：錯過接駁、對後續交通的影響、恢復行程 ``` 這項 Skill 只負責導向，因此每項案例只需一段簡短描述。完整而權威的恆常用途、可辨識成果、產品層面不變條件、使用者角色關係和決策負責人，仍保存在穩定使用案例紀錄。[規格優先交付的知識系統就緒度](/zh-tw/hub/knowledge-system-readiness-for-specification-first-delivery)另行說明程式碼儲存庫根目錄下 `skills/` 的整體慣例、AI 程式開發代理的查找路徑，以及選用的符號連結相容安排。 以下範例展示一個規模較大、以程式碼儲存庫為中心的做法： - `product/`: 程式碼儲存庫範例，展示由多個檔案組成的穩定使用案例目錄，以及選用的導向 Skill。 - `docs/`: 按既定管治程序維護並供交付工作使用的產品知識。 - `use-cases/`: 單一 use-cases.md 檔案過大後，用來分別存放各項權威穩定使用案例的目錄。 - `README.md`: 穩定使用案例總索引，列出選用的情境群組、識別碼、簡短目的、負責人，以及權威紀錄的連結。 - `travel-partial-replan.md`: 外在干擾發生後修改既定行程受影響部分的穩定使用案例。 - `travel-missed-connection-recovery.md`: 錯過接駁交通後恢復可行行程的穩定使用案例。 - `travel-fixed-commitments.md`: 圍繞固定安排規劃可靈活調整行程元素的穩定使用案例。 - `skills/`: 在程式碼儲存庫根目錄維護的可重用導向程序。 - `use-case-directory/`: 大型穩定使用案例目錄可以選用的按需分層載入導向工具。 - `SKILL.md`: 精簡的使用案例索引、選用的情境群組、適用規則和載入路徑。 無論目錄大小，穩定使用案例都必須容易找到、按既定程序維護，並可靠連接至適用的使用者角色。單一檔案、多檔案目錄、情境群組和導向 Skill 只是不同規模的實作選擇；產品真正出現瀏覽或維護需要時，才逐步加入相應結構。 [^citation-01]: Cockburn, A. (2001). *Writing Effective Use Cases*. Addison-Wesley Professional. [出版社](https://www.informit.com/store/writing-effective-use-cases-9780201702255). [^citation-02]: Constantine, L. L., & Lockwood, L. A. D. (2000). *Structure and Style in Use Cases for User Interface Design*. In M. van Harmelen (Ed.), *Object Modeling and User Interface Design*. [PDF](https://citeseerx.ist.psu.edu/document?doi=923abcddf77983c50bc200302c8f8d155c4e7a8f&repid=rep1&type=pdf). [^citation-03]: Cooper, A., Reimann, R., Cronin, D., & Noessel, C. (2014). *About Face: The Essentials of Interaction Design* (4th ed.). John Wiley & Sons. [出版社](https://www.wiley-vch.de/en?isbn=9781118766576&option=com_eshop&view=product). [^citation-04]: Karolita, D., McIntosh, J., Kanij, T., Grundy, J., & Obie, H. O. (2023). *Use of Personas in Requirements Engineering: A Systematic Mapping Study*. Information and Software Technology, 162, 107264. [DOI](https://doi.org/10.1016/j.infsof.2023.107264). [^citation-05]: Sim, W. W., & Brouse, P. S. (2014). *Empowering Requirements Engineering Activities with Personas*. Procedia Computer Science, 28, 237–246. [DOI](https://doi.org/10.1016/j.procs.2014.03.030). [^citation-06]: Sutcliffe, A. G., Maiden, N. A. M., Minocha, S., & Manuel, D. (1998). *Supporting Scenario-Based Requirements Engineering*. IEEE Transactions on Software Engineering, 24(12), 1072–1088. [DOI](https://doi.org/10.1109/32.738340). [^citation-07]: Jacobson, I., Spence, I., & Kerr, B. (2016). *Use-Case 2.0: The Hub of Software Development*. Communications of the ACM, 59(5), 61–69. [DOI](https://doi.org/10.1145/2890778).