二、業(yè)務(wù)建模

    很多人都沒有意識到業(yè)務(wù)需求階段應(yīng)該做些什么事情，實際上業(yè)務(wù)建模是最重要的一件事情。不要覺得業(yè)務(wù)建模這個詞很深奧，讓人模不著頭腦。其實所有做過需求分析的人都做過業(yè)務(wù)建模，比如你了解企業(yè)的運作模式就?是一種你腦海中的業(yè)務(wù)建模。但是大多數(shù)人都沒有科學的、系統(tǒng)的、文檔化的做過業(yè)務(wù)建模。

    業(yè)務(wù)建模的目的在于：　

    了解目標組織（將要在其中部署系統(tǒng)的組織）的結(jié)構(gòu)及機制。

    了解目標組織中當前存在的問題并確定改進的可能性。

    確保客戶、最終用戶和開發(fā)人員就目標組織達成共識。

    導(dǎo)出支持目標組織所需的業(yè)務(wù)需求。

    上面的話是不是很抽象呢，其實沒有什么復(fù)雜的：人和電腦是完全不同的思想（思維方式）。所以，原先適合人的業(yè)務(wù)流程對于計算機來說可不一定合適的，為了最大限度的利用計算機，必須要了解原先的業(yè)務(wù)流程并對此加易改造（流程自動化），當然這些動作需要得到用戶的許可。有些人認為說只有ERP這種大系統(tǒng)才需要對業(yè)務(wù)流程進行重組，但是實際，不論是部門級的MIS系統(tǒng)，還是社會級的電子商務(wù)系統(tǒng)，都需要對業(yè)務(wù)流程進行改造，所不同的只是改造的程度?！?/p>

    業(yè)務(wù)建模很重要的一點是在分析企業(yè)流程的同時分析出基礎(chǔ)企業(yè)對象（CommonBusinessObject）（這個詞我翻譯的不好，如果大家有更好的翻譯，請告訴我）。任何企業(yè)都有最基礎(chǔ)的一些元素，例如銀行的CBO就有帳戶，制造業(yè)的CB對多，訂單和產(chǎn)品之間又是一對多，這樣一個多對多的關(guān)系就拆分成兩個一對多的關(guān)系，而新的訂單類也就順理成章的產(chǎn)生了。在訂單類產(chǎn)生時，你可能還會加入一個關(guān)聯(lián)類：業(yè)務(wù)員類。而業(yè)務(wù)員類又是從員工類繼承下來的。所以呢，企業(yè)的四種CBO通過不同的組合，不同的關(guān)系，能夠形成企業(yè)運作的許許多多的CBO?！?br /> CBO是做業(yè)務(wù)建模的基礎(chǔ)，在此基礎(chǔ)上，通過評估業(yè)務(wù)狀態(tài)，說明當前業(yè)務(wù)，確定業(yè)務(wù)流程，改進業(yè)務(wù)流程的定義，設(shè)計業(yè)務(wù)流程實現(xiàn)，改進角色和職責，研究流程自動化，開發(fā)領(lǐng)域模型等一系列在RUP中定義的工作流程實現(xiàn)業(yè)務(wù)建模的目標。

    三、需求獲取

    需求獲取(requirementelicitation)是需求工程的主體。對于所建議的軟件產(chǎn)品，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。獲取用戶需求位于軟件需求三個層次的中間一層。業(yè)務(wù)需求決定用戶需求，它描述了用戶利用系統(tǒng)需要完成的任務(wù)。從這些任務(wù)中，分析者能獲得用于描述系統(tǒng)活動的特定的軟件功能需求，這些系統(tǒng)活動有助于用戶執(zhí)行他們的任務(wù)。需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步。獲取需求的一個必不可少的結(jié)果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發(fā)者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開始設(shè)計系統(tǒng)，否則，對需求定義的任何改進，設(shè)計上都必須大量的返工。把需求獲取集中在用戶任務(wù)上—而不是集中在用戶接口上—有助于防止開發(fā)組由于草率處理設(shè)計問題而造成的失誤。需求獲取、分析、編寫需求規(guī)格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復(fù)的。當你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息（需求獲?。?。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，要交流的方面。需求獲取只有通過有效的客戶—開發(fā)者的合作才能成功。分析者必須建立一個對問題進行徹底探討的環(huán)境，而這些問題與產(chǎn)品有關(guān)。為了方便清晰地進行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需要一種技術(shù)，利用這種技術(shù)不但考慮了問題的功能需求方面，還可討論項目的非功能需求。確定用戶已經(jīng)理解：對于某些功能的討論并不意味著即將在產(chǎn)品中實現(xiàn)它。對于想到的需求必須集中處理并設(shè)定優(yōu)先級?，以避免一個不能帶來任何益處的無限大的項目。需求獲取是一個需要高度合作的活動，而并不是客戶所說的需求的簡單謄本。作為一個分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴充（open-ended）的問題有助于你更好地理解用戶目前的業(yè)務(wù)過程并且知道新系統(tǒng)如何幫助或改進他們的工作。調(diào)查用戶任務(wù)可能遇到的變更，或者用戶需要使用系統(tǒng)其它可能的方式。想像你自己在學習用戶的工作，你需要完成什么任務(wù)？你有什么問題？從這一角度來指導(dǎo)需求的開發(fā)和利用。

    還有，探討例外的情況：什么會妨礙用戶順利完成任務(wù)？對系統(tǒng)錯誤情況的反映，用戶是如何想的？詢問問題時，以“還有什么能”,”當?時，將會發(fā)生什么”“你有沒有曾經(jīng)想過”,“有沒有人曾經(jīng)”為開頭。記下每一個需求的來源，這樣向下跟蹤直到發(fā)現(xiàn)特定的客戶。

    有些時候，嘗試著問一些“愚蠢”的問題也有助于客戶打開話匣子。如果你直接要求客戶寫出業(yè)務(wù)是如何實現(xiàn)的，客戶十有八九無法完成。但是如果你嘗試著問一些實際的問題，例如：“以我的理解，你們收到訂單后，會...”?？蛻袅⒖叹蜁赋瞿愕腻e誤，并滔滔不絕的開始談?wù)摌I(yè)務(wù)，而你，就在一邊仔細的聆聽吧。這一招就叫做“拋磚引玉”。

    需求討論會上必須要使用筆記本電腦，還要指定一個打字熟練的人把所有的討論記錄下來，記錄的同時還要做一定的整理。如果不這樣做，那么你結(jié)束會議的時候就會發(fā)現(xiàn)，所有的討論只剩下一個模糊的印象，需求對你來說仍然是一件遙遠的事情。在座談討論之后，記下所討論的條目(item)，并請參與討論的用戶評論并更正。及早并經(jīng)常進行座談討論是需求獲取成功的一個關(guān)鍵途徑，因為只有提供需求的人才能確定是否真正獲取需求。進行深入收集和分析以消除任何沖突或不一致性。

    盡量把客戶所持的假設(shè)解釋清楚，特別是那些發(fā)生沖突的部分。從字里行間去理解以明確客戶沒有表達清楚但又想加入的特性或特征。Gause和Weinberg（1989）提出使用“上下文無關(guān)問題”—這是一個高層次的問題，它可以獲取業(yè)務(wù)問題和可能的解決方案的全部信息?？蛻魧@些問題的回答諸如“產(chǎn)品要求怎樣的精確度”或“你能幫我解釋一下你為什么不同意某人的回答嗎？”這些回答可以更直接地認識問題，而這是封閉（close-end）問題所不能做到的。
 
    需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟件解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發(fā)者和客戶之間采用了更多的交流方式（KielandCarmel1995）。與單個客戶或潛在的用戶組一起座談，對于業(yè)務(wù)軟件包或信息管理系統(tǒng)（MIS）的應(yīng)用來說是一種傳統(tǒng)的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入（buy-in）的一種方式。

    盡量理解用戶用于表述他們需求的思維過程。充分研究用戶執(zhí)行任務(wù)時作出決策的過程，并提取出潛在的邏輯關(guān)系。流程圖和決策樹是描述這些邏輯決策途徑的好方法?！?/p>