多年來，分析者總是利用情節或經歷來描述用戶和軟件系統的交互方式，從而獲取需求（McGrawandHarbison1997）。IvarJacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源于面向對象的開發環境，但是它也能應用在具有許多開發方法的項目中，因為用戶并不關心你是怎樣開發你的件。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什么遠遠強于詢問用戶希望系統為他們做什么這一傳統方法。用例的重要功能是用畫用例圖的功能來鑒別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬件或者甚至是其它軟件系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分并接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應采取的補救措施。這樣說可能會非常復雜，其實一個用例描述了系統和一個角色（actor）的交互順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。用例由角色激活，并提供確切的值給角色。用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。在UML中，用例表示為一個橢圓。角色是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例（例如有很多個銷售員），但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，交換。單個角色可與多個用例聯系；反過來，一個用例可與多個角色聯系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡管執行的，但角色未必是人。例如，角色也可以是一個外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進行交互�！�
一個用例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個用例是相關的用法說明的集合，并且一個說明（scenario）是用例的實例。這種關系就像是類和對象的關系。在用例中，一個說明被視為事件的普通過程(normalcourse)，也叫作主過程，基本過程，普通流，或“滿意之路”(happypath)。在描述普通過程時列出執行者和系統之間相互交互或對話的順序。當這種交互結束時，執行者也達到了預期的目的。
在用例中的其它說明可以描述為可選過程(alternativecoruse)�？蛇x過程也可促進成功地完成任務，但它們代表了任務的細節或用于完成任務的途徑的變化部分。在交互序列中，普通過程可以在一些決策點上分解成可選過程，然后再重新匯成一個普通過程。角色類和角色實例。軟件產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟件目標組織中所處的地位不同，地理位置不同，業務熟練程度不同�！�
不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率�？紤]到用戶的差異性，將用戶分類并研求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規模的調查的，只是要把重點放在用戶代表上�！�
確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向后傳，到最后，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。對于和用戶直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟件，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：
做大規模的市場調查，針對你的目標市場做市場調查，并根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些游戲公司會發布一些Demo版的游戲。是對于一般的企業來說，這項工作費時費力，高昂的成本往往使大家知難而退。我的意見是，方法是非常好的，但是可以軟件技術并不熟悉；第二種是開發過同類軟件的軟件專家，這種人在開發同類軟件過程中已經積累了大量的項目經驗，并且具有軟件開發的知識。這種方式是獲取需求的最好的方式。分析對比同類軟件，微軟在開發Office、VisualStudio的時候，也是參照了Lotus和Borland的成熟產品。這種方式的特點在于成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。有的時候，雖然已經將用戶分類并選出了用戶代表。但是需求的來源眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來后，人們難以解決沖突，澄清模糊之處以及協調不一致之處。某些人還要對不可避免要發生的范圍問題單獨作出決定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權并且有責任來作出決策，或者授權的個人不愿意或不能作出決策，那么決策者的角色將自然而然地落在開發者身上。這是一個非常糟糕的選擇，因為開發者通常沒有足夠多的信息和觀點來作出業務上的決策�！�
在軟件項目中，誰將對需求作出決策的問題并沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處于公司底層的人作出決策，因為他們與題密切相關，并能得到關于這些問題的廣泛信息。
如果不同的用戶類有不一致的需求，那么必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助于你決定哪一個用戶類所占份額最大�！�
文章來源于領測軟件測試網 http://www.kjueaiud.com/
