怎麼做需求分析

本文來自[url]www.Linuxaid.com.cn[/url]

作者：axing

--------------------------------------------------------------------------------

需求分析

在具體的研究需求分析之前，我們先了解一下軟體工程這個概念。軟體工程分為三個層次，過程層、方法層、工具層。在最基礎的過程層，最重要的就是一組被稱為關鍵過程區域（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. 如果使用者提出對将來産品的要求，而不是現在我們讨論的特定産品，也許你就完成了收集需求的工作。

以上知識大緻上讨論需求分析應該如何做，實際上對于需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的應用主要還是要靠個人。是以，大家在實際應用的時候，不妨結合自己的實際，有選擇性的采用一些方法，那你就是成功的。