一、需求的分類
需求分析是構建軟體系統的乙個重要過程。一般，把需求型別分成三個型別:
1、業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目的要求，它們在專案檢視與範圍文件中予以說明。
2、使用者需求(user requirement) 文件描述了使用者使用產品必須要完成的任務，這在使用例項文件或方案指令碼說明中予以說明。
3、功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。
業務需求和使用者需求是軟體需求分析的基礎，也是軟體構建的前提。系統分析員通過對業務需求和使用者需求的分解，將其轉換成克一形式化描述的軟體功能需求。開發軟體系統最為困難的部分，就是準確說明開發什麼。這就需要在開發的過程中不斷的與使用者進行交流與**,使系統更加詳盡,準確到位。這就需要確定使用者是否需要這樣的產品型別以及獲取每個使用者類的需求。
二、需求的質量分解
一般情況下，採用如下的手段描述軟體需求的質量：
正確性：所有需求必須是正確的、合理的、滿足任務書要求的。
必要性：所有需求必須是為完成指定任務所必需的。
可行性：在指定的環境和條件下，所有的需求必須是可行的。
完備性：為完成指定任務，這些需求是完備的、無遺漏的。
一致性：所有需求相互之間沒有矛盾，是一致的。
非退化：任一需求的引入都不會導致軟體效能的退化。
無歧義：任一需求的陳述都是確定的、不會導致多義性的。
可驗證：任一需求都是可以測試、可以驗證的。
可追蹤：人以需求都可以追蹤到專案的任務書或規格說明的需求。
三、需求的隱含質量要求
除了這些可以量化的質量標準，還有一些需求的標準是隱含的。這些要求即使客戶沒有提出來，在實現的時候也應該考慮到，否則，可能導致專案的失敗。
操作方便：每乙個客戶都會有操作方面的要求，只是具體的表現方式不一樣。一般，客戶在開始的時候對操作很難對操作有很具體的考慮，他會想當然個認為新的軟體系統會和他以前所熟悉的某乙個系統類似。而事實並非如此。當他發現新的軟體系統不方便使用的時候，就會提出修改的建議。有的時候，這種修改對軟體系統的影響是災難性的。
可以保證操作質量：一般，系統分析員會認為客戶應該勾畫出系統執行過程中可能發現的重要風險，然後在系統實現的時候予以考慮。然而，在溝通的過程中，客戶認為的重要的風險會和系統分析員所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因為對於客戶而言，這些內容應該是顯而易見的；而系統分析員一般並不了解這些事實。例如，在乙個管理保險公司客戶的系統裡面，修改職業是需要嚴格審核的，如果系統分析員以前接觸的業務以電子商務居多，他可能自然而然的認為客戶修改職業僅僅是乙個一般性的變更。
四、客戶對需求的影響
目前很多系統分析員在進行需求分析的時候，把主要精力放在了解客戶的業務流程，並試圖將其用形式化的手段描述。而事實上，這樣了解到的客戶需求往往是不完整的，甚至具有很大的片面性。除了隱含需求的定義比較困難以外，客戶本身也是影響需求質量的乙個重要因素。
1、客戶有不同的需要。一些客戶知道他們需要什麼，而另外一些人知道他們不需要什麼。一些客戶希望進行詳細討論，而另外一些客戶則滿足於模糊的承諾。
2、客戶有不同的個性。
3、客戶和**商之間有著不同的通訊方式。一些人非常熟悉產品以及生產廠商，而另外一些人則可能素未謀面，僅僅通過信件往來和幾個匆忙的**與生產廠商溝通。
4、客戶也經常是矛盾的。事實上，很少有客戶能夠明確的知道怎樣的乙個系統對自己是最有益處的，他們往往在集中方案之間徘徊，於是經常產生需求的變動。生產廠商經常陷入客戶自己的矛盾之中。
客戶的負面影響可能對於能夠在預算內按時完成專案產生很大的影響。儘管客戶需要對需求的質量負責任，但是，當乙個軟體專案因為客戶事先沒有預料到的情況而導致失敗的時候，即使客戶不會追究開發方的責任，就軟體專案本身而言，也已經是失敗的。
五、目前控制需求質量的手段
目前，專案經理和系統分析員主要通過聽證、評審、確認等手段控制軟體需求的質量。
聽證：主要是指通過正式或者非正式的渠道召開有關人員的會議，聽求大家對新的軟體系統的要求和意見。
評審：組織有關的專家對軟體需求進行評價，指出目前的需求由那些不合理的地方，以及修改的意見等。評審一般發生在初步的軟體需求已經形成以後。
確認：開發方將整理過的需求分析說明書交給客戶確認。如果客戶認可該需求分析說明書，就形成正式的需求分析文件，並作為乙個重要基線管理。
這些需求控制手段可以提高軟體需求的質量，但是仍然無法保證需求是可用的。因為：
1、聽證會的參與者並不一定代表使用者的真實意圖。實踐中經常遇到這樣的情況。即使他是目標軟體的最主要使用者，他也經常會遺忘一些他覺得是很基本的，而事實上對於軟體系統是很重要的細節。
2、參與評審的專家並不一定對軟體的最終質量負責，因此，他可能把工作的重點放在發現需求中的問題，而不是確認需求是否可行。
3、客戶確認只代表客戶對需求負責人，不代表客戶承認需求的質量。如果因為需求的質量導致軟將專案無法進展，客戶只能承擔經濟上的責任，而專案小組並不能因此緩解軟體專案陷入的尷尬。
六、用逆向溝通改善需求的質量
逆向溝通，就是在需求調研的過程中，除了了解客戶的情況，同時，向客戶提出一些建議，供客戶參考。
一般認為，客戶在其所在的領域具有比較資深的經歷，因此需要嚴格遵守客戶的意見。事實上，客戶雖然在其所在的領域內很資深，但是，他們的角度是單純的業務流程，而不是從實現資訊科技角度構件的業務流程。因此，系統分析員要充分的說明對於實現乙個業務系統而言，現有的業務流程應該做如何的剪裁，以及需要注意哪些要點。
雖然，逆向溝通不能完全保證需求的質量，有效的逆向溝通可以大大減少因為對業務流程的理解不一致而造成的需求質量的下降。
七、逆向溝通的主要要點
1、所提出的業務需求是否符合行業的規範。
不同的行業對於業務流程有一定的規範，例如財務，審計，工程設計，都具有一定的行業規範，這些規範一方面是對行業行為的一種約束，同時，也是行業內經驗的歸納和總結。例如，審計準則不但約束了審計過程中的不規範行為，同時也保護了註冊會計師的利益。部分企業由於所處的狀況的不同，沒有完全遵守行業規範，這造成了需求變更的隱患。系統分析員在**業務流程的過程中，應該留一客戶的業務流程是否符合行業規範，如果有不符合的地方，應該進行適當的引導。即使客戶目前實施行業規範有難度，也應該注意其理由，以**其業務流程變更的可能性。
2、展望系統發展環境，留有適當的擴充套件介面。
每個行業的發展趨勢應該有一定的規律可遵循。企業本身的發展變化是引起需求變更的最主要因素，因此，提前**行業的發展趨勢對於軟體預留一定的發展介面是很重要的。
客戶沒有預料到行業的變化趨勢，一方面，可能參與軟體需求的客戶代表並不是關注行業和企業發展趨勢的人員；另一方面，客戶關注需求的程度可能和系統實現人員不同，有些客戶會很自然接受的變化，會對系統有很重大的影響，相反，一些客戶認為很重大的變化，可能對系統的影響是很小的。
3、探索適合於資訊化的工作流程。
客戶有的時候會提出對資訊系統的要求，但是，客戶所提到的要求，是在他的理解中，資訊系統應該具有的樣子。系統分析員應該深入挖掘這些要求背後的隱含目標，以便設計最適合客戶，也最有利於實現的系統框架。例如，為了控制員工的工作時間，客戶可能要求在軟體限時使用。可是，能夠實現控制員工工作時間的手段有很多，而且，客戶提到的並不一定是最適合、最有效的方式。
4、合理使用批處理方式。
對於一些規模不大的系統，集中處理（批處理）的方式是合適的。可是，如果系統的規模很大，涉及的交易很多，而且對交易的實時性要求很高，集中的批量處理不是乙個很好的方法。是否使用批處理方式，要根據業務需求的型別，系統的容量，以及以後的發展趨勢決定。
5、留有操作痕跡
乙個資料的產生，應該有一定的來由，不應該有沒有根源的資料。
保留操作痕跡可能造成資料空間的急劇增加，但是，對於一些重要的資料，必須做到操作可以追溯。追溯的內容根據操作的重要程度有所不同，一般可能包括以下內容：操作人員，操作時間，操作以前的狀況，操作以後的狀況，操作所通過的模組，操作的機器資訊。
6、操作可以恢復
對於錯誤的操作，可以恢復到操作以前的狀況。恢復過程作為乙個重要的操作，應該留有痕跡。也就是說，業務資料恢復到了操作以前的狀況，但是系統必須紀錄前一次操作和本次逆向操作的有關資訊，以備核查。同時，逆操作應該比操作本身具有更高的授權級別和操作限制。
7、重要流程有校驗的功能
所謂重要流程，指對下一步操作有重要影響的流程，或者無法回溯的流程。例如，傳送客戶對賬單，對賬單發到客戶手裡以前還可以重新列印已修復一些錯誤，但是，如果已經發給客戶，即使可以修復，也會產生一定的不良影響。因此，在這些流程上應該進行比較細緻的校驗。校驗可以採用自動校驗，前提是有比較可靠的校驗演算法，否則，通過有經驗的操作員進行校驗是比較有效的方式。另外，一旦發現校驗失敗的案例，必須把這些案例作為重要的時間進行核查，以找到原因，糾正以前的校驗演算法。
八、逆向溝通的實現條件
1、熟悉業務流程的業務邏輯分析師
系統分析員熟悉業務流程是實現逆向溝通的前提。在進入乙個新的領域以前，系統分析員必須花費大量的經歷，了解這個行業的狀況，行業的發展趨勢，行業內企業的運作模式，行業的目標企業在這個行業所處的地位等資訊。這些資訊會為以後分析客戶的需求，了解需求的質量，分析需求的合理性打下很好的基礎。
2、工作由被動轉變為主動
如果認為提出乙個完整的需求是客戶的責任，那麼一切逆向溝通都會被認為是沒有必要的。如前所述，雖然客戶對需求的質量負有最終的責任，但是，系統分析員的積極溝通，將會提高需求的質量，減少專案擱淺的可能性。另外，有很多責任是無法具體定位為客戶的責任還是專案組的責任。因此，採用積極的手段，確保專案的成功是系統分析員應該採用的態度。
綜述
良好的需求分析是軟體成功的基礎。以上是作者對需求分析工作實踐的一次小結以及綜合性的思考，是對需求分析本身所做的一次分析。在此基礎上，作者提出了逆向溝通的設想，即系統分析員主動進行溝通，提出指導性意見。當軟體融合了客戶和系統分析員雙方智慧型，其質量將會進一步得以提高。
需求分析過程中和使用者溝通的幾個心得
在幾年的專案工作中，積累了一點和使用者溝通的經驗。如果你做的專案業務是你熟悉的，那還好，如果是你不熟悉的，一定要花點精力學習一下這個行業業務的背景資料。畢竟，客戶是不可能給你系統地介紹業務的。只有你通曉了行業業務，才能和使用者交流，並正確而有效地引導客戶，做好需求分析，你不能指望客戶能明確地說出需求...
ERP實施過程中的溝通管理研究
關於溝通管理，內容很多，也聽了大師級老師的培訓，自己略微總結一下，並結合 erp專案實施的具體特點來談談如何與客戶做溝通。這裡先講講溝通的基本概念，後期在深入體會 erp實施過程中如何與客戶進行溝通，希望更多的朋友參與討論。一 為什麼需要溝通？溝通的目的是什麼？一般來關於溝通管理，內容很多，也聽了大...
Oracle Mysql儲存過程中獲取客戶端IP
oracle mysql儲存過程中獲取客戶端ip 由於工作原因，我們往往需要在資料庫中獲取客戶端ip，對於oracle資料庫非常方便。sys context userenv ip address select v random,t.host into v random2,v host from in...