＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊
這是月初的授課—「系統需求分析與整理」，其中一位上課學員拿他們的實際案例提供參考的。
先來瞧瞧這張看似很複雜的作業流程圖，主要是要描述當客戶單位提出報修需求時，維修單位的報價與維修的相關作業活動。
圖、原稿—客戶維修報價作業流程
這是一張典型 SA 所繪製的業務流程 （business process)圖，是否使用 UML 語法來表示，那並不重要。最主要的問題是，大多單位往往都認為這類業務流程的表達，必須要描述得很「精確」，才可以轉移到實作的階段。所以為了要能取得「精確」的結果，就需要不斷地開會與確認 (還含時常爭執各據的論點)，秏上個把個月才能有產出，然後再轉移到實作階段。
但是無論再如何精細，我發現到有一個相當有趣的現象，在這類環境下的 Programmer，往往都還是覺得不夠精細。
「越是想表達得精確，Programmer 越會嫌不夠精確！」
這就是典型的瀑布式 (waterfall)系統分析。這類所謂「精確」的業務流程圖，耗費太多在需求分析的時間，且由於描述了太多細節，反而讓實作寫碼不容易抓到適切的焦點，因而導致 Programmer 不知道如何寫出較具「彈性」可包容變動細節的程式碼，當然相對日久也就會把不精確的細節當成是一種無法 Coding 的藉口。
所以，上述如此好像「鉅細靡遺」的設計圖，主要的問題在哪裡？ 其實簡單的說，它早已違背了軟體設計至高無上的原則—封裝 (encapsulation)。
- 把資料細節呈現出來 (資料導向的思維)。
- 設計圖內描述了企業邏輯 (business logic)。
- 過早把資訊系統角色帶入。