《上海交通大學(xué)計(jì)算機(jī)集成技術(shù)開(kāi)放實(shí)驗(yàn)室第6講需求分析.ppt》由會(huì)員分享，可在線(xiàn)閱讀，更多相關(guān)《上海交通大學(xué)計(jì)算機(jī)集成技術(shù)開(kāi)放實(shí)驗(yàn)室第6講需求分析.ppt（88頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。
1、2020/7/14,1,第6講 需求分析,2020/7/14,2,內(nèi)容,需求分析的重要性 需求分析的困難性 需求工程 需求分析過(guò)程 概念模型和規(guī)范化 圖形工具 需求驗(yàn)證 原型技術(shù),2020/7/14,3,需求分析,需求分析是軟件定義時(shí)期的最后一個(gè)階段 回答“系統(tǒng)必須做什么？”的問(wèn)題,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 Agency
2、(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 a
3、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 tr
4、ajectory 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. More
5、over, 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)生后很長(zhǎng)一段時(shí)間才被檢查出來(lái) 在需求過(guò)
6、程中會(huì)產(chǎn)生很多錯(cuò)誤 DeMarco在一份研究報(bào)告中指出，被檢查出來(lái)的錯(cuò)誤的56產(chǎn)生的根源可以追溯到需求階段。 AIRMICS所進(jìn)行的一項(xiàng)調(diào)查發(fā)現(xiàn)，在一份美國(guó)軍方大型管理信息系統(tǒng)的需求現(xiàn)格說(shuō)明書(shū)(SRS)中存在著500多個(gè)錯(cuò)誤，當(dāng)然這僅僅是一個(gè)軟件項(xiàng)目中的一次調(diào)查。 在需求階段，代表性的錯(cuò)誤為疏忽、不一致和二義性 美國(guó)海軍研究實(shí)驗(yàn)室從20世紀(jì)70年代起就對(duì)軟件開(kāi)發(fā)技術(shù)不斷地進(jìn)行研究。他們對(duì)海軍A7E它機(jī)上的”宅行操作程序進(jìn)行實(shí)地測(cè)試，以驗(yàn)證許多新設(shè)想的可行性。得出的研究數(shù)據(jù)表明：A7E項(xiàng)目中77的需求錯(cuò)誤特點(diǎn)是不明確：疏忽、不一致和二義性。按錯(cuò)誤類(lèi)型對(duì)這些錯(cuò)誤分布進(jìn)行分析的結(jié)果是： 49不正確的
7、事實(shí)，31疏忽，l 3不一致，5二義性,2020/7/14,9,需求分析的重要性,需求錯(cuò)誤是可以被檢查出來(lái)的,2020/7/14,10,需求分析的重要性,在需求過(guò)程中會(huì)產(chǎn)生很多錯(cuò)誤(事實(shí)3和4)。 許多錯(cuò)誤并沒(méi)有在早期被發(fā)現(xiàn)(事實(shí)2)。 這樣的錯(cuò)誤是能夠在產(chǎn)生的初期被檢查出來(lái)的(事實(shí)5)。 如果沒(méi)有及時(shí)檢查出來(lái)這些錯(cuò)誤，軟件費(fèi)用會(huì)直線(xiàn)上升(事實(shí)1),2020/7/14,11,需求管理的困難性,2020/7/14,12,需求工程,需求是什么?需求就是以一種清晰、簡(jiǎn)潔、一致且無(wú)二義性的方式，對(duì)一個(gè)待開(kāi)發(fā)系統(tǒng)中各個(gè)有意義方面的陳述的一個(gè)集合。 需求工程一般指應(yīng)用已證實(shí)有效的原理、方法，通過(guò)合適的工具
8、和記號(hào)，系統(tǒng)地描述出待開(kāi)發(fā)系統(tǒng)及其行為特征和相關(guān)約束；通常是一些過(guò)程的集合：需求獲取(需求引出)、需求分析和編寫(xiě)軟件規(guī)格說(shuō)明書(shū)(SRS)及驗(yàn)證(包括鑒定和證實(shí))。,2020/7/14,13,需求工程涉及人員,2020/7/14,14,軟件需求,功能需求 性能需求 環(huán)境需求 可靠性需求 安全保密要求 用戶(hù)界面需求,資源使用需求 成本消耗需求 開(kāi)發(fā)進(jìn)度需求 預(yù)先估計(jì)以后系統(tǒng)可能達(dá)到的目標(biāo),2020/7/14,15,需求分析與程序分析的不同,2020/7/14,16,需求分析現(xiàn)狀,誤解 交流障礙 缺乏共同語(yǔ)言 “完整性”問(wèn)題 需求永遠(yuǎn)不會(huì)穩(wěn)定 用戶(hù)意見(jiàn)不統(tǒng)一 錯(cuò)誤要求 認(rèn)識(shí)混淆,2020/7/14,
9、17,需求分析的任務(wù),可行性分析階段已經(jīng)粗略了解了用戶(hù)的需求，甚至已經(jīng)提出了一些可行的方案，但是，可行性研究的基本目的是用較小的成本在較短的時(shí)間內(nèi)確定是否存在可行的方案。因此許多細(xì)節(jié)被忽略。 在系統(tǒng)開(kāi)發(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、確定要求 功能要求(functional r
10、equirements):系統(tǒng)必須做什么？ 性能要求(performance requirements)：做得怎樣？ 例：response time , memory , back-up memory , security , 運(yùn)行要求(operational requirements) ：運(yùn)行環(huán)境、軟硬件配置等。 未來(lái)可能的擴(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 Hierarchy, Warni
11、er 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、開(kāi)發(fā)原型系統(tǒng)(Prototyping),2020/7/14,24,分析過(guò)程,軟件系統(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/14,25,分析過(guò)程,1
12、、沿DFD回溯 （1）DFD的輸出端是系統(tǒng)的最終目的 （2）向回確定每個(gè)數(shù)據(jù)元素的來(lái)源 （3）為了得到某個(gè)數(shù)據(jù)元素需要用到數(shù)據(jù)流圖中目前還沒(méi)有的數(shù)據(jù)元素，或者得出某個(gè)數(shù)據(jù)元素需要用的算法尚不清楚，可加細(xì)DFD及DD，并將相關(guān)算法記錄在IPO圖中。,2020/7/14,26,分析過(guò)程,2、用戶(hù)復(fù)查 數(shù)據(jù)字典準(zhǔn)確完整嗎？ 算法正確嗎？ 有沒(méi)有遺漏必要的處理或數(shù)據(jù)元素？ 某些數(shù)據(jù)元素是從哪里來(lái)的？ 構(gòu)成一個(gè)循環(huán)，認(rèn)識(shí)螺旋式上升,2020/7/14,27,分析過(guò)程,3、細(xì)化DFD： 加細(xì)前后的IO須相同。 分解到須考慮具體實(shí)現(xiàn)的代碼時(shí)即可仃止,2020/7/14,28,分析過(guò)程,4、修正計(jì)劃 5、文檔
13、：需求規(guī)格說(shuō)明書(shū),2020/7/14,29,需求分析規(guī)格說(shuō)明書(shū),2020/7/14,30,需求分析規(guī)格說(shuō)明書(shū),系統(tǒng)規(guī)格說(shuō)明： 系統(tǒng)概貌 功能要求 性能要求 運(yùn)行要求 可能增加的要求 DFD IPO, 數(shù)據(jù)要求： DD Hierarchy 或 Warnier Diagram, 用戶(hù)系統(tǒng)描述 初步用戶(hù)手冊(cè)：從用戶(hù)的觀點(diǎn)考慮系統(tǒng) 系統(tǒng)功能、性能 使用與步驟 等,修正的開(kāi)發(fā)計(jì)劃： 成本估計(jì) 資源使用計(jì)劃 進(jìn)度計(jì)劃,2020/7/14,31,需求分析規(guī)格說(shuō)明書(shū),從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)” 要求使用面向處理的規(guī)格說(shuō)明語(yǔ)言（或稱(chēng)系統(tǒng)定義語(yǔ)言） 如果被開(kāi)發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)
14、元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說(shuō)明的描述之中 規(guī)格說(shuō)明必須包括系統(tǒng)運(yùn)行環(huán)境 規(guī)格說(shuō)明必須是一個(gè)認(rèn)識(shí)模型 規(guī)格說(shuō)明必須是可操作的 規(guī)格說(shuō)明必須容許不完備性并允許擴(kuò)充 規(guī)格說(shuō)明必須局部化和松散耦合,2020/7/14,32,分析過(guò)程,輕松一分鐘 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 from her along with a xero
15、x 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,分析過(guò)程,節(jié)選自目前我國(guó)的一些實(shí)際系統(tǒng)中的功能性需求的說(shuō)明方式：“根據(jù)詳細(xì)的系統(tǒng)調(diào)研和需求分析，系統(tǒng)的功能必須滿(mǎn)足以下需求： 1)編制計(jì)劃
16、、計(jì)劃工程撥款管理，工程批復(fù)管理，工程進(jìn)度統(tǒng)計(jì)； 2)工程項(xiàng)目管理； 3)計(jì)劃撥款、征費(fèi)收繳信息及其他收撥款信息查詢(xún)統(tǒng)計(jì)； 4)路產(chǎn)管理，違章建筑管理，工程材料管理，超限運(yùn)輸管理； 5)養(yǎng)征信息查詢(xún)管理，收費(fèi)站信息管理； 6)文檔管理，會(huì)議管理，合同管理，駕駛員外勤管理，常用管理； 7)養(yǎng)護(hù)信息管理，公路維護(hù)預(yù)警； 8)路況信息管理，交通量信息管理，科研項(xiàng)目信息管理；,2020/7/14,34,需求表達(dá),需求說(shuō)明語(yǔ)句 保持語(yǔ)句和段落的簡(jiǎn)短 采用主動(dòng)語(yǔ)態(tài)的表達(dá)方式 編寫(xiě)具有正確的語(yǔ)法和標(biāo)點(diǎn)的完整句子 使用的術(shù)語(yǔ)應(yīng)該和詞匯表中定義的一致 需求陳述應(yīng)該具有一致的式樣，例如“系統(tǒng)必須”，或者“用戶(hù)必須
17、”，并緊跟一個(gè)行為動(dòng)作和可觀察的結(jié)果，例如“倉(cāng)庫(kù)管理子系統(tǒng)必須現(xiàn)實(shí)一張?jiān)谒?qǐng)求的倉(cāng)庫(kù)中有存貨的藥品名單。”,2020/7/14,35,需求表達(dá),為了減少不確定性，避免采用模糊的、主觀的術(shù)語(yǔ)，例如，用戶(hù)友好、容易、簡(jiǎn)單、迅速、有效、支持、許多、最新技術(shù)、優(yōu)越的、可接受的和健壯的。 避免使用比較性的詞匯，例如：提高，最大化，最小化和最佳化。定量地說(shuō)明所需要提高的程度或者說(shuō)清一些參數(shù)可接受的最大值和最小值。,2020/7/14,36,需求表達(dá),“產(chǎn)品必須在固定的時(shí)間間隔內(nèi)提供狀態(tài)消息，并且每次時(shí)間間隔不得小于60秒” 后臺(tái)任務(wù)管理器應(yīng)該在用戶(hù)界面的指定區(qū)域顯示狀態(tài)消息 在后臺(tái)任務(wù)進(jìn)程啟動(dòng)之后，消息必
18、須每隔60（+_10）秒更新一次，并且保持連續(xù)的可見(jiàn)性。 如果正在正常處理后臺(tái)任務(wù)進(jìn)程，那么后臺(tái)任務(wù)管理器必須顯示后臺(tái)任務(wù)進(jìn)程已完成的百分比 當(dāng)完成后臺(tái)任務(wù)時(shí)，后臺(tái)任務(wù)管理器必須顯示一個(gè)“已完成”的消息。 如果后臺(tái)任務(wù)中止執(zhí)行，那么后臺(tái)任務(wù)管理器必須顯示一個(gè)出錯(cuò)信息。,2020/7/14,37,需求表達(dá),“產(chǎn)品必須在顯示和隱藏非打印字符之間進(jìn)行瞬間切換” “用戶(hù)在編輯文檔時(shí)，通過(guò)激活特定的觸發(fā)機(jī)制，可以在顯示和隱藏所有HTML標(biāo)記之間進(jìn)行切換?！?2020/7/14,38,需求表達(dá),“分析程序應(yīng)該能生成HTML標(biāo)記出錯(cuò)的報(bào)告，這樣就可以使HTML的初學(xué)者使用它來(lái)迅速排錯(cuò)” 在HTML分析程序完
19、全分析完一個(gè)文件后，該分析程序必須生成一個(gè)出錯(cuò)報(bào)告，這個(gè)報(bào)告中包含了在分析文件中所發(fā)生錯(cuò)誤的HTML所在的行號(hào)以及文本內(nèi)容，還包含了對(duì)每個(gè)錯(cuò)誤的描述。 如果分析過(guò)程中未發(fā)生任何錯(cuò)誤，就不必生成任何錯(cuò)誤報(bào)告,2020/7/14,39,分析過(guò)程,第六步 審查和復(fù)審 以上六步構(gòu)成一個(gè)循環(huán),2020/7/14,40,需求分析過(guò)程,2020/7/14,41,概念模型和規(guī)范化,軟件系統(tǒng)開(kāi)發(fā)過(guò)程中必須考慮兩方面的問(wèn)題 “數(shù)據(jù)”及對(duì)數(shù)據(jù)的“處理” 為了把用戶(hù)的數(shù)據(jù)要求清晰明確地表達(dá)出來(lái)，系統(tǒng)分析員通常建立一個(gè)概念性的數(shù)據(jù)模型（也稱(chēng)為信息模型）。概念性數(shù)據(jù)模型是一種面向問(wèn)題的數(shù)據(jù)模型，是按照用戶(hù)的觀點(diǎn)來(lái)對(duì)數(shù)據(jù)和
20、信息建模。,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)系。,2020/7/14,45,概念模型和規(guī)范化,屬性是實(shí)體或聯(lián)系
21、所具有的性質(zhì)。通常一個(gè)實(shí)體由若干個(gè)屬性來(lái)刻畫(huà)。 例如，“學(xué)生”實(shí)體有學(xué)號(hào)、姓名、性別、系、年級(jí),2020/7/14,46,概念模型和規(guī)范化,例：,2020/7/14,47,概念模型和規(guī)范化,2、范式(Normal Forms)：消除數(shù)據(jù)冗余的程度 IBM E. F. Godd (1970) 例：,*Keyword:可唯一地標(biāo)識(shí)一個(gè)元組的屬性,2020/7/14,48,概念模型和規(guī)范化,范式級(jí)別越高，存儲(chǔ)同樣數(shù)據(jù)就要分解成更多張表，因此“存儲(chǔ)自身”的過(guò)程也就越復(fù)雜 隨著范式級(jí)別的提高，數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)與基于問(wèn)題域的結(jié)構(gòu)間的匹配程度也隨之下降，因此，在需求變化時(shí)數(shù)據(jù)的穩(wěn)定性較差 范式級(jí)別的提高則需要
22、訪(fǎng)問(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 決定（而非依賴(lài)于key word 的一部分）。例：“Major”實(shí)際上由“ID”的第6、7位決定，可省去。,2020/7/14,51,概念模型和規(guī)范化,3 - NF：在 2-NF基礎(chǔ)上，non-key-word之間無(wú)從屬關(guān)系。,2020/7/14,52,圖形工具,1、層次方框圖 (Hierarchy) 描繪數(shù)據(jù)的結(jié)構(gòu) 例：A Ro
23、om hierarchy based on an interior designers perspective.,2020/7/14,53,圖形工具,2、Warnier Diagram：,2020/7/14,54,圖形工具,3、IPO圖(Input / Process / Output)：簡(jiǎn)要的算法描述,1. 校驗(yàn) 主記錄 2. 校驗(yàn) 事務(wù)記錄 3. 更新 主記錄,舊的主文件 事務(wù)文件,有效的 主記錄 有效的 事務(wù)記錄 更新后的 主文件,2020/7/14,55,改進(jìn)的IPO圖,2020/7/14,56,需求驗(yàn)證,方法： 人工審查 初步用戶(hù)手冊(cè) Prototyping 使用軟件工具 完整性、一
24、致性,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,自動(dòng)化工具,近年來(lái)已經(jīng)開(kāi)發(fā)出一些需求分析工具，它們提供一組程序，幫助分析員制定需求規(guī)格說(shuō)明。以自動(dòng)化為主的工具給分析員提供另一種可供選擇的方案
25、。軟件需求能夠用一種規(guī)格說(shuō)明語(yǔ)言來(lái)描述，這種語(yǔ)言把關(guān)鍵字指示符與自然語(yǔ)言(例如英語(yǔ))描述結(jié)合起來(lái)。規(guī)格說(shuō)明語(yǔ)言被送進(jìn)一個(gè)處理機(jī)，它產(chǎn)生出一份需求規(guī)格說(shuō)明，更為重要的是，它同時(shí)還產(chǎn)生出一組有關(guān)規(guī)格說(shuō)明的一致性和組織的診斷報(bào)告。 在過(guò)去的10年間，已經(jīng)提出過(guò)一些用于制訂需求規(guī)格說(shuō)明的自動(dòng)化工具。,2020/7/14,60,自動(dòng)化工具,2020/7/14,61,自動(dòng)化工具,軟件需求工程方法學(xué)(SREM)和問(wèn)題陳述語(yǔ)言問(wèn)題陳述分析器(PSLPSA)是有代表性的自動(dòng)化工具。此外，一些基于知識(shí)或形式化方法都需要有自動(dòng)工具來(lái)支持，才能有較好實(shí)用價(jià)值。,2020/7/14,62,自動(dòng)化工具,軟件需求工程方法學(xué)
26、(SREM) SREM是一種自動(dòng)化的需求分析工具，它用一種需求陳述語(yǔ)言(RSL)來(lái)描述“元素、屬性、關(guān)系和結(jié)構(gòu)”。元素(按照SREM的術(shù)語(yǔ))包括一組用來(lái)制定需求規(guī)格說(shuō)明的對(duì)象和概念。各對(duì)象之間的關(guān)系規(guī)定為RSL的一部分，而屬性則用來(lái)描述或說(shuō)明元素，結(jié)構(gòu)用來(lái)說(shuō)明信息流程。這些RSL基本成分與敘述性信息一起構(gòu)成需求規(guī)格說(shuō)明的細(xì)節(jié)。,2020/7/14,63,自動(dòng)化工具,問(wèn)題陳述語(yǔ)言與問(wèn)題陳述分析PSLPSA PSLPSA是1968年由DTeichroew在密執(zhí)安大學(xué)(Un5versity nf Michigan)提出的。 它是為ISDOS項(xiàng)目而開(kāi)發(fā)的，又是一個(gè)稱(chēng)之為計(jì)算機(jī)輔助設(shè)計(jì)與規(guī)格說(shuō)明分析工具
27、(computeraided design and sPecification analysisto01，CADSAT)的更大的系統(tǒng)的部分。 PSLPSA給分析員提供的功能包括： 一般信息系統(tǒng)的描述，不論其應(yīng)用領(lǐng)域如何。 建立一個(gè)包含用于信息系統(tǒng)的描述符的數(shù)據(jù)庫(kù)。 描述符的添加、刪除和修改。 提供格式化的文檔資料和關(guān)于規(guī)格說(shuō)明的各種報(bào)告。,2020/7/14,64,自動(dòng)化工具,(1)問(wèn)題陳述語(yǔ)言(the problem statement language，PSL)。PSL是一種用來(lái)描述信息系統(tǒng)的語(yǔ)言。PSL模型的結(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)
28、的規(guī)模和容量、系統(tǒng)的動(dòng)態(tài)特性、系統(tǒng)的性質(zhì)以及項(xiàng)目的管理等。 (2)問(wèn)題陳述分析(the problem statement analyzer，PSA)。PSA能夠?qū)τ蒔SL描述的問(wèn)題進(jìn)行分析。使用者對(duì)系統(tǒng)建立了一個(gè)完整的PSL描述后，就調(diào)用問(wèn)題陳述分析器(PSA)對(duì)其進(jìn)行分析。PSA將產(chǎn)生一系列報(bào)告。其中包括修改規(guī)格說(shuō)明數(shù)據(jù)的所有記錄、以各種格式介紹數(shù)據(jù)庫(kù)信息的參考報(bào)告、提供研制項(xiàng)目管理信息的小結(jié)報(bào)告和評(píng)價(jià)該數(shù)據(jù)庫(kù)文件的分析報(bào)告等。,2020/7/14,65,自動(dòng)化工具,基于知識(shí)的途徑 軟件開(kāi)發(fā)是一種高級(jí)智能活動(dòng)，極富創(chuàng)造性，是知識(shí)密集型產(chǎn)業(yè)，需要使用有關(guān)領(lǐng)域的大量知識(shí)。因此，引入人工智能技術(shù)
29、，構(gòu)造基于知識(shí)的軟件工具或軟件工程環(huán)境是十分必要的。隨著知識(shí)工程的進(jìn)步，目前在軟件開(kāi)發(fā)過(guò)程中使用人工智能在技術(shù)上已成為可能。 引入人工智能的原理和技術(shù)，把演進(jìn)型原型的思想進(jìn)一步提高和細(xì)化，可以得出如圖所示的擴(kuò)展的自動(dòng)程序設(shè)計(jì)范型。這是一個(gè)把用受限自然語(yǔ)言描述的初步需求逐步演進(jìn)成最終的源程序的自動(dòng)程序設(shè)計(jì)系統(tǒng)的概念模型，是由美國(guó)南加州大學(xué)信息科學(xué)研究所首先提出來(lái)的。,2020/7/14,66,原型化方法,在開(kāi)發(fā)初期，要想得到一個(gè)完整準(zhǔn)確的規(guī)格說(shuō)明不是一件容易的事。特別是對(duì)一些大型的軟件項(xiàng)目。 用戶(hù)往往對(duì)系統(tǒng)只有一個(gè)模糊的想法，很難完全準(zhǔn)確地表達(dá)對(duì)系統(tǒng)的全面要求。 軟件開(kāi)發(fā)者對(duì)于所要解決的應(yīng)用問(wèn)題
30、認(rèn)識(shí)更是模糊不清 隨著開(kāi)發(fā)工作向前推進(jìn)，用戶(hù)可能會(huì)產(chǎn)生新的要求，或因環(huán)境變化，要求系統(tǒng)也能隨之變化；開(kāi)發(fā)者又可能在設(shè)計(jì)與實(shí)現(xiàn)的過(guò)程中遇到些沒(méi)有預(yù)料到的實(shí)際困難，需要以改變需求來(lái)解脫困境。 因此規(guī)格說(shuō)明難以完善、需求的變更、以及通信中的模糊和誤解，都會(huì)成為軟件開(kāi)發(fā)順利推進(jìn)的障礙。 為了解決這些問(wèn)題，逐漸形成了軟件系統(tǒng)的快速原型的概念。,2020/7/14,67,軟件原型的分類(lèi),在軟件開(kāi)發(fā)中，原型是軟件的一個(gè)早期可運(yùn)行的版本，它反映最終系統(tǒng)的部分重要特性。 探索型：目的是要弄清對(duì)目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。 實(shí)驗(yàn)型：這種原型用于大規(guī)模開(kāi)發(fā)和實(shí)現(xiàn)之前，考核方案是否合適，
31、規(guī)格說(shuō)明是否可靠。 進(jìn)化型：這種原型的目的不在于改進(jìn)規(guī)格說(shuō)明，而是將系統(tǒng)建造得易于變化，在改進(jìn)原型的過(guò)程中，逐步將原型進(jìn)化成最終系統(tǒng)。,2020/7/14,68,建立快速原型好處,增進(jìn)軟件者和用戶(hù)對(duì)系統(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é)果。 軟件原型的最終版本，有的可以原封不動(dòng)地成為產(chǎn)品，有的略加修改就可以成為最終系統(tǒng)的一個(gè)組成部分，這樣有利于建成最終系統(tǒng)。,2020/7/14,69,可執(zhí)行規(guī)格說(shuō)明
32、 基于腳本(scenario)的設(shè)計(jì) 自動(dòng)程序設(shè)計(jì) 專(zhuān)用語(yǔ)言 可復(fù)用(reusable)的軟件 簡(jiǎn)化假設(shè),原型開(kāi)發(fā)技術(shù),2020/7/14,70,可執(zhí)行規(guī)格說(shuō)明,可執(zhí)行規(guī)格說(shuō)明是用于需求規(guī)格說(shuō)明的一種自動(dòng)化技術(shù)。使用這種方法，人們可以直接觀察他們用語(yǔ)言規(guī)定的任何系統(tǒng)性行為。包括 代數(shù)規(guī)格說(shuō)明 有限狀態(tài)模型 可執(zhí)行的數(shù)據(jù)流圖,2020/7/14,71,（1）代數(shù)規(guī)格說(shuō)明,代數(shù)規(guī)格說(shuō)明使用集合、定義于這些集合上的函數(shù)和定義于這些函數(shù)上的方程來(lái)描述對(duì)象。規(guī)格說(shuō)明的操作語(yǔ)義用這些方程表示。 舉例：定義一個(gè)無(wú)界的棧及其操作 NEW_STACK： Stack PUSH：Stack，Element Stac
33、k POP： Stack (Element | Undefined) POP (NEW_STACK ( ) ) Undefined POP (PUSH ( stk，elem ) ) elem 其中，前三行定義了操作的語(yǔ)法，后兩行把它們的語(yǔ)義定義為一些方程。,2020/7/14,72,（2）有限狀態(tài)模型,parnas提出的使用最廣泛的一種可執(zhí)行規(guī)格說(shuō)明形式。從一個(gè)初始狀態(tài)開(kāi)始接收輸入，到產(chǎn)生輸出，狀態(tài)在推移變化。施加在狀態(tài)元素上的約束確定了有效狀態(tài)的推移。 舉例：建立用戶(hù)程序?qū)υ?huà),2020/7/14,73,（3）可執(zhí)行的數(shù)據(jù)流圖,數(shù)據(jù)流圖是基于結(jié)構(gòu)化開(kāi)發(fā)方法的結(jié)構(gòu)化規(guī)格說(shuō)明 用一種可執(zhí)行的語(yǔ)言程
34、序代替定義處理邏輯的結(jié)構(gòu)化英語(yǔ)，數(shù)據(jù)流圖就成為由可執(zhí)行語(yǔ)言程序模塊組成的網(wǎng)絡(luò)，在一定環(huán)境或工具的支持下就可成為一個(gè)可以執(zhí)行的原型系統(tǒng)。,2020/7/14,74,基于腳本的設(shè)計(jì),腳本是指用戶(hù)界面的原型。一個(gè)腳本用以模擬在系統(tǒng)運(yùn)行期間用戶(hù)經(jīng)歷的事件。它提供了輸入處理輸出的屏幕格式和有關(guān)對(duì)話(huà)的模型。因此，軟件開(kāi)發(fā)者能夠給用戶(hù)顯示系統(tǒng)的逼真的視圖，使用戶(hù)得以判斷是否符合他的意圖。 可在任一腳本中使用一套可復(fù)用的軟件模塊，以表達(dá)某一方面的要求。 可使用一種原型語(yǔ)言來(lái)描述原型系統(tǒng)。原型開(kāi)發(fā)過(guò)程中用這種語(yǔ)言來(lái)定義屏幕、數(shù)據(jù)項(xiàng)、及其相關(guān)的操作。從系統(tǒng)的外部描述開(kāi)始，開(kāi)發(fā)與數(shù)據(jù)庫(kù)的接口、錯(cuò)誤處理和恢復(fù)過(guò)程等系
35、統(tǒng)的與外部視圖一致的細(xì)節(jié)。,2020/7/14,75,自動(dòng)程序設(shè)計(jì),自動(dòng)程序設(shè)計(jì)是指在程序自動(dòng)生成環(huán)境的支持下，利用計(jì)算機(jī)實(shí)現(xiàn)軟件的開(kāi)發(fā)。它可以自動(dòng)地或半自動(dòng)地把用戶(hù)的非過(guò)程式問(wèn)題規(guī)格說(shuō)明轉(zhuǎn)換為某種高級(jí)語(yǔ)言程序： 演繹綜合手段： 基于數(shù)學(xué)推理的構(gòu)造式證明。 程序變換手段： 將一程序轉(zhuǎn)換成另一功能等價(jià)的程序，并保持其正確性不變。 實(shí)例推廣手段： 從實(shí)例特征出發(fā)，將它推廣為待編程序的特征，最后得到程序。 過(guò)程化手段： 研究甚高級(jí)語(yǔ)言的編譯和知識(shí)的過(guò)程化。,2020/7/14,76,專(zhuān)用語(yǔ)言,專(zhuān)用語(yǔ)言是應(yīng)用領(lǐng)域的模型化語(yǔ)言。在原型開(kāi)發(fā)中使用專(zhuān)用語(yǔ)言，可方便用戶(hù)和軟件開(kāi)發(fā)者在計(jì)劃中的系統(tǒng)特性方面的交流
36、。,2020/7/14,77,軟件復(fù)用技術(shù),利用可復(fù)用的模塊，做出適當(dāng)?shù)慕M合，就可得到快速構(gòu)造的原型系統(tǒng)。 為了快速地構(gòu)造原型，這些模塊首先必須有簡(jiǎn)單而清晰的界面；其次它們應(yīng)當(dāng)盡量不依賴(lài)其它的模塊或數(shù)據(jù)結(jié)構(gòu)；第三，它們應(yīng)具有一些通用的功能。,2020/7/14,78,簡(jiǎn)化假設(shè),簡(jiǎn)化假設(shè)是在開(kāi)發(fā)過(guò)程中使設(shè)計(jì)者迅速得到一個(gè)簡(jiǎn)化的系統(tǒng)所做的假設(shè)。盡管這些假設(shè)可能實(shí)際上并不能成立，但它們?cè)谠烷_(kāi)發(fā)過(guò)程中可以使開(kāi)發(fā)者的注意力集中在一些主要的方面。 在修改一個(gè)文件時(shí)，可以假設(shè)這個(gè)文件確實(shí)存在 在存取文件時(shí)，待存取的記錄總是存在 一旦計(jì)劃中的系統(tǒng)滿(mǎn)足用戶(hù)所有的要求，就可以撤消這些假設(shè)，并追加一些細(xì)節(jié)。,20
37、20/7/14,79,系統(tǒng)動(dòng)態(tài)分析,系統(tǒng)的需求規(guī)格說(shuō)明通常是用自然語(yǔ)言來(lái)敘述的，但是用自然語(yǔ)言描述往往會(huì)出現(xiàn)歧義性。 為了直觀地分析系統(tǒng)的動(dòng)作，從特定的視點(diǎn)出發(fā)描述系統(tǒng)的行為，需要采用動(dòng)態(tài)分析的方法。 最常用的動(dòng)態(tài)分析方法 狀態(tài)遷移圖 時(shí)序圖 Petri網(wǎng),2020/7/14,80,狀態(tài)遷移圖,狀態(tài)遷移圖是描述系統(tǒng)的狀態(tài)如何相應(yīng)外部的信號(hào)進(jìn)行推移的一種圖形表示。 圓圈“”表示可得到的系統(tǒng)狀態(tài) 箭頭“”表示從一種狀態(tài)向另一種狀態(tài)的遷移。 例如, 當(dāng)有多個(gè)申請(qǐng)占用CPU運(yùn)行的進(jìn)程時(shí), 有關(guān)CPU分配的進(jìn)程的狀態(tài)遷移。,2020/7/14,81,可得到的狀態(tài)就緒，運(yùn)行，等待 生成的事件t1，t2，
38、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)的開(kāi)發(fā)中，它適用于描述與分析相互獨(dú)立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。 Petri網(wǎng)簡(jiǎn)稱(chēng)PNG (Petri Net Graph)，它有兩種結(jié)點(diǎn)： 位置(place)：符號(hào)為“”，它用來(lái)表示系統(tǒng)的狀態(tài)。 轉(zhuǎn)移(transition)：符號(hào)為 “”, 它用來(lái)表示系統(tǒng)中的事件。 圖中的有向邊表示對(duì)轉(zhuǎn)移的輸入，或由轉(zhuǎn)移的輸出,2020/7/14,84,標(biāo)記，或稱(chēng)令牌(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)程的同步問(wèn)題,Petri網(wǎng),2020/7/14,88,Petri網(wǎng),
上海交通大學(xué)計(jì)算機(jī)集成技術(shù)開(kāi)放實(shí)驗(yàn)室第6講需求分析.ppt
