在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由于用例的范 圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。
為什么要采用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上采集信息，然后由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。
用例圖適于表達交互，之所以上面使用了電信系統，是因為用例最早來自于Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，并于1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的用于對功能進行描述。每個用例代表了系統與外部ACTOR的交互�？梢圆扇№樞驁D來表達用例的具體操作程序。ACTOR用于確定系統的邊界。
ACTOR、用例可以從不同的層次來描述信息。采用該原則的原因有：
1. 需求并不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。
2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。采用不同的層次來描述，適于認知的過程。
4 需求的沖突
有的時候，雖然已經將用戶分類并選出了用戶代表。但是需求的來源眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來后，人們難以解決沖突，澄清模糊之處以及協調不一致之處。某些人還要對不可避免要發生的范圍問題單獨作出決定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權并且有責任來作出決策，或者授權的個人不愿意或不能作出決策，那么決策者的角色將自然而然地落在開發者身上。這是一個非常糟糕的選擇，因為開發者通常沒有足夠多的信息和觀點來作出業務上的決策。
在軟件項目中，誰將對需求作出決策的問題并沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處于公司底層的人作出決策，因為他們與問題密切相關，并能得到關于這些問題的廣泛信息。
如果不同的用戶類有不一致的需求，那么必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助于你決定哪一個用戶類所占份額最大。
當開發者想象中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到“客戶總是對的”的陷阱中去，對他們百依百順�，F實中，客戶并不總是對的�？蛻艨偸浅钟凶约旱挠^點，開發者必須理解并尊重這一觀點。
5 角色類和角色實例
軟件產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟件目標組織中所處的地位不同，地理位置不同，業務熟練程度不同。
不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率�？紤]到用戶的差異性，將用戶分類并研究用戶類的行為特征是非常有必要的。所以在做具體的需求之前，先將用戶分局行為和特點進行分類，對于研究、收集用戶的需求是非常有幫助的。
可以利用一個簡單的表格列出一些原始的分類，然后不斷的完善這個表格。確認你的分類之間沒有交集。并充分描述用戶分類的行為，目的，要求等。在企業分析中，比較常見的分類可能包括，供應商，客戶，部門等。
就像C++中的類和對象一樣，我們把分析出的用戶分類稱為“角色類”，把實際的用戶稱為“角色實例”。在得到用戶分類之后，最重要的就是要選出用戶代表，用戶代表不僅僅是在需求階段中參與項目，還必須對項目的全過程負責。用戶代表能夠代表用戶分類的需求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規模的調查的，只是要把重點放在用戶代表上。
確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向后傳，到最后，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。
對于和用戶直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟件，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：
做大規模的市場調查，針對你的目標市場做市場調查，并根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些游戲公司會發布一些Demo版的游戲�？墒菍τ谝话愕钠髽I來說，這項工作費時費力，高昂的成本往往使大家知難而退。我的意見是，方法是非常好的，但是可以采用折衷的辦法，例如選取有代表性的企業，為特定企業制作一個較小的版本并收集反饋意見等。這涉及到很多市場營銷的內容，并不是我的專業所長，這里就不多弄斧了。
聘請行業專家，一個行業專家往往可以在項目需求方面發揮極為重要的作用。一個行業專家往往都有大量的行業經驗和行業的人際關系網絡。在產品的設計方面，這個行業專家提供很多寶貴的意見。在目前很多的軟件的開發過程中都采用了這種方式。行業專家有兩種：一種是在這個行業中有很深的資歷，但是對軟件技術并不熟悉；第二種是開發過同類軟件的軟件專家，這種人在開發同類軟件過程中已經積累了大量的項目經驗，并且具有軟件開發的知識。這種方式是獲取需求的最好的方式。 分析對比同類軟件，微軟在開發Office、Visual Studio的時候，也是參照了Lotus和Borland的成熟產品。這種方式的特點在于成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
