用例在需求分析中的使用
多年來，分析者總是利用情節或經歷來描述使用者和軟體系統的互動方式，從而獲取需求（mcgraw and harbison 1997）。ivar jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例**於物件導向的開發環境，但是它也能應用在具有許多開發方法的專案中，因為使用者並不關心你是怎樣開發你的軟體。
而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意使用者要利用系統做什麼遠遠強於詢問使用者希望系統為他們做什麼這一傳統方法。 用例的重要功能是用畫用例圖的功能來鑑別和劃分系統功能。
它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統使用者能扮演的角色（role）。這些使用者可能是人，可能是其他的計算機一些硬體或者甚至是其它軟體系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。
它們必須能刺激系統部分並接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文字描述。
它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文字通常也描述每乙個活動在特殊的活動線時可能的錯誤和系統應採取的補救措施。 這樣說可能會非常複雜，其實乙個用例描述了系統和乙個角色（actor）的互動順序。
用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:
用例捕獲某些使用者可見的需求，實現乙個具體的使用者目標。
用例由角色啟用，並提供確切的值給角色。
用例可大可小，但它必須是對乙個具體的使用者目標實現的完整描述。在uml中，用例表示為乙個橢圓。
角色是指使用者在系統中所扮演的角色。其圖形化的表示是乙個小人。在某些組織中很可能有許多角色例項（例如有很多個銷售員），但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用乙個角色表示。
乙個使用者也可以扮演多種角色。例如，乙個高階營銷人員既可以是**經理，也可以是普通的營銷人員；乙個營銷人員也可以是售貨員。在處理角色時，應考慮其作用，而不是人或工作名稱，這一點是很重要的。
我們使用不帶箭頭的線段將角色與用例連線到一起，表示兩者之間交換資訊，稱之為通訊聯絡。角色觸發用例，並與用例進行資訊交換。單個角色可與多個用例聯絡；反過來，乙個用例可與多個角色聯絡。
對同乙個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，儘管執行的，但角色未必是人。
例如，角色也可以是乙個外界系統，該外界系統可能需要從當前系統中獲取資訊，與當前系統有進行互動。
乙個用例可能包括完成某項任務的許多邏輯相關任務和互動順序。因此，乙個用例是相關的用法說明的集合，並且乙個說明（scenario）是用例的例項。這種關係就像是類和物件的關係。
在用例中，乙個說明被視為事件的普通過程(normal course)，也叫作主過程，基本過程，普通流，或「滿意之路」 (happy path)。在描述普通過程時列出執行者和系統之間相互互動或對話的順序。當這種互動結束時，執行者也達到了預期的目的。
在用例中的其它說明可以描述為可選過程(alternative coruse)。可選過程也可促進成功地完成任務，但它們代表了任務的細節或用於完成任務的途徑的變化部分。在互動序列中，普通過程可以在一些決策點上分解成可選過程，然後再重新匯成乙個普通過程。
角色類和角色例項
軟體產品最終是給一些使用者來使用的，而使用者之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟體目標組織中所處的地位不同，地理位置不同，業務熟練程度不同。
不同的使用者都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的使用者可能希望有乙個友好的介面，熟練程度高的使用者可能更希望有快捷鍵或巨集的操作以提高工作效率。考慮到使用者的差異性，將使用者分類並研究使用者類的行為特徵是非常有必要的。
所以在做具體的需求之前，先將使用者分局行為和特點進行分類，對於研究、收集使用者的需求是非常有幫助的。
可以利用乙個簡單的**列出一些原始的分類，然後不斷的完善這個**。確認你的分類之間沒有交集。並充分描述使用者分類的行為，目的，要求等。
在企業分析中，比較常見的分類可能包括，**商，客戶，部門等。
就像c 中的類和物件一樣，我們把分析出的使用者分類稱為「角色類」，把實際的使用者稱為「角色例項」。在得到使用者分類之後，最重要的就是要選出使用者代表，使用者代表不僅僅是在需求階段中參與專案，還必須對專案的全過程負責。使用者代表能夠代表使用者分類的需求。
抓住使用者代表的需求就大致把握住了使用者類的需求。當然，需求分析還是需要在使用者中做大規模的調查的，只是要把重點放在使用者代表上。
確保和使用者直接進行溝通！大家有沒有玩過傳話的遊戲，可能看過。一群人排成一列，一句話從排頭挨個向後傳，到最後，那句話已經是面目全非了。
所以，一定要保證專案組能夠直接和使用者接觸。 對於和使用者直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟體，和使用者直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：
做大規模的市場調查，針對你的目標市場做市場調查，並根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些遊戲公司會發布一些demo版的遊戲。可是對於一般的企業來說，這項工作費時費力，高昂的成本往往使大家知難而退。
我的意見是，方法是非常好的，但是可以採用折衷的辦法，例如選取有代表性的企業，為特定企業製作乙個較小的版本並收集反饋意見等。這涉及到很多市場營銷的內容，並不是我的專業所長，這裡就不多弄斧了。 聘請行業專家，乙個行業專家往往可以在專案需求方面發揮極為重要的作用。
乙個行業專家往往都有大量的行業經驗和行業的人際關係網路。在產品的設計方面，這個行業專家提供很多寶貴的意見。在目前很多的軟體的開發過程中都採用了這種方式。
行業專家有兩種：一種是在這個行業中有很深的資歷，但是對軟體技術並不熟悉；第二種是開發過同類軟體的軟體專家，這種人在開發同類軟體過程中已經積累了大量的專案經驗，並且具有軟體開發的知識。這種方式是獲取需求的最好的方式。
分析對比同類軟體，微軟在開發office、visual studio的時候，也是參照了lotus和borland的成熟產品。這種方式的特點在於成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。
需求的衝突
有的時候，雖然已經將使用者分類並選出了使用者代表。但是需求的**眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來後，人們難以解決衝突，澄清模糊之處以及協調不一致之處。
某些人還要對不可避免要發生的範圍問題單獨作出決定。在專案的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權並且有責任來作出決策，或者授權的個人不願意或不能作出決策，那麼決策者的角色將自然而然地落在開發者身上。
這是乙個非常糟糕的選擇，因為開發者通常沒有足夠多的資訊和觀點來作出業務上的決策。
在軟體專案中，誰將對需求作出決策的問題並沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用使用者代表這一手段，必須解決來自不同使用者類的相衝突的需求。
通常，應盡可能由處於公司底層的人作出決策，因為他們與問題密切相關，並能得到關於這些問題的廣泛資訊。
如果不同的使用者類有不一致的需求，那麼必須決策出滿足哪一類使用者的需求更為重要。了解可能使用產品的客戶種類的資訊和他們的用法與產品的業務目標的關係如何，將有助於你決定哪乙個使用者類所佔份額最大。
當開發者想象中的產品與客戶需求衝突時，通常應該由客戶作出決策。然而，不要陷到「客戶總是對的」的陷阱中去，對他們百依百順。現實中，客戶並不總是對的。
客戶總是持有自己的觀點，開發者必須理解並尊重這一觀點。
用例 在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由於用例的範圍決定的。用例像是乙個黑盒，它沒有包括任何和實現有關或是內部的一些資訊。
它很容易就被使用者（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的資訊來支援系統的開發，就有必要把用例黑盒開啟，審視其內部的結構，找出黑盒內部的actor和用例。就這樣通過不斷的開啟黑盒，分析黑盒，再開啟新的黑盒。
直到整個系統可以被清晰的了解為止。
為什麼要採用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的互動，在系統內部也往往存在著複雜的互動。因此，在系統建模時，除了描述系統與外界的互動，同時還要描述系統內部的互動。
傳統的mis系統中，系統與外界的互動較多。典型的，如atm取款機：存在著大量的使用者與atm，atm與其它系統的互動。
而電信領域的系統，與外界的互動較少。例如，系統的輸入可能僅僅是從交換機上採集資訊，然後由系統進行處理。系統的複雜邏輯包含在系統內部處理的流程上，而非與外部系統的互動。
建模主要任務是表達系統內部的互動。
用例圖適於表達互動，之所以上面使用了電信系統，是因為用例最早來自於ericsson的交換機系統。當時，還是ericsson雇員的jacobson初步建立了用例圖的概念，並於2023年提出了oose方法，其最大特點是面向用例（use-case），並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要**，比較適合支援商業工程和需求分析。
隨著用例的發展，用例被大量的用於對功能進行描述。每個用例代表了系統與外部actor的互動。可以採取順序圖來表達用例的具體操作程式。
actor用於確定系統的邊界。
actor、用例可以從不同的層次來描述資訊。採用該原則的原因有：
1. 需求並不是在專案一開始就很明確，往往是隨著專案的推進，逐漸細化。
2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。採用不同的層次來描述，適於認知的過程。 使用用例開發系統的一般過程
在開發過程的初始階段，可以根據具體的專案特點，制訂開發各個檢視之間的關聯原則，指導規範。在開發的過程中，檢視的組織原則應不斷進行維護、更新。
識別actor來識別系統與外界互動的實體。actor具有特定領域的特徵，例如：交換機（採集系統）、97資訊系統等。在系統層次的actor確定了系統的邊界。
識別用例。同actor一樣，用例具有不同層次。對較為概括的usecase，需要細化。
當用例細化到可以被理解的層次。需要基於用例進行下一步的開發。如前面提到的，用例主要用來描述互動。
因此，存在互動的實體和互動的細節。互動的實體採用類圖來描述；而互動的細節，採用順序圖來描述。
當系統複雜到一定層次時，類圖和順序圖可能不能足以描述其複雜程度。在該情況下，需要使用狀態圖來輔助闡述。狀態圖和順序圖之間使用事件聯結在一起。
它們之間的一致性問題，目前uml和rose沒有提供解決方案。相對折衷的方法是使用事件的命名規範強制一致性。
報表怎麼做,財務報表怎麼做
報表是各個企業 各個職位常常涉及到的，乙份漂亮的報表往往要耗費不少精力，運用很多經驗。尤其是複雜的財務報表。如何在報表中建立美觀的圖表樣式，最終能夠獨立生成專業美觀的資料分析報表?本文就來分析報表怎麼做。報表製作有幾個步驟，其流程如下。1.建立乙個新的報表檔案。報表軟體finereport還提供了財...
新課程改革下,教師該怎麼做
新課程改革下，教師該怎麼做？新泰市新汶中學紀豔梅 2010年7月30日 10 16 隨著新課改在我校的全面鋪開,我對於新課程的主要模組和其選擇性 時代性等有了初步的了解，終於我明白了我們為什麼要實行課改，我真正改變了我對新課改的看法 豐富的活動 多樣的教材，全新的授課理念，在專家的講解以及課改區老師...
服裝生意怎麼做
服裝生意怎麼做 現在服裝生意好做嗎 做服裝生意如何起步 至於什麼樣的行業最賺錢，我的理解只有一點，任何行業都賺錢，只要你做到行業的第一名！可能這樣說比較難做到，那我們 如何才能賺錢更容易呢？服裝生意怎麼做 現在服裝生意好做嗎 做服裝生意如何起步是人們最想的事，每個人都在想，每個人都想知道。但是你知道...