第3章需求分析與用例建模本章目的⑴掌握客戶需求分析的要點及需求分析規(guī)格說明報告的書寫格式。⑵通過繪制用例圖及其正文描述來完成客戶需求分析的方法。⑶掌握UML的用例模型建模方法。⑷掌握活動圖的繪制方法，并且能夠繪制活動圖。3.1客戶需求分析需求分析階段是開發(fā)過程中第一重要的階段，如果不能準確的理解客戶需要什么，那么就無法構(gòu)造出正確的系統(tǒng)。如果不了解客戶的領域及客戶需要解決的問題，那么所有的用例分析都無濟于事?？蛻粜枨髮Q定整個項目要承辦方具體做些什么，承辦方只有明確了客戶的需求，才能進行系統(tǒng)設計、編程、測試和維護等工作。在初始需求階段，需要獲得客戶的業(yè)務模型，然后根據(jù)業(yè)務模型建立計算機模型。要建立一個符合客戶需要的計算機系統(tǒng)，首要條件是完全徹底搞清楚客戶的業(yè)務，而不是預先假設已有一個計算機系統(tǒng)，再讓客戶假象計算機系統(tǒng)幫他們做什么。然而，實際情況是大多數(shù)情況下，用戶并不清楚自己究竟想要什么。因此，期望僅僅依靠用戶獲得完整的需求是完全不現(xiàn)實的。所以，需求分析階段，開發(fā)人員必須進行細致的調(diào)查研究，以便較好地理解客戶的要求。將客戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應的需求規(guī)格說明。需求分析階段的首要工作是要深入了解用戶的實際工作領域，通過客戶和軟件開發(fā)人員之間的溝通，了解客戶的需求。然后與問題領域?qū)＜矣懻?，分析問題領域的業(yè)務范圍、業(yè)務規(guī)則和業(yè)務處理過程，明確系統(tǒng)的責任、范圍和邊界，確定系統(tǒng)的需求，并建立需求模型。在UML中需求模型使用用例圖來表示。3.1.1系統(tǒng)調(diào)查系統(tǒng)調(diào)查是系統(tǒng)開發(fā)過程中的基礎工作，通常分為初步調(diào)查和詳細調(diào)查，是一種十分有效的需求獲取方法，也是系統(tǒng)開發(fā)不可缺少的過程和手段。需求獲取技術包括用戶訪談、用戶調(diào)查、現(xiàn)場觀摩用戶的工作流程、觀察用戶的實際操作、考查文檔、開需求討論會、從行業(yè)標準及規(guī)范中提取需求、采用原型法和其他技術等。這個活動也稱為信息收集或者數(shù)據(jù)收集。調(diào)查研究分為兩個階段，一是初步的調(diào)查，在可行性分析階段進行，即先投入少量的人力對系統(tǒng)進行大致的了解，分析其開發(fā)的可行性；二是詳細的調(diào)查，這是在系統(tǒng)分析階段進行的，即在確定系統(tǒng)可行并立項后，投入大量的人力，展開大規(guī)模、全面詳細的系統(tǒng)調(diào)查。3.1.1.1初步調(diào)查初步調(diào)查是接受客戶提出建立新系統(tǒng)的要求后，系統(tǒng)研制人員與用戶管理人員的第一次溝通。調(diào)查研究技術有：對現(xiàn)有文檔、表格和數(shù)據(jù)庫進行抽樣；實地訪問；觀察工作環(huán)境；發(fā)調(diào)查表；面談；原型化和聯(lián)合需求計劃等。初步調(diào)查的范圍是全方位的，需要對經(jīng)濟、技術、管理和開發(fā)環(huán)境等等方面的內(nèi)容進行調(diào)查。初步調(diào)查的重點是了解用戶與現(xiàn)行系統(tǒng)的總的情況，現(xiàn)行系統(tǒng)與外部環(huán)境的聯(lián)系，現(xiàn)行系統(tǒng)的現(xiàn)有資源，外界的約束條件等。具體來說了解如下的內(nèi)容：⑴現(xiàn)行系統(tǒng)的概況。了解現(xiàn)行系統(tǒng)的規(guī)模、系統(tǒng)目標、發(fā)展歷史、組織結(jié)構(gòu)、管理體制、人員分工、技術條件、技術水平等。⑵系統(tǒng)外部環(huán)境?，F(xiàn)行系統(tǒng)和外部環(huán)境有哪些聯(lián)系，哪些外部條件制約系統(tǒng)的發(fā)展。⑶現(xiàn)行系統(tǒng)的資源。現(xiàn)行系統(tǒng)有哪些資源，信息系統(tǒng)的狀況等。⑷用戶資源和要求。開發(fā)新系統(tǒng)用戶可以提供的人力、物力和財力等情況，用戶的時間要求、功能要求、非功能要求和開發(fā)目標等。⑸現(xiàn)行系統(tǒng)存在的問題。在初步調(diào)查中可以設計一些調(diào)查表，通過這些調(diào)查表可以更好地收集一些信息。了解現(xiàn)行系統(tǒng)存在的主要問題。3.1.1.2詳細調(diào)查1.詳細調(diào)查的原則在進行詳細調(diào)查時可遵循以下的原則：⑴系統(tǒng)性原則。⑵計劃性原則。⑶科學性原則。⑷前瞻性原則。2.詳細調(diào)查的內(nèi)容⑴全面調(diào)查的內(nèi)容與初步調(diào)查一樣，要了解現(xiàn)行系統(tǒng)的發(fā)展歷史、現(xiàn)狀、規(guī)模、經(jīng)營狀況、業(yè)務范圍、與外界的聯(lián)系、確定系統(tǒng)的邊界；對系統(tǒng)的組織結(jié)構(gòu)進行調(diào)查，了解各個部門的權限、職責、人員分工和關系等；了解系統(tǒng)的資源狀況，現(xiàn)有系統(tǒng)的物資、資金、設備、建筑平面布局和其他的資源。2.詳細調(diào)查的內(nèi)容⑵重點調(diào)查的內(nèi)容。詳細調(diào)查的重點是業(yè)務流程以及數(shù)據(jù)的調(diào)查。在進行調(diào)查時，要弄清楚某項業(yè)務做什么？為什么做？由誰來做？在哪里做？何時做以及如何做等，在做的過程中產(chǎn)生了哪些數(shù)據(jù)。即：What、Why、Who、Where、When、How數(shù)據(jù)的調(diào)查內(nèi)容主要包括輸入信息、輸出信息、信息處理過程、存儲方式、代碼信息和信息需求調(diào)查等。3調(diào)查的方法與策略⑴獲取信息的渠道。⑵調(diào)查數(shù)據(jù)的來源。①組織正式報告（對于手工系統(tǒng)）；②各種卡片、報表；③會議決議；④現(xiàn)行系統(tǒng)的說明性文件（局部計算機化的系統(tǒng)）；⑤各種流程圖；⑥計算機文件（或數(shù)據(jù)庫），系統(tǒng)的數(shù)據(jù)組織結(jié)構(gòu)；⑦組織外的數(shù)據(jù)來源；⑧上級下達的各種文件和各項任務指標；⑨與本單位密切相關的其它單位的有關信息。⑶調(diào)查的方法①詢問法。②觀察法。③實驗法。④抽樣調(diào)查法⑤查閱檔案資料法。⑥聯(lián)合需求計劃。聯(lián)合需求計劃（JointRequirementPlanning，JRP）也有的稱為聯(lián)合應用開發(fā)（JAD，JointApplicationDevelopment），它是一個方法論，它將一個應用程序的設計和開發(fā)中的客戶或最終用戶聚集在一起，通過一連串的合作研討會獲得需求，也叫JRP會議。計劃一個JRP會議包括3個步驟1）選擇JRP會議地點。2）選擇JRP會議參加者。參加者包括JRP主持人、抄寫員和用戶團體代表。用戶和管理人員IT專家和其他觀察員IT專家和其他觀察員抄寫員抄寫員抄寫員計算機投影設備黑板食物和飲料圖3.JRP會議的典型房間布局⑷調(diào)查的策略在進行調(diào)查研究時，通常不要直接進行面談，而是先收集可以通過其他方法收集到信息。調(diào)查研究的策略是：了解現(xiàn)有文檔、表格、報告和文件；如果合適，觀察工作中的系統(tǒng)；根據(jù)你已經(jīng)收集到的信息，設計并分發(fā)調(diào)查表，澄清你沒有完全理解的問題；進行面談來驗證和澄清最困難的問題；對于沒有理解的功能需求或者需要被驗證的需求，可以構(gòu)造獲取原型；使用合適的調(diào)查研究技術驗證事實。這個策略并不是不可改變的，根據(jù)實際情況選擇調(diào)查策略。但基本思想是在面談之前收集盡可能多的事實。3.1.2系統(tǒng)需求陳述 面向?qū)ο蠓治龅牡谝徊?，就是獲取用戶的需求。需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息，由于在實際工作中，大部分客戶無法完整地講述其需求需求獲取是一件看似簡單，做起來卻很難的一件事情。在需求獲取過程中，主要需要弄清楚3個問題，即：明確需要獲取的信息（What）、明確所獲取信息的來源和渠道（Where）和怎樣獲取需求（How）。3.1.3系統(tǒng)需求分析 從廣義來說需求分析包括需求的獲取、分析、規(guī)格說明、變更、驗證、管理等一系列需求工程。從狹義上來看需求分析是指需求的分析、定義過程。需求分析就是分析軟件用戶的需求是什么。在軟件工程中，需求分析指的是在建立一個新的或改變一個現(xiàn)存的系統(tǒng)時描寫新系統(tǒng)的目的、范圍、定義和功能所要做的所有的工作。需求分析的目的就是發(fā)現(xiàn)和解決需求中的這些問題并達成一致意見。如果在調(diào)查研究的過程中獲取的需求被查出存在問題，就需要分析員對這些問題進行專門的分析。1.需求分析的任務需求分析階段的工作包括定義需求、分析與綜合、制訂規(guī)格說明和評審等。⑴定義需求。定義需求就是從系統(tǒng)角度來理解軟件，確定對所開發(fā)系統(tǒng)的綜合要求，并提出這些需求的實現(xiàn)條件，以及需求應該達到的標準。這些需求包括：功能需求和非功能性需求。功能性需求描述一個系統(tǒng)必須提供的活動和服務（做什么）；非功能性需求描述一個滿意的系統(tǒng)的其他特征、特點和約束條件等，1.需求分析的任務⑵分析與綜合。逐步細化所有的軟件功能，找出系統(tǒng)各元素間的聯(lián)系，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最后，綜合成系統(tǒng)的解決方案，給出要開發(fā)的系統(tǒng)的模型（做什么的模型）。⑶編制需求規(guī)格說明書。描述需求的文檔稱為軟件需求規(guī)格說明書。需求分析階段的成果是需求規(guī)格說明書，是提交下一階段的文檔資料。⑷評審。對功能的正確性、完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作，否則重新進行需求分析。2.需求分析的過程3.需求分析的特點⑴用戶與開發(fā)人員很難進行交流。⑵用戶的需求是動態(tài)變化的。對于一個大型而復雜的軟件系統(tǒng)，用戶很難精確完整地提出它的功能和性能要求。⑶系統(tǒng)變更的代價呈非線性增長。需求分析是軟件開發(fā)的基礎。假定在該階段發(fā)現(xiàn)一個錯誤，解決它需要用一小時的時間，到設計、編程、測試和維護階段解決，則要花2.5、5、25、100倍的時間。3.2需求建模 3.2.1用例建模

需求分析主要是定義業(yè)務用例模型。業(yè)務用例模型的目的在于描述企業(yè)的內(nèi)部組織結(jié)構(gòu)；描述企業(yè)各部門的業(yè)務；關注于角色和系統(tǒng)的交互界面。用例建模被認為是描述信息系統(tǒng)功能需求的最佳實踐，用例模型描述系統(tǒng)外部的參與者所理解的系統(tǒng)功能。用例圖是UML圖中較為重要和常用的一種圖，常常用于軟件開發(fā)的分析階段，也能用于軟件的系統(tǒng)測試階段。1.用例圖用例圖是描述系統(tǒng)與其他外部系統(tǒng)以及用戶之間交互的圖形，即用例圖描述了誰將使用系統(tǒng)，用戶希望以什么方式與系統(tǒng)交互。用例圖確定系統(tǒng)中所包含的參與者、用例和兩者之間的對應關系，它描述的是關于系統(tǒng)功能的一個概述，描述軟件應具備哪些功能模塊以及這些模塊之間的調(diào)用關系。用例圖包含了用例和參與者，用例之間用關聯(lián)來連接以求把系統(tǒng)的整個結(jié)構(gòu)和功能反映給非技術人員（通常是軟件的用戶）。用例圖展示了用例之間以及同用例參與者之間是怎樣相互聯(lián)系的。用例模型的建立過程先畫用例圖，然后對用例圖編寫用例說明。在編寫用例說明的時候，對一些復雜的、認為有必要的地方，繪制活動圖、狀態(tài)圖或順序圖，方便閱讀者理解。用例圖關注的是三部分內(nèi)容：用例、參與者和關系。用例之間的關系①如果一個用例包含另一個用例的行為，則這兩個用例之間存在包含關系，或者說一個用例使用了另一個用例的行為，被調(diào)用用例可以是事先定義好的，也可以是在各種環(huán)境下使用的公共行為，調(diào)用是無條件的。②如果對一個用例的行為添加某些額外的行為，包含此額外行為的用例和原來的用例之間就構(gòu)成了擴展關系③如果一個用例是另一個用例的特例，這兩個用例之間就是泛化關系，父用例不具備完整的事件流，不具備執(zhí)行能力，而子用例實現(xiàn)其高級行為2.用例描述用例描述是業(yè)務事件以及用戶如何同系統(tǒng)交互以完成任務的文字描述。用例圖可以直觀地展現(xiàn)需求中的所有用例、參與者、系統(tǒng)邊界，以及它們之間的關系，但這還不足以表達需求分析所要求表達的內(nèi)容。用例圖必須輔之以用例說明，才能完整清楚地表達。針對每一個用例都應該有一個用例規(guī)約文檔與之相對應，該文檔描述用例的細節(jié)內(nèi)容。3.用例建模的步驟⑴確定將要設計的系統(tǒng)范圍和它的邊界。⑵確定系統(tǒng)外的參與者。⑶從參與者（用戶）和系統(tǒng)對話的角度繼續(xù)尋找一下兩方面的特征：尋找參與者怎樣使用系統(tǒng)；系統(tǒng)向參與者提供什么樣的功能。把離用戶最近（接口）的用例作為頂層用例。⑷對復雜的用例做進一步分解，并確定低層用例以及用例間的關系。⑸對每一用例做進一步細化。⑹尋找每一個用例發(fā)生的前提條件和發(fā)生后對系統(tǒng)產(chǎn)生的結(jié)果。3.用例建模的步驟⑺尋找每一個用例在正常條件下的執(zhí)行過程。⑻尋找每一個用例在非正常條件下的執(zhí)行過程。⑼用UML建模工具畫出分層的用例模型圖。⑽審核用例模型。⑾編寫用例模型圖的補充說明文檔。4.業(yè)務用例建模當進行一個項目的需求分析時，首先要聽用戶談他們的需求，或者看用戶提交的業(yè)務需求文檔。用戶一定會提出一個又一個的功能或要求，它們中的每一個要求就成為了最初的用例。分析這些用例，關注它們的每一個參與者，以及它們相互之間的關系，這就形成了最初的用例模型。在采用用例分析的方式與客戶溝通需求的時候，應當著重關注的是參與者及其目標，即每個功能的參與者是誰，完成這個功能的目標是什么，以及如何完成這個目標。4.業(yè)務用例建模這時的用例說明采用概述的方式，即只進行主成功場景（基本流程）的描述。此后，繼續(xù)細化用例，各個用例的替代場景（分支流程）逐漸被整理出來，用例再一步步細化。開發(fā)人員對一些需求的認識一開始可能存在著偏差，因此，需要不斷更正用例描述。一些新的功能可能被用戶提出來，形成一些新的用例。如此反復數(shù)輪之后，項目需求的整體框架才逐漸清晰。然后應該討論系統(tǒng)邊界，對用例模型進行再一次調(diào)整。3.2.2確定系統(tǒng)邊界和范圍 1.確定系統(tǒng)的邊界任何一個系統(tǒng)都有一個邊界的問題。邊界問題就是確定系統(tǒng)和相鄰系統(tǒng)交接部分。定義系統(tǒng)邊界就是定義系統(tǒng)的范圍，即哪些元素屬于本系統(tǒng)，哪些元素屬于相鄰系統(tǒng)，明確系統(tǒng)目標范圍。系統(tǒng)邊界是一個軟件系統(tǒng)需要處理的整個問題空間的范圍。一個軟件系統(tǒng)不可能處理所有問題，必須得給它定義這個問題空間的范圍。2.確定系統(tǒng)的范圍在確定好系統(tǒng)的執(zhí)行者和用例后，系統(tǒng)的邊界就確定了。然后就需要確定項目的范圍，清晰的定義項目的范圍，將不需要做的事情放到一邊，同時為需要做的劃分優(yōu)先級。系統(tǒng)范圍是指整個系統(tǒng)中安全基線所涉及的對象和考慮的范圍，系統(tǒng)范圍確定是一個劃定系統(tǒng)安全邊界的過程，該邊界界定了安全基線的管轄范圍，即將系統(tǒng)劃分為內(nèi)部和外部兩部分，系統(tǒng)內(nèi)部即為安全基線的系統(tǒng)范圍，系統(tǒng)外部即為系統(tǒng)環(huán)境，而系統(tǒng)安全邊界正是這兩部分的接口。3.2.3確定參與者 通常將系統(tǒng)外部與系統(tǒng)內(nèi)部交互的事物統(tǒng)稱為參與者，也有的稱為執(zhí)行者或者角色。參與者是在系統(tǒng)之外與系統(tǒng)交互的某人或事物，每一個執(zhí)行者都對應一種特定的角色，每一個系統(tǒng)之外的實體對應多種執(zhí)行者，就好比一個人在系統(tǒng)中他會有多種角色一樣，又或者幾個人可以用一個執(zhí)行者來表示，因為他們對于系統(tǒng)來講屬于同一個角色。參與者是在系統(tǒng)之外，在系統(tǒng)之內(nèi)的不是參與者，參與者與系統(tǒng)有明顯的系統(tǒng)邊界。如何尋找參與者可以參考如下的信息源：標示系統(tǒng)范圍和邊界的上下文圖；現(xiàn)有的系統(tǒng)文檔和系統(tǒng)手冊；項目會議和研討會的記錄；現(xiàn)有的需求文檔、項目章程或工作陳述。參與者總是在你的系統(tǒng)之外，他們從來都不是系統(tǒng)的一部分。為了幫助找到執(zhí)行者，可以在人、其他的軟件、硬件設備、數(shù)據(jù)存儲、或者網(wǎng)絡目錄中進行尋找。參與者是在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進行有意義交互的任何事物。通俗地講，參與者就是所要定義系統(tǒng)的使用者。尋找參與者可以從以下問題入手：⑴

系統(tǒng)開發(fā)完成之后，有哪些人會使用這個系統(tǒng)？⑵系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？⑶系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？⑷系統(tǒng)需要與哪些其他系統(tǒng)交互？⑸系統(tǒng)是由誰來維護和管理并保持其正常運行？⑹系統(tǒng)需要應付（處理）哪些硬設備？⑺誰（或什么）對系統(tǒng)運行產(chǎn)生的結(jié)果感興趣？⑻有沒有自動發(fā)生的事件？3.2.4確定需求用例 用例圖中首先要明確的概念就是用例。用例是系統(tǒng)的一個功能單元，描述了參與者與系統(tǒng)發(fā)生的一次交互行為。用例，就是一件事情，要完成這件事情，需要一系列活動。做一件事情可以有很多不同的方法和步驟，也可能會有各種各樣的意外情況，因此，這件事情由很多不同情況的集合構(gòu)成，在UML中稱為場景。用例必然是以動賓形式出現(xiàn)，用例相對獨立，但不意味用例不與其他用例交互而獨立完成參與者的目的。3.2.4確定需求用例 確定用例主要是看各參與者需要系統(tǒng)提供什么樣的服務，或者說參與者是如何使用系統(tǒng)的。如銀行的ATM自動提款機系統(tǒng)，用戶提款就是一個用例。用例就是一個用來描述參與者如何使用系統(tǒng)來實現(xiàn)其目標的一組場景的集合。用例強調(diào)的是一組場景，在這組場景不多但相互之間存在功能上的共性，就像一個大功能模塊下的多個子模塊。這組場景中的每一個，又分別形成一個個子用例。尋找用例的方法：⑴從原始需求中尋找所包含的功能。⑵未來的系統(tǒng)，需要和哪些系統(tǒng)發(fā)生信息交互？⑶哪些人將操作未來的軟件系統(tǒng)？⑷系統(tǒng)有哪些受限的條件？⑸未來的軟件界面怎樣組織？⑹系統(tǒng)的響應有哪些去向？3.2.5用例模型的關系 用例描述的是系統(tǒng)外部可見的行為，是系統(tǒng)為某一個或幾個參與者提供的一段完整的服務。從原則上來講，用例之間都是并列的，它們之間并不存在著包含從屬關系。但是從保證用例模型的可維護性和一致性角度來看，可以在用例之間抽象出包含（include）、擴展（extend）和泛化（generalization）這幾種關系。這幾種關系都是從現(xiàn)有的用例中抽取出部分信息，然后通過不同的方法來重用這部分信息，以減少模型維護的工作量。1.UML用例圖的包含關系包含關系（include）是把幾個用例的公共行為分離成一個單獨的用例，使這幾個用例與該單獨的用例之間所建立的關系。被抽取出來的單獨的用例叫做被包含用例（Inclusion），而抽取出公共用例的幾個用例稱為基礎用例（Base）。包含用例是被封裝的，代表在各種不同基本用例中復用的行為。當某用例的事件流過于復雜時，為了簡化用例的描述，可以把某一段事件流抽象成為一個被包含的用例；相反，用例劃分太細時，也可以抽象出一個基用例，來包含這些細顆粒的用例。2.UML用例圖的擴展關系擴展關系（extend）是將基用例中一段相對獨立并且可選的動作，用擴展用例加以封裝，再讓它從基用例中聲明的擴展點上進行擴展，從而使基用例行為更簡練和目標更集中。擴展用例為基用例添加新的行為，擴展用例可以訪問基用例的屬性對于一個擴展用例，可以在基用例上有幾個擴展點。擴展用例帶有抽象性質(zhì)，表示用例場景中的某個“支流”，由特定的擴展點觸發(fā)而被啟動。與包含關系不同，擴展表示“可選”，而不是“必需”，這意味即使沒有擴展用例，基本用例也是完整的，如果沒有基本用例，擴展用例不能單獨存在。表3.包含和擴展關系的主要區(qū)別包含的用例擴展的用例這個用例是可選的嗎否是沒有這個用例基本用例還完整嗎否是這個用例的執(zhí)行是有條件的嗎否是這個用例改變了基本用例的行為嗎否是3.UML用例圖的泛化關系泛化關系（generalization）表示子用例和父用例的相似；子用例將繼承父用例的所有結(jié)構(gòu)、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在，代表一般與特殊的關系，它的意思和面向?qū)ο蟪绦蛟O計中的繼承的概念是類似的。子用例從父用例繼承了行為和屬性，還可以添加行為和屬性，改變已繼承的行為。3.2.6構(gòu)造業(yè)務用例模型圖建立業(yè)務模型，查找業(yè)務用例都必須使用業(yè)務主角，而不是普通參與者。業(yè)務主角是客戶實際業(yè)務里的參與者，沒有計算機，沒有抽象的計算機角色。參與者位于系統(tǒng)邊界外面，如果把邊界內(nèi)和外的參與業(yè)務的人都作為參與者建模，會混亂。。3.2.7用例規(guī)格說明用例模型包括用例圖和用例規(guī)格說明，有時還要輔之一些簡單的活動圖、狀態(tài)圖和順序圖等。用例說明是對用例、參與者和系統(tǒng)邊界進行的詳細描述。在描述過程中，還可以對一些關鍵的流程，以及這些流程中關鍵類的狀態(tài)變化，使用活動圖、狀態(tài)圖或順序圖進行圖形化地展現(xiàn)。因此，詳細描述用例的方式有用例規(guī)約描述、活動圖、狀態(tài)圖、順序圖和通信圖等。在需求分析中尚不涉及狀態(tài)問題，所以沒有必要用狀態(tài)圖、順序圖或通信圖表示，可以使用活動圖對用例進行分析，因為活動圖對分支、判斷、循環(huán)等流程概念的表達比其他圖清晰，適合用于描述業(yè)務過程。1.用例規(guī)約描述一個完整的用例包括參與者、前置條件、場景和后置條件等用例建模圖畫完以后，就要進行描述文檔的編寫，文檔主要用來彌補圖形表示的不足和增強系統(tǒng)的完整性。對于用例描述的內(nèi)容，一般沒有硬性規(guī)定的格式，但一些必須或者重要的內(nèi)容還是必須要寫進用例描述里面的。通常包括的內(nèi)容有：用例名稱、參與者、前置條件、后置條件、基本事件流、備用事件流、異常事件流等。表3.用例描述格式使用者場景1場景2場景3前置條件后置條件圖3.完整的用例表3.用例描述1⑴只描述參與者的行為，沒有描述系統(tǒng)的行為用例名稱取款用例描述客戶取款事件流基本事件流1.儲戶插入ATM卡，并鍵入密碼；2、儲戶按“取款”按鈕，并鍵入取款數(shù)目；3、儲戶取走現(xiàn)金、ATM卡以及收據(jù)；4、儲戶離開。用例描述⑵只描述系統(tǒng)的行為，沒有描述參與者的行為用例名稱取款用例描述客戶取款事件流基本事件流1、ATM系統(tǒng)獲得ATM卡和密碼；2、設置事務類型為“取款”；3、ATM系統(tǒng)獲取要提取的現(xiàn)金數(shù)目；4、驗證賬戶上是否有足夠儲蓄金額；5、輸出現(xiàn)金、數(shù)據(jù)和ATM卡；6、系統(tǒng)復位。用例描述2⑶描述過于冗長用例名稱客戶維護用例描述對客戶資料進行維護事件流……備選事件流修改客戶資料1．在客戶資料維護的主界面，用戶選擇查詢某客戶資料；2．系統(tǒng)顯示符合條件的客戶資料，內(nèi)容包括；客戶編號、來源、類型、省份、公司名稱，同時在每行的開始位置放置“修改”的按鈕，以便讓用戶點擊進行資料修改；3．用戶選擇某客戶記錄左邊的“修改”按鈕，修改某客戶資料；4．系統(tǒng)打開修改客戶資料界面；5．……2.使用活動圖描述用例前面用文本描述了用例的流程（用例規(guī)格說明）。文本描述的好處是容易被創(chuàng)建和修改，它們可以在任何地方被創(chuàng)建，可以很容易地由業(yè)務人員和開發(fā)人員使用和分享。但是，用文字描述的復雜用例、業(yè)務過程和算法可能難以理解。復雜流程采用可視化描述就會好很多。所以，完成了業(yè)務用例圖后，可以為每一個業(yè)務用例繪制一幅活動圖?；顒訄D提供了活動流程的可視化描述，可以是在系統(tǒng)、業(yè)務、工作流或其他過程中使用?；顒訄D關注被執(zhí)行的活動以及誰（或什么）負責執(zhí)行這些活動?；顒訄D還有個很重要的使命就是從業(yè)務用例分析出系統(tǒng)用例。一個系統(tǒng)用例應該是實際使用系統(tǒng)的用戶所進行的一個操作，如“圖書管理”這個業(yè)務用例，可以分解出多個系統(tǒng)操作。這里要特別注意這些操作，其中很多“活動”都很可能是一個系統(tǒng)用例（當然，并不是每個都是）。如系統(tǒng)中至少包含以下備選系統(tǒng)用例：登錄、注銷登錄、查看圖書列表、修改圖書、刪除圖書。這樣，將每個業(yè)務用例都繪制出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統(tǒng)用例。3.3活動圖活動圖是UML用于對系統(tǒng)的動態(tài)行為建模的另一種常用工具，它描述活動的順序，展現(xiàn)從一個活動到另一個活動的控制流?；顒訄D在本質(zhì)上是一種流程圖?；顒訄D著重表現(xiàn)從一個活動到另一個活動的控制流，是內(nèi)部處理驅(qū)動的流程。3.3.1活動圖的符號UML活動圖中包含的圖形符號有：活動狀態(tài)（Activity）、動作狀態(tài)（Actions）、動作狀態(tài)約束（ActionConstraints）、動作流（ControlFlow）、開始節(jié)點（InitialNode）、終止節(jié)點（FinalNode）、對象（Objects）、數(shù)據(jù)存儲對象（DataStore）、對象流（ObjectFlows）、分支與合并（DecisionandMergeNodes）、分叉與匯合（ForkandJoinNodes）、異常處理（ExceptionHandler）、活動中斷區(qū)域（InterruptibleActivityRegion）和泳道（Partition）。如所示。3.3.2活動圖的基本概念1.動作狀態(tài)動作狀態(tài)是指原子的，不可中斷的動作，并在此動作完成后通過完成轉(zhuǎn)換轉(zhuǎn)向另一個狀態(tài)。動作狀態(tài)特點：⑴動作狀態(tài)是原子的，它是構(gòu)造UML活動圖的最小單位。⑵動作狀態(tài)是不可中斷的。⑶動作狀態(tài)是瞬時的行為。⑷動作狀態(tài)可以有入轉(zhuǎn)換，入轉(zhuǎn)換既可以是動作流，也可以是對象流。⑸動作狀態(tài)與狀態(tài)圖中的狀態(tài)不同，它不能有入口動作和出口動作，更不能有內(nèi)部轉(zhuǎn)移。⑹在一張UML活動圖中，動作狀態(tài)允許多處出現(xiàn)。2.活動狀態(tài)活動圖包含活動狀態(tài)?；顒訝顟B(tài)表示過程中命令的執(zhí)行或工作流程中活動的進行。與等待某一個事件發(fā)生的一般等待狀態(tài)不同，活動狀態(tài)等待計算處理工作的完成。當活動完成后，執(zhí)行流程轉(zhuǎn)入到活動圖中的下一個活動狀態(tài)。當一個活動的前導活動完成時，活動圖中的完成轉(zhuǎn)換被激發(fā)?；顒訝顟B(tài)不是原子的，也就是說它們可以被中斷。可以把活動狀態(tài)看成是一個組合，它的控制流由其他的活動狀態(tài)和動作狀態(tài)組成，如工資報表申報審批可以看做是一個活動狀態(tài)，然后可分解成報表生成，報表提交，報表審批，報表發(fā)布四個動作狀態(tài)?；顒訄D的特點如下：⑴活動狀態(tài)可以分解成其他子活動或者動作狀態(tài)。⑵活動狀態(tài)的內(nèi)部活動可以用另一個UML活動圖來表示。⑶和動作狀態(tài)不同，活動狀態(tài)可以有入口動作和出口動作，也可以有內(nèi)部轉(zhuǎn)移。⑷動作狀態(tài)是活動狀態(tài)的一個特例，如果某個活動狀態(tài)只包括一個動作，那么它就是一個動作狀態(tài)。UML中活動狀態(tài)和動作狀態(tài)的圖標相同，但是活動狀態(tài)可以在圖標中給出入口動作和出口動作等信息。3.分叉控制活動圖可以包含并發(fā)線程的分叉控制。對象在運行時可能會存在兩個或多個并發(fā)運行的控制流，為了對并發(fā)的控制流建模，UML中引入了分叉與匯合的概念。分叉用于將動作流分為兩個或多個并發(fā)運行的分支，而匯合則用于同步這些并發(fā)分支，以達到共同完成一項事務的目的?；顒訄D不僅能夠表達順序流程控制還能夠表達并發(fā)流程控制，如果排除了這一點，活動圖很像一個傳統(tǒng)的流程圖。4.泳道泳道將UML活動圖中的活動劃分為若干組，并把每一組指定給負責這組活動的業(yè)務組織，即對象。在包含泳道的UML活動圖中，每個活動只能明確地屬于一個泳道。泳道是用垂直實線繪出，由于它們的外觀的緣故，這些區(qū)域被稱作泳道。泳道之間的排序并不會影響語義。每個活動狀態(tài)都指派了一條泳道，而轉(zhuǎn)移則可能跨越數(shù)條泳道。5.對象流對象流是動作狀態(tài)或者活動狀態(tài)與對象之間的依賴關系，表示動作使用對象或動作對對象的影響。用UML活動圖描述某個對象時，可以把涉及到的對象放置在UML活動圖中并用一個依賴將其連接到進行創(chuàng)建、修改和撤銷的動作狀態(tài)或者活動狀態(tài)上，對象的這種使用方法就構(gòu)成了對象流。5.對象流對象流中的對象有以下特點：⑴一個對象可以由多個動作操作。⑵一個動作輸出的對象可以作為另一個動作輸入的對象。⑶在UML活動圖中，同一個對象可以多次出現(xiàn)，它的每一次出現(xiàn)表面該對象正處于對象生存期的不同時間點。6．活動的分解一個活動可以分為若干個動作或子活動，這些動作和子活動本身又可以組成一個UML活動圖。不含內(nèi)嵌活動或動作的活動稱之為簡單活動，嵌套了若干活動或動作的活動稱為組合活動。組合活動有自己的名字和相應的子UML活動圖。3.3.3活動圖的構(gòu)建⑴標識需要活動圖的用例。一個系統(tǒng)用例模型包含多幅用例圖，每幅圖又包含多個用例⑵建模每一個用例的主路徑。在創(chuàng)建用例的活動圖時，需要先確定該用例一條明確的執(zhí)行工作流程，建立活動圖的主路徑，然后以該路徑為主線進行補充、擴展和完善。⑶建模每一個用例的從路徑。。⑷添加泳道來標識活動的事務分區(qū)。。⑸改進高層的活動。⑹進一步對細節(jié)進行完善。對前面的活動圖進行補充和完善?；顒訄D的主要應用有：⑴

描述用例的行為。⑵理解工作流程?；顒訄D對理解業(yè)務處理過程十分有用?？梢援嫵雒枋鰳I(yè)務工作流的活動圖與領域?qū)＜疫M行交流，明確業(yè)務處理操作是如何進行的，將會有怎樣的變化。⑶描述復雜過程的算法。在這種情況下使用的活動圖和傳統(tǒng)的程序流程圖的功能是差不多的。UML的活動圖和一般的流程圖是有區(qū)別的。UML活動圖與流程圖的區(qū)別：⑴

流程圖著重描述處理過程，它的主要控制結(jié)構(gòu)是順序、分支和循環(huán)，各個處理過程之間有嚴格的順序和時間關系。而UML活動圖描述的是對象活動的順序關系所遵循的規(guī)則，它著重表現(xiàn)的是系統(tǒng)的行為，而非系統(tǒng)的處理過程。⑵UML活動圖能夠表示并發(fā)活動的情形，而流程圖不能。⑶UML活動圖是面向?qū)ο蟮?，而流程圖是面向過程的。所以兩者的最大區(qū)別在于，活動圖是以OOAD為指導的，是以對象為分析基礎，配合狀態(tài)機圖使用，為的是對用例的執(zhí)行流程進行描述，而并不是以現(xiàn)實中的業(yè)務流程為視角。需求分析規(guī)格說明軟件需求說明（softwarerequirementsspecification，簡稱為SRS）的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎。根據(jù)國標GB/T9385-2008計算機軟件需求規(guī)格說明規(guī)范的要求，軟件需求說明包括以下的內(nèi)容：1.引言1.1目的1.2范圍1.3定義、簡稱、縮略語1.4引用文件1.5綜述需求分析規(guī)格說明2.總體描述2.1產(chǎn)品描述2.2產(chǎn)品功能2.3用戶特點2.4約束2.5假設和依賴關系2.6需求分配3.具體需求3.1外部接口需求3.1.1用戶界面3.1.2硬件接口3.1.3軟件接口3.1.4通信接口3.2類/對象3.2.1類/對象13.2.1.1屬性（直接的3.2.1.2功能3.2.1.3消息3.2.2類/對象23.3性能需求3.4

設計約束3.5

軟件系統(tǒng)屬性3.6其他需求3.5需求分析用例建模案例3.5.1需求陳述“圖書管理信息系統(tǒng)”的用戶需求陳述如下：在圖書流通管理系統(tǒng)中，管理員要為每個讀者建立借閱賬戶，并給讀者發(fā)放不同類別的借閱卡（借閱卡可提供卡號、讀者姓名、類別、單位、職稱等）。持有借閱卡的讀者可以借閱、歸還、預約和續(xù)借圖書，不同類別的讀者可借閱圖書的范圍、數(shù)量和期限不同。讀者來圖書館借書，可能先查詢館中的圖書信息，查詢可以按書名、作者、圖書編號、關鍵字查詢。如果查到則記下書號，交給流通組工作人員，等待辦理借書手續(xù)。如果該書已經(jīng)被全部借出，可做預定登記，等待有書時被通知。如果圖書館沒有該書的記錄，可進行缺書登記。3.5需求分析用例建模案例3.5.1需求陳述辦理借書手續(xù)時要先出示借閱證，借閱圖書時，先輸入讀者的借閱卡號，系統(tǒng)驗證借閱卡的有效性和讀者是否可繼續(xù)借閱圖書。如果借閱卡無效，讓讀者到辦公室進行補辦。如果借書數(shù)量超出規(guī)定，則不繼續(xù)借閱。如果有過期圖書，則需要交納罰款。如果可以借書，則顯示讀者的基本信息（包括照片）供管理員人工核對。借書時系統(tǒng)登記圖書證編號、圖書編號、借出時間和應還書時間。如果是預約圖書，還要修改預約記錄。當讀者還書時，流通組工作人員根據(jù)圖書證編號找到讀者的借書信息，察看是否超期。如果已經(jīng)超期，則進行超期處罰；如果圖書有破損、丟失，則進行破損及丟失等處罰。登記還書信息，做還書處理，同時查看是否有預定登記，如果有則發(fā)出到書通知。3.5需求分析用例建模案例3.5.1需求陳述圖書采購人員采購圖書時，要注意合理采購。如果有缺書登記，則隨時進行采購。采購到貨后，編目人員進行驗收、編目、上架、錄入圖書信息、發(fā)到書通知。圖書館管理人員定期對圖書進行盤庫，如果圖書丟失或舊書淘汰，則將該書從書庫中清除，即圖書注銷。以上是圖書管理系統(tǒng)的基本需求。經(jīng)過與圖書館工作人員反復交流，他們提出了下列建議：a.當借閱的圖書到期時，希望能夠提前用短信或電子郵件方式提示讀者。b.讀者希望能夠?qū)崿F(xiàn)網(wǎng)上查詢和預定圖書。c.應用系統(tǒng)的各種參數(shù)設置最好是靈活的，由系統(tǒng)管理人員根據(jù)需要設定，如借閱期的上限，還書提示的時間，預定圖書的保持時間等參數(shù)。3.5.2需求分析用例建模如下：⑴確定參與者。通過對系統(tǒng)需求陳述的分析，可以確定系統(tǒng)有如下執(zhí)行者：讀者，流通組工作人員，辦公室工作人員，采購員，編目人員。讀者可查詢圖書信息和個人借閱信息，還可以在符合續(xù)借的條件下自己辦理預約及續(xù)借圖書；流通組工作人員完成讀者借書、還書、預約和續(xù)借圖書及罰款等管理工作；辦公室工作人員為讀者辦理借書證有關事宜。采購人員對圖書進行訂購；編目人員進行圖書的編目。⑵確定用例。在確定參與者之后，結(jié)合圖書管理的領域知識，進一步分析系統(tǒng)的需求，識別出的用例有：借書、還書、缺書登記、預約、取消預約、查詢、通知、讀者管理、圖書管理、處罰、采購、編目、圖書催還等。3.5.2需求分析用例建模如下：⑶系統(tǒng)用例的審查與細化。要對系統(tǒng)用例逐一進行審核。用例的審核必須有用戶參與，可以通過用戶訪談和討論會的形式對系統(tǒng)用例進行審核。確定每一個用例實現(xiàn)了用戶的那些需求。是不是用戶的每一個需求都有相應的用例來實現(xiàn)。基本路徑和擴展路徑是否完備，是否存在冗余。⑷確定用例之間的關系。確定參與者和用例之后，進一步確定用例之間的關系。3.5.2需求分析3.5.2需求分析如借閱的用例描述如下：用例名稱：借書用例描述：當讀者前來圖書館借書時，流通組工作人員啟動該用例，該用例檢查讀者的有效性及借閱記錄，檢查圖書是否在庫，實現(xiàn)讀者借書活動。參與者：管理員。前置條件：流通組工作人員要先執(zhí)行登陸用例，才能啟動借書用例。讀者號存在圖書號存在圖書在庫后置條件：記錄了借閱信息3.5.2需求分析如借閱的用例描述如下：圖書庫存減少創(chuàng)建借還書記錄活動的基本過程：1.輸入讀者賬號；2.輸入圖書編號；3.添加一條借書記錄；4.“圖書信息表”中“現(xiàn)有庫存量”-1；5.“讀者信息表”中“已借書數(shù)量”＋1；6.提示執(zhí)行情況；7.修改預約記錄；8.清空讀者、圖書編號等輸入數(shù)據(jù)；重復第2~第