《軟件需求分析》單選填空判斷答案全解

1、軟件需求分析習(xí)題集軟件需求分析課程組編2012 年 4月目錄一、單項(xiàng)選擇題 2二、填空題 5三、判斷題 912軟件需求分析習(xí)題集一、單項(xiàng)選擇題1 、軟件生產(chǎn)中產(chǎn)生需求問(wèn)題的最大原因在于對(duì)應(yīng)用軟件的（）理解不透徹或應(yīng)用不堅(jiān)決。（ A）復(fù)雜性（ B）目的性（ C）模擬性 （ D）正確性2 、需求分析的目的是保證需求的（）。（ A）目的性和一致性 （B）完整性和一致性（ C）正確性和目的性 （D）完整性和目的性3 、系統(tǒng)需求開(kāi)發(fā)的結(jié)果最終會(huì)寫(xiě)入（）。（A）可行性研究報(bào)告（ B）前景和范圍文檔（C）用戶(hù)需求說(shuō)明（ D）系統(tǒng)需求規(guī)格說(shuō)明4 、現(xiàn)實(shí)世界中的（）構(gòu)成了問(wèn)題解決的基本范圍，稱(chēng)為該問(wèn)題的問(wèn)題域。

2、（A）屬性和狀態(tài) （ B）實(shí)體和狀態(tài) （C）實(shí)體和操作（ D ）狀態(tài)和操作5 、功能需求通常分為三個(gè)層次，即業(yè)務(wù)需求、用戶(hù)需求和（）。（A）硬件需求（ B）軟件需求（C ）質(zhì)量屬性（D）系統(tǒng)需求6、比較容易發(fā)現(xiàn)的涉眾稱(chēng)為初始涉眾，又稱(chēng)為（），通常包括客戶(hù)、管理者和相關(guān)的投資者。（ A）關(guān)鍵涉眾 （B）涉眾基線（C）普通涉眾（ D）一般涉眾7、如果在最終的物件（ Final Artifact ）產(chǎn)生之前，一個(gè)中間物件（ Mediate Artifact ）被 用來(lái)在一定廣度和深度范圍內(nèi)表現(xiàn)這個(gè)最終物件，那么這個(gè)中間物件就被認(rèn)為是最終物件在 該廣度和深度上的（ ）。（A）模擬（B）構(gòu)造（C ）原型

3、（D）模型8、按照使用方式進(jìn)行分類(lèi)，原型可分為：演示原型、（）、試驗(yàn)原型和引示系統(tǒng)原型。（ A）非操作原型（ B）系列首發(fā)原型（ C）選定特征原型（ D）嚴(yán)格意義上的原型9、按照功能特征進(jìn)行分類(lèi)，原型可分為：（）、非操作原型、系列首發(fā)原型和選定特征原型。（ A）拼湊原型（ B）樣板原型（ C）紙上向?qū)г停?D ）嚴(yán)格意義上的原型10 、按照開(kāi)發(fā)方法進(jìn)行分類(lèi)，原型可分為：演化式原型和拋棄式原型，其中拋棄式原 型又被細(xì)分為（ ）。（ A）演示原型和試驗(yàn)原型（B）系列首發(fā)原型和選定特征原型（ C）探索式原型和實(shí)驗(yàn)式原型（D）樣板原型和紙上向?qū)г?1 、原型的需求內(nèi)容可以從三個(gè)緯度上分析：即（ ）

4、。（ A）外觀、角色和實(shí)現(xiàn)（ B ）開(kāi)發(fā)、實(shí)現(xiàn)和作用（ C）成本、技術(shù)和實(shí)現(xiàn)（ D ）需求、作用和角色12、當(dāng)用戶(hù)無(wú)法完成主動(dòng)的信息告知，或與需求工程師之間的語(yǔ)言交流無(wú)法產(chǎn)生有效 的結(jié)果時(shí)，有必要采用（ ）。（ A ）民族志（ B）觀察法（ C）話語(yǔ)分析（D）任務(wù)分析13 、以下（）不是情景性的重要性質(zhì)？（A）突現(xiàn)（ B）涉身（C）完善（D）模糊14 、以下（）是情景性的重要性質(zhì)？（ A ）全局（ B）開(kāi)放 （C ）交互（D）即時(shí)）不是需求獲取常見(jiàn)的模型驅(qū)動(dòng)方法？基于場(chǎng)景的方法。 基于采樣的方法15 、下列（ A）面向目標(biāo)的方法（B）（ C）基于用例的方法（D）16 、下列（ ）屬于定量硬數(shù)據(jù)

5、？ （ A）工作手冊(cè) （B）規(guī)章手冊(cè) 17 、下列（ ）屬于定性硬數(shù)據(jù)？ （ A）數(shù)據(jù)收集表（B）月報(bào)表18 、功能目標(biāo)可以分為（ A）安全目標(biāo)和可用性目標(biāo) （ C ）軟目標(biāo)和硬目標(biāo)C）統(tǒng)計(jì)報(bào)表C）年報(bào)表D）備忘錄D）規(guī)章手冊(cè)）。B）D）19 、在表達(dá)軟目標(biāo)的分解和細(xì)化時(shí)使用的 接， Contribution 的作用是）。滿(mǎn)足型目標(biāo)和信息型目標(biāo) 維護(hù)目標(biāo)和實(shí)現(xiàn)目標(biāo)AND Contribution 鏈接和 OR Contribution 鏈（A）積極的 （B）消極的（C）積極的或消極的（D ）不能確定20、AND 鏈接將一個(gè)父目標(biāo)連接到一系列細(xì)化的子目標(biāo)，意思是如果能夠滿(mǎn)足所有細(xì) 化的子目標(biāo)，那

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

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

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

9、需求規(guī)格說(shuō)明（C）結(jié)合面向目標(biāo)的方法，指導(dǎo)需求獲取活動(dòng)的開(kāi)展（D）組織需求獲取得到的信息32 、下列（）是組織場(chǎng)景時(shí)可用的場(chǎng)景關(guān)系。（ A）合取關(guān)系（ B ）定性關(guān)系 （C ）定量關(guān)系（ D）演繹關(guān)系33 、與其他的場(chǎng)景方法相比，用例最大的特點(diǎn)是采用了（）的描述方式。B）動(dòng)態(tài)非結(jié)構(gòu)化文本D）動(dòng)態(tài)結(jié)構(gòu)化文本 ）三種。B）合取、析取和擴(kuò)展 D）包含、擴(kuò)展和泛化（A）靜態(tài)非結(jié)構(gòu)化文本（C）靜態(tài)結(jié)構(gòu)化文本34 、用例之間的關(guān)系主要有（ （A）包含、擴(kuò)展和簡(jiǎn)化 （ C ）包含、多態(tài)和繼承35、分析的活動(dòng)主要包括識(shí)別、定義和結(jié)構(gòu)化，它的目的是獲取某個(gè)可以轉(zhuǎn)換為知識(shí)的 事物的信息，這種分析活動(dòng)被稱(chēng)為（ ）。

10、（ A ）需求信息獲取（ B ）建立軟件系統(tǒng)解決方案（ C）需求信息轉(zhuǎn)化（ D ）建立需求分析模型36 、（ ）是建模最為常用的兩種手段。（ A）具體和抽象（ B ）抽象和分解（ C）分解和細(xì)化（D）抽象和細(xì)化37 、抽象通過(guò)強(qiáng)調(diào)本質(zhì)的特征，（ ）了問(wèn)題的復(fù)雜性。（ A）調(diào)整（B）避免（ C）增加 （D ）減少38、需求分析僅僅需要描述解決方案，不需要探索實(shí)現(xiàn)細(xì)節(jié)的情況下，分析模型又是 （ ）的，尤為適用。（ A）形式化（B）半形式化（C ）結(jié)構(gòu)化（D ）非結(jié)構(gòu)化39、上下文圖描述系統(tǒng)與環(huán)境中外部實(shí)體之間的界限和聯(lián)系。它從現(xiàn)實(shí)世界的角度說(shuō)明 了系統(tǒng)的（ ），并確定了所有的輸入和輸出。（ A）環(huán)

11、境與外觀（ B ）邊界和聯(lián)系 （C）邊界和環(huán)境 （D）輸入和輸出40 、（ ）是結(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）面向問(wèn)題域 （ B）面向解系統(tǒng) （C ）面向設(shè)計(jì) （D）面向需求42 、使用面向問(wèn)題的技術(shù)對(duì)問(wèn)題世界的建模就被稱(chēng)為（ ）需求階段的分析。 （A）前期 （B）中期 （ C）后期 （D）全過(guò)程43 、使用面向解系統(tǒng)的技術(shù)對(duì)軟件系統(tǒng)解決方案的描述稱(chēng)為（ ）需求階段的分析

12、。 （A）前期 （B）中期 （ C）后期 （D）全過(guò)程44 、需求分析活動(dòng)的一個(gè)重要任務(wù)是進(jìn)行（ ），明確用戶(hù)需求的隱含信息，展開(kāi)為 明確的對(duì)軟件系統(tǒng)的行為期望，即系統(tǒng)需求。（ A）需求整理（B ）需求細(xì)化 （C ）需求獲取（D）需求分析45 、在分層結(jié)構(gòu)中， DFD定義了三個(gè)層次類(lèi)別的DFD 圖：（ ）、 0層圖和 N層圖。（ A）1層圖 （ B ）底層圖 （C ）上下文圖 （ D ）頂視圖 46、因?yàn)閿?shù)據(jù)存儲(chǔ)是系統(tǒng)內(nèi)部的功能實(shí)現(xiàn)，所以在將系統(tǒng)視為黑盒的情況下，上下文 圖中不會(huì)出現(xiàn)（ ）。（A）實(shí)體（ B）數(shù)據(jù)存儲(chǔ)實(shí)例（C）需求信息（D）過(guò)程處理47 、數(shù)據(jù)建模技術(shù)能夠彌補(bǔ)過(guò)程建模在（ ）方

13、面的缺陷，它描述數(shù)據(jù)的定義、結(jié) 構(gòu)和關(guān)系等特性。（ A）需求分析（B ）數(shù)據(jù)轉(zhuǎn)換 （C ）數(shù)據(jù)說(shuō)明（D）數(shù)據(jù)分析48 、。概念實(shí)體是一種抽象概念，不考慮概念背后的物理存在，所以通常不包含與之相 關(guān)聯(lián)的其他（ ）。（A）模型（B）特征（即屬性）（C）關(guān)系 （D ）處理49、在 ERD 建模中，實(shí)體通常所指的就是（ ）。（ A）邏輯實(shí)體 （B）概念實(shí)體 （C）物理實(shí)體（D）進(jìn)程實(shí)體50、ERD 中屬性是實(shí)體的特征，不是數(shù)據(jù)。屬性會(huì)以一定的形式存在，這種存在才是 數(shù)據(jù)，被稱(chēng)為屬性的（ ）。（ A）域 （B）實(shí)例（C ）說(shuō)明（D）值51 、ERD 中關(guān)系的度數(shù)（ Degree ）是指參與關(guān)系的實(shí)體數(shù)量

14、，是度量關(guān)系（）的一個(gè)指標(biāo)。（ A）模型（B）復(fù)雜度（C）精確度（ D）屬性值52 、ERD 中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最大基數(shù)又被稱(chēng)為（）。（ A）鍵約束 （B）參與約束（ C）自然約束 （D）一般約束 53、在實(shí)體之間建立關(guān)系時(shí)，可能會(huì)產(chǎn)生一些附帶的實(shí)體，被稱(chēng)為關(guān)聯(lián)實(shí)體，最常見(jiàn) 的形式是（ ）。（ A）邏輯實(shí)體（B ）進(jìn)程實(shí)體 （C ）概念實(shí)體（D）自然實(shí)體54 、在實(shí)現(xiàn) ERD 與過(guò)程模型同步的技術(shù)中，（ ）是一種較為常見(jiàn)的技術(shù)。（A）用例圖（B）數(shù)據(jù)流圖（C）功能實(shí)體矩陣（D ）微規(guī)格說(shuō)明55 、下列（ ）不是用例模型中的關(guān)系？（ A）屬性（B）關(guān)聯(lián)（C）泛化（D）包含56、

15、系統(tǒng)邊界是指一個(gè)系統(tǒng)所包含的系統(tǒng)成分與系統(tǒng)外事物的分界線。用例模型使用 一個(gè)（ ）來(lái)表示系統(tǒng)邊界，以顯示系統(tǒng)的上下文環(huán)境。（ A）圓形框（B）菱形框（ C）虛線框 （D ）矩形框57 、UML 使用的行為模型有三種，即：（ ）。（ A）交互圖、狀態(tài)圖和順序圖（ B）順序圖、通信圖和時(shí)間圖（ C）交互圖、狀態(tài)圖和活動(dòng)圖（D）交互概述圖、通信圖和時(shí)間圖58 、項(xiàng)目的前景和范圍文檔、用戶(hù)需求文檔都被視為屬于（ ），重點(diǎn)都是用戶(hù)的現(xiàn) 實(shí)世界。（ A）開(kāi)發(fā)文檔（B ）需求文檔 （C ）前景文檔（D）用戶(hù)文檔59、系統(tǒng)需求規(guī)格說(shuō)明文檔、軟件需求規(guī)格說(shuō)明文檔、硬件需求規(guī)格說(shuō)明文檔、接口 需求規(guī)格說(shuō)明文檔和人

16、機(jī)交互文檔一起被用于系統(tǒng)開(kāi)發(fā)的目的，都被認(rèn)為是開(kāi)發(fā)文檔。（ A）開(kāi)發(fā)文檔（B ）需求文檔 （C ）過(guò)程文檔（D）用戶(hù)文檔60 、下列（ ）不是需求規(guī)格說(shuō)明文檔的讀者？（ A）項(xiàng)目管理者（ B ）編程人員（ C）銷(xiāo)售商 （D）律師 二、填空題1、傳統(tǒng)的需求分析方法都是從設(shè)計(jì)領(lǐng)域轉(zhuǎn)入分析領(lǐng)域的。2、面向?qū)I(yè)用戶(hù)的純工具型軟件分析階段的主要目的是為充分利用創(chuàng)新優(yōu)勢(shì)而進(jìn)行巧 妙的功能安排。3、面向普通用戶(hù)的純工具型軟件進(jìn)行分析的主要目的是進(jìn)行方案權(quán)衡，尋找一套切實(shí) 有效的功能配置。4、應(yīng)用型軟件分析階段的主要目的是發(fā)現(xiàn)人們利用軟件的原因（目的），找出需要軟件 解決的問(wèn)題，理解應(yīng)用環(huán)境中的領(lǐng)域知識(shí)，保證

17、功能的模擬性。5、需求工程是所有需求處理活動(dòng)的總和，它收集信息、分析問(wèn)題、整合觀點(diǎn)、記錄需 求并驗(yàn)證其正確性，最終反映軟件被應(yīng)用后與其環(huán)境互動(dòng)形成的期望效應(yīng)。6、軟件需求開(kāi)發(fā)用來(lái)確定系統(tǒng)需求中應(yīng)該由軟件滿(mǎn)足的部分，將其映射為軟件行為， 產(chǎn)生軟件需求規(guī)格說(shuō)明。7、約束是不受解系統(tǒng)影響，卻會(huì)給解系統(tǒng)帶來(lái)極大影響的問(wèn)題域特性。8、優(yōu)秀的需求應(yīng)該具備 7 個(gè)特性，即完整性、正確性、精確性、可行性、必要性、無(wú) 歧義和可驗(yàn)證。9、所有對(duì)軟件系統(tǒng)的開(kāi)發(fā)和應(yīng)用具有發(fā)言權(quán)和決定權(quán)的人統(tǒng)稱(chēng)為涉眾。10 、按照媒介載體進(jìn)行分類(lèi)，原型可分為：樣板原型和紙上向?qū)г汀?1 、演示原型主要被用在項(xiàng)目啟動(dòng)階段。12、演示原

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

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

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

21、建立的模型是進(jìn)行信息整理和歸類(lèi)的很好的框架依據(jù)。32、模型驅(qū)動(dòng)方法的模型是在前期需求階段的分析中建立的。33、目標(biāo)模型的一個(gè)核心要素是元素之間的關(guān)系，稱(chēng)為鏈接。34、目標(biāo)模型的鏈接有兩類(lèi)：一類(lèi)是目標(biāo)之間的鏈接；另一類(lèi)是目標(biāo)與其他模型元素之 間的鏈接。35 、面向目標(biāo)方法的處理過(guò)程可以分為三個(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、場(chǎng)景具有重點(diǎn)描述真實(shí)世界的特征，它利用情景、行為者之間的交互、事件隨時(shí)間 的演化等方式來(lái)敘述性地描述系統(tǒng)的使用。38、靜態(tài)外觀

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

23、的一種，是靜態(tài)的結(jié)構(gòu)化文本描述。46、在高層的功能需求獲取完備之前，用例的產(chǎn)生方式中不允許使用功能分解方式。47、單個(gè)用例描述了系統(tǒng)的功能片段，系統(tǒng)的所有用例基于一定的關(guān)系組織起來(lái)，建立 用例模型，就可以描述整個(gè)系統(tǒng)的功能。48、原有用例和新建立的抽象用例的關(guān)系即為包含關(guān)系。49、在需求工程中，主要產(chǎn)生三類(lèi)重要的文檔：項(xiàng)目前景和范圍文檔、用戶(hù)需求文檔以 及需求規(guī)格說(shuō)明。用例文檔通常被用來(lái)代替用戶(hù)需求文檔，起到記錄、交流領(lǐng)域信息和用戶(hù) 期望的作用。50、需求獲取得到的信息和需求開(kāi)發(fā)應(yīng)該建立的軟件系統(tǒng)解決方案之間有著很大的差 距。需求分析就是用來(lái)解決這個(gè)差距的需求工程活動(dòng)。51 、需求分析的根本任

24、務(wù)是：建立分析模型并創(chuàng)建解決方案。52、分解將單個(gè)復(fù)雜和難以理解的問(wèn)題分解成多個(gè)相對(duì)更容易的子問(wèn)題，并掌握各子 問(wèn)題之間的聯(lián)系。53、基于軟件構(gòu)建單位及其之間的關(guān)系建立的模型，用來(lái)說(shuō)明軟件邏輯上的構(gòu)建方式 和實(shí)現(xiàn)方式，由于它使用的組元及其關(guān)系都是軟件的元素，因此它是來(lái)自于軟件的模型，稱(chēng) 為計(jì)算模型。54 、模型語(yǔ)言的三要素：語(yǔ)法、語(yǔ)義、語(yǔ)用。其中語(yǔ)用給出了一個(gè)模型元素描述的更 寬廣的上下文，以及影響該模型元素意義的約束和假定。55、互相之間建立了語(yǔ)義聯(lián)系的多個(gè)模型，集成在一起通常被稱(chēng)為視圖。56 、需求分析方法主要有：結(jié)構(gòu)化方法、信息工程方法和面向?qū)ο蠓椒?。其中面向?qū)?象方法是目前工業(yè)界使用的

25、主流方法。57、信息工程和結(jié)構(gòu)化方法的本質(zhì)差別在于解決問(wèn)題的策略不同。58、前期需求階段分析的重點(diǎn)是理解問(wèn)題世界，因此它關(guān)注的是整個(gè)問(wèn)題世界，注重 于系統(tǒng)的環(huán)境、開(kāi)發(fā)組織的業(yè)務(wù)背景、涉眾的特征以及目標(biāo)等等，軟件系統(tǒng)只是整個(gè)背景下 的一個(gè)要素。59、后期需求階段分析關(guān)注的是解系統(tǒng)解決方案的建立，因此它以軟件系統(tǒng)為中心， 注重于分析系統(tǒng)的內(nèi)部功能以及它與環(huán)境的互動(dòng)，是對(duì)系統(tǒng)功能的詳細(xì)信息的分析。60、以軟件復(fù)用為核心，建立產(chǎn)品族的方法被稱(chēng)為產(chǎn)品線。61 、需求協(xié)商活動(dòng)既包括對(duì)目標(biāo)沖突的處理，也包括對(duì)需求細(xì)節(jié)沖突的處理。 62、微規(guī)格說(shuō)明被用來(lái)描述 DFD 過(guò)程分解結(jié)構(gòu)中最底層過(guò)程的處理邏輯。63

26、、 DFD 中所有的外部實(shí)體聯(lián)合起來(lái)構(gòu)成了軟件系統(tǒng)的外部上下文環(huán)境，它們與軟件 系統(tǒng)的交互流就是軟件系統(tǒng)與其外部環(huán)境的接口，這些接口聯(lián)合起來(lái)定義了軟件系統(tǒng)的系統(tǒng) 邊界。64、數(shù)據(jù)流是指數(shù)據(jù)的運(yùn)動(dòng)，它是系統(tǒng)與其環(huán)境之間或者系統(tǒng)內(nèi)兩個(gè)過(guò)程之間的通信 形式。65 、 DFD 的 0層圖中的每個(gè)過(guò)程都可以進(jìn)行分解，被分解的過(guò)程稱(chēng)為父過(guò)程，分解后 產(chǎn)生的揭示更多細(xì)節(jié)的 DFD 圖稱(chēng)為子圖。66 、DFD 的 0層圖通常被用來(lái)作為整個(gè)系統(tǒng)的功能概圖。67、為了保證 DFD 圖的可理解性， 0層圖應(yīng)該被描述的簡(jiǎn)潔、清晰，所以在描述復(fù)雜的 系統(tǒng)時(shí)， 0層圖中不應(yīng)出現(xiàn)太過(guò)具體的過(guò)程和數(shù)據(jù)存儲(chǔ)。68 、DFD 中

27、對(duì) 0層圖的過(guò)程分解產(chǎn)生的子圖稱(chēng)為 1層圖。69、數(shù)據(jù)建模建立的模型稱(chēng)為數(shù)據(jù)模型，是問(wèn)題域和解系統(tǒng)共享的知識(shí)集合，通常能 夠反映企業(yè)業(yè)務(wù)的核心知識(shí)。70、數(shù)據(jù)模型的內(nèi)容是問(wèn)題域和解系統(tǒng)所共享的知識(shí)模型，可以用問(wèn)題域的語(yǔ)言來(lái)解 釋?zhuān)部梢杂媒庀到y(tǒng)的語(yǔ)言來(lái)解釋?zhuān)€可以用介于問(wèn)題域和解系統(tǒng)之間的中立語(yǔ)言來(lái)解釋。71 、在需求工程中，數(shù)據(jù)建模建立的是概念數(shù)據(jù)模型和邏輯數(shù)據(jù)模型，不涉及物理數(shù) 據(jù)模型。72 、 ERD 的邏輯實(shí)體是對(duì)概念實(shí)體的細(xì)化，擁有完整的特征描述。73、數(shù)據(jù)建模中對(duì)行為和事件的建模需要是為了了解它們?cè)谀承r(shí)刻的快照或者運(yùn)行 環(huán)境信息，而不是它們所體現(xiàn)出來(lái)的功能和達(dá)成的效果，所以稱(chēng)這類(lèi)

28、實(shí)體為進(jìn)程實(shí)體。74 、 ERD 中屬性就是可以對(duì)實(shí)體進(jìn)行描述的特征，一系列屬性的存在集成起來(lái)就可以 描述一個(gè)實(shí)體的實(shí)例。75 、ERD 中屬性取值的受限制范圍稱(chēng)為域（ Domain ）。76 、 ERD 為實(shí)體指定一個(gè)屬性或多個(gè)屬性的組合，可以用來(lái)唯一地確定和標(biāo)識(shí)每個(gè)實(shí) 例，這些屬性或?qū)傩缘慕M合稱(chēng)為實(shí)體的標(biāo)識(shí)符，又稱(chēng)為鍵。77 、一個(gè)實(shí)體可能有多個(gè)鍵，這些鍵都被稱(chēng)為候選鍵。78、通常人們從多個(gè)候選鍵中選擇和使用固定的某一個(gè)鍵來(lái)進(jìn)行實(shí)例的標(biāo)識(shí)，這個(gè)被 選中的候選鍵被稱(chēng)為主鍵，沒(méi)有被選做主鍵的候選鍵被稱(chēng)為替代鍵。79、實(shí)體實(shí)例大多數(shù)屬性的值都是需要從現(xiàn)實(shí)中獲取的，稱(chēng)為存儲(chǔ)屬性。80 、有些實(shí)體實(shí)

29、例的屬性的值是可以由其他屬性的值計(jì)算得出的，稱(chēng)為導(dǎo)出屬性。 81、關(guān)系是存在于一個(gè)或多個(gè)實(shí)體之間的自然業(yè)務(wù)聯(lián)系。82 、只有一個(gè)實(shí)體參與的關(guān)系存在于實(shí)體的不同實(shí)例之間，稱(chēng)為一元關(guān)系，又稱(chēng)為遞 歸關(guān)系。83 、 ERD 中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最小基數(shù)又被稱(chēng)為參與約束。84、ERD 中一個(gè)實(shí)體在關(guān)系中的最大基數(shù)是指，對(duì)關(guān)系中任意的其他實(shí)體實(shí)例，該實(shí) 體可能參與關(guān)系的最大數(shù)量。85、ERD 中一個(gè)實(shí)體在關(guān)系中的最小基數(shù)是指，對(duì)關(guān)系中任意的其他實(shí)體實(shí)例，該實(shí)體可能參與關(guān)系的最小數(shù)量。86 、 ERD 中被關(guān)系影響的實(shí)體主要是弱實(shí)體和關(guān)聯(lián)實(shí)體。87、用例模型的基本元素有四種：用例、參與者、

30、關(guān)系和系統(tǒng)邊界。88、UML 行為模型是用例模型的實(shí)現(xiàn)，以更加詳細(xì)的方式說(shuō)明用例所描述的系統(tǒng)行為。89、UML 行為模型的活動(dòng)圖是依據(jù)處理流程進(jìn)行的用例實(shí)現(xiàn)。90 、 UML 行為模型的交互圖通常描述的是單個(gè)用例的典型場(chǎng)景。91、接口需求規(guī)格說(shuō)明文檔是對(duì)整個(gè)系統(tǒng)中需要軟、硬件協(xié)同實(shí)現(xiàn)部分的詳細(xì)描述。92、優(yōu)秀的需求規(guī)格說(shuō)明文檔應(yīng)該具備：正確性、無(wú)歧義、完備性、一致性、根據(jù)重 要性和穩(wěn)定性分級(jí)、可驗(yàn)證、可修改、可跟蹤等特性。93、需求驗(yàn)證常見(jiàn)方法有：需求評(píng)審、原型與模擬、測(cè)試用例開(kāi)發(fā)、用戶(hù)手冊(cè)編制、 利用跟蹤關(guān)系和自動(dòng)化分析。94 、評(píng)審又被稱(chēng)為同級(jí)評(píng)審，是指由作者之外的其他人來(lái)檢查產(chǎn)品問(wèn)題的方

31、法。95、在系統(tǒng)驗(yàn)證中，評(píng)審是主要的靜態(tài)分析手段，所以評(píng)審也是需求評(píng)審的一種主要 方法。96 、需求基線的維護(hù)主要包括配置管理和狀態(tài)維護(hù)。97、需求跟蹤是以軟件需求規(guī)格說(shuō)明文檔為基線，在向前和向后兩個(gè)方向上，描述需 求以及跟蹤需求變化的能力。98 、從需求向后回溯（前向跟蹤的兩種聯(lián)系之一）說(shuō)明軟件需求來(lái)源于哪些涉眾的需 要和目標(biāo)。99、后向跟蹤是指需求被定義到軟件需求規(guī)格說(shuō)明文檔之后的演化過(guò)程。100 、后向跟蹤包括兩種聯(lián)系：從需求向前跟蹤和回溯到需求的跟蹤。三、判斷題1、需求工程包括需求獲取和需求開(kāi)發(fā)兩個(gè)方面。（×）2、需求驗(yàn)證是需求工程中最后一個(gè)活動(dòng)。（×）3、軟件系統(tǒng)

32、能夠與問(wèn)題域進(jìn)行交互和相互影響的原因在于，軟件系統(tǒng)中的某些部分對(duì)問(wèn) 題域中的某些部分具有模擬特性。（）4、規(guī)格說(shuō)明是問(wèn)題域?yàn)闈M(mǎn)足用戶(hù)需求而提供的解決方案，規(guī)定了解系統(tǒng)的行為特征。（×）5、業(yè)務(wù)需求具有明顯的目的性和較高的抽象性，經(jīng)過(guò)明確和細(xì)化的處理，可以直接轉(zhuǎn)化 為系統(tǒng)需求。（×）6、需求開(kāi)發(fā)的一些特性決定了需求開(kāi)發(fā)過(guò)程只能是一個(gè)簡(jiǎn)單的線性增量過(guò)程。（×）7、對(duì)于需求不確定性比較小的項(xiàng)目，用戶(hù)參與可以取得比較好的效果，但對(duì)于需求不確 定性比較大的項(xiàng)目，用戶(hù)參與反而可能帶來(lái)阻礙作用。（×）8、按照構(gòu)建技術(shù)進(jìn)行分類(lèi)，原型可分為：水平原型和垂直原型。（）9、嚴(yán)

33、格意義上的原型主要被用在需求分析階段。（）10 、要完成相同的功能，構(gòu)建拋棄式原型比構(gòu)建演化式原型所花費(fèi)的代價(jià)要大得多。（×）11 、水平原型方法僅僅實(shí)現(xiàn)選定功能實(shí)現(xiàn)的所有層次，能夠處理較大范圍的功能。（×）12、垂直原型方法會(huì)觸及選定功能所有層次中的某些特定層次，處理的功能范圍通常較 小。（×）13 、建立外觀原型時(shí)重在原型的用戶(hù)界面和交互方式，原型的功能和技術(shù)實(shí)現(xiàn)細(xì)節(jié)就會(huì) 被簡(jiǎn)化處理。（）14、如果選擇的開(kāi)發(fā)方法是實(shí)驗(yàn)式或者探索式開(kāi)發(fā)方法，應(yīng)該盡量花費(fèi)最小的代價(jià)，爭(zhēng) 取最快的速度，忽略或簡(jiǎn)化不重要的功能處理。（）15 、原型修正主要依據(jù)評(píng)估人員的反饋，可以忽略

34、事先的原型調(diào)整計(jì)劃。（×）16、文檔審查是一種傳統(tǒng)的需求獲取方法，是專(zhuān)門(mén)針對(duì)文檔進(jìn)行的需求獲取活動(dòng)。（）17、由于文檔是來(lái)自于當(dāng)前計(jì)算機(jī)或手工系統(tǒng)的產(chǎn)物，因此它是正確的，也正是客戶(hù)所 需要的。（×）18 、成功的需求獲取任務(wù)不僅要求成功地執(zhí)行每一次具體的需求獲取行為，還要求成功 地處理多次獲取行為之間的關(guān)系。（）19 、軟目標(biāo)是一類(lèi)無(wú)法清晰判斷是否滿(mǎn)足的目標(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è)自上

35、而下分解的過(guò)程，也就是一個(gè)不斷發(fā)現(xiàn)和細(xì)化的過(guò)程。（×）23、對(duì)系統(tǒng)的現(xiàn)狀和背景進(jìn)行分析往往能夠發(fā)現(xiàn)重要的目標(biāo)，得到一些明確的問(wèn)題和缺 陷，它們的反面就是系統(tǒng)需要實(shí)現(xiàn)的目標(biāo)。（）24、場(chǎng)景被人們廣泛接受的原因是因?yàn)槿藗兏鼉A向于會(huì)對(duì)真實(shí)事件和真實(shí)事物的描述產(chǎn) 生反應(yīng)。（）25、描述場(chǎng)景時(shí)所使用的常見(jiàn)媒介形式主要有：敘述性的自由文本、結(jié)構(gòu)化文本。強(qiáng)限 制文本、表格、圖表、圖像等。（）26 、在實(shí)踐中，以動(dòng)態(tài)的場(chǎng)景外觀為主。（×）27 、場(chǎng)景內(nèi)包含的知識(shí)只能是關(guān)于未來(lái)的。（×）28 、描述性場(chǎng)景的目的是為了記錄已經(jīng)得到的需求，即整理每次需求獲取行為中得到的 信息。（）29、UML 就是以用例來(lái)捕獲系統(tǒng)所有的系統(tǒng)需求的。（×）30 、用例的內(nèi)容只能包含有正常流程，而不能包含有異常流程。（×）31、用例可以用于各種目的的應(yīng)用，包括描述、探索和解釋。（）32、用例是在對(duì)現(xiàn)實(shí)世界的探索中或者是在對(duì)需求規(guī)格說(shuō)明的解釋中產(chǎn)生的，是通過(guò)功 能分解的方式創(chuàng)建的。（×）33、抽象用例是不能被實(shí)例化的，它必須被包含在其他用例中才能得以執(zhí)行。（）34、用例間的泛化關(guān)系是指子用例繼承了父用例的特征。（×）并增加了新的特征35 、抽象一方面要求人們關(guān)注重要的信息，同時(shí)又不能忽略次要的內(nèi)容。另一方面也要 求人們將認(rèn)知保留在適當(dāng)?shù)?/p>