《上海交通大學(xué)計(jì)算機(jī)集成技術(shù)開放實(shí)驗(yàn)室第6講需求分析.ppt》由會員分享，可在線閱讀，更多相關(guān)《上海交通大學(xué)計(jì)算機(jī)集成技術(shù)開放實(shí)驗(yàn)室第6講需求分析.ppt（88頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。
1、2020/7/14,1,第6講 需求分析,,2020/7/14,2,內(nèi)容,需求分析的重要性 需求分析的困難性 需求工程 需求分析過程 概念模型和規(guī)范化 圖形工具 需求驗(yàn)證 原型技術(shù),2020/7/14,3,需求分析,需求分析是軟件定義時(shí)期的最后一個(gè)階段 回答“系統(tǒng)必須做什么？”的問題,2020/7/14,4,需求分析的重要性,,真的很重要嗎？ 例：Our real-time example is based on the embedded software in the Ariane-5, a space rocket belonging to the European Space Agenc
2、y (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was
3、a loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million (Newsbytes home page 1996; Lions et al. 1996).,2020/7/14,5,需求分析的重要性,The reason: there was no discussion in the requirements documents of the ways in which the Ariane-5
4、trajectory would be different from Ariane-4.,統(tǒng)計(jì)資料： In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent of the software projects were canceled before they were completed. M
5、oreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).,2020/7/14,6,需求分析的重要性,2020/7/14,7,需求分析的重要性,5點(diǎn)事實(shí) 軟件生命周期中，一個(gè)錯(cuò)誤發(fā)現(xiàn)得越晚，修復(fù)錯(cuò)誤的費(fèi)用越高,2020/7/14,8,需求分析的重要性,許多錯(cuò)誤是潛伏的，并且在錯(cuò)誤產(chǎn)生后很長一段時(shí)間才被檢查出來 在
6、需求過程中會產(chǎn)生很多錯(cuò)誤 DeMarco在一份研究報(bào)告中指出，被檢查出來的錯(cuò)誤的56產(chǎn)生的根源可以追溯到需求階段。 AIRMICS所進(jìn)行的一項(xiàng)調(diào)查發(fā)現(xiàn)，在一份美國軍方大型管理信息系統(tǒng)的需求現(xiàn)格說明書(SRS)中存在著500多個(gè)錯(cuò)誤，當(dāng)然這僅僅是一個(gè)軟件項(xiàng)目中的一次調(diào)查。 在需求階段，代表性的錯(cuò)誤為疏忽、不一致和二義性 美國海軍研究實(shí)驗(yàn)室從20世紀(jì)70年代起就對軟件開發(fā)技術(shù)不斷地進(jìn)行研究。他們對海軍A7E它機(jī)上的”宅行操作程序進(jìn)行實(shí)地測試，以驗(yàn)證許多新設(shè)想的可行性。得出的研究數(shù)據(jù)表明：A7E項(xiàng)目中77的需求錯(cuò)誤特點(diǎn)是不明確：疏忽、不一致和二義性。按錯(cuò)誤類型對這些錯(cuò)誤分布進(jìn)行分析的結(jié)果是： 49不
7、正確的事實(shí)，31疏忽，l 3不一致，5二義性,2020/7/14,9,需求分析的重要性,需求錯(cuò)誤是可以被檢查出來的,2020/7/14,10,需求分析的重要性,在需求過程中會產(chǎn)生很多錯(cuò)誤(事實(shí)3和4)。 許多錯(cuò)誤并沒有在早期被發(fā)現(xiàn)(事實(shí)2)。 這樣的錯(cuò)誤是能夠在產(chǎn)生的初期被檢查出來的(事實(shí)5)。 如果沒有及時(shí)檢查出來這些錯(cuò)誤，軟件費(fèi)用會直線上升(事實(shí)1),2020/7/14,11,需求管理的困難性,,2020/7/14,12,需求工程,需求是什么?需求就是以一種清晰、簡潔、一致且無二義性的方式，對一個(gè)待開發(fā)系統(tǒng)中各個(gè)有意義方面的陳述的一個(gè)集合。 需求工程一般指應(yīng)用已證實(shí)有效的原理、方法，通過合
8、適的工具和記號，系統(tǒng)地描述出待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束；通常是一些過程的集合：需求獲取(需求引出)、需求分析和編寫軟件規(guī)格說明書(SRS)及驗(yàn)證(包括鑒定和證實(shí))。,2020/7/14,13,需求工程涉及人員,,2020/7/14,14,軟件需求,,功能需求 性能需求 環(huán)境需求 可靠性需求 安全保密要求 用戶界面需求,資源使用需求 成本消耗需求 開發(fā)進(jìn)度需求 預(yù)先估計(jì)以后系統(tǒng)可能達(dá)到的目標(biāo),2020/7/14,15,需求分析與程序分析的不同,2020/7/14,16,需求分析現(xiàn)狀,誤解 交流障礙 缺乏共同語言 “完整性”問題 需求永遠(yuǎn)不會穩(wěn)定 用戶意見不統(tǒng)一 錯(cuò)誤要求 認(rèn)識混淆,2020
9、/7/14,17,需求分析的任務(wù),可行性分析階段已經(jīng)粗略了解了用戶的需求，甚至已經(jīng)提出了一些可行的方案，但是，可行性研究的基本目的是用較小的成本在較短的時(shí)間內(nèi)確定是否存在可行的方案。因此許多細(xì)節(jié)被忽略。 在系統(tǒng)開發(fā)前，還需要進(jìn)一步確定,2020/7/14,18,需求分析的任務(wù),Final stage of Definition phase,仍然回答“What”，而不是“How”， 但更細(xì)致、精確（合同的擬定）,2020/7/14,19,需求分析的任務(wù),完整 準(zhǔn)確 清晰 具體,2020/7/14,20,需求分析的任務(wù),,2020/7/14,21,需求分析的任務(wù),1、確定要求 功能要求(funct
10、ional requirements):系統(tǒng)必須做什么？ 性能要求(performance requirements)：做得怎樣？ 例：response time , memory , back-up memory , security , 運(yùn)行要求(operational requirements) ：運(yùn)行環(huán)境、軟硬件配置等。 未來可能的擴(kuò)充要求(possible evolution)：如3維虛擬現(xiàn)實(shí)的效果等等。,2020/7/14,22,需求分析的任務(wù),,2分析數(shù)據(jù) 建立概念模型(conceptual models): E-R Diagram 形象描繪數(shù)據(jù)結(jié)構(gòu): Data Hierarc
11、hy, Warnier Diagram, IPO 數(shù)據(jù)結(jié)構(gòu)規(guī)范化(Normalization),3、導(dǎo)出邏輯模型： DFD + DD + IPO,4、修正計(jì)劃：重估成本、進(jìn)度等,2020/7/14,23,需求分析的任務(wù),“樣機(jī) 試用”,,C,D,G,5、開發(fā)原型系統(tǒng)(Prototyping),2020/7/14,24,分析過程,軟件系統(tǒng)本質(zhì)上是信息處理系統(tǒng)，任何信息處理系統(tǒng)的基本功能都是把輸入數(shù)據(jù)轉(zhuǎn)變成需要的輸出信息 數(shù)據(jù)是分析的出發(fā)點(diǎn)，在可行性分析階段許多實(shí)際的數(shù)據(jù)元素被忽略了，需求分析階段將定義這些數(shù)據(jù)元素 結(jié)構(gòu)化分析方法就是面向數(shù)據(jù)流自頂向下逐步求精進(jìn)行需求分析的方法,2020/7/1
12、4,25,分析過程,1、沿DFD回溯 （1）DFD的輸出端是系統(tǒng)的最終目的 （2）向回確定每個(gè)數(shù)據(jù)元素的來源 （3）為了得到某個(gè)數(shù)據(jù)元素需要用到數(shù)據(jù)流圖中目前還沒有的數(shù)據(jù)元素，或者得出某個(gè)數(shù)據(jù)元素需要用的算法尚不清楚，可加細(xì)DFD及DD，并將相關(guān)算法記錄在IPO圖中。,2020/7/14,26,分析過程,2、用戶復(fù)查 數(shù)據(jù)字典準(zhǔn)確完整嗎？ 算法正確嗎？ 有沒有遺漏必要的處理或數(shù)據(jù)元素？ 某些數(shù)據(jù)元素是從哪里來的？ 構(gòu)成一個(gè)循環(huán)，認(rèn)識螺旋式上升,2020/7/14,27,分析過程,3、細(xì)化DFD： 加細(xì)前后的IO須相同。 分解到須考慮具體實(shí)現(xiàn)的代碼時(shí)即可仃止,2020/7/14,28,分析過程
13、,,4、修正計(jì)劃 5、文檔：需求規(guī)格說明書,2020/7/14,29,需求分析規(guī)格說明書,2020/7/14,30,需求分析規(guī)格說明書,系統(tǒng)規(guī)格說明： 系統(tǒng)概貌 功能要求 性能要求 運(yùn)行要求 可能增加的要求 DFD IPO, 數(shù)據(jù)要求： DD Hierarchy 或 Warnier Diagram, 用戶系統(tǒng)描述 初步用戶手冊：從用戶的觀點(diǎn)考慮系統(tǒng) 系統(tǒng)功能、性能 使用與步驟 等,修正的開發(fā)計(jì)劃： 成本估計(jì) 資源使用計(jì)劃 進(jìn)度計(jì)劃,2020/7/14,31,需求分析規(guī)格說明書,從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)” 要求使用面向處理的規(guī)格說明語言（或稱
14、系統(tǒng)定義語言） 如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中 規(guī)格說明必須包括系統(tǒng)運(yùn)行環(huán)境 規(guī)格說明必須是一個(gè)認(rèn)識模型 規(guī)格說明必須是可操作的 規(guī)格說明必須容許不完備性并允許擴(kuò)充 規(guī)格說明必須局部化和松散耦合,2020/7/14,32,分析過程,輕松一分鐘 True Tech Support Stories A woman complied with a techs request to send in a copy of a defective diskette. A few days later, the tech received a letter
15、from her along with a xerox copy of the floppy. A tech advised a customer to put his troubled floppy back in the drive and close the door. The customer put his phone down and was heard walking across the room and shutting the door to the room.,2020/7/14,33,分析過程,節(jié)選自目前我國的一些實(shí)際系統(tǒng)中的功能性需求的說明方式：“根據(jù)詳細(xì)的系統(tǒng)調(diào)研和
16、需求分析，系統(tǒng)的功能必須滿足以下需求： 1)編制計(jì)劃、計(jì)劃工程撥款管理，，工程批復(fù)管理，工程進(jìn)度統(tǒng)計(jì)； 2)工程項(xiàng)目管理； 3)計(jì)劃撥款、征費(fèi)收繳信息及其他收撥款信息查詢統(tǒng)計(jì)； 4)路產(chǎn)管理，違章建筑管理，工程材料管理，，超限運(yùn)輸管理； 5)養(yǎng)征信息查詢管理，收費(fèi)站信息管理； 6)文檔管理，會議管理，合同管理，，駕駛員外勤管理，常用管理； 7)養(yǎng)護(hù)信息管理，公路維護(hù)預(yù)警； 8)路況信息管理，交通量信息管理，科研項(xiàng)目信息管理；,2020/7/14,34,需求表達(dá),需求說明語句 保持語句和段落的簡短 采用主動語態(tài)的表達(dá)方式 編寫具有正確的語法和標(biāo)點(diǎn)的完整句子 使用的術(shù)語應(yīng)該和詞匯表中定義的一致 需
17、求陳述應(yīng)該具有一致的式樣，例如“系統(tǒng)必須”，或者“用戶必須”，并緊跟一個(gè)行為動作和可觀察的結(jié)果，例如“倉庫管理子系統(tǒng)必須現(xiàn)實(shí)一張?jiān)谒埱蟮膫}庫中有存貨的藥品名單?！?2020/7/14,35,需求表達(dá),為了減少不確定性，避免采用模糊的、主觀的術(shù)語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術(shù)、優(yōu)越的、可接受的和健壯的。 避免使用比較性的詞匯，例如：提高，最大化，最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數(shù)可接受的最大值和最小值。,2020/7/14,36,需求表達(dá),“產(chǎn)品必須在固定的時(shí)間間隔內(nèi)提供狀態(tài)消息，并且每次時(shí)間間隔不得小于60秒” 后臺任務(wù)管理器應(yīng)該在用戶
18、界面的指定區(qū)域顯示狀態(tài)消息 在后臺任務(wù)進(jìn)程啟動之后，消息必須每隔60（+_10）秒更新一次，并且保持連續(xù)的可見性。 如果正在正常處理后臺任務(wù)進(jìn)程，那么后臺任務(wù)管理器必須顯示后臺任務(wù)進(jìn)程已完成的百分比 當(dāng)完成后臺任務(wù)時(shí)，后臺任務(wù)管理器必須顯示一個(gè)“已完成”的消息。 如果后臺任務(wù)中止執(zhí)行，那么后臺任務(wù)管理器必須顯示一個(gè)出錯(cuò)信息。,2020/7/14,37,需求表達(dá),“產(chǎn)品必須在顯示和隱藏非打印字符之間進(jìn)行瞬間切換” “用戶在編輯文檔時(shí)，通過激活特定的觸發(fā)機(jī)制，可以在顯示和隱藏所有HTML標(biāo)記之間進(jìn)行切換。”,2020/7/14,38,需求表達(dá),“分析程序應(yīng)該能生成HTML標(biāo)記出錯(cuò)的報(bào)告，這樣就可以
19、使HTML的初學(xué)者使用它來迅速排錯(cuò)” 在HTML分析程序完全分析完一個(gè)文件后，該分析程序必須生成一個(gè)出錯(cuò)報(bào)告，這個(gè)報(bào)告中包含了在分析文件中所發(fā)生錯(cuò)誤的HTML所在的行號以及文本內(nèi)容，還包含了對每個(gè)錯(cuò)誤的描述。 如果分析過程中未發(fā)生任何錯(cuò)誤，就不必生成任何錯(cuò)誤報(bào)告,2020/7/14,39,分析過程,第六步 審查和復(fù)審 以上六步構(gòu)成一個(gè)循環(huán),2020/7/14,40,需求分析過程,,2020/7/14,41,概念模型和規(guī)范化,軟件系統(tǒng)開發(fā)過程中必須考慮兩方面的問題 “數(shù)據(jù)”及對數(shù)據(jù)的“處理” 為了把用戶的數(shù)據(jù)要求清晰明確地表達(dá)出來，系統(tǒng)分析員通常建立一個(gè)概念性的數(shù)據(jù)模型（也稱為信息模型）。概念性
20、數(shù)據(jù)模型是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點(diǎn)來對數(shù)據(jù)和信息建模。,2020/7/14,42,概念模型和規(guī)范化,最常用的表示概念性數(shù)據(jù)模型的方法，是實(shí)體聯(lián)系方法（Entity-Relationship Approach） ER圖描述現(xiàn)實(shí)世界中的實(shí)體，而不涉及這些實(shí)體在系統(tǒng)中的實(shí)現(xiàn)方法。,2020/7/14,43,概念模型和規(guī)范化,實(shí)體是客觀世界中存在的且可相互區(qū)分的事務(wù)。實(shí)體可以是人也可以是物，可以是具體的事物也可以是抽象概念。例如，職工、學(xué)生、課程、教師等都是實(shí)體。,2020/7/14,44,概念模型和規(guī)范化,客觀世界中的事物彼此間往往是有聯(lián)系的，例如，教師與課程間存在“教”這種聯(lián)系。,
21、2020/7/14,45,概念模型和規(guī)范化,屬性是實(shí)體或聯(lián)系所具有的性質(zhì)。通常一個(gè)實(shí)體由若干個(gè)屬性來刻畫。 例如，“學(xué)生”實(shí)體有學(xué)號、姓名、性別、系、年級,2020/7/14,46,概念模型和規(guī)范化,例：,2020/7/14,47,概念模型和規(guī)范化,2、范式(Normal Forms)：消除數(shù)據(jù)冗余的程度 IBM E. F. Godd (1970) 例：,*Keyword:可唯一地標(biāo)識一個(gè)元組的屬性,2020/7/14,48,概念模型和規(guī)范化,范式級別越高，存儲同樣數(shù)據(jù)就要分解成更多張表，因此“存儲自身”的過程也就越復(fù)雜 隨著范式級別的提高，數(shù)據(jù)的存儲結(jié)構(gòu)與基于問題域的結(jié)構(gòu)間的匹配程度也隨之
22、下降，因此，在需求變化時(shí)數(shù)據(jù)的穩(wěn)定性較差 范式級別的提高則需要訪問的表增多，性能（速度）將下降,2020/7/14,49,概念模型和規(guī)范化,1 - NF：所有屬性都是原子值，即不出現(xiàn)“表中有表”,2020/7/14,50,概念模型和規(guī)范化,2 - NF：在 1-NF 基礎(chǔ)上，每個(gè)non-key-word都由整個(gè)key word 決定（而非依賴于key word 的一部分）。例：“Major”實(shí)際上由“ID”的第6、7位決定，可省去。,2020/7/14,51,概念模型和規(guī)范化,3 - NF：在 2-NF基礎(chǔ)上，non-key-word之間無從屬關(guān)系。,2020/7/14,52,圖形工具,,1、
23、層次方框圖 (Hierarchy) 描繪數(shù)據(jù)的結(jié)構(gòu) 例：A Room hierarchy based on an interior designers perspective.,2020/7/14,53,圖形工具,2、Warnier Diagram：,2020/7/14,54,圖形工具,3、IPO圖(Input / Process / Output)：簡要的算法描述,1. 校驗(yàn) 主記錄 2. 校驗(yàn) 事務(wù)記錄 3. 更新 主記錄,舊的主文件 事務(wù)文件,有效的 主記錄 有效的 事務(wù)記錄 更新后的 主文件,2020/7/14,55,改進(jìn)的IPO圖,2020/7/14,56,需求驗(yàn)證,方法： 人工審查
24、 初步用戶手冊 Prototyping 使用軟件工具 完整性、一致性,2020/7/14,57,需求驗(yàn)證,例1：Software Requirements Engineering Methodology (SREM) (TRW Corporation, 1977) SREM = Requirements Statement Language (RSL) + Requirements Engineering Validation System (REVS),2020/7/14,58,需求驗(yàn)證,2020/7/14,59,自動化工具,近年來已經(jīng)開發(fā)出一些需求分析工具，它們提供一組程序，
25、幫助分析員制定需求規(guī)格說明。以自動化為主的工具給分析員提供另一種可供選擇的方案。軟件需求能夠用一種規(guī)格說明語言來描述，這種語言把關(guān)鍵字指示符與自然語言(例如英語)描述結(jié)合起來。規(guī)格說明語言被送進(jìn)一個(gè)處理機(jī)，它產(chǎn)生出一份需求規(guī)格說明，更為重要的是，它同時(shí)還產(chǎn)生出一組有關(guān)規(guī)格說明的一致性和組織的診斷報(bào)告。 在過去的10年間，已經(jīng)提出過一些用于制訂需求規(guī)格說明的自動化工具。,2020/7/14,60,自動化工具,,2020/7/14,61,自動化工具,軟件需求工程方法學(xué)(SREM)和問題陳述語言問題陳述分析器(PSLPSA)是有代表性的自動化工具。此外，一些基于知識或形式化方法都需要有自動工具來支持
26、，才能有較好實(shí)用價(jià)值。,2020/7/14,62,自動化工具,軟件需求工程方法學(xué)(SREM) SREM是一種自動化的需求分析工具，它用一種需求陳述語言(RSL)來描述“元素、屬性、關(guān)系和結(jié)構(gòu)”。元素(按照SREM的術(shù)語)包括一組用來制定需求規(guī)格說明的對象和概念。各對象之間的關(guān)系規(guī)定為RSL的一部分，而屬性則用來描述或說明元素，結(jié)構(gòu)用來說明信息流程。這些RSL基本成分與敘述性信息一起構(gòu)成需求規(guī)格說明的細(xì)節(jié)。,2020/7/14,63,自動化工具,問題陳述語言與問題陳述分析PSLPSA PSLPSA是1968年由DTeichroew在密執(zhí)安大學(xué)(Un5versity nf Michigan)提出的
27、。 它是為ISDOS項(xiàng)目而開發(fā)的，又是一個(gè)稱之為計(jì)算機(jī)輔助設(shè)計(jì)與規(guī)格說明分析工具(computeraided design and sPecification analysisto01，CADSAT)的更大的系統(tǒng)的部分。 PSLPSA給分析員提供的功能包括： 一般信息系統(tǒng)的描述，不論其應(yīng)用領(lǐng)域如何。 建立一個(gè)包含用于信息系統(tǒng)的描述符的數(shù)據(jù)庫。 描述符的添加、刪除和修改。 提供格式化的文檔資料和關(guān)于規(guī)格說明的各種報(bào)告。,2020/7/14,64,自動化工具,(1)問題陳述語言(the problem statement language，PSL)。PSL是一種用來描述信息系統(tǒng)的語言。PSL模型的
28、結(jié)構(gòu)由表達(dá)以下內(nèi)容的描述符構(gòu)成：系統(tǒng)信息流、系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)的導(dǎo)出、系統(tǒng)的規(guī)模和容量、系統(tǒng)的動態(tài)特性、系統(tǒng)的性質(zhì)以及項(xiàng)目的管理等。 (2)問題陳述分析(the problem statement analyzer，PSA)。PSA能夠?qū)τ蒔SL描述的問題進(jìn)行分析。使用者對系統(tǒng)建立了一個(gè)完整的PSL描述后，就調(diào)用問題陳述分析器(PSA)對其進(jìn)行分析。PSA將產(chǎn)生一系列報(bào)告。其中包括修改規(guī)格說明數(shù)據(jù)的所有記錄、以各種格式介紹數(shù)據(jù)庫信息的參考報(bào)告、提供研制項(xiàng)目管理信息的小結(jié)報(bào)告和評價(jià)該數(shù)據(jù)庫文件的分析報(bào)告等。,2020/7/14,65,自動化工具,基于知識的途徑 軟件開發(fā)是一種高級智能活動，
29、極富創(chuàng)造性，是知識密集型產(chǎn)業(yè)，需要使用有關(guān)領(lǐng)域的大量知識。因此，引入人工智能技術(shù)，構(gòu)造基于知識的軟件工具或軟件工程環(huán)境是十分必要的。隨著知識工程的進(jìn)步，目前在軟件開發(fā)過程中使用人工智能在技術(shù)上已成為可能。 引入人工智能的原理和技術(shù)，把演進(jìn)型原型的思想進(jìn)一步提高和細(xì)化，可以得出如圖所示的擴(kuò)展的自動程序設(shè)計(jì)范型。這是一個(gè)把用受限自然語言描述的初步需求逐步演進(jìn)成最終的源程序的自動程序設(shè)計(jì)系統(tǒng)的概念模型，是由美國南加州大學(xué)信息科學(xué)研究所首先提出來的。,2020/7/14,66,原型化方法,在開發(fā)初期，要想得到一個(gè)完整準(zhǔn)確的規(guī)格說明不是一件容易的事。特別是對一些大型的軟件項(xiàng)目。 用戶往往對系統(tǒng)只有一個(gè)模
30、糊的想法，很難完全準(zhǔn)確地表達(dá)對系統(tǒng)的全面要求。 軟件開發(fā)者對于所要解決的應(yīng)用問題認(rèn)識更是模糊不清 隨著開發(fā)工作向前推進(jìn)，用戶可能會產(chǎn)生新的要求，或因環(huán)境變化，要求系統(tǒng)也能隨之變化；開發(fā)者又可能在設(shè)計(jì)與實(shí)現(xiàn)的過程中遇到些沒有預(yù)料到的實(shí)際困難，需要以改變需求來解脫困境。 因此規(guī)格說明難以完善、需求的變更、以及通信中的模糊和誤解，都會成為軟件開發(fā)順利推進(jìn)的障礙。 為了解決這些問題，逐漸形成了軟件系統(tǒng)的快速原型的概念。,2020/7/14,67,軟件原型的分類,在軟件開發(fā)中，原型是軟件的一個(gè)早期可運(yùn)行的版本，它反映最終系統(tǒng)的部分重要特性。 探索型：目的是要弄清對目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討
31、多種方案的可行性。 實(shí)驗(yàn)型：這種原型用于大規(guī)模開發(fā)和實(shí)現(xiàn)之前，考核方案是否合適，規(guī)格說明是否可靠。 進(jìn)化型：這種原型的目的不在于改進(jìn)規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進(jìn)原型的過程中，逐步將原型進(jìn)化成最終系統(tǒng)。,2020/7/14,68,建立快速原型好處,增進(jìn)軟件者和用戶對系統(tǒng)服務(wù)需求的理解，使比較含糊的具有不確定性的軟件需求（主要是功能）明確化。 軟件原型化方法提供了一種有力的學(xué)習(xí)手段。 使用原型化方法，可以容易地確定系統(tǒng)的性能，確認(rèn)各項(xiàng)主要系統(tǒng)服務(wù)的可應(yīng)用性，確認(rèn)系統(tǒng)設(shè)計(jì)的可行性，確認(rèn)系統(tǒng)作為產(chǎn)品的結(jié)果。 軟件原型的最終版本，有的可以原封不動地成為產(chǎn)品，有的略加修改就可以成為最終系統(tǒng)的
32、一個(gè)組成部分，這樣有利于建成最終系統(tǒng)。,2020/7/14,69,可執(zhí)行規(guī)格說明 基于腳本(scenario)的設(shè)計(jì) 自動程序設(shè)計(jì) 專用語言 可復(fù)用(reusable)的軟件 簡化假設(shè),原型開發(fā)技術(shù),2020/7/14,70,可執(zhí)行規(guī)格說明,可執(zhí)行規(guī)格說明是用于需求規(guī)格說明的一種自動化技術(shù)。使用這種方法，人們可以直接觀察他們用語言規(guī)定的任何系統(tǒng)性行為。包括 代數(shù)規(guī)格說明 有限狀態(tài)模型 可執(zhí)行的數(shù)據(jù)流圖,,2020/7/14,71,（1）代數(shù)規(guī)格說明,代數(shù)規(guī)格說明使用集合、定義于這些集合上的函數(shù)和定義于這些函數(shù)上的方程來描述對象。規(guī)格說明的操作語義用這些方程表示。 舉例：定義一個(gè)無界的棧及其操作
33、 NEW_STACK： Stack PUSH：Stack，Element Stack POP： Stack (Element | Undefined) POP (NEW_STACK ( ) ) Undefined POP (PUSH ( stk，elem ) ) elem 其中，前三行定義了操作的語法，后兩行把它們的語義定義為一些方程。,2020/7/14,72,（2）有限狀態(tài)模型,parnas提出的使用最廣泛的一種可執(zhí)行規(guī)格說明形式。從一個(gè)初始狀態(tài)開始接收輸入，到產(chǎn)生輸出，狀態(tài)在推移變化。施加在狀態(tài)元素上的約束確定了有效狀態(tài)的推移。 舉例：建立用戶程序?qū)υ?2020/7/14,73,（3）可
34、執(zhí)行的數(shù)據(jù)流圖,數(shù)據(jù)流圖是基于結(jié)構(gòu)化開發(fā)方法的結(jié)構(gòu)化規(guī)格說明 用一種可執(zhí)行的語言程序代替定義處理邏輯的結(jié)構(gòu)化英語，數(shù)據(jù)流圖就成為由可執(zhí)行語言程序模塊組成的網(wǎng)絡(luò)，在一定環(huán)境或工具的支持下就可成為一個(gè)可以執(zhí)行的原型系統(tǒng)。,2020/7/14,74,基于腳本的設(shè)計(jì),腳本是指用戶界面的原型。一個(gè)腳本用以模擬在系統(tǒng)運(yùn)行期間用戶經(jīng)歷的事件。它提供了輸入處理輸出的屏幕格式和有關(guān)對話的模型。因此，軟件開發(fā)者能夠給用戶顯示系統(tǒng)的逼真的視圖，使用戶得以判斷是否符合他的意圖。 可在任一腳本中使用一套可復(fù)用的軟件模塊，以表達(dá)某一方面的要求。 可使用一種原型語言來描述原型系統(tǒng)。原型開發(fā)過程中用這種語言來定義屏幕、數(shù)據(jù)項(xiàng)
35、、及其相關(guān)的操作。從系統(tǒng)的外部描述開始，開發(fā)與數(shù)據(jù)庫的接口、錯(cuò)誤處理和恢復(fù)過程等系統(tǒng)的與外部視圖一致的細(xì)節(jié)。,2020/7/14,75,自動程序設(shè)計(jì),自動程序設(shè)計(jì)是指在程序自動生成環(huán)境的支持下，利用計(jì)算機(jī)實(shí)現(xiàn)軟件的開發(fā)。它可以自動地或半自動地把用戶的非過程式問題規(guī)格說明轉(zhuǎn)換為某種高級語言程序： 演繹綜合手段： 基于數(shù)學(xué)推理的構(gòu)造式證明。 程序變換手段： 將一程序轉(zhuǎn)換成另一功能等價(jià)的程序，并保持其正確性不變。 實(shí)例推廣手段： 從實(shí)例特征出發(fā)，將它推廣為待編程序的特征，最后得到程序。 過程化手段： 研究甚高級語言的編譯和知識的過程化。,2020/7/14,76,專用語言,專用語言是應(yīng)用領(lǐng)域的模型化
36、語言。在原型開發(fā)中使用專用語言，可方便用戶和軟件開發(fā)者在計(jì)劃中的系統(tǒng)特性方面的交流。,2020/7/14,77,軟件復(fù)用技術(shù),利用可復(fù)用的模塊，做出適當(dāng)?shù)慕M合，就可得到快速構(gòu)造的原型系統(tǒng)。 為了快速地構(gòu)造原型，這些模塊首先必須有簡單而清晰的界面；其次它們應(yīng)當(dāng)盡量不依賴其它的模塊或數(shù)據(jù)結(jié)構(gòu)；第三，它們應(yīng)具有一些通用的功能。,2020/7/14,78,簡化假設(shè),簡化假設(shè)是在開發(fā)過程中使設(shè)計(jì)者迅速得到一個(gè)簡化的系統(tǒng)所做的假設(shè)。盡管這些假設(shè)可能實(shí)際上并不能成立，但它們在原型開發(fā)過程中可以使開發(fā)者的注意力集中在一些主要的方面。 在修改一個(gè)文件時(shí)，可以假設(shè)這個(gè)文件確實(shí)存在 在存取文件時(shí)，待存取的記錄總是存
37、在 一旦計(jì)劃中的系統(tǒng)滿足用戶所有的要求，就可以撤消這些假設(shè)，并追加一些細(xì)節(jié)。,2020/7/14,79,系統(tǒng)動態(tài)分析,系統(tǒng)的需求規(guī)格說明通常是用自然語言來敘述的，但是用自然語言描述往往會出現(xiàn)歧義性。 為了直觀地分析系統(tǒng)的動作，從特定的視點(diǎn)出發(fā)描述系統(tǒng)的行為，需要采用動態(tài)分析的方法。 最常用的動態(tài)分析方法 狀態(tài)遷移圖 時(shí)序圖 Petri網(wǎng),2020/7/14,80,狀態(tài)遷移圖,狀態(tài)遷移圖是描述系統(tǒng)的狀態(tài)如何相應(yīng)外部的信號進(jìn)行推移的一種圖形表示。 圓圈“”表示可得到的系統(tǒng)狀態(tài) 箭頭“”表示從一種狀態(tài)向另一種狀態(tài)的遷移。 例如, 當(dāng)有多個(gè)申請占用CPU運(yùn)行的進(jìn)程時(shí), 有關(guān)CPU分配的進(jìn)程的狀態(tài)遷移。
38、,2020/7/14,81,可得到的狀態(tài)就緒，運(yùn)行，等待 生成的事件t1，t2， t3， t4 t1 中斷事件 t2 中斷已處理 t3 分配CPU t4 用完CPU時(shí)間,狀態(tài)遷移圖,2020/7/14,82,狀態(tài)遷移圖的優(yōu)點(diǎn),狀態(tài)之間的關(guān)系能夠直觀地捕捉到 由于狀態(tài)遷移圖的單純性，能夠機(jī)械地分析許多情況，可很容易地建立分析工具,2020/7/14,83,Petri網(wǎng),Petri網(wǎng)已廣泛地應(yīng)用于硬件與軟件系統(tǒng)的開發(fā)中，它適用于描述與分析相互獨(dú)立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。 Petri網(wǎng)簡稱PNG (Petri Net Graph)，它有兩種結(jié)點(diǎn)： 位置(place)：符號為“”，它用來表示系統(tǒng)的狀態(tài)。 轉(zhuǎn)移(transition)：符號為 “”, 它用來表示系統(tǒng)中的事件。 圖中的有向邊表示對轉(zhuǎn)移的輸入，或由轉(zhuǎn)移的輸出,2020/7/14,84,標(biāo)記，或稱令牌(token)，是表明系統(tǒng)當(dāng)前處于什么狀態(tài)的標(biāo)志,Petri網(wǎng),2020/7/14,85,Petri網(wǎng),2020/7/14,86,Petri網(wǎng),2020/7/14,87,處理兩個(gè)進(jìn)程的同步問題,Petri網(wǎng),2020/7/14,88,Petri網(wǎng),
上海交通大學(xué)計(jì)算機(jī)集成技術(shù)開放實(shí)驗(yàn)室第6講需求分析.ppt
