上個月我在「工研院」授課時，其中一位較為資深的程式開發人員問的問題： 我感覺不到寫好使用案例 (Use Case) 有什麼好處？
別誤會，這位年輕的開發人員並沒有惡意，我也認識他一陣子了。他的確是有感而發，覺得在工作上，從以前透過一般的需求規格書，到現在開發時導入 使用案例 的分析需求技術，但是，他並沒有感受到因為這樣而有加快程式撰寫的速度，反而還覺得縛手綁腳，經常需要受到規範。
這個問題，可比想像得還難以回答。 是為了可以有效保存需求分析的資產？ 還是為了系統的彈性 (flexibility)？ 前者似乎有道理，但如此對現在正進行的開發專案好像沒有說服力，甚至開發人員還覺得為了要補足這些需求文件，反而拖累了開發的速度；後者的系統彈性問題，我則是很確定與寫得好需求分析文件沒什麼直接的關係，彈性度的考量，與軟體的結構設計 (structure desgin)才是更主要的關鍵。
思考許久，我是以為，寫的好使用案例最直接的關鍵是： 影響到專案開發整個流程的節奏！
以使用案例為導向 (use case driven)的開發模式，我的體會是越來越能感受到那個所謂的 "driven" 這個字眼。 短線專案的特性，幾乎是偏以需求為優先。而使用案例的分析，其本質上仍是屬於功能 (functional)性的分析。只是有別於模組化的功能樹分析模式，後者的功能模組，耦合性 (coupling) 太重，容易牽一髮而動全身，所以在需求分析階段，會耗費許多時間在分析共用模組的考量；而使用案例，是一種目標導向 (goal-oriented)的功能分析方式。 每一個使用案例，都可以看待成是系統在某一段期間 (session)，可以滿足使用者使用系統的目的。 所以每一個使用案例，是可以個別被獨立開發，也就是說，UC-A 與 UC-B 甚至可以交付給不同團隊並行開發。而至於兩者若有共用性的議題的考量，則是延宕到結構設計階段再來討論即可。因為在需求分析階段，不用花太多時間在共用議題的考量上，所以可以很快速地實現 (realize)功能需求。
能抓得好與定義得好一個一個的橢圓使用案例，就能以該使用案例為開發單位。 這麼說好了，甚至可以把該使用案例就當成是一個迷你系統，然後來串連出整個開發的程序與產出。 例如，針對一個使用案例，就會設計一個位於中間層 (middleware)的控制型物件 (control object)，並從使用案例的敘述 (use case description)中，找出該物件應承擔的行為 (behavior)，然後再轉化成更詳細規格、程式語言的方法 (method)。 定義好控制物件與其應有的行為，就可以知道需求分析是容易並可以無縫式地轉移到實做階段，並快速地界定出程式碼的骨架 (sketletion)，再來就是補足細節、實做邏輯、連結資料庫或外部系統 等等…。
從中間層的控制物件來做為實現使用案例的中心，要提供給使用者操作的畫面，或是再橋接 "web service" 物件，提供給外部系統自動存取，這也是所謂的 SOA (service-oriented architecture)、以需求為導向的架構，都很容易被實現的；而對內就是為了實現使用者交付的需求，需要連結至資料庫或是外部系統，只要再加上所謂的 "DAO (data access object)" 與 "adapter" 助理型的物件，將實際連結的工作，委交給這類助理物件，分門別類、井然有序，是非常容易控管的。
再則，規劃好控制物件的骨架，馬上就應該撰寫測試程式，以確保程式開發的品質。而這類功能性的測試 (functional test)程式，更是可以作為系統驗收的主要依據。 而測試程式的來源為何？ 就是測試案例 (test case) 與 測試數據。 而這些仍都是以使用案例為中心，每一個使用案例會撰寫最少兩個以上的測試情節 (scenario)，並在其內填上測試的數據與預期的測試結果。
寫好使用案例的好處，族繁不及備載。越大規模的專案，更能感受到開發節奏的順暢度。再加上 "漸進循環 (incremental and iteration)" 的開發模式，會越形容易謀和在系統開發期間，人與事的種種…。
對了，上述的論述，有沒有說服到那位開發人員？ 當然是沒有！
為什麼？ 若比較是站在局部 (part)個別的角度來看系統開發時，尤其是對程式寫碼人員，寫不寫的好使用案例，對他沒差；只有當站在係以專案整個全局來看時，例如專案經理或軟體架構師，則會有明顯的感受。這也是在我們輔導的過程中，為什麼反而專案經理的接受度就很高的原因了。
那麼到底要如何說服呢？ 我從來都不認為需要說服！ 這裡我就引用 Martin Fowler 在「UML Distilled」一書中曾經說過的：
「你只能強迫新手們這麼做。過了幾年後，他們會突然恍然大悟，然後腦袋彷彿重生！」