《軟件需求分析》單選填空判斷答案(共12頁)

《《軟件需求分析》單選填空判斷答案(共12頁)》由會(huì)員分享，可在線閱讀，更多相關(guān)《《軟件需求分析》單選填空判斷答案(共12頁)（12頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。

1、精選優(yōu)質(zhì)文檔-----傾情為你奉上 《軟件需求分析》習(xí)題集 《軟件需求分析》課程組編 2012年 4月 專心---專注---專業(yè) 目 錄 一、單項(xiàng)選擇題………………………………………………2 二、填空題……………………………………………………5 三、判斷題……………………………………………………9 1 《軟件需求分析》習(xí)題集 一、單項(xiàng)選擇題 1、軟件生產(chǎn)中產(chǎn)生需求問題的最大原因在于對應(yīng)用軟件的（ ）理解不透徹或應(yīng)用不 堅(jiān)決。 （A）復(fù)雜性（B）目的性 （C）模擬性（D）正確性 2、需求分析的目的是保證需求的（ ）。

2、（A）目的性和一致性 （B）完整性和一致性 （C）正確性和目的性 （D）完整性和目的性 3、系統(tǒng)需求開發(fā)的結(jié)果最終會(huì)寫入（ ）。 （A）可行性研究報(bào)告 （C）用戶需求說明 4、現(xiàn)實(shí)世界中的（ （B）前景和范圍文檔 （D）系統(tǒng)需求規(guī)格說明 ）構(gòu)成了問題解決的基本范圍，稱為該問題的問題域。 （A）屬性和狀態(tài)（B）實(shí)體和狀態(tài)（C）實(shí)體和操作（D）狀態(tài)和操作 5、功能需求通常分為三個(gè)層次，即業(yè)務(wù)需求、用戶需求和（ ）。 （A）硬件需求（B）軟件需求 （C）質(zhì)量屬性 （D）系統(tǒng)需求 6、比較容易發(fā)現(xiàn)的涉眾稱為初始涉眾，又稱為（ ），通常包括客戶、管理者和相關(guān) 的投資者

3、。 （A）關(guān)鍵涉眾（B）涉眾基線 （C）普通涉眾 （D）一般涉眾 7、如果在最終的物件（Final Artifact）產(chǎn)生之前，一個(gè)中間物件（Mediate Artifact）被 用來在一定廣度和深度范圍內(nèi)表現(xiàn)這個(gè)最終物件，那么這個(gè)中間物件就被認(rèn)為是最終物件在 該廣度和深度上的（ ）。 （A）模擬 （B）構(gòu)造 （C）原型 （D）模型 8、按照使用方式進(jìn)行分類，原型可分為：演示原型、（ ）、試驗(yàn)原型和引示系統(tǒng)原 型。 （A）非操作原型（B）系列首發(fā)原型（C）選定特征原型（D）嚴(yán)格意義上的原型 9、按照功能特征進(jìn)行分類，原型可分為：（ ）、非操作原型、系列首發(fā)原型和

4、選定 特征原型。 （A）拼湊原型（B）樣板原型（C）紙上向?qū)г停―）嚴(yán)格意義上的原型 10、按照開發(fā)方法進(jìn)行分類，原型可分為：演化式原型和拋棄式原型，其中拋棄式原 型又被細(xì)分為（ ）。 （A）演示原型和試驗(yàn)原型 （C）探索式原型和實(shí)驗(yàn)式原型 （B）系列首發(fā)原型和選定特征原型 （D）樣板原型和紙上向?qū)г? 11、原型的需求內(nèi)容可以從三個(gè)緯度上分析：即（ ）。 （A）外觀、角色和實(shí)現(xiàn) （C）成本、技術(shù)和實(shí)現(xiàn) （B）開發(fā)、實(shí)現(xiàn)和作用 （D）需求、作用和角色 12、當(dāng)用戶無法完成主動(dòng)的信息告知，或與需求工程師之間的語言交流無法產(chǎn)生有效 的結(jié)果時(shí)，有必要采用（ ）。

5、 （A）民族志 13、以下（ （A）突現(xiàn) 14、以下（ （A）全局 （B）觀察法 （C）話語分析 （D）任務(wù)分析 （D）模糊 （D）即時(shí) ）不是情景性的重要性質(zhì)？ （B）涉身 （C）完善 ）是情景性的重要性質(zhì)？ （B）開放 （C）交互 2 15、下列（ ）不是需求獲取常見的模型驅(qū)動(dòng)方法？ （A）面向目標(biāo)的方法 （C）基于用例的方法 （B）基于場景的方法。 （D）基于采樣的方法 16、下列（ ）屬于定量硬數(shù)據(jù)？ （A）工作手冊 17、下列（ （B）規(guī)章手冊 （C）統(tǒng)計(jì)報(bào)表 （D）備忘錄 ）屬于定性硬數(shù)據(jù)？ （A）數(shù)據(jù)收集表

6、 （B）月報(bào)表 （C）年報(bào)表 （D）規(guī)章手冊 18、功能目標(biāo)可以分為 ( （A）安全目標(biāo)和可用性目標(biāo) （C）軟目標(biāo)和硬目標(biāo) )。 （B）滿足型目標(biāo)和信息型目標(biāo) （D）維護(hù)目標(biāo)和實(shí)現(xiàn)目標(biāo) 19、在表達(dá)軟目標(biāo)的分解和細(xì)化時(shí)使用的 AND Contribution鏈接和 OR Contribution鏈 接，Contribution的作用是（ （A）積極的 （B）消極的 20、AND鏈接將一個(gè)父目標(biāo)連接到一系列細(xì)化的子目標(biāo)，意思是如果能夠滿足所有細(xì) ）。 （C）積極的或消極的 （D）不能確定 化的子目標(biāo)，那么將（ ）父目標(biāo)。 （A）無法確定 （B）阻礙

7、（C）不能滿足 （D）足以滿足 21、OR鏈接是將一個(gè)父目標(biāo)連接到一系列細(xì)化的子目標(biāo)，意思是如果能夠滿足所有細(xì) 化子目標(biāo)中的（ ），那么將足以滿足父目標(biāo)。 （A）每一個(gè)（B）任何一個(gè) （C）特定的（D）某一個(gè) 22、下列選項(xiàng)中，（ （A）行為者 23、面向目標(biāo)方法的目標(biāo)分析階段的主要任務(wù)是（ ）不是在目標(biāo)模型中使用的其他模型元素。 （B）場景 （C）操作 （D）概念 ）。 （A）獲取目標(biāo) （B）確定解決方案 （C）建立目標(biāo)模型 （D）發(fā)現(xiàn)問題和缺陷 24、場景的分類框架將場景方法從場景的（ ）4個(gè)方面進(jìn)行了分類和描述。 （A）形式、目的、內(nèi)容和生命周期

8、 （C）描述、目的、內(nèi)容和形式 （B）外觀、目的、內(nèi)容和生命周期 （D）描述、外觀、目的和內(nèi)容 25、場景的形式是指場景的表達(dá)模式，從形式上分為兩個(gè)方面：（ ） （A）內(nèi)容和目的（B）內(nèi)容和生命周期（C）描述和外觀（D）描述和目的 26、描述場景所使用的表示法要符合正規(guī)性要求，一般可使用非形式化語言、半形式 化語言和形式化語言。在實(shí)踐中，（ ）是主要的描述方式。 （B）非形式化的自然語言 （D）非形式化的設(shè)計(jì)語言 （A）形式化的程序語言 （C）形式化的圖形工具 27、外觀是指場景被表達(dá)出來時(shí)的效果，主要有（ （A）靜態(tài)、動(dòng)態(tài)和結(jié)構(gòu)化 （B）線性、非線性和交互 （

9、C）靜態(tài)、動(dòng)態(tài)和動(dòng)靜結(jié)合（D）靜態(tài)、動(dòng)態(tài)和交互 28、場景的內(nèi)容是指場景所表達(dá)的知識(shí)類型。它被分為 6個(gè)不同的方面。下列（ ）三種類型。 ） 不是場景的內(nèi)容。 （A）主要關(guān)注點(diǎn) （B）環(huán)境范圍 （C）目的 （D）抽象層次 29、需求工程利用場景的目的可能有三種：即：（ ）。 （A）描述、探索和解釋 （C）描述、探索和發(fā)現(xiàn) （B）描述、表示和探索 （D）表示、解釋和證明 30、使用解釋性場景在需求分析時(shí)能夠（ ），或者被用于進(jìn)行需求的驗(yàn)證。 （A）提高模型的復(fù)雜性 （B）降低模型的復(fù)雜性 3 （C）提高預(yù)見性 31、下列（ （D）降低編程量 ）不

10、是場景方法在需求工程中的應(yīng)用。 （A）幫助進(jìn)行詳細(xì)的需求分析 （B）編寫系統(tǒng)需求規(guī)格說明 （C）結(jié)合面向目標(biāo)的方法，指導(dǎo)需求獲取活動(dòng)的開展 （D）組織需求獲取得到的信息 32、下列（ ）是組織場景時(shí)可用的場景關(guān)系。 （A）合取關(guān)系 （B）定性關(guān)系 （C）定量關(guān)系 （D）演繹關(guān)系 33、與其他的場景方法相比，用例最大的特點(diǎn)是采用了（ ）的描述方式。 （A）靜態(tài)非結(jié)構(gòu)化文本 （C）靜態(tài)結(jié)構(gòu)化文本 （B）動(dòng)態(tài)非結(jié)構(gòu)化文本 （D）動(dòng)態(tài)結(jié)構(gòu)化文本 ）三種。 34、用例之間的關(guān)系主要有（ （A）包含、擴(kuò)展和簡化 （C）包含、多態(tài)和繼承 （B）合取、析取和擴(kuò)展 （D

11、）包含、擴(kuò)展和泛化 35、分析的活動(dòng)主要包括識(shí)別、定義和結(jié)構(gòu)化，它的目的是獲取某個(gè)可以轉(zhuǎn)換為知識(shí)的 事物的信息，這種分析活動(dòng)被稱為（ （A）需求信息獲取 ）。 （B）建立軟件系統(tǒng)解決方案 （D）建立需求分析模型 （C）需求信息轉(zhuǎn)化 36、（ ）是建模最為常用的兩種手段。 （A）具體和抽象 （B）抽象和分解 （C）分解和細(xì)化 （D）抽象和細(xì)化 37、抽象通過強(qiáng)調(diào)本質(zhì)的特征，（ ）了問題的復(fù)雜性。 （A）調(diào)整 （B）避免 （C）增加 （D）減少 38、需求分析僅僅需要描述解決方案，不需要探索實(shí)現(xiàn)細(xì)節(jié)的情況下，分析模型又是 （ ）的，尤為適用。 （A）形式

12、化 （B）半形式化 （C）結(jié)構(gòu)化 （D）非結(jié)構(gòu)化 39、上下文圖描述系統(tǒng)與環(huán)境中外部實(shí)體之間的界限和聯(lián)系。它從現(xiàn)實(shí)世界的角度說明 了系統(tǒng)的（ ），并確定了所有的輸入和輸出。 （A）環(huán)境與外觀 40、（ （B）邊界和聯(lián)系（C）邊界和環(huán)境 （D）輸入和輸出 ）是結(jié)構(gòu)化分析方法的核心技術(shù)，它表明系統(tǒng)的輸入、處理、存儲(chǔ)和輸出，以 及它們?nèi)绾卧谝黄饏f(xié)調(diào)工作。 （A）數(shù)據(jù)流圖 DFD（B）實(shí)體聯(lián)系圖 ERD（C）狀態(tài)轉(zhuǎn)換圖（D）上下文圖 41、結(jié)構(gòu)化、信息工程和面向?qū)ο笕N方法學(xué)下的需求分析技術(shù)都是（ （A）面向問題域 （B）面向解系統(tǒng) （C）面向設(shè)計(jì) （D）面向需求

13、 42、使用面向問題的技術(shù)對問題世界的建模就被稱為（ （A）前期 （B）中期 （C）后期 （D）全過程 43、使用面向解系統(tǒng)的技術(shù)對軟件系統(tǒng)解決方案的描述稱為（ （A）前期 （B）中期 （C）后期 （D）全過程 ）的。 ）需求階段的分析。 ）需求階段的分析。 44、需求分析活動(dòng)的一個(gè)重要任務(wù)是進(jìn)行（ ），明確用戶需求的隱含信息，展開為 明確的對軟件系統(tǒng)的行為期望，即系統(tǒng)需求。 （A）需求整理 （B）需求細(xì)化 （C）需求獲取 （D）需求分析 45、在分層結(jié)構(gòu)中，DFD定義了三個(gè)層次類別的 DFD圖：（ （A）1層圖 （B）底層圖 （C）上下文圖 （D）頂視圖

14、46、因?yàn)閿?shù)據(jù)存儲(chǔ)是系統(tǒng)內(nèi)部的功能實(shí)現(xiàn)，所以在將系統(tǒng)視為黑盒的情況下，上下文 ）、0層圖和 N層圖。 圖中不會(huì)出現(xiàn)（ ）。 4 （A）實(shí)體 （B）數(shù)據(jù)存儲(chǔ)實(shí)例 （C）需求信息 （D）過程處理 47、數(shù)據(jù)建模技術(shù)能夠彌補(bǔ)過程建模在（ ）方面的缺陷，它描述數(shù)據(jù)的定義、結(jié) 構(gòu)和關(guān)系等特性。 （A）需求分析 （B）數(shù)據(jù)轉(zhuǎn)換 （C）數(shù)據(jù)說明 （D）數(shù)據(jù)分析 48、。概念實(shí)體是一種抽象概念，不考慮概念背后的物理存在，所以通常不包含與之相 關(guān)聯(lián)的其他（ ）。 （A）模型 （B）特征（即屬性） （C）關(guān)系 （D）處理 49、在 ERD建模中，實(shí)體通常所指

15、的就是（ （A）邏輯實(shí)體 （B）概念實(shí)體 （C）物理實(shí)體 50、ERD中屬性是實(shí)體的特征，不是數(shù)據(jù)。屬性會(huì)以一定的形式存在，這種存在才是 ）。 （D）進(jìn)程實(shí)體 數(shù)據(jù)，被稱為屬性的（ ）。 （A）域 （B）實(shí)例 （C）說明 （D）值 51、ERD中關(guān)系的度數(shù)（Degree）是指參與關(guān)系的實(shí)體數(shù)量，是度量關(guān)系（ ）的 一個(gè)指標(biāo)。 （A）模型 52、ERD中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最大基數(shù)又被稱為（ （A）鍵約束 （B）參與約束（C）自然約束 （D）一般約束 53、在實(shí)體之間建立關(guān)系時(shí)，可能會(huì)產(chǎn)生一些附帶的實(shí)體，被稱為關(guān)聯(lián)實(shí)體，最常見 （B）復(fù)雜度 （

16、C）精確度 （D）屬性值 ）。 的形式是（ ）。 （A）邏輯實(shí)體 （B）進(jìn)程實(shí)體 （C）概念實(shí)體 （D）自然實(shí)體 54、在實(shí)現(xiàn) ERD與過程模型同步的技術(shù)中，（ ）是一種較為常見的技術(shù)。 （A）用例圖 55、下列（ （A）屬性 （B）數(shù)據(jù)流圖 （C）功能／實(shí)體矩陣 （D）微規(guī)格說明 ）不是用例模型中的關(guān)系？ （B）關(guān)聯(lián) （C）泛化 （D）包含 56、系統(tǒng)邊界是指一個(gè)系統(tǒng)所包含的系統(tǒng)成分與系統(tǒng)外事物的分界線。用例模型使用 一個(gè)（ ）來表示系統(tǒng)邊界，以顯示系統(tǒng)的上下文環(huán)境。 （A）圓形框 （B）菱形框 （C）虛線框 （D）矩形框 57、UML使用

17、的行為模型有三種，即：（ ）。 （A）交互圖、狀態(tài)圖和順序圖 （C）交互圖、狀態(tài)圖和活動(dòng)圖 （B）順序圖、通信圖和時(shí)間圖 （D）交互概述圖、通信圖和時(shí)間圖 58、項(xiàng)目的前景和范圍文檔、用戶需求文檔都被視為屬于（ ），重點(diǎn)都是用戶的現(xiàn) 實(shí)世界。 （A）開發(fā)文檔 （B）需求文檔 （C）前景文檔 （D）用戶文檔 59、系統(tǒng)需求規(guī)格說明文檔、軟件需求規(guī)格說明文檔、硬件需求規(guī)格說明文檔、接口 需求規(guī)格說明文檔和人機(jī)交互文檔一起被用于系統(tǒng)開發(fā)的目的，都被認(rèn)為是開發(fā)文檔。 （A）開發(fā)文檔 60、下列（ （B）需求文檔 （C）過程文檔 （D）用戶文檔 ）不是需求規(guī)格說明文檔

18、的讀者？ （A）項(xiàng)目管理者 （B）編程人員 （C）銷售商 （D）律師 二、填空題 1、傳統(tǒng)的需求分析方法都是從設(shè)計(jì)領(lǐng)域轉(zhuǎn)入分析領(lǐng)域的。 2、面向?qū)I(yè)用戶的純工具型軟件分析階段的主要目的是為充分利用創(chuàng)新優(yōu)勢而進(jìn)行巧 妙的功能安排。 3、面向普通用戶的純工具型軟件進(jìn)行分析的主要目的是進(jìn)行方案權(quán)衡，尋找一套切實(shí) 5 有效的功能配置。 4、應(yīng)用型軟件分析階段的主要目的是發(fā)現(xiàn)人們利用軟件的原因（目的），找出需要軟件 解決的問題，理解應(yīng)用環(huán)境中的領(lǐng)域知識(shí)，保證功能的模擬性。 5、需求工程是所有需求處理活動(dòng)的總和，它收集信息、分析問題、整合觀點(diǎn)、記錄需 求并驗(yàn)證其正

19、確性，最終反映軟件被應(yīng)用后與其環(huán)境互動(dòng)形成的期望效應(yīng)。 6、軟件需求開發(fā)用來確定系統(tǒng)需求中應(yīng)該由軟件滿足的部分，將其映射為軟件行為， 產(chǎn)生軟件需求規(guī)格說明。 7、約束是不受解系統(tǒng)影響，卻會(huì)給解系統(tǒng)帶來極大影響的問題域特性。 8、優(yōu)秀的需求應(yīng)該具備 7個(gè)特性，即完整性、正確性、精確性、可行性、必要性、無 歧義和可驗(yàn)證。 9、所有對軟件系統(tǒng)的開發(fā)和應(yīng)用具有發(fā)言權(quán)和決定權(quán)的人統(tǒng)稱為涉眾。 10、按照媒介載體進(jìn)行分類，原型可分為：樣板原型和紙上向?qū)г汀? 11、演示原型主要被用在項(xiàng)目啟動(dòng)階段。 12、演示原型都是被用來展示用戶想象中的系統(tǒng)視圖，所以它要能夠表現(xiàn)用戶界面的重 要特征。

20、 13、，如果一個(gè)問題的技術(shù)解決方案是不清晰的，演示原型也可以被用來展現(xiàn)相應(yīng)的細(xì) 節(jié)功能以使用戶確信該問題解決的可能性。 14、通常來說，如果用戶需求出現(xiàn)了模糊、不清晰、不完整等具有一定不確定性的特征， 就可以考慮使用原型方法。 15、角色是指原型物件在用戶工作中的價(jià)值，也就是說它為什么對用戶是有用的。 16、外觀是指用戶對原型物件的具體感覺體驗(yàn)，即用戶在使用原型物件時(shí)會(huì)看到什么、 聽到什么和感覺到什么。 17、實(shí)現(xiàn)是指原型物件完成功能的細(xì)節(jié)技術(shù)和方法。 18、使用演化式原型方法，在開發(fā)時(shí)就需要注意原型的健壯性和代碼的質(zhì)量。 19、使用實(shí)驗(yàn)式開發(fā)方法，需要實(shí)現(xiàn)多種技術(shù)方案，

21、考察重要的系統(tǒng)的質(zhì)量屬性。 20、選擇使用探索式開發(fā)方法，需要盡可能地考慮各種不同的設(shè)計(jì)選項(xiàng)，比較不同選項(xiàng) 下的用戶反饋。 21、原型方法的最大優(yōu)點(diǎn)是能夠及早地解決系統(tǒng)開發(fā)中的不確定性，從而降低軟件項(xiàng)目 失敗的風(fēng)險(xiǎn)。 22、航空調(diào)度、證券交易、醫(yī)療手術(shù)控制等復(fù)雜的協(xié)同問題都具有突現(xiàn)的情景性。 23、民族志的一個(gè)主要應(yīng)用目的就是研究和解決復(fù)雜的協(xié)同問題。 24、復(fù)雜的工作總會(huì)同時(shí)存在著正常流程和異常流程，異常流程大多是一些特殊情況下 的處理，限定了異常處理的上下文環(huán)境，即異常處理具有局部的情景性。 25、有很多重要工作的進(jìn)行需要用戶具備一定的認(rèn)知，認(rèn)知要求已經(jīng)成了用戶工作必備

22、 的部分，即工作具有涉身的情景性。 26、采樣觀察是最簡單的觀察方法，應(yīng)用目的是發(fā)現(xiàn)異常流程，驗(yàn)證用戶所述知識(shí)和實(shí) 際的一致性，以及發(fā)現(xiàn)默認(rèn)知識(shí)。 27、時(shí)間采樣允許需求工程師建立指定的時(shí)間間隔來觀察用戶的活動(dòng)情況。 28、文檔審查主要獲取對象包括相關(guān)產(chǎn)品的需求規(guī)格說明、硬數(shù)據(jù)和客戶的需求文檔。 29、文檔分析通常是數(shù)據(jù)建模方法的一個(gè)基礎(chǔ)部分，它是通過檢查采集的硬數(shù)據(jù)來確定 潛在的需求。 30、如果當(dāng)前存在一份客戶的需求文檔，就可以使用需求剝離技術(shù)，從需求文檔中抽取 單個(gè)的需求并加入到新的需求文檔之中。 31、需求工程師可以使用模型驅(qū)動(dòng)方法來進(jìn)行信息的整理和歸類，其中模型驅(qū)動(dòng)

23、方法所 6 建立的模型是進(jìn)行信息整理和歸類的很好的框架依據(jù)。 32、模型驅(qū)動(dòng)方法的模型是在前期需求階段的分析中建立的。 33、目標(biāo)模型的一個(gè)核心要素是元素之間的關(guān)系，稱為鏈接。 34、目標(biāo)模型的鏈接有兩類：一類是目標(biāo)之間的鏈接；另一類是目標(biāo)與其他模型元素之 間的鏈接。 35、面向目標(biāo)方法的處理過程可以分為三個(gè)階段：目標(biāo)獲取、目標(biāo)分析（即目標(biāo)模型的 建立）和目標(biāo)實(shí)現(xiàn)。 36、目標(biāo)實(shí)現(xiàn)階段的主要任務(wù)是收集與目標(biāo)相關(guān)的需求信息，討論可能的候選解決方案， 確定最終的系統(tǒng)詳細(xì)需求和解決方案。 37、場景具有重點(diǎn)描述真實(shí)世界的特征，它利用情景、行為者之間的交互、事件隨時(shí)間

24、 的演化等方式來敘述性地描述系統(tǒng)的使用。 38、靜態(tài)外觀的場景被展現(xiàn)為一個(gè)或者數(shù)個(gè)描述性的文本或者圖片。 39、動(dòng)態(tài)外觀的場景會(huì)被以動(dòng)態(tài)的方式展現(xiàn)出來，人們可能會(huì)要求按時(shí)序向前或者向后 瀏覽場景，也可能會(huì)要求跳轉(zhuǎn)到場景的某一個(gè)時(shí)刻進(jìn)行觀察。 40、交互外觀的場景提供交互性，它允許用戶在一定程度上控制和改變場景的變化時(shí)序 或者效果。 41、具體場景，又稱為實(shí)例場景，是對個(gè)別行為者、事件、情節(jié)的細(xì)節(jié)描述。 42、抽象場景，又稱為類型場景，是以經(jīng)驗(yàn)中的類別和抽象概念來描述事實(shí)。 43、探索性場景可以用來進(jìn)行需求獲取和需求建模與分析。 44、每個(gè)用例是對相關(guān)場景集合的敘述性的文本描

25、述，這些場景是用戶和系統(tǒng)之間的交 互行為序列，幫助實(shí)現(xiàn)用戶的目的。 45、用例是場景方法中的一種，是靜態(tài)的結(jié)構(gòu)化文本描述。 46、在高層的功能需求獲取完備之前，用例的產(chǎn)生方式中不允許使用功能分解方式。 47、單個(gè)用例描述了系統(tǒng)的功能片段，系統(tǒng)的所有用例基于一定的關(guān)系組織起來，建立 用例模型，就可以描述整個(gè)系統(tǒng)的功能。 48、原有用例和新建立的抽象用例的關(guān)系即為包含關(guān)系。 49、在需求工程中，主要產(chǎn)生三類重要的文檔：項(xiàng)目前景和范圍文檔、用戶需求文檔以 及需求規(guī)格說明。用例文檔通常被用來代替用戶需求文檔，起到記錄、交流領(lǐng)域信息和用戶 期望的作用。 50、需求獲取得到的信息和需求

26、開發(fā)應(yīng)該建立的軟件系統(tǒng)解決方案之間有著很大的差 距。需求分析就是用來解決這個(gè)差距的需求工程活動(dòng)。 51、需求分析的根本任務(wù)是：建立分析模型并創(chuàng)建解決方案。 52、分解將單個(gè)復(fù)雜和難以理解的問題分解成多個(gè)相對更容易的子問題，并掌握各子 問題之間的聯(lián)系。 53、基于軟件構(gòu)建單位及其之間的關(guān)系建立的模型，用來說明軟件邏輯上的構(gòu)建方式 和實(shí)現(xiàn)方式，由于它使用的組元及其關(guān)系都是軟件的元素，因此它是來自于軟件的模型，稱 為計(jì)算模型。 54、模型語言的三要素：語法、語義、語用。其中語用給出了一個(gè)模型元素描述的更 寬廣的上下文，以及影響該模型元素意義的約束和假定。 55、互相之間建立了語義

27、聯(lián)系的多個(gè)模型，集成在一起通常被稱為視圖。 56、需求分析方法主要有：結(jié)構(gòu)化方法、信息工程方法和面向?qū)ο蠓椒āＦ渲忻嫦驅(qū)? 象方法是目前工業(yè)界使用的主流方法。 57、信息工程和結(jié)構(gòu)化方法的本質(zhì)差別在于解決問題的策略不同。 58、前期需求階段分析的重點(diǎn)是理解問題世界，因此它關(guān)注的是整個(gè)問題世界，注重 7 于系統(tǒng)的環(huán)境、開發(fā)組織的業(yè)務(wù)背景、涉眾的特征以及目標(biāo)等等，軟件系統(tǒng)只是整個(gè)背景下 的一個(gè)要素。 59、后期需求階段分析關(guān)注的是解系統(tǒng)解決方案的建立，因此它以軟件系統(tǒng)為中心， 注重于分析系統(tǒng)的內(nèi)部功能以及它與環(huán)境的互動(dòng)，是對系統(tǒng)功能的詳細(xì)信息的分析。 60、以軟件復(fù)用

28、為核心，建立產(chǎn)品族的方法被稱為產(chǎn)品線。 61、需求協(xié)商活動(dòng)既包括對目標(biāo)沖突的處理，也包括對需求細(xì)節(jié)沖突的處理。 62、微規(guī)格說明被用來描述DFD過程分解結(jié)構(gòu)中最底層過程的處理邏輯。 63、DFD中所有的外部實(shí)體聯(lián)合起來構(gòu)成了軟件系統(tǒng)的外部上下文環(huán)境，它們與軟件 系統(tǒng)的交互流就是軟件系統(tǒng)與其外部環(huán)境的接口，這些接口聯(lián)合起來定義了軟件系統(tǒng)的系統(tǒng) 邊界。 64、數(shù)據(jù)流是指數(shù)據(jù)的運(yùn)動(dòng)，它是系統(tǒng)與其環(huán)境之間或者系統(tǒng)內(nèi)兩個(gè)過程之間的通信 形式。 65、DFD的 0層圖中的每個(gè)過程都可以進(jìn)行分解，被分解的過程稱為父過程，分解后 產(chǎn)生的揭示更多細(xì)節(jié)的DFD圖稱為子圖。 66、DFD的 0

29、層圖通常被用來作為整個(gè)系統(tǒng)的功能概圖。 67、為了保證DFD圖的可理解性，0層圖應(yīng)該被描述的簡潔、清晰，所以在描述復(fù)雜的 系統(tǒng)時(shí)，0層圖中不應(yīng)出現(xiàn)太過具體的過程和數(shù)據(jù)存儲(chǔ)。 68、DFD中對 0層圖的過程分解產(chǎn)生的子圖稱為1層圖。 69、數(shù)據(jù)建模建立的模型稱為數(shù)據(jù)模型，是問題域和解系統(tǒng)共享的知識(shí)集合，通常能 夠反映企業(yè)業(yè)務(wù)的核心知識(shí)。 70、數(shù)據(jù)模型的內(nèi)容是問題域和解系統(tǒng)所共享的知識(shí)模型，可以用問題域的語言來解 釋，也可以用解系統(tǒng)的語言來解釋，還可以用介于問題域和解系統(tǒng)之間的中立語言來解釋。 71、在需求工程中，數(shù)據(jù)建模建立的是概念數(shù)據(jù)模型和邏輯數(shù)據(jù)模型，不涉及物理數(shù) 據(jù)模型

30、。 72、ERD的邏輯實(shí)體是對概念實(shí)體的細(xì)化，擁有完整的特征描述。 73、數(shù)據(jù)建模中對行為和事件的建模需要是為了了解它們在某些時(shí)刻的快照或者運(yùn)行 環(huán)境信息，而不是它們所體現(xiàn)出來的功能和達(dá)成的效果，所以稱這類實(shí)體為進(jìn)程實(shí)體。 74、ERD中屬性就是可以對實(shí)體進(jìn)行描述的特征，一系列屬性的存在集成起來就可以 描述一個(gè)實(shí)體的實(shí)例。 75、ERD中屬性取值的受限制范圍稱為域（Domain）。 76、ERD為實(shí)體指定一個(gè)屬性或多個(gè)屬性的組合，可以用來唯一地確定和標(biāo)識(shí)每個(gè)實(shí) 例，這些屬性或?qū)傩缘慕M合稱為實(shí)體的標(biāo)識(shí)符，又稱為鍵。 77、一個(gè)實(shí)體可能有多個(gè)鍵，這些鍵都被稱為候選鍵。 78、通

31、常人們從多個(gè)候選鍵中選擇和使用固定的某一個(gè)鍵來進(jìn)行實(shí)例的標(biāo)識(shí)，這個(gè)被 選中的候選鍵被稱為主鍵，沒有被選做主鍵的候選鍵被稱為替代鍵。 79、實(shí)體實(shí)例大多數(shù)屬性的值都是需要從現(xiàn)實(shí)中獲取的，稱為存儲(chǔ)屬性。 80、有些實(shí)體實(shí)例的屬性的值是可以由其他屬性的值計(jì)算得出的，稱為導(dǎo)出屬性。 81、關(guān)系是存在于一個(gè)或多個(gè)實(shí)體之間的自然業(yè)務(wù)聯(lián)系。 82、只有一個(gè)實(shí)體參與的關(guān)系存在于實(shí)體的不同實(shí)例之間，稱為一元關(guān)系，又稱為遞 歸關(guān)系。 83、ERD中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最小基數(shù)又被稱為參與約束。 84、ERD中一個(gè)實(shí)體在關(guān)系中的最大基數(shù)是指，對關(guān)系中任意的其他實(shí)體實(shí)例，該實(shí) 體可能參

32、與關(guān)系的最大數(shù)量。 85、ERD中一個(gè)實(shí)體在關(guān)系中的最小基數(shù)是指，對關(guān)系中任意的其他實(shí)體實(shí)例，該實(shí) 8 體可能參與關(guān)系的最小數(shù)量。 86、ERD中被關(guān)系影響的實(shí)體主要是弱實(shí)體和關(guān)聯(lián)實(shí)體。 87、用例模型的基本元素有四種：用例、參與者、關(guān)系和系統(tǒng)邊界。 88、UML行為模型是用例模型的實(shí)現(xiàn)，以更加詳細(xì)的方式說明用例所描述的系統(tǒng)行為。 89、UML行為模型的活動(dòng)圖是依據(jù)處理流程進(jìn)行的用例實(shí)現(xiàn)。 90、UML行為模型的交互圖通常描述的是單個(gè)用例的典型場景。 91、接口需求規(guī)格說明文檔是對整個(gè)系統(tǒng)中需要軟、硬件協(xié)同實(shí)現(xiàn)部分的詳細(xì)描述。 92、優(yōu)秀的需求規(guī)格說明文檔應(yīng)該具

33、備：正確性、無歧義、完備性、一致性、根據(jù)重 要性和穩(wěn)定性分級、可驗(yàn)證、可修改、可跟蹤等特性。 93、需求驗(yàn)證常見方法有：需求評審、原型與模擬、測試用例開發(fā)、用戶手冊編制、 利用跟蹤關(guān)系和自動(dòng)化分析。 94、評審又被稱為同級評審，是指由作者之外的其他人來檢查產(chǎn)品問題的方法。 95、在系統(tǒng)驗(yàn)證中，評審是主要的靜態(tài)分析手段，所以評審也是需求評審的一種主要 方法。 96、需求基線的維護(hù)主要包括配置管理和狀態(tài)維護(hù)。 97、需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在向前和向后兩個(gè)方向上，描述需 求以及跟蹤需求變化的能力。 98、從需求向后回溯（前向跟蹤的兩種聯(lián)系之一）說明軟件需求來源于

34、哪些涉眾的需 要和目標(biāo)。 99、后向跟蹤是指需求被定義到軟件需求規(guī)格說明文檔之后的演化過程。 100、后向跟蹤包括兩種聯(lián)系：從需求向前跟蹤和回溯到需求的跟蹤。 三、判斷題 1、需求工程包括需求獲取和需求開發(fā)兩個(gè)方面。（） 2、需求驗(yàn)證是需求工程中最后一個(gè)活動(dòng)。（） 3、軟件系統(tǒng)能夠與問題域進(jìn)行交互和相互影響的原因在于，軟件系統(tǒng)中的某些部分對問 題域中的某些部分具有模擬特性。（√） 4、規(guī)格說明是問題域?yàn)闈M足用戶需求而提供的解決方案，規(guī)定了解系統(tǒng)的行為特征。（） 5、業(yè)務(wù)需求具有明顯的目的性和較高的抽象性，經(jīng)過明確和細(xì)化的處理，可以直接轉(zhuǎn)化 為系統(tǒng)需求。（） 6、需求開發(fā)

35、的一些特性決定了需求開發(fā)過程只能是一個(gè)簡單的線性增量過程。（） 7、對于需求不確定性比較小的項(xiàng)目，用戶參與可以取得比較好的效果，但對于需求不確 定性比較大的項(xiàng)目，用戶參與反而可能帶來阻礙作用。（） 8、按照構(gòu)建技術(shù)進(jìn)行分類，原型可分為：水平原型和垂直原型。（√） 9、嚴(yán)格意義上的原型主要被用在需求分析階段。（√） 10、要完成相同的功能，構(gòu)建拋棄式原型比構(gòu)建演化式原型所花費(fèi)的代價(jià)要大得多。（） 11、水平原型方法僅僅實(shí)現(xiàn)選定功能實(shí)現(xiàn)的所有層次，能夠處理較大范圍的功能。（） 12、垂直原型方法會(huì)觸及選定功能所有層次中的某些特定層次，處理的功能范圍通常較 小。（） 13、建立外觀

36、原型時(shí)重在原型的用戶界面和交互方式，原型的功能和技術(shù)實(shí)現(xiàn)細(xì)節(jié)就會(huì) 被簡化處理。（√） 14、如果選擇的開發(fā)方法是實(shí)驗(yàn)式或者探索式開發(fā)方法，應(yīng)該盡量花費(fèi)最小的代價(jià)，爭 取最快的速度，忽略或簡化不重要的功能處理。（√） 15、原型修正主要依據(jù)評估人員的反饋，可以忽略事先的原型調(diào)整計(jì)劃。（） 9 16、文檔審查是一種傳統(tǒng)的需求獲取方法，是專門針對文檔進(jìn)行的需求獲取活動(dòng)。（√） 17、由于文檔是來自于當(dāng)前計(jì)算機(jī)或手工系統(tǒng)的產(chǎn)物，因此它是正確的，也正是客戶所 需要的。（） 18、成功的需求獲取任務(wù)不僅要求成功地執(zhí)行每一次具體的需求獲取行為，還要求成功 地處理多次獲取行為之

37、間的關(guān)系。（√） 19、軟目標(biāo)是一類無法清晰判斷是否滿足的目標(biāo)，所以可以用 AND和 OR鏈接直接應(yīng) 用于軟目標(biāo)。（） 20、子目標(biāo)的實(shí)現(xiàn)只能促進(jìn)父目標(biāo)的實(shí)現(xiàn)。（） 21、AND和 OR鏈接用于描述目標(biāo)的分解和細(xì)化關(guān)系。（√） 22、目標(biāo)的發(fā)現(xiàn)并是一個(gè)自上而下分解的過程，也就是一個(gè)不斷發(fā)現(xiàn)和細(xì)化的過程。（） 23、對系統(tǒng)的現(xiàn)狀和背景進(jìn)行分析往往能夠發(fā)現(xiàn)重要的目標(biāo)，得到一些明確的問題和缺 陷，它們的反面就是系統(tǒng)需要實(shí)現(xiàn)的目標(biāo)。（√） 24、場景被人們廣泛接受的原因是因?yàn)槿藗兏鼉A向于會(huì)對真實(shí)事件和真實(shí)事物的描述產(chǎn) 生反應(yīng)。（√） 25、描述場景時(shí)所使用的常見媒介形式主要有：

38、敘述性的自由文本、結(jié)構(gòu)化文本。強(qiáng)限 制文本、表格、圖表、圖像等。（√） 26、在實(shí)踐中，以動(dòng)態(tài)的場景外觀為主。（） 27、場景內(nèi)包含的知識(shí)只能是關(guān)于未來的。（） 28、描述性場景的目的是為了記錄已經(jīng)得到的需求，即整理每次需求獲取行為中得到的 信息。（√） 29、UML就是以用例來捕獲系統(tǒng)所有的系統(tǒng)需求的。（） 30、用例的內(nèi)容只能包含有正常流程，而不能包含有異常流程。（） 31、用例可以用于各種目的的應(yīng)用，包括描述、探索和解釋。（√） 32、用例是在對現(xiàn)實(shí)世界的探索中或者是在對需求規(guī)格說明的解釋中產(chǎn)生的，是通過功 能分解的方式創(chuàng)建的。（） 33、抽象用例是不能被實(shí)例化的，

39、它必須被包含在其他用例中才能得以執(zhí)行。（√） 34、用例間的泛化關(guān)系是指子用例繼承了父用例的特征。（）并增加了新的特征 35、抽象一方面要求人們關(guān)注重要的信息，同時(shí)又不能忽略次要的內(nèi)容。另一方面也要 求人們將認(rèn)知保留在適當(dāng)?shù)膶哟?，屏蔽更深層次的?xì)節(jié)。（） 36、由于計(jì)算模型的形式化特征不適合于需求工程階段，因此計(jì)算模型不適合用于需求 分析中的建模。（√） 37、具有形式化特征的計(jì)算模型是用戶和開發(fā)者共同理解的模型。（） 38、由于模型需要描述的內(nèi)容太過復(fù)雜的，因此分析模型對模型語言語用的要求不可能 太高。（） 39、軟件需求分析的關(guān)鍵是為真實(shí)世界的問題建立模型，即問題域建模。

40、（√） 40、在“結(jié)構(gòu)化方法一信息工程方法一面向?qū)ο蠓椒ā钡陌l(fā)展歷程中，每一種后來的方 法在吸收了前面方法的重要思想的同時(shí)也替代前面的方法。（） 41、結(jié)構(gòu)化、信息工程和面向?qū)ο笕N方法學(xué)下的需求分析技術(shù)都適合于需求階段全過 程的分析任務(wù)。（）后期 42、上下文圖是 DFD的一個(gè)特定層次，被用來說明系統(tǒng)的上下文環(huán)境，確定系統(tǒng)的邊 界。（√） 43、外部實(shí)體是指處于待構(gòu)建系統(tǒng)之外的人、組織、設(shè)備或者其他軟件系統(tǒng)，但它們要 受系統(tǒng)的控制，開發(fā)者可以以任何方式操縱它們。（） 44、上下文圖以黑盒看待和描述系統(tǒng)的方式使它非常適合描述系統(tǒng)的應(yīng)用環(huán)境、定義系 10 統(tǒng)的邊

41、界，這正是 DFD在層次結(jié)構(gòu)中將其置于最高層的原因。（√） 45、數(shù)據(jù)模型說明了問題域和解系統(tǒng)共享的事物、對共享事物的描述和共享事物之間 的關(guān)系。（√） 46、ERD關(guān)系表達(dá)的不是邏輯上的鏈接（例如整體部分關(guān)系），而是實(shí)體物理上的聯(lián)系。 （） 47、ERD中存在于兩個(gè)實(shí)體之間的關(guān)系是最常見的關(guān)系，稱為二元關(guān)系。（√） 48、ERD中子類型關(guān)系是實(shí)體間自然的業(yè)務(wù)聯(lián)系，而不是人為施加的結(jié)構(gòu)關(guān)系，是一 種特殊的實(shí)體間關(guān)系。（） 49、建立功能／實(shí)體矩陣的過程可以幫助驗(yàn)證過程模型和數(shù)據(jù)模塊的正確性，發(fā)現(xiàn)其中 的錯(cuò)誤、遺漏、冗余和不一致。（√） 50、發(fā)起或觸發(fā)用例的外部用戶以及其他

42、軟件系統(tǒng)等角色被稱為參與者。（√） 51、交互圖是對單個(gè)用例的典型場景的實(shí)現(xiàn)，適合于事務(wù)性業(yè)務(wù)工作的表示。（√） 52、UML行為模型的狀態(tài)圖是以狀態(tài)機(jī)模型的方式進(jìn)行的用例實(shí)現(xiàn)。狀態(tài)圖只能用來 實(shí)現(xiàn)單個(gè)用例。（） 53、OCL無法被用來描述程序的控制邏輯和工作流程。（√） 54、OCL的表達(dá)式定義可以在程序中得到直接的執(zhí)行。（） 55、軟件需求規(guī)格說明文檔是對部分系統(tǒng)功能分配給軟件部分的詳細(xì)描述。（） 56、硬件需求規(guī)格說明文檔是對整個(gè)系統(tǒng)功能當(dāng)中分配給硬件部分的詳細(xì)描述。（√） 57、人機(jī)交互文檔是對整個(gè)系統(tǒng)功能中需要進(jìn)行人機(jī)交互部分的詳細(xì)描述。（√） 58、驗(yàn)證活動(dòng)同樣普遍存在于需求分析過程中。（） 59、需求驗(yàn)證并不是一個(gè)可以一次結(jié)束的活動(dòng)，它可能需要多次、反復(fù)地執(zhí)行驗(yàn)證。（√） 60、前向跟蹤是指需求在被獲取到軟件需求規(guī)格說明文檔之前的演化過程。（）定義