軟件測試之怎么做需求分析[3]

關鍵字：需求分析 方法

　　用例在需求分析中的使用

　　多年來，分析者總是利用情節或經歷來描述用戶和軟件系統的交互方式，從而獲取需求(McGraw and Harbison 1997)。Ivar Jacobson(1992)把這種看法系統地闡述成用例(用例)的方法進行需求獲取和建模。雖然用例來源于面向對象的開發環境，但是它也能應用在具有許多開發方法的項目中，因為用戶并不關心你是怎樣開發你的軟件。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什么遠遠強于詢問用戶希望系統為他們做什么這一傳統方法。 用例的重要功能是用畫用例圖的功能來鑒別和劃分系統功能。它把系統分成角色(actor)和用例(用例)。角色(actor)表示系統用戶能扮演的角色(role)。這些用戶可能是人，可能是其他的計算機一些硬件或者甚至是其它軟件系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分并接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應采取的補救措施。 這樣說可能會非常復雜，其實一個用例描述了系統和一個角色(actor)的交互順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:

　　用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。

　　用例由角色激活，并提供確切的值給角色。

　　用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。在UML中，用例表示為一個橢圓。

　　角色是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例(例如有很多個銷售員)，但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，一個高級營銷人員既可以是貿易經理，也可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理角色時，應考慮其作用，而不是人或工作名稱，這一點是很重要的。

　　我們使用不帶箭頭的線段將角色與用例連接到一起，表示兩者之間交換信息，稱之為通信聯系。角色觸發用例，并與用例進行信息交換。單個角色可與多個用例聯系;反過來，一個用例可與多個角色聯系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡管執行的，但角色未必是人。例如，角色也可以是一個外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進行交互。

　　一個用例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個用例是相關的用法說明的集合，并且一個說明(scenario)是用例的實例。這種關系就像是類和對象的關系。在用例中，一個說明被視為事件的普通過程(normal course)，也叫作主過程，基本過程，普通流，或“滿意之路” (happy path)。在描述普通過程時列出執行者和系統之間相互交互或對話的順序。當這種交互結束時，執行者也達到了預期的目的。

　　在用例中的其它說明可以描述為可選過程(alternative coruse)?？蛇x過程也可促進成功地完成任務，但它們代表了任務的細節或用于完成任務的途徑的變化部分。在交互序列中，普通過程可以在一些決策點上分解成可選過程，然后再重新匯成一個普通過程。

　　角色類和角色實例

　　軟件產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟件目標組織中所處的地位不同，地理位置不同，業務熟練程度不同。

　　不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率?？紤]到用戶的差異性，將用戶分類并研究用戶類的行為特征是非常有必要的。所以在做具體的需求之前，先將用戶分局行為和特點進行分類，對于研究、收集用戶的需求是非常有幫助的。

原文轉自：http://www.anti-gravitydesign.com