在需求獲取的過程中，你可能會發(fā)現(xiàn)對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業(yè)務和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那么客戶將會提出很重要的但又在當前產品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的范圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。正如經常所說的，需求主要是關于系統(tǒng)做什么，而解決方案如何實現(xiàn)是屬于設計的范圍。這樣說雖然很簡潔，但似乎過于簡單化。需求的獲取應該把重點放在“做什么”上，但在分析和設計之間還是存在一定的距離。你可以使用假設“怎么做”來分類并改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然后提供一個尋找錯誤和遺漏的辦法。把你在需求開發(fā)階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統(tǒng)設計者、開發(fā)者和可視化設計者等主要工程角色。相反地，從極少的代表那里收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最?好的權衡在于選擇一些授權為他們的用戶類發(fā)言的產品代表者，他們也被同組用戶類的其它代表所支持。沒有一個簡單、清楚的信號暗示你什么時候已完成需求獲取。當客戶和開發(fā)者與他們的同事聊天、閱讀工業(yè)和商業(yè)上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點?！?/p>

    1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。　

    2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。　

    3. 如果用戶開始重復原先討論過的問題，此時，也許你就完成了收集需求的工作。

    4. 如果所提出的新需求比你已確定的需求的優(yōu)先級都低時，也許你就完成了收集需求的工作?！?/p>

    5. 如果用戶提出對將來產品的要求，而不是現(xiàn)在我們討論的特定產品，也許你就完成了收集需求的工作?！?/p>

    以上知識大致上討論需求分析應該如何做，實際上對于需求分析的方法有很多很多，已經形成了一定的用例在需求分析中的使用。

    多年來，分析者總是利用情節(jié)或經歷來描述用戶和軟件系統(tǒng)的交互方式，從而獲取需求（McGrawandHarbison1997）。IvarJacobson（1992）把這種看法系統(tǒng)地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源于面向對象的開發(fā)環(huán)境，但是它也能應用在具有許多開發(fā)方法的項目中，因為用戶并不關心你是怎樣開發(fā)你的件。而最重要的，用例的觀點和思維過程帶給需求開發(fā)的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統(tǒng)做什么遠遠強于詢問用戶希望系統(tǒng)為他們做什么這一傳統(tǒng)方法。用例的重要功能是用畫用例圖的功能來鑒別和劃分系統(tǒng)功能。它把系統(tǒng)分成角色（actor）和用例（用例）。角色(actor)表示系統(tǒng)用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬件或者甚至是其它軟件系統(tǒng)，唯一的標準是它們必須要在被劃分進用例的系統(tǒng)部分以外。它們必須能刺激系統(tǒng)部分并接收返回。用例描述了當角色給系統(tǒng)特定的刺激時系統(tǒng)的活動。這些活動被文本描述。它描述了觸發(fā)用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統(tǒng)應采取的補救措施。這樣說可能會非常復雜，其實一個用例描述了系統(tǒng)和一個角色（actor）的交互順序。用例被定義成系統(tǒng)執(zhí)行的一系列動作，動作執(zhí)行的結果能被指定角色察覺到。用例可以:用例捕獲某些用戶可見的需求，實現(xiàn)一個具體的用戶目標。用例由角色激活，并提供確切的值給角色。用例可大可小，但它必須是對一個具體的用戶目標實現(xiàn)的完整描述。在UML中，用例表示為一個橢圓。角色是指用戶在系統(tǒng)中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例（例如有很多個銷售員），但就該系統(tǒng)而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，交換。單個角色可與多個用例聯(lián)系；反過來，一個用例可與多個角色聯(lián)系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡管執(zhí)行的，但角色未必是人。例如，角色也可以是一個外界系統(tǒng)，該外界系統(tǒng)可能需要從當前系統(tǒng)中獲取信息，與當前系統(tǒng)有進行交互。　

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

    在用例中的其它說明可以描述為可選過程(alternativecoruse)?？蛇x過程也可促進成功地完成任務，但它們代表了任務的細節(jié)或用于完成任務的途徑的變化部分。在交互序列中，普通過程可以在一些決策點上分解成可選過程，然后再重新匯成一個普通過程。角色類和角色實例。軟件產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟件目標組織中所處的地位不同，地理位置不同，業(yè)務熟練程度不同?！?br />  
    不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率。考慮到用戶的差異性，將用戶分類并研求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規(guī)模的調查的，只是要把重點放在用戶代表上?！?/p>

    確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向后傳，到最后，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。對于和用戶直接溝通這一點，一般的針對特定企業(yè)的應用系統(tǒng)當然是不成問題，可是如果是開發(fā)行業(yè)軟件，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：