需求分析概述
在具體的研究需求分析之前，我們先了解一下軟件工程這個概念。軟件工程分為三個層次，過程層、方法層、工具層。在最基礎的過程層，最重要的就是一組被稱為關(guān)鍵過程區(qū)域（KPAs）的框架（KPA的概念在討論CMM的書中有詳細的概念說明）。關(guān)鍵過程區(qū)域構(gòu)成了軟件項目的管理控制的基礎，并且確立了上下文各區(qū)域的關(guān)系，其中規(guī)定了技術(shù)方法的采用、工程產(chǎn)品的，模型、文檔、數(shù)據(jù)、報告、表格等，等的產(chǎn)生、里程碑的建立、質(zhì)量的保證及變化的適當管理。方法層主要是過程在技術(shù)上的實現(xiàn)。它解決的問題是如何做。軟件工程方法涵蓋了一系列的任務：需求分析、設計、編程、測試、維護。同時他還包括了一組基本原則，控制了每一個的關(guān)鍵過程區(qū)域。工具層就很好理解了，他對過程層和方法層提供了自動和半自動的支持。這些輔助工具就稱為CASE。 可以看到需求分析的位置，但是事實上需求分析是跨越了軟件工程的三個層次的。這一點是和其他的過程是一樣的。當然我們這里比較重點強調(diào)的是在軟件工程的方法層，同時也涉及到一些過程層的
思想，至于工具層則不再我們的討論之列，但是會提到一些很適合在需求分析時應用的工具，諸如Word、Excel、Visio等。 方法
需求分析都包括了哪些方法呢？這里列舉出在《需求分析》一書中推薦的一些方法，
1. 繪制系統(tǒng)關(guān)聯(lián)圖，這種關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質(zhì)流。
2. 創(chuàng)建用戶接口原型，當開發(fā)人員或用戶不能確定需求時，開發(fā)一個用戶接口原型—一個可能的局部實現(xiàn)—這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。
3. 分析需求可行性，在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現(xiàn)相聯(lián)系的風險，包括與其它需求的沖突，對外界因素的依賴和技術(shù)障礙。
4. 確定需求的優(yōu)先級別，應用分析方法來確定使用實例、產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先級別。以優(yōu)先級為基礎確定產(chǎn)品版本將包括哪些特性或哪類需求。當允許需求變更時，在
特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。
5. 為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。
6. 創(chuàng)建數(shù)據(jù)字典，數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項以確保客戶與開發(fā)小組是使用一致的定義和術(shù)語。分析和設計工具通常包括數(shù)據(jù)字典組件。
7. 使用質(zhì)量功能調(diào)配，（QFD）是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現(xiàn)了會給客戶帶去驚喜，但若未實現(xiàn)也不會受到責備（Zultner 1993;Pardee 1996）。
記住一點，不要試圖在你的項目中把這些方法都用上去，四個現(xiàn)代化并不是一夜就可以實
現(xiàn)的。同樣，嘗試著使用你認為對你很有幫助的方法，確實收到效果之后，在考慮繼續(xù)學習方法。因為上面提到的都是需求分析的大方法，事實上還有很多很多的方法可以采用，例如，采用SRS模板、指明需求的來源、為每項需求注上標號、記錄業(yè)務規(guī)范、創(chuàng)建需求跟蹤能力矩陣、審查需求文檔、以需求為依據(jù)編寫測試用例、編寫用戶手冊、確定合格的標準。
業(yè)務建模
很多人都沒有意識到業(yè)務需求階段應該做些什么事情，實際上業(yè)務建模是最重要的一件事情。不要覺得業(yè)務建模這個詞很深奧，讓人模不著頭腦。其實所有做過需求分析的人都做過業(yè)務建模，比如你了解企業(yè)的運作模式就是一種你腦海中的業(yè)務建模。但是大多數(shù)人都沒有科學的、系統(tǒng)的、文檔化的做過業(yè)務建模。
業(yè)務建模的目的在于：
·了解目標組織（將要在其中部署系統(tǒng)的組織）的結(jié)構(gòu)及機制。
·了解目標組織中當前存在的問題并確定改進的可能性。
·確保客戶、最終用戶和開發(fā)人員就目標組織達成共識。
·導出支持目標組織所需的業(yè)務需求。
上面的話是不是很抽象呢，其實沒有什么復雜的：人和電腦是完全不同的思想（思維方式）。所以，原先適合人的業(yè)務流程對于計算機來說可不一定合適的，為了最大限度的利用計算機，必須要了解原先的業(yè)務流程并對此加易改造（流程自動化），當然這些動作需要得到用戶的許可。有些人認為說只有ERP這種大系統(tǒng)才需要對業(yè)務流程進行重組，但是實際上，不論是部門級的MIS系統(tǒng)，還是社會級的電子商務系統(tǒng)，都需要對業(yè)務流程進行改造，所不同的只是改造的程度。
業(yè)務建模很重要的一點是在分析企業(yè)流程的同時分析出基礎企業(yè)對象（Common Business Object）（這個詞我翻譯的不好，如果大家有更好的翻譯，請告訴我）。任何企業(yè)都有最基礎的一些元素，例如銀行的CBO就有帳戶，制造業(yè)的CBO就有訂單等。有一次我的一個在企業(yè)應用方面研究多年的朋友告訴我一個秘訣，他說，企業(yè)的CBO無非是4個：客戶、員工、產(chǎn)品和供應商（銀行的供應商應該稱為同業(yè)）。其他的所有CBO都是在這四個CBO的基礎上發(fā)展起來的。比如說CBO中客戶和產(chǎn)品是多對多的關(guān)系，根據(jù)關(guān)系數(shù)據(jù)的理論，
任何多對多的關(guān)系都可以拆分成多個一對多或一對一的關(guān)系。你就可以在這兩個類之間引入訂單類，客戶和訂單之間是一對多，訂單和產(chǎn)品之間又是一對多，這樣一個多對多的關(guān)系就拆分成兩個一對多的關(guān)系，而新的訂單類也就順理成章的產(chǎn)生了。在訂單類產(chǎn)生時，你可能還會加入一個關(guān)聯(lián)類：業(yè)務員類。而業(yè)務員類又是從員工類繼承下來的。所以呢，企業(yè)的四種CBO通過不同的組合，不同的關(guān)系，能夠形成企業(yè)運作的許許多多的CBO。
CBO是做業(yè)務建模的基礎，在此基礎上，通過評估業(yè)務狀態(tài)，說明當前業(yè)務，確定業(yè)務流程，改進業(yè)務流程的定義，設計業(yè)務流程實現(xiàn)，改進角色和職責，研究流程自動化，開發(fā)領(lǐng)域模型等一系列在RUP中定義的工作流程實現(xiàn)業(yè)務建模的目標。
需求獲取 需求獲取(requirement elicitation)是需求工程的主體。對于所建議的軟件產(chǎn)品，獲取需求是一個確定和理解不同用戶類的需要和限制的過程。獲取用戶需求位于軟件需求三個層次的中間一層。業(yè)務需求決定用戶需求，它描述了用戶利用系統(tǒng)需要完成的任務。從這些任務中，分析者能獲得用于描述系統(tǒng)活動的特定的軟件功能需求，這些系統(tǒng)活動有助于用戶執(zhí)行他們的任務。 需求獲取是在問題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個必不可少的結(jié)果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，
分析者、開發(fā)者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開始設計系統(tǒng)，否則，對需求定義的任何改進，設計上都必須大量的返工。把需求獲取集中在用戶任務上—而不是集中在用戶接口上—有助于防止開發(fā)組由于草率處理設計問題而造成的失誤。 需求獲取、分析、編寫需求規(guī)格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復的。當你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息（需求獲取）。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯(lián)系（分析）。然后，你可以使客戶信息結(jié)構(gòu)化，并編寫成文檔和示意圖（說明）。下一步，就可以讓客戶代表評審文檔并糾正存在的錯誤（驗證）。這四個過程貫穿著需求分析的整個階段。
