功能講完了，事情還沒完

區塊 4 把功能清單、優先級、Out of Scope 都確認完，照理說「要做什麼」已經很清楚了。但鼠勾以不會馬上跳去畫流程，它會在這裡停下來，再追問一輪看起來很瑣碎的問題：這個功能放在哪個系統做？資料存哪？要不要對接別人？

這一輪叫「規格基線」，是區塊 4 結尾的一張檢查表。它問的都是需求方PM 認為該由工程師決定、但工程師沒有答案就估不出工時的項目。

規格基線是什麼：把「限制」先講出來

先解釋一下名字。規格基線做的事，是正向定義每個功能的邊界數值：單檔上傳上限幾 MB、最多可以選幾個、查詢最遠能查到多久以前、單筆交易上限多少。

它跟後面區塊 7 的「例外情境」是一對。差別在方向：

• 規格基線正向講「限制是什麼」：單檔上限 5MB。
• 例外情境負向講「違反限制時怎麼辦」：超過 5MB 就提示並擋下來。

這個順序不能反。沒有先定出「5MB」這個基線，區塊 7 根本寫不出「超過怎麼處理」，因為連超過的門檻在哪都不知道。所以規格基線是例外情境的前置依賴，鼠勾以選擇在區塊 4 一氣呵成把它問掉。

五題系統決策：不分功能，每個都要問

規格基線的第一段，是五題不分功能類型、所有需求都要問的系統決策。它們長這樣：

1. 主執行系統：這個功能放在哪個系統做？使用者看到的入口在哪？
2. 後台管理介面：需要給管理員或客服用的後台嗎？放哪？
3. 資料儲存：資料存在哪？是現有的資料表還是要新增？
4. 外部系統介接：需要對接其他系統的資料或 API 嗎？
5. 排程/批次：有沒有定時或批次處理的部分？

這五題的內容看起來很瑣碎，但每一題都會影響工時，差別集中在同一組判斷上：沿用現有還是新建。

「在現有 App 加一個頁面」跟「新建一套獨立系統」，工時可能差到十倍。同一個功能，如果能掛在既有後台、用現成的資料表、走既有的金流對接，大約兩週可以完成；如果每一項都要新建，就會變成兩個月的專案。需求方PM 是從使用者體驗的角度描述功能，通常不會意識到這條成本差異。鼠勾以先把它問出來，工程師拿到 PRD 才不用再回頭追問一輪。

需求方PM 當然常常答不出來，例如「我哪知道要不要新建資料表」。這時候鼠勾以不會硬逼，會提供一個「待技術評估」的選項，記進待確認清單並備註「留給 SA 或系統架構師確認」。它的目標是把「這題需要被討論」標記出來，避免整題被跳過，而不是要求需求方具備工程判斷。

十類功能，動態帶出對應的規格

五題系統決策問完，接著是依功能類型帶出的專屬規格。鼠勾以內建了十類常見功能：表單、選擇、查詢、交易、預約、上傳、通知、權限、個資、匯出。

它會先判斷區塊 4 收集到的功能命中哪幾類（可以同時命中多類），再只帶出相關的題目。例如使用者要做一個「理賠檔案上傳」，它就會自動冒出上傳類的那組：

單檔大小上限幾 MB？
一次最多上傳幾個檔案？
允許哪些格式？
上傳後保留多久？
上傳後可以刪除或換掉嗎？

這就是動態帶出的用意：只問跟這個功能有關的那幾題，不把十類、上百個規格項目全部丟給使用者。一個純查詢功能不會被問到「手續費怎麼算」，一個通知功能也不會被問「電子簽名要不要浮水印」。整份檢查表如果照單全問，使用者多半答到一半就放棄了。

每一類問完，會收斂成一張功能規格表，長這樣：

最右邊那欄是刻意預留的：每一條規格都先掛上「違反時對應到哪條驗收標準」，等區塊 7 寫例外情境時可以直接接上，不會漏掉。

5MB 是誰說了算

這裡要特別講清楚一件事，免得誤會：表上那個「5MB」，不是需求方PM 隨口喊了就定案，它是一個「提案」，最後要跟 SA 一起敲定。

規格基線的數字大致分兩種。一種是業務面的，例如「商品照片大概多大、使用者通常傳幾張」，PM 有實際業務經驗，由他先提一個 5MB 是有依據的。另一種是技術面的：同一個 5MB 會牽動儲存成本、上傳逾時、要不要壓縮、怎麼掃毒，這些要 SA 評估。SA 可能回覆沒問題，也可能回覆「要做到 5MB，上傳得改成分段，工時要加」。

而業務面這邊，光講一個數字其實還不夠，最好把「這些照片是怎麼來的」也一起講，工程師才好評估。同樣是「上傳照片」，來源不同，背後完全是兩回事：

• 手機相機拍的原圖：現在動輒 3 到 8MB、解析度高，可能要考慮壓縮跟 EXIF 資訊。
• 螢幕截圖：通常小很多，需求完全不同。
• 裝置與系統：用哪種手機、iOS 還是 Android，甚至會影響預設的圖檔格式（像 HEIC 就得另外處理相容性）。

所以鼠勾以問的不只是「幾 MB」，還會接著問「這些照片通常是怎麼產生的、用什麼裝置」。來源講清楚，SA 才有判斷依據，能評估 5MB 夠不夠、要不要轉檔。

鼠勾以在這裡的角色很明確：它不替 PM 決定 5MB，只負責把「5MB 需要被討論」這件事標記出來。能先給的就填一個起始值，涉及技術判斷或答不出來的就標「待技術評估」留給 SA。這樣做的效果是，會議上討論的是一個具體提案，SA 有東西可以評估、可以修正，不必從空白開始問起。這也呼應 Day 1 提過的原則：規格由兩邊一起敲定。

為什麼夾在區塊 4 和區塊 5 之間

規格基線的位置是刻意安排的：放在區塊 4 結尾、區塊 5 流程圖之前。

理由有兩個。第一，它是功能範圍的延伸。功能講的是「要做什麼」，規格基線講的是「做到什麼程度」，兩者接在一起問最順。第二是距離。規格基線如果排到很後面才問，使用者已經忘了當初那個功能的情境，得重新回想一輪；如果排得太前面、和功能盤點混在一起，又會打斷「先把功能列完」的節奏。放在功能確認完、還沒開始畫流程的這個點，使用者對功能的記憶還很清楚，補問規格的成本最低。

小結

規格基線是區塊 4 結尾的一張檢查表，內容看起來瑣碎，但每一題都會影響工時。它先用五題系統決策確認「沿用還是新建」，再依十類功能動態帶出對應的規格項目，最後收斂成一張預留了例外情境接口的規格表。它的用途，是讓工程師拿到 PRD 時不必再回頭追問一輪，同時替後面的區塊 7 準備好觸發條件。

Day 17 進到區塊 5「The How」：當功能跟規格都定了，怎麼跟使用者一起把「使用流程」畫成一張連工程師都看得懂的 Mermaid 流程圖，而且只用兩種節點。

參考資料

• Boehm, B. W., & Papaccio, P. N. (1988). "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering, 14(10), 1462–1477.（缺陷越晚發現、修正成本越高，規格沒定清楚的代價會延後爆發）https://doi.org/10.1109/32.6191
• Méndez Fernández, D., et al. (2017). "Naming the Pain in Requirements Engineering." Empirical Software Engineering, 22, 2298–2338.（不完整需求與專案延期、超支的關聯）https://doi.org/10.1007/s10664-016-9451-7
• "Using LLMs in Software Requirements Specifications: An Empirical Evaluation." (arXiv 2404.17842).（結構化規格對 AI 產出品質的影響）https://arxiv.org/abs/2404.17842

這是 iThome 鐵人賽系列文章。明天見。