我曾在濟南一家軟件公司開發管理軟件，那時剛剛完成北大青鳥的培訓，所找的第一家軟件公司，這家軟件公司幾十個人的規模。用jsp開發。剛進入公司就分配到一個項目組，該項目已做到一半了，該項目搞jsp就三個人，其中一個是我的頭，一個搞數據庫管理，一個搞jsp開發。在參與項目的過程中也產生了困惑。可惜當時沒有機會也沒有高人指導解決此困惑。後來隨的工作經驗的豐富以及跟各位朋友的交流，逐漸明白了困惑所在。特寫下此文，希望能幫助還有此困惑的朋友。
當時參與的項目還算是表面上正軌的項目流程，採用的算是瀑布模型。該項目問題也是很多的（真不知道是那個項目經理是不是偷懶，世界上那麼多知名的軟件工程產品如RUP就沒去仔細學學）。
我第一次的困惑就是項目需求文檔跟做到一半的軟件無法聯繫起來，爲什麼呢，當時沒想明白，我的頭也只是一味的說要多主動去做，多主動去理解，還說你必須比客戶更瞭解業務，文檔不可能那麼詳細。到了最後項目依然沒有改變大改的命運，不過還得佩服那個項目經理，在理論上偷懶，實踐上還是可圈可點的，說服了大家接受這個大改。根本的原因是需求文檔跟軟件設計之間少做了一個非常重要的工作，就是需求分析，當我拿到這些文檔時就不可避免的要自己做軟件分析，要命的是開發jsp的同事她也要做這個分析，這個工作都是不自主進行的，這個困惑就產生了，我分析的結果自然和她分析的結果不一樣，工作自然就無法繼續下去了，2個人的分析不一致是無法配合的。我的頭理念也是十分錯誤的，你如果自以爲比客戶還了解業務，就會陷入到一個實際上是猜客戶業務的過程，不會去虛心把客戶當老師，需求自然就把握不準，項目大改自然就避免不了了。
第二次困惑就測試，測試不是誰都適合乾的，開發人員是堅決不能從事黑盒測試的，這個是鐵律，可公司卻不講究這個，我當時也很困惑，爲啥跟我學的不一樣，無論什麼測試都是開發人員做，但項目經理也有想解決的問題，怎麼能測試出深層的業務bug。這個照那時的項目過程是永遠也做不到的。問題的所在就是沒有相關的測試文檔，測試文檔也得有個輸入吧，這個輸入文檔裏最重要的還是需求分析。沒有需求分析的後果就是無論誰去測試，其測試標準是不統一的，一個人認爲是bug，另外一個人認爲不是，這測試沒法進行了。
至於怎麼進行需求分析，可以多去看看RUP的資料。