分析技術和呈現格式
詞匯表
強有力溝通的一個重要內容是一致地使用術語和慣用語。每次談話都涉及對術語的共同理解。
工作流圖（也稱為流程圖、UNL活動圖和過程圖）
工作流程把一個或多個業務過程的細節可視化地呈現出來，以澄清理解或提出過程改進建議。
一種相對新穎的制作工作流圖的方法叫做業務過程建模表示法（Business Process Modeling Notation）。
另一類工作流圖是在過程改進六西格瑪中出現的。六西格瑪工作流圖被稱為SIPOC圖：供應商（Supplier）、輸入（Inputs）、過程（Process）、輸出（Outputs）和客戶（Customer）。用于表示體現整個業務交易的概要視圖。SIPOC圖中的過程可被分解成更詳細的SIPOC圖。六西格瑪技術被用于找出并度量當前的業務活動，并進行根本原因分析，找出過程效率不高的部分。
Lean方法使用一種稱為價值映射的方法來分析物資的流動和信息的流動，從而如何把產品或服務送到客戶那里。它包括供應鏈的標準符號，關注過程改進和減小浪費。
工作流圖也被用來表示實施和轉換需求。
在員工流程手冊、標準操作流程和上線計劃中，除了文字描述外再增加可視化的圖形表示，將有利于更好地溝通。
為什么使用工作流圖？
工作流圖非常靈活，可用不同標準和表示法來進行創建，所以在許多類型的項目中都是非常有用的。
業務改進項目非常依賴于于是和要是圖。軟件開發項目在業務需求層面（用戶做什么）或功能需求層面（用戶將怎么做）使用工作流圖。這項技術在諸如并購和收購等企業級項目中也非常有用。當合并兩個部門的時候，有必要分析兩個部門的當前流程是什么，并做比較，這樣才能描述共同活動并標志出差異。
項目團隊也可以利用指標找出最佳實踐，并建議合并后的未來流程（要是）。
此外，工作流圖對于開發面向服務架構的組織也非常關鍵。
實體關系圖
數據需求是用實體關系圖(ERD)表示的，這種圖及其附加的描述和細節共同組成了“數據模型”。這是業務領域或應用軟件系統信息需求的一種可視化表達。這項技術使用了實體、屬性和業務規則等核心需求組件，這項技術可幫助分析師涉及信息需求的提問。
為什么要構建邏輯數據模型
最重要的原因是要確認用戶和分析師對業務數據需求的理解，并確保軟件開發滿足業務需要。邏輯數據建模為分析師提供了一種做分析的結構化工具和技術。大多數領域專家可以把問題和可能的解決方案表達出來；但不幸的是，他們的問題和解決方案通常是基于目前系統的約束，而不是真正的業務需要。向業務人員詢問以細致了解每項數據（屬性）要求，理解并清晰地能表達業務的方方面面。這一過程使業務驅動系統設計。識別并細化出模型中的數據，就會進一步發現需求和問題，并且在軟件設計之前的階段就開始處理它們。
能幫助分析師從不同角度理解業務，幫助分析師發現重要的業務規則，并提取出能夠發現更多隱含業務規則的詳細問題。
當項目設計創建和修改數據庫的時候，負責創建和維護IT數據的人更傾向于用ERD作為溝通工具。ERD更易于理解，它在分析師和數據庫管理員之間建立溝通的共同語言。
邏輯數據模型還能促進數據復用和共享。
使用分解圖進行業務過程建模
分解圖在無需表現任何順序和關系的情況下展示了核心業務流程。
分解分析把復雜系統分解成可管理的小塊。因為這種圖本身就遵循組織架構圖的基本規則。被分解的原因在于，每個過程都可以被分解成為多個詳細描述它的過程，把它們看成獨立的任務將更有幫助。通過把各個組成部分獨立開來，你就能洞見復雜業務流程和系統的核心組成。把這些組成內容看成獨立的單元也有助于思考未來可以如何構造或者以不同方式實現這些過程。
確保在一張分解圖（使用不同的標簽）上只展示一種類型的組件。分解圖常被用于戰略規劃，把公司的高層戰略目標分解成低層的處室或部門目標。
用這種作圖技術，以項目啟動文檔和對業務的基本理解作為依據做分解圖，并給領域專家去修正。
分解圖的每個過程都要繼續用觸發器、追蹤器、相關業務規則和數據來描述。這些描述和圖一起被稱為“過程模型”或“業務模型”。
分解圖技術有些關鍵規則可以保證其一致性和嚴謹性。
分解圖的作圖規則：
- 在圖中只體現組件之間一種類型的關系：父子關系（用方塊之間的一條線來表示）
- 在一張圖中只顯示一種類型的需求（如果你正在分解過程，就不要顯示任何業務規劃；只顯示過程）
- 每個父節點都可以有多個子節點
- 不顯示順序（沒有箭頭）
- 一個子節點必須比它的父節點低一級（更詳細而細致地區分）
盡管有許多分解圖制作規則，但對同一組需求來說，任何兩位業務分析師都不可能做出同樣的圖來。每個分解圖都可以表達不同觀點并包含不同細節。
分解圖有助于組織和結構化分析工作，它使團隊以可視化方法在業務背景下觀察每個過程，使小組一次只關注一個特定過程，它可幫助設定詳細分析工作的邊界。
為什么要構建分解圖？
分解圖是業務領域的一種圖形化表示，它易于評審和修訂。分解圖可以是概要的也可以是詳細的。它可用來設計任何類型的解決方案：軟件、硬件、流程的或手工的。
用例圖
用例是軟件系統的一個目標。
用例圖展示了主要用例以及所涉及的角色。用例圖技術使用來展示功能需求的 - 軟件系統是如何與它的用戶（角色）交互的。它常用于表示系統的一個未來視圖。這種圖在顯示項目或軟件產品的范圍時非常有用。
用例圖是一種軟件設計的工具，但它也可用于業務需求（非技術）層面。用例可以獨立于技術命名和定義（商業論證）。用例圖也可以用來表示需求和分析工作的范圍。
用例描述
用例圖中的每個用例都是用例子來描述的。每個用例描述都是一個功能需求交付物，包含特定軟件功能的所有需求組件。用例描述還包括一系列順序的步驟描述軟件和角色應如何交互以實現業務目標。
在用例的步驟中，分析師通常會放一條主要路徑（開心路徑）和幾條備用路徑。備用路徑顯示了意外處理和錯誤條件。對每一步，分析師都描述角色將會采用的動作和系統的響應方式。這個描述包括詳細數據需求以及適用的業務規則。
用例方法的主要缺點是：一個用例描述可能涉及幾個需求組件（數據、過程、業務規則、外部實體），而不是分別描述它們。把組件寫在一起很容易遺漏需求，而且需求組件很難被復用。信息系統中的大多數數據元素會被一個以上的過程使用。當一個數據元素出現在一個用例中時，它必須在所有用到它的用例中被重復定義。這既浪費時間，又可能出錯。如果某個數據元素的特性發生改變，你必須在所有用到這個數據元素的用例中進行同樣的修改。如果漏掉一個，你的需求就會不一致，而且軟件開發就會出粗。
為什么使用用例圖
用例圖是UML（標準建模語言）的一部分。它是干系人評審的簡單圖，可以使業務干系人和技術干系人之間的溝通更加容易。
用例圖的價值不像其在設計過程的討論和決定那么重要。但可以與業務干系人，特別是決定者一起使用，因為它要求對人（角色）與系統合作方法作出決定。圖中角色和用例之間簡單的一根線可能會徹底改變業務人員的工作。它可能會使工作描述、職責發生變化，也可能會出現新的流程。
為什么要使用原型和仿真？
原型是一款出色的軟件開發分析工具，因為它讓業務干系人很容易能確定設計是否包括了所有必要的數據組件、標簽和描述是否有意義，還能針對屏幕上各條目的位置及其美觀方面給出特別建議。原型對于IT開發人員來說也是一種出色的需求呈現交互物，因為通過他們呢能夠看出到底構建了什么樣的系統。
事件建模
識別并分析事件是另外一個很有價值的需求角度。事件是指在業務領域外發生的二業務領域必須響應的事情。
用戶故事
用戶故事是一種相對較新的需求技術，源自用例技術。一個用戶故事是對軟件需要完成的某種事情的描述。敏捷軟件開發和極限編程經常采用用戶故事技術來快速獲取需求。故事經常是非正式地寫在索引卡上，在開發過程中也不去維護它們。它們不是用來獲取詳細需求的，只是提供對軟件的優先級和估算上的整體需求，更詳細的需求是由開發人員和用戶在構建軟件時討論的。
