前言：作為軟件開發(fā)人員，一定要了解軟件工程學，而這門科學的第一步就是需求分析，打開任何一本軟件工程的書籍翻看目錄就知道了。在實際的一個項目中，在進行需求分析之后，對這個項目進行規(guī)劃、編碼，到最后完成這個項目，看著這個項目最后實施應(yīng)用，對我們開發(fā)人員來說，這真是一種成就感?？墒窃谌蘸蟮氖褂眠^程中，客戶不停地提出各種意見和建議，讓我們沒法把精力投入到其他項目，而是不停地修改舊作，相信我們都遭遇過。
需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發(fā)計劃的一個復(fù)雜過程。需求分析主要（還有很多，比如性能需求、可靠性需求、逆向需求、將來可能提出的需求，這里不做介紹）包括：業(yè)務(wù)需求、客戶需求和功能需求三個部分。業(yè)務(wù)需求（Business Requirement）意為客戶對產(chǎn)品的目標或者要求；客戶需求（User Requirement）意為客戶在使用產(chǎn)品過程中需要完成的一系列任務(wù)，功能需求（Functional Requirement）指定了產(chǎn)品系統(tǒng)必須提供的功能。在整個軟件系統(tǒng)的開發(fā)過程中，其實有很多問題是由于在需求分析階段沒有正確實施而產(chǎn)生的。下面一一列出：
1、對需求理解的錯誤
我是從工程角度來理解的，當甲方（客戶）向乙方（開發(fā)方）提出產(chǎn)品需求的時候，其描述過程往往是通過口述語言來表達出來的，但不可能100%的保證其描述正確，同時也不能保證收聽者完全正確理解，這是就產(chǎn)生了分歧。當乙方將產(chǎn)品初期模型交給甲方看，甲方驚呼這不是我們要的東西，這時已經(jīng)浪費了大量的時間、人力和物力。
2、實際應(yīng)用與初期預(yù)想有出入
當客戶提出具體要求之前，其實他并不知道這個產(chǎn)品在實際使用中的情況，一切要求都是憑空想象出來的，客戶將要求提給開發(fā)方，開發(fā)方開始工作，當客戶拿到這個產(chǎn)品的Demo版的時候，開始實際操作，他就會慢慢對產(chǎn)品的界面、操作、易用性、功能等等有一些認識，這個時候就很有可能對產(chǎn)品需求有更改需求。
3、每個客戶的情況不一
人的五根手指還不一樣長呢，客戶也一樣，100人的公司和10000人的工廠，實際應(yīng)用怎么可能完全一樣？但這里也不排除人為因素的存在。
4、產(chǎn)品本身的問題
人無完人，我們會努力做到精益求精，力保產(chǎn)品的可靠性，但難免會遇到bug.客戶在使用了一段時間后，發(fā)現(xiàn)產(chǎn)品的自身問題，可能是數(shù)據(jù)莫名丟失，也可能是系統(tǒng)崩潰，還可能是兼容性問題，這個時候就需要找到開發(fā)方來進行產(chǎn)品升級或者修改。 就算需求分析很完善，整個項目進行的一切順利，但每個開發(fā)人員的能力參差不齊，造成產(chǎn)品自身問題，這是根本無法避免的。
我們當然希望客戶永遠不會提出需求變更，但如果一定要變化，而我們又不得不面對，我們該怎么辦？
5、對需求分析人員培訓
看了上面的分析，當然第一個需要培訓的就是需求分析人員了，這是開始，也是根源，還有就是規(guī)范需求分析人員與客戶的溝通方式，以及規(guī)范記錄需求的文檔格式。爭取保證雙方和諧地完成溝通會談。如果還是不行，那就只能更換作需求分析的員工了。
6、對開發(fā)人員培訓
我想這個不用多說了吧，我們都該有緊迫感了。
6、保證需求文檔的有效性
工作以來我還從未看過正式的需求文檔，這也是軟件業(yè)普遍存在的問題，因為人們不重視它，沒人關(guān)心它是否合理，沒人關(guān)心它是否實用，有的甚至是在日后慢慢補進去的。所以希望開發(fā)公司一定要重視需求文檔，要對需求文檔有一個合理性的審查。
7、從軟件工程學來看
首先要從系統(tǒng)分析和編碼入手，提高系統(tǒng)的可靠性，保證代碼的質(zhì)量，增加系統(tǒng)的可擴展性和可移植性，降低因需求變更而帶來的風險和維護代價。
從