在我看來，軟體需求與分析，說的就是我們這些程式設計人員要理解客戶的需求，分析客戶想要的究竟是什麼，來做出使客戶滿意的作品。專案經理在和客戶溝通的時候要清晰地理解客戶的需求，這將為後續的軟體設計打下良好的 基礎。
需求調研：需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點——既是乙份體力活兒，更是乙份技術活兒。它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險。這毫無疑問會形成乙個良性迴圈，但要做到這一點並不容易，毫無疑問，在與客戶接觸初期的表現起到了極其關鍵的作用。
軟體需求與分析，它的任務就是確定對系統的綜合要求。要分析系統的資料要求並匯出系統的邏輯模型，修正系統的開發計畫。在進行軟體需求與分析的時候，我們要做的是深入描述軟體的功能和效能。我們應注意的是，所有的需求都是要站在客戶的角度上考慮，不能憑藉自己的主觀想象。要多與客戶進行溝通，讓客戶進行評價，這樣才能準確的進行需求分析。
在需求分析階段，主要包括1.業務需求，2.使用者需求，3..功能需求，4..需求分析報告。
業務需求針對的是公司，描述的是公司如何解決使用者的問題，如何滿足使用者的慾望，然後將利益最大化。
使用者需求針對的是人，描述的是使用者想做某件事情所遇到的問題，這需要使用者提供詳細的業務說明，業務流程等資訊。
功能需求就是將使用者需求歸類分解為計算機可以實現的子系統和功能模組，使用設計語言來描述和解釋永和的需求，來實現程式的設計。
需求調研不是一蹴而就的事情，是一件持續很久的事情。在這漫長的時間裡，我們需要依靠客戶的幫助，一步一步掌握真實可靠的業務需求。不僅如此，技術這東西總有不如意甚至實現不了的地方，我們需要客戶的理解與包容，這都需要有良好的客戶關係。按照現在的軟體運作理念，軟體專案已經不是一錘子的買賣，而是長期的、持續不斷的提供服務。按照這樣的理念，軟體**商與客戶建立的是長期共贏的戰略協作關係，這更需要我們與客戶建立長期友好的關係。
需求調研其實是門藝術，我有個觀點就是軟體以實用為準。我們要重視客戶需求，引導客戶得出比較好的解決問題辦法。從而編寫出高質量的軟體需求分析報告。
專案任務書下達給專案經理的時候，專案經理及調研人員應該對合同中軟體範圍認真審閱，雖然合同中的只大概對寫了軟體需求範圍，但這些資訊極為重要，它是調研計畫制定的乙個依據。
調研計畫制定，專案經理及調研人員對軟體範圍進行討論，對調研活動序列進行劃分，可以採用自頂向下的方法把活動細分，同時對各活動的週期進行評估，對各活動的資源進行分配，制定計畫時最好與以前的經驗及類似的專案關聯起來，使計畫制定的盡量準確些。在制定計畫時考慮到相應的分析，使分配的時間及資源盡量合理些。編制後的計畫在公司評審通過後，及時提交給客戶相關部分，一般為資訊中心，讓客戶對我們的調研計畫有充分的了解，同時讓他們在相應的時間協調相關的部門的人員參與我們的調研工作。
迭代是重複反饋過程的活動，它的目的是為了接近並達到所需的目標和結果。
軟體需求與分析 問題賬戶需求分析
案例 某大銀行的一位銀行卡辦公室的收賬經理liz遇到了乙個問題。她每週都收到乙份過期未付款的賬戶名單。這份報告已經從兩年前的250個賬戶增加到現在的1250個賬戶。為了確定那些嚴重拖欠債務的賬戶，liz需要通讀這份報告。嚴重拖欠債務的賬戶由幾個不同的規則確定，每個規則都要求liz檢查客戶的一項或幾項...
軟體需求與分析 認識
沒有技術背景很難真正成為乙個優秀的軟體需求分析師，最多也就是乙個業務需求分析師。菜鳥的軟體需求分析知識體系架構 個人認識 我以為對於軟體需求來說，我感覺並不需要什麼具體的知識體系，會侷限我們的想法 我的意思是不要讓思想拘束起來，解決了本質問題的就是好方法 私以為 需求的目的是做出 符合 的軟體，使用...
軟體需求分析
本章共分為四個部分，一軟體需求的任務和過程 二結構化分析方法 三，原型化方法四，動態分析方法。本章學習的要點是 1。了解軟體需求分析的目標和任務 2.了解軟體需求的獲得方法 3.掌握結構化的分析方法 4.了解需求規格說明和需求評審的主要內容。軟體需求分析的主要任務 深入描述軟體的功能和效能 確定軟體...