我太難了，自認為對需求已經非常清楚了，但交付軟體時使用者卻說：這不是他想要的！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

□第二層（中層）-資料邏輯推理（確定資料間引用關係）

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

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

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

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

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

通過邏輯推演的方法搞清楚了使用者需求，雖然還不能表明你具有優化需求和提升使用者價值的能力（要想做到優化和提升，還必須掌握相當深度的使用者業務知識），但至少為理解、優化和提升打下了基