很多需求分析的工作都是從需求調研開始，需求調研是需求分析最重要的一環，決定之後的工作能否順利地展開，與客戶的交流決定了能否明確的交換雙方的想法，讓客戶與我們都可以達到滿意。面對客戶群體的不同層次決定了如何交流，不同的群體對程式設計的了解是不同的，對不同的人要有不同的交流方法，而需求調研不是一朝一夕所可以完成的，大約需要幾個月才能掌握真實可靠的客戶需求。
了解了客戶需求，就正式開始了，組織一場研討會，具體討論一下我們應當怎樣與客戶討論業務需求。以往我們常常認為，需求分析是一件最簡單的事情。客戶說他們需要做乙個什麼軟體，有些什麼功能，我們照著做就可以了，所謂的需求分析員就是需求的記錄員。這是乙個極大的錯誤，許多失敗的軟體專案，或者說軟體專案中的需求問題，大多都源於此。經過人們多年的研究發現，在需求分析過程中，客戶存在的最大問題就是提不出正確的需求，這表現為幾種形式：
1.由於對軟體不了解，客戶提不出需求，不知道軟體最終會做成什麼樣子。雖然在自己心中對軟體有乙個大體的想法，但是一旦到細節的時候，就會描述的模稜兩可。
2.能提出一些業務需求，但當軟體做出來擺在自己面前時，需求就變了。總是當看到真實的軟體的時候，才發現現實理想有差距，而又很難描述這些不同的地方，這就造成程式設計師對軟體改了又改了。
3.能非常詳細地提出業務需求，甚至有時候該怎麼做的提出來了。這些客戶雖然對專業的知識有一些了解，但是對程式的想法過於理想，完成的時間會大大增加並增加人工的成本過於理想而無法實現。
我們去分析客戶提出的所有原始需求。他們為什麼要提出這項需求，提這項需求的目的是什麼？只有經過這樣的分析，我們才能深刻地理解需求，進而運用我們的專業知識，提出更加合理的技術方案。但非常遺憾，我們在需求分析中常常不是這樣做的，甚至當軟體都開發出來了，需求分析人員都說不出客戶為什麼要提出這個需求，更談不上了解業務操作流程。一句經典的話是：「客戶讓我們這樣做的。」，我們做需求分析，眼界不能僅僅停留在軟體本身，應當更開闊一些，應當擴充套件到跟這個業務有關的那些領域知識中。
需求分析工作是乙個迭代的過程：需求捕獲->需求整理->需求驗證->再需求捕獲······需求捕獲是這個迭代過程的開始，也是整個需求分析工作中最重要的部分。
而需求的捕獲是乙個很崎嶇的道路，在軟體需求捕獲過程中，最根本、最容易犯錯的問題是什麼呢？我是乙個態度的問題，是採用主動態度去捕獲需求，還是採用被動的態度去捕獲需求。若是被動的捕獲需求，把客戶的需求直接給開發人員，那麼需求調研人員的存在就不需要了，開發人員與客戶之間也沒有交流，會對專案存在巨大的影響。所以我們要主動的捕獲需求，從客戶那裡獲取所有我們所需要的需求，什麼是客戶嘴中沒有說出來的需求，並不是客戶故意賣弄官子不願說出來，而是在客戶所在業務領域已經約定俗稱，在他們看來已經是天經地義，根本就不用說出來的業務規則。然而，作為剛剛涉足該領域的需求人員，他們是不了解這些規則的。
軟體需求分析 閱讀筆記
筆記要求 發表一篇閱讀筆記，說明本學期 軟體需求分析 需要掌握哪些必要的內容？針對每個內容點說出自己的理解，並繪圖標意相互之間的關聯關係。讀 需求工程 軟體建模與分析 有感 今天大致的看了一下這本書，對軟體需求分析有了初步的了解，我認為學習軟體需求分析需要掌握的內容主要包括五個方面 需求基礎與過程 ...
軟體需求分析閱讀筆記
今天讀了關於如何做需求分析的博文，學習了軟體需求與分析需要掌握的一些內容，下面就做一些總結。首先要認識到深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。第乙個舉出來東軟的例子，東軟在做這個專案的時候，整個過程經歷了10多次結構性的大變更，區域性性的調整更是不計其數...
軟體需求分析 閱讀筆記6
在需求開發活動之後，需求基線應該成為後序軟體系統開發的工作基礎和粘合劑。需求管理在需求開發之後的產品生命週期中保證需求作用的有效發揮。作為需求開發的結果，最終的需求應該被明確和固定，需求基線就是被明確和固定的需求集合，是專案團隊需要在，某一特定產品版本中實現的特徵和需求集合。需求基線是需求開發過程中...