資深PRD：需求分析的 7 種絕佳策略

需求分析 ：

是對用戶的意圖不斷揭示和驗判的過程，要對經(jīng)過系統(tǒng)可行性分析所確定的系統(tǒng)目標(biāo)做更為詳細(xì)的描述。

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

我們應(yīng)該注意三點：

1 .  準(zhǔn)確的理解和描述客戶需要的功能

客戶說，我的雞窩要三層的，帶電梯，飲水池，廁所，飲水池要自動判斷水位供水，電梯要可以同時乘坐10只雞….

客戶滔滔不絕的講了一大堆，你也都非常忠實的按照自己的理解再一一的向客戶描述一遍，以便于確認(rèn)客戶的需求是否正確。

 2 .  幫助客戶挖掘需求

等客戶把自己的需求說完了，你發(fā)現(xiàn)客戶沒有說雞的臥室，于是，你向客戶提議說：

“你看，這雞的臥室要什么樣子的？”

客戶連連的拍著腦門說，我差點給忘記了，雞們啊喜歡晚上在一起聊天，所以呢，需要一個長而大的臥室，但一定要舒適。

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

客戶臨走時又說，最近了，黃鼠狼很多，我這個雞窩啊，一樓就不用蓋了，直接蓋二樓和三樓吧！

以免晚上遭遇黃鼠狼的攻擊。你這么一分析，客戶這要求，按照目前的技術(shù)可沒法建啊，于是，你向客戶提議，一樓采用堅固架子來支撐二三樓的建筑。

01

需求分析困難在哪兒？

有幾種原因使需求分析變得困難：

（1）客戶說不清楚需求；

（2）需求自身經(jīng)常變動；

（3）分析人員或客戶理解有誤。

 1、客戶說不清需求

有些客戶對需求只有朦朧的感覺，當(dāng)然說不清楚具體的需求。

例如全國各地的很多政府機(jī)構(gòu)在搞網(wǎng)絡(luò)建設(shè)，這些單位的領(lǐng)導(dǎo)和辦公人員大多不清楚計算機(jī)網(wǎng)絡(luò)有什么用，反而要軟件系統(tǒng)分析人員替他們設(shè)想需求。

這類工程的需求是如此的主觀，以致產(chǎn)生很多貪污腐敗現(xiàn)象。

有些客戶心里非常清楚想要什么，但卻說不明白。

你可能很不以為然。就舉日常生活的事例吧，比如說買鞋子，我們非常了解自已的腳，但沒法說清楚腳的大小和形狀。

只能拿鞋子去試，試穿時感覺到舒服才會買鞋（居然也有神通廣大的售貨員，看一眼客戶的手，就知道應(yīng)該穿什么樣的鞋）。

如果客戶本身就懂軟件開發(fā)，能把需求說得清清楚楚，這樣的需求分析將會非常輕松、愉快。

如果客戶全不懂軟件，但信任軟件開發(fā)方，這事也好辦。

分析人員可以引導(dǎo)客戶，先闡述常規(guī)的需求，再由客戶否定不需要的，最終確定客戶真正的需求。

最怕的就是“不懂裝懂”或者“半懂充內(nèi)行”的客戶，他們會提出不切實際的需求。

如果這些客戶甚至覺得自己是上帝的爸爸，那么溝通和協(xié)商都會很困難。

 2、需求經(jīng)常變動 …

唐僧曾說：“妖要是有了仁慈之心，就不再是妖，是人妖?！保ā洞笤捨饔沃笫ト⒂H》）

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

軟件的需求會變化嗎？

答： 據(jù)歷史記載，沒有一個軟件的需求改動少于三次。

唯一只改動需求兩次的客戶是個死人。

這個可憐的家伙還是在運送第三次需求的路上被車子撞死的。

讓我們先接受“需求會變動”這個事實吧，免得在需求變動時驚慌失措。

明白“需求會變動”這個道理后，在進(jìn)行需求分析時就要留點神。

（1）盡可能地分析清楚哪些是穩(wěn)定的需求，哪些是易變的需求。

以便在進(jìn)行系統(tǒng)設(shè)計時，將軟件的核心建筑在穩(wěn)定的需求上，否則將會吃盡苦頭。

（2）在合同中一定要說清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。

要防止象韓復(fù)渠那樣，在別人請他喝酒吃飯時他什么都點頭（人家就更加獻(xiàn)殷勤），吃完了他就宣布剛才答應(yīng)的事都不算數(shù)，便揚長而去。

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

有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。

它們喝汽油，靠四個輪子滾動前進(jìn)。嗓門極大，在夜里雙眼能射出強(qiáng)光。

……

有趣的是，車?yán)镒≈环N叫作‘人’的寄生蟲，這些寄生蟲完全控制了車?！?/p>

軟件系統(tǒng)分析人員不可能都是全才。客戶表達(dá)的需求，不同的分析人員可能有不同的理解。

如果分析人員理解錯了，可能會導(dǎo)致開發(fā)人員白干活，吃力不討好。

我讀中學(xué)時候最怕寫作文逃題，如果逃題了，不管作文寫得多長，總是零分。

所以分析人員寫好需求說明書后，要請客戶方的各個代表驗證。

如果問題很復(fù)雜，雙方都不太明白，就有必要請開發(fā)人員快速構(gòu)造軟件的原型，雙方再次論證需求說明書是否正確。

由于客戶大多不懂軟件，他們可能覺得軟件是萬能的，會提出一些無法實現(xiàn)的需求。

有時客戶還會把軟件系統(tǒng)分析人員的建議或答復(fù)給想歪了。

有一個軟件人員滔滔不絕地向客戶講解在“信息高速公路上做廣告”的種種好處，客戶聽得津津有味。

最后，心動的客戶對軟件人員說：“好得很，就讓我們馬上行動起來吧。

請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。”

02

需求分析的分類

需求分析一般可分為功能需求、非功能需求和領(lǐng)域需求。

1 . 功能需求：

功能需求主要說明了系統(tǒng)實際應(yīng)做到什么。這是用戶最直觀也是最主要的需求，如系統(tǒng)的輸入輸出、系統(tǒng)能完成的功能以及其它相關(guān)處理等；

2 . 非功能需求：

非功能需求又稱“約束”，它主要從各個角度對系統(tǒng)起約束和限制作用。

如響應(yīng)時間、存儲效率、報表的規(guī)格和界面的樣式等。

3 . 領(lǐng)域需求：

領(lǐng)域需求的來源不是用戶，而是系統(tǒng)應(yīng)用的領(lǐng)域，其主要反映了該領(lǐng)域的基本問題。

例如勤工儉學(xué)管理系統(tǒng)，其領(lǐng)域需求就涉及到諸如應(yīng)聘合同書、酬金發(fā)放及勞工考核等相關(guān)內(nèi)容，如果這些需求得不到滿足，系統(tǒng)就無法正常運行。

值得一提的是，領(lǐng)域需求可能是功能需求，也可能是非功能需求。

03

如何進(jìn)行需求分析

進(jìn)行需求分析不象情人之間的浪漫做法——“讓我摸摸你的頭發(fā)，感覺它是什么顏色。

”我們需要了解需求分析的渠道和過程。

需求分析的過程

（1）可行性研究

它指明現(xiàn)有的軟件、硬件技術(shù)能否實現(xiàn)用戶對系統(tǒng)的要求，從業(yè)務(wù)角度來決定系統(tǒng)開發(fā)是否可行以及在預(yù)算范圍內(nèi)能否開發(fā)出來。

可行性研究的結(jié)果是清楚的回答：該系統(tǒng)是否值得開發(fā)。

（2）需求導(dǎo)出和分析

這是一個通過對現(xiàn)有系統(tǒng)分析、與潛在客戶討論、進(jìn)行任務(wù)分析等導(dǎo)出系統(tǒng)需求的過程，也可能需要開發(fā)一個或多個不同的系統(tǒng)原型，以幫助分析員了解所要描述的系統(tǒng)。

（3）需求描述

需求描述就是把在分析活動中收集的信息通過分析整理之后以文檔的形式確定下來。

該文檔中有兩類需求：用戶需求是從客戶和最終用戶角度對系統(tǒng)需求的抽象描述；系統(tǒng)需求是對系統(tǒng)要提供的功能的詳盡描述。

（4）需求有效性驗證

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

（5）需求管理

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

04

需求分析的方法

 1、功能分析方法

那怕是天下最無能的市長或書記，都知道在作報告時要先從宏觀上講一、二、三、四、五，再從細(xì)節(jié)上講 A、B、C、D、E；

需求分析不象偵探推理那樣從蛛絲馬跡著手。應(yīng)該先了解宏觀的問題，再了解細(xì)節(jié)的問題。

功能分析法功能分解法以系統(tǒng)提供的功能為中心來組織系統(tǒng)。

首先定義各種功能, 然后把功能分解為子功能, 同時定義功能之間的接口。

數(shù)據(jù)結(jié)構(gòu)是根據(jù)功能/子功能的需要設(shè)計的。

 其基本策略是以分析員的經(jīng)驗為依據(jù), 確定新系統(tǒng)所期望的處理步驟或子步驟, 然后, 將問題空間映射到功能和子功能上。

2、數(shù)據(jù)流方法

周末，小明一覺醒來突然想吃紅燒肉，那想得口水直流，于起床，穿好衣服，打開錢包一看空的，好吧，先去銀行取錢，然后去菜那買了一肉、各種配料，然后回家，開火，各種材料往鍋里一放，開始小火慢燉，半個小時后，小明終于吃上了美味可口的紅燒肉。

這是一個典型的流程，如果把它看成一個系統(tǒng)功能的話，那么小明吃到紅燒肉是這個功能的目的，那么中間要經(jīng)歷許多環(huán)節(jié)，起床穿衣—取錢—習(xí)材料—-制作完成。而且各個功能（步驟）之間是相互聯(lián)系的，小明總不能不穿衣服直接去取錢吧。

數(shù)據(jù)流法也叫結(jié)構(gòu)化分析, 其基本策略是研究問題域中數(shù)據(jù)如何流動以及在各個環(huán)節(jié)上進(jìn)行何種處理, 從而發(fā)現(xiàn)數(shù)據(jù)流和加工。

問題域被映射為由數(shù)據(jù)流、加工以及文件、端點等成份構(gòu)成的數(shù)據(jù)流圖(DFD) , 并用數(shù)據(jù)字典對數(shù)據(jù)流和加工進(jìn)行詳細(xì)說明。

這種方法的關(guān)鍵是動態(tài)跟蹤數(shù)據(jù)流動。

 3、 信息建模方法

一個貴婦去報案，我丟了一個輛車，小明是警察，然后問貴婦，你丟的什么樣的車子？

貴婦噼里啪啦的給小明描述車子樣子：我的車子有四個輪子，前面兩個小，后面兩個大，車身是流線型的，后面帶尾翼，里面只一排坐位的那種，車坐上都用的真皮做套子，后面…..你聽著聽頭大了，然后對貴婦說：等等，我給你畫下來。

于是，貴婦邊說，你邊畫，然后貴婦指出畫的不對的地方由你來修改。當(dāng)然了這只是實體的樣子。

我們還需要知道汽車各個部件的功能以及各部件之間的關(guān)系。

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

 4、面向?qū)ο蠓椒?/strong>

我想你如果學(xué)習(xí)過面向?qū)ο缶幊痰脑?，會很容易理解?/p>

面向?qū)ο蠓治?OOA(Object- Oriented Analysis) 的基本策略是通過信息隱藏將比較容易變化的元素隱藏起來, 分析員基于比較穩(wěn)定的元素建立其思想和規(guī)格說明的總體結(jié)構(gòu)。

面向?qū)ο蠓治龅闹饕匦允羌訌?qiáng)了對問題域( Problem Domain) 和系統(tǒng)責(zé)任( System Responsibili-ties)的理解; 改進(jìn)與分析有關(guān)的各類人員之間的交流; 對需求的變化具有較強(qiáng)的適應(yīng)性; 支持軟件復(fù)用。

5、面向本體方法

面向本體的需求分析 OORA (Ontology- Oriented Require-ments Analysis) , 是 OOA方法的有效補充和提升。

面向本體方法強(qiáng)調(diào)相關(guān)領(lǐng)域的本質(zhì)概念以及這些概念之間的關(guān)聯(lián)。其實質(zhì)是在面向?qū)ο蠓椒ㄖ幸雽ο箨P(guān)聯(lián), 并給出各種關(guān)聯(lián)的語義語用。

OORA方法由 4 個階段來完成。

第一階段: 用一種自然語言BIDL( Bisiness Information Description Language) 描述事務(wù);

第二階段: 確認(rèn)隱含在 BIDL文本中的本體和對象;

 第三階段: 將這些本體和對象轉(zhuǎn)換成另一種語言 Ononet (Ontology and Object- Ori-ented Network) , 得到用 Ononet 書寫的需求預(yù)定義;

第四階段: 在采用 Ononet 作為知識表示形式的領(lǐng)域本體知識庫中搜索相關(guān)的知識, 并和前面的需求預(yù)定義合并, 得到軟件完整的需求定義。

 6、形式化方法

形式化方法, 廣義上講, 是應(yīng)用數(shù)學(xué)的手段來設(shè)計、 模擬和分析, 得到像數(shù)學(xué)公式那樣精確的表示。

從狹義上講, 就是使用一種形式語言進(jìn)行語言公式的形式推理, 用于檢查語法的良構(gòu)性并證明某些屬性。

在需求分析階段, 利用形式化方法得到需求規(guī)格說明書, 可以規(guī)范軟件開發(fā)過程, 為獲得更好的系統(tǒng)性能提供重要保證。

 7、粗俗的方法

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

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

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

（2）有些需求客戶講不清楚，分析人員又猜不透，這時就要請教行家。

有些高手真的很厲害，你還沒有開始問，他就能講出前因后果。讓你感到“聽君一席言，勝讀十年書?！?/p>

（3）有很多需求可能客戶與分析人員想都沒有想過，或者想得太幼稚。

要經(jīng)常分析優(yōu)秀的和蹩腳的同類軟件，看到了優(yōu)點就盡量吸取，看到了缺點就引以為戒。前人既然付了學(xué)費，后人就不要拒絕坐享其成。