淺說軟件需求分析

什麼是需求分析？

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

 

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

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

     客戶說，個人雞窩要三層的，帶電梯，飲水池，廁所，飲水池要自動判斷水位供水，電梯要能夠同時乘坐10只雞....客戶口若懸河的講了一大堆，你也都很是忠實的按照本身的理解再一一的向客戶描述一遍，以便於確認客戶的需求是否正確。

  2 .  幫助客戶挖掘需求。

    等客戶把本身的需求說完了，你發現客戶沒有說雞的臥室，因而，你向客戶提議說：「你看，這雞的臥室要什麼樣子的？」，客戶連連的拍着腦門說，我差點給忘記了，雞們啊喜歡晚上在一塊兒聊天，因此呢，須要一個長而大的臥室，但必定要溫馨。

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

   客戶臨走時又說，最近了，黃鼠狼不少，我這個雞窩啊，一樓就不用蓋了，直接蓋二樓和三樓吧！以避免晚上遭遇黃鼠狼的攻擊。你這麼一分析，客戶這要求，按照目前的技術可無法建啊，因而，你向客戶提議，一樓採用堅固架子來支撐二三樓的建築。

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

 

需求分析困難在哪兒？

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

1 . 客戶說不清楚需求

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

　　有些客戶內心很是清楚想要什麼，但卻說不明白。你可能很不覺得然。就舉平常生活的事例吧，好比說買鞋子。咱們很是瞭解自已的腳，但無法說清楚腳的大小和形狀。只能拿鞋子去試，試穿時感受到舒服纔會買鞋（竟然也有神通廣大的售貨員，看一眼客戶的手，就知道應該穿什麼樣的鞋）。

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

2 . 需求自身常常變更  

    唐僧曾說：「妖要是有了仁慈之心，就再也不是妖，是人妖。」（《大話西遊之大聖娶親》）

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

　　軟件的需求會變化嗎？

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

　　讓咱們先接受「需求會變更」這個事實吧，省得在需求變更時惶恐不安。明白「需求會變更」這個道理後，在進行需求分析時就要留點神：

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

      （2）在合同中必定要說清楚「作什麼」和「不作什麼」。若是合同含含糊糊，往後扯皮的事情就多。要防止象韓復渠那樣，在別人請他喝酒吃飯時他什麼都點頭（人家就更加獻殷勤），吃完了他就宣佈剛纔答應的事都不算數，便揚長而去。

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

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

　　軟件系統分析人員不可能都是全才。客戶表達的需求，不一樣的分析人員可能有不一樣的理解。若是分析人員理解錯了，可能會致使開發人員白乾活，吃力不討好。我讀中學時候最怕寫做文逃題，若是逃題了，無論做文寫得多長，老是零分。因此分析人員寫好需求說明書後，要請客戶方的各個表明驗證。若是問題很複雜，雙方都不太明白，就有必要請開發人員快速構造軟件的原型，雙方再次論證需求說明書是否正確。

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

　　有一個軟件人員口若懸河地向客戶講解在「信息高速公路上作廣告」的種種好處，客戶聽得津津有味。最後，心動的客戶對軟件人員說：「好得很，就讓咱們立刻行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我當即派人去作。」

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

 

需求分析的分類

   需求分析通常可分爲功能需求、非功能需求和領域需求

1 . 功能需求：

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

2 . 非功能需求：

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

3 . 領域需求：

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

 

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

如何進行需求分析

進行需求分析不象情人之間的浪漫作法——「讓我摸摸你的頭髮，感受它是什麼顏色。」咱們須要瞭解需求分析的渠道和過程。

 

需求分析的過程

 

（1）可行性研究

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

（2）需求導出和分析

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

（3）需求描述

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

（4）需求有效性驗證

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

（5）需求管理

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

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

 

需求分析的方法

1 .  功能分析方法

      那怕是天下最無能的市長或書記，都知道在做報告時要先從宏觀上講1、2、3、4、五，再從細節上講 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）有不少需求可能客戶與分析人員想都沒有想過，或者想得太幼稚。要常常分析優秀的和蹩腳的同類軟件，看到了優勢就儘可能吸收，看到了缺點就引覺得戒。前人既然付了學費，後人就不要拒絕不勞而獲。

 

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

 

參考文獻：

《關於軟件需求分析的研究》--邱樹偉

《軟件工程思想》--林銳