第四章需求獲取.doc_第1頁
第四章需求獲取.doc_第2頁
第四章需求獲取.doc_第3頁
第四章需求獲取.doc_第4頁
第四章需求獲取.doc_第5頁
已閱讀5頁,還剩8頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

【習題】三、選擇填空四、問答題1、在軟件需求分析時,首先建立當前系統(tǒng)的物理模型,再根據(jù)物理模型建立當前系統(tǒng)的邏輯模型。試問:什么是當前系統(tǒng)?當前系統(tǒng)的物理模型與邏輯模型有什么差別?所謂當前系統(tǒng)可能是需要改進的某個已在計算機上運行的數(shù)據(jù)處理系統(tǒng),也可能是一個人工的數(shù)據(jù)處理過程。當前系統(tǒng)的物理模型客觀地反映當前系統(tǒng)實際的工作情況。但在物理模型中有許多物理的因素,隨著分析工作的深入,有些非本質(zhì)的物理因素就成為不必要的負擔,因而需要對物理模型進行分析,區(qū)分出本質(zhì)的和非本質(zhì)的因素,去掉那些非本質(zhì)的因素即可獲得反映系統(tǒng)本質(zhì)的邏輯模型。所以當前系統(tǒng)的邏輯模型是從當前系統(tǒng)的物理模型抽象出來的。2、軟件需求分析是軟件工程過程中交換意見最頻繁的步驟。為什么交換意見的途徑會經(jīng)常阻塞?軟件需求分析過程中,由于最初分析員對要解決的問題了解很少,用戶對問題的描述、對目標軟件的要求也很凌亂、模糊,再加上分析員和用戶共同的知識領域不多,導致相互間通信的需求。但是由于分析員和用戶之間需要通信的內(nèi)容相當多,業(yè)務知識上的不足,表達方式的不足,可能對某些需求存在錯誤解釋或誤解的可能性,造成需求的模糊性。另外,用戶和分析員之間經(jīng)常存在無意識的“我們和他們”的界限,不是按工作需要組成統(tǒng)一的精干的隊伍,而是各自定義自己的“版圖”,并通過一系列備忘錄、正式的意見書、文檔,以及提問和回答來相互通信。歷史已經(jīng)證明,這樣會產(chǎn)生大量誤解。忽略重要信息,無法建立成功的工作關系。3、你認為一個系統(tǒng)分析員的理想訓練和基礎知識是什么?請說明理由。系統(tǒng)分析員處在用戶和高級程序員之間,負責溝通用戶和開發(fā)人員的認識和見解,起著橋梁的作用。一方面要協(xié)助用戶對所開發(fā)的軟件闡明要求,另一方面還要與高級程序員交換意見,探討用戶所提要求的合理性以及實現(xiàn)的可能性。最后還要負責編寫軟件需求規(guī)格說明和初步的用戶手冊。為能勝任上述任務,分析員應當具備如下的素質(zhì):(1) 能夠熟練地掌握計算機硬、軟件的專業(yè)知識,具有一定的系統(tǒng)開發(fā)經(jīng)驗。(2) 善于進行抽象的思維和創(chuàng)造性的思維,善于把握抽象的概念,并把它們重新整理成為各種邏輯成分,并給出簡明、清晰的描述。(3) 善于從相互沖突或混淆的原始資料中抽出恰當?shù)臈l目來。(4) 善于進行調(diào)查研究,能夠很快學習用戶的專業(yè)領域知識,理解用戶的環(huán)境條件。(5) 能夠傾聽他人的意見,注意發(fā)揮其它人員的作用。(6) 具有良好的書面和口頭交流表達能力。4、可行性研究主要研究哪些問題?試說明之??尚行匝芯恐饕?個方面的研究:經(jīng)濟可行性:進行成本效益分析。從經(jīng)濟角度判斷系統(tǒng)開發(fā)是否“合算”。技術可行性:進行技術風險評價。從開發(fā)者的技術實力、以往工作基礎、問題的復雜性等出發(fā),判斷系統(tǒng)開發(fā)在時間、費用等限制條件下成功的可能性。法律可行性:確定系統(tǒng)開發(fā)可能導致的任何侵權(quán)、妨礙和責任。方案的選擇:評價系統(tǒng)或產(chǎn)品開發(fā)的幾個可能的候選方案。最后給出結(jié)論意見。5、信息和信息結(jié)構(gòu)有什么區(qū)別?有沒有不存在信息流的系統(tǒng)?有沒有不存在信息結(jié)構(gòu)的系統(tǒng)?信息是宇宙三要素(物質(zhì)、能量、信息)之一。它是現(xiàn)實世界各種事物在人們頭腦中的反映。此外,人們通過科學儀器能夠認識到的也是信息。信息的特征為:可識別、可存儲、可變換、可處理、可傳遞、可再生、可壓縮、可利用、可共享。信息域就是對信息的多視角考慮。信息域包含3個不同的視圖:信息內(nèi)容和關系、信息流和信息結(jié)構(gòu)。為了完全理解信息域,必須了解每一個視圖。信息結(jié)構(gòu):它是信息在計算機中的組織形式。一般表示了各種數(shù)據(jù)和控制對象的內(nèi)部組織。數(shù)據(jù)和控制對象是被組織成n維表格,還是組織成有層次的樹型結(jié)構(gòu)? 在結(jié)構(gòu)中信息與其它哪些信息相關? 所有信息是在一個信息結(jié)構(gòu)中,還是在幾個信息結(jié)構(gòu)中? 一個結(jié)構(gòu)中的信息與其它結(jié)構(gòu)中的信息如何聯(lián)系? 這些問題都由信息結(jié)構(gòu)的分析來解決。信息流:表示數(shù)據(jù)和控制在系統(tǒng)中傳遞時的變化方式。輸入對象首先被變換成中間信息(數(shù)據(jù)或控制),然后再變換成輸出結(jié)果信息。沿著變換路徑,可能從已有的數(shù)據(jù)存儲(如磁盤文件或內(nèi)存緩沖區(qū))中引入附加的信息。對數(shù)據(jù)進行變換是程序中應有的功能或子功能。兩個變換功能之間的數(shù)據(jù)傳遞就確定了功能間的接口。所以,沒有信息流的系統(tǒng)相當于沒有功能的系統(tǒng),這樣的系統(tǒng)的存在是毫無意義的。而沒有信息結(jié)構(gòu)的系統(tǒng)是沒有信息的系統(tǒng),這樣的系統(tǒng)不是計算機能夠處理的系統(tǒng)。6、有人說:軟件開發(fā)時,一個錯誤發(fā)現(xiàn)得越晚,為改正它所付出的代價就越大。對否?請解釋你的回答。軟件開發(fā)時,一個錯誤發(fā)現(xiàn)得越晚,為改正它所付出的代價就越大。這個說法是對的。在1970年代,GTE、TRW和IBM等三家公司對此問題做了獨立研究,最后它們得到相似的結(jié)論:從表中可以看出,在需求分析階段檢查和修復一個錯誤所需的代價只有編碼階段所需代價的1/5到1/10,而在維護階段做同樣的工作所付出的代價卻是編碼階段的20倍。7、軟件需求分析的操作性原則和需求工程的指導性原則是什么?軟件需求分析的操作性原則指所有的需求分析方法都與一組操作性原則相關聯(lián):必須理解和表示問題的信息域。必須定義軟件將完成的功能。必須表示軟件的行為(作為外部事件的結(jié)果)。必須對描述信息、功能和行為的模型進行分解,能夠以層次方式揭示其細節(jié)。分析過程應當從要素信息轉(zhuǎn)向細節(jié)的實現(xiàn)。通過使用這些原則,分析員可以系統(tǒng)地處理問題。首先檢查信息域以便更完整地理解目標軟件的功能,再使用模型以簡潔的方式表達目標軟件的功能和行為,并利用自頂向下、逐層分解的手段來降低問題的復雜性。在這些處理過程中,因處理需求帶來的邏輯約束和因其它系統(tǒng)元素帶來的物理約束需要通過軟件要素和視圖的實現(xiàn)加以檢驗和確認。Davis建議了一組針對“需求工程”的指導性原則:在開始建立分析模型之前應當先理解問題。如果問題沒有很好理解就急于求成,常常會產(chǎn)生一個解決錯誤問題的完美的軟件。強力推薦使用原型。這樣做可以使用戶了解將如何與計算機交互,而人們對軟件質(zhì)量的認識常常是基于對界面“友好性”的切身體會。記錄每一個需求的起源和原因。這是建立對用戶要求的可追溯性的第一步。使用多個視圖,建立系統(tǒng)的數(shù)據(jù)、功能和行為模型。這樣做可幫助分析員從多方面分析和理解問題,減少遺漏,識別可能的不一致之處。給需求賦予優(yōu)先級。因為過短的時限會減少實現(xiàn)所有軟件需求的可能性。因此,對需求排定一個優(yōu)先次序,標識哪些需求先實現(xiàn),哪些需求后實現(xiàn)。注意消除歧義性。因為大多數(shù)需求都是以自然語言描述,存在敘述的歧義性問題,造成遺漏和誤解。采用正式的技術評審是發(fā)現(xiàn)和消除歧義性的好方法。遵循以上原則,就可能做好軟件需求規(guī)格說明,為軟件設計奠定基礎。8、數(shù)據(jù)流圖的作用是什么?它有哪些基本成份?數(shù)據(jù)流圖可以用來抽象地表示系統(tǒng)或軟件。它從信息傳遞和加工的角度,以圖形的方式刻畫數(shù)據(jù)流從輸入到輸出的移動變換過程,同時可以按自頂向下、逐步分解的方法表示內(nèi)容不斷增加的數(shù)據(jù)流和功能細節(jié)。因此,數(shù)據(jù)流圖既提供了功能建模的機制,也提供了信息流建模的機制,從而可以建立起系統(tǒng)或軟件的功能模型。數(shù)據(jù)流圖的基本成份有4種:9、Petri網(wǎng)可以描述計算機軟件系統(tǒng)的執(zhí)行?,F(xiàn)有一個程序如下(類似于Pascal語言)L :S1;WHILE P1 DOBEGIN IF P2 THEN S2ELSE S3; COBEGINS4;S5;S6; COEND END;GOTO L;S6是單個執(zhí)行語句,COBEGIN和COEND是并行執(zhí)行開始和并行執(zhí)行結(jié)束(即S4,S5和S6語句并行執(zhí)行)。試用Petri網(wǎng)描述這段程序的執(zhí)行過程。采用條件事件網(wǎng)(CE網(wǎng),CCondition, EEvent)式Petri網(wǎng)。10、數(shù)據(jù)詞典的作用是什么?它有哪些基本詞條?分析模型中包含了對數(shù)據(jù)對象、功能和控制的表示。在每一種表示中,數(shù)據(jù)對象和控制項都扮演一定的角色。為表示每個數(shù)據(jù)對象和控制項的特性,建立了數(shù)據(jù)詞典。數(shù)據(jù)詞典精確地、嚴格地定義了每一個與系統(tǒng)相關的數(shù)據(jù)元素,并以字典式順序?qū)⑺鼈兘M織起來,使得用戶和分析員對所有的輸入、輸出、存儲成分和中間計算有共同的理解。在數(shù)據(jù)詞典的每一個詞條中應包含以下信息:名稱:數(shù)據(jù)對象或控制項、數(shù)據(jù)存儲或外部實體的名字。別名或編號。分類:數(shù)據(jù)對象?加工?數(shù)據(jù)流?數(shù)據(jù)文件?外部實體?控制項(事件狀態(tài))?描述:描述內(nèi)容或數(shù)據(jù)結(jié)構(gòu)等。何處使用:使用該詞條(數(shù)據(jù)或控制項)的加工。11、軟件需求分析說明書主要包括哪些內(nèi)容?軟件需求規(guī)格說明是分析任務的最終產(chǎn)物,通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準,給出對目標軟件的各種需求。軟件需求規(guī)格說明的框架如下: 12、考務處理系統(tǒng)的分層數(shù)據(jù)流圖如下圖所示。該考務處理系統(tǒng)有如下功能:對考生送來的報名表進行檢查;對合格的報名表編好準考證號碼后將準考證送給考生,并將匯總后的考生名單送給閱卷站;對閱卷站送來的成績表進行檢查,并根據(jù)考試中心指定的合格標準審定合格者;填寫考生通知單(內(nèi)容包含考試成績及合格不合格標志),送給考生;按地區(qū)、年齡、文化程度、職業(yè)、考試級別等進行成績分類統(tǒng)計及試題難度分析,產(chǎn)生統(tǒng)計分析表。(1)圖(c)中,加工1.1的輸入數(shù)據(jù)流是( A ),輸出數(shù)據(jù)流是( B ),圖(b)中,加工2的輸出數(shù)據(jù)流是( C ),它是由( D )和( E )組成。供選擇的答案:AE. 統(tǒng)計分析表 報名表 準考證 考生通知單 合格報名表 難度分析表 錯誤成績表 分類統(tǒng)計表(2) 圖(d)中的文件“試題得分表”是否在圖(b)中漏掉了?回答是( F )。供選擇的答案:F: “試題得分表”沒有在圖(b)中畫出,是錯誤的。 “試題得分表”是圖(b)中加工的內(nèi)部文件,不必在圖(b)中畫出。 “試題得分表”是多余的。應注意的問題: 適當?shù)貫閿?shù)據(jù)流、加工、文件、數(shù)據(jù)的源匯點命名。名字應反映該元素的實際含義,避免空洞的名字。如數(shù)據(jù)、信息處理、計算等名字都不好。 畫數(shù)據(jù)流時不要夾帶控制流。數(shù)據(jù)流圖中各種數(shù)據(jù)的加工沒有考慮時序關系,引入控制流后,加工之間就有了時序關系,這與畫數(shù)據(jù)流圖不考慮實現(xiàn)細節(jié)的初衷相違背。 一個加工的輸出數(shù)據(jù)流不要與該加工的輸入數(shù)據(jù)流重名,即使它們的組成成分相同。例如圖(c)中加工1.1的輸入數(shù)據(jù)流“報名表”與輸出數(shù)據(jù)流“合格報名表”。 允許一個加工有多個數(shù)據(jù)流流向另一個加工,也允許一個加工有兩個相同的輸出數(shù)據(jù)流流向兩個不同的加工。 保持父圖與子圖的平衡。就是說,父圖與它的子圖的輸入數(shù)據(jù)流與輸出數(shù)據(jù)流應當在數(shù)量與名字上都相同。特別的是,如果父圖的一個輸入(或輸出)數(shù)據(jù)流對應于子圖中幾個輸入(或輸出)數(shù)據(jù)流,但子圖中這幾個數(shù)據(jù)流中的數(shù)據(jù)項合起來正好是父圖中的那個數(shù)據(jù)流,這時它們還算是平衡的。例如,圖(b)中加工2的輸出數(shù)據(jù)流“統(tǒng)計分析表”是由“難度分析表”和“分類統(tǒng)計表”組成,那么圖(b)與圖(d)仍滿足父圖與子圖平衡的條件。 在自頂向下的分解過程中,若一個文件首次出現(xiàn)時只與一個加工有關,那么這個文件應作為這個加工的內(nèi)部文件而不必畫出。例如,圖(d)中的文件“試題得分表”就是圖(b)中加工的內(nèi)部文件,所以在圖(b)中沒有畫出。 保持數(shù)據(jù)守恒。就是說,一個加工的所有輸出數(shù)據(jù)流中的數(shù)據(jù)必須能從該加工的輸入數(shù)據(jù)流中直接獲得,或者是通過該加工產(chǎn)生的數(shù)據(jù)。13、閱讀下列關于開發(fā)人事管理系統(tǒng)的交互式工作方式的敘述,再回答問題。某大企業(yè)最近決定采用高性能微機開發(fā)人事管理系統(tǒng),將四臺聯(lián)機終端分置于人事處的三個科室。該系統(tǒng)可供操作員和程序員使用,也可供人事處負責人和主管人事的副廠長等查詢?nèi)耸滦畔⒂?。人事管理系統(tǒng)通過錄入人事數(shù)據(jù)和修改、刪除等操作,產(chǎn)生和更新各類人事文件,通過搜索這些文件進行各類人事信息的查詢。該企業(yè)有3000多個工人、干部和技術人員,大體可分成機關科室、生產(chǎn)車間、后勤服務和開發(fā)研制部門等幾類部門。廠領導決定由計算機應用科來負責協(xié)調(diào)和開發(fā)應用系統(tǒng)。計算機應用科科長指示系統(tǒng)工程師張某負責進行系統(tǒng)分析??紤]到人事處有大量的查詢信息要求、頻繁的人事信息修改和文件存檔、查閱等特點,計算機應用科決定認真設計人機交互界面,首先設計好在終端上的交互式會話的方式。系統(tǒng)工程師張某通過調(diào)查收集到如下10條意見:(1)某程序員認為:系統(tǒng)在屏幕格式、編碼等方面應具有一致性和清晰性,否則會影響操作人員的工作效率。(2)某操作人員認為:在交互式會話過程中,操作人員可能會忘記或記錯某些事情,系統(tǒng)應當提供HELP功能。(3)某操作人員認為:既然是交互式會話,那么對所有的輸入都應當作出響應,不應出現(xiàn)擊鍵后,計算機沒有任何反應的情況。(4)某操作人員認為:在出錯的時候,交互式會話系統(tǒng)應當給出出錯信息,并且盡可能告訴我們出錯的性質(zhì)和錯在什么地方。(5)某程序員認為:終端會話也應當符合程序員編制程序時的習慣,這樣可以更高效地維護人事管理系統(tǒng)。(6)教育科干部甲認為:應當對操作員進行一些必要的培訓,讓他們掌握交互式會話系統(tǒng)的設計技巧,有助于提高系統(tǒng)的使用效率。(7)教育科干部乙認為:盡管操作人員的指法已經(jīng)強化訓練但在交互式會話時應盡可能縮短和減少操作員輸入的信息,以降低出錯概率。(8)某程序員認為:由于本企業(yè)中有很多較大的文件,文件的查找很費時間,交互式會話系統(tǒng)在響應時間較長時應給予使用者以提示信息。(9)人事處干部丙認為:我們企業(yè)的人事資料相當復雜,格式非常之多,希望交互式系統(tǒng)使用十分清晰的格式,并容易對輸入數(shù)據(jù)中的錯誤進行修改。(10) 人事處干部丁認為:人事管理系統(tǒng)應當具有相當?shù)谋C苄院蛿?shù)據(jù)安全性,因此在屏幕上顯示出的信息應該含混一些,以免泄密。系統(tǒng)工程師張某對上述調(diào)查情況和其他要求作了分析后,發(fā)現(xiàn)收集到的10條意見中有3條意見是不能接受的,寫出編號并各用40字以內(nèi)敘述理由。不能接受的3條意見是 (5)、(6)、(10)。人機交互界面首先考慮的是用戶如何使用起來方便,與編程習慣、設計技巧無關。此外,屏幕上信息應很清晰易懂,安全保密與屏幕顯示無關。14、工資計算系統(tǒng)中的一個子系統(tǒng)有如下功能:計算扣除部分由基本工資計算出應扣除(比如水電費、缺勤)的部分;計算獎金部分根據(jù)職工的出勤情況計算出獎勵金;計算工資總額部分由工資總額中計算出應扣除各種稅金;生成工資表根據(jù)計算總額部分和計算稅金部分傳遞來有關職工工資的詳細信息生成工資表根據(jù)要求畫出該問題的數(shù)據(jù)流程圖。15、Please map the following data flow diagram (DFD) to structure chart (SC) using transform analysis. The afferent path, transform center and efferent path are labeled in the DFD.ABCPDEQRWUVabcrdepuvwAfferent pathEfferent pathTransform center第1步 復查基本系統(tǒng)模型。第2步 復查并精化數(shù)據(jù)流圖。第3步 確定數(shù)據(jù)流圖具有變換特性還是事務特性。第4步 確定輸入流和輸出流的邊界,從而孤立出變換中心。第5步 完成“第一級分解(first level factoring)”。第6步 完成“第二級分解”。第7步 使用設計度量和啟發(fā)式規(guī)則對第一次分割得到的軟件結(jié)構(gòu)進一步精化。MCMTMAMEc, ec, eu, wu, wMTMTMTMTReadDMAAtoBReadADtoEBtoCGetBGetEGetCc, ecbbcaabdedeUtoVMEWriteVPutUWriteWwuuvw, uvMTPQRec, prw, upc, er16、Please map the following data flow diagram (DFD) to structure chart (SC) using transform analysis. The afferent path, transform center and efferent path are labeled in the DFD.1234567891

溫馨提示

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

評論

0/150

提交評論