采用用例，第1部分: 理解用例類型和工件

用例技術(shù)是一種越來(lái)越流行的捕獲需求和驅(qū)動(dòng)系統(tǒng)開發(fā)的方法。這種技術(shù)的新采用者面臨的挑戰(zhàn)是如何將此技術(shù)引入到一個(gè)組織，以及如何確定用例何時(shí)完成。通常，他們必須在實(shí)際的項(xiàng)目壓力之下面對(duì)這些挑戰(zhàn)。本文的目標(biāo)就是概述這些原理，幫助他們戰(zhàn)勝這些挑戰(zhàn)。在第1部分，我們將分析不同的用例和工件類型，并簡(jiǎn)要討論如何將用例技術(shù)引入到一個(gè)不熟悉它們的團(tuán)隊(duì)。

在本系列中，我們將通過一個(gè)假定的案例研究來(lái)進(jìn)行我們的具體討論，在這個(gè)案例中，一個(gè)積極熱心的分析師和她的CATLYST項(xiàng)目團(tuán)隊(duì)的其他成員使用用例開始了一段新的旅程。你們中那些讀過 Rational Edge 的 2003 年 1 月期中“一個(gè)新的RUP經(jīng)理的真實(shí)故事”的人，將會(huì)認(rèn)出我們的虛擬團(tuán)隊(duì)的扮演者。第2部分將會(huì)跟蹤這個(gè)項(xiàng)目的執(zhí)行，并突出這些原理是如何應(yīng)用的。

Smith，是一個(gè)經(jīng)驗(yàn)豐富的項(xiàng)目經(jīng)理，他剛剛成功地交付了項(xiàng)目REALITY-J，正坐在他的小臥室中，這時(shí)，一名高級(jí)團(tuán)隊(duì)成員，Harriet，輕輕地敲了敲他門口的鋼門。Harriet已經(jīng)被分到另一個(gè)項(xiàng)目作分析師，并且在收集項(xiàng)目需求方面需要得到幫助，特別是在使用用例方面。了解到Smith有使用用例的實(shí)踐經(jīng)驗(yàn)，她想到找他尋求建議。

“我們正打算開始一個(gè)叫CATALYST的新項(xiàng)目。”她解釋道。“它的目標(biāo)為一個(gè)國(guó)際連鎖酒店提供增值服務(wù)，并解決他們的記賬問題。我們的團(tuán)隊(duì)在用例技術(shù)方面參差不齊。你能給我一些有關(guān)如何進(jìn)行的提示嗎？”

需求領(lǐng)導(dǎo)能力是關(guān)鍵的

“你的團(tuán)隊(duì)有一個(gè)主設(shè)計(jì)師嗎？”Smith問。

你說的主設(shè)計(jì)師是指的什么呢？“Harriet 回答道。

”如果你的團(tuán)隊(duì)成員在有關(guān)如何引導(dǎo)需求管理過程上有不同的想法，并且有不同的文檔化和組織需求的方式，那么誰(shuí)來(lái)進(jìn)行最后的發(fā)言呢？“Smith問道。

”我不知道，我認(rèn)為我不是一個(gè)主分析師。我在REALITY-J的時(shí)侯，我只是看到了所應(yīng)用的用例，但是你寫了大多數(shù)用例。我只是你的用例的一個(gè)用戶。目前在我們的團(tuán)隊(duì)中，我們已經(jīng)有了三個(gè)工作成員：Roland，Helen和我自己。我們?cè)陧?xiàng)目開始時(shí)都承擔(dān)了分析師角色，然后接下來(lái)是團(tuán)隊(duì)領(lǐng)導(dǎo)角色。Roland說他有一些使用用例的經(jīng)驗(yàn)。Helen沒有使用用例的經(jīng)驗(yàn)，但她正在積極地閱讀這個(gè)主題，我也是這樣。Simon是我們的項(xiàng)目經(jīng)理。我想，如果我們之中要有一些差異的話，他將是做決定的一個(gè)人。” Harriet回答道。

“Simon要積極地參與到需求采集－－確定用例，概述它們，等等－－中嗎？” Smith問道。

“我認(rèn)為不是這樣。他可能會(huì)非常忙于項(xiàng)目的其它方面，并且對(duì)用例也相當(dāng)陌生。我們大概要做這些需求，并且他可能是提出項(xiàng)目進(jìn)度表的人，等等。” Harriet說道。

“那么，Simon不會(huì)有時(shí)間做一個(gè)主分析師的工作，” Smith說道。 “這是一個(gè)問題。如果你的團(tuán)隊(duì)沒有一個(gè)主分析師，每個(gè)人都處于風(fēng)險(xiǎn)中。你的團(tuán)隊(duì)必須做的第一件事就是確定一個(gè)主分析師。” Smith 告誡說。他指出IBM Rational統(tǒng)一過程^，® 或 RUP，^®在涉及到需求采集過程的兩個(gè)角色之間進(jìn)行了一個(gè)明確的區(qū)分，并且給Harriet展示了RUP中的以下描述：

• 系統(tǒng)分析師。系統(tǒng)分析師角色通過概述系統(tǒng)功能和給系統(tǒng)劃定界限，領(lǐng)導(dǎo)和協(xié)調(diào)需求抽取和用例建模；例如，設(shè)置存在哪些角色和用例，以及他們?nèi)绾芜M(jìn)行交互。
• 需求說明者。需求說明者角色通過描述需求的一個(gè)或若干個(gè)用例以及其它支持性軟件需求，來(lái)詳細(xì)說明系統(tǒng)功能的一部分規(guī)格說明。需求說明者可能也要負(fù)責(zé)一個(gè)用例包，并維護(hù)這個(gè)包的完整性。 ¹

”簡(jiǎn)而言之，系統(tǒng)分析師擁有大的景象，而需求說明者工作在詳細(xì)內(nèi)容上。“ Smith 解釋道，指出 Harriet 的項(xiàng)目既沒有一個(gè)系統(tǒng)分析師（如RUP所定義的），也沒有一個(gè)主設(shè)計(jì)師（如他所定義的）。她的團(tuán)隊(duì)需要一個(gè)負(fù)責(zé)人，不僅要協(xié)調(diào)團(tuán)隊(duì)，而且要通過明確描述需求指南來(lái)確保一致性。否則，一個(gè)需求說明者可能錯(cuò)誤地認(rèn)為另一個(gè)人正在編寫一個(gè)特定區(qū)域的需求文檔，至關(guān)重要的需求區(qū)域就可能從縫隙中漏掉。Smith強(qiáng)調(diào)的主分析師，在連接隔閡和確保需求完整性方面扮演了一個(gè)關(guān)鍵性的角色。

“用戶代表也需要一個(gè)負(fù)責(zé)人。否則，你將發(fā)現(xiàn)自己處于無(wú)休止的爭(zhēng)論之中，并遲延將耽擱需求收集過程的決策。”他繼續(xù)道。“告訴最終用戶團(tuán)隊(duì)在你們開始工作之前確定這樣一個(gè)人。一個(gè)成功的項(xiàng)目要求在項(xiàng)目一方和最終用戶一方都要有強(qiáng)有力的領(lǐng)導(dǎo)能力。”

回頁(yè)首

需求是一種達(dá)到目的的方式

Smith向Helen笑了笑，Helen已經(jīng)進(jìn)到了他的小房間，從旁聽到了這個(gè)討論。

Smith知道Harriet是一個(gè)完美主義者，喜歡事情都清楚地說到最小的細(xì)節(jié)，他想幫助她在開始管理需求時(shí)采用一種平衡的觀點(diǎn)。“她必須避免為了自己的興趣而集中于文檔上，相反，要堅(jiān)持聚焦在理解問題和獲得有關(guān)如何解決問題的多數(shù)人意見上。”他自己這樣認(rèn)為。因此下一步，他畫出了三個(gè)重疊橢圓，并標(biāo)記出一些區(qū)域，表示顧客需要什么，哪些將被捕獲為需求，以及將最終被交付的系統(tǒng)（參見圖1）。

"這三個(gè)橢圓表示了你需要跟蹤項(xiàng)目進(jìn)度的框架。"Smith 說道，并在下面繼續(xù)解釋了每一個(gè)橢圓。

• 涉眾需求和目標(biāo)。 系統(tǒng)被構(gòu)建以滿足一定的涉眾需求或目標(biāo)；這些定義了系統(tǒng)要做什么。
• 描述需求。 在需求采集期間，涉眾需求和目標(biāo)被提取為需求。
• 系統(tǒng)構(gòu)建。 系統(tǒng)遵從規(guī)定需求進(jìn)行構(gòu)建，并驗(yàn)證涉眾需求和目標(biāo)。這樣就關(guān)閉了橢圓。

“決不要忽略看到這個(gè)事實(shí)，即需求不只是到結(jié)束的一個(gè)手段。最終目標(biāo)是要有一個(gè)滿足涉眾的需求和目標(biāo)的有益的運(yùn)轉(zhuǎn)系統(tǒng)。” Smith告訴Harriet道。 然后他增加了一些字母到需求橢圓中的每個(gè)區(qū)域，如圖1所示。

“好吧，讓我們?cè)囈恍┬y(cè)驗(yàn)。在這些標(biāo)記字母部分的哪一塊發(fā)生了活動(dòng)？”Smith問道。

"很明確，是A部分。"Harriet 回復(fù)道。

“是的，A是被識(shí)別的涉眾需求集，需求是根據(jù)它們進(jìn)行編寫的，并且它們表示了已經(jīng)被構(gòu)建和驗(yàn)證的系統(tǒng)部分。” Smith 贊同道。

“我認(rèn)為行動(dòng)在D部分也發(fā)生了。” Helen 提出。

“正是！如果一個(gè)系統(tǒng)滿足了涉眾目標(biāo)，你是否已經(jīng)寫下了需求就無(wú)關(guān)緊要了。在一些非常少見的實(shí)例中，當(dāng)每個(gè)人都對(duì)項(xiàng)目目標(biāo)有一個(gè)非常強(qiáng)的理解時(shí)，就已經(jīng)不需要描述需求了－－或者需求規(guī)格說明可以是最小程度的。”

這實(shí)際上是讓Harriet思考。“你是說，在某些實(shí)例中，我們可以忘掉需求？”

"當(dāng)然不是！但是記住我說需求是到達(dá)目標(biāo)的方法，這是一個(gè)有用的系統(tǒng)。" Smith 說道。“需求的主要目的是連接涉眾和我們的想法之間的差距，特別是在我們不理解或不同意的區(qū)域。”

“我還不確定我是否了解了。這意味著我們應(yīng)當(dāng)有更多的會(huì)議和更少的文檔嗎？” Harriet 問道。

“你應(yīng)當(dāng)保持會(huì)議以取得一致意見，并使用文檔來(lái)明了已經(jīng)同意了什么以及還有哪些未解決。” Smith 回答道。

回頁(yè)首

選擇合適的技術(shù)和工件

“那么需求的整體思想是保持涉眾和我們之間的連續(xù)的一致。用例技術(shù)如何在這里得到應(yīng)用呢？” Helen 問道。

“確定業(yè)務(wù)角色，業(yè)務(wù)工作人員以及業(yè)務(wù)用例，還有系統(tǒng)角色和用例，有助于我們闡明系統(tǒng)的目標(biāo)和范圍，以及其滿足業(yè)務(wù)目標(biāo)的任務(wù)。用例規(guī)格說明幫助我們闡明角色和系統(tǒng)之間的交互關(guān)系。”Smith 回答道。

“根據(jù)‘系統(tǒng)應(yīng)...’格式敘述的傳統(tǒng)需求表示方法的關(guān)鍵問題是這些敘述不直接轉(zhuǎn)化為驗(yàn)收測(cè)試；這要求一個(gè)額外的思考過程。用例通過連接跨越此間隙。“ 他強(qiáng)調(diào)說。他繼續(xù)解釋，用例的事件流描述了主角的請(qǐng)求和系統(tǒng)的動(dòng)作（例如顯示處理結(jié)果或修改一個(gè)系統(tǒng)狀態(tài)），工作在測(cè)試過程中時(shí)，這對(duì)明確描述測(cè)試步驟和驗(yàn)證點(diǎn)是有用的。在早期階段使用系統(tǒng)驗(yàn)收標(biāo)準(zhǔn)作為抽取和記錄需求的一個(gè)基礎(chǔ)，會(huì)給團(tuán)隊(duì)成員大量的控制。

回頁(yè)首

需求工件

”我們的系統(tǒng)有不同種類的需求：用戶界面，業(yè)務(wù)過程，基礎(chǔ)結(jié)構(gòu)需求，數(shù)據(jù)需求，以及接口需求。我們?nèi)绾卧谟美胁蹲竭@些需求呢？”

Smith進(jìn)行了回答，描述了捕捉除了用例之外的各種不同種類需求的許多關(guān)鍵工件 ² ，如圖2所示。

• 業(yè)務(wù)用例模型。 所期望系統(tǒng)的目標(biāo)經(jīng)常是要解決業(yè)務(wù)問題或通過提供增值服務(wù)開拓商業(yè)機(jī)會(huì)。業(yè)務(wù)用例將用例的概念擴(kuò)展為描述業(yè)務(wù)過程。業(yè)務(wù)用例模型（與業(yè)務(wù)用例規(guī)格說明一起）提供了一種評(píng)價(jià)所期望系統(tǒng)范圍的方式－－有些部分可以自動(dòng)化，有些部分不能，有些部分可以通過更改業(yè)務(wù)過程來(lái)進(jìn)行。這就允許我們從一種業(yè)務(wù)觀點(diǎn)來(lái)評(píng)價(jià)用例模型的完整性，因?yàn)槊總€(gè)系統(tǒng)用例必須支持一個(gè)或更多的業(yè)務(wù)用例。
• 業(yè)務(wù)實(shí)體和領(lǐng)域模型。 大多數(shù)系統(tǒng)需要操作和展現(xiàn)業(yè)務(wù)信息。一個(gè)業(yè)務(wù)實(shí)體將一組相關(guān)信息字段表示為類。業(yè)務(wù)實(shí)體通過一個(gè)業(yè)務(wù)過程（例如業(yè)務(wù)用例）被處理和操作，它們接著通過系統(tǒng)用例被自動(dòng)化。所有業(yè)務(wù)用例及它們關(guān)系的總和組成了領(lǐng)域模型，領(lǐng)域模型描述了問題域。每個(gè)系統(tǒng)用例將操作一些實(shí)體，并且實(shí)體通常被包括在多個(gè)系統(tǒng)用例中。
• 業(yè)務(wù)規(guī)則。 今天，系統(tǒng)的復(fù)雜性通常是由系統(tǒng)必須符合的業(yè)務(wù)規(guī)則的復(fù)雜性所導(dǎo)致的結(jié)果。業(yè)務(wù)規(guī)則將被業(yè)務(wù)用例和系統(tǒng)用例來(lái)表示，并且可以是各種形式，決策表，計(jì)算規(guī)則，決策樹，時(shí)間圖（描述哪些事件必須發(fā)生在其它事件之前或之后，以及從中產(chǎn)生的過程），運(yùn)算法則，等等。在用例流中描述業(yè)務(wù)規(guī)則通常會(huì)把用例規(guī)格弄得混亂。因此，它們通常是在單獨(dú)的工件中被捕獲，或者是作為用例規(guī)格的附加物。
• 用戶體驗(yàn)?zāi)Ｐ秃颓楣?jié)串連圖板 用戶體驗(yàn)建模是捕獲用戶界面需求而不借助于畫出屏幕布局的一種便利方式，畫出屏幕布局的方式可能要花費(fèi)巨大的工作量，并且非?？赡馨l(fā)生變更。用戶體驗(yàn)建模將實(shí)際的用戶界面屏幕抽象為一個(gè)UML類，其原型是«screen»。屬性確定了用戶在一個(gè)屏幕上可以看到什么；操作確定了用戶在每個(gè)屏幕上可以做什么；并且關(guān)聯(lián)關(guān)系確定了航行路線。用戶體驗(yàn)情節(jié)串連圖板是用戶體驗(yàn)?zāi)Ｐ偷淖蛹?，用于描述與系統(tǒng)用例有關(guān)的屏幕。
• 補(bǔ)充規(guī)格說明。 補(bǔ)充規(guī)格說明描述了影響多個(gè)用例的需求。例如，所有用例都服從權(quán)限控制，審計(jì)跟蹤，個(gè)性化，等等。補(bǔ)充需求實(shí)際上通常是技術(shù)方面的，并且可以是關(guān)聯(lián)于功能、可用性、可靠性、性能以及可支持性。它們通常被表示為“系統(tǒng)應(yīng)做 ...”形式的陳述語(yǔ)句。

回頁(yè)首

用例類型

“我如何知道我應(yīng)當(dāng)使用這些工件的哪一個(gè)？”Harriet問道。

“好，像毛主席所說的：‘不管黑貓或白貓－－只要抓到老鼠就沒有差別。’只要這種技術(shù)能做這件事情，它就是好的。” Smith 回答道。

“我理解你的意思是什么，盡管我認(rèn)為這是后來(lái)的鄧小平所說的話。” Harriet 說。“但是我仍然需要一些一般的指南。”

“讓我們通過看一下用例的不同類型來(lái)開始吧。” Smith 回答道，并且繼續(xù)列出了如表1所示的用例類型。

“這是真正有用的。” Harriet說道。“我需要不同的用例規(guī)格說明模版來(lái)創(chuàng)建不同的工件嗎？"

“你可以對(duì)所有的工件使用相同的基本用例規(guī)格說明模版，如果你用適當(dāng)?shù)母郊用枋霰緛?lái)補(bǔ)充它的話。” Smith 回答道。“例如，你可以附加相應(yīng)的用戶體驗(yàn)情節(jié)串連圖板，參與實(shí)體的類圖，相關(guān)業(yè)務(wù)規(guī)則等等，作為你的用例規(guī)格的附加描述。這不意味著每個(gè)用例規(guī)格說明都需要一個(gè)完全的附加描述集；只包括那些會(huì)促進(jìn)理解的附加描述。”

“那么，對(duì)你的列表中的用例類型要求哪些工件呢？” Harriet 問道。

“我真的想忍住不作推薦－－以免你們把它們視為上帝的永恒之語(yǔ)。” Smith 說道。“這實(shí)際上取決于項(xiàng)目環(huán)境。然而，還是有一些明顯的。例如，數(shù)據(jù)維護(hù)用例可以很好地通過領(lǐng)域建模來(lái)描述，還可能有用戶體驗(yàn)建模。我發(fā)現(xiàn)領(lǐng)域建模適合于數(shù)據(jù)分析用例。因?yàn)樗鼈兪且詳?shù)據(jù)為中心的。請(qǐng)求批準(zhǔn)用例可以用業(yè)務(wù)用例規(guī)格來(lái)補(bǔ)充，如果它們不是瑣細(xì)的話。在許多情況下，支付用例需要相當(dāng)多的業(yè)務(wù)規(guī)則。忠實(shí)用例是令人感興趣的，因?yàn)樗鼈儗⒆约翰迦氲搅艘延杏美小?#8221;

“我不能完全回答你的問題。” Smith 繼續(xù)道。“用例類型更像是用例模式－－設(shè)計(jì)模式－－但是是在用例級(jí)別。你將在你的項(xiàng)目中碰到不同的用例種類，因此盡早地從每個(gè)種類中選出一個(gè)代表性的用例，用它進(jìn)行工作。這會(huì)幫助你決定需要什么樣的書寫風(fēng)格和什么樣的附加信息。如果你喜歡的話，我可以幫助你確定在項(xiàng)目開始時(shí)的用例模式。”

回頁(yè)首

評(píng)價(jià)完整性和細(xì)節(jié)

“我如何知道我何時(shí)已經(jīng)完成了我的用例？” Harriet問道。

“你必須應(yīng)用一些參考框架來(lái)評(píng)價(jià)用例模型，例如業(yè)務(wù)要求，業(yè)務(wù)領(lǐng)域，等等。然而，直到項(xiàng)目完全結(jié)束之后，你的用例才會(huì)真正完成，因?yàn)槟銓?duì)系統(tǒng)的理解－－以及你的最終用戶的理解會(huì)隨著時(shí)間的過去而被改進(jìn)和發(fā)展。這就是為什么你必須增量地和迭代地進(jìn)行工作。” Smith 回答道。“起先，你會(huì)想要集中在每個(gè)用例對(duì)于要進(jìn)行的開發(fā)是否足夠詳細(xì)。”

“是的，但是我如何知道我已經(jīng)有了足夠的細(xì)節(jié)？” Harriet 問道。

Smith 通過列出一些標(biāo)準(zhǔn)進(jìn)行了回答：

• 用例規(guī)格說明。基本流和可選流對(duì)于開發(fā)和測(cè)試團(tuán)隊(duì)是清晰的和可以理解的，并且已經(jīng)收到了最終用戶的正式批準(zhǔn)。
• 業(yè)務(wù)用例規(guī)格說明。 當(dāng)用例在業(yè)務(wù)過程中被激活時(shí)，規(guī)格說明是非常清晰的。團(tuán)隊(duì)也已經(jīng)驗(yàn)證，結(jié)果是對(duì)業(yè)務(wù)過程中的步驟有價(jià)值的。換句話說，團(tuán)隊(duì)已經(jīng)驗(yàn)證了相對(duì)于業(yè)務(wù)過程的用例中的事件流。
• 業(yè)務(wù)實(shí)體。 所有的將通過已經(jīng)被細(xì)化的用例操作的業(yè)務(wù)實(shí)體，以及它們的屬性和子分類已經(jīng)被定義。子類常常被用于評(píng)價(jià)事件流的完整性和業(yè)務(wù)規(guī)則。例如，預(yù)訂將是用于預(yù)訂一個(gè)酒店房間的一個(gè)實(shí)體，但是有三種不同的預(yù)訂類型：預(yù)付款，直接預(yù)訂，優(yōu)先預(yù)訂，等等。這些不同的類型應(yīng)當(dāng)按照可選流來(lái)對(duì)待，并且業(yè)務(wù)規(guī)則也必須考慮它們，例如，通過計(jì)算不同預(yù)訂類型的房間費(fèi)用。
• 業(yè)務(wù)規(guī)則。要求支持用例的業(yè)務(wù)規(guī)則是清晰的。例如，如果有一個(gè)用例是進(jìn)行一個(gè)房間預(yù)訂，也必須有一個(gè)計(jì)算規(guī)則來(lái)確定房間費(fèi)用。
• 用戶體驗(yàn)情節(jié)串連圖板。由用例定義的用戶界面所需要的屏幕被識(shí)別出來(lái)，包括字段和導(dǎo)航路徑。
• 補(bǔ)充規(guī)格說明。 清楚補(bǔ)充規(guī)格說明如何影響用例事件流的。例如，如果用例需要用戶身份標(biāo)識(shí)，就必須清楚何時(shí) 要求身份標(biāo)識(shí)以及要求什么許可。

“喔！看起來(lái)有很多工作！” Harriet 喊道。

“我沒有說詳細(xì)說明需求是容易的，但是就像我先前所說的，需求是到目標(biāo)－－一個(gè)有用的和工作的系統(tǒng)－－的一種方式。” Smith說道。“使用一個(gè)表（參見表2）來(lái)決定哪個(gè)工件對(duì)你的項(xiàng)目最有意義。然后，決定你需要用例的多少細(xì)節(jié)，并使用相同的表來(lái)跟蹤在采集你所需要信息方面的進(jìn)度。在表中的每一個(gè)單元，指出你是否已經(jīng)收集了工件的內(nèi)容和已與用戶進(jìn)行了驗(yàn)證。”

回頁(yè)首

迭代地引入用例技術(shù)

“這要學(xué)習(xí)那么多東西！” Helen 喊道。

“我同意。我的團(tuán)隊(duì)和用戶代表不熟悉用例，挑選和選擇技術(shù)將不太容易。” Harriet 接著說。“我認(rèn)為我們?cè)谂嘤?xùn)上也要用大量時(shí)間。”

“你們說得對(duì)，這是一件復(fù)雜的事情。讓我看一下你們可以如何應(yīng)對(duì)。” Smith 說。他建議采用如圖3所示的三階段的方法，并繼續(xù)解釋每個(gè)階段。

• 階段1：技術(shù)研討會(huì)
• 階段2：使用范例和指南進(jìn)行微小迭代
• 階段3：使用高級(jí)技術(shù)

回頁(yè)首

技術(shù)研討會(huì)

大多數(shù)項(xiàng)目團(tuán)隊(duì)在使用需求技術(shù)，特別是在用例方面有具有不同程度經(jīng)驗(yàn)的成員，因此主導(dǎo)一個(gè)研討會(huì)來(lái)建立你計(jì)劃使用的需求技術(shù)的共同理解是明智的。分析師和最終用戶代表都應(yīng)當(dāng)參與，因?yàn)樗麄兌紝⑴c到文檔化需求的編寫和評(píng)審中。

主持人可以是來(lái)自團(tuán)隊(duì)內(nèi)的或是團(tuán)隊(duì)外的，只要他或她是知識(shí)淵博的人，其專業(yè)技能是大家都知道的，并且受人尊重的。主持人在當(dāng)前項(xiàng)目的環(huán)境中討論需求技術(shù)是重要的；否則，討論將過于抽象。預(yù)先提供一些項(xiàng)目信息，即使他或她不是團(tuán)隊(duì)的一名成員。

回頁(yè)首

進(jìn)行微小迭代

在按照技術(shù)研討會(huì)之后，項(xiàng)目團(tuán)隊(duì)?wèi)?yīng)對(duì)挑選不同的用例類型（參見表1），然后在一個(gè)微小迭代中細(xì)化、實(shí)現(xiàn)和測(cè)試它們，這個(gè)迭代要努力解決風(fēng)險(xiǎn)。當(dāng)項(xiàng)目的大多數(shù)成員都對(duì)用例沒有什么經(jīng)驗(yàn)時(shí)，這是非常重要的。通過走過這個(gè)微小迭代，項(xiàng)目團(tuán)隊(duì)將獲得重要技能的第一手經(jīng)驗(yàn)：

• 編寫有效的用例。
• 決定補(bǔ)充用例所需要的額外工件。
• 理解用例如何驅(qū)動(dòng)開發(fā)（設(shè)計(jì)和測(cè)試）。

微小迭代的目標(biāo)是快速地按比例增加團(tuán)隊(duì)的能力。如果有些團(tuán)隊(duì)成員在獲得這些技能方面有困難，就有必要延長(zhǎng)主持人的涉入或重新調(diào)整團(tuán)隊(duì)角色結(jié)構(gòu)。

因?yàn)槟繕?biāo)是培訓(xùn)技能和幫助團(tuán)隊(duì)從一個(gè)瀑布模型轉(zhuǎn)換到一個(gè)迭代模型，因此微小迭代的場(chǎng)景應(yīng)當(dāng)簡(jiǎn)單，以使團(tuán)隊(duì)可以快速地從需求移到設(shè)計(jì)，然后進(jìn)行編碼和測(cè)試。這個(gè)小規(guī)模試驗(yàn)項(xiàng)目將幫助團(tuán)隊(duì)立即如何執(zhí)行一個(gè)迭代和使用合適的工件。

回頁(yè)首

必要時(shí)使用高級(jí)技術(shù)

研討會(huì)和微小迭代應(yīng)當(dāng)覆蓋各種用例類型：數(shù)據(jù)集中，工作流集中，數(shù)據(jù)維護(hù)，報(bào)告，等等。這將幫助團(tuán)隊(duì)成員試驗(yàn)不同的編寫風(fēng)格和需求模式。在微小迭代結(jié)束時(shí)，團(tuán)隊(duì)?wèi)?yīng)當(dāng)回顧需求是如何被組織和文檔化的，并識(shí)別要改進(jìn)的區(qū)域。這可能要求引入更高級(jí)的技術(shù)，通過用例符號(hào)： «include» 和 «extend» 來(lái)結(jié)構(gòu)化需求，等等。

沒有經(jīng)驗(yàn)的團(tuán)隊(duì)可能想在項(xiàng)目開始時(shí)避免使用高級(jí)技術(shù)，因?yàn)檫@些技術(shù)會(huì)激起方法論辯論，并將團(tuán)隊(duì)從他們的采集和捕獲需求的主要目標(biāo)轉(zhuǎn)移開。最好是在需求改進(jìn)需求之前，首先將需求記錄在紙上。

在微小迭代的最后，團(tuán)隊(duì)將獲得使用用例的動(dòng)手經(jīng)驗(yàn)，并且他們也將會(huì)對(duì)項(xiàng)目需求有一個(gè)好的理解。高級(jí)技術(shù)將幫助他們按照一種最大化用例可理解性的方式來(lái)結(jié)構(gòu)化他們的需求，并在用例編寫方面減少重復(fù)。主持人應(yīng)當(dāng)推薦要使用哪種技術(shù)，并提供有關(guān)如何進(jìn)行的必要指導(dǎo)。

在第2部分，我們將再次訪問CATALYST項(xiàng)目團(tuán)隊(duì)，看一下當(dāng)他們開始將用例用于工作時(shí)發(fā)生了什么。

回頁(yè)首

注釋

¹來(lái)自 Rational Unified Process，v2002。

²有關(guān)捕獲業(yè)務(wù)需求的更多信息，參見Rational Edge的2002年11月期中的"Effective Business Modeling with UML: Describing Business Use Cases and Realizations"：http://www.ibm.com/developerworks/rational/rationaledge/

參考資料

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文。
  

關(guān)于作者

		Pan-Wei Ng 作為一個(gè)軟件工程專家加入了Rational，目前是使用用例進(jìn)行需求管理（RMUC）的一個(gè)高級(jí)講師。他幫助許多組織采用Rational統(tǒng)一過程（RUP）和Rational Suite，并主導(dǎo)相關(guān)主題的專家研討會(huì)和討論會(huì)。他的興趣包括獲取模式和指南以加速RUP的應(yīng)用，這主要基于他的經(jīng)驗(yàn)和對(duì)客戶的觀察。他出生并成長(zhǎng)在新加坡，現(xiàn)在仍然住在那里，Ng獲得了博士學(xué)位，在加入Rational之前一直在國(guó)防工業(yè)工作。他的背景包括開發(fā)作戰(zhàn)分析、戰(zhàn)斗模擬以及指揮和控制系統(tǒng)的軟件。