通過閱讀《我們應當怎麼做需求分析》： 一文，我了解了需求分析的基本步驟和一些方法
:（1）需求調研：如何與客戶交流、建立聯絡、研討業務需求，捕獲需求
：（2）需求分析：功能角色分析、業務流程分析與業務領域分析，用例分析及用例圖，查詢報表分析，原文分析，非功能需求
：（3）需求確認：需求列表,需求例項，快速原型法，需求規格說明書，評審與簽字確認會
一， 需求調研
1.與客戶交流的方法
首要的是收集需求，收集需求的方法千千萬，直接徵集客戶意見是最簡單粗暴的一種，但是效果卻不一定有多好
與客戶交流過程，不僅需要我們的理解、設計能力，更需要我們具有與人溝通交往的能力，wiegers的《software requirement》中更是提到，what & why，在與客戶溝通時，我們不能僅僅侷限於what ，客戶說什麼就是什麼，而更應該從why方面展開，通過理解客戶的意圖來得到對客戶意圖更深入的理解，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險。這毫無疑問會形成乙個良性迴圈，但要做到這一點並不容易，毫無疑問，在與客戶接觸初期的表現起到了極其關鍵的作用。大方而得體地提出自己的意見，會使客戶重視你的意見，甚至主動徵求你的意見。這一方面要求我們對自己要有足夠的自信，另一方面也要有循循善誘的表達能力。
2，主動收集需求
除了向客戶收集需求外，還可以通過訪問使用者，實際體驗，問卷調查，市場調查等手段收集需求
3，迭代
從客戶嘴中說出來的需求，只是整個軟體需求中的冰山一角，還有兩類需求需要我們自己去挖掘：客戶嘴中沒有說出來的需求，和客戶壓根兒就沒有想到的需求。
客戶嘴中沒有說出來的需求，並不是客戶故意賣弄官子不願說出來，而是在客戶所在業務領域已經約定俗稱，在他們看來已經是天經地義，根本就不用說出來的業務規則。然而，作為剛剛涉足該領域的需求人員，他們是不了解這些規則的。
如何破解這樣的問題呢？那就是要求我們在需求分析的整個過程，不斷進行業務領域知識的學習。多問why而不是what
另一種就是客戶壓根兒沒有想到的需求。
如何解決這樣的問題呢？首先，在需求分析階段，需求分析人員應當在深入理解業務領域與需求的基礎上，通過分析提前發現這些需求。作為需求分析人員，他們應當站在客戶的角度去思考，我們的軟體應當設計成什麼樣子，每個需求的真實意圖是什麼。站在這個基礎上，再運用專業知識去整理、分析與設計。先用最短的時間先做乙個可以展示和操作的原型給客戶看，讓客戶提一些意見。然後再在這個原型的基礎上再多做一些，再給客戶看。一步一步推進，直到最終專案研發結束。採用這樣的方式，最適合那些客戶在專案初期提不出什麼需求，也沒用合適的參照物來進行需求分析的軟體專案，特別是那些資料分析與決策類的軟體專案。
二， 需求分析
需求分析不應當是太公釣魚，而應當是拉網排查。任何乙個疏忽都可能對專案研發帶來風險。因此，我們應當採用一套成熟而完整的分析方法，穩步而有序地完成這部分工作。不同型別的軟體專案其分析方法可能存在差異，但一般來說，資訊化管理類軟體專案通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。
需求分析不是一項一蹴而就就可以完成的工作，它需要乙個長期的過程，而這個過程是乙個由粗到細的過程，它體現了人類認識事物的客觀規律。在需求分析的初期，我們對需求的認識往往是整體的、巨集觀的，隨著分析工作的逐漸深入，一步步細化。
1， 功能角色分析
所謂功能角色分析，就是從乙個外部使用者的視角分析整個軟體系統能夠提供的功能，以及這些功能到底是提供給哪些角色使用。對乙個系統進行功能和角色方面的梳理和分析，可以採用的比較主流的方法之一就是繪製用例圖。
2，業務流程分析
如果我們現在做的需求分析是乙個企業資訊化管理系統，毫不疑問，我們的軟體系統就是在模擬企業已有的那些業務流程。在現實世界中，企業是按照怎樣的流程來管理，我們的軟體就應當去模擬這樣的流程。但是實際上，存在諸多問題導致我們不能完全模擬這些流程，有些環節則是應當在系統之外，由人工去完成的。我們進行流程分析，就是要求分析哪些是系統之內的，哪些是系統之外的。
除此之外，還可以對流程進行改進。一般來說，我們可以用以下思路來進行我們對流程改進的分析：清除低效環節、簡化業務瓶頸、整合可用資源，以及將繁瑣任務自動化。
在進行業務流程分析時，不可避免要用到用例分析、報表等
3， 業務領域分析
業務領域分析，就是對需求分析中涉及到的業務實體，以及它們相互之間關聯關係的分析。系統中應當有哪些實體，這些實體都有哪些屬性，被賦予了哪些行為，它們之間的相互關係是怎樣的，就成為了業務領域分析的重要內容，而業務領域分析也就成為了對系統進行的一種靜態分析。我們進行業務領域分析，就是通過與使用者進行交流，掌握領域知識，然後繪製成業務領域模型，去指導我們軟體開發的過程。
3， 非功能需求
那麼哪些是非功能需求呢？我們可以簡單歸納為「urps+」，即可用性（usability）、可靠性（reliability）、效能（performance）、可支援性（supportability）以及其它（+）。這些不針對於系統的功能，但卻對系統至關重要，非功能性需求是常常被輕視，甚至被忽視的乙個重要方面。
三.需求確認
1，需求列表
需求列表，又稱之為需求跟蹤表，是最原始的、使用者對業務需求的描述。用這樣乙個列表來開始分析，最後用它來驗證設計，為軟體開發指明方向。
其次，需求列表應當是站在業務人員的視角，對業務需求的簡明扼要的描述。
需求列表描述的更應當是客戶對軟體功能的意圖，即客戶使用這個功能所達到的目的，而不是功能的具體實現。
最後，需求列表也不是一步到位的，而是經過由粗到細逐漸整理形成的。
2， 快速原型法
在需求分析階段拿出實物，用實物與使用者確認需求，這就是快速原型法的基本思想
3， 需求規格說明書
使用者編寫的原始需求，是脫離了技術實現，編寫的乙份十分理想的業務需求。我們之所以要編寫自己的需求規格說明書，就是要本著實事求是、切實可行的態度，去描述使用者的業務需求。那些不可行的需求被摒棄，或者換成更加可行的解決方案。這就是需求規格說明書的重要作用。
閱讀部落格 《我們應當怎樣做需求分析？》筆記記錄
這篇部落格的作者開篇這樣寫道 幸福的家庭都是一樣的，不幸的家庭卻各有各的不幸 幸福的軟體專案都是一樣的，不幸的軟體專案卻各有各的不幸 或者說，成功的軟體專案都是一樣的，失敗的專案卻各有各的問題。軟體的失敗原因千奇百怪，但說到根本，問題還是出在軟體需求和分析上。從我們的角度來說，需求 於使用者的一些 ...
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...