某日，老師在課堂上想考考學生們的智商，就問一個男孩:“樹上有十隻鳥，開槍打死一隻，還剩幾隻？”
男孩反問:“是無聲槍麼？”
“不是。”
“槍聲有多大？”
“80~100分貝。”
“那就是說會震的耳朵疼？”
“是。”
“在這個城市裏打鳥犯不犯法？”
‘不犯。”
“您確定那隻鳥真的被打死啦？”
“確定。”老師已經不耐煩了，”拜託，你告訴我還剩幾隻就行了，OK？”
“OK。鳥裏有沒有聾子？”
“沒有。”
“有沒有關在籠子裏的？”
“沒有。”
“邊上還有沒有其他的樹，樹上還有沒有其他鳥？”
“沒有。”
“方圓十里呢？”
“就這麼一棵樹!”
“有沒有殘疾或餓的飛不動的鳥？”
“沒有，都身體倍棒。”
“算不算懷孕肚子裏的小鳥？”
“都是公的。”
“都不可能懷孕？”
“………，決不可能。”
“打鳥的人眼裏有沒有花？保證是十隻？”
“沒有花，就十隻。”
老師腦門上的汗已經流下來了，下課鈴響起，但男孩仍繼續問:“有沒有傻的不怕死的？”
“都怕死。”
“有沒有因爲情侶被打中，自己留下來的？”
“笨蛋，之前不是說都是公的嘛!”
“同志可不可以啊!”
“…………，性取向都很正常!”
“會不會一槍打死兩隻？”
“不會。”
“一槍打死三隻呢？”
“不會。”
“四隻呢？”
“更不會!”
“五隻呢？”
“絕對不會!!!”
“那六隻總有可能吧？”
“除非你他媽的是豬生的纔有可能!”
“…好吧，那麼所有的鳥都可以自由活動麼？”
“完全可以。”
“它們受到驚嚇起飛時會不會驚慌失措而互相撞上？”
“不會，每隻鳥都裝有衛星導航系統，而且可以自動飛行。”
“恩，如果您的回答沒有騙人，”學生滿懷信心的回答，“打死的鳥要是掛在樹上沒掉下來，那麼就剩一隻，如果掉下來，就一隻不剩。”
老師當即倒!
正值六一兒童節之際，用這篇笑話故事來做開頭，笑過之後可能不少能會認爲這個小朋友是需求調研的最佳人選。回顧軟件開發上的許多案例，軟件開發失敗率一直居高不下，特別在外包開發這個領域中，這個值可能會更高一籌。在分析項目失敗的原因的時候，需求的因素可能是失敗的關鍵原因、需求不明確，客戶對需求的變更頻頻等等。
1．需求的調研
需求調研是爲需要說明書做前期工作，可以說需要說明書是從需求調研表中得到或抽取而出。需求調研是要了解客戶希望所要開發的系統能夠解決他們的問題，以及瞭解他們對系統的期望等等。需求調研是整個開發的基礎，經過需求調研的結果整理出需求說明書作爲後續開發使用。
如果做的項目是一個陌生的一個行業（專業），這是往往需要專家或者顧問等角色的協助，但是作爲調研人員最少要想辦法瞭解個專業，或許你需要成爲這個行業的專家，但最少要了解一定的專業知識（最少專業詞彙你要知道）。這樣客戶的溝通才能達到順暢，不會出現牛頭不對馬嘴的現象。
在某些難度不是很大的行業或者項目，做需求調研的時候可以通過自學的方式瞭解行業的特點，這些項目往往因爲規模比較小，也不會有專家的影子出現。但是作爲調研的時候我們最需要了解的一些問題如：
1）：客戶目前的問題與苦難
2）：客戶現在的工作模式
3）：客戶對系統的期望
4）：客戶哪些要求是自己能做到的，那些是依靠系統來做
5）：還有客戶對系統開發方式以及時間的要求等等
其實做需求調研的時候最重要的目的在於資料收集，或許小孩的那種打破砂鍋的方式會引起客戶的反感，但是實際項目中往往需要的就是這些比較周全的調研方式，能夠考慮到的問題點都需要和客戶確認，儘量避免想當然的做法，只是採用的方式可能需要優化一下，採用良好的方式，儘量得到客戶的最大配合。
2．需求的描述和確認
對於需求的調研內容需要進行整理和分類，分清有用功能、可選用功能、無用功能及不可實現功能。對於這些功能和客戶再次確認之後才能最終形成開發的需求文檔。對於需求的描述有很多的方法和工具，但是無論採用那種方法和工具都是相對抽象的方式，如何讓客戶能夠理解需求的實際內容，需要客戶有良好的理解能力，畢竟系統還只是紙面上的內容，客戶還是很難完全瞭解到真實的系統。
如何對需求進行描述在項目開發中是一個很難定奪的題目，有些公司採用Demo的方式，有些採用傳統的功能樹的方式，有些採用界面的描述方式，有些採用UML建模的方式，形式多種多樣。各種方式都有其好壞。但是對於方式的選擇需要注意一些問題：
1）瞭解客戶是否能夠理解所描述的問題，
2）避免先入爲主，
3）避免形式主義，
有些公司採用UML描述需求，但是客戶的能力達不到能夠理解UML所描述的問題，甚至公司內部的開發人員也無法很好的理解UML，可能只有需求人員懂UML，這種需求結果就值得思考，客戶是否知道你在說什麼？如果你先入爲主使用這種方式來描述問題，難道也期望客戶去學習這些知識嗎？
3．需求的控制
客戶往往很難知道他們需要什麼樣的系統，有時候系統做到一半的時候客戶會提出一些新的想法，更甚至等系統上線的時候客戶才發現系統和他們腦子裏想的東西完全不是一回事。對於這些可能會說當初需求定義的時候不是簽字下來說是做成這樣，怎麼不是你想要的呢？問題可能會歸根於與客戶溝通的方式和手法上，但是對於需求的控制來說，對如何避免需求的反覆，客戶腦門一熱就有新點子出來，還有許多不切實的要求等等，都在需求的控制範圍內。
有些人會說我們和客戶說好了，協議也簽訂說：除了紙上描述的東西之外，其餘的都是變更追加。但是這個觀點固然好，也是完全歸於一方有利來考慮，而且有很多時候我們簽署在合同內的需求文檔也比較含糊，而且雙方在問題的理解上可能會有歧義，一旦真正要將合同拿出來對峙的時候，我想彼此都很難說服對方。就像樹上有十隻鳥一樣，沒有說好環境，狀態等等的假設，一切的結果應該說都可能是合理的。
如何控制需求，我想除了軟件工程上提出的那些理論之外，也很難有新的觀點，但是在實際的操作過程中，我們可能一方面要維護和客戶的關係，另一方面也要考慮系統的開發時間和整體工數等等，做一個權衡。不過我個人更趨向使用問題具體化的方式來控制，儘量將能夠想出的問題通通羅列出來和客戶確認，同時採用換位思考的方式，儘量能夠讓客戶理解我們所描述的系統的狀況，如果在調研和需求的確認階段能夠把工作做得很好，在後期的開發過程中變更的內容就會比較少，變更的內容也就容易控制。
和客戶進行良好的溝通，多爲客戶做一個考慮，避免將自己以一個高調姿態介入和客戶的溝通中，說一些客戶很難懂的專業術語，將客戶噴的雲裏霧裏，自以爲自己的專業領域多麼了不起，這種和客戶的共通方式最容易造成需求空洞，後期翻盤的概率很高。如果客戶不懂你口中所說的內容，可能問題出於客戶，另外更大的程度出於你，我們需要考慮採用的溝通的方式以及內容是不適通俗易懂，能將複雜的問題講的簡單就表示你不簡單。