乙個專案的開始便是為了滿足客戶的需求，有了需求才有了我們的供需關係。但是軟體與人之間的關係並不是如同人與人來的那麼清晰於簡單。人們對於乙個目標的軟體總是有不同的想法和思路。客戶和經理的交流和溝通並不能是他們完全的理解對方，而經理帶回專案交給開發團隊也並不是能夠完全的滿足顧客的想法。因為顧客經常也不知道他們想要的是什麼，他們也知識靠想象來嘗試，這無疑給乙個開發團隊帶來了無窮的潛在茅盾。
《我們應當怎樣做需求分析》這一文章，做好軟體需求調研從這幾方面入手。首先是做需求調研，就是採集需求這個階段，在這個階段其實是乙個反覆迭代的過程：需求捕獲——需求整理——需求驗證——再需求捕獲。
需求的捕獲有個初始階段，然後我們還不要不斷的接觸客戶溝通，了解客戶的變化並且了解客戶的目的自己理性的分析客戶到底要什麼。接下來我們開發團隊要不斷的與客戶開展研討會，跟客戶**的不是軟體功能，而是客戶現有的業務知識，用專業的話叫「業務領域分析」以及客戶現有的業務流程。在認識了客戶的業務領域之後，我們才能去分析他們提出的所有原始需求。他們為什麼要提出這項需求，提這項需求的目的是什麼？只有經過這樣的分析，我們才能深刻地理解需求，進而運用我們的專業知識，提出更加合理的技術方案。
需求的整理也就是需求分析人員對研討內容的分析和整理的過程。首先，需求分析人員應當通過用例模型，劃分整個系統的功能模組，以及各個模組的業務流程。用例模型分析是乙個由粗到細的過程，這樣乙個過程也是符合人類認識世界的思維習慣的乙個過程。最先，我們應當對整個系統繪製用例圖，設計用例場景，並依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然，在整體用例分析的同時，我們還應當進行乙個整體的角色分析，繪製乙個角色分析圖，進行乙個流程分析，繪製乙個流程分析圖。用例分析的過程，之所以稱之為分析，它摻入了很多需求分析人員對業務的理解與設計：模組如何劃分、流程如何設計、業務如何轉換，等等。
需求的驗證即當我們完成了一系列的分析整理並形成文件以後，應當對及時地與客戶進行反饋，確認我們的理解是否正確。但是需求的驗證也不是此時才開始而是從始至終的因為我們是乙個服務行業，顧客的需求的是不斷變化，我們得到的的需求也不斷有細微變化。在開發過程中不斷的與顧客交流這樣客戶可以及時地提出我們對需求理解的偏差，或者及時提出對我們設計不滿意的地方，使我們存在的問題得到及時地發現與解決。問題及時的解決，使我們修復問題的代價得以降至最小，不會浪費不必要的勞動。
最後便是雙方在需求規格說明書的簽字了。這也是需求確認書，雙方達成一致。但這也並不以為，後面所有的工作都一次為標桿開展。需求分析階段完成所有的需求分析工作，它將延續到設計、開發，甚至測試階段。但是這種需求的變化是可見的聽不會隨意的變化而是只發生在某些固定的範圍內，弄清楚了這些範圍，我們的問題就迎刃而解了。
我們應當怎麼做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太大往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...
我們應當怎麼做需求分析
無體現出論是從東軟開發軟體還是作者自己開發軟體的經歷中都體現出提前做好全面徹底的需求分析的重要性。而且就像上課時提到的不能完全任由客戶提出需求，也就是不能說使用者提出什麼需求就完成什麼，應該就能力還有開發實際情況，還有社會情況綜合提出。這樣給出自己的建設性的意見，不僅能夠使開發過程更加得心應手，而且...
怎麼做需求分析
如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階段...