什么是需求分析?

　　通俗的講，對用戶的意圖不斷揭示和驗叛的過程，要對經過系統可行性分析所確定的系統目標做更為詳細的描述。

　　假如你是個建筑工程師，有個客戶找你建一個雞窩，這個時候要需要與客戶溝通，來確定客戶到底想要一個什么樣子的雞窩。我們應該注意三點：

　　1 . 準確的理解和描述客戶需要的功能。

　　客戶說，我的雞窩要三層的，帶電梯，飲水池，廁所，飲水池要自動判斷水位供水，電梯要可以同時乘坐10只雞....客戶滔滔不絕的講了一大堆，你也都非常忠實的按照自己的理解再一一的向客戶描述一遍，以便于確認客戶的需求是否正確。

　　2 . 幫助客戶挖掘需求。

　　等客戶把自己的需求說完了，你發現客戶沒有說雞的臥室，于是，你向客戶提議說：“你看，這雞的臥室要什么樣子的?”，客戶連連的拍著腦門說，我差點給忘記了，雞們啊喜歡晚上在一起聊天，所以呢，需要一個長而大的臥室，但一定要舒適。

　　3 . 分析客戶需求的可行性

　　客戶臨走時又說，最近了，黃鼠狼很多，我這個雞窩啊，一樓就不用蓋了，直接蓋二樓和三樓吧!以免晚上遭遇黃鼠狼的攻擊。你這么一分析，客戶這要求，按照目前的技術可沒法建啊，于是，你向客戶提議，一樓采用堅固架子來支撐二三樓的建筑。

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

　　需求分析困難在哪兒?

　　有幾種原因使需求分析變得困難：(1)客戶說不清楚需求;(2)需求自身經常變動;(3)分析人員或客戶理解有誤。

　　1 . 客戶說不清楚需求

　　有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多政府機構在搞網絡建設，這些單位的領導和辦公人員大多不清楚計算機網絡有什么用，反而要軟件系統分析人員替他們設想需求。這類工程的需求是如此的主觀，以致產生很多貪污腐敗現象。

　　有些客戶心里非常清楚想要什么，但卻說不明白。你可能很不以為然。就舉日常生活的事例吧，比如說買鞋子。我們非常了解自已的腳，但沒法說清楚腳的大小和形狀。只能拿鞋子去試，試穿時感覺到舒服才會買鞋(居然也有神通廣大的售貨員，看一眼客戶的手，就知道應該穿什么樣的鞋)。

　　如果客戶本身就懂軟件開發，能把需求說得清清楚楚，這樣的需求分析將會非常輕松、愉快。如果客戶全不懂軟件，但信任軟件開發方，這事也好辦。分析人員可以引導客戶，先闡述常規的需求，再由客戶否定不需要的，最終確定客戶真正的需求。最怕的就是“不懂裝懂”或者“半懂充內行”的客戶，他們會提出不切實際的需求。如果這些客戶甚至覺得自己是上帝的爸爸，那么溝通和協商都會很困難。

　　2 . 需求自身經常變動

　　唐僧曾說：“妖要是有了仁慈之心，就不再是妖，是人妖?！?《大話西游之大圣娶親》)

　　連妖都會變心，別說人了。所以喜新厭舊乃人之常情，世界也因此變得多姿多彩。

　　軟件的需求會變化嗎?

　　答：據歷史記載，沒有一個軟件的需求改動少于三次。唯一只改動需求兩次的客戶是個死人。這個可憐的家伙還是在運送第三次需求的路上被車子撞死的。[Cline 1995]

　　讓我們先接受“需求會變動”這個事實吧，免得在需求變動時驚慌失措。明白“需求會變動”這個道理后，在進行需求分析時就要留點神：

　　(1)盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求。以便在進行系統設計時，將軟件的核心建筑在穩定的需求上，否則將會吃盡苦頭。

　　(2)在合同中一定要說清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。要防止象韓復渠那樣，在別人請他喝酒吃飯時他什么都點頭(人家就更加獻殷勤)，吃完了他就宣布剛才答應的事都不算數，便揚長而去。

　　3 . 分析人員和顧客理解有誤

　　有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜里雙眼能射出強光。……有趣的是，車里住著一種叫作‘人’的寄生蟲，這些寄生蟲完全控制了車。”

　　軟件系統分析人員不可能都是全才。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致開發人員白干活，吃力不討好。我讀中學時候最怕寫作文逃題，如果逃題了，不管作文寫得多長，總是零分。所以分析人員寫好需求說明書后，要請客戶方的各個代表驗證。如果問題很復雜，雙方都不太明白，就有必要請開發人員快速構造軟件的原型，雙方再次論證需求說明書是否正確。

　　由于客戶大多不懂軟件，他們可能覺得軟件是萬能的，會提出一些無法實現的需求。有時客戶還會把軟件系統分析人員的建議或答復給想歪了。

　　有一個軟件人員滔滔不絕地向客戶講解在“信息高速公路上做廣告”的種種好處，客戶聽得津津有味。最后，心動的客戶對軟件人員說：“好得很，就讓我們馬上行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。”

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

　　需求分析的分類

　　需求分析一般可分為功能需求、非功能需求和領域需求

　　1 . 功能需求：

　　功能需求主要說明了系統實際應做到什么。這是用戶最直觀也是最主要的需求，如系統的輸入輸出、系統能完成的功能以及其它相關處理等;

　　2 . 非功能需求：

　　非功能需求又稱“約束”，它主要從各個角度對系統起約束和限制作用。如響應時間、存儲效率、報表的規格和界面的樣式等

　　3 . 領域需求：

　　領域需求的來源不是用戶，而是系統應用的領域，其主要反映了該領域的基本問題。例如勤工儉學管理系統，其領域需求就涉及到諸如應聘合同書、酬金發放及勞工考核等相關內容，如果這些需求得不到滿足，系統就無法正常運行。值得一提的是，領域需求可能是功能需求，也可能是非功能需求。

　如何進行需求分析

　　進行需求分析不象情人之間的浪漫做法——“讓我摸摸你的頭發，感覺它是什么顏色。”我們需要了解需求分析的渠道和過程。

　　需求分析的過程

　　(1)可行性研究

　　它指明現有的軟件、硬件技術能否實現用戶對系統的要求，從業務角度來決定系統開發是否可行以及在預算范圍內能否開發出來。可行性研究的結果是清楚的回答：該系統是否值得開發

　　(2)需求導出和分析

　　這是一個通過對現有系統分析、與潛在客戶討論、進行任務分析等導出系統需求的過程，也可能需要開發一個或多個不同的系統原型，以幫助分析員了解所要描述的系統。

　　(3)需求描述

　　需求描述就是把在分析活動中收集的信息通過分析整理之后以文檔的形式確定下來。該文檔中有兩類需求：用戶需求是從客戶和最終用戶角度對系統需求的抽象描述;系統需求是對系統要提供的功能的詳盡描述。

　　(4)需求有效性驗證

　　主要是通過評審、驗證等一系列活動來找出需求文檔中的錯漏并加以改正。

　　(5)需求管理

　　需求管理需求管理是一種系統化方法，可用于獲取、組織和記錄系統需求并使用戶和開發方在系統變更需求上始終保持一致

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

　　需求分析的方法

　　1 . 功能分析方法

　　那怕是天下最無能的市長或書記，都知道在作報告時要先從宏觀上講一、二、三、四、五，再從細節上講 A、B、C、D、E;需求分析不象偵探推理那樣從蛛絲馬跡著手。應該先了解宏觀的問題，再了解細節的問題。

　　功能分析法功能分解法以系統提供的功能為中心來組織系統。首先定義各種功能, 然后把功能分解為子功能, 同時定義功能之間的接口。數據結構是根據功能/子功能的需要設計的。 其基本策略是以分析員的經驗為依據, 確定新系統所期望的處理步驟或子步驟, 然后, 將問題空間映射到功能和子功能上。

　　2 . 數據流方法

　　周末，小明一覺醒來突然想吃紅燒肉，那想得口水直流，于起床，穿好衣服，打開錢包一看空的，好吧，先去銀行取錢，然后去菜那買了一肉、各種配料，然后回家，開火，各種材料往鍋里一放，開始小火慢燉，半個小時后，小明終于吃上了美味可口的紅燒肉。這是一個典型的流程，如果把它看成一個系統功能的話，那么小明吃到紅燒肉是這個功能的目的，那么中間要經歷許多環節，起床穿衣---取錢---習材料----制作完成。而且各個功能(步驟)之間是相互聯系的，小明總不能不穿衣服直接去取錢吧。

　　數據流法也叫結構化分析, 其基本策略是研究問題域中數據如何流動以及在各個環節上進行何種處理, 從而發現數據流和加工。 問題域被映射為由數據流、加工以及文件、端點等成份構成的數據流圖(DFD) , 并用數據字典對數據流和加工進行詳細說明。這種方法的關鍵是動態跟蹤數據流動。

　　3 . 信息建模方法

　　一個貴婦去報案，我丟了一個輛車，小明是警察，然后問貴婦，你丟的什么樣的車子?貴婦噼里啪啦的給小明描述車子樣子：我的車子有四個輪子，前面兩個小，后面兩個大，車身是流線型的，后面帶尾翼，里面只一排坐位的那種，車坐上都用的真皮做套子，后面…..你聽著聽頭大了，然后對貴婦說：等等，我給你畫下來。于是，貴婦邊說，你邊畫，然后貴婦指出畫的不對的地方由你來修改。當然了這只是實體的樣子。我們還需要知道汽車各個部件的功能以及各部件之間的關系。

　　信息建模法的核心概念是實體和關系, 主要工具是語義數據模型(實體關系圖) , 其基本策略是找出現實世界的對象, 然后用屬性來描述對象, 增添對象與對象之間的關系, 定義父類與子類, 用父類型/子類型提煉屬性的共性, 用關聯對象關系作細化的描述, 最后進行規范化處理。 其實質是將問題空間直接映射成模型中的對象。

　　----下面三種方法，我還不能理解-----

　　4 . 面向對象方法

　　我想你如果學習過面向對象編程的話，會很容易理解。

　　面向對象分析 OOA(Object- Oriented Analysis) 的基本策略是通過信息隱藏將比較容易變化的元素隱藏起來, 分析員基于比較穩定的元素建立其思想和規格說明的總體結構。

　　面向對象分析的主要特性是加強了對問題域( Problem Domain) 和系統責任( System Responsibili-ties)的理解; 改進與分析有關的各類人員之間的交流; 對需求的變化具有較強的適應性; 支持軟件復用

　　5 . 面向本體方法

　　面向本體的需求分析 OORA (Ontology- Oriented Require-ments Analysis) , 是 OOA方法的有效補充和提升。 面向本體方法強調相關領域的本質概念以及這些概念之間的關聯。其實質是在面向對象方法中引入對象關聯, 并給出各種關聯的語義語用。

　　OORA方法由 4 個階段來完成。第一階段: 用一種自然語言BIDL( Bisiness Information Description Language) 描述事務; 第二階段: 確認隱含在 BIDL文本中的本體和對象; 第三階段: 將這些本體和對象轉換成另一種語言 Ononet (Ontology and Object- Ori-ented Network) , 得到用 Ononet 書寫的需求預定義; 第四階段: 在采用 Ononet 作為知識表示形式的領域本體知識庫中搜索相關的知識, 并和前面的需求預定義合并, 得到軟件完整的需求定義。

　　6 . 形式化方法

　　形式化方法, 廣義上講, 是應用數學的手段來設計、 模擬和分析, 得到像數學公式那樣精確的表示。從狹義上講, 就是使用一種形式語言進行語言公式的形式推理, 用于檢查語法的良構

　　性并證明某些屬性。在需求分析階段, 利用形式化方法得到需求規格說明書, 可以規范軟件開發過程, 為獲得更好的系統性能提供重要保證。

　=============================粗俗的方法=====================

　　可能你對上面的方法看不懂，起碼后三種我是看不懂的，怪我知識太少的緣故。

　　我們來看下面了解需求的方式：

　　(1)直接與客戶交談。如果分析人員生有足球評論員的那張“大嘴”，就非常容易侃出需求。

　　(2)有些需求客戶講不清楚，分析人員又猜不透，這時就要請教行家。有些高手真的很厲害，你還沒有開始問，他就能講出前因后果。讓你感到“聽君一席言，勝讀十年書。”

　　(3)有很多需求可能客戶與分析人員想都沒有想過，或者想得太幼稚。要經常分析優秀的和蹩腳的同類軟件，看到了優點就盡量吸取，看到了缺點就引以為戒。前人既然付了學費，后人就不要拒絕坐享其成。