1. 規格會不會變 跟 應不應該寫規格 是兩碼子事
規格肯定會變，沒有不變的，但應不應該寫規格就看公司文化
有兩派說法：
a. 規格是產品擁有者跟開發者的依據
b. 產品迭代快，產品目前的行為就是規格
實作會錯、test會錯、規格也有可能會錯，只要是人就會犯錯，所以
板友說這是看團隊，不無道理
2. 回到人會犯錯，規格有時會變成政治工具的一種
因為說到底，如果你的公司是犯錯就要究責的文化，那責任出在誰身上，那就很重要
此時規格的目的不再是為了完成產品
3. 規格不好寫
只要規格是用自然語言寫成的，就有可能會造成誤解
(我相信大家不可能沒遇過一群人對同一句話有兩種以上不同解釋的狀況)
精準的規格，有些產業可能隨便寫下來就是一兩千頁，然後賣你個五六萬
光是名詞解釋就能分成一冊單售
當然你們公司的商業邏輯可能複雜程度不是什麼業界標準等級的，可以參考
domain driven的叢書，但我試過，台灣大部分是推不起來:)
如果規格的目的是在避免犯錯或降低溝通的成本，但又不想寫規格，那不如
由開發人員主動設想所有「可能會出錯」、「模糊不清」的腳本或狀況
這些edge case的設想往往需要判斷與經驗、對系統的了解
我的經驗是大部分是非工程師的人往往不會去想這些，作為開發者的我有必要
在看到他們描述行為時，就盡量釐清我能想到的狀況
當你有了這些case或腳本，你就能夠建立測試