前言：作為軟件開發(fā)人員，一定要了解軟件工程學，而這門科學的第一步是需求分析，打開任何一本軟件工程的書籍翻看目錄知道了。在實際的一個項目中，在進行需求分析之后，對這個項目進行規(guī)劃、編碼，到后完成這個項目，看著這個項目后實施應用，對我們開發(fā)人員來說，這真是一種成感�？墒窃谌蘸蟮氖褂眠^程中，客戶不停地提出各種意見和建議，讓我們沒法把精力投入到其他項目，而是不停地修改舊作，相信我們都遭遇過。

需求分析是指理解用戶需求，軟件功能與客戶達成一致，估計軟件風險和評估項目代價，終形成開發(fā)計劃的一個復雜過程。需求分析主要(還有很多，比如性能需求、可靠性需求、逆向需求、將來可能提出的需求，這里不做介紹)包括：業(yè)務需求、客戶需求和功能需求三個部分。業(yè)務需求(Business Requirement )意為客戶對產品的目標或者要求;客戶需求(User Requirement )意為客戶在使用產品過程中需要完成的一系列任務，功能需求(Functional Requirement )指定了產品系統(tǒng)必須提供的功能。在整個軟件系統(tǒng)的開發(fā)過程中，其實有很多問題是由于在需求分析階段沒有正確實施而產生的。下面一一列出：

1、對需求理解的錯誤

我是從工程角度來理解的，當甲方(客戶)向乙方(開發(fā)方)提出產品需求的時候，其描述過程往往是通過口述語言來表達出來的，但不可能的保證其描述正確，同時也不能保證收聽者完全正確理解，這是產生了分歧。當乙方將產品初期模型交給甲方看，甲方驚呼這不是我們要的東西，這時已經浪費了大量的時間、人力和物力。

2、實際應用與初期預想有出入

當客戶提出具體要求之前，其實他并不知道這個產品在實際使用中的情況，一切要求都是憑空想象出來的，客戶將要求提給開發(fā)方，開發(fā)方開始工作，當客戶拿到這個產品的Demo版的時候，開始實際操作，他會慢慢對產品的界面、操作、易用性、功能等等有一些認識，這個時候很有可能對產品需求有更改需求。

3、每個客戶的情況不一

人的五根手指還不一樣長呢，客戶也一樣，100人的公司和10000人的工廠，實際應用怎么可能完全一樣?但這里也不排除人為因素的存在。

4、產品本身的問題

人無完人，我們會努力做到精益求精，力保產品的可靠性，但難免會遇到bug。客戶在使用了一段時間后，發(fā)現產品的自身問題，可能是數據莫名丟失，也可能是系統(tǒng)崩潰，還可能是兼容性問題，這個時候需要找到開發(fā)方來進行產品升級或者修改。 算需求分析很完善，整個項目進行的一切順利，但每個開發(fā)人員的能力參差不齊，造成產品自身問題，這是根本無法避免的。

我們當然希望客戶永遠不會提出需求變更，但如果一定要變化，而我們又不得不面對，我們該怎么辦?

對需求分析人員培訓

看了上面的分析，當然第一個需要培訓的是需求分析人員了，這是開始，也是根源，還有是規(guī)范需求分析人員與客戶的溝通方式，以及規(guī)范記錄需求的文檔格式。爭取保證雙方和諧地完成溝通會談。如果還是不行，那只能更換作需求分析的員工了。

對開發(fā)人員培訓

我想這個不用多說了吧，我們都該有緊迫感了。

保證需求文檔的有效性

工作以來我還從未看過正式的需求文檔，這也是軟件業(yè)普遍存在的問題，因為人們不重視它，沒人關心它是否合理，沒人關心它是否實用，有的甚至是在日后慢慢補進去的。所以希望開發(fā)公司一定要重視需求文檔，要對需求文檔有一個合理性的審查。

從軟件工程學來看

首先要從系統(tǒng)分析和編碼入手，提高系統(tǒng)的可靠性，保證代碼的質量，增加系統(tǒng)的可擴展性和可移植性，降低因需求變更而帶來的風險和維護代價。

從測試入手，一定要保證測試的質量，并且及時作測試。

采用面向對象(OO)技術

面向對象方法學的出發(fā)點和基本原則，是盡可能地模擬人類習慣的思維方式，使開發(fā)軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程，也是使描述問題的問題域與實現解法的求解域在結構上盡可能一致。OO 的意義在于分析和設計軟件系統(tǒng)的思考方式，以及建立對象庫以后的軟件重用將給軟件系統(tǒng)的開發(fā)帶來質的改變，但是在建立OO 開發(fā)體系之前的過程，一定會是一段荊棘遍布的路，需要付出加倍的努力以及達成思想的轉變。這里還有一個誤區(qū)需要澄清的是很多人以為用了C++，PB ，VB ，DELPHI 是面向對象的開發(fā)了，其實只是用了一些面向對象的工具，骨子里仍然是結構化的分析和設計方法，套上一層OOP 的外殼而已。

可見，在面對需求變更時，除了要對人員培訓來提高開發(fā)團隊的整體素質外，從系統(tǒng)分析和設計角度可以提高產品的可靠性，做到對需求變更的靈活應對，這些至少可以在一定程度上降低產品的風險和維護代價，提高客戶的滿意度。

以上這些是我工作以來對軟件工程學以及實際工作中的一些認識，并且參考了一些書籍和網絡文獻寫出來的，希望可以對大家在解決問題中有一些實際的幫助。