二、業務建模
很多人都沒有意識到業務需求階段應該做些什么事情，實際上業務建模是最重要的一件事情。不要覺得業務建模這個詞很深奧，讓人模不著頭腦。其實所有做過需求分析的人都做過業務建模，比如你了解企業的運作模式就?是一種你腦海中的業務建模。但是大多數人都沒有科學的、系統的、文檔化的做過業務建模。
業務建模的目的在于：
了解目標組織（將要在其中部署系統的組織）的結構及機制。
了解目標組織中當前存在的問題并確定改進的可能性。
確�？蛻�、最終用戶和開發人員就目標組織達成共識。
導出支持目標組織所需的業務需求。
上面的話是不是很抽象呢，其實沒有什么復雜的：人和電腦是完全不同的思想（思維方式）。所以，原先適合人的業務流程對于計算機來說可不一定合適的，為了最大限度的利用計算機，必須要了解原先的業務流程并對此加易改造（流程自動化），當然這些動作需要得到用戶的許可。有些人認為說只有ERP這種大系統才需要對業務流程進行重組，但是實際，不論是部門級的MIS系統，還是社會級的電子商務系統，都需要對業務流程進行改造，所不同的只是改造的程度�！�
業務建模很重要的一點是在分析企業流程的同時分析出基礎企業對象（CommonBusinessObject）（這個詞我翻譯的不好，如果大家有更好的翻譯，請告訴我）。任何企業都有最基礎的一些元素，例如銀行的CBO就有帳戶，制造業的CB對多，訂單和產品之間又是一對多，這樣一個多對多的關系就拆分成兩個一對多的關系，而新的訂單類也就順理成章的產生了。在訂單類產生時，你可能還會加入一個關聯類：業務員類。而業務員類又是從員工類繼承下來的。所以呢，企業的四種CBO通過不同的組合，不同的關系，能夠形成企業運作的許許多多的CBO�！�
CBO是做業務建模的基礎，在此基礎上，通過評估業務狀態，說明當前業務，確定業務流程，改進業務流程的定義，設計業務流程實現，改進角色和職責，研究流程自動化，開發領域模型等一系列在RUP中定義的工作流程實現業務建模的目標。
三、需求獲取
需求獲取(requirementelicitation)是需求工程的主體。對于所建議的軟件產品，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。獲取用戶需求位于軟件需求三個層次的中間一層。業務需求決定用戶需求，它描述了用戶利用系統需要完成的任務。從這些任務中，分析者能獲得用于描述系統活動的特定的軟件功能需求，這些系統活動有助于用戶執行他們的任務。需求獲取是在問題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大量的返工。把需求獲取集中在用戶任務上—而不是集中在用戶接口上—有助于防止開發組由于草率處理設計問題而造成的失誤。需求獲取、分析、編寫需求規格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復的。當你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息（需求獲�。�。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，要交流的方面。需求獲取只有通過有效的客戶—開發者的合作才能成功。分析者必須建立一個對問題進行徹底探討的環境，而這些問題與產品有關。為了方便清晰地進行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需要一種技術，利用這種技術不但考慮了問題的功能需求方面，還可討論項目的非功能需求。確定用戶已經理解：對于某些功能的討論并不意味著即將在產品中實現它。對于想到的需求必須集中處理并設定優先級?，以避免一個不能帶來任何益處的無限大的項目。需求獲取是一個需要高度合作的活動，而并不是客戶所說的需求的簡單謄本。作為一個分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴充（open-ended）的問題有助于你更好地理解用戶目前的業務過程并且知道新系統如何幫助或改進他們的工作。調查用戶任務可能遇到的變更，或者用戶需要使用系統其它可能的方式。想像你自己在學習用戶的工作，你需要完成什么任務？你有什么問題？從這一角度來指導需求的開發和利用。
還有，探討例外的情況：什么會妨礙用戶順利完成任務？對系統錯誤情況的反映，用戶是如何想的？詢問問題時，以“還有什么能”,”當?時，將會發生什么”“你有沒有曾經想過”,“有沒有人曾經”為開頭。記下每一個需求的來源，這樣向下跟蹤直到發現特定的客戶。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
