需求分析書中最重要的資訊是什麼？

Sept. 21 23:04~ Sept. 22 00:14

Teddy 這次到美國出差，利用 Amazon 在美國國內買書不用運費的優惠，一不小心買了 10 本書（標準的貪小便宜心態），等要回台灣打包行李時才發現，這還真有點快放不下（要不是幫剛做完月子沒多久的同事帶了六個奶瓶回來，可能會買更多書... XD）。不過這不是重點，今天的主題是 Teddy 要介紹一本此行出差所買的書：Bridging the Communication Cap: Specification by example and agile acceptance testing。

當初會買這本書是因為被書名副標題『Specification by example and agile acceptance testing』所吸引。記得當年 Teddy 還在念博速班的時候，看過 Phillip G. Armour 所寫的一篇 paper，叫做 The Case for a New Business Model: Is software a product or a medium?, Communications of the ACM, pp. 19-22, August. 2000。這篇  paper 提到有五種儲存知識的媒介：

• DNA
• Brains
• Hardware
• Books
• Software

Paper 細節就容 Teddy 偷個懶，請鄉民們自行發掘。當年 Teddy 看完的感想是，一般的軟體需求都是以『文件』形式存在，屬於上述第四種知識儲存媒介（book）。但是軟體開發的最終產品卻是以第五種知識儲存媒介（software）存在（這算是所謂的『阻抗不匹配嗎？』）。所以，問題來了，軟體開發人員就需要確保這兩種不同的知識儲存媒介（想表達相同的事情---軟體功能或需求）是否同步（軟體工程裡面所謂的  traceability）。相信大家都知道軟體開發人員都很忙，沒有那個美國時間去更新需求文件，因此需求文件所記載的內容與程式碼實際完成的功能經常有所出入也是很『正常』的現象。所以，到底要相信文件還是要相信程式碼，便成為許多軟體開發人員心中的痛（鄉民甲：其實... 兩者都不可信...XD）。

所以，Teddy 當時就在想，如果能夠將軟體需以 software 的形式表達，那麼需求與產品都是以第五種知識儲存媒介（software）來紀錄，是不是就可以減少『阻抗不匹配』的問題？此外，由於軟體具有『可執行』的這個特性，因此就有可能自動驗證『需求』與『軟體系統』是否『同步』。

講了這麼多，還沒轉台的鄉民們，再看一次這本書的副標題：『Specification by example and agile acceptance testing』，其實是有類似的味道。許多做 agile testing 的人都知道所謂的 agile acceptance testing，在開發一個 story 的時候，先幫這個 story 寫一個 acceptance test case （當然此時這個 test case 一定會失敗，因為程式碼都還沒出生啊），中間經過一連串開發過程（細節跳過），最後如果這個 acceptance test case 通過，就代表這個 story 完成。從另一個角度來看，我們可以說這個 acceptance test case 紀錄著它所代表（測試）的那個story 的知識。

***

講了這麼多，其實這全部都不是重點，回到本篇的重點：『需求分析書中最重要的資訊是什麼？』

答案：寫這本需求分析書的那個人的電話號碼。

來源請參考本書第 25 頁：

Ron Jeffries said, during his session on the natural laws of software development at Agile 2008, that the most important information in a requirements document are not the requirements, but the phone number of the person who wrote it.

這本書目前只看了 20％ 左右，有機會看完的話再跟鄉民們報告。

*** 

友藏內心獨白：親愛的鄰居們，夜深了，烤肉用具可以收起來了。搞得空氣中都是烤肉味道，怎麼睡覺啊。