第三講需求分析與建模

第三講需求分析與建模第1頁，課件共80頁，創(chuàng)作于2023年2月內(nèi)容需求分析概述結(jié)構(gòu)化需求分析方法面向?qū)ο笮枨蠓治龇椒ǖ?頁，課件共80頁，創(chuàng)作于2023年2月分類篩選合并排序需求分析的過程第3頁，課件共80頁，創(chuàng)作于2023年2月需求分析成功的條件乙方正確的

方法論甲方明確的

建設(shè)目標(biāo)第4頁，課件共80頁，創(chuàng)作于2023年2月需求分析分析什么？業(yè)務(wù)流程優(yōu)化關(guān)鍵問題結(jié)構(gòu)化分析法面向?qū)ο蠓治龇ㄔ趺捶治?？?頁，課件共80頁，創(chuàng)作于2023年2月系統(tǒng)建模系統(tǒng)模型描述了系統(tǒng)的某個特殊方面，在需求文檔中對自然語言描述的系統(tǒng)需求加入補充信息。系統(tǒng)模型的界定需求規(guī)格說明中應(yīng)該包含的高層次的模型表示系統(tǒng)運行環(huán)境的模型說明系統(tǒng)如何分解為子系統(tǒng)的體系結(jié)構(gòu)模型系統(tǒng)建模需要注意的事項第6頁，課件共80頁，創(chuàng)作于2023年2月需求分析前的工作需求（系統(tǒng)）分析與建模理解真實世界中的問題和用戶的需要并提出滿足這些需要的解決方案的過程。分析前的準(zhǔn)備確認(rèn)系統(tǒng)的參與者確認(rèn)系統(tǒng)的運行環(huán)境確認(rèn)系統(tǒng)的約束第7頁，課件共80頁，創(chuàng)作于2023年2月內(nèi)容需求分析概述結(jié)構(gòu)化需求分析方法面向?qū)ο笮枨蠓治龇椒ǖ?頁，課件共80頁，創(chuàng)作于2023年2月需求分析與建?！Y(jié)構(gòu)化方法結(jié)構(gòu)化方法是一種系統(tǒng)分析和設(shè)計的方法，包括定義、開發(fā)和確認(rèn)系統(tǒng)模型過程中用到的表示法、指南和規(guī)則。功能需求分析與建模方法功能需求說明數(shù)據(jù)的用途，以及如何記錄、計算、轉(zhuǎn)換、修改及傳輸數(shù)據(jù)等。數(shù)據(jù)需求分析與建模方法數(shù)據(jù)需求指定系統(tǒng)的存儲數(shù)據(jù)第9頁，課件共80頁，創(chuàng)作于2023年2月

結(jié)構(gòu)化開發(fā)方法（StructuredDevelopingMethod）是現(xiàn)有的軟件開發(fā)方法中最成熟、應(yīng)用最廣泛的方法，主要特點是快速、自然和方便。結(jié)構(gòu)化開發(fā)方法由結(jié)構(gòu)化分析方法（SA法）、結(jié)構(gòu)化設(shè)計方法（SD法）及結(jié)構(gòu)化程序設(shè)計方法（SP法）構(gòu)成的。結(jié)構(gòu)化分析方法是面向數(shù)據(jù)流的需求分析方法，是20世紀(jì)70年代末由Yourdon,Constaintine及DeMarco等人提出和發(fā)展，并得到廣泛的應(yīng)用。它適合于分析大型的數(shù)據(jù)處理系統(tǒng)，特別是企事業(yè)管理系統(tǒng)。

SA法也是一種建模的活動，主要是根據(jù)軟件內(nèi)部的數(shù)據(jù)傳遞、變換關(guān)系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。結(jié)構(gòu)化分析方法第10頁，課件共80頁，創(chuàng)作于2023年2月

分解：對于一個復(fù)雜的系統(tǒng)，為了將復(fù)雜性降低到可以掌握的程度，可以把大問題分解成若干小問題，然后分別解決（如右圖）。

結(jié)構(gòu)化分析方法的基本思想是“分解”和“抽象”。抽象：分解可以分層進行，即先考慮問題最本質(zhì)的屬性，暫把細節(jié)略去,以后再逐層添加細節(jié)，直至涉及到最詳細的內(nèi)容，這種用最本質(zhì)的屬性表示一個系統(tǒng)的方法就是“抽象”。1.11.21.3x2132.12.22.31.11.3SA法的基本思想第11頁，課件共80頁，創(chuàng)作于2023年2月需求分析的方法繪制系統(tǒng)關(guān)聯(lián)圖創(chuàng)建用戶接口原型分析需求可行性確定需求的優(yōu)先級別為需求建立模型（模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖）創(chuàng)建數(shù)據(jù)字典使用質(zhì)量功能調(diào)配第12頁，課件共80頁，創(chuàng)作于2023年2月需求分析方法（細節(jié)）采用SRS模板指明需求的來源為每項需求注上標(biāo)號記錄業(yè)務(wù)規(guī)范創(chuàng)建需求跟蹤能力矩陣審查需求文檔以需求為依據(jù)編寫測試用例編寫用戶手冊確定合格的標(biāo)準(zhǔn)。

第13頁，課件共80頁，創(chuàng)作于2023年2月分析1:定義系統(tǒng)的邊界評估原始需求，定義將要開發(fā)的計算機系統(tǒng)的邊界。確定哪些是系統(tǒng)需求哪些是和系統(tǒng)相關(guān)的操作過程的需求哪些在系統(tǒng)范圍之外的需求原則第14頁，課件共80頁，創(chuàng)作于2023年2月分析2:系統(tǒng)環(huán)境建模環(huán)境模型是系統(tǒng)將要使用的語境模型，應(yīng)該是最先開發(fā)的系統(tǒng)模型之一。效益：記錄必須說明接口的外部系統(tǒng)模型包括：和正在說明的系統(tǒng)直接交互的其他系統(tǒng)其他有可能和本系統(tǒng)共存并發(fā)生交互的系統(tǒng)系統(tǒng)所在的業(yè)務(wù)過程（定義涉及的行為、它們的輸入和輸出、負(fù)責(zé)這些過程的人以及支持這些過程的軟件）第15頁，課件共80頁，創(chuàng)作于2023年2月系統(tǒng)環(huán)境建模-上下文圖作用：上下文圖能很好地概括產(chǎn)品的必要接口，初步確新產(chǎn)品包含了哪些內(nèi)容，產(chǎn)品之外又包含哪些內(nèi)容。即說明產(chǎn)品及其環(huán)境的圖示說明產(chǎn)品的范圍優(yōu)點：上下文圖為開發(fā)人員概括了所有的接口，在開發(fā)中或開發(fā)后，方便地驗證是否已處理了所有接口用戶能不費力地理解上下文圖，并發(fā)現(xiàn)遺漏的接口。第16頁，課件共80頁，創(chuàng)作于2023年2月系統(tǒng)環(huán)境建模案例郵件傳閱系統(tǒng)環(huán)境建模企業(yè)OA辦公系統(tǒng)圖書管理系統(tǒng)操作管理員一般工作人員第17頁，課件共80頁，創(chuàng)作于2023年2月分析3:系統(tǒng)體系結(jié)構(gòu)建模效益體系結(jié)構(gòu)模型有助于劃分系統(tǒng)需求體系結(jié)構(gòu)模型說明了系統(tǒng)功能的概況體系結(jié)構(gòu)模型有助于需求工程師找出那些涉及多個子系統(tǒng)的需求體系結(jié)構(gòu)模型描述方式-方框圖第18頁，課件共80頁，創(chuàng)作于2023年2月系統(tǒng)體系結(jié)構(gòu)“標(biāo)準(zhǔn)”模式客戶機-服務(wù)器通用服務(wù)器提供共享的系統(tǒng)功能分層系統(tǒng)系統(tǒng)功能通過調(diào)用更低層次所提供的功能來實現(xiàn)基于庫的系統(tǒng)子系統(tǒng)通過一個共享庫進行通信管道系統(tǒng)系統(tǒng)中的每個部件都進行一定的計算，并將結(jié)果傳給其他部件以進行進一步的操作第19頁，課件共80頁，創(chuàng)作于2023年2月體系結(jié)構(gòu)建模舉例第20頁，課件共80頁，創(chuàng)作于2023年2月分析4:開發(fā)互補的系統(tǒng)建?；パa的系統(tǒng)模型可以解釋系統(tǒng)規(guī)格說明的不同方面。系統(tǒng)模型用來表達系統(tǒng)規(guī)格說明的行為視圖或者結(jié)構(gòu)視圖。系統(tǒng)模型的例子數(shù)據(jù)處理模型組合模型分類模型刺激-響應(yīng)模型過程模型第21頁，課件共80頁，創(chuàng)作于2023年2月分析5:事件列表與功能列表事件就是要求系統(tǒng)執(zhí)行某項功能的請求業(yè)務(wù)事件與產(chǎn)品事件對復(fù)雜的業(yè)務(wù)任務(wù)采用任務(wù)說明、用例說明或數(shù)據(jù)流圖等方法進行解釋。對復(fù)雜的功能采用數(shù)據(jù)流圖、算法描述、活動圖、數(shù)學(xué)說明等進行解釋第22頁，課件共80頁，創(chuàng)作于2023年2月事件列表與功能列表(續(xù))事件及功能列表的優(yōu)點主要作為核對清單，以說明應(yīng)開發(fā)什么。而其中對這些功能的詳細說明構(gòu)成了功能需求的主要部分開發(fā)人員可以方便的檢查產(chǎn)品是否實現(xiàn)每一個功能用戶能夠在某種程度上確認(rèn)業(yè)務(wù)事件和任務(wù)列表通過一致性檢查確定列表是否完備第23頁，課件共80頁，創(chuàng)作于2023年2月功能需求舉例-活動圖第24頁，課件共80頁，創(chuàng)作于2023年2月分析6:數(shù)據(jù)需求數(shù)據(jù)模型數(shù)據(jù)流圖（狀態(tài)圖、活動圖）數(shù)據(jù)字典虛擬窗口（原型界面）第25頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)需求—數(shù)據(jù)模型數(shù)據(jù)模型說明了系統(tǒng)所要存儲的數(shù)據(jù)以及數(shù)據(jù)之間的關(guān)系提供了對數(shù)據(jù)的高級“體系結(jié)構(gòu)”視圖，也可以描述信息的細節(jié)。模型：E-R模型、概念模型數(shù)據(jù)模型的優(yōu)缺點第26頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)需求—數(shù)據(jù)模型第27頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)流圖數(shù)據(jù)流圖（DataFlowDiagram，DFD）是描述系統(tǒng)中數(shù)據(jù)流程的圖形工具，它標(biāo)識了一個系統(tǒng)的邏輯輸入和邏輯輸出，以及把邏輯輸入轉(zhuǎn)換為邏輯輸出所需的加工處理。數(shù)據(jù)存儲數(shù)據(jù)源點或終點加工加工名數(shù)據(jù)流數(shù)據(jù)流名文件名實體名箭頭圓或橢圓單或雙杠矩形框還有一些輔助的圖例:一、數(shù)據(jù)流圖的圖符四種基本圖形符號：TAB*CTAB*CTAB+CTAB+CTABC+TABC+*

與

+或互斥+第28頁，課件共80頁，創(chuàng)作于2023年2月顧客出版社驗證訂單匯總訂單訂單圖書目錄文件顧客檔案待處理訂單文件正確訂單一批訂單出版社檔案文件出版社訂單訂貨存根文件舉例：圖書預(yù)訂系統(tǒng)畫圖步驟：

1、確定外部實體（顧客、出版社）及輸入、輸出數(shù)據(jù)流（訂單、出版社訂單）。

2、確定分解頂層的加工（驗證訂單、匯總訂單）。

3、確定使用的文件（圖書目錄文件、顧客檔案等5個文件）。

4、用數(shù)據(jù)流將各部分連接起來，形成數(shù)據(jù)封閉。加工和文件還有其他一些圖例：加工加工名編號加工名編號文件名文件名文件注意：標(biāo)注各加工框及數(shù)據(jù)流名稱。第29頁，課件共80頁，創(chuàng)作于2023年2月經(jīng)過初步的需求分析，得到系統(tǒng)功能要求：1、監(jiān)視病員的病癥（血壓、體溫、脈搏等）。2、定時更新病歷。3、病員出現(xiàn)異常情況時報警。4、隨機地產(chǎn)生某一病員的病情報告。實例：醫(yī)院病房監(jiān)護系統(tǒng)產(chǎn)生病情報告監(jiān)視病情更新病歷第30頁，課件共80頁，創(chuàng)作于2023年2月監(jiān)護系統(tǒng)分層DFD圖病員護士護士病員監(jiān)護系統(tǒng)病員日志病癥信號要求報告病癥報告報警頂層醫(yī)院病房監(jiān)護系統(tǒng)分層DFD圖頂層確定了系統(tǒng)的范圍，其外部實體為病員和護士。護士病員護士醫(yī)院病房監(jiān)護系統(tǒng)頂層第31頁，課件共80頁，創(chuàng)作于2023年2月

監(jiān)護系統(tǒng)分層DFD圖計算超過極限值否病員數(shù)據(jù)超過極限值報警開解信號產(chǎn)生報警信息病員極限格式化病員數(shù)據(jù)體溫血壓、體溫、脈搏生理信號極限值時間脈搏血壓日期時鐘格式化病員數(shù)據(jù)3.13.23.33.4第二層：加工“中央監(jiān)視”分解醫(yī)院病房監(jiān)護系統(tǒng)分層DFD圖第一層格式化病員數(shù)據(jù)生理信號極限值病員護士護士中央監(jiān)視病員日志病癥信號要求報告病癥報告報警局部監(jiān)視生成報告病員極限更新日志病員數(shù)據(jù)1324日志數(shù)據(jù)第一層分解為局部監(jiān)視、生成報告、中央監(jiān)視、更新日志4個加工。這層的分解是關(guān)鍵。以4個加工中最重要的加工“中央監(jiān)視”為例，進行第二層分解。第32頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)流圖的用處系統(tǒng)分析員用這種工具可以自頂向下分析系統(tǒng)信息流程；可在圖上劃出需要計算機處理的部分和需要修改的部分；根據(jù)邏輯存儲，進一步作數(shù)據(jù)分析，向數(shù)據(jù)庫數(shù)據(jù)過渡；根據(jù)數(shù)據(jù)流向，定出存取方式；對應(yīng)一個處理過程，用相應(yīng)的語言，判定表等工具來表達處理方法。第33頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)需求—數(shù)據(jù)字典數(shù)據(jù)字典是一個系統(tǒng)組織的、敘述性的數(shù)據(jù)說明效益保證名字使用的一致性，避免名字重復(fù)使用和誤解。有助于提高系統(tǒng)需求、設(shè)計和實現(xiàn)維護過程中的可跟蹤性。第34頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)需求—數(shù)據(jù)字典（續(xù)）數(shù)據(jù)字典應(yīng)具有的信息模型中的實體的名字名字的別名或其它變體命名的實體類型命名實體和為何將它引入系統(tǒng)模型的描述對于命名實體的約束指向相關(guān)實體的聯(lián)接第35頁，課件共80頁，創(chuàng)作于2023年2月分層數(shù)據(jù)流圖只是表達了系統(tǒng)的“分解”，為了完整地描述這個系統(tǒng)，還需借助“數(shù)據(jù)詞典”(datadictionary)和“小說明”對圖中的每個數(shù)據(jù)和加工給出解釋。對數(shù)據(jù)流圖中包含的所有元素的定義的集合構(gòu)成了數(shù)據(jù)詞典。它有四類條目：數(shù)據(jù)流、數(shù)據(jù)項、文件及基本加工。在定義數(shù)據(jù)流或文件時，使用表2-1給出的符號。將這些條目按照一定的規(guī)則組織起來，構(gòu)成數(shù)據(jù)詞典。數(shù)據(jù)詞典（DD）表2-1X=1??8表示X可取1到8中的任意一個值連接符??X=“a”表示X是取值為字符a的數(shù)據(jù)元素基本數(shù)據(jù)元素“???”X=(a)表示a可在X中出現(xiàn)，也可不出現(xiàn)可選(???)X=2{a}6或x={a}表示重復(fù)2~5次a重復(fù)m{???}n或{???}X={a}表示X由0個或多個a組成重復(fù){???}X=[a|b]表示X由a或b組成或[???|???]X=a+b表示X由a和b組成與+被定義為=例及說明含義符號Nm62第36頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)流條目給出了DFD圖中數(shù)據(jù)流的定義，通常列出該數(shù)據(jù)流的各組成數(shù)據(jù)項。例如，數(shù)據(jù)流“乘客名單”由若干“乘客姓名”、“單位名”和“等級”組成，則詞典中的“乘客名單”條目是：乘客名單＝{乘客姓名＋單位名＋等級}又如，報名單＝姓名＋單位名＋年齡＋性別＋課程名數(shù)據(jù)詞典類型加工條目加工條目就是“加工小說明”。一般應(yīng)單獨列出。數(shù)據(jù)項條目給出某個數(shù)據(jù)單項的定義，通常是該數(shù)據(jù)項的值類型、允許值等。例如：賬號=00000~99999；存款期=[1|3|5]（單位：年）文件條目給出某個文件的定義，文件的定義通常是列出文件記錄的組成數(shù)據(jù)流。例如，某銷售系統(tǒng)的訂單文件：訂單文件＝訂單編號＋顧客名稱＋產(chǎn)品名稱＋訂貨數(shù)量＋交貨日期第37頁，課件共80頁，創(chuàng)作于2023年2月加工邏輯說明對數(shù)據(jù)流圖中每一個不能再分解的基本加工都必須有一個加工小說明給出這個加工的精確描述。小說明中應(yīng)精確地描述加工的激發(fā)條件、加工邏輯、優(yōu)先級、執(zhí)行頻率和出錯處理等。加工邏輯是其中最基本的部分，是指用戶對這個加工的邏輯要求。對基本加工說明有三種描述方式：結(jié)構(gòu)化語言，判定表，判定樹。一、結(jié)構(gòu)化語言結(jié)構(gòu)化語言是介于自然語言和形式語言之間的一種半形式語言，它是自然語言的一個受限制的子集。一般分為兩層結(jié)構(gòu)：外層語法較具體，為控制結(jié)構(gòu)（順序、選擇、循環(huán)）,內(nèi)層較靈活，表達“做什么”。例如：外層可為以下結(jié)構(gòu)：

1、順序結(jié)構(gòu)

2、選擇結(jié)構(gòu)

IF–THEN-ELSE;CASE-OF-ENDCASE；

3、循環(huán)結(jié)構(gòu)

WHILE-DO;REPEAT-UNTIL第38頁，課件共80頁，創(chuàng)作于2023年2月例二

“確定能否供貨”的加工邏輯：根據(jù)庫存記錄

IF訂單項目的數(shù)量<該項目庫存量的臨界值

THEN可供貨處理

ELSE此訂單缺貨，登錄，待進貨后再處理

ENDIF例一根據(jù)當(dāng)前流動資金值確定貶值數(shù)。IFtheCurrent–Capital–Valueislessthen$1000ThenSetDepreciated–AmounttoCurrent–Capital–Value.SetCurrent–Capital–Valuetozero.OtherwiseSetDepreciated–Amountto10%ofCurrent–Capital–Value.ReduceCurrent–Capital-Valueby10%.

一、結(jié)構(gòu)化語言結(jié)構(gòu)化語言特點:簡單，易學(xué)，少二義性。不好處理組合條件。結(jié)構(gòu)化語言舉例第39頁，課件共80頁，創(chuàng)作于2023年2月判定表是一種二維的表格，常用于較復(fù)雜的組合條件（與結(jié)構(gòu)化語言比較），通常由四部分組成。判定表判定表的特點：可處理較復(fù)雜的組合條件，但不易理解.不易輸入計算機。條件框—

條件定義。操作框—

操作的定義。條件條目—

各條件的取值及組合。操作條目—

在各條件取值組合下所執(zhí)行的操作。條件框條件條目操作框操作條目例如:對商店每天的營業(yè)額所收稅率營業(yè)額X（￥）1000≤X<50005000≤X<10000X≥10000稅率5%8%10%第40頁，課件共80頁，創(chuàng)作于2023年2月例：一圖書銷售系統(tǒng)，其中一加工為“優(yōu)先處理”，條件是：顧客的營業(yè)額大于1000元，同時必須信譽好，或者雖然信譽不好，但是20年以上的老主顧。判定表應(yīng)用舉例分析：共有3個判定條件，有8種可能的組合情況（圖a）。對圖a進行化簡后，得到圖b?；喓?/p>

圖b圖aY-滿足條件N-不滿足條件X-選中判定的結(jié)論第41頁，課件共80頁，創(chuàng)作于2023年2月特點:描述一般組合條件較清晰，易理解。不易輸入計算機。好的支付信譽

優(yōu)惠處理壞的支付信譽營業(yè)額>1000元≤1000元正常處理

>20年優(yōu)惠處理

<20年

正常處理如上例判定樹第42頁，課件共80頁，創(chuàng)作于2023年2月數(shù)據(jù)需求—虛擬窗口虛擬窗口是理想化的屏幕圖像，形同真實的屏幕圖像，但不具備功能或菜單。虛擬窗口的目的。虛擬窗口的優(yōu)缺點。第43頁，課件共80頁，創(chuàng)作于2023年2月需求分級關(guān)注最重要的需求劃分優(yōu)先級可以幫助項目相關(guān)人員判斷系統(tǒng)的核心需求需求優(yōu)先級之間明顯的關(guān)聯(lián)可以幫助設(shè)計者決定系統(tǒng)體系結(jié)構(gòu)，還可以幫助解決可能發(fā)生的設(shè)計沖突第44頁，課件共80頁，創(chuàng)作于2023年2月使用多維方法進行需求分級效益需求分級是發(fā)現(xiàn)需求之間的共性和例外關(guān)系的依據(jù)。有助于發(fā)現(xiàn)需求重疊和沖突。需求分級提高需求文檔的跟蹤能力需求分級可以幫助你找到遺漏的需求實施需求分級最簡單的方法就是使用刻面方法。定義一系列的維度或者說是刻面，并用相應(yīng)的關(guān)鍵詞描述它們。第45頁，課件共80頁，創(chuàng)作于2023年2月評估需求風(fēng)險對每一項需求或者一系列相關(guān)的需求進行風(fēng)險分析，指出在實現(xiàn)需求過程中可能會發(fā)生的問題、這些問題發(fā)生的機率及其影響。第46頁，課件共80頁，創(chuàng)作于2023年2月內(nèi)容需求分析概述結(jié)構(gòu)化需求分析方法面向?qū)ο笮枨蠓治龇椒ǖ?7頁，課件共80頁，創(chuàng)作于2023年2月采用面向?qū)ο蠓治鼋Ｊ紫仁敲枋鲂枨?其次根據(jù)需求建立系統(tǒng)的靜態(tài)模型,以構(gòu)造系統(tǒng)的結(jié)構(gòu);第三步是描述系統(tǒng)的行為。其中在第一步與第二步中所建立的模型都是靜態(tài)的,包括用例圖、類圖(包含包)、對象圖、組件圖和配置圖等五個圖形,是標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機制。第48頁，課件共80頁，創(chuàng)作于2023年2月采用面向?qū)ο蠓治鼋?續(xù)其中第三步中所建立的模型或者可以執(zhí)行,或者表示執(zhí)行時的時序狀態(tài)或交互關(guān)系。它包括狀態(tài)圖、活動圖、順序圖和合作圖等四個圖形,是標(biāo)準(zhǔn)建模語言UML的動態(tài)建模機制。第49頁，課件共80頁，創(chuàng)作于2023年2月OO分析師與設(shè)計師的任務(wù)找出參與者和用例詳述用例組織用例模型（注意：用例僅能獲取功能需求）需求工程師任務(wù)找出功能性需求找出非功能性需求優(yōu)先排序需求跟蹤用例和需求第50頁，課件共80頁，創(chuàng)作于2023年2月用例過程描述用例第51頁，課件共80頁，創(chuàng)作于2023年2月用例建?；顒拥妮敵鲇美；顒拥妮敵鍪怯美Ｐ驮撃Ｐ途哂兴膫€部分：參與者-人們所扮演的角色或者使用系統(tǒng)的事物；用例-參與者與系統(tǒng)交互的物件；關(guān)系-參與者和用例之間有意義的聯(lián)系；系統(tǒng)邊界-包圍用例的方框，說明正在建模系統(tǒng)的邊界第52頁，課件共80頁，創(chuàng)作于2023年2月關(guān)于”用例”的誤解用例模型就是指”UML用例圖”用例模型包括用例圖和用例描述用例分析技術(shù)是一項分解技術(shù).用例分析技術(shù)是一項合成技術(shù)第53頁，課件共80頁，創(chuàng)作于2023年2月用例是什么?用例實例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成特定參與者可見的價值結(jié)果特點用例實例也就是“使用場景”用例應(yīng)該給參與者帶來可見的價值用例是在系統(tǒng)中第54頁，課件共80頁，創(chuàng)作于2023年2月典型的用例建模活動找出系統(tǒng)邊界識別參與者合并需求找出用例詳述用例第55頁，課件共80頁，創(chuàng)作于2023年2月用例建?！页鱿到y(tǒng)邊界系統(tǒng)邊界是定義由誰或什么（即參與者）使用系統(tǒng)，系統(tǒng)能夠為哪些參與者提供什么特定的利益（即用例）第56頁，課件共80頁，創(chuàng)作于2023年2月用例建?！獏⑴c者參與者是直接與系統(tǒng)交互的事物所扮演的角色。參與者角色人其它系統(tǒng)硬件系統(tǒng)時鐘第57頁，課件共80頁，創(chuàng)作于2023年2月如何識別參與者誰或什么使用該系統(tǒng)？交互中，它們扮演什么角色？誰安裝系統(tǒng)？誰啟動和關(guān)閉系統(tǒng)？誰維護系統(tǒng)？與該系統(tǒng)交互的是其它什么系統(tǒng)？誰從該系統(tǒng)獲取信息，誰提供信息給系統(tǒng)？有什么事情發(fā)生在固定時間？第58頁，課件共80頁，創(chuàng)作于2023年2月在識別參與者需要注意的！參與者對于系統(tǒng)而言總是外部的；參與者直接同系統(tǒng)交互；參與者表示人和事物同系統(tǒng)發(fā)生交互時所扮演的角色，而不是特定的人和特定的事物；一個人或事物在與系統(tǒng)發(fā)生交互時，同時或不同時扮演多種角色；每個參與者需要一個具有業(yè)務(wù)意義的簡短名稱；每個參與者必須有簡短描述，它從業(yè)務(wù)角度描述參與者是什么。像類一樣，參與者可以具有分欄，表示參與者屬性和它可能接收的事件；第59頁，課件共80頁，創(chuàng)作于2023年2月用例建?！美美x為“系統(tǒng)、子系統(tǒng)或類能夠與外部參與者交互所執(zhí)行的動作序列，包括各種序列以及出錯序列的規(guī)格說明。用例是參與者想要系統(tǒng)做的事情。第60頁，課件共80頁，創(chuàng)作于2023年2月識別用例特定參與者希望系統(tǒng)提供什么功能？系統(tǒng)存儲和檢索信息嗎？如果有，哪個參與者觸發(fā)這個行為？當(dāng)系統(tǒng)改變狀態(tài)時，通知參與者嗎？存在影響系統(tǒng)的外部時間嗎？是誰通知系統(tǒng)這些事件的？第61頁，課件共80頁，創(chuàng)作于2023年2月用例圖郵件訂閱系統(tǒng)PlaceOrderCancelOrderCheckOrderStatusSendCatalogShipProductCustomerDispatcherShippingCompany第62頁，課件共80頁，創(chuàng)作于2023年2月詳述用例用例模型補充需求項目詞匯表用例詳述用例用例闡述員第63頁，課件共80頁，創(chuàng)作于2023年2月在編寫事件流需要注意的！使用簡單的語法：主語明確，語義易于理解;明確寫出“誰控制球”從俯視的角度來編寫顯示過程向前推移顯示參與者的意圖而非動作包括“合理的活動集”（帶數(shù)據(jù)的請求、系統(tǒng)確認(rèn)、更改內(nèi)部、返回結(jié)果）用“確認(rèn)”而非“檢查是否”可選擇地提及時間限制第64頁，課件共80頁，創(chuàng)作于2023年2月用例技術(shù)的優(yōu)點用例相對容易寫用例是用用戶的語言寫的用例為行為或場景提供相關(guān)線索，用戶和開發(fā)人員都能夠理解用例的圖形表示提高對復(fù)雜軟件系統(tǒng)的可理解性用例描述的場景在確認(rèn)階段幾乎可以直接用作測試腳本第65頁，課件共80頁，創(chuàng)作于2023年2月用例方法的適用場合適用場合系統(tǒng)是面向功能的，具有多種類型的用戶和功能行為團隊采用UML和面向?qū)ο螅∣O）方法實現(xiàn)系統(tǒng)不太適用場合系統(tǒng)用戶很少或沒有并且接口也很少系統(tǒng)中非功能性需求和設(shè)計約束占主導(dǎo)地位第66頁，課件共80頁，創(chuàng)作于2023年2月用例建模實戰(zhàn)-調(diào)研后的功能特性FEAT01.新增學(xué)生信息FEAT02.修改已有的學(xué)生信息FEAT03.學(xué)生信息按統(tǒng)招生、工程碩士、學(xué)位進修分別建檔FEAT04.錄入新生信息時能夠自動按規(guī)則生成學(xué)生號號FEAT05.統(tǒng)招生、工程碩士與學(xué)位進修生采用不同的書號規(guī)則FEAT06.錄入新生信息時如果重名將自動提示FEAT07.按入學(xué)時間、所在學(xué)院、學(xué)生類別等關(guān)鍵字組合查詢學(xué)生信息FEAT08.列出所有學(xué)生信息FEAT09.記錄學(xué)生休學(xué)、退學(xué)、轉(zhuǎn)學(xué)和留級情況FEAT10.學(xué)生狀態(tài)能夠自動反應(yīng)在學(xué)生信息中FEAT11.按姓名、學(xué)號查詢學(xué)生成績情況、交費情況、獎懲情況FEAT12.列出所有的獲得獎懲情況學(xué)生名單及所在學(xué)院FEAT13.按特定時間段統(tǒng)計學(xué)生學(xué)習(xí)成績和學(xué)分FEAT14.所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨對統(tǒng)招生、工程碩士、學(xué)位進修類別進行；也可以按照學(xué)院進行第67頁，課件共80頁，創(chuàng)作于2023年2月學(xué)生老師用例建模實戰(zhàn)-識別參與者第68頁，課件共80頁，創(chuàng)作于2023年2月特征用例用例FEAT01.新增學(xué)生信息UC01.新增學(xué)生信息FEAT03.學(xué)生信息按統(tǒng)招生、工程碩士、學(xué)位進修分別建檔FEAT04.錄入新生信息時能夠自動按規(guī)則生成學(xué)生號號FEAT05.統(tǒng)招生、工程碩士與學(xué)位進修生采用不同的書號規(guī)則FEAT06.錄入新生信息時如果重名將自動提示FEAT02.修改已有的學(xué)生信息UC02.修改學(xué)生信息FEAT07.按入學(xué)時間、所在學(xué)院、學(xué)生類別等關(guān)鍵字組合查詢學(xué)生信息UC03.查詢學(xué)生信息FEAT08.列出所有學(xué)生信息FEAT14.所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨對統(tǒng)招生、工程碩士、學(xué)位進修類別進行；也可以按照學(xué)院進行FEAT09.記錄學(xué)生休學(xué)、退學(xué)、轉(zhuǎn)學(xué)和留級情況UC04.改變學(xué)生狀態(tài)FEAT10.學(xué)生狀態(tài)能夠自動反應(yīng)在學(xué)生信息中FEAT11.按姓名、學(xué)號查詢學(xué)生成績情況、交費情況、獎懲情況UC05.查詢學(xué)生狀態(tài)信息FEAT12.列出所有的獲得獎懲情況學(xué)生名單及所在學(xué)院FEAT14.所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨對統(tǒng)招生、工程碩士、學(xué)位進修類別進行；也可以按照學(xué)院進行FEAT13.按特定時間段統(tǒng)計學(xué)生學(xué)習(xí)成績和學(xué)分UC056.統(tǒng)計學(xué)生成績FEAT14.所有查詢、列表、統(tǒng)計功能應(yīng)可以單獨對統(tǒng)招生、工程碩士、學(xué)位進修類別進行；也可以按照學(xué)院進行用例建模實戰(zhàn)-合并需求獲得用例第69頁，課件共80頁，創(chuàng)作于2023年2月用例建模實戰(zhàn)-繪制用例圖郵件訂閱系統(tǒng)新增學(xué)生信息修改學(xué)生信息查詢學(xué)生信息改變學(xué)生狀態(tài)查詢學(xué)生狀態(tài)teacherstudent統(tǒng)計學(xué)生成績第70頁，課件共80頁，創(chuàng)作于2023年2月1）用例名稱：應(yīng)該與用例圖相符，并寫上其相應(yīng)的編號；2）簡要說明：該用例對參與者所傳遞的價值結(jié)果進行描述。3）前置條件：是執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)4）后置條件：用例執(zhí)行完畢系統(tǒng)可能處于的一組狀態(tài)。5）擴展點：如果包括擴展或包含用例，則寫出擴展或包含用例名，并說明在什么情況下使用。如果有，則應(yīng)該在編寫事件流的同時進行編寫。6）優(yōu)先級:說明用戶對該用例的期望值，可以為今后開發(fā)時制定先后順序。用例建模實戰(zhàn)-細化用例描述第71頁，課件共80頁，創(chuàng)作于2023年2月用例建模實戰(zhàn)-用例粒度思辨“四輪馬車”如何整理用例的層次第72頁，課件共80頁，創(chuàng)作于2023年2月把建立原型系統(tǒng)作為一種可能采取的策略的主要理由：由于人類認(rèn)識能力的局限，不能預(yù)先指定所有要求。在用戶和系統(tǒng)分析員之間存在固有的交流鴻溝。用戶需要一個“活的”系統(tǒng)模型，以便獲得實踐經(jīng)驗。在開發(fā)過程中重復(fù)和反復(fù)是必要的和不可避免的。目前有快速建立原型系統(tǒng)的工具可供選用。由于成本的增加，過去很少采用樣機策略。但是，由于正確地提出用戶需求是軟件開發(fā)工程成功的基礎(chǔ)，近來主張采用樣機策略的人也多起來。原型需求分析第73頁，課件共80頁，創(chuàng)作于2023年2月按照傳統(tǒng)的瀑布模型進行軟件開發(fā)，由于將軟件開發(fā)這樣一個充滿回朔的過程硬性地割裂開，雖然強調(diào)各個階段的復(fù)審，而用戶所提出的需求往往是模糊的，因此很難得到一個完整精確的規(guī)格說明，直接影響到后期的開發(fā)，針對其主要缺點推出了原型化方法。2.3原型化方法什么是原型化方法（PrototypingMethod）

？原型是軟件開發(fā)過程中，軟件的一個早期可運行的版本，它反映了最終系統(tǒng)的部分重要特性。原型化方法的基本思想是花費少量代價建立一個可運行的系統(tǒng)，使用戶及早獲得學(xué)習(xí)的機會，原型化方法又稱速成原型法（RapidPrototyping），強調(diào)的是軟件開發(fā)人員與用戶的不斷交互，通過原型的演進不斷適應(yīng)用戶任務(wù)改變的需求。將維護和修改階段的工作盡早進行，使用戶驗收提前，從而使軟件產(chǎn)品更加適用。第74頁，課件共80頁，創(chuàng)作于2023年2月由于軟件項目的特點和運行原型的目的不同，原型有兩種不同的類型。軟件原型的分類

2、追加（addon）型也稱為快速建立漸進原型RCP法（RapidCyclicPrototyping）法采用循環(huán)漸進的開發(fā)方式，對系統(tǒng)模型作連續(xù)精化，即先構(gòu)造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，作為最終系統(tǒng)的核心，將系統(tǒng)需要具備的性質(zhì)逐步添加上去，通過不斷地擴充修改，逐步追加新的要求，直至所有性質(zhì)全部滿足，此時的原型模型也就是最終的產(chǎn)品。

1、廢棄（throwaway）型也稱為快速建立需求規(guī)格原型RSP法（RapidSpecific