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

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

1、對(duì)需求理解的錯(cuò)誤

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

2、實(shí)際應(yīng)用與初期預(yù)想有出入

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

3、每個(gè)客戶的情況不一

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

4、產(chǎn)品本身的問(wèn)題

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

我們當(dāng)然希望客戶永遠(yuǎn)不會(huì)提出需求變更，但如果一定要變化，而我們又不得不面對(duì)，我們?cè)撛趺崔k?

對(duì)需求分析人員培訓(xùn)

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

對(duì)開(kāi)發(fā)人員培訓(xùn)

我想這個(gè)不用多說(shuō)了吧，我們都該有緊迫感了。

保證需求文檔的有效性

工作以來(lái)我還從未看過(guò)正式的需求文檔，這也是軟件業(yè)普遍存在的問(wèn)題，因?yàn)槿藗儾恢匾曀瑳](méi)人關(guān)心它是否合理，沒(méi)人關(guān)心它是否實(shí)用，有的甚至是在日后慢慢補(bǔ)進(jìn)去的。所以希望開(kāi)發(fā)公司一定要重視需求文檔，要對(duì)需求文檔有一個(gè)合理性的審查。

從軟件工程學(xué)來(lái)看

首先要從系統(tǒng)分析和編碼入手，提高系統(tǒng)的可靠性，保證代碼的質(zhì)量，增加系統(tǒng)的可擴(kuò)展性和可移植性，降低因需求變更而帶來(lái)的風(fēng)險(xiǎn)和維護(hù)代價(jià)。

從測(cè)試入手，一定要保證測(cè)試的質(zhì)量，并且及時(shí)作測(cè)試。

采用面向?qū)ο?OO)技術(shù)

面向?qū)ο蠓椒▽W(xué)的出發(fā)點(diǎn)和基本原則，是盡可能地模擬人類習(xí)慣的思維方式，使開(kāi)發(fā)軟件的方法與過(guò)程盡可能接近人類認(rèn)識(shí)世界解決問(wèn)題的方法與過(guò)程，也就是使描述問(wèn)題的問(wèn)題域與實(shí)現(xiàn)解法的求解域在結(jié)構(gòu)上盡可能一致。OO 的意義在于分析和設(shè)計(jì)軟件系統(tǒng)的思考方式，以及建立對(duì)象庫(kù)以后的軟件重用將給軟件系統(tǒng)的開(kāi)發(fā)帶來(lái)質(zhì)的改變，但是在建立OO 開(kāi)發(fā)體系之前的過(guò)程，一定會(huì)是一段荊棘遍布的路，需要付出加倍的努力以及達(dá)成思想的轉(zhuǎn)變。這里還有一個(gè)誤區(qū)需要澄清的是很多人以為用了C++，PB ，VB ，DELPHI 就是面向?qū)ο蟮拈_(kāi)發(fā)了，其實(shí)只是用了一些面向?qū)ο蟮墓ぞ?，骨子里仍然是結(jié)構(gòu)化的分析和設(shè)計(jì)方法，套上一層OOP 的外殼而已。

可見(jiàn)，在面對(duì)需求變更時(shí)，除了要對(duì)人員培訓(xùn)來(lái)提高開(kāi)發(fā)團(tuán)隊(duì)的整體素質(zhì)外，從系統(tǒng)分析和設(shè)計(jì)角度可以提高產(chǎn)品的可靠性，做到對(duì)需求變更的靈活應(yīng)對(duì)，這些至少可以在一定程度上降低產(chǎn)品的風(fēng)險(xiǎn)和維護(hù)代價(jià)，提高客戶的滿意度。

以上這些是我工作以來(lái)對(duì)軟件工程學(xué)以及實(shí)際工作中的一些認(rèn)識(shí)，并且參考了一些書籍和網(wǎng)絡(luò)文獻(xiàn)寫出來(lái)的，希望可以對(duì)大家在解決問(wèn)題中有一些實(shí)際的幫助。