軟件系統的目的是爲了解決問題，因此在建模之初最重要的步驟是對問題的分析與定義，並在此基礎上歸結模型，這樣才能夠獲得切實有效的模型。定義問題的過程包括：理解真實世界中的問題和用戶的需要，並提出滿足這些需要的解決方案的過程。
1 問題分析
問題分析的目標就是在開發之前對要解決的問題有一個更透徹的理解。爲了達到這一目標，通常需要經過在問題定義上達成共識，理解問題的本質，確定項目干係人和用戶，定義系統的邊界和確定系統實現的約束這五個步驟。
1.1 在問題定義上達成共識
要檢驗大家是否在問題的定義上達成了共識，最簡單的方法就是把問題寫出來，看看是否能夠獲得大家的認可。而要使得這個過程更加有效，應該將問題用標準化的格式寫出來，根據 UP 的建議，應該包括以下幾個方面的要素。
- 問題概述：用簡短的幾句話，將所理解的問題本質描述出來；
- 影響：說明該問題將會對哪些項目干係人（Stakeholder，風險承擔者）產生影響；
- 結果：確定問題對項目干係人和商業活動會產生什麼樣的影響；
- 優點：概要性地提出解決方案，並列舉出該解決方案的主要優點。
- 在問題定義上達成共識，就能夠有效地將開發團隊的理解與用戶的需求達成一致，這樣就能夠使得整個系統的開發沿着合理的方向發展。
1.2 理解問題的本質
每一句描述都會夾雜着敘述者的個人理解和判斷，因此透過表面深入本質，理解問題背後的問題，是問題分析階段一個十分關鍵的任務。其中一種技術是 “ 根本原因 ” 分析，這是一種提示問題或其表象的根本原因的系統化方法。在實際的應用中，常使用因果魚骨圖和帕累託圖兩種方法。
（1）因果魚骨圖
因果魚骨圖是一種有效的探尋問題根源的技術，它通過直觀的圖形找出問題或現象的所有潛在原因，從而追蹤出問題的根源。它能夠幫助人們將問題的原因放在首位，提供了一種運用集體智慧解決問題的方法。在使用時，通常按照以下步驟進行。
- 將問題簡明扼要地寫在右邊的方框裏；
- 確定問題潛在原因的主要類別，將它們連到魚的脊骨上；
- 用頭腦風暴法尋找原因並歸類。
圖 1 是魚骨圖的一個示例。
（2）帕累託圖
帕累託圖是採用直方圖的形式，根據問題的相對頻率或大小從高往低降序排列，幫助設計師將精力集中在重要的問題上。它爲 80% 的問題找到關鍵的 20% 的原因，它可以一目瞭然地顯示出各個問題的相對重要程度，有助於預防在解決了一些問題後，卻使另外一些問題變得更糟的現象發生。在使用時，通常按照以下步驟進行。
- 明確問題：也就是前面達成共識的問題定義；
- 找出問題的各種可能原因：通常可以利用頭腦風暴來收集意見，並通過參考以往積累的資料和運營的數據來綜合分析；
- 選擇評價標準和考察期限：最常用的評價標準包括頻率（佔總原因的百分比）和費用（產生的影響），而考察的期限則應具有相應問題的代表性，並不是越長越好；
- 收集各種原因發生的頻率及費用數據；
- 將原因按照發生的頻率或費用從大到小排列起來；
- 將原因排在橫軸上，頻率或費用排列在縱軸上，形成如圖 2 所示的結果。
這樣就能夠將造成問題的關鍵原因捕獲出來，以便指導設計出更符合需要 、 更能夠解決問題的解決方案。
1.3 確定項目干係人和用戶
要想有效地解決問題，必須瞭解用戶和其他相關的項目干係人（任何將從新系統或應用的實現中受到實質性影響的人）的需要。不同的項目干係人通常對問題有不同的看法和不同的需要，這些在解決問題時必須加以考慮。事實上，許多項目干係人就是系統的用戶，這一部分通常是易於識別的；但還有一部分項目干係人是系統的間接用戶，甚至只是受系統影響的商業結果，這一部分不易識別，但十分重要。
在尋找項目干係人時，可以思考：系統的用戶是誰？系統的客戶（購買者）是誰？還有哪些人會受到系統輸出的影響？系統完成並投入使用後，有誰會對它進行評估？還有沒有其他系統內部或外部的客戶，他們的需要有沒有必要去考慮？系統將來由誰來維護？
1.4 定義系統的邊界
系統的邊界是指解決方案系統和現實世界之間的邊界。在系統邊界中，信息以輸入和輸出的形式流入系統並由系統流向系統外的用戶，所有和系統的交互都是通過系統和外界的接口進行的。在定義系統的邊界時，將世界分爲兩個部分：系統及與系統進行交互的事物。要描述系統的邊界有兩種方法：一種是結構化分析中的 “ 上下文範圍圖 ” ，另一種則是面向對象分析中的 “ 用例模型 ” 。
（1）上下文範圍圖
也就是數據流圖中的頂層圖，它是一個反映領域信息的模型，能夠清晰地顯示出系統的工作職責和相鄰系統的職責起止之處，從而讓我們能夠從宏觀的層面去了解系統。圖 3 就是一個描述 “ 證券經紀人系統 ” 的上下文範圍圖。
（2）用例模型
用例模型則通過引入參與者來描述 “ 和系統進行交互的事物 ” ，只要識別了參與者，自然而然系統的界限就確定下來了。在尋找參與者時，可以思考以下問題：誰會對系統提供信息？誰會在系統中使用信息？誰會從系統中刪除信息？誰將操作系統？系統將會在哪裏被使用？系統從哪裏得到信息？哪些外部系統要和系統進行交互？
然後，再根據每個參與者的功能需求，識別出代表系統功能的用例，從而界定系統的邊界。
1.5 確定系統實現的約束
由於各種因素的存在，會對解決方案的選擇造成一定的限制，稱這種限制爲約束。每條約束都將影響到最後的解決方案的形成，甚至會影響是否能夠提出解決方案。
在考慮約束時，首先應該考察到不同的約束源，其中包括進度 、 投資收益 、 人員 、 設備預算 、 環境 、 操作系統 、 數據庫 、 主機和客戶機系統 、 技術問題 、 行政問題 、 已有軟件 、 公司總體戰略和程序 、 工具和語言的選擇 、 人員及其他資源限制等。
2 問題定義
通過對問題進行細緻周密的分析，就可以對其進行綜合的定義。對於一個問題的完整定義，通常應包括目標 、 功能需求和非功能需求三個方面。
2.1 目標
目標是指構建系統的原因，它是最高層次的用戶需求，是業務上的需要，而功能 、 性能需求則必須是以某種形式對該目標做出貢獻。在描述目標時，應該注意以下幾個方面。
- 優勢：目標應該不僅僅是解決問題，還要提供業務上的優勢；
- 度量：不僅要說明業務的優勢，而且還必須提供度量這種優勢的標準；
- 合理性：要確保完成解決方案所需的工作量少於所獲得的業務優勢，這纔是合理的解決方案；
- 可行性：要探尋能夠滿足度量標準的解決方案；
- 可達成性：對於組織而言，是否具備獲取該系統的技能，構建完成後是否能夠操作它。
2.2 功能需求
功能需求是用來指明系統必須做的事情，只有這些行爲的存在，纔有系統存在的價值。功能需求應該源於業務需求，它只與問題域相關，與解決方案域無關。也就是說，功能需求是在與用戶或某個業務人員交談時，他們所描述的內容是爲了完成他們某部分的工作而必須做的事情。
而在設計解決方案時，會遇到一些限制條件，這些東西也是 “ 系統需求 ” 的一部分，不過應該是設計約束或非功能需求形式指定。在規定功能需求時要注意其詳細程度。由於這些需求是業務需求，因此應該由業務人員來驗證。也就是說，用戶應該能夠指明系統要達到有用的程度，功能是否已經足夠；考慮到工作的成果，它的功能是否正確。另外，在描述功能需求時，應該注意需求的二義性。而二義性主要體現在以下幾個方面。
（1）同名異義的詞：在自然語言中存在許多同名但異義的詞語，應該謹慎地排除它們帶來的影響。
（2）代詞：在需求描述中，代詞經常會產生指代不明的現象，應該儘量避免使用，而是換成主語及賓語。
在檢查功能需求的二義性時，一種有效的方法是大聲地朗讀出來，大家一起邊聽邊進行討論，這樣可以不斷地優化。
2.3 非功能需求
非功能需求是系統必須具備的屬性，這些屬性可以看作是一些使產品具有吸引力 、 易用 、 快速或可靠的特徵或屬性。非功能需求並不改變產品的功能，它是爲工作賦予特徵的。
在識別功能需求和非功能需求時，有一種十分有用的思維模式：功能需求是以動詞爲特徵的，而非功能性需求則是以副詞爲特徵的。非功能需求主要包括以下幾種。
（1）觀感需求：即產品外觀的精神實質，也就是與用戶界面的觀感相關的一組屬性；
（2）易用性需求：也就是產品的易用性程度，以及特殊的可用性考慮，通常包括用戶的接受率 、 因爲引入該產品而提高的生產效率 、 錯誤率 、 特殊人羣的可用性等指標；
（3）性能需求：也就是關於功能實現要求有多快 、 多可靠 、 多少處理量及多精確的約束。例如：速度 、 精度 、 安全性 、 容量 、 值範圍 、 吞吐量 、 資源使用效率 、 可靠性（平均無故障時間） 、 可用性（不停機時間） 、 可擴展性等；
（4）可操作性需求：衡量產品的操作環境，以及對該操作環境必須考慮的問題；
（5）可維護性和可移植性需求：期望的改變，以及完成改變允許的時間；
（6）安全性需求：產品的安全保密性，通常體現爲保密性 、 完整性和可獲得性；
（7）文化和政策需求：由產品的開發者和使用者所帶來的特別需求；
（8）法律需求：哪些法律和標準適用於本產品。