Agile Meetup 2015/04 #2 — PM大，我們換個方式寫需求文件吧!
PM大，我們換個方式寫需求文件吧!
本月份Agile Meetup的第二炮由Jamis帶來，分享主題是關於需求文件的撰寫方式─『Specification by Example(實例化需求)』，這邊是Jamis提供的投影片。
在軟體開發當中，需求文件的重要性無需贅述，但是傳統由PM所寫的需求文件太過抽象、不明確、不清楚，容易造成團隊成員在對需求的認知或彼此溝通上的困難，一旦需求沒有被明確的定義就進入開發階段，那麼付出的代價絕對是慘痛的，所以我們希望可以找到一種文件撰寫方式讓所有團隊成員都能了解『需求』。
過去PM寫出的需求文件可能類似下述內容(引用自投影片P.13)：
如果沒有註冊的使用者會回報server error，請改成自動註冊，且回傳正確的oathu token。
短短的幾句話好似寫了些什麼，但又好像什麼都沒寫，當中缺少了：
- 場景
- 時間
- 對象
- 如何使用
- 目的
那系統該怎麼設計呢？所以程式該怎麼寫呢？QA又要如何構思測試案例呢？大概沒有人能夠正確的從這份需求文件獲得軟體開發的所需資訊吧。
因此我們期望實例化需求能達到這個目標，首先以範例(投影片P.24,25)來作簡單的介紹。
範例一
場景：當使用者在APP使用Facebook登入，使用者的FB帳號已經存在系統裡。
假如：當APP取得使用者的FB email及FB ID後，回傳server。
| FB email | FB ID |
|---|---|
IAMALLPL@gmail.com | IAMAPPLE |
當：模擬使用者登入，進行使用者帳號密碼確認。
那麼：使用者確認成功後，回傳User Token。
| Token |
|---|
| 092kjdfl92hjdkf82 |
範例二
場景：當使用者在APP使用Facebook登入，使用者的FB帳號不存系統裡。
假如：當APP取得使用者的FB email及FB ID後，回傳server。
| FB email | FB ID |
|---|---|
IAMALLPL@gmail.com | IAMAPPLE |
當：模擬使用者登入，使用者帳號不存在，進行註冊使用者。
那麼：使用者帳號註冊成功後，回傳User Token。
| Token |
|---|
| 092kjdfl92hjdkf82 |
不是單純用抽象的文字敘述說明軟體的行為，而是採以實際的例子來：
- 定義軟體的需求
- 商業導向的測試
- 說明與確定要做事情的範圍
透過具體案例來說明需求及範圍，並且將重點擺在軟體應該如何處理事情的邏輯，而非處理流程的腳本上。
優點：
- 透過自然語言描述需求，能夠串聯整個團隊的所有成員，語言一旦一致，溝通也就更為容易，讓所有角色都能夠明確了解需求結果。
- 且無論從軟體開發初期到後期、所有團隊成員都可以看同一份文件，連貫性高。
(上圖修改自投影片內容)
缺點：
需要多花時間撰寫需求案例，會使得需求準備時間變長。
除了討論實例化需求的寫法、優缺點等，那麼應該要在什麼時候開始撰寫這份文件呢？撰寫的工作又應該交由誰負責呢？應該是在定義需求的時候，就由所有團隊的成員一同來分析、討論各種可能的案例及例外，方能確保其完備性。
總結：
實例化需求並不是要用來取代傳統傳統文件，而是用來補充傳統文件上的不足。
Q&A：
Q：撰寫完成的實例化需求文件放在哪裡？
Ans：可以放在Task system或者透過軟體放在live document中。
Q：PM沒辦法想出太多Case
Ans：應該是要所有成員共同思考，一起撰寫，否則需求一旦不明確，很容易拉長開發時間。
Q：寫完的需求未來是否可能會用到？
Ans：相關聯的資料會用到，花的時間也會跟著減少(因為同一系統用到的資料關聯性高)。
Q：非功能性需求(效能、安全性…等)是否也需要實例化？
Ans：一樣可以透過實例敘述。
Q：PM不想寫，是否需要拉攏QA來同一陣線？
Ans：可以找QA一起討論例外案例等。
Q：比起傳統方式多花了多少時間？
Ans：前期為了尋找案例相關資料可能會多花近兩倍的時間，但期待能在開發、測試階段節省更多時間‧
討論：
如果是由PM自己開始導入實例化需求，可以自行先寫幾個案例，接著再找團隊成員一起到白板前討論，並逐漸養成其習慣。
太專業的術語容易引起排斥，傾向不要跟PM或其它成員說我們來撰寫實例化需求文件，而是以我們來釐清需求這種說法即可。
所花在實例化需求上的時間其實也是保護自己的一種工具，因為有事先找PM討論並且確認無誤，那麼完成的程式或功能不符合客戶需求，那問題的責任應該就數PM要負責了。
UI層面的需求可能需要透過scenario測試，而非UI面則是可以實例化需求來測試。