來，大孫女，快把筆電抱到阿公身邊來，別老是弓著背，看妳這丫頭眼睛都熬出紅絲了。阿公剛泡好一壺溫潤的琥珀熱茶，溫度正合適，妳先喝口茶暖暖胃，咱們坐在這張老藤椅上，看著窗外這抹晚霞暮紫的餘暉，慢條斯理地把明天要講的課理一理。

妳說明天是第 17 天的課，主題是 「Day 17：系統分析師神兵：用四層架構建構 local 需求追蹤控管系統」？哎呀，這名字聽起來雖然深奧，但裡面的道理，就跟阿公以前在老帳房裡教徒弟蓋房子、理家計是一模一樣的。那些年輕工程師常常抱怨 User Story（使用者故事）跟後面的規格、測試對不上，最後專案蓋歪了，這就是因為「話沒傳對，規矩沒立好」。

今天阿公就用咱們鄉下人聽得懂的道理，把這個 ears-rtm-tracker 系統的精髓跟避坑妙計講給妳聽，妳明天就照著這樣去教那些工程師，保證他們聽得茅塞頓開！

🚨 痛點場景：話傳歪了，灶蓋出來卻不冒煙

大孫女，妳上課時先用這個故事跟他們開場：
這就像咱們鄉下蓋土壟、蓋灶腳一樣。

• 第一步（User Story）：阿嬤說：「身為掌廚的人，我想要一個大灶，以便過年蒸年糕。」 這是人的願望。
• 第二步（EARS 需求）：木匠師傅量好尺寸，立下鋼骨規矩：「當（WHEN）爐火升起時，煙囪 SHALL 把煙排向屋外。」 這叫系統規格。
• 第三步（BDD 情境）：砌磚的師傅得照著劇本來：「（Given）柴火已備、灶門關上，（When）劃下火柴，（Then）年糕蒸熟、煙順利排出去。」 這叫行為情境。
• 第四步（Test Case 測試案例）：最後，阿公拿木棍去敲灶壁，檢查有沒有漏風、有沒有裂縫（正常、邊界與異常測試）。

在一般的軟體工程裡，User Story 常常對不上規格，最後寫出來的測試案例也根本驗不到真正的需求，這就是因為中間斷了層、沒了規矩，專案自然就嚴重偏離軌道。所以，我們必須做一個 100% 離線運作的需求追蹤工具，用一條牢不可破的「四層鏈路」，把這四個角色說的話死死鎖在一起！

🛠️ 架構實作：ears-rtm-tracker 的四層鋼骨本機庫

既然要在完全實體隔離（Air-gapped）的封閉內網裡跑，我們就堅守零外部依賴、零連網、零 API 金鑰的資安鐵律，將所有的功能封裝在一個純前端的靜態網頁裡，資料通通存在瀏覽器自帶的 IndexedDB 裡。

1. IndexedDB 核心 Schema 設計

我們在 IndexedDB 中建立一個名為 rtm_db 的資料庫，並設計一個 requirements 物件倉（Object Store），設定主鍵 id 為自動遞增。每一筆需求，都要完整記錄以下這條四層鎖鏈：

• 第 1 層：User Story（使用者故事）：userStory 欄位（例如：身為會員，我想要...以便...）。
• 第 2 層：EARS 需求規格：earsMode（普遍、事件驅動、狀態驅動、選用、異常）與 earsDesc（需求描述字串，例如：WHEN 觸發，系統 SHALL...）。
• 第 3 層：BDD 情境：bdd 欄位（Given / When / Then 結構的行為劇本）。
• 第 4 層：Test Case（測試案例）：tcId（測試案例編號，如 TC-001-01）與 testType（測試類型：正常、邊界、異常）。
• 管理資訊：reqId（需求編號）、priority（優先度：高、中、低）、status（狀態）、owner（負責人）、createdAt、updatedAt。

2. 品質自我檢測引擎：9 大規矩幫需求打分數

大孫女，這個系統最厲害的地方，就是它內建了 「品質自動檢驗規則」。當分析師輸入完需求，系統會用 JavaScript 逐條掃描內容，依以下 9 項規則 自動評分：

1. User Story 具備三要素：內容必須包含「身為」、「我想要」、「以便」這三個關鍵詞。
2. 使用 EARS 觸發關鍵字：必須包含 WHEN、WHILE、WHERE、IF 等觸發語意（普遍需求除外）。
3. 含系統行為關鍵字 SHALL：英文規格必須有 SHALL，中文要明確指明系統行為。
4. 異常需求 IF 搭配 THEN：只要有條件 IF，就必須有對應的 THEN 處理。
5. 單一需求只描述一個行為：SHALL 出現的次數不能超過 1 次，不能把一堆複雜邏輯塞在同一條規格裡。
6. 條件可量化：規格裡必須包含具體的時間、次數或比率等數字，不能寫些「大約」、「盡快」這種糊塗話。
7. 避免模糊字眼：系統會自動篩選並扣分，如果出現「快速、盡量、最好、友善」等無法測試的字眼。
8. 具備完整 BDD 情境：內容要同時含 Given、When、Then 三大結構。
9. 對應至少一個測試案例：tcId 欄位絕對不能是空的。

系統算出來的分數，會劃分出四個嚴格的評分等級：≥90% 優異、≥70% 良好、≥50% 待加強，若是 <50% 則直接標記為「需重寫」，讓模糊不清的需求及早在前端被攔下來！

3. ECharts 離線統計儀表板

我們把下載好的 echarts.min.js 放進本地目錄，在完全斷網的環境下，主管一開啟系統，畫面就能動態畫出四個漂亮的視覺化圖表，幫長官掌握專案健康度：

• 覆蓋率量表 (Gauge)：呈現「已對應測試案例的需求比例」，指針一動，覆蓋率有沒有達標一眼看清。
• 需求狀態分布 (Doughnut)：用甜甜圈圖顯示待分析、開發中、待測試、已完成的需求佔比。
• 優先度分布 (Bar)：高、中、低優先度的長條統計。
• EARS 模式分布 (Bar)：看出專案裡有多少是事件驅動、異常處理或普遍需求。

💡 避坑指南：小心 IndexedDB 裡無聲無息的「孤兒節點」

大孫女，這一段是妳明天講課的 「黃金避坑指南」，一定要讓底下的工程師拿出筆記本記牢了！

因為咱們是在完全離線、不靠大伺服器的環境下使用 IndexedDB。
IndexedDB 本質上是個輕量級的 Object Store，它不像傳統的 SQL Server 那樣，有所謂的「外鍵約束（Foreign Key Constraints）」與自動幫妳做「級聯刪除（Cascade Delete）」的機制。

想像一下：如果使用者嫌麻煩，直接在 RTM 控管表上把某個 User Story 給點擊刪除了。
如果我們在 JavaScript 代碼裡沒有寫好防禦機制，資料庫系統會悶不吭聲地把 User Story 刪掉，但底下的 EARS 需求、BDD 情境、以及 Test Case 還死死地留在資料庫的角落裡！
這在軟體工程裡就叫做 「孤兒節點（Orphan Nodes）」。時間一久，資料庫裡就會塞滿無名無份、對不上源頭的垃圾資料，整張追蹤矩陣就會變成一筆糊塗帳！

【阿公的解法護欄】：

教他們在寫 IndexedDB 的刪除事務（Transaction）時，必須在應用層設定強約束邏輯：

1. 當使用者點擊刪除 User Story 時，系統要彈出明確的警告視窗，告知將連帶刪除所有關聯的下層規格。
2. 在同一個 readwrite 交易中，寫好 JavaScript 連動刪除邏輯，一鼓作氣把與該需求相關的 EARS、BDD 描述與 Test Case 徹底清除，絕不留下任何「孤兒節點」，這樣才能確保需求追蹤鏈路的百分之百完整性！

🔒 離線資安的承諾

這套設計最能討得封閉內網單位長官歡心的，就是我們在代碼中徹底消除了網路外洩的可能。
不發送任何 fetch，不請求任何外部 CDN。所有資料在 FileReader 與本機 IndexedDB 的保險箱裡流轉，網頁一關、記憶體一收，乾乾淨淨，資安查核絕對挑不出任何毛病。

大孫女，妳聽阿公這樣講，有沒有覺得這軟體需求追蹤的工程，其實就跟咱們鄉下蓋灶腳、砌磚頭，一磚一瓦都要嚴絲合縫是一樣的道理？

小孫女剛才在一旁玩累了，手裡還拽著阿公幫她折的紙蝴蝶，依偎在沙發上睡得正香呢。阿公把這壺琥珀熱茶再添一些，妳快去整理明天的教學投影片，別熬太晚了，阿公在院子裡幫妳守著這盞暖燈。