在具體的研究需求分析之前，我們先了解一下軟件工程這個概念。軟件工程分為三個層次，過程層、方法層、工具層。在最基礎的過程層，最重要的就是一組被稱為關鍵過程區域（KPAs）的框架（KPA的概念在討論CMM的書中有詳細的概念說明）。關鍵過程區域構成了軟件項目的管理控制的基礎，并且確立了上下文各區域的關系，其中規定了技術方法的采用、工程產品的，模型、文檔、數據、報告、表格等，等的產生、里程碑的建立、質量的保證及變化的適當管理。方法層主要是過程在技術上的實現。它解決的問題是如何做。軟件工程方法涵蓋了一系列的任務：需求分析、設計、編程、測試、維護。同時他還包括了一組基本原則，控制了每一個的關鍵過程區域。工具層就很好理解了，他對過程層和方法層提供了自動和半自動的支持。這些輔助工具就稱為CASE。
　　可以看到需求分析的位置，但是事實上需求分析是跨越了軟件工程的三個層次的。這一點是和其他的過程是一樣的。當然我們這里比較重點強調的是在軟件工程的方法層，同時也涉及到一些過程層的思想，至于工具層則不再我們的討論之列，但是會提到一些很適合在需求分析時應用的工具，諸如Word、Excel、Visio等。
方法
　　需求分析都包括了哪些方法呢？這里列舉出在《需求分析》一書中推薦的一些方法，
　　1) 繪制系統關聯圖，這種關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質流。
　　2) 創建用戶接口原型，當開發人員或用戶不能確定需求時，開發一個用戶接口原型—一個可能的局部實現—這樣使得許多概念和可能發生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。
　　3) 分析需求可行性，在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。 　　4) 確定需求的優先級別，應用分析方法來確定使用實例、產品特性或單項需求實現的優先級別。以優先級為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。
　　5) 為需求建立模型，需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
　　6) 創建數據字典，數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確保客戶與開發小組是使用一致的定義和術語。分析和設計工具通常包括數據字典組件。
　　7) 使用質量功能調配，（QFD）是一種高級系統技術，它將產品特性、屬性與對客戶的重要性聯系起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現了會給客戶帶去驚喜，但若未實現也不會受到責備（Zultner 1993;Pardee 1996）。
　　記住一點，不要試圖在你的項目中把這些方法都用上去，四個現代化并不是一夜就可以實現的。同樣，嘗試著使用你認為對你很有幫助的方法，確實收到效果之后，在考慮繼續學習方法。因為上面提到的都是需求分析的大方法，事實上還有很多很多的方法可以采用，例如，采用SRS模板、指明需求的來源、為每項需求注上標號、記錄業務規范、創建需求跟蹤能力矩陣、審查需求文檔、以需求為依據編寫測試用例、編寫用戶手冊、確定合格的標準。
業務建模
　　很多人都沒有意識到業務需求階段應該做些什么事情，實際上業務建模是最重要的一件事情。不要覺得業務建模這個詞很深奧，讓人模不著頭腦。其實所有做過需求分析的人都做過業務建模，比如你了解企業的運作模式就?是一種你腦海中的業務建模。但是大多數人都沒有科學的、系統的、文檔化的做過業務建模。
　　業務建模的目的在于：
　　了解目標組織（將要在其中部署系統的組織）的結構及機制。
　　了解目標組織中當前存在的問題并確定改進的可能性。
　　確保客戶、最終用戶和開發人員就目標組織達成共識。
　　導出支持目標組織所需的業務需求。
　　上面的話是不是很抽象呢，其實沒有什么復雜的：人和電腦是完全不同的思想（思維方式）。所以，原先適合人的業務流程對于計算機來說可不一定合適的，為了最大限度的利用計算機，必須要了解原先的業務流程并對此加易改造（流程自動化），當然這些動作需要得到用戶的許可。有些人認為說只有ERP這種大系統才需要對業務流程進行重組，但是實際上，不論是部門級的MIS系統，還是社會級的電子商務系統，都需要對業務流程進行改造，所不同的只是改造的程度。
　　業務建模很重要的一點是在分析企業流程的同時分析出基礎企業對象（Common Business Object）（這個詞我翻譯的不好，如果大家有更好的翻譯，請告訴我）。任何企業都有最基礎的一些元素，例如銀行的CBO就有帳戶，制造業的CBO就有訂單等。有一次我的一個在企業應用方面研究多年的朋友告訴我一個秘訣，他說，企業的CBO無非是4個：客戶、員工、產品和供應商（銀行的供應商應該稱為同業）。其他的所有CBO都是在這四個CBO的基礎上發展起來的。比如說CBO中客戶和產品是多對多的關系，根據關系數據的理論，任何多對多的關系都可以拆分成多個一對多或一對一的關系。你就可以在這兩個類之間引入訂單類，客戶和訂單之間是一對多，訂單和產品之間又是一對多，這樣一個多對多的關系就拆分成兩個一對多的關系，而新的訂單類也就順理成章的產生了。在訂單類產生時，你可能還會加入一個關聯類：業務員類。而業務員類又是從員工類繼承下來的。所以呢，企業的四種CBO通過不同的組合，不同的關系，能夠形成企業運作的許許多多的CBO。
　　CBO是做業務建模的基礎，在此基礎上，通過評估業務狀態，說明當前業務，確定業務流程，改進業務流程的定義，設計業務流程實現，改進角色和職責，研究流程自動化，開發領域模型等一系列在RUP中定義的工作流程實現業務建模的目標。
需求獲取
　　需求獲取(requirement elicitation)是需求工程的主體。對于所建議的軟件產品，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。獲取用戶需求位于軟件需求三個層次的中間一層。業務需求決定用戶需求，它描述了用戶利用系統需要完成的任務。從這些任務中，分析者能獲得用于描述系統活動的特定的軟件功能需求，這些系統活動有助于用戶執行他們的任務。 需求獲取是在問題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大量的返工。把需求獲取集中在用戶任務上—而不是集中在用戶接口上—有助于防止開發組由于草率處理設計問題而造成的失誤。 需求獲取、分析、編寫需求規格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復的。當你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息（需求獲取）。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯系（分析）。然后，你可以使客戶信息結構化，并編寫成文檔和示意圖（說明）。下一步，就可以讓客戶代表評審文檔并糾正存在的錯誤（驗證）。這四個過程貫穿著需求分析的整個階段。 需求獲取可能是軟件開發中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶—開發者的合作才能成功。分析者必須建立一個對問題進行徹底探討的環境，而這些問題與產品有關。為了方便清晰地進行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需要一種技術，利用這種技術不但考慮了問題的功能需求方面，還可討論項目的非功能需求。確定用戶已經理解：對于某些功能的討論并不意味著即將在產品中實現它。對于想到的需求必須集中處理并設定優先級?，以避免一個不能帶來任何益處的無限大的項目。 需求獲取是一個需要高度合作的活動，而并不是客戶所說的需求的簡單謄本。作為一個分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴充（open-ended）的問題有助于你更好地理解用戶目前的業務過程并且知道新系統如何幫助或改進他們的工作。調查用戶任務可能遇到的變更，或者用戶需要使用系統其它可能的方式。想像你自己在學習用戶的工作，你需要完成什么任務？你有什么問題？從這一角度來指導需求的開發和利用。
　　還有，探討例外的情況：什么會妨礙用戶順利完成任務？對系統錯誤情況的反映，用戶是如何想的？詢問問題時，以“還有什么能” ,”當?時，將會發生什么”“你有沒有曾經想過” ,“有沒有人曾經”為開頭。記下每一個需求的來源，這樣向下跟蹤直到發現特定的客戶。
　　有些時候，嘗試著問一些“愚蠢”的問題也有助于客戶打開話匣子。如果你直接要求客戶寫出業務是如何實現的，客戶十有八九無法完成。但是如果你嘗試著問一些實際的問題，例如：“以我的理解，你們收到訂單后，會...”。客戶立刻就會指出你的錯誤，并滔滔不絕的開始談論業務，而你，就在一邊仔細的聆聽吧。這一招就叫做“拋磚引玉”。
　　需求討論會上必須要使用筆記本電腦，還要指定一個打字熟練的人把所有的討論記錄下來，記錄的同時還要做一定的整理。如果不這樣做，那么你結束會議的時候就會發現，所有的討論只剩下一個模糊的印象，需求對你來說仍然是一件遙遠的事情。在座談討論之后，記下所討論的條目(item)，并請參與討論的用戶評論并更正。及早并經常進行座談討論是需求獲取成功的一個關鍵途徑，因為只有提供需求的人才能確定是否真正獲取需求。進行深入收集和分析以消除任何沖突或不一致性。
　　盡量把客戶所持的假設解釋清楚，特別是那些發生沖突的部分。從字里行間去理解以明確客戶沒有表達清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下文無關問題”—這是一個高層次的問題，它可以獲取業務問題和可能的解決方案的全部信息。客戶對這些問題的回答諸如“產品要求怎樣的精確度”或“你能幫我解釋一下你為什么不同意某人的回答嗎？”這些回答可以更直接地認識問題，而這是封閉（close-end）問題所不能做到的。
　　需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟件解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間采用了更多的交流方式（Kiel and Carmel 1995）。與單個客戶或潛在的用戶組一起座談，對于業務軟件包或信息管理系統（MIS）的應用來說是一種傳統的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入（buy-in）的一種方式。
　　盡量理解用戶用于表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，并提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。
　　在需求獲取的過程中，你可能會發現對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業務和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那么客戶將會提出很重要的但又在當前產品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的范圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。 正如經常所說的，需求主要是關于系統做什么，而解決方案如何實現是屬于設計的范圍。這樣說雖然很簡潔，但似乎過于簡單化。需求的獲取應該把重點放在“做什么”上，但在分析和設計之間還是存在一定的距離。你可以使用假設“怎么做”來分類并改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然后提供一個尋找錯誤和遺漏的辦法。把你在需求開發階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。 需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。相反地，從極少的代表那里收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最?好的權衡在于選擇一些授權為他們的用戶類發言的產品代表者，他們也被同組用戶類的其它代表所支持。 沒有一個簡單、清楚的信號暗示你什么時候已完成需求獲取。當客戶和開發者與他們的同事聊天、閱讀工業和商業上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。
　　1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。
　　2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。 　　3. 如果用戶開始重復原先討論過的問題，此時，也許你就完成了收集需求的工作。
　　4. 如果所提出的新需求比你已確定的需求的優先級都低時，也許你就完成了收集需求的工作。
　　5. 如果用戶提出對將來產品的要求，而不是現在我們討論的特定產品，也許你就完成了收集需求的工作。
　　以上知識大致上討論需求分析應該如何做，實際上對于需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的應用主要還是要靠個人。所以，大家在實際應用的時候，不妨結合自己的實際，有選擇性的采用一些方法，那你就是成功的。

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

　　為什么要采用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上采集信息，然后由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。
　　用例圖適于表達交互，之所以上面使用了電信系統，是因為用例最早來自于Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，并于1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的 用于對功能進行描述。每個用例代表了系統與外部ACTOR的交互。可以采取順序圖來表達用例的具體操作程序。ACTOR用于確定系統的邊界。
　　ACTOR、用例可以從不同的層次來描述信息。采用該原則的原因有：
　　1. 需求并不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。
　　2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。采用不同的層次來描述，適于認知的過程。 使用用例開發系統的一般過程
　　在開發過程的初始階段，可以根據具體的項目特點，制訂開發各個視圖之間的關聯原則，指導規范。在開發的過程中，視圖的組織原則應不斷進行維護、更新。
　　識別ACTOR來識別系統與外界交互的實體。ACTOR具有特定領域的特征，例如：交換機（采集系統）、97信息系統等。在系統層次的ACTOR確定了系統的邊界。
　　識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。注：系統開發需要一定的規則來確定，如何來分解用例；可能基于原有系統的經驗，或是參考現有資料。
　　當用例細化到可以被理解的層次。需要基于用例進行下一步的開發。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節。交互的實體采用類圖來描述；而交互的細節，采用順序圖來描述。
　　當系統復雜到一定層次時，類圖和順序圖可能不能足以描述其復雜程度。在該情況下，需要使用狀態圖來輔助闡述。狀態圖和順序圖之間使用事件聯結在一起。它們之間的一致性問題，目前UML和ROSE沒有提供解決方案。相對折衷的方法是使用事件的命名規范強制一致性。
　　可以說，之前說的所有的東西都是為了能夠導出用例在需求中的作用。用例是從用戶的角度看待系統，而不是基于程序員的角度。這樣的話，用例驅動的系統能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統開發鏈中完整的體現。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。 從前，系統開發者總是通過情節來獲取需求，是問用戶希望系統為他做什么。在Jacobson發明了用例的概念之后，需求獲取就變成問用戶要利用系統做什么。這是立場不同導致的結果。用戶通常并不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源于用戶，服務于用戶，但是它同樣可以用于開發的流程。當系統的開發過程都是基于用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。 用例和用例文檔
　　《軟件需求》一書中提到了幾種方法來確定用例：
　　首先明確執行者和他們的角色，然后確定業務過程，在這一過程中每一個參與者都在為確定用例而努力。
　　確定系統所能反映的外部事件，然后把這些事件與參與的執行者和特定的用例聯系起來。
　　以特定的說明形式表達業務過程或日常行為，從這些說明中獲得用例，并確定參與到用例中的執行者，有可能從現在的功能需求說明中獲得用例。如果有些需求與用例不一致，就應考慮是否真的需要它們。
　　用例代表了用戶的需求，在你的系統中，應該直接從不同用戶類的代表或至少應從代理那里收集需求。用例為表達用戶需求提供了一種方法，而這一方法必須與系統的業務需求相一致。分析者和用戶必須檢查每一個用例，在把它們納入需求之前決定其是否在項目所定義的范圍內。基于“用例”方法進行需求獲取的目的在于：描述用戶需要使用系統完成的所有任務。在理論上，用例的結果集將包括所有合理的系統功能。在現實中，你不可能獲得完全包容，但是比起我所知道的其它獲取方法，基于用例的方法可以為你帶來更好的效果。 當使用用例進行需求獲取時，應避免受不成熟的細節的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節都作為需求記錄下來，他們會給隨后的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發過程中，將會詳盡闡述他們的需求。在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，并作為用例。然后，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和用戶對質量的期望。雖然最初的屏幕構思有助于描述你對需求的理解，但是你必須細化用戶界面設計。 建立用例文檔。在每一次的需求獲取之后，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術能夠提高你的速度和需求的復用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標識號、用例名稱、父用例標志號、創建者、創建時間、審核者、修訂記錄、角色、說明、先決條件、請求結果、優先級、普通過程、可選過程、例外、非功能需求、假設、注釋和問題。 雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟件系統，并不是一大堆的用例說明。