需求分析師經常抱怨說：我太難了，自認為對需求已經非常清楚了，但交付軟件時用戶卻說：這不是他想要的！

軟件行業從事需求分析師的人經常會提到下面的一些有代表性的現象

■現象1.認真聽取了用戶需求、并且用界面原型向用戶進行了需求確認，費盡了千辛萬苦把軟件開發出來后，用戶一試卻說“這不是我想要的東西！”，這樣的結果讓我感到崩潰，不是確認好的嗎？！這說明編碼之前需求工程師與用戶雙方對用原型表達的需求認知是一致的（如不一致是不會開始編碼的），相信很多需求分析師都經歷過，這個問題一旦發生了就會帶來開發返工、成本超支、延遲罰款，甚至最后雙方不歡而散。

■現象2.開發工程師總是抱怨說需求分析師的資料看不懂、表達不清晰，有時為了搞清楚一個問題（在一張A4紙上用文字說明）可能需要打3～4天的電話溝通。久而久之就造成了產品經理、開發工程師對需求分析師的不信任，形成了需求分析師水平低的印象。

■現象3.對完成的分析與設計結果正確與否判斷不清楚（或沒有判斷方法）。老手的需求分析師可以通過積累的專業知識和經驗來做出判斷，但是對新手的需求分析師來說因為沒有積累可以利用，常常面對完成的分析與設計結果不知道用什么方法來判斷它的正確與否，交給開發之后總是提心吊膽怕什么地方出錯誤。

這種現象在其他行業則很少會出現，比如IT行業經常會用建筑與軟件的設計制造過程做比較，但由于建筑物是具象的，看到設計圖形馬上能聯系起你所有的經驗記憶，在大腦中建立起一個具體的形象。描繪建筑物是用幾何圖形、位置關系和物理尺寸來表達的，比如：用與實際相似的圖形來表達建筑物的外觀，還可以將建筑物分解為窗、門、柱、梁、板等構件，同樣用完全相似的圖形來表達，建筑物從里到外都可以精確地給出構件之間的銜接關系，看了建筑設計圖之后，投資業主、建筑設計師和施工公司三方都不會對圖形有認知上的歧義。

那么軟件行業為什么會出現前述的現象呢？主要是因為軟件產品的需求和交付物都比較“抽象”，很難用“具象”的圖形表達出來，對同一個軟件需求不同的人有不同的理解和表達，沒有絕對公知的、唯一的和定量的表達方式，這個難題對提需求的用戶、分析需求和開發的軟件工程師來說都是一樣的，這就容易造成交流時出現理解和認知上的誤差。

有的需求分析師說：與用戶交流前我畫了高保真的界面原型，用原型法向用戶確認需求并獲得了用戶的認可，為什么還會出現不盡人意的結果呢？原因在于：利用原型法雖然可以直觀地說明與確認界面上數據輸入方面的需求，但是對不同原型之間的關系、輸入后數據之間的關系、業務整體的運行機理、未來需求發生變化時系統的應對方法等，用原型法是難以獲得這些復雜邏輯關系和重要信息的，原型法主要幫助獲得功能操作層面的邏輯和信息。

抽象的對象是人為的認識，用文字、界面表達的內容與現實的對象有聯系，但是并不能夠做到“形似”，（因為研究的對象沒有“形”），它是一種用文字、或是邏輯圖標（符號）表達的“抽象”形象。在軟件中除去操作界面（interface）的表達具有一定的“形象”以外，支持這個界面運行的所有內容都是抽象的， 比如采購流程、組織分解、管理控制、合同簽訂、核算支付等，它們的事理、邏輯非常不同。

軟件需求工作中重要的成果之一就是分析和表達“邏輯”，除了用文字和界面原型的方法外，表達邏輯的最重要的方式是繪制邏輯圖，邏輯圖是由圖標、連接線、位置、包含關系等組成的（對比建筑物的表達用圖標、形狀、位置、尺寸等）。界面原型表達的是“數據的輸入和處理結果的展示”，邏輯圖形表達的是“業務事理、邏輯”，是表面看不到的信息，而這些信息正是用來抽提業務規律、建立數據模型的依據。

因此，在需求調研完成時除去要搞清楚功能（界面原型）和數據以外，還必須要搞清楚“邏輯”。除界面原型和文字兩種形式外，表達邏輯的圖形有：業務的分層圖、框架圖、分解圖、流程圖、數據勾稽圖等。用圖形表達的邏輯來源于“架構設計”，缺乏邏輯表達的資料往往缺乏的就是架構設計環節，沒有架構設計環節的系統基本上就是需求分析師看到什么做到什么，看一步做一步。缺乏邏輯表達的是造成前述現象的重要原因之一。下面簡單說明一下邏輯與前述現象之間的因果關系。

□現象1：界面原型與邏輯

用戶可以理解原型界面上的內容，但是他不清楚原型背后的邏輯（如流程、流轉條件、發生變化時的應對方法等），這是因為需求工程師用界面原型僅確認了用戶做事的“表單（需要哪些字段）”，但沒有做業務流程、各功能間協同關系等深層次的邏輯確認，所以當系統運行中處理各種各樣的真實場景時，用戶就感到不是他預想的樣子了（通常用戶會認為界面原型對了，原型背后的邏輯就一定是他想要的樣子）。

□現象2：開發工程師與邏輯

軟件開發工程師非常關注邏輯表達（因為編程是基于邏輯進行的），需求分析資料必須要表達出做事的步驟順序、每個步驟上的內容、內容要描述到精細的規則。由于需求分析師不注重從“邏輯”的角度進行分析與表達，且完成資料中的大部分內容采用文章體的描述方式，由于文字表達的局限性（不規范、因人而異等），就造成了產品經理、開發工程師的閱讀和理解的困難（特別是復雜邏輯），覺得資料中的功能描述都是獨立的、缺乏邏輯關系的描述，整個系統到處是斷點、經不起推敲。

□現象3：結果是否正確與邏輯推演

從事需求分析工作時間短、或是遇到了首次接觸的用戶業務時，如果新手需求分析師能夠采用“邏輯推演”的方式進行調研和分析，則可以很大程度上彌補因對用戶業務知識不足而帶來的判斷不準問題。邏輯推演方式分為三層（業務邏輯層、數據邏輯層和管控邏輯層）來檢查分析與設計結果是否正確，其原理就是采用“順藤摸瓜”的方法搞清楚研究對象，在三個不同層面上進行邏輯推演的方式簡述如下：

□第一層（底層）-業務邏輯推理（確保業務事理正確）。

第一層主要用業務架構圖的形式表達。給出業務構成的要素、要素間的關系，這一步給出了業務要素之間外在的“定性關系”，勾勒出業務的“形象”，使得所研究的業務對象可視、有形，它是后續分析、設計、開發的基礎。業務關系明白了，粗線條的邏輯關系就清楚了。

□第二層（中層）-數據邏輯推理（確定數據間引用關系）

第二層主要用數據關系圖的形式表達，在第一層的基礎上給出業務要素內在的“定量關系”，第一層說明了要素之間的外在關系是定性的，第二層通過對數據之間的邏輯關系分析，給出要素之間精確的、唯一的關系表達。數據關系明白了，詳細的邏輯關系就清楚了。

□第三層（上層）-管控邏輯推理（確定約束條件合理）

有了前面對業務要素的從“業務層、數據層”的“定性、定量”分析和描述，下面就可以在此基礎之上給出要素之間的管控關系，管控關系說明了要素之間的相互作用以及因此產生的約束關系，約束關系在企業管理系統的中的作用就是“管理”。

完成符合三層邏輯的設計后，最后再采用業務用例驗證和應用用例驗證的方式對設計結果進行檢查和驗證（即利用場景進行動態推演）。這種方式大大地提升了需求分析師與用戶、開發工程師的溝通效率，基本上確保了分析與設計結果與完成后系統的相似度，同時也基本上消除了系統開發完成后發生大規模返工或推倒重來的風險。

從前述的三種現象以及造成現象的原因可以看出來，研發一款非具象的軟件產品，邏輯思維、分析和表達是非常重要的基礎能力，需求分析師是將用戶的抽象需求、通過分析和設計，轉換為可視、可操作產品的第一人。某種意義上可以說，需求分析師的邏輯思維、分析和表達水平，決定了最終產品水平的高低，特別是對于復雜系統來說更是如此。

通過邏輯推演的方法搞清楚了用戶需求，雖然還不能表明你具有優化需求和提升用戶價值的能力（要想做到優化和提升，還必須掌握相當深度的用戶業務知識），但至少為理解、優化和提升打下了基礎。詳細內容可參考《大話軟件工程—需求分析與軟件設計》一書。

?

總結

以上是生活随笔為你收集整理的需求分析师的基本功：逻辑思维、逻辑分析与逻辑表达的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。