需求分析概述word版-資料下載頁
2025-08-22 04:10本頁面
【正文】 輯包含在系統(tǒng)內(nèi)部處理的流程上，而非與外部系統(tǒng)的交互。建模主要任務是表達系統(tǒng)內(nèi)部的交互。用例圖適于表達交互，之所以上面使用了電信系統(tǒng)，是因為用例最早來自于Ericsson的交換機系統(tǒng)。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，并于1994年提出了OOSE方法，其最大特點是面向用例（UseCase），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業(yè)工程和需求分析。隨著用例的發(fā)展，用例被大量的用于對功能進行描述。每個用例代表了系統(tǒng)與外部ACTOR的交互?？梢圆扇№樞驁D來表達用例的具體操作程序。ACTOR用于確定系統(tǒng)的邊界。ACTOR、用例可以從不同的層次來描述信息。采用該原則的原因有：1.需求并不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。2.人的認知往往具有層次的特性。從粗到細、從一般到特殊。采用不同的層次來描述，適于認知的過程。使用用例開發(fā)系統(tǒng)的一般過程在開發(fā)過程的初始階段，可以根據(jù)具體的項目特點，制訂開發(fā)各個視圖之間的關聯(lián)原則，指導規(guī)范。在開發(fā)的過程中，視圖的組織原則應不斷進行維護、更新。識別ACTOR來識別系統(tǒng)與外界交互的實體。ACTOR具有特定領域的特征，例如：交換機（采集系統(tǒng)）、97信息系統(tǒng)等。在系統(tǒng)層次的ACTOR確定了系統(tǒng)的邊界。識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。注：系統(tǒng)開發(fā)需要一定的規(guī)則來確定，如何來分解用例；可能基于原有系統(tǒng)的經(jīng)驗，或是參考現(xiàn)有資料。當用例細化到可以被理解的層次。需要基于用例進行下一步的開發(fā)。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節(jié)。交互的實體采用類圖來描述；而交互的細節(jié)，采用順序圖來描述。當系統(tǒng)復雜到一定層次時，類圖和順序圖可能不能足以描述其復雜程度。在該情況下，需要使用狀態(tài)圖來輔助闡述。狀態(tài)圖和順序圖之間使用事件聯(lián)結在一起。它們之間的一致性問題，目前UML和ROSE沒有提供解決方案。相對折衷的方法是使用事件的命名規(guī)范強制一致性?？梢哉f，之前說的所有的東西都是為了能夠導出用例在需求中的作用。用例是從用戶的角度看待系統(tǒng)，而不是基于程序員的角度。這樣的話，用例驅動的系統(tǒng)能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統(tǒng)開發(fā)鏈中完整的體現(xiàn)。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。從前，系統(tǒng)開發(fā)者總是通過情節(jié)來獲取需求，是問用戶希望系統(tǒng)為他做什么。在Jacobson發(fā)明了用例的概念之后，需求獲取就變成問用戶要利用系統(tǒng)做什么。這是立場不同導致的結果。用戶通常并不關心系統(tǒng)是如何實現(xiàn)的（也有少數(shù)可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現(xiàn)用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源于用戶，服務于用戶，但是它同樣可以用于開發(fā)的流程。當系統(tǒng)的開發(fā)過程都是基于用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發(fā)過程就是用例驅動的。用例和用例文檔《軟件需求》一書中提到了幾種方法來確定用例：?首先明確執(zhí)行者和他們的角色，然后確定業(yè)務過程，在這一過程中每一個參與者都在為確定用例而努力。?確定系統(tǒng)所能反映的外部事件，然后把這些事件與參與的執(zhí)行者和特定的用例聯(lián)系起來。?以特定的說明形式表達業(yè)務過程或日常行為，從這些說明中獲得用例，并確定參與到用例中的執(zhí)行者，有可能從現(xiàn)在的功能需求說明中獲得用例。如果有些需求與用例不一致，就應考慮是否真的需要它們。用例代表了用戶的需求，在你的系統(tǒng)中，應該直接從不同用戶類的代表或至少應從代理那里收集需求。用例為表達用戶需求提供了一種方法，而這一方法必須與系統(tǒng)的業(yè)務需求相一致。分析者和用戶必須檢查每一個用例，在把它們納入需求之前決定其是否在項目所定義的范圍內(nèi)?；凇坝美狈椒ㄟM行需求獲取的目的在于：描述用戶需要使用系統(tǒng)完成的所有任務。在理論上，用例的結果集將包括所有合理的系統(tǒng)功能。在現(xiàn)實中，你不可能獲得完全包容，但是比起我所知道的其它獲取方法，基于用例的方法可以為你帶來更好的效果。當使用用例進行需求獲取時，應避免受不成熟的細節(jié)的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節(jié)都作為需求記錄下來，他們會給隨后的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發(fā)過程中，將會詳盡闡述他們的需求。在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，并作為用例。然后，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統(tǒng)的限制和用戶對質量的期望。雖然最初的屏幕構思有助于描述你對需求的理解，但是你必須細化用戶界面設計。建立用例文檔。在每一次的需求獲取之后，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術能夠提高你的速度和需求的復用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標識號、用例名稱、父用例標志號、創(chuàng)建者、創(chuàng)建時間、審核者、修訂記錄、角色、說明、先決條件、請求結果、優(yōu)先級、普通過程、可選過程、例外、非功能需求、假設、注釋和問題。雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟
教學教案相關推薦
鄂ICP備17016276號-1