如何做好需求分析?
怎麼做好一個需求分析師？
看看下面這個故事吧，也許看完了你就能明白了。。
先來看一個老掉牙的故事：福特說，我在設計汽車之前，到處去問人們“需要一個什麼樣的更好的交通工具？”，幾乎所有人的答案都是 ── 一匹“更快的馬”。
“更好的交通工具”代表用戶的“需求”；“更快的”是用戶對於解決這個“需求”的“期望值”；“馬”是用戶對於解決這個“需求”的自假設“功能”。
一個初級的設計者，被用戶牽著鼻子走。聽到“更快的馬”以後，會馬上去設計一匹“馬”。這個時候，無論在“馬”上如何做創新，思路已經框死，結果很難突破。最終只能出來平庸的設計，很難長久很容易被模仿和超越，實現不了多大的商業價值。
一個合格的設計者，和用戶一起走。聽到“更快的馬”以後，會考慮“更快的”這個“期望值”，圍繞著它突破“馬”的侷限，去做設計。最終可能會出來很好的設計，但他們把“需求”本身拋到了腦後，最終只能簡單的滿足需求達到期望，而無法引導需求。他們績以做出來成功的產品，但隨著用戶期望的增長，這樣的產品很 難有取得用戶的長久青睞，也很難取得商業上長久的成功。
一個卓越的設計者，自己會作為用戶的一部分深入瞭解他們，並帶著用戶一起走。聽到“更快的馬”以後，他們會先去考慮需求是“更好的交通”工具，然後再結合 “更快的”這個主要期望。用對用戶最有價值的方式在的滿足需求超越期望(把“馬”這件事拋到腦後)，從而引導需求，並獲取更豐厚更長久的商業利益，和用戶雙贏。
不可否認，史玉柱是一個商業的天才。
他發現了“送禮”這個大需求，並發現了送禮的期望在於“面子”而非“ 實用”。於是他通過“廣告”在推廣的同時增加產品的“價值”，而非在產品質量上增加“價值”。春節，杭州人告訴我：“我們春節送禮都是送保健品，廣告播什麼就買什麼，因為有 知名度”。但他忘記了，這樣是否可以給用戶帶來真正的長期價值。生活層次相對較高的行州人又告訴我“我們不買腦白金和黃金酒，那些都是騙人的檔次低。我們買靈芝、鹿茸、人蔘、...”。
他發現了“砍人”的需求，並發現了“花再多錢也要砍死他”這個期望，最終使用了“網遊”這個功能，用最簡單粗暴的商業設計獲取暴利。但他忘記了，這樣做不能給人帶來真正的價值，於是最後他在利用互聯網社區引導需求的時候遇到了問題 ...
福特是一個商業的天才，更是產品的天才。
他可以發現人們需要“更好的交通工具”這個大需求，並肯定了這個需求的渴望程度會隨著社會交往的擴大會越來越強。同時他肯定了“更快的”這個用戶的首要期望，結合這個期望開始思考。然後，他又判斷出汽車比火車有更低的成本，而且對於用戶更有價值，會替代火車。最後，他用“汽車”而不是“馬”來滿足需求、達到並超越期望， 同時引導用戶往下的進一步需求和期望... 於是，他的商業回報自然而然的產生了。
用戶的真正需求是什麼？ 》 用戶的期望值是什麼？ 》 如何做才對用戶最有價值，並讓企業獲利？ 》 如何超越期望並引導需求，獲取更高更長久的商業利益？
這是一個必然思考邏輯，違背這個邏輯出來的產品勢必難以獲取長久的成功。從某種程度上來說，產品模式是“用戶真正需要的是什麼？”，產品設計是“主要滿足什麼期望值，給用戶帶去什麼價值？”，商業模式是“用什麼功能，如何賺錢？”，創新設計是“如何超越期望，獲取更高更長久的利益？”。
所以，我在同意邵亦波所說“創業者更應該注重‘產品’”的同時，主張一個產品的主導者甚至是一個企業的領導者，更應該注重：
產品模式的設計：用戶真正需要滿足的需求是什麼？
產品的設計：讓用戶達到什麼樣的期望？給他們帶去什麼價值？......
從哪些方面如何具體做好需求分析
1. 訪問並與有潛力的用戶探討
為找出新軟件產品的用戶需求，最直截了當的方法是詢問他們。本章討論如何尋找合適的用戶代表，而在第8章講述從這些代表中獲取需求的技巧。
2. 把對目前的或競爭產品的描述寫成文檔
文檔可以描述一種所必須遵循的標準或產品所必須遵循的政府或工業規則。
3. 系統需求規格說明
一個包含軟、硬件的產品需要一個高檔次的系統需求規格說明以介紹整個產品。系統需求的子集被分配到每個軟件子系統中（ Nelsen 1990）。附加的詳細軟件功能需求將從有關軟件的系統需求裡獲得。
4. 對當前系統的問題報告和增強要求
指導用戶和提供技術支持的工作人員是最有價值的需求來源。他們收集了用戶在使用現有系統過程中所遇到問題的信息，還接受了用戶關於系統改進的想法。
5. 市場調查和用戶問卷調查
調查有助於從廣大有潛力的用戶那裡獲得大量定量的數據，務必調查相關的用戶並詢問一些能產生反響的好問題。
6. 觀察正在工作的用戶
對當前系統的用戶和將來系統的有潛力的用戶，分析員觀察“日常工作”以獲得經驗，這些經驗能提供很有價值的信息。分析員可通過觀察用戶與所關聯的任務環境的工作流程來預見用戶在使用當前系統時所遇到的問題，並能分析新的系統可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998）。比起僅僅簡單地詢問用戶，並記下用戶在處理任務時的步驟來說，直接觀察用戶的工作流程可以對他們的活動有更正確的理解。分析員必須抽象和總結用戶的直接活動，以確保所獲得的需求具有普遍性，而不僅僅代表單個用戶。一個富有技巧的分析員還可以為改進用戶的當前事務處理過程提出一些見解。
7. 用戶任務的內容分析
通常通過開發具體的情節（ s c e n a r i o）或活動順序（有時稱作“情節”），可以確定用戶利用系統需要完成的任務，分析員由此可以獲得用戶用於處理任務的必要的功能需求。
需求分析的作用及如何進行需求分析
通過對應問題及其環境的理解與分析，為問題涉及的信息、功能及系統行為建立模型，將用戶需求精確化、完全化，最終形成需求規格說明，這一系列的活動即構成軟件開發生命週期的需求分析階段。
需求分析是介於系統分析和軟件設計階段之間的橋樑。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟件角度對它們進行檢查與調整；另一方面，需求規格說明又是軟件設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或儘早剔除早期錯誤，從而提高軟件生產率，降低開發成本，改進軟件質量。
需求工程是隨著計算機的發展而發展的，在計算機發展的初期，軟件規模不大，軟件開發所關注的是代碼編寫，需求分析很少受到重視。後來軟件開發引入了生命週期的概念，需求分析成為其第一階段。隨著軟件系統規模的擴大，需求分析與定義在整個軟件開發與維護過程中越來越重要，直接關係到軟件的成功與否。人們逐漸認識到需求分析活動不再僅限於軟件開發的最初階段，它貫穿於系統開發的整個生命週期。80年代中期，形成了軟件工程的子領域——需求工程(requirementengineering,RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《RequirementsEngineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，並開始開展工作。 需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特徵和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。RE可分為系統需求工程（如果是針對由軟硬件共同組成的整個系統）和軟件需求工程（如果僅是專門針對純軟件部分）。軟件需求工程是一門分析並記錄軟件需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟件，並通過一系列重複的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟件的需求描述和一些性能參數。
需求工程是一個不斷反覆的需求定義、文檔記錄、需求演進的過程，並最終在驗證的基礎上凍結需求。80年代，HerbKrasner定義了需求工程的五階段生命週期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理。近來，MatthiasJarke和KlausPohl提出了三階段週期的說法：獲取、表示和驗證。
綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：
（1）需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；
（2）需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，並儘可能多的捕獲現實世界的語義；
（3）形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；
（4）需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；
（5）需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。...
如何進行用戶需求分析
1.概念
需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.
關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".
百事通
而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.
需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:
需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.
從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.
任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.
2.需求分析的任務
開發軟件系統最為困難的部分就是準確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟件系統的接口.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難.
目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間接口是系統開發人員最頭痛的問題.
對於商業最終用戶應用程序,企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?
然而,即便並非出於商業目的的軟件需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟件.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重複返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟件開發者身上發生.
近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件.不幸的是,當他們開發完這個工具後,發現這個工具不能打印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思準確,如果我們沒有編寫文檔,軟件達不到期望目標也只能是咎由自取了.
相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此係統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.
事實上,需求文檔在開發過程中一直起指導作用.
3.需求分析過程
可把整個軟件需求工程......
如何做好需求分析，需求調研
轉載以下資料供參考
從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。
原因
需求分析就是分析軟件用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟件卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟件，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個for linux的軟件，而你在軟件開發前期忽略了軟件的運行環境，忘了向用戶詢問這個問題，而想當然的認為是開發for windows的軟件。當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。
需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟件開發的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟件系統的開發中，他的作用要遠遠大於程序設計。
任務
簡言之，需求分析的任務就是解決“做什麼"的問題，就是要全面地理解用戶的各項要求，並準確地表達所接受的用戶需求。
過程
需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。
問題識別：就是從系統角度來理解軟件，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟件運行是所需的內存、CPU等)、軟件成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
分析與綜合： 逐步細化所有的軟件功能，找出系統各元素間的聯繫，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。
制訂規格說明書： 即編制文檔，描述需求的文檔稱為軟件需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。
評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。
方法
需求分析的方法有很多，這裡只強調原型化方法，其它的方法如：結構化方法、動態分析法等，從來沒用過這些方法在此不討論。
原型化方法是十分重要的，原型就是軟件的一個早期可運行的版本，它實現了目標系統的某些或全部功能。
原型化方法就是儘可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能。但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟件工具快速的建造一個原型系統，這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。
原型主要有三種類型：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。
實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。
進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。
在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。
廢棄策略：先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反覆進行修改,形成......
如何做需求分析
首先了解企業經營目標，進行分配人員的招聘，然後讓各部門做月度或者年度類的招聘需求，每月度之前再確認，最主要的是你們要有明確的目標，還有可根據去年的招聘情況和經營目標做一個對比，成比例的一個增長，然後也根據去年的離職率哪個月份比較多，哪些時間好招聘去做好一個招聘計劃等等。
如何才能把軟件需求分析做好
我的第一個故事來自大名鼎鼎的東軟。我在2005年接一個項目的時候，聽說這個項目之前是東軟做的。當時東軟在做這個項目的時候，整個過程經歷了10多次結構性的大變更，局部性的調整更是不計其數。據說某天早上，客戶對某個功能不滿意，他們不得不對幾百處程序進行修改。之後客戶對修改的內容還是不滿意，又不得不將幾百處修改重新改回來。最後這個項目導致的結果是，整個這個項目組的所有成員都離開了東軟，並似乎從此不願涉足軟件開發領域。多麼慘痛的教訓啊!我常常聽到網友抱怨客戶總是對需求改來改去，但客戶對需求改來改去的真正原因是什麼呢?當我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢?他不知道，於是就在一點兒一點兒試，於是這種反覆變更就這樣發生了。如果我們明白了這一點，深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。記住，當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，他為什麼提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。
如何做需求分析
做市場調查、商業情況等。也可以做一個問答卷。