需求建模實(shí)例Agenda什么是需求如何使用UML對需求建模需求建模實(shí)例本章小結(jié)在業(yè)務(wù)需求充分理解并且收集了最為本質(zhì)的用戶需求之后就可以開始需求分析了，并不是等到需求捕獲完全做完之后才開始。分析的目的是為了理解、整理、合并這些需求建模的目的是在理解需求的基礎(chǔ)上，繪制出系統(tǒng)藍(lán)圖，以便統(tǒng)一認(rèn)識。如何使用UML對需求建模用例模型—組織需求用例特性--用例描繪的場景（或事件流）展示了參與者如何使用系統(tǒng)。這都應(yīng)基于系統(tǒng)要完成的任務(wù)及其重要性來決定如何確定主要場景、次要場景，以及需要多少場景。 對于規(guī)模較大的系統(tǒng)用例數(shù)量應(yīng)控制在幾十個；對規(guī)模較小的系統(tǒng)應(yīng)該控制在10個左右。--用例的粒度問題很關(guān)鍵，既不能太大也不能夠太小

用例模型—組織需求用例建模工作流前置條件：需求捕獲活動取得階段性成果主要參與者：分析人員次要參與者：設(shè)計人員、客戶與項目干系人代表輸入：需求捕獲生成的特性列表、業(yè)務(wù)模型或概念模型輸出：用例模型

用例模型—組織需求用例建模工作步驟

--識別參與者：參與者的識別是個迭代的過程 --尋找用例：結(jié)合需求捕獲結(jié)果來考慮各個參與者對系統(tǒng)的需求 --描述參與者和用例的交互方式：導(dǎo)航方向（信號傳遞方向）

--用包來組織用例和參與者（可選）：同一個包的用例與同一個參與者交互，相互之間具有包含或擴(kuò)展關(guān)系

--通過用例圖表示用例模型

--細(xì)化用例模型：編寫用例規(guī)格說明 --評估用例模型：WAVE測試和客戶驗(yàn)證（是否確定所有必要用例；是否確定任何不必要用例；是否按正確順序執(zhí)行各用例的行為；各個用例的事件流是否達(dá)到現(xiàn)階段可能具備的完整性；用例模型的說明是否明白易懂）類模型—概念模型概念模型也稱為領(lǐng)域模型，通常把業(yè)務(wù)建模生成的稱為領(lǐng)域模型，而無專門的業(yè)務(wù)建模生成的稱為概念模型建立概念模型的目的是幫助開發(fā)團(tuán)隊理解問題領(lǐng)域的各種概念、各種名詞、以及它們之間的各種關(guān)系，它的主要表現(xiàn)方式就是類圖在構(gòu)建這個模型時，最主要的工作是找出相關(guān)的類，然后明明類之間的關(guān)聯(lián)關(guān)系，必要時加入一些多重性描述和業(yè)務(wù)規(guī)則約束交互模型—描述事件流文字描述直觀、易懂和便于跟用戶溝通。但具有歧義性和非規(guī)格化，會對開發(fā)工作帶來一定的困擾。在需求階段的交互模型是一個起點(diǎn)，隨著分析和設(shè)計工作的開展，該模型將不斷的精化和修正可借助Robustness分析來推導(dǎo)出交互模型交互模型中一般只包含概念模型中的實(shí)體對象和分析模型中的邊界對象，其目標(biāo)只是幫助分析人員理清整個事件流，而控制對象、設(shè)計類的引入都將在后續(xù)階段進(jìn)行并非一定要為用例模型中的所有用例構(gòu)建交互模型，關(guān)鍵在于“是否需要”可借助狀態(tài)圖表示一些對象狀態(tài)的變遷及用戶界面設(shè)計，還可以借助活動圖來理解活動與活動之間的控制流Agenda什么是需求如何使用UML對需求建模需求建模實(shí)例本章小結(jié)確定業(yè)務(wù)需求確定業(yè)務(wù)需求確定業(yè)務(wù)需求目標(biāo)：為開發(fā)人員提供一個PSP工具，簡化時間記錄工作；同時提供數(shù)據(jù)使用的工具，幫助開發(fā)人提高估算能力。發(fā)起人：總經(jīng)理項目干系人：總經(jīng)理、研發(fā)經(jīng)理、開發(fā)人員對于工程類項目，通過與項目的發(fā)起人、主要的項目干系人來溝通，從根本上理解項目的意義。對于產(chǎn)品類項目，通過詳細(xì)的產(chǎn)品規(guī)劃和市場調(diào)查來確定產(chǎn)品對用戶能夠帶來的利益和好處。確定業(yè)務(wù)需求在業(yè)務(wù)需求指引下挖掘用戶需求的過程由于是內(nèi)部項目，技術(shù)顧問已經(jīng)做了一次關(guān)于PSP的培訓(xùn)配合公司的政策，開發(fā)人員已經(jīng)比較支持這個項目，因此溝通比較順暢。可采用用戶訪談和聯(lián)合開發(fā)的形式進(jìn)行需求捕獲。需求捕獲需求捕獲需求捕獲獲取需求特性表建立概念模型—發(fā)現(xiàn)類建立概念模型—關(guān)聯(lián)分析建立概念模型—職責(zé)分析建議召集一些主要的分析、設(shè)計人員在白板上共同構(gòu)建概念模型。對于規(guī)模比較大的系統(tǒng)，可以先根據(jù)業(yè)務(wù)的關(guān)聯(lián)關(guān)系將其先分解成小的子系統(tǒng)，然后在通過這種流程進(jìn)行建模。主要步驟：識別參與者、合并需求獲得用例、細(xì)化用例描述。用例描述的細(xì)化是隨著開發(fā)過程的推進(jìn)迭代進(jìn)行的。建立用例模型建立用例模型—識別參與者根據(jù)需求特性表識別參與者；檢查參與者之間是否存在關(guān)系建立用例模型—合并特性獲得用例建立用例模型—合并特性獲得用例建立用例模型—繪制用例圖建立用例模型—簡要描述用例建立用例模型—劃分用例優(yōu)先級建立用例模型—詳細(xì)描述用例建立交互模型建立狀態(tài)模型設(shè)計約束：時間記錄程序應(yīng)以離線式工作，該程序會自動連接服務(wù)器，完成時間日志上傳的工作，如果未能連接服務(wù)器，則在本機(jī)暫存時間日志。（可在需求建模時確定，也可以在設(shè)計階段確定）解決方案：將時間日志的上傳與記錄分離，也就是一直都往本地數(shù)據(jù)庫存儲。將上傳日志用例作為另外一個用例來建模。這個用例是“記錄時間日志”的一個擴(kuò)展。處理規(guī)則與約束對于MIS應(yīng)用系統(tǒng)的開發(fā)而言，建議在需求分析階段對用戶界面進(jìn)行必要的設(shè)計，能夠?qū)υO(shè)計階段的工作起到指引作用。通過用戶界面的設(shè)計，能夠更好地與用戶達(dá)成共識，減少理解上的偏差。是對需求建模的一個有益的補(bǔ)充。用戶界面設(shè)計用戶界面設(shè)計Agenda什么是需求如何使用UML對需求建模需求建模實(shí)例本章小結(jié)本章小結(jié)首先闡述了需求的三個層次，解釋了需求工程的任務(wù)，并展開說明了需求捕獲的工作流程闡述了如何通過UML來對需求進(jìn)行建模，包括組織需求的用例模型、建立概念模型的類模型以及描述事件