我做軟體做好幾年了，寫程式換過幾種語言。而寫規格書，卻沒有下過功夫去研究。最近一次開發一個比較大的系統，我自己後來寫出來的規格書，大概包含了三個部分：
1. 用講故事 (story telling) 的方式，用人類語言敘述的系統行為。
2. Database 的 schema
3. API 的 spec
後來，仔細想想，這樣子其實也是有問題。其實一個系統的開發，應該拆解成三個階段：
A. 用「非開發人員」也可以理解的方式，書寫的高階系統行為、概述。講的是系統的目的 (purpose)
B. 以程式語言實作系統 (implementation)
C. 寫出該系統的實作規格 (description of implementation)
以我自己的最近一回做的東西來講，story telling 算是 A 。Database schema 和 API spec 都是 C。而系統在與非開發人員溝通，主要是依賴 A 的部分。換言之，其實我做 A 的部分，算是做得很不清楚，因為只有 story telling ，算是相對難以把事情說清楚的。
Event Modeling
Event Modeling 該網站提出的方法，我覺得算是 story telling 的加強版，即 story telling with time。它建議，首先畫一條水平軸，描述「時間」的進展，然後在這個由時間構成的水平軸線上，會放上一個又一個的長方形來描述系統的 story 。
每一個長方形由三個要素構成：
1. Trigger - 通常是「使用者介面」或是「外部 API」
2. Action - 通常是要讀或是要寫入系統，分成兩種：Command 與 View 。Command 是「想要改變系統狀態的意圖」、而 View 是系統當下的「報表」、「結論」
每一個長方形由三個要素構成：
1. Trigger - 通常是「使用者介面」或是「外部 API」
2. Action - 通常是要讀或是要寫入系統，分成兩種：Command 與 View 。Command 是「想要改變系統狀態的意圖」、而 View 是系統當下的「報表」、「結論」
3. Event - 寫入硬碟的業務事件 (business fact)
長方形又可以根據 action 與 external states 可以仔細區分成 4 種 patterns
1. Command - state change
2. View - view
3. Translation - external state input
4. Automation - external state output
