雙曲線提示您：看後求收藏（奇妙書庫www.qmshu.tw），接著再看更方便。
書包 網 。 想看書來
獲取反饋
在規範書付諸實現之前，越多的眼睛看到它，它就會變得越好，並且將來要求的返工也會越少。如果你想很容易就能獲得反饋，你也想別人很容易就能提出反饋，至少你要將規範書草稿放到SharePoint上，並進行變更跟蹤和版本控制。做得更好一點，你可以把規範書放到一個維基站點上去，或者貼在功能團隊主要活動區域的一塊白板上。
撰寫規範書的這個過程、反饋和變更管理需要有多正式呢？像我在前一個欄目討論的那樣（即本章的“停止寫規範書”那個欄目），正式的程度取決於溝通是否直接，以及溝通的“頻寬”有多大。在同一個共享區域、同一個時間、工作在同一個功能的人們，他們可以使用很不正式的規範書和過程；而在不同時區、不同時間、工作在不同功能的人們，他們則必須要有高度正式的規範書和過程。
不管怎麼樣，你想讓規範書隨時都可以修改，直到團隊認為它不需要再改為止。那你怎麼知道規範書不需要再改了呢？答案是，要等到測試團隊驗證規範書透過了所有的質量檢查。
整合質量檢查
這是我們目前正在使用的規範書最離譜的地方。各個部門不是把安全、隱私和許多其他問題當作質量檢查，而是把它們一節一節單獨地寫在了規範書中。這是個災難，原因是：
？ 規範書變得更大並且複雜得多。
？ 作者必須在各節中複製資訊。
？ 讀者對後面的節次重視不夠，導致嚴重的質量缺口。
？ 設計變得難以理解，因為它們的描述分散在多節之中。
？ 錯誤和缺口很容易被忽略，因為沒有一個節次對設計作了完整的描述。
？ 更新幾乎是不可能的，因為一個最新的改動會影響多個節次，牽一髮而動全身。
取而代之的是，採用適合於每一份規範書的質量檢查，它以一個清單的形式出現，並且每個人都能觸手可得。一開始的幾個檢查對於每個團隊都是一樣的：
？ 需求清楚、完整、可驗證、並與有效的應用範例關聯了嗎？
？ 設計滿足了所有的需求嗎？
？ 所有關鍵的設計決議都被解決並存檔了嗎？
接下去的一套質量檢查也相當基本：
？ 所有的術語都被定義了嗎？ ？ 有沒有相容性問題？
？ 安全問題解決了嗎？ ？ 故障和錯誤處理解決了嗎？
？ 隱私問題解決了嗎？ ？ 談到安裝和升級問題了嗎？
？ 使用者介面完全可達到嗎？ ？ 維護問題解決了嗎？
？ 為全球化和本地化準備好了嗎？ ？ 備份和恢復問題解決了嗎？
？ 對於響應和效能的期望是否清楚並可測量？ ？ 是否有足夠的文件用於支援故障檢修？
？ 原始碼插樁和可程式設計能力定義清楚了嗎？ ？ 有沒有潛在的問題會影響打補丁？
各個團隊還可以為他們自己或者他們的產品線增加更多的質量檢查，解決他們常常面臨的特殊的質量問題。
線上資料：規範書檢查清單（Spec ）。
這裡的關鍵是，設計節次對功能進行了完整的描述，而質量檢查保證了沒有東西被遺漏。是的，這意味著設計節次可能會變得非常龐大，以覆蓋所有需要涉及的領域。但這些領域不再是把功能按照每一個質量要求展開的累贅品（比如對話方塊的安全、對話方塊的隱私、對話方塊的可達到性等）。
取而代之的是，所有的領域將是功能的邏輯組成部分（比如應用程式程式設計介面、對話方塊、選單等）。重複消除了。每個功能組成部分完整地被描述出來，並且所有的質量要求都融合在了設計情境中。
作者注：一個奇怪而有趣的巧合：在本欄目發表之後的第二天，Office部門把他們的規範書模板做了簡化，只使用單獨的一個節次來描述設計，並且採納了我釋出的質量檢查清單。儘管我不能對這個改變邀功，但我的成就感著實得到了滿足。
書 包 網 txt小說上傳分享
差別在哪？
如果增加了所有的這些檢查和測試，你可能會懷疑我根本就沒有對規範書作出簡化。其實，這裡的最大改動是：
？ 節次的數量減少到了只剩下3個（需求、設計和問題）。
？ 設計在一個節次中得到了完整的描述。
