需求是開發者和用戶交互的一個過程，任何一方的不投入都會導致項目的失敗。由於售前諮詢的定位，必然存在著客戶溝通和客戶合作態度的問題（再者用戶不是專業人士），因而開發者需要以積極的態度告訴客戶需求開發的方法，以獲取客戶的支持。
軟件需求層次
軟件需求包括三個不同的層次——業務需求、用戶需求和功能需求，也包括非功能需求。業務需求反映了組織機構或客戶對系統、產品高層次的目標要求，在項目視圖與範圍文檔中予以說明。用戶需求描述用戶使用產品必須要完成的任務，可使用用例文檔或場景腳本予以說明。功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性是指邏輯上相關的功能需求的集合，給用戶提供處理能力並滿足業務需求。
無論哪個層次的需求，其目的都是為了說明系統要完成的內容，可採用不同的模型進行分析和展現：
• 業務需求，通過業務建模（即採用業務架構理解客戶業務），對企業目前的業務流程進行描述和評估
• 用戶需求，重心就是如何收集用戶的需求上，即確定角色和角色的用例，通過用例和場景說明客戶的工作內容和信息化需求
• 功能需求，依賴於用戶需求，是用戶需求在系統上的一個映射（Mapping）。在這個層次上，為用戶做一個軟件原型是一個不錯的方法
UML與相關模型
UML是一種圖形化的面向對象建模語言，通過不同的圖形表示來捕捉系統靜態結構和動態行為的信息，建立起對象模型。
考慮到售前諮詢過程更多的是理解和闡述客戶需求，因而可以將注意力聚焦在用例和活動圖上，即通過層次化的用例（Use Case）模型和時序模型描述企業範圍內各種應用的功能需求；通過逐級分解的活動模型（業務過程、子過程、活動）來細化描述業務。當然也可適當考慮類模型的分析，藉此說明企業相關的實體和關係。
UML概述
UML的概念包括了UML語義（Semantics）和UML表示符（Notation）兩個部分，UML語義定義了三種模型（類模型、狀態模型和交互模型），UML表示符提供了完整的語義定義，UML的表示符包括了下面的幾種主要的圖：類圖、用例圖、順序圖、協作圖、狀態圖、活動圖和部署圖。
三種模型從不同的視角來描述系統：
• 類模型。描述了系統內部對象及其關係的靜態結構——它們的標識、與此同時其他對象的關係、屬性以及操作。類模型提供了放置狀態模型和交互模型的基本框架。類模型中最重要的概念是類、關聯和泛化。
• 狀態模型。描述的是對象當中與時間相關的內容，如表明變化的事件，以及那些界定了事件上下文的狀態。狀態模型是由多張狀態圖所構成的，一個類有一張狀態圖，每張狀態圖都包含了一些重要的時序行為。
• 交互模型。描述的是對象如何協作以達成某種結果。交互模型是跨越了許多對象的整體視圖。交互可以在不同的抽象層次上建模。在高層上，用例描述的是系統如何與外部參與者交互（用例表示功能片段，有助於捕獲非形式化的需求）；順序圖提供更多的細節，顯示交互的對象，以及對象交互的時間順序；活動圖提供最詳盡的細節，以顯示某次活動中處理步驟之間的控制流。
用例模型
用例是從用戶的角度看待系統，用例標識系統的功能，並根據用戶的觀點組織這些功能。用例模型包括參與者、用例和用例圖三部分構成：
• 參與者（Actor）。系統的直接外部用戶——直接與系統通信的一個對象或一級對象，但並不是系統的一部分。
• 用例。用例是系統通過與參與者的交互可以提供的一段連貫的功能，每個用例會涉及一個或多個參與者以及系統本身。用例把與此一部分系統功能相關的所有行為組合在一起，包括普通主線行為、普通行為的變體、異常條件、錯誤條件和請求取消。
• 用例圖。UML用一套圖形表示法來總結用例，如下圖。其中矩形包含了系統的用例，參與者列在矩形外面。系統的名稱可以寫在矩形的某條邊的附近。橢圓內部的名稱表示用例。"火柴人"圖標表示參與者，參與者的名稱列在圖標下方或者臨近圖標的地方。實線連接用例及其參與者。
順序模型
順序模型詳細描述用例的主題。有兩種順序模型：場景和順序圖，順序圖具有更加結構化的形式。
場景。是指系統在某個特定的執行期內所發生的一系列事件，如用例。場景的範圍可以變化——它可以包括系統中的所有事件，或者只包括與某些對象有密切聯繫或由這些對象產生的那些事件。場景可以是執行一個實際系統的歷史記錄，或者是執行擬採用系統的預想實踐。
順序圖。文本格式便於編寫，但無法清晰地顯示每條消息的發送者和接收者，順序圖顯示了交互的參與者之間的消息順序。
每個用例需要一張或多張順序圖來描述其行為。每張順序圖顯示用例的一個特定的行為序列，同時用例內部的每種異常條件也需要繪製順序圖。在多數系統中，會有無限多的場景，因此全部顯示是不可能的，但是應該試著詳細描述所有的用例，並用順序圖來覆寫基本的行為種類。
活動模型
活動圖顯示了組成複雜過程的步驟序列，例如算法和工作流。與順序圖類似，活動圖可以顯示控制流，但專注於操作而不是對象。
活動圖很像傳統的流程圖，一步一步地顯示流程控制。
在活動圖中，拉長了的橢圓表示活動，箭頭表示活動的順序，菱形表示決策點，粗線條表示併發線程的分流和合並，帶輸出箭頭的實心圓表示活動圖的起點，靶心（空心圓圍繞著實心圓）表示終止點。
類模型
類描述了擁有相同特性（屬性）、行為（操作）、關係種別以及語義的一組對象，類中的對象有著相同的屬性和行為模式。
類圖提供了地類及其關係進行建模的一種圖形化的表示法。
類的UML表示法是一個方框，方框裡面是類名（用黑體字表示，一般用單數名詞表示）。
值和屬性。屬性是類的一個命名特性，它描述了類的每個對象都擁有一個值，值就是一段數據。UML表示法會在類方框的第二格里列舉屬性，而第二格里也可能會包含屬性，其表示法是列出每個屬性名，之後跟著等號和取值。
操作和方法。操作是一個函數或過程，可以應用於類的對象，或被對象使用。方法是類中操作的實現。UML表示法在類的第三格里列舉操作。
可以通過鏈接、關聯、泛化和繼承來建立對象與類之間的關係。由於類與類之間的關係內容比較得雜，且不是售前諮詢關注的重點，本文就不細述。
用UML進行需求分析
採用UML進行需求分析，我們通過確定系統的整體邊界來進行需求建模，然後識別用例，用場景和順序圖來充實用例：
確定系統邊界
首先，必須要了解系統的準確範圍，也即系統邊界，以便把功能確定下來。這意味著必須要確定系統包括哪些功能（或者涵蓋的業務範圍），更重要的是，要確定系統應該忽略哪些內容。
在確定系統邊界階段，可以把系統看作是一個可以和外界交互的黑盒（內部系統被隱藏了），我們要確定的是系統的意圖以及系統呈現給參與者的視圖。
通過不應該把人看成是系統的一部分——人是必須與系統交互的參與者，但他們的活動不受系統控制。
尋找參與者
一旦將系統邊界確定下來之後，就要確定與系統直接交互的外部對象，這些都是系統的參與者。參與者可以是人、外部設備和其他軟件系統。
在尋找參與者的過程，要找的不是個體，而是行為原型。每個參與者都代表一個理想化的會執行一部分系統功能的用戶，外部對象可能會有多個參與者。
尋找用例
對於每個參與者，列舉參與者使用系統的不同方式，每一種方式都是一個用例。用例將系統功能劃分成少數離散單元，所有的系統行為都必須處在某種用例之下。
每個用例都應該表示系統所提供的一類服務，即給參與者提供價值的內容。在用例中，要努力使所有的用例都保持相似的層次細節。此時可繪製初步的用例圖，顯示參與此同時者和用例，並將參與者連接到用例上。
尋找初始和終止事件
用例將系統功能拆分成離散單元，並顯示了每一個單元所涉及到的參與者，但它們並沒有清晰地顯示行為。要理解行為，就必須理解覆寫每一個用例的執行順序，我們可以從尋找發起每個用例的事件開始，確定哪個參與者發起了用例，並且定義它發送給系統的事件。在許多情況下，初始事件是對用例所提供服務的一種請求。
同時，還應該確定一個或多個終止事件以及每個用例中究竟要包含多少個終止事件。
準備普通場景
對於每一個用例，準備出一種或多種典型的對話，以獲得對系統期望行為的感覺。這些場景描述了主要的交互、外部顯示格式以及信息互換等（場景是在一組交互對象之間發生的一系列事件）。
對於大多數問題來說，邏輯上的正確性要取決於交互序列，而不是交互的確切時間。
增加變化和異常場景
整理"普通"情形的場景，也即沒有任何異常輸入或者錯誤的交互。因而在準備好典型場景之後，就要考慮特例了，此外還要考慮錯誤情形（包括無效值和沒有響應）。
尋找外部事件
檢查場景，尋找所有的外部事件，包括所有的輸入、決策、中斷以及用戶或外部設備之間的往來交互，外部事件可以觸發目標對象動作。
把信息傳輸給對象是一種事件，許多事件都有參數。
應該把對控制流有著相同效果的事件都組織在同一個名稱下面，即使它們的參數值不同的時候也要這麼作。事件之間的差異取決於應用。
為每一種場景都準備一張順序圖，順序圖要清晰地顯示每次事件的發送者和接收者。如果同一個類的多個對象都參與了場景，那就要給每一個對象分配一列，通過檢視圖中的某一列，就可以觀察到會直接影響某個對象的事件，這樣從順序圖就可以總結出每個類接收和發送的事件。
編制複雜用例的活動圖
順序圖捕獲參與者之間的會話與相互作用，但並沒有清晰地給出分支和決策，而活動圖通過歸檔控制流中的分叉和匯合，對業務邏輯進行分析。
組織參與者和用例
下一步是用關係（包括、擴展和泛化）來組織用例了。
組織原型界面
用戶界面是以一致的方式給系統用戶提供訪問其領域對象、命令和應用選項的一個或一組對象。在售前諮詢階段，原型界面的展現和功能描述是關鍵環節。
在售前諮詢階段，界面要求通常是模糊的、不明確的，多數用戶往往並不能提出明確的、全局的界面需求。因而組織原型界面，要先草擬出一種示例界面，將應用程序的操作可視化表示，並看看有什麼重要內容被遺漏。
原型界面的組織步驟可為：確定所涉及的界面元素，分析用戶特徵並定義用戶角色，依據用戶角色的界面需求設計界面原型並不斷改進完善。
通常一個軟件界面的元素包括界面主顏色、字體顏色、字體大小、界面佈局、界面交互方式、界面功能分佈、界面輸入輸出模式。其中：
對用戶工作效率有顯著影響的元素包括：輸入輸出方式、交互方式、功能分佈，在使用命令式交互方式的系統中，命令名稱、參數也是界面元素的內容，如何設計命令及參數也很重要。
影響用戶對系統友好性評價的元素則有：顏色、字體大小、界面佈局等，這種劃分不是絕對的，軟件界面作為一個整體，其中任何一個元素不符合用戶習慣、不滿足用戶要求都將降低用戶對軟件系統的認可度，因而在做原型界面時要儘量地考慮友好性。
