ieee軟體工程詞彙表中將軟體的需求定義為：
pmbok第四版中把需求定義為：根據合同、標準、規格或其他正式的強制性檔案，某個系統、產品、服務、成果或部件必須達到的條件或具備的能力。
實施立項開始，需求就成了所有專案經理的心頭之痛。客戶花錢購買了我們軟體，理所當然地認為軟體可以解決一切問題、甚至代替管理;加上銷售過度承諾、客戶應用經驗的增加和對軟體的了解程度加深等，都有可能使客戶對軟體的需求不斷變化。如果不能有效管理這些需求，就很容易導致專案失去控制，客戶購買的一輛qq，也許最後你不得不為他打造一輛勞斯萊斯。
一、需求無法控制，只能進行管理
需求無法控制，只能進行管理，正如吃飯一樣，餓了就得吃，不吃難受。為了把需求管理在一定的範圍內，首先，實施顧問必須充分了解銷售階段是否有過度承諾(包括文字或簽約)。其次，我們在制定實施方案時就要與客戶專案負責人確認實施範圍、目標、專案風險及本次實施工作的重點。專案管理者聯盟文章
二、了解需求產生的原因
總結大部分專案，提出的需求所產生的原因往往集中在以下幾方面：
1、調研產生的需求;
2、對軟體操作不熟悉，總覺得需要快捷方式或快捷鍵;**目管理者
3、操作模式同之前的軟體有較大的區別，這種情況尤其是此前使用過軟體或習慣了excel靈活模式的人；
4、業務流程還未理順，尤其是部門之間的銜接還不順暢，這時候抱怨產生的需求;
專案管理者聯盟
5、相關的基礎資料不完善，甚至有錯誤的地方;
6、出於部門利益的考慮，某個人或部門的想法，沒有考慮全域性;
7、客戶方人員或專案負責人變更引起;
8、企業高層比較理想化的思維;
9、隨著對軟體深入了解，對軟體提出的更高要求。
三、需求收集
收集需求的方法有很多，主要有：
1. 與專案干係人一對一訪談，這種方法很有效，但是成本很高，而且很花時間。
2. 焦點小組會議
3. 問卷調查法
4. 觀察法
5. 原型法
四、需求分析
1、需求調研和業務流程整理完成後，實施顧問手裡就會有一大堆的新需求。這時，最忌諱的就是哪個最簡單的，就先實現哪乙個。而應該是那個最重要，最有影響力，就要先實現它，以達到很好的短期效果。
2、針對實施過程中產生的臨時需求，需要灌輸"先固化、再優化"的思想。
3、對於應用層面的，主要加強培訓，並對提出者要給予鼓勵和表揚，說明將在後續的工作或軟體版本中給予響應或解決。
4、對於關心部門利益的，可提交客戶方專案負責人或多部門同時開會討論解決，很多時候這種效果很明顯。
5、對於影響了企業全域性工作或影響實施效果的需求，經過判斷，應和客戶管理層進行溝通。
6、隨著客戶應用層面的提公升，客戶提出的需求必須明確可以提供解決方案，但不在本次實施範圍。
五、需求需要溝通並確認
客戶提供出了眾多的需求，均需充分了解客戶需要的是乙個解決方案還是真正的功能需求。提前和客戶方專案負責人及提出人一起，對需求的認識達成一致;確認需求時要避免與一般業務人員交談，因為一般業務人員可能僅僅考慮軟體的實際操作或習慣問題，應該與企業的管理層溝通，了解他們需求背後實際的管理要求，從而分清客戶需要的是乙個解決方案還是軟體的功能需求;確認後雙方書面簽字確認。我們實施顧問經常忽略的一點是需要解決未和客戶確認，這非常重要，問題解決一定要確認，看處理情況可以高調宣布。
六、不要滿足所有需求
對專案干係人提出的新的需求不要立即答應，要經過專案評審委員會審核批准後才能滿足，審核不批准就拒絕該需求。
七、承諾必須兌現
如果同客戶確認了需求並明確了解決方案和實現時間，必須在規定時間內兌現，不能如期兌現的，也需提前和客戶溝通，切忌到兌現時間沒完成才去和客戶談，一次還好，多了直接影響客戶對實施顧問的信任度。專案經理圈子
技術人員管理
人員的管理確實比較煩，但是人總要向上走，那就不得不管理人，既然要管理人那就先定義幾條規則吧 技術人員應遵守的職業規範 l 按照公司約定的或行業及職業的規範開展相關的工作 l 本著務實 勤勞 主動 好學的原則工作 l 本著團結 協助 互助 貢獻的原則參與團隊的工作 l 本著符合規範，追求高質量 高標準...
專案管理之需求管理
需求的變化問題 在軟體開發過程中如果只有一條真理的話，那一定是 需求的變化是永恆的，需求不可能是完備的。軟體開發的過程實際上是同變化做鬥爭的過程，需求的變更不一定是壞事，也有可能是好事，是商業機會，對市場敏感的人可以從需求的變化中發現市場機會。需求變化的原因很多，如 一開始沒有識別全，需要增加需求 ...
怎樣管理研發技術人員
第乙個是甄選優秀的人才。其他的崗位都是要選擇最適合的人，但是研發不是，研發要選擇比較優秀的人。我們對研發人員的要求，有乙個素質模型，當然不是每個企業都是這樣的。面試考核的時候要看你的素質是怎樣的。第乙個是思維能力，第二個就是成就導向，成就導向就是乙個人追求卓越的願望，你願意不願意追求乙個卓越，希望把...