團隊如何交付正確的軟體 - ch8 - 提煉需求規格
團隊如何交付正確的軟體 - ch8 - 提煉需求規格
成功的團隊在討論關鍵實例後，不會直接使用原本的例子，他們會從中**提煉 spec(Refining the specification)**。他們會從關鍵實例中提取精華，將其轉化成清楚且明確的定義，並去除不相關的細節。
附帶實例的 Spec. 即為驗收測試
一個良好的 spec ，再與實例結合後，其實就是有效的驗收測試所描述的功能
一個優質的需求規格範例
免費送貨服務
- VIP 用戶購買一定量的書籍後，為其提供免運費服務。免運費服務不提供給普通用戶。
- 要獲得免運非服務必須要購買至少五本書籍
實例
| 客戶類型 | 購物車中的產品 | 送貨服務 |
|---|---|---|
| VIP | 5 本書 | 免費、標準 |
| VIP | 4 本書 | 標準 |
| 普通 | 10 本書 | 標準 |
| VIP | 5 台洗衣機 | 標準 |
| VIP | 5 本書、1 台洗衣機 | 標準 |
提煉需求規格時需要關注的要點
理想的情況下，附帶實例的 spec 應該從業務角度明確地定義所需的功能，而不是去定義系統該如何運作，在完成了功能之後， spec 將會成為系統的說明文件
好的 spec 應該要符合下面所說的要點：
實例要精確可測
spec 必須是衡量成功與否的客觀標準，他必須包含可驗證的資訊。
腳本不是需求規格
spec 解釋系統在做什麼，他盡可能以最直接的方式關注在業務邏輯上。 spec 叫剪短，也較容易理解。
:thumbsdown: - 不要使用程式的描述
提防關於系統應該如何工作的描述，想想什麼才是系統應該做到的事
需求規格應關注在業務的功能，而非軟體的設計
spec 不應該牽扯到軟體設計，他應該要能解釋業務功能，但對於軟體該如何執行則不該有任何規定，其目的有二
- 讓開發人員找出當下最佳的解決方案
- 便於未來開發人員改善他們的設計
:thumbsdown: - 避免編寫與程式碼緊密耦合的需求規格
- 與程式碼緊密耦合、密切反應軟體實作方式的 spec 會讓測試變得脆弱
- spec 如果出自於軟體實作內容，例如提及資料庫或是物件類別名稱。請重組 spec 避免使用此種類型的概念，才能讓 spec 更易於理解及維護
:thumbsdown: - 不要用臨時的解決方案來解決需求規格中的技術困難點（適用於：處理遺留系統時）
遺留系統（Legancy System）常常存有一些技術怪僻，如果此時將臨時的解決方案加入到 spec 中，往往會把 spec 綁定到實作細節上
:thumbsdown: - 不要深陷在 UI 的細節裡（適用於：處理 Web 專案）
與其糾結在 UI 的細節（應該是指樣式類的東西）中，不如考慮使用者在網站上的操作流程還來得更有用
需求規格應該是不言自明的
:thumbsup: - 使用敘述性的標題並使用短篇幅闡釋目標
標題應該要可以總結出該 spec 的意圖，並嘗試用不超過一段的篇幅去解釋 spec 的目標以及實例的結構
:thumbsup: - 展示給別人看並保持沈默
適用於：獨自邊些需求規格時
目的：檢視需求規格是否可以不言自明
你可以在對方看完你的 spec 後請對方闡述 spec 的意圖，看看是否有符合你所描述的真正意圖
:thumbsdown: - 不要過度定義實例
關鍵實例過多反而會讓看的人眼花撩亂、難以理解，且實際執行驗證的時間成本也會大增
不要試圖覆蓋所有的狀況
:thumbsup: - 由基本的範例入手，再逐步擴大（適用於：使用許多參數組合描述業務規則）
需求規格應集中在焦點上
一個 spec 應該一間單獨的事情：一條業務規則、一個功能，或單一程序中的一個步驟。
聚焦的 spec 有兩個好處
- 較為簡短 > 較好理解
- 更易於維護
:thumbsup: - 在需求規格中使用「Given - When - Then」語言
（或是 Arrange - Actual - Assert）
目的：讓測試更容易理解
一般來說，一個 spec 應該要聲明背景環境，指定一個單一的動作，接著定義預測的後置條件
:thumbsdown: - 不要在需求規格中明確設置所有相依關係（適用於：處理複雜的相依關係＼引用完整性時）
例如需要複雜配置的資料驅動專案中，物件通常不能被單獨建立
許多團隊會錯誤的將前置條件都放入 spec 中，雖然會讓 spec 更完整，但同時也互造成 spec 更加難以閱讀及理解
:thumbsup: - 在自動化曾中應用預設值
建立有效的物件是自動化曾的職責
自動化層可以預先使用合理的預設值來填充物件，並設置相依關係。
:thumbsdown: - 不要總是依賴預設值（適用於：有許多屬性的物件）
如果一個實例的關鍵屬性與自動化層提供的預設值相匹配，儘管可以省略，但明確定義出來仍然是明智的做法
需求規格應使用領域語言
功能性的 spec 對於使用者、業務分析師、測試人員、開發人員以及任何想要了解系統的人都相當重要。所以 spec 必須使用每個人都能夠理解的語言來編寫，且使用的語言必須有一致性（統一語言）
重點回顧
- 不要直接使用初始實例，要對他們提煉 spec
- 為了充分利用實例，最終的 spec 應該是精確的、可測的、不言自明的、聚焦的、以領域語言所編寫，且與業務功能相關
- spec 中要避免使用腳本，也要避免論及軟體設計
- 不要試圖覆蓋所有使用案例。 spec 不是用來替代組合回歸測試的
- 所有重要的使用案例，都得從一個範例開始設置，並逐步增加值得程式設計師及測試人員特別關注的例子
- 在 spec 、軟體設計以及測試中定義並且使用統一語言