，他會想當然個認為新的軟件系統(tǒng)會和他以前所熟悉的某一個系統(tǒng)類似。而事實并非如此。當他發(fā)現(xiàn)新的軟件系統(tǒng)不方便使用的時候，就會提出修改的建議。有的時候，這種修改對軟件系統(tǒng)的影響是災(zāi)難性的。
可以保證操作質(zhì)量：一般，系統(tǒng)分析員會認為客戶應(yīng)該勾畫出系統(tǒng)運行過程中可能發(fā)現(xiàn)的重要風(fēng)險，然后在系統(tǒng)實現(xiàn)的時候予以考慮。然而，在溝通的過程中，客戶認為的重要的風(fēng)險會和系統(tǒng)分析員所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因為對于客戶而言，這些內(nèi)容應(yīng)該是顯而易見的；而系統(tǒng)分析員一把并不了解這些事實。例如，在一個管理保險公司客戶的系統(tǒng)里面，修改職業(yè)是需要嚴格審核的，如果系統(tǒng)分析員以前接觸的業(yè)務(wù)以電子商務(wù)居多，他可能自然而然的認為客戶修改職業(yè)僅僅是一個一般性的變更。
五、目前控制需求質(zhì)量的手段
目前，項目經(jīng)理和系統(tǒng)分析員主要通過聽證、評審、確認等手段控制軟件需求的質(zhì)量。
聽證：主要是指通過正式或者非正式的渠道召開有關(guān)人員的會議，聽求大家對新的軟件系統(tǒng)的要求和意見。
評審：組織有關(guān)的專家對軟件需求進行評價，指出目前的需求由那些不合理的地方，以及修改的意見等。評審一般發(fā)生在初步的軟件需求已經(jīng)形成以后。
確認：開發(fā)方將整理過的需求分析說明書交給客戶確認。如果客戶認可該需求分析說明書，就形成正式的需求分析文檔，并作為一個重要基線管理。
這些需求控制手段可以提高軟件需求的質(zhì)量，但是仍然無法保證需求是可用的。因為：
1、聽證會的參與者并不一定代表使用者的真實意圖。實踐中經(jīng)常遇到這樣的情況。即使他是目標軟件的最主要使用者，他也經(jīng)常會遺忘一些他覺得是很基本的，而事實上對于軟件系統(tǒng)是很重要的細節(jié)。
2、參與評審的專家并不一定對軟件的最終質(zhì)量負責(zé)，因此，他可能把工作的重點放在發(fā)現(xiàn)需求中的問題，而不是確認需求是否可行。
3、客戶確認只代表客戶對需求負責(zé)人，不代表客戶承認需求的質(zhì)量。如果因為需求的質(zhì)量導(dǎo)致軟將項目無法進展，客戶只能承擔經(jīng)濟上的責(zé)任，而項目小組并不能因此緩解軟件項目陷入的尷尬。
六、用逆向溝通改善需求的質(zhì)量
逆向溝通，就是在需求調(diào)研的過程中，除了了解客戶的情況，同時，向客戶提出一些建議，供客戶參考。
一般認為，客戶在其所在的領(lǐng)域具有比較資深的經(jīng)歷，因此需要嚴格遵守客戶的意見。事實上，客戶雖然在其所在的領(lǐng)域內(nèi)很資深，但是，他們的角度是單純的業(yè)務(wù)流程，而不是從實現(xiàn)信息技術(shù)角度構(gòu)件的業(yè)務(wù)流程。因此，系統(tǒng)分析員要充分的說明對于實現(xiàn)一個業(yè)務(wù)系統(tǒng)而言，現(xiàn)有的業(yè)務(wù)流程應(yīng)該做如何的剪裁，以及需要注意哪些要點。
雖然，逆向溝通不能完全保證需求的質(zhì)量，有效的逆向溝通可以大大減少因為對業(yè)務(wù)流程的理解不一致而造成的需求質(zhì)量的下降。
七、逆向溝通的主要要點
1、所提出的業(yè)務(wù)需求是否符合行業(yè)的規(guī)范。
不同的行業(yè)對于業(yè)務(wù)流程有一定的規(guī)范，例如財務(wù)，審計，工程設(shè)計，都具有一定的行業(yè)規(guī)范，這些規(guī)范一方面是對行業(yè)行為的一種約束，同時，也是行業(yè)內(nèi)經(jīng)驗的歸納和總結(jié)。例如，審計準則不但約束了審計過程中的不規(guī)范行為，同時也保護了注冊會計師的利益。部分企業(yè)由于所處的狀況的不同，沒有完全遵守行業(yè)規(guī)范，這造成了需求變更的隱患。系統(tǒng)分析員在探討業(yè)務(wù)流程的過程中，應(yīng)該留一客戶的業(yè)務(wù)流程是否符合行業(yè)規(guī)范，如果有不符合的地方，應(yīng)該進行適當?shù)囊龑?dǎo)。即使客戶目前實施行業(yè)規(guī)范有難度，也應(yīng)該注意其理由，以預(yù)測其業(yè)務(wù)流程變更的可能性。
2、展望系統(tǒng)發(fā)展環(huán)