需求規格實例化

需求規格實例化（Specification by example）也稱為實例化規格，簡稱SBE，是一種協作方法，利用擷取實際範例和說明，來定義軟體產品的需求和以業務為導向的功能測試，和其他方法用抽象的說明定義需求的做好不同。需求規格實例化常用在敏捷軟件開發上，特別是行為驅動開發（behavior-driven development，BDD）。此作法特別適合用來管理重大領域以及有組織複雜度的大型專案中的需求以及功能測試^[1]。

需求規格實例化也稱為實例驅動開發（example-driven development）、可執行需求（executable requirements）、允收測試驅動開發（英語：acceptance test–driven development）（ATDD^[2]或A-TDD^[3]）、敏捷允收測試（Agile Acceptance Testing）^[4]、測試驅動需求（Test-Driven Requirements、TDR）。

優點

高度抽象概念或是全新的概念在沒有具體實例時，很難讓人理解^{[來源請求]}。需求規格實例化的目的是要建構準確的理解，大幅減少軟體開發過程的回饋迴路、減少重工、提高產品品質、針對軟體變更有較快的交付時間、在軟體開發團隊不同角色（例如測試者、分析師和開發者）的活動可以比較一致^[1]。

以實例為單一事實來源

需求規格實例化中，很重要的是創建有關專案各層面資訊的單一事實來源（英語：single source of truth）。多半情形下，商業分析師（英語：business analyst）有自己的文件，會在其文件上進行相關工作，軟件開發者維護其自己的文件，測試者有另一份功能測試的文件，需要定期維護這些文件，在不同文件和不同版本之間同步，因此軟件部署的效能會大幅下降。若是短的迭代週期，維護一般需要每一週或是每兩週一次。利用需求規格實例化，不同角色一起參與，知道大家所理解的內容，創建單一的事實來源。實例可以清晰準確的說明，因此同一個資訊可以用來當規格以及業務導向的功能測試。在開發或是交付程中發現的新資訊（像是功能落差的澄清、缺乏需求或是需求不完整、需額外測試等）都可以加入這個單一事實來源中。因為這是唯一一份有關功能的事實來源，在交付週期中，不需再維護、翻譯或是詮釋相關資訊。

若應用在需要變更的情形下，一組良好的實例可以有效的成為軟體功能的規格，以及業務導向的驗收測試。在變更實施後，有實例的規格成為文件，說明已有的功能。隨著這類文件可以自動化驗證，在其頻繁驗證的過程中，這類文件就是軟體業務功能的可靠資訊來源。為了區分這類文件以及傳統的列印文件（很快就會過期）^[4]，有實例的完整規格會稱為活文件（Living Documentation）^[1]。

重點實務

應用需求規格實例化的團隊常常會進行以下的實務^[1]：

• 從目標推導專案規模
• 規格協作：透過整個團隊的規格工作坊、較小的會議或是電話會議評審。
• 用實例來描述需求
• 完善規格
• 以實例建立自動化測試
• 時常用測試確認軟體情形
• 從有實例的規格開始，演進文件系統，以支援後續的開發。

應用需求規格實例化的軟體團隊一般會花5%至10%的時間完善產品backlog、包括規格協作、用實例來描述需求和完善實例^[3]。

實例映射

實例映射（Example Mapping）是簡單的技巧，可以在短時間帶領對話，推導允收準則。此作法將故事拆解為以需求規格實例化表示的規則和範例，在BDD圈有許多人使用^[5]。

適用性

一般會將需求規格實例化應用在有相當組織複雜度和領域複雜度，從業務領域觀點瞭解需求或溝通會造成問題的專案。需求規格實例化不適用在純技術問題，或是其困難度不是在瞭解知識或溝通知識上的專案。有使用需求規格實例化的領域包括有銀行投資、金融交易、保險、機票預訂、線上遊戲或是比價^[1]。也有記錄提及將需求規格實例化用在核電廠模擬計劃^[3]。

基於共享範例的測試適合歸類在：以從業務角度支援團隊交付軟體的測試類別中（可參考Agile Testing Quadrants^[6]）確保所建構的是對的產品。這類測試無法取代以純技術觀點看待軟體系統的測試（這類測試會評估軟體是否以正確的方式建構，這類測試包括單元測試、模組或是技術整合測試），或是一些在產品完成後進行的測試（例如滲透測試）。

歷史

最早有紀錄的，用實例作為單一事實來源、需求和自動化測試的軟體專案是WyCash+專案，用沃德·坎寧安在1996年的論文《A Pattern Language of Competitive Development》^[7][8]。Specification by Example的名稱是由馬丁·福勒在2004年所提出^[9]。

需求規格實例化是源自極限編程在1997年提出的Customer Test^[10]實務，和領域驅動設計在2004年提出的Ubiquitous Language^[11]，其中使用了Weinberg和Gause^[12]在1989年提出，以黑箱測試為需求的概念。

自動化

要成功的將需求規格實例化用在大型專案，需要頻繁的用大量的實例來測試軟體功能。實際上，這需要可以自動化進行以實例為基礎的測試。常見的作法是將測試自動化，但讓實例維持成團隊非技術成員或技術成員可讀取、可取得的形式，讓實例是單一事實來源。有許多測試自動化的工具可以支援此過程，其作法會將測試分為兩部份：規格和自動化層。測試的規格常會以文字、HTML格式出現，包括實例和輔助說明。自動化層連接待測的軟體系統。這些工具有

• Behat（英語：Behat (computer science)）
• Concordion（英語：Concordion）
• Cucumber（英語：Cucumber (software)）
• FitNesse（英語：FitNesse）
• Framework for Integrated Test（英語：Framework for Integrated Test）
• Robot Framework
• .NET的 Reqnroll和SpecFlow
• Gauge (軟體)（英語：Gauge (software)）