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