使用案例研討會是有組織的集體研討會議。它需要各方面的知識:
-
客戶需求
-
系統設計
-
單元設計
-
Rational Unified Process
-
測試
這表示群組將包含有不同背景、知識和經驗的人。請嘗試維持小規模的群組(不超出 10 人)。一般設定是群組一半成員來自開發小組,一半成員來自使用者代表。他們中間是代理。代理應該扮演主持人的角色 - 所有觀念和希望的催化者。
以下是您需要的工具:
-
兩個大白板(一個就夠了,但兩個更好)
-
圖表掛板
-
膠帶
-
兩種顏色的自貼變箋
-
白板筆(多色)
-
鉛筆
-
用來張貼紙張的牆,最好是在兩或三星期內可以不受干擾地使用的「戰爭室」裡。
請嘗試識別誰或什麼東西將使用這個系統。首先從實際使用系統的人員開始;相較於抽象的事物,大部分人在聚焦於具體的事物時,會比較自在。識別了使用者之後,請嘗試識別使用者與系統互動時所扮演的角色 - 這通常最好是參與者的名稱。
當識別參與者時,請務必寫下每個參與者的簡短說明;通常只需要少數幾個要點,擷取參與者關聯於系統所扮演的角色和參與者的責任,便有助於在稍後判斷參與者需要從系統中得到什麼。
當定義參與者時,請不要忘記將與設計中的系統互動的其他系統。參與者的圖示在這裡會造成誤導 -
它似乎隱含著「人」,但參與者的概念也包含系統。不過,請先將焦點集中在尋找「人類」參與者;大部分群組在聚焦於熟悉的東西時,都做得比較好,之後,再考量比較難理解的項目。
請不要擔心使用案例模型的結構,也不要擔心參與者之間的關係;只需要擷取將使用系統的人或事物就行了。請將焦點放在識別,準備去找出大量參與者。現在尚不需要太擔心過濾清單的問題;識別使用案例(請參閱下文)時,會處理這個問題。
請詢問這個問題:組織中的哪些角色將使用這個系統? 請繪製一個人形來代表每個建議的角色,將名稱寫在這個人形之下。之後,在白板上列出兩個參與者直欄,雲團或您剛繪製的圖示的兩側各一個。有時候,用角色或使用者這個詞來取代參與者會很有幫助。
請問下列問題:
-
誰會使用這個系統?
-
這個系統將傳送資訊給哪些其他系統?
-
我們將收到哪些其他系統的資訊?
-
誰啟動系統?
-
誰維護使用者資訊?
您可能會得到類似「這個參與者為什麼不是 Tom?這一向都是 Tom 負責的」的問題。之後,您必須問其他問題來瞭解 Tom 的角色。參與者的名稱應該反映角色。
-
Tom 的角色是什麼?
-
還有哪些人可以執行這個角色?
-
為什麼 Tom 有這個角色?
許多參與者都可以利用它們在組織中的正式職位來直接識別。組織中的職位可能對應於系統的多個角色。例如,Tom 可能是正式的倉庫工作人員,也是負責重組倉庫來騰出空間給新產品的人。對系統而言,這兩個責任可能是兩個不同的參與者。
有些人會想將一般化推到極致。他們會建議將「使用者」當作參與者,之後,再建議這是我們唯一需要的參與者。沒錯,但沒意義,這對於系統的瞭解沒有幫助。如果出現這個建議,請不要討論它。請將「使用者」參與者寫在白板上,再繼續下一個參與者。
-
問任何人是否遺漏了任何東西。
-
自動提出一些壞的建議。這樣,小組便可以糾正您和說明系統的確切角色。
-
一律接受所有建議 - 稍後您總是可以移除重複的部分和非參與者。批評某人的建議會傷害會議的精神。
定義參與者通常需要 1 至 4 小時。這時白板應該會列出許多參與者,但請確定還有空間可加入使用案例。當這組參與者似乎已經完整時,便可以開始使用案例。
請擦掉白板中的雲團或圖示,開始識別使用案例。請將焦點放在具體使用案例,避免討論併入和延伸關係。畫一個省略符號,寫下每項建議的名稱。畫各個指向參與者的箭頭。
請利用您完全不知道什麼使用案例的應用情況來作為一項優勢。研討會的參與者需要告訴您系統應該做什麼。您應該問許多關於系統的問題。當參與者提供說明時,使用案例就會出現。
有些人可以立即瞭解使用案例的概念,但有些人不會。為了更容易透視這個概念,請邀請一個人來畫系統視圖。系統視圖是系統的抽象表現。例如,它可能是一部伺服器,其中包含一個資料庫和幾個用戶端,也可能是幾塊標示了特殊作業的電路板。這個視圖通常很容易說明:通常是由一位參與者拿著一枝白板筆來說明系統如何運作。系統視圖有助於在系統邊界之間延伸使用案例,且會隱含地指向許多不同的系統狀態。請詢問這些狀態的問題,這時又會出現一些使用案例。請檢查失去不同的通訊時,將發生什麼
- 這有助於識別使用案例中的替代流程。
如果您在使用技術系統,通常每個人都已經非常清楚系統視圖是什麼,這時系統視圖是尋找參與者的最佳方法。在這個情況下,您可以先讓他們繪製系統視圖,再開始要求參與者。
如果您在使用管理系統,就不一定每個人都明白系統視圖。在這個情況下,說明手動常式的圖可能比較有用。這個圖可以說明如何將商業實體從一個人移到另一個人,以及他們打算要如何處理它。如果要將訂購和交付流程視覺化,這個圖可以顯示客戶辦公室、我們的辦公室、倉庫及客戶倉庫的概要視圖。
請確定每個人都能清楚見到使用案例模型和系統視圖/商業實體視圖。這便是有兩塊白板遲早會有用之時。
請允許使用案例使用長的名字。新識別的使用案例,名稱可能和句子一樣長 - 這正是使用案例簡要說明的好起點,您可以稍後再縮短名稱。
總有許多使用案例會有共用的部分。請確定大家都瞭解暫時可以接受這個情況。目前與結構化無關,因為我們還不太明白使用案例的內容。您應該等產生了事件流程概要之後,再提出任何關於使用案例關係的討論。
當小組同意白板上的使用案例涵蓋了整個系統的功能時,就可以休息了,午餐開始。
用完午餐之後,請檢視早上的會議結果:
-
看一下每個參與者:他在這個系統中的作業是什麼? 對不熟悉使用案例模型技術的人而言,作業一詞可能比使用案例好。
-
看一下每個建議的使用案例:您瞭解使用者會因為這個使用案例而得到什麼價值? 如果使用案例有正面的結果,使用者會更願意執行使用案例。
-
看一下每個建議的使用案例:這個使用案例完整嗎?或它只是大東西裡的一小部份?
請問下列問題:
-
每個參與者都應該至少有一個使用案例。如果不是,也許是因為參與者重複了(有其他參與者扮演相同的角色),也許是參與者實際上並非系統的直接使用者。在這些情況下,如果討論這個參與者值不值得保留,沒有得出很好的保留原因,便可以除去這個參與者。
請逐一處理每個使用案例,每個使用案例都要建立一個圖表掛板。請畫一個橢圓,在圖表頂端寫下使用案例的名稱。拿著一枝鉛筆,邀請小組協助您寫下使用案例的簡要說明。簡要說明應該有大約 1 到 3
個句子。有時畫出連接使用案例的參與者會很有幫助。請嘗試留下半張空白,下一步驟要用。
在這項工作期間,您會發現有些事情所有人都以為清楚,但實際上根本不清楚。請參閱在願景中識別為 關鍵使用者需求和特性的需求,嘗試找出是否有任何這個使用案例的需求。
這時會出現新的使用案例。有些使用案例會消失。請將使用案例紙張放在牆上。請嘗試用每個功能區一個直欄來組織它們。(這裡不要用白板 - 系統視圖和參與者及使用案例都需要它們。)
如果您無法立即解決問題,請將它們寫在自貼便箋上,再將它們放在適當的使用案例。問題使用一個顏色。
當所有使用案例都有圖表掛板和簡要說明時,就可以進入下一個模式了。這時最好花一點時間來討論這些是否真是所需要的所有使用案例。
您可以在 Rational Rose 或 Rational
RequisitePro 中,產生目前所建立之模型的文件,放在使用案例模型調查報表中。
開始撰寫使用案例的方式是先建立文字結構。如果關係人沒有先提供輸入資料,就不需坐著來嘗試建立文字結構。
請逐一處理每個使用案例。依照順序寫下不同的動作。請勿嘗試找出各項東西在程式碼結構、迴圈、for-while 陳述式等中所呈現的面貌,我們只處理基本事件流程,不用擔心任何替代流程。請列舉出第 1、2、3、4
步驟。為了協助小組瞭解所需要的細節層次,您可以指明基本流程需要 5 到 10 個步驟。
取得基本事件流程的步驟共識之後,請走過這些步驟,找出替代步驟。請列舉替代流程 A1、A2、A3、A4。
在這項討論期間,會產生許多問題,在進入分析和設計之前,往往無法解決。請記得寫下所有問題,以及一路上需要建立的任何假設。有些問題需要儘快解決,需求指定者才能夠正確詳述事件流程,其中有些必須確定解決之後,您才能開始「分析和設計」。
現在,每個圖表掛板上的東西應該足供需求指定者詳述使用案例的事件流程。
在這個會議期間,會有幾項系統需求無法很快擷取到使用案例中。這些陳述式通常與系統的一般功能、使用性、可靠性、效能和可支援性相關。請保留一份個別的圖表掛板來記下這些陳述式。它們會形成增補規格的基礎。
請瀏覽主要的關係人需求及願景文件中的主要特性,確認使用案例模型以適當方式涵蓋它們。請討論哪些使用者需求會 追蹤到哪些使用案例。
請採用願景文件,閱讀第一個 特性。將它的身分寫在一張(必要的話,可以有好幾張)自貼便箋上,請用另一個顏色,以便區分需求和問題。請將便箋放在完成這項需求的使用案例上。稍後,您便可以在您的
RequisitePro 儲存庫中輸入這些 可追蹤性。
永遠會有一些需求無法連接到任何使用案例:
-
它們可能是必須延遲到設計階段的特定需求 - 請將這些需求放在一張紙上(設計需求)。
-
它們可能是無法連接到任何使用案例的一般需求 - 請將它們放在增補規格清單上。
-
它們可能是被遺忘的需求,需要新的使用案例或變更現有的使用案例。
請花一時間來檢視室內結構:還有不含需求的使用案例嗎? 為什麼? 不需要這個使用案例嗎? 或寫下這項需求規格的人忘了這個功能? (通常就是這樣。) 這個狀況必須解決。客戶知道他需要這個功能嗎? 他願意為它付錢嗎?
|