就像小說里那些早慧的少年，很早就嘗試過用例驅(qū)動的需求文案，結(jié)果與客戶，一個愁默默，一個恨綿綿。
狂熱的用例編寫者也承認，用例對客戶與需求人員都是一種heavy的相互折磨。
客戶看用例時總要收攝心神來閱讀整個交互的流程，還有那些該死的擴展流異常流，沒經(jīng)過程序員專業(yè)抽象訓練的客戶，對著這些偽代碼一般的情景腳本，剛開始的一兩個還好，看多了，就是白天也能睡去?？蛻糁皇强炊既绱肆?，負責寫的人當然也不會好過。
但heavy的工作總有heavy的好處，否則早被唾棄于舞臺的背面。
在用戶的角度，用例比模棱兩可的功能點描述要清晰，也更直白于系統(tǒng)的價值。
在開發(fā)團隊角度，RUP的核心方法論之一---用例驅(qū)動的口號，明白人自然明白它的妙用。
設(shè)計人員的新設(shè)計手段：“用時序圖分析用例的實現(xiàn)，在描述過程中確定構(gòu)件或類，分配它們的職責和方法”，通過對用例覆蓋率的追蹤，需求與設(shè)計之間的信息損耗這個famous problem大大降低。
測試人員和文檔人員，更可以直接把系統(tǒng)用例笑納為《測試用例》和《用戶手冊》。
來到億迅后，被這里的用例文明給震住了，每個項目的軟件規(guī)格說明都是屯門清一色的幾百頁的前景，用例規(guī)約，業(yè)務規(guī)則，詞匯表，補充規(guī)約組成.......難得有情郎啊。
昨天又看到了一批新的用例誕生，但實在有好些明顯的不足啊，忍不住舊事重提的記下一批經(jīng)典的錯誤。不過.....只要能和客戶達成需求共識，就是一份好的用例了，也不用花太多時間在學術(shù)性的討論上。
1.客戶沒有能力閱讀用例
如果客戶實在沒辦法撐住困意看完用例的細節(jié)，即使草草簽了名，得不到用戶真正確認的用例，依然無法用來驅(qū)動設(shè)計和測試。
解決方法：放棄編寫用例，改回用戶容易看的傳統(tǒng)方式。
2.團隊沒有能力實現(xiàn)用例驅(qū)動
如果開發(fā)團隊在設(shè)計與測試時，根本不依照用例細節(jié)驅(qū)動，那用例對開發(fā)團隊就只是個擺設(shè)，花瓶。
解決方法：對設(shè)計、測試人員進行用例驅(qū)動的培訓，如果事不可為就干脆放棄，怎么省事怎么做。
3.在用例中描述系統(tǒng)內(nèi)部工作
經(jīng)典錯誤，開發(fā)人員把用例當作設(shè)計文檔來寫，如“系統(tǒng)將銷售信息寫入數(shù)據(jù)庫”，實際上應該寫的是“系統(tǒng)記錄銷售”。
解決方法：站在客戶的角度，把系統(tǒng)視為黑盒，刪除所有內(nèi)部設(shè)計描述。
4.在用例中描述界面
另一個經(jīng)典錯誤，不說了，如果在意用戶信息包括了姓名和密碼，可以在詞匯表里記錄，而用例寫成--顯示<用戶信息>。
5.在用例中越出系統(tǒng)邊界描述整個業(yè)務流程
要建立的系統(tǒng)只是整個業(yè)務流程里的一部，善良的需求人員為了大家清楚來龍去脈，將系統(tǒng)外的處理步驟也寫進了用例的情景。
如：
1.用戶去營業(yè)廳開戶
2.用戶撥號接入
實際上去營業(yè)廳開戶不屬于寬帶接入認證系統(tǒng)的職責。
解決方法：開戶的描述應該放到用例的前置條件中。前置與后置條件是說明系統(tǒng)邊界外的業(yè)務流程的好地方。
6.過多的用例，讓人暈菜
國外的慣例，一個用例一般有半個以上人月的開發(fā)量。
解決方法：
1.開戶，銷戶這樣的CRUD型用例可以合并成一個管理用例，以四個主場景分別表達。
2."老板問：你每天做什么阿?"，"我每天登陸系統(tǒng)"。這就是用例沒有提供足夠價值的明顯標志。
3.用例中的每一個步驟，其實都可以寫成一個獨立的用例，分 or 不分？這是個問題。
4.用例的打包組織是一門藝術(shù)，混合的按照功能包、目標用例，Actor，開發(fā)團隊或者版本號等等。
7.過多的擴展事件和異常事件流，讓人暈菜
即使是受過訓練的程序員，2a, 3b1看多了也要暈掉，記住閱讀者是人而不是機器。
解決方法：
1.如果邏輯不多，可以一句話講完，不影響主場景的，不建議新起一個事件流。
2.可以使用活動圖來輔助說明。在RSM7.0的模版里，每個用例都會帶上一個活動圖。
8.過多的關(guān)系，繼續(xù)讓人暈菜
“不要花一個月的時間去討論應該include還是extend”。大家對include, extend and generalize都不熟悉，那就干脆都不要用了。
狂熱的用例編寫者也承認，用例對客戶與需求人員都是一種heavy的相互折磨。
客戶看用例時總要收攝心神來閱讀整個交互的流程，還有那些該死的擴展流異常流，沒經(jīng)過程序員專業(yè)抽象訓練的客戶，對著這些偽代碼一般的情景腳本，剛開始的一兩個還好，看多了，就是白天也能睡去?？蛻糁皇强炊既绱肆?，負責寫的人當然也不會好過。
但heavy的工作總有heavy的好處，否則早被唾棄于舞臺的背面。
在用戶的角度，用例比模棱兩可的功能點描述要清晰，也更直白于系統(tǒng)的價值。
在開發(fā)團隊角度，RUP的核心方法論之一---用例驅(qū)動的口號，明白人自然明白它的妙用。
設(shè)計人員的新設(shè)計手段：“用時序圖分析用例的實現(xiàn)，在描述過程中確定構(gòu)件或類，分配它們的職責和方法”，通過對用例覆蓋率的追蹤，需求與設(shè)計之間的信息損耗這個famous problem大大降低。
測試人員和文檔人員，更可以直接把系統(tǒng)用例笑納為《測試用例》和《用戶手冊》。
來到億迅后，被這里的用例文明給震住了，每個項目的軟件規(guī)格說明都是屯門清一色的幾百頁的前景，用例規(guī)約，業(yè)務規(guī)則，詞匯表，補充規(guī)約組成.......難得有情郎啊。
昨天又看到了一批新的用例誕生，但實在有好些明顯的不足啊，忍不住舊事重提的記下一批經(jīng)典的錯誤。不過.....只要能和客戶達成需求共識，就是一份好的用例了，也不用花太多時間在學術(shù)性的討論上。
1.客戶沒有能力閱讀用例
如果客戶實在沒辦法撐住困意看完用例的細節(jié)，即使草草簽了名，得不到用戶真正確認的用例，依然無法用來驅(qū)動設(shè)計和測試。
解決方法：放棄編寫用例，改回用戶容易看的傳統(tǒng)方式。
2.團隊沒有能力實現(xiàn)用例驅(qū)動
如果開發(fā)團隊在設(shè)計與測試時，根本不依照用例細節(jié)驅(qū)動，那用例對開發(fā)團隊就只是個擺設(shè)，花瓶。
解決方法：對設(shè)計、測試人員進行用例驅(qū)動的培訓，如果事不可為就干脆放棄，怎么省事怎么做。
3.在用例中描述系統(tǒng)內(nèi)部工作
經(jīng)典錯誤，開發(fā)人員把用例當作設(shè)計文檔來寫，如“系統(tǒng)將銷售信息寫入數(shù)據(jù)庫”，實際上應該寫的是“系統(tǒng)記錄銷售”。
解決方法：站在客戶的角度，把系統(tǒng)視為黑盒，刪除所有內(nèi)部設(shè)計描述。
4.在用例中描述界面
另一個經(jīng)典錯誤，不說了，如果在意用戶信息包括了姓名和密碼，可以在詞匯表里記錄，而用例寫成--顯示<用戶信息>。
5.在用例中越出系統(tǒng)邊界描述整個業(yè)務流程
要建立的系統(tǒng)只是整個業(yè)務流程里的一部，善良的需求人員為了大家清楚來龍去脈，將系統(tǒng)外的處理步驟也寫進了用例的情景。
如：
1.用戶去營業(yè)廳開戶
2.用戶撥號接入
實際上去營業(yè)廳開戶不屬于寬帶接入認證系統(tǒng)的職責。
解決方法：開戶的描述應該放到用例的前置條件中。前置與后置條件是說明系統(tǒng)邊界外的業(yè)務流程的好地方。
6.過多的用例，讓人暈菜
國外的慣例，一個用例一般有半個以上人月的開發(fā)量。
解決方法：
1.開戶，銷戶這樣的CRUD型用例可以合并成一個管理用例，以四個主場景分別表達。
2."老板問：你每天做什么阿?"，"我每天登陸系統(tǒng)"。這就是用例沒有提供足夠價值的明顯標志。
3.用例中的每一個步驟，其實都可以寫成一個獨立的用例，分 or 不分？這是個問題。
4.用例的打包組織是一門藝術(shù)，混合的按照功能包、目標用例，Actor，開發(fā)團隊或者版本號等等。
7.過多的擴展事件和異常事件流，讓人暈菜
即使是受過訓練的程序員，2a, 3b1看多了也要暈掉，記住閱讀者是人而不是機器。
解決方法：
1.如果邏輯不多，可以一句話講完，不影響主場景的，不建議新起一個事件流。
2.可以使用活動圖來輔助說明。在RSM7.0的模版里，每個用例都會帶上一個活動圖。
8.過多的關(guān)系，繼續(xù)讓人暈菜
“不要花一個月的時間去討論應該include還是extend”。大家對include, extend and generalize都不熟悉，那就干脆都不要用了。