第4部分(第4/4 頁)

麼決定？風險和權衡都有哪些？（比如依賴關係。）

？ 後設資料：標題、簡短描述、作者、功能團隊、優先順序、成本和狀態。

就這些了！“狀態”後設資料可以是個工作流，也可以是個檢查清單，但不能太複雜。

“但威脅模型放在哪裡？還有隱私宣告呢？原始碼插樁或者效能度量呢？”我可以聽到你在提出這些要求。請你冷靜一下！這些條目屬於質量檢查，我在後面很快就會談到。規範書結構本身是簡單的，比實際需要的多一點或少一點都不行。這樣才能容易寫，也容易被人讀懂。

線上資料：規範書模板（Spec　）。

變得穩健

規範書必須是穩健的。它必須是可被驗證的，並且所有定義的功能需求和質量需求都能被滿足。你可能會問，“怎麼做到？！”但你說“怎麼做到？！”究竟是什麼意思？怎樣在第一時間驗證需求？那就要編寫測試，對嗎？對！這就是你怎麼寫出一份穩健的規範書的方法。在規範書的第一節中，當你列出功能和質量上的需求時，應該包含如下內容：

惟一標識 優先順序 功能或質量 簡短描述 相關應用範例 用於驗證需求的測試

如果你不能指明一個測試來驗證一個需求，那麼這個需求就不能被滿足，因此要把需求丟棄。不能丟棄？那好吧，重寫需求，直到它能被測試為止。

作者注：我相信，一個可靠的設計把“測試”和“需求”放在基本同等重要的地位。每個需求都應該有一個測試。每個測試都應該基於一個需求。這將導致：清晰而可被驗證的需求；更加全面的測試；一致的完成標準（即所有測試透過等於所有需求得到了滿足）；以及更好的設計，因為測試驅動的設計自然要更加簡單，更加內聚，具有更松的耦合。

書包　網　。　想看書來

獲取反饋

在規範書付諸實現之前，越多的眼睛看到它，它就會變得越好，並且將來要求的返工也會越少。如果你想很容易就能獲得反饋，你也想別人很容易