讓技術人員看得懂的流程（2）——用例模型

讓技術人員看得懂的流程（2）

——用例模型

一般的管理流程都將軟件項目劃分為“需求->分析->設計->實現->維護”，對應的技術流程中首先也肯定是要將需求明確，而“用例模型”就是用於獲得和分析需求的。

簡單來說，用例模型就是要將客戶的需求寫下來。“需求”不是很好理解，更加通俗的講法是“故事(story)”。我覺得“故事”這個詞非常好，非常形象，非常容易理解！我們看看為什麼“故事”更加容易適合說明客戶要求：

（1）故事中有很多角色，而需求中也有很多角色；

（2）故事有具體的經過，有開始、進行、結束；而需求也是一個完整的流程，有輸入、處理、輸出。

（3）故事必須有意義，而需求對客戶來說，也是必須有意義的；

具體的用例格式等這裏就不詳細描述了，大家上網搜索一下就知道了，如何更好的把握需求可以參考我的博文《需求分析的故事——如何練就需求分析的火眼金晴？》，下麵我把用例模型階段容易犯的錯誤重點說明一下。

1）“需求”和“功能”混淆

很多朋友在分析需求的時候，將“功能”和“需求”混淆起來，導致了需求的粒度不合理，或者把握不住重點的需求，我總結出一個很簡單的區分辦法：“需求是對客戶有價值的東西，功能是為了實現需求而作的東西”。

以POS機為例：對於客戶來說，“買單”是一個有價值的東西，因為客戶買完單就可以把商品拿走了；而買單過程中的“讀商品條形碼”、“計算商品總額”、“打印購物清單”等都是功能，因為它們當中任何一個獨立的功能對客戶沒有價值（你不會跑到超市“讀商品條形碼”玩吧:-P），隻是為了實現“買單”而做的。

2）在用例模型階段進行係統分解

除了容易將“功能”和“需求”混淆外，用例模型階段還有一個常見的錯誤就是在用例模型階段對係統進行分解。

以POS機為例，有的人將需求描寫為：掃描機掃描商品條形碼信息，然後將信息發給庫存係統，庫存係統返回詳細的商品信息給交易係統……在用例模型階段這樣做是不對的，因為這樣轉移了我們的注意力：從關注用戶需求轉到了係統分析了。

記住：用例模型關注的是用戶需求，不需要進行係統分解，把係統當做一個黑盒看待就可以了。

下麵我們給出POS機一個簡單的用例片段，有興趣的可以自己寫一個完整的（這個完整的可不簡單哦，至少可以寫3頁）：

1）顧客攜帶商品到收銀台；

2）收銀員掃描商品條形碼；

3）係統根據條形碼獲取並顯示商品信息；

4）收銀員重複2~3步，直到所有商品掃描完畢；

5）係統計算商品總額；

。。。。。。。。。。。。。。。。。。。。

n）係統打出商品清單，完成交易。

===================2010.03.20補充==================

（經過garrodran99的提醒，補充SSD（係統順序圖）的內容，在此感謝garrodran99）

SSD即係統順序圖，目的就是站在係統的角度，以UML的順序圖來描述係統與“外部實體”（包括人、其它係統、輸入輸出設備）的交互過程，簡單來說就是“圖形化的用例”。

那為什麼有了文字化的用例文檔，還要圖形化的SSD呢？其實很簡單：字不如表，表不如圖，因為圖可以一目了然的看出交互過程。

可能有的朋友又要問了：既然圖那麼好，還要文字描述的用例做什麼呢？有兩個原因：第一個是客戶不會用UML給你描述需求，客戶隻會用自然語言描述需求；第二個就是圖形的優點是簡潔、一目了然，但圖形的缺點就是不能承載太多信息，詳細和豐富的信息還是要文字來承載。

用一句話總結就是：交互用圖形，說明用文字！

那麼，是否一個用例就要寫一個SSD呢？基本上不需要，因為SSD重點在描述係統的交互過程，如果用例本身沒有什麼交互、或者交互很少或者很簡單，就不需要SSD。隻有主要的、複雜的用例才需要SSD。

最後更新：2017-04-02 04:01:44