TDD系列文章到這邊，只是獨立介紹了測試與重構，接下來要介紹的部分，則是筆者認為TDD整個流程中，影響成敗的一環，也就是從user requirement break down到acceptance testing。

TDD可以幫助開發人員產出high quality的程式碼、物件、甚至模組，這些程式碼有高可維護性、可擴充的彈性，但使用者對程式碼的開發流程、工具、方法並沒有興趣，使用者只想滿足他們的需求，透過我們的系統提高生產力、解決問題，或是創造更多的利潤。

這也是這整個系列文章的主旨：一切都是為了滿足使用者需求而存在。

這篇文章會先從使用者需求管理的方式開始說明，也將常見的幾種方式，如user story, use case，以及功能清單三種，簡短地做個比較。

瞭解user requirement之後，後面我們才能開始進行ATDD（Acceptance Test-Driven Development），因為test cases不會憑空產生。

註：本系列文章，會以user story為主軸，因為在Scrum中，透過user story來管理使用者需求，是一種輕量級、又相當具備彈性的方式。

上一篇文章：[Day 19]Refactoring - The End is the Beginning
本系列文章專區
＠前言
TDD系列到這邊，只是獨立介紹了測試與重構，接下來要介紹的部分，則是筆者認為TDD整個流程中，影響成敗的一環，也就是從user requirement break down到acceptance testing。這也是一般文章或書籍中，比較少提及的部分，然而也是筆者認為大家對TDD在實務上應用，最缺少的一環。

正因為少了這一環，TDD的起手式，會使得大家認為TDD不就只是個先寫測試的開發方式罷了。

當把user requirement，串到ATDD，輔以BDD，搭配TDD，一路打通任督二脈之後，在Scrum的流程中，Agile的精神中，XP的基礎建設上，整個開發流程，每個階段，每個角色的串接順暢，資訊基底一致，筆者才體會到了TDD的美妙之處。

也希望接下來幾篇文章，不會讓讀者們失望。

＠V-model
一般軟體開發流程中，常見的V-model如下圖所示：

(出處: http://www.testingexcellence.com/v-model/)

V-model中，可以看到基本上開發流程的幾個階段就是：

1. 使用者需求蒐集與分析 (RA)
2. 系統分析 (SA)
3. 架構/系統設計 (SD)
4. 程式開發 (PG)

接著每一個階段有對應的測試來進行verify與確認執行無誤。

（註：上面這張V-model的圖，在後面幾篇文章中，會有不同的進化）

從V-model中也可以看到，在軟體開發流程中，第一步基本上就是蒐集與分析使用者需求，而驗證系統是否符合使用者需求，則是透過User Acceptance Testing。這也是為什麼，筆者一直強調使用者需求管理與驗收測試，在TDD中這麼重要的原因。

因為：系統的存在目的，是為了滿足使用者需求，而不是給開發人員寫爽的。

因此在講ATDD，介紹Acceptance Testing之前，筆者想先介紹一下user requirement管理（或是稱為「定義」）的方式。

＠User Requirement
在需求蒐集的過程中，我們需要透過一種方式，將使用者的需求以某種方式紀錄或定義，其目的如下所示：

1. 用來供整個團隊與使用者確認，是否這些需求滿足之後，這就是他們要的系統。（參與的人員，可能包括了使用者、Product Owner、需求分析師、系統分析師、開發人員、測試人員）

2. 供分析人員、測試人員、開發人員可以繼續往下進行系統開發的共同基底資訊

3. 用來檢視目前完成進度與驗收範圍

這邊則針對user story, use case與一般常見的功能清單來進行說明。

＠User Story
使用者故事（User Story）是一種輕量級且相當靈活的使用者需求管理方式。

在系統開發之前，整個團隊都應該思考預期的系統行為，是否能夠滿足使用者的需求，這就是user story可以幫助我們的地方。

透過相當簡單好懂的方式，用大家都懂的語言，記錄下來使用者的需求。（大家都喜歡聽故事，不是嗎？）

這邊舉出wiki上的幾種user story格式，供大家參考一下：（來源）

1. 最原始的範本：點出role, goal跟benefit，格式如下：
   "As a <role>, I want <goal/desire> so that <benefit>"

2. Mike Cohn覺得上面的 so that...不一定需要存在，但重點是goal一定要出來，格式如下：
   "As a <role>, I want <goal/desire>"

3. Chris Matts覺得，系統開發的重點在於可以給使用者帶來什麼價值，所以將benefit拉到最前面，格式如下：
   "In order to <receive benefit> as a <role>, I want <goal/desire>"

4. 5個W的格式，也就是人事時地物，格式如下：
   "As <who> <when> <where>, I <what> because <why>."

（註：筆者自己認為1,2,3在使用上都挺OK，5個W的格式則是太冗長）

例子如下圖所示：

注意事項：
user story的撰寫重點在於，用最簡單的方式，讓大家都可以瞭解這個需求是什麼。通常會focus在What，而不是How。一旦user story關注地太詳細，可能會導致開發流程中無法因應需求的變化。也額外的花費了太多的成本在於可能會一直變動、重工的部分。

筆者自己習慣的方式：

1. 簡單的點出，這個需求的目的，由誰使用，需要什麼樣的功能。

2. 如果user story的描述有10句話，拿掉其中3句話，仍能清楚表達需求，能瞭解目的、功能、誰，那就把這些多餘的話拿掉。

3. 確定使用者看的懂、測試人員看的懂、開發人員看的懂，可以用最簡單的資訊，來當作彼此之間溝通的基底，用最快的速度完成共識，或是在需求變更時，用最快的速度、最小的成本推翻它 （笑）

User story因為簡短，所以蠻多團隊會準備一些小卡：user story card，將user story寫在上面，這樣的方式有幾個好處：

1. 篇幅有限，可以限制廢話太多

2. 實際物體形式存在，讓大家更有參與感與透明感。搭配白板，也很方便可以呈現狀態的轉移

3. 可在上面標記priority

4. 可在上面標記目前負責人員

使用user story時，也有個3C原則可以參考一下：

1. Card
2. Conversation
3. Confirmation

簡單的說，user story記錄在Card上面，可以拿來當作溝通的基底，最後user story要搭配對應的acceptance test cases，才能說明這個user story，也就是這個不包含太多細節的使用者需求，該怎麼確認完成(done)。

User story切記不要寫太長，把步驟或細節都列上去，只會失去其最主要的意義與目的，如下圖所示 （from wiki）：

1. 簡短版
   

2. 冗長版
   

讀者覺得上面兩個例子，哪一個好懂呢？哪一個有彈性呢？

想瞭解更多user story的眉角，建議大家可以參考Mike Cohn的User Stories Applied，（書上寫得相當完整，但許多都是實務上眉角的探討，並不適合當入門書）這邊因為篇幅限制，就不講太細太深，而是透過user story來當作ATDD的入口點。

＠Use Case
有透過UML來進行SA/SD的團隊（尤其是使用MDA的團隊），肯定對Use Case不會陌生。

Use Case基本上分為兩段，一個是Use Case Diagram，如下圖所示：

透過連使用者都看的懂的圖示，來說明：

1. 系統邊界
2. 參與角色
3. 使用案例

夠抽象，就會穩定。

然而，Use Case有時還會搭配Use Case Description/Use Case Specification，其中包含了pre-condition與post-condition，如同上圖的註解所簡單點出的部分。也可以參考一下這篇文章的簡介：[系統開發生命週期]Use Case Diagram補完

實際的Use Case Description/Use Case Specification其實要包含的東西相當多，讀者可以參考wiki上的說明：用例模版

Use Case Diagram筆者也會使用，但使用的時機通常是拿來當作SD的開頭，而不是拿來當使用者需求管理的目的。例如：將user story透過一張use case diagram來圖示系統邊界、角色以及功能，三者之間的關係。

＠功能清單
這個在有導入CMMI的公司中，絕對是相當常見的東西，格式不一，但基本上就是長的像下圖所示：

格式不一，目的就是需求管理，驗收清單。記錄著將使用者抽象、漫無邊際的需求，轉化成一支一支的功能清單，並且針對該功能進行簡單的描述，可能還會延伸出拿來派工(task arrangement)，即可看出由誰負責開發、測試、驗收等等資訊。

功能清單主要拿來做需求管理，在瀑布式開發方式與CMMI所重視的精神中，需求是需要追蹤以及妥善的管理，這都是對的，但是很容易就變成：需求需要在一開始就明確定義清楚，才能往分析階段前進，全部分析完成，才能往開發階段前進。

每一次的需求異動，都是一整個流程階段狀態的改變，也就是重工的範圍是會影響整個團隊中不同角色，甚至把開發階段回推至先前的狀態。這也容易導致階段、角色之間的對立，導致開發團隊並非一整個團隊，並非全力的為了滿足使用者需求而開發，而是責任歸屬、互推皮球，食物鏈式的往下壓榨。

這些，在Agile/CMMI的比較或Agile的宗旨，如下圖所示，已經講得很清楚了，筆者就不在這著墨太多。

＠三種方式簡單的歸納與比較

1. User story：
   建立的成本最低，著墨的資訊也幾乎是最少，主要拿來溝通與管理使用者需求。需搭配acceptance test cases當確定怎麼樣可以認定為done。

2. Use case diagram搭配use case description：
   一張圖可以快速的表象出人事物的關係，但只有圖容易太抽象，加上description則太冗重。建議可以選擇性的加入pre-condition與post-condition。好處當然是針對某一個使用案例，可以詳細的描述相關的步驟，但寫越多，需求異動的成本就越高。（後面文章有機會的話，會提到pre-condition與post-condition，可以對開發、測試上有什麼幫助）

3. 功能清單：
   傳統的開發方式，學習成本較低，就只是一種文書整理的方式。可讀性較差，只能拿來當作驗收、請款、派工、需求異動管理的一份文件，對系統從需求要繼續往下延伸至分析、設計、開發的幫助最低。

＠小結
在TDD的流程中，講究的是小步前進，快速回饋，擁抱變化，重視溝通，滿足需求。所以基本上建議搭配Scrum的流程、Agile的精神、Extreme Programming的基礎建設。

User story在這三者中，最適合拿來當TDD的user requirement文件，因為建立容易、好懂、成本低，且可以表達使用者需求，搭配acceptance test cases來輔助後面的ATDD、BDD，進而進入開發人員最擅長的TDD循環。

所以，這系列文章，將會以user story為例子，說明完整的TDD開發流程。

註：擁抱變化，需求變更是系統進化的原動力，科技始終來自於人性。嚴禁需求異動，最終只會做出一個開發團隊自爽的產品，而不是滿足使用者需求的產品。

＠補充
補充一下一些term的全名：

1. TDD: Test-Driven Development
2. ATDD: Acceptance Test-Driven Development
3. XP: Extreme Programming