采用用例，第1部分: 理解用例類型和工件
作者：Wayne 文章來源：天極
在此 Rational Edge 文章系列的第1部分，作者分析了不同的用例和工件類型，并簡要地討論了如何將用例技術引入到一個不熟悉它們的團隊。
用例技術是一種越來越流行的捕獲需求和驅動系統開發的方法。這種技術的新采用者面臨的挑戰是如何將此技術引入到一個組織，以及如何確定用例何時完成。通常，他們必須在實際的項目壓力之下面對這些挑戰。本文的目標就是概述這些原理，幫助他們戰勝這些挑戰。在第1部分，我們將分析不同的用例和工件類型，并簡要討論如何將用例技術引入到一個不熟悉它們的團隊。
在本系列中，我們將通過一個假定的案例研究來進行我們的具體討論，在這個案例中，一個積極熱心的分析師和她的CATLYST項目團隊的其他成員使用用例開始了一段新的旅程。你們中那些讀過 Rational Edge 的 2003 年 1 月期中“一個新的RUP經理的真實故事”的人，將會認出我們的虛擬團隊的扮演者。第2部分將會跟蹤這個項目的執行，并突出這些原理是如何應用的。
Smith，是一個經驗豐富的項目經理，他剛剛成功地交付了項目REALITY-J，正坐在他的小臥室中，這時，一名高級團隊成員，Harriet，輕輕地敲了敲他門口的鋼門。Harriet已經被分到另一個項目作分析師，并且在收集項目需求方面需要得到幫助，特別是在使用用例方面。了解到Smith有使用用例的實踐經驗，她想到找他尋求建議。
“我們正打算開始一個叫CATALYST的新項目�！彼忉尩��！八哪繕藶橐粋�國際連鎖酒店提供增值服務，并解決他們的記賬問題。我們的團隊在用例技術方面參差不齊。你能給我一些有關如何進行的提示嗎？”
需求領導能力是關鍵的
“你的團隊有一個主設計師嗎？”Smith問。
你說的主設計師是指的什么呢？“Harriet 回答道。
”如果你的團隊成員在有關如何引導需求管理過程上有不同的想法，并且有不同的文檔化和組織需求的方式，那么誰來進行最后的發言呢？“Smith問道。
”我不知道，我認為我不是一個主分析師。我在REALITY-J的時侯，我只是看到了所應用的用例，但是你寫了大多數用例。我只是你的用例的一個用戶。目前在我們的團隊中，我們已經有了三個工作成員：Roland，Helen和我自己。我們在項目開始時都承擔了分析師角色，然后接下來是團隊領導角色。Roland說他有一些使用用例的經驗。Helen沒有使用用例的經驗，但她正在積極地閱讀這個主題，我也是這樣。Simon是我們的項目經理。我想，如果我們之中要有一些差異的話，他將是做決定的一個人�！� Harriet回答道。
“Simon要積極地參與到需求采集－－確定用例，概述它們，等等－－中嗎？” Smith問道。
“我認為不是這樣。他可能會非常忙于項目的其它方面，并且對用例也相當陌生。我們大概要做這些需求，并且他可能是提出項目進度表的人，等等�！� Harriet說道。
“那么，Simon不會有時間做一個主分析師的工作，” Smith說道。 “這是一個問題。如果你的團隊沒有一個主分析師，每個人都處于風險中。你的團隊必須做的第一件事就是確定一個主分析師�！� Smith 告誡說。他指出IBM Rational統一過程，? 或 RUP，?在涉及到需求采集過程的兩個角色之間進行了一個明確的區分，并且給Harriet展示了RUP中的以下描述：
系統分析師。系統分析師角色通過概述系統功能和給系統劃定界限，領導和協調需求抽取和用例建模；例如，設置存在哪些角色和用例，以及他們如何進行交互。 需求說明者。需求說明者角色通過描述需求的一個或若干個用例以及其它支持性軟件需求，來詳細說明系統功能的一部分規格說明。需求說明者可能也要負責一個用例包，并維護這個包的完整性。”簡而言之，系統分析師擁有大的景象，而需求說明者工作在詳細內容上�！� Smith 解釋道，指出 Harriet 的項目既沒有一個系統分析師（如RUP所定義的），也沒有一個主設計師（如他所定義的）。她的團隊需要一個負責人，不僅要協調團隊，而且要通過明確描述需求指南來確保一致性。否則，一個需求說明者可能錯誤地認為另一個人正在編寫一個特定區域的需求文檔，至關重要的需求區域就可能從縫隙中漏掉。Smith強調的主分析師，在連接隔閡和確保需求完整性方面扮演了一個關鍵性的角色。
“用戶代表也需要一個負責人。否則，你將發現自己處于無休止的爭論之中，并遲延將耽擱需求收集過程的決策�！彼^續道�！案嬖V最終用戶團隊在你們開始工作之前確定這樣一個人。一個成功的項目要求在項目一方和最終用戶一方都要有強有力的領導能力�！�
需求是一種達到目的的方式
Smith向Helen笑了笑，Helen已經進到了他的小房間，從旁聽到了這個討論。
Smith知道Harriet是一個完美主義者，喜歡事情都清楚地說到最小的細節，他想幫助她在開始管理需求時采用一種平衡的觀點�！八仨毐苊鉃榱俗约旱呐d趣而集中于文檔上，相反，要堅持聚焦在理解問題和獲得有關如何解決問題的多數人意見上�！彼约哼@樣認為。因此下一步，他畫出了三個重疊橢圓，并標記出一些區域，表示顧客需要什么，哪些將被捕獲為需求，以及將最終被交付的系統（參見圖1）。
圖1：有效捕獲需求
"這三個橢圓表示了你需要跟蹤項目進度的框架。"Smith 說道，并在下面繼續解釋了每一個橢圓。
涉眾需求和目標。 系統被構建以滿足一定的涉眾需求或目標；這些定義了系統要做什么。
描述需求。 在需求采集期間，涉眾需求和目標被提取為需求。
系統構建。 系統遵從規定需求進行構建，并驗證涉眾需求和目標。這樣就關閉了橢圓。
“決不要忽略看到這個事實，即需求不只是到結束的一個手段。最終目標是要有一個滿足涉眾的需求和目標的有益的運轉系統�！� Smith告訴Harriet道。 然后他增加了一些字母到需求橢圓中的每個區域，如圖1所示。
“好吧，讓我們試一些小測驗。在這些標記字母部分的哪一塊發生了活動？”Smith問道。
"很明確，是A部分。"Harriet 回復道。
“是的，A是被識別的涉眾需求集，需求是根據它們進行編寫的，并且它們表示了已經被構建和驗證的系統部分�！� Smith 贊同道。
“我認為行動在D部分也發生了�！� Helen 提出。
“正是！如果一個系統滿足了涉眾目標，你是否已經寫下了需求就無關緊要了。在一些非常少見的實例中，當每個人都對項目目標有一個非常強的理解時，就已經不需要描述需求了－－或者需求規格說明可以是最小程度的�！�
這實際上是讓Harriet思考�！澳闶钦f，在某些實例中，我們可以忘掉需求？”
"當然不是！但是記住我說需求是到達目標的方法，這是一個有用的系統。" Smith 說道�！靶枨蟮闹饕康氖沁B接涉眾和我們的想法之間的差距，特別是在我們不理解或不同意的區域�！�
“我還不確定我是否了解了。這意味著我們應當有更多的會議和更少的文檔嗎？” Harriet 問道。
“你應當保持會議以取得一致意見，并使用文檔來明了已經同意了什么以及還有哪些未解決�！� Smith 回答道。
選擇合適的技術和工件
“那么需求的整體思想是保持涉眾和我們之間的連續的一致。用例技術如何在這里得到應用呢？” Helen 問道。
“確定業務角色，業務工作人員以及業務用例，還有系統角色和用例，有助于我們闡明系統的目標和范圍，以及其滿足業務目標的任務。用例規格說明幫助我們闡明角色和系統之間的交互關系�！盨mith 回答道。
“根據‘系統應...’格式敘述的傳統需求表示方法的關鍵問題是這些敘述不直接轉化為驗收測試；這要求一個額外的思考過程。用例通過連接跨越此間隙�！� 他強調說。他繼續解釋，用例的事件流描述了主角的請求和系統的動作（例如顯示處理結果或修改一個系統狀態），工作在測試過程中時，這對明確描述測試步驟和驗證點是有用的。在早期階段使用系統驗收標準作為抽取和記錄需求的一個基礎，會給團隊成員大量的控制。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
