承接上一篇文章，在煮飯的業務裏，問初學者做菜的流程裏面，洗菜是不是也可以當成一個完整的事件。
我想回答的是“買菜都是事件了，洗菜也可以是事件”。
對了，昨天的流程還遺漏了切菜，還有菜品的醃製環節，纔想起來，暴露了我不做菜的本質。
今天早上走去公司的路上，在想怎麼樣的顆粒度劃分，才能稱之爲事件了，想來想去，還在爲什麼單獨洗個番茄，做事件就不合適煩惱。也沒有答案，總歸，也就不糾結了。可能在對事件的細分上，總是要有點層次感，才能在宏觀把控的時候，抓住方向。在梳理流程脈絡的時候，不糾結與細節。在真正應對細節的時候，能顆粒分明。這個問題就等後面有了答案再說了。
接下來，講下洗菜的流程，流程過程的活動，以及活動詳細的步驟
因爲是三道菜的原材料一起洗，所以，要洗的東西有：
番茄，排骨，黃牛肉，芹菜，辣椒
這就簡單，番茄芹菜泡一會兒水再洗乾淨，排骨清洗後小火過血，辣椒簡單洗一下就可以了。黃牛肉也簡單洗洗吧。
流程過程的活動，洗番茄，洗排骨，洗黃牛肉，洗芹菜，洗辣椒，可以順序着來，也可以並行着來，按着習慣和食材的特性就可以了。
[補充一個活動圖]---鼠標沒電，假裝有活動圖一個
我們可以通過分析這個活動圖，活動圖有執行者，沒有寫出來，但是是要有執行者，活動才能執行，這個時候，我們就可以建立針對洗菜這個事件下所有的活動，建立用例圖了。
[補充一個用例圖]假裝用例圖在
針對每個用例，我們通過“用例規約”詳細地描述每個活動的活動過程
例如：
用例【煮飯大廚洗番茄】
用例規約如下：
利益相關者：喫這頓飯的每一個人，煮飯的人
操作者（用戶）：煮飯大廚
前置條件：廚房已有現成的菜品
業務步驟：
1）煮飯大廚拿到番茄
2）煮飯大廚拿碗盛水
3）煮飯大廚把番茄放在碗裏泡水5分鐘
4）煮飯大廚拿起番茄
5）煮飯大廚把番茄放在砧板上
6）煮飯大廚去掉番茄的蒂
7）煮飯大廚拿刀切番茄，切成一瓣一瓣的
8）當番茄已經全部切成瓣之後
9）煮飯大廚將番茄放到盛生食的碗裏面
業務規則：
1）番茄拿到之後，要檢查，如果腐爛，則扔掉
2）番茄泡水要把整個都泡在水裏
3）切出來的一瓣一瓣番茄，要像橘子剝成的那種效果
4）....
在用例規約都寫出來了之後，基本就把整個做飯的過程，在業務層面做了規定。
我們回顧這兩篇文章，做飯的業務需求分析過程，就是：
- 明確業務目標
- 分析主題域
- 尋找業務事件和事件流程
- 整理業務活動和活動流程
- 切換視角，輸出活動用例
- 編寫用例規約，凸顯業務步驟
在這個過程，我們對業務的分析，從宏觀到微觀的過程如下：
業務目標->主題域->業務事件->業務活動->業務步驟
[補充完整的分析結果過圖]
想想也是挺有意思的，如果把這個世界當成一個大系統，那麼針對這個大系統之上，人類要去實現一些所謂的價值，或許就可以轉化成業務目標，然後通過需求分析的方式，像剝洋蔥的方式，一步一步的分析要做哪些事，並且在這裏面細化，何人，何時，何地，何種約束和規定，何種可利用的資源。便有可能可以達成。
感悟，書本《軟件需求最佳實踐》，或許換一個角度，可以看到，不只是適用於軟件需求的實踐，可能還可以適用於其他的需求的實踐。還是謝謝作者，給我帶來了很多新的關於軟件需求，關於生活的思考。