第三講需求分析與建模_第1頁(yè)
第三講需求分析與建模_第2頁(yè)
第三講需求分析與建模_第3頁(yè)
第三講需求分析與建模_第4頁(yè)
第三講需求分析與建模_第5頁(yè)
已閱讀5頁(yè),還剩75頁(yè)未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

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

方法論甲方明確的

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

結(jié)構(gòu)化開發(fā)方法(StructuredDevelopingMethod)是現(xiàn)有的軟件開發(fā)方法中最成熟、應(yīng)用最廣泛的方法,主要特點(diǎn)是快速、自然和方便。結(jié)構(gòu)化開發(fā)方法由結(jié)構(gòu)化分析方法(SA法)、結(jié)構(gòu)化設(shè)計(jì)方法(SD法)及結(jié)構(gòu)化程序設(shè)計(jì)方法(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法也是一種建模的活動(dòng),主要是根據(jù)軟件內(nèi)部的數(shù)據(jù)傳遞、變換關(guān)系,自頂向下逐層分解,描繪出滿足功能要求的軟件模型。結(jié)構(gòu)化分析方法第10頁(yè),共80頁(yè),2023年,2月20日,星期一

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

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

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

+或互斥+第28頁(yè),共80頁(yè),2023年,2月20日,星期一顧客出版社驗(yàn)證訂單匯總訂單訂單圖書目錄文件顧客檔案待處理訂單文件正確訂單一批訂單出版社檔案文件出版社訂單訂貨存根文件舉例:圖書預(yù)訂系統(tǒng)畫圖步驟:

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

2、確定分解頂層的加工(驗(yàn)證訂單、匯總訂單)。

3、確定使用的文件(圖書目錄文件、顧客檔案等5個(gè)文件)。

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

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

一、結(jié)構(gòu)化語(yǔ)言結(jié)構(gòu)化語(yǔ)言是介于自然語(yǔ)言和形式語(yǔ)言之間的一種半形式語(yǔ)言,它是自然語(yǔ)言的一個(gè)受限制的子集。一般分為兩層結(jié)構(gòu):外層語(yǔ)法較具體,為控制結(jié)構(gòu)(順序、選擇、循環(huán)),內(nèi)層較靈活,表達(dá)“做什么”。例如:外層可為以下結(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頁(yè),共80頁(yè),2023年,2月20日,星期一例二

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

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

THEN可供貨處理

ELSE此訂單缺貨,登錄,待進(jìn)貨后再處理

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

一、結(jié)構(gòu)化語(yǔ)言結(jié)構(gòu)化語(yǔ)言特點(diǎn):簡(jiǎn)單,易學(xué),少二義性。不好處理組合條件。結(jié)構(gòu)化語(yǔ)言舉例第39頁(yè),共80頁(yè),2023年,2月20日,星期一判定表是一種二維的表格,常用于較復(fù)雜的組合條件(與結(jié)構(gòu)化語(yǔ)言比較),通常由四部分組成。判定表判定表的特點(diǎn):可處理較復(fù)雜的組合條件,但不易理解.不易輸入計(jì)算機(jī)。條件框—

條件定義。操作框—

操作的定義。條件條目—

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

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

圖b圖aY-滿足條件N-不滿足條件X-選中判定的結(jié)論第41頁(yè),共80頁(yè),2023年,2月20日,星期一特點(diǎn):描述一般組合條件較清晰,易理解。不易輸入計(jì)算機(jī)。好的支付信譽(yù)

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

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

<20年

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

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

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

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

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論