前言：作為軟件開發人員，一定要了解軟件工程學，而這門科學的第一步是需求分析，打開任何一本軟件工程的書籍翻看目錄知道了。在實際的一個項目中，在進行需求分析之后，對這個項目進行規劃、編碼，到后完成這個項目，看著這個項目后實施應用，對我們開發人員來說，這真是一種成感。可是在日后的使用過程中，客戶不停地提出各種意見和建議，讓我們沒法把精力投入到其他項目，而是不停地修改舊作，相信我們都遭遇過。
需求分析是指理解用戶需求，軟件功能與客戶達成一致，估計軟件風險和評估項目代價，終形成開發計劃的一個復雜過程。需求分析主要(還有很多，比如性能需求、可靠性需求、逆向需求、將來可能提出的需求，這里不做介紹)包括：業務需求、客戶需求和功能需求三個部分。業務需求(Business Requirement )意為客戶對產品的目標或者要求;客戶需求(User Requirement )意為客戶在使用產品過程中需要完成的一系列任務，功能需求(Functional Requirement )指定了產品系統必須提供的功能。在整個軟件系統的開發過程中，其實有很多問題是由于在需求分析階段沒有正確實施而產生的。下面一一列出：
1、對需求理解的錯誤
我是從工程角度來理解的，當甲方(客戶)向乙方(開發方)提出產品需求的時候，其描述過程往往是通過口述語言來表達出來的，但不可能的保證其描述正確，同時也不能保證收聽者完全正確理解，這是產生了分歧。當乙方將產品初期模型交給甲方看，甲方驚呼這不是我們要的東西，這時已經浪費了大量的時間、人力和物力。
2、實際應用與初期預想有出入
當客戶提出具體要求之前，其實他并不知道這個產品在實際使用中的情況，一切要求都是憑空想象出來的，客戶將要求提給開發方，開發方開始工作，當客戶拿到這個產品的Demo版的時候，開始實際操作，他會慢慢對產品的界面、操作、易用性、功能等等有一些認識，這個時候很有可能對產品需求有更改需求。
3、每個客戶的情況不一
人的五根手指還不一樣長呢，客戶也一樣，100人的公司和10000人的工廠，實際應用怎么可能完全一樣?但這里也不排除人為因素的存在。
4、產品本身的問題
人無完人，我們會努力做到精益求精，力保產品的可靠性，但難免會遇到bug。客戶在使用了一段時間后，發現產品的自身問題，可能是數據莫名丟失，也可能是系統崩潰，還可能是兼容性問題，這個時候需要找到開發方來進行產品升級或者修改。 算需求分析很完善，整個項目進行的一切順利，但每個開發人員的能力參差不齊，造成產品自身問題，這是根本無法避免的。
我們當然希望客戶永遠不會提出需求變更，但如果一定要變化，而我們又不得不面對，我們該怎么辦?
對需求分析人員培訓
看了上面的分析，當然第一個需要培訓的是需求分析人員了，這是開始，也是根源，還有是規范需求分析人員與客戶的溝通方式，以及規范記錄需求的文檔格式。爭取保證雙方和諧地完成溝通會談。如果還是不行，那只能更換作需求分析的員工了。
對開發人員培訓
我想這個不用多說了吧，我們都該有緊迫感了。
保證需求文檔的有效性
工作以來我還從未看過正式的需求文檔，這也是軟件業普遍存在的問題，因為人們不重視它，沒人關心它是否合理，沒人關心它是否實用，有的甚至是在日后慢慢補進去的。所以希望開發公司一定要重視需求文檔，要對需求文檔有一個合理性的審查。
從軟件工程學來看
首先要從系統分析和編碼入手，提高系統的可靠性，保證代碼的質量，增加系統的可擴展性和可移植性，降低因需求變更而帶來的風險和維護代價。
從測試入手，一定要保證測試的質量，并且及時作測試。
采用面向對象(OO)技術
面向對象方法學的出發點和基本原則，是盡可能地模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程，也是使描述問題的問題域與實現解法的求解域在結構上盡可能一致。OO 的意義在于分析和設計軟件系統的思考方式，以及建立對象庫以后的軟件重用將給軟件系統的開發帶來質的改變，但是在建立OO 開發體系之前的過程，一定會是一段荊棘遍布的路，需要付出加倍的努力以及達成思想的轉變。這里還有一個誤區需要澄清的是很多人以為用了C++，PB ，VB ，DELPHI 是面向對象的開發了，其實只是用了一些面向對象的工具，骨子里仍然是結構化的分析和設計方法，套上一層OOP 的外殼而已。
可見，在面對需求變更時，除了要對人員培訓來提高開發團隊的整體素質外，從系統分析和設計角度可以提高產品的可靠性，做到對需求變更的靈活應對，這些至少可以在一定程度上降低產品的風險和維護代價，提高客戶的滿意度。
以上這些是我工作以來對軟件工程學以及實際工作中的一些認識，并且參考了一些書籍和網絡文獻寫出來的，希望可以對大家在解決問題中有一些實際的幫助。
