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

需求分析 ：

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

假如你是個(gè)建筑工程師，有個(gè)客戶(hù)找你建一個(gè)雞窩，這個(gè)時(shí)候要需要與客戶(hù)溝通，來(lái)確定客戶(hù)到底想要一個(gè)什么樣子的雞窩。

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

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

客戶(hù)說(shuō)，我的雞窩要三層的，帶電梯，飲水池，廁所，飲水池要自動(dòng)判斷水位供水，電梯要可以同時(shí)乘坐10只雞….

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

 2 .  幫助客戶(hù)挖掘需求

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

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

客戶(hù)連連的拍著腦門(mén)說(shuō)，我差點(diǎn)給忘記了，雞們啊喜歡晚上在一起聊天，所以呢，需要一個(gè)長(zhǎng)而大的臥室，但一定要舒適。

3 . 分析客戶(hù)需求的可行性

客戶(hù)臨走時(shí)又說(shuō)，最近了，黃鼠狼很多，我這個(gè)雞窩啊，一樓就不用蓋了，直接蓋二樓和三樓吧！

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

01

需求分析困難在哪兒？

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

（1）客戶(hù)說(shuō)不清楚需求；

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

（3）分析人員或客戶(hù)理解有誤。

 1、客戶(hù)說(shuō)不清需求

有些客戶(hù)對(duì)需求只有朦朧的感覺(jué)，當(dāng)然說(shuō)不清楚具體的需求。

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

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

有些客戶(hù)心里非常清楚想要什么，但卻說(shuō)不明白。

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

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

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

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

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

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

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

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

唐僧曾說(shuō)：“妖要是有了仁慈之心，就不再是妖，是人妖。”（《大話(huà)西游之大圣娶親》）

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

軟件的需求會(huì)變化嗎？

答： 據(jù)歷史記載，沒(méi)有一個(gè)軟件的需求改動(dòng)少于三次。

唯一只改動(dòng)需求兩次的客戶(hù)是個(gè)死人。

這個(gè)可憐的家伙還是在運(yùn)送第三次需求的路上被車(chē)子撞死的。

讓我們先接受“需求會(huì)變動(dòng)”這個(gè)事實(shí)吧，免得在需求變動(dòng)時(shí)驚慌失措。

明白“需求會(huì)變動(dòng)”這個(gè)道理后，在進(jìn)行需求分析時(shí)就要留點(diǎn)神。

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

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

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

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

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

有個(gè)外星人間諜潛伏到地球刺探情報(bào)，它給上司寫(xiě)了一份報(bào)告：“主宰地球的是車(chē)。

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

……

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

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

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

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

所以分析人員寫(xiě)好需求說(shuō)明書(shū)后，要請(qǐng)客戶(hù)方的各個(gè)代表驗(yàn)證。

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

由于客戶(hù)大多不懂軟件，他們可能覺(jué)得軟件是萬(wàn)能的，會(huì)提出一些無(wú)法實(shí)現(xiàn)的需求。

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

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

最后，心動(dòng)的客戶(hù)對(duì)軟件人員說(shuō)：“好得很，就讓我們馬上行動(dòng)起來(lái)吧。

請(qǐng)您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做?！?/p>

02

需求分析的分類(lèi)

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

1 . 功能需求：

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

2 . 非功能需求：

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

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

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

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

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

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

03

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

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

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

需求分析的過(guò)程

（1）可行性研究

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

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

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

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

（3）需求描述

需求描述就是把在分析活動(dòng)中收集的信息通過(guò)分析整理之后以文檔的形式確定下來(lái)。

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

（4）需求有效性驗(yàn)證

主要是通過(guò)評(píng)審、驗(yàn)證等一系列活動(dòng)來(lái)找出需求文檔中的錯(cuò)漏并加以改正。

（5）需求管理

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

04

需求分析的方法

 1、功能分析方法

那怕是天下最無(wú)能的市長(zhǎng)或書(shū)記，都知道在作報(bào)告時(shí)要先從宏觀上講一、二、三、四、五，再?gòu)募?xì)節(jié)上講 A、B、C、D、E；

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

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

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

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

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

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

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

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

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

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

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

 3、 信息建模方法

一個(gè)貴婦去報(bào)案，我丟了一個(gè)輛車(chē)，小明是警察，然后問(wèn)貴婦，你丟的什么樣的車(chē)子？

貴婦噼里啪啦的給小明描述車(chē)子樣子：我的車(chē)子有四個(gè)輪子，前面兩個(gè)小，后面兩個(gè)大，車(chē)身是流線(xiàn)型的，后面帶尾翼，里面只一排坐位的那種，車(chē)坐上都用的真皮做套子，后面…..你聽(tīng)著聽(tīng)頭大了，然后對(duì)貴婦說(shuō)：等等，我給你畫(huà)下來(lái)。

于是，貴婦邊說(shuō)，你邊畫(huà)，然后貴婦指出畫(huà)的不對(duì)的地方由你來(lái)修改。當(dāng)然了這只是實(shí)體的樣子。

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

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

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

我想你如果學(xué)習(xí)過(guò)面向?qū)ο缶幊痰脑?huà)，會(huì)很容易理解。

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

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

5、面向本體方法

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

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

OORA方法由 4 個(gè)階段來(lái)完成。

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

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

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

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

 6、形式化方法

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

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

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

 7、粗俗的方法

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

我們來(lái)看下面了解需求的方式：

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

（2）有些需求客戶(hù)講不清楚，分析人員又猜不透，這時(shí)就要請(qǐng)教行家。

有些高手真的很厲害，你還沒(méi)有開(kāi)始問(wèn)，他就能講出前因后果。讓你感到“聽(tīng)君一席言，勝讀十年書(shū)?！?/p>

（3）有很多需求可能客戶(hù)與分析人員想都沒(méi)有想過(guò)，或者想得太幼稚。

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