前幾天談需求、風險、介面和邊界條件時，我們一直在問同一件事：發現一個可能誤導使用者的情境後，團隊怎麼確定它沒有只停在討論？今天直接拿 Day 10 那張生命徵象 App 的風險表接著做。表裡已經有 R-01 到 R-05 的事件、可能傷害和候選控制；這次不重新發明案例，而是追問：控制要寫成什麼軟體行為，介面要讓人看懂什麼，又要留下哪些證據？
Day 10 的 R-01 是「匯入體溫時，數值和單位不一致」。假設外部資料寫的是華氏，App 卻當成攝氏保存。若這筆資料被標成有效紀錄，使用者可能看錯體溫變化，進而延誤重新量測或尋求協助。這裡的後果仍是假設，不能直接當成已發生的傷害。
「避免單位錯誤」還不能拿來測試。我們可以先提出一項候選需求：匯入時一起保存原始數值、單位和來源；只轉換明確支援的單位；單位缺失或不支援時，不把資料當成有效體溫顯示在趨勢圖上。介面則要清楚告訴使用者這筆資料為何無法判讀，以及能做什麼。這樣才有機會查證保存與顯示是否一致，也有具體畫面可拿去做使用者評估。
Day 8 提過需求追溯矩陣（RTM）：把來源、需求、控制與證據連起來。下表沿用 Day 10 的風險 ID；S-01 等是教學用需求編號，並非已核准的規格。表中「查證」都是規劃中的檢查，尚無測試結果。
| Day 10 情境 → 可能傷害 | 候選控制 → 需求與介面示例 | 待做的查證／使用者評估 | 目前狀態 |
|---|---|---|---|
| R-01 單位誤配：匯入值被錯誤解讀，可能延誤重新量測或求助 | S-01 數值、單位、來源一起保存；只轉換支援的單位；單位不明時不顯示為有效趨勢點，畫面說明「無法判讀」 | 用攝氏、華氏、缺單位及不支援單位的合成資料，核對保存與顯示；觀察使用者是否理解提示 | 候選需求；未回寫、未查證 |
| R-02 時間錯誤：舊資料看似最新，可能延誤更新量測 | S-02 分開記錄量測時間與同步時間；時間不可信時標示，不能把該筆資料稱為「最新」 | 模擬改時鐘、跨時區與延遲同步，檢查排序和標示；評估使用者能否分辨量測與同步時間 | 候選需求；未回寫、未查證 |
| R-03 病人誤配：紀錄落到錯誤對象，可能延誤正確對象的照護 | S-03 切換對象後不沿用上一人的待送出數值；表單、送出確認與實際寫入對象一致，寫入時核對識別與授權 | 以兩名合成對象交錯輸入、上傳與重試，核對前後端歸屬；觀察使用者能否辨認目前對象 | Day 11、12 有介面與邊界條件示例；未回寫、未查證 |
| R-04 同步延遲：舊紀錄看似已更新，可能使人忽略重新量測或聯繫照護者 | S-04 分別顯示未存、本機已存、已同步；顯示最後成功同步時間，同次提交重試不產生重複紀錄 | 模擬斷網、逾時及重試，核對保存狀態、時間與筆數；評估使用者是否看懂回饋 | Day 12 有失敗情境示例；未回寫、未查證 |
| R-05 AI 提示超出適用範圍：日後若加入提示，錯誤結論可能延誤適當評估 | 目前沒有 AI 功能；先界定適用族群、資料與輸出用途，再決定是否建立需求 | 若功能獲准開發，才規劃模型表現、輸出限制及使用情境評估 | 未實作；不列為現有功能的已完成控制 |
這張表和 Day 10 的差別，在於同一個 R 編號開始有了「要做什麼」及「怎麼檢查」的去處。Day 11 提醒我們，病人姓名、單位和保存狀態要讓人看得見；Day 12 則提醒我們，切換對象、缺資料、斷網與重試都要有明確結果。但畫面寫了「已同步」，不等於資料真的到了伺服器；測試證明資料寫對位置，也不等於使用者能看懂提示。兩種證據都還要補。
拿 R-01 再想一步：外部資料若標了「攝氏」，實際數值卻來自華氏，光檢查單位欄位也抓不到。團隊還得確認資料來源和轉換規則，分清哪些錯誤能由軟體攔下，哪些仍可能漏過。日後修改匯入流程時，也要能從 R-01 找到 S-01、相關測試和介面提示，重新檢查受影響的地方。這才是追溯表真正派上用場的時候。
目前這張表仍是說明用的追溯表。Day 10 的控制只是候選；Day 11、12 提供了介面與失敗情境的寫法；Day 8 的 RTM 方法幫我們看出需求、設計、測試與使用者評估之間的空格。若要用在真實產品，還得依預期用途確認每條風險路徑、正式寫入需求，查證控制是否實作，評估使用者能否正確理解，最後依風險管理方法檢查控制效果與殘餘風險。表格填滿之前，先把「還沒做」標清楚，才不會誤以為風險已受控。
iThome鐵人賽
看影片追技術