第三講需求分析與建模

第三講需求分析與建模第一頁，共八十頁，編輯于2023年，星期一內容需求分析概述結構化需求分析方法面向對象需求分析方法第二頁，共八十頁，編輯于2023年，星期一分類篩選合并排序需求分析的過程第三頁，共八十頁，編輯于2023年，星期一需求分析成功的條件乙方正確的

方法論甲方明確的

建設目標第四頁，共八十頁，編輯于2023年，星期一需求分析分析什么？業(yè)務流程優(yōu)化關鍵問題結構化分析法面向對象分析法怎么分析？第五頁，共八十頁，編輯于2023年，星期一系統(tǒng)建模系統(tǒng)模型描述了系統(tǒng)的某個特殊方面，在需求文檔中對自然語言描述的系統(tǒng)需求加入補充信息。系統(tǒng)模型的界定需求規(guī)格說明中應該包含的高層次的模型表示系統(tǒng)運行環(huán)境的模型說明系統(tǒng)如何分解為子系統(tǒng)的體系結構模型系統(tǒng)建模需要注意的事項第六頁，共八十頁，編輯于2023年，星期一需求分析前的工作需求（系統(tǒng)）分析與建模理解真實世界中的問題和用戶的需要并提出滿足這些需要的解決方案的過程。分析前的準備確認系統(tǒng)的參與者確認系統(tǒng)的運行環(huán)境確認系統(tǒng)的約束第七頁，共八十頁，編輯于2023年，星期一內容需求分析概述結構化需求分析方法面向對象需求分析方法第八頁，共八十頁，編輯于2023年，星期一需求分析與建?！Y構化方法結構化方法是一種系統(tǒng)分析和設計的方法，包括定義、開發(fā)和確認系統(tǒng)模型過程中用到的表示法、指南和規(guī)則。功能需求分析與建模方法功能需求說明數據的用途，以及如何記錄、計算、轉換、修改及傳輸數據等。數據需求分析與建模方法數據需求指定系統(tǒng)的存儲數據第九頁，共八十頁，編輯于2023年，星期一

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

SA法也是一種建模的活動，主要是根據軟件內部的數據傳遞、變換關系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。結構化分析方法第十頁，共八十頁，編輯于2023年，星期一

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

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

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

與

+或互斥+第二十八頁，共八十頁，編輯于2023年，星期一顧客出版社驗證訂單匯總訂單訂單圖書目錄文件顧客檔案待處理訂單文件正確訂單一批訂單出版社檔案文件出版社訂單訂貨存根文件舉例：圖書預訂系統(tǒng)畫圖步驟：

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

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

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

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

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

一、結構化語言結構化語言是介于自然語言和形式語言之間的一種半形式語言，它是自然語言的一個受限制的子集。一般分為兩層結構：外層語法較具體，為控制結構（順序、選擇、循環(huán)）,內層較靈活，表達“做什么”。例如：外層可為以下結構：

1、順序結構

2、選擇結構

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

3、循環(huán)結構

WHILE-DO;REPEAT-UNTIL第三十八頁，共八十頁，編輯于2023年，星期一例二“確定能否供貨”的加工邏輯：根據庫存記錄

IF訂單項目的數量<該項目庫存量的臨界值

THEN可供貨處理

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

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

一、結構化語言結構化語言特點:簡單，易學，少二義性。不好處理組合條件。結構化語言舉例第三十九頁，共八十頁，編輯于2023年，星期一判定表是一種二維的表格，常用于較復雜的組合條件（與結構化語言比較），通常由四部分組成。判定表判定表的特點：可處理較復雜的組合條件，但不易理解.不易輸入計算機。條件框—

條件定義。操作框—

操作的定義。條件條目—

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

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

圖b圖aY-滿足條件N-不滿足條件X-選中判定的結論第四十一頁，共八十頁，編輯于2023年，星期一特點:描述一般組合條件較清晰，易理解。不易輸入計算機。好的支付信譽

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

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

<20年

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

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

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

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