在軟件開發的傳統瀑布模型中，需求分析的第一個階段也是最重要的階段。這個階段包括以最清楚的形式蒐集與客戶要求和定義有關的信息以及希望產品解決的問題。
這種分析包括瞭解客戶的商業背景和限制、產品必須執行的功能、它必須實現的性能水平、以及它必須兼容的外部系統。用來了解這些問題的技巧包括客戶面談、使用情況和軟件特性“購物清單”。分析結果一般以正式需求規範的形式呈現，並作爲下一個步驟的輸入。
至少，這是它理論上的應用情況。實際上，這個理論模型存在着許多問題，這些問題可能給分析過程的其它步驟造成延遲或連鎖性錯誤。本文討論項目經理在這個階段中遇到的一些常見問題，並提出可能的解決方案。
問題1：客戶並不（確切地）知道他們需要什麼
在需求分析階段，可能最常見的問題就是客戶對於他們的需要僅有一個模糊的概念，而要由你提出合適的問題、進行必要的分析，把這個不確定的概念轉化成一個正式文本化的軟件需求規範；這個規範反過來又可用作一個項目計劃和工程結構的基礎。
要解決這個問題，你應當：
- 確保在項目開始之初，你用了足夠的時間來了解項目的目標、交付成果和範圍。
- 確定客戶所使用的任何假設，用批評的眼光評估項目給終端用戶可能帶來的好處和風險。
- 嘗試爲項目寫出一份具體的遠景陳述，包括它提供的特殊功能或給用戶帶來的好處，以及希望它解決的所有商業問題。
- 讓客戶閱讀、考慮並同意前面完成的軟件需求規範，調整他們的期待，保證雙方充分理解項目交付成果。
問題2：需求在項目進行過程中發生改變
軟件開發項目中遇到的第二個問題是，隨着項目的發展，在第一階段定義的需求發生了變化。隨着開發不斷取得進展，軟件原型得以確定，這時客戶能夠更加清楚的發現原始計劃中存在的問題並做出必要的糾正，於是需求也因而改變。需求發生改變還可能是因爲外部環境的變化要求改造原始的商業問題，並因此有必要開發一個與最初建議的解決方案全然不同的解決方案。優秀的項目經理意識到這些可能性，並往往制定了後備計劃來應對這些變化。
要解決這個問題，你應當：
- 爲變更請求的收集、分析和組合制定一個定義明確的過程，保證你的客戶知道他/她的切入點。
- 爲每個開發階段設定轉折點，超過這個轉折點就不允許進行某些改變——例如，一旦一個模塊完成75%，就不允許進行重大改變。
- 保證向所有股東清楚地通報變更請求（和變更批准），以及進行變更的根本原因，因而還要對主項目計劃進行更新。
問題3：客戶的時間表不合理
我們常常聽到客戶這樣說：“這是一個非常緊迫的任務，我們需要項目在X周內完成。”常見的錯誤就是，沒有進行詳細分析，並瞭解項目的範圍以及完成項目所必需的資源，就同意客戶的要求。未經討論就同意不合理的時間表，你實際上在給客戶造成傷害：項目很有可能被延期（因爲不可能按時完成），或存在質量問題（因爲你在趕工，沒有進行適當的檢驗）。
要解決這個問題，你應當：
- 把項目需求規範轉化成一個項目計劃、詳細的任務和各階段所需的資源，併爲最佳情況、一般情況和最差情況建立模型。
- 保證項目計劃考慮到有效資源的限制，併爲檢測和質量檢驗保留足夠的時間。
- 與客戶討論最終期限問題，用你計劃草案中的數據爲你的陳述提供證據。如果你的計劃是合理的，則很有可能隨後的談判會極爲成效，並對雙方有利。
問題4：溝通客戶、工程師和項目經理間存在的隔閡
通常，客戶和工程師之間由於背景差異以及理解技術條款的不同方式，他們無法進行有效地溝通。這可能導致混亂和嚴重的溝通問題；因此，項目經理的一項重要任務——特別是在需求分析階段——就是保證雙方能夠準確瞭解交付成果以及必須完成的任務。
要解決這個問題，你應當：
- 在每次會議上做記錄，並向整個項目團隊分發這些記錄。
- 注意用詞一致。從一開始就列出一份你要使用的名詞術語表，保證所有股東都有一份，並堅持使用這些術語。
問題5：開發團隊並不理解客戶組織的政治策略
Bolman和Deal這兩位學者認爲一位高效的項目經理是一個把組織看作一個“競爭舞臺”的人，它理解權力、衝突、談判和聯盟的重要性。這樣的經理不僅熟悉運作和職能任務，他或她還認識到爲通用目標制定議程、建立觀點一致的聯盟以及向抗拒性的經理說明一個特定職位合法性的重要性。
在給大型組織執行大型項目時，這些技巧尤其重要，因爲信息常常分散在各處，因此需求分析往往會受到信任問題、內部利益衝突和信息低效這些因素的阻礙。
要解決這個問題，你應當：
- 審查現有的網絡，確定你需要的信息和可能擁有這些信息的人。
- 培養同盟，發展關係，並系統地考慮你在組織內的社會資產。
- 以符合他們自己經歷的方式說明問題，說服客戶組織內的反對者。
- 使用初始訪問/支撐點來推動議程。
- 希望上述討論能夠讓你意識到需求分析階段存在的可能缺陷，並提供一些避免這些缺陷的指導方法。祝你好運！