怎么做需求分析（下）

用例在需求分析中的使用

多年來，分析者總是利用情節或經歷來描述用戶和軟件系統的交互方式，從而獲取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源于面向對象的開發環境，但是它也能應用在具有許多開發方法的項目中，因為用戶并不關心你是怎樣開發你的軟件。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什么遠遠強于詢問用戶希望系統為他們做什么這一傳統方法。

用例的重要功能是用畫用例圖的功能來鑒別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬件或者甚至是其它軟件系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分并接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應采取的補救措施。

這樣說可能會非常復雜，其實一個用例描述了系統和一個角色（actor）的交互順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:

用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。
用例由角色激活，并提供確切的值給角色。

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

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

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

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

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

角色類和角色實例

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

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

可以利用一個簡單的表格列出一些原始的分類，然后不斷的完善這個表格。確認你的分類之間沒有交集。并充分描述用戶分類的行為，目的，要求等。在企業分析中，比較常見的分類可能包括，供應商，客戶，部門等。

就像C++中的類和對象一樣，我們把分析出的用戶分類稱為“角色類”，把實際的用戶稱為“角色實例”。在得到用戶分類之后，最重要的就是要選出用戶代表，用戶代表不僅僅是在需求階段中參與項目，還必須對項目的全過程負責。用戶代表能夠代表用戶分類的需求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規模的調查的，只是要把重點放在用戶代表上。

確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向后傳，到最后，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。

對于和用戶直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟件，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：

做大規模的市場調查，針對你的目標市場做市場調查，并根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些游戲公司會發布一些Demo版的游戲?？墒菍τ谝话愕钠髽I來說，這項工作費時費力，高昂的成本往往使大家知難而退。我的意見是，方法是非常好的，但是可以采用折衷的辦法，例如選取有代表性的企業，為特定企業制作一個較小的版本并收集反饋意見等。這涉及到很多市場營銷的內容，并不是我的專業所長，這里就不多弄斧了。

聘請行業專家，一個行業專家往往可以在項目需求方面發揮極為重要的作用。一個行業專家往往都有大量的行業經驗和行業的人際關系網絡。在產品的設計方面，這個行業專家提供很多寶貴的意見。在目前很多的軟件的開發過程中都采用了這種方式。行業專家有兩種：一種是在這個行業中有很深的資歷，但是對軟件技術并不熟悉；第二種是開發過同類軟件的軟件專家，這種人在開發同類軟件過程中已經積累了大量的項目經驗，并且具有軟件開發的知識。這種方式是獲取需求的最好的方式。

分析對比同類軟件，微軟在開發Office、Visual Studio的時候，也是參照了Lotus和Borland的成熟產品。這種方式的特點在于成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。

需求的沖突

有的時候，雖然已經將用戶分類并選出了用戶代表。但是需求的來源眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來后，人們難以解決沖突，澄清模糊之處以及協調不一致之處。某些人還要對不可避免要發生的范圍問題單獨作出決定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權并且有責任來作出決策，或者授權的個人不愿意或不能作出決策，那么決策者的角色將自然而然地落在開發者身上。這是一個非常糟糕的選擇，因為開發者通常沒有足夠多的信息和觀點來作出業務上的決策。

在軟件項目中，誰將對需求作出決策的問題并沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處于公司底層的人作出決策，因為他們與問題密切相關，并能得到關于這些問題的廣泛信息。

如果不同的用戶類有不一致的需求，那么必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助于你決定哪一個用戶類所占份額最大。

當開發者想象中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到“客戶總是對的”的陷阱中去，對他們百依百順?，F實中，客戶并不總是對的?？蛻艨偸浅钟凶约旱挠^點，開發者必須理解并尊重這一觀點。

用例

在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由于用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。

為什么要采用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上采集信息，然后由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。

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