一、什麼是需求分析呢？

　　軟體需求分析就是把軟體計劃期間建立的軟體可行性分析求精和細化，分析各種可能的解法，並且分配給各個軟體元素。需求分析是軟體定義階段中的最後一步，是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。

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

下面舉個栗子：

  假如你是個軟體工程師，夏天到了，有位客戶跟你說要給他們的家禽養殖場開發一個溫感控制系統，這個時候要需要與客戶溝通，來確定客戶到底想要一個什麼樣子的溫感控制系統。我們應該注意三點：

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

     客戶說，我的溫感系統系統可以感知當前天氣溫度，當溫度過高時，採取灑水模式給環境降溫，當天氣太潮溼，可以開啟除溼模式....客戶滔滔不絕的講了一大堆，你也都非常忠實的按照自己的理解再一一的向客戶描述一遍，以便於確認客戶的需求是否正確。

  2 .  幫助客戶挖掘需求。

    等客戶把自己的需求說完了，你發現客戶沒有跟你說該養殖場的規模是多大的，是在露天的環境下還是在室內的，於是，你向客戶提議說：“你看，咱們這個養殖場的規模是多大的，是在室內呢還是在室外，我們應該怎麼樣設計監控範圍呢？”，客戶連連的拍著腦門說，我差點給忘記了，我們這個養殖場是室內的，有兩層，一層有500平左右。

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

   客戶臨走時又說，對了，一樓二樓的情況不太一樣，二樓比較熱，家禽很多會中暑，能不能二樓的跟一樓的監控是分開的。你這麼一分析，客戶這要求，按照目前的技術可沒法做啊，於是，你向客戶提議，一層使用一個溫感控制器，單獨監控。

二、軟體需求分析難點又在哪裡呢？

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

1 . 客戶說不清楚需求

        有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如談戀愛的時候，女生總希望男朋友能有讀心術猜出自己的心事。每次生氣總會扯出很多事情，然後始終不說清楚為什麼生氣，想要的是什麼。

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

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

2 . 需求自身經常變動  

    　都說女人是善變的，但是其實生活中善變的不止止是女人，你的上司，你的客戶變臉比變天還快 ~ 

需求分析時要注意的問題：

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

      （2）在合同中一定要說清楚“做什麼”和“不做什麼”。如果合同含含糊糊，就要跟客戶確認清楚。

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

    　　俗話說，一千個讀者有一千個哈姆雷特，每個人的思維模式和理解方法都是不一樣的，你不是客戶肚子裡面的蛔蟲，客戶也不是你的大腦反射弧，溝通是解決這些問題的最好方式。

　　  軟體系統分析人員不可能都是全才。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致開發人員白乾活，吃力不討好。所以分析人員寫好需求說明書後，要請客戶方的各個代表驗證。如果問題很複雜，雙方都不太明白，就有必要請開發人員快速構造軟體的原型，雙方再次論證需求說明書是否正確。

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

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

三、需求分析的分類

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

1 . 功能需求：

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

2 . 非功能需求：

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

3 . 領域需求：

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

四、需求分析的不同層次

軟體需求包括三個不同的層次：業務需求、使用者需求和功能需求（也包括非功能需求）。

1．業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們

在專案檢視與範圍文件中予以說明。

2．使用者需求(user requirement) 文件描述了使用者使用產品必須要完成的任務，這在使用例項（use

case）文件或方案指令碼說明中予以說明。

3．功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得使用者能完成他們的

任務，從而滿足了業務需求。

五、如何進行需求分析 

1、需求分析的渠道和過程

2、需求分析的過程

軟體需求分析的過程主要有四個階段：

1、確定軟體需求目標

2、進行分析並整合

3、規格的相關說明規定

4、最終評審。

確定軟體需求目標在涵義上是指系統分析師和程式開發工程師在進行工作中，找出目標軟體工程所需的要求，從而講述出能夠達到要求所需要的條件。一般來說，這些要求主要體現在功能、效能、環境、可靠性、安全性以及使用者介面、資源使用、軟體成本消耗與開發進度等。

（1）功能是指將軟體的功能開發；

（2）效能則在於軟體技術效能標準；

（3）環境是指如硬體和軟體方面在軟體系統執行時的要求，另外還包括對使用此軟體的工作人員的技術要求；

（4）可靠性是通過軟體在開發過程中對實際環境的要求，並滿足在進行需求分析時顯露出所有存在的問題，估計執行後會產生的後果，提出更高的可靠性；

（5）安全性是指安全保密，在進行開發時特別針對安全效能嚴格要求，保證在日後的使用過程中能夠擁有強大的安全效能；

（6）使用者介面要根據客戶的要求進行需求分析；

（7）資源使用是要保證使用者能夠接受在軟體的使用中的資源需求；

（8）大致提出軟體開發所需要的時間和各個階段的費用，合理控制成本消耗和進度。另外，分析系統的功能，檢測在開發之後的效能，有利於及時對系統做出改正。在這些問題得出相應的分析結果之後，要將結果與軟體開發工程師進行核對，並且得到認可。

六、需求分析的方法

1 .  功能分析方法

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

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 . 形式化方法

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

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

七、需求工程

以上例子可能描述不夠嚴謹，有些描述是網上摘錄的，如有講述不對的，歡迎指出，感謝 ！