需求定義
通過需求捕獲，將系統建立不同的問題域，對每個問題域進行上下文關係分析。問題域可以用元件圖來描述；上下文關係用上下文關係圖來描述，它描述的其實是業務用例。
按照上下文關係的每個事件建立脈絡。
脈絡及框架分析
對上下文關係的每個事件進行分析，進行流程分析，描述事件的具體流程，可以用活**和dfd來描述，在oo中，一般使用活**。
下一步對活動中的業務實體進行分析，可以通過類圖來描述，在需求階段，類圖用來描述業務實體，只用確定類之間的關係和屬性，不用過早的確定操作，操作可以在設計階段再確定。類圖在設計階段要遵守實體的規則，不要對大類進行拆分，對子類進行合併、抽象。這些都是設計階段要做的事情，這裡只要準確的反映實體的關係即可。另外一種表示方法是e-r圖，但在oo中一般用類圖來表示。
然後通過對業務流程的分析，確定用例模型，建立用例模型的乙個要點是要站在系統外部去觀察系統。舉乙個簡單的例子，在信用卡系統中「增加客戶」這個用例，是在系統內部，以軟體開發人員的角度去描述用例，而如果站在系統外部，或站在業務人員的角度去描述則是「信用卡開卡」。
參與者是直接作業系統的外部使用者(角色)，可以分為使用者、外部系統、時鐘，這裡要注意是直接作業系統，間接作業系統的使用者不是用例中的參與者（如顧客不是參與者，而銀行櫃員是參與者）
在系統用例中，用例是系統要實現的功能，在活**中，每個用例活動都可以作為用例，但要區別這個活動是否需求系統完成。另外就是要確認這個活動是否太小，只是乙個步驟，就不用作為用例。用例是對參與者有意義的一件事情。
填充細節階段
根據第二階段的脈絡和框架分析，將每個事件中的用例和類片斷整合，可得出系統的用例模型和類模型，填充細節階段要做的工作主要是對用例規約進行描述內容包括：功能描述、基本事件流、擴充套件事件流、業務規則、ui原型、約束等。
如何做需求分析
如何做需求分析 原則 永遠不要顯得比客戶更聰明 第一條 了解需求，而不是去批評客戶 第二條 客戶比你更熟悉業務的環境 第三條 客戶總是知道問題在哪兒，你的工作就是要讓他們自己願意說出來 原則 尊重使用者的現實選擇 第一條 客戶永遠是對的 第二條 提供最合適的解決方案，而非最好或最貴的方案 第三條 不...
如何做需求分析？
目錄1.使用者需求與產品需求分析 2.什麼可以把產品需求轉化為使用者需求？3.使用者動機 4.需求篩選 一 分析 1 產品的構思初期，我們會羅列盡可能多需求，也會收集到很多需求。但有些需求是偽需求，有些需求也不具備實現價值，那我們如何做判斷呢？每天有無數產品誕生，也有無數產品隕落，很多時候會談到乙個...
如何做需求分析
這裡講的 需求 這個詞的含義是指客戶對他所委託開發的 在功能上明確約定和 形式上應當達到的標準的約定。我把對乙個 或者更廣義的說，乙個產品 的需求分為 3個層次 1 核心需求。核心需求定義了乙個 的最基本功能，是必須無條件得到有效滿足的需求。核心需求是同一行業同一型別的單位所具有的共性需求。例如西安...