軟件需求習(xí)題

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

2、分為三個(gè)層次，即業(yè)務(wù)需求、用戶需求和（D ）。 （A）硬件需求 （B）軟件需求 （C）質(zhì)量屬性 （D）系統(tǒng)需求 6、比較容易發(fā)現(xiàn)的涉眾稱為初始涉眾，又稱為（ B），通常包括客戶、管理者和相關(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)為是最終物件在該廣度和深度上的（C ）。 （A）模擬 （B）構(gòu)造 （C）原型 （D）模型 8、按照使用方式進(jìn)行分類，原型可分為：演示原型、（D ）、試驗(yàn)原型

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

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

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

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

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

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

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

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

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

12、求階段的分析。 （A）前期 （B）中期 （C）后期 （D）全過(guò)程 44、需求分析活動(dòng)的一個(gè)重要任務(wù)是進(jìn)行（B ），明確用戶需求的隱含信息，展開為明確的對(duì)軟件系統(tǒng)的行為期望，即系統(tǒng)需求。 （A）需求整理 （B）需求細(xì)化 （C）需求獲取 （D）需求分析 45、在分層結(jié)構(gòu)中，DFD定義了三個(gè)層次類別的DFD圖：（C ）、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)（ B）。 （A）實(shí)體 （B）數(shù)據(jù)存儲(chǔ)實(shí)例 （C）需求信息 （D）過(guò)程處理 47、數(shù)據(jù)建模技術(shù)能夠彌補(bǔ)過(guò)程建模在（ C）

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)的其他（B ）。 （A）模型 （B）特征（即屬性） （C）關(guān)系 （D）處理 49、在ERD建模中，實(shí)體通常所指的就是（ A）。 （A）邏輯實(shí)體 （B）概念實(shí)體 （C）物理實(shí)體 （D）進(jìn)程實(shí)體 50、ERD中屬性是實(shí)體的特征，不是數(shù)據(jù)。屬性會(huì)以一定的形式存在，這種存在才是數(shù)據(jù)，被稱為屬性的（D ）。 （A）域 （B）實(shí)例 （C）說(shuō)明 （D）值 51、ERD中關(guān)系的度數(shù)（Degree）是指參與關(guān)系的實(shí)體數(shù)

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

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

16、檔、接口需求規(guī)格說(shuō)明文檔和人機(jī)交互文檔一起被用于系統(tǒng)開發(fā)的目的，都被認(rèn)為是開發(fā)文檔。 A（A）開發(fā)文檔 （B）需求文檔 （C）過(guò)程文檔 （D）用戶文檔 60、下列（C ）不是需求規(guī)格說(shuō)明文檔的讀者？ （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)勢(shì)而進(jìn)行巧妙的功能安排。 3、面向普通用戶的純工具型軟件進(jìn)行分析的主要目的是進(jìn)行方案權(quán)衡，尋找一套切實(shí)有效的功能配置。 4、應(yīng)用型軟件分析階段的主要目的是發(fā)現(xiàn)人們利用軟件的原因（目的），找出需要軟件解決的問(wèn)題

17、，理解應(yīng)用環(huán)境中的領(lǐng)域知識(shí)，保證功能的模擬性。 5、需求工程是所有需求處理活動(dòng)的總和，它收集信息、分析問(wèn)題、整合觀點(diǎn)、記錄需求并驗(yàn)證其正確性，最終反映軟件被應(yīng)用后與其環(huán)境互動(dòng)形成的期望效應(yīng)。 6、軟件需求開發(fā)用來(lái)確定系統(tǒng)需求中應(yīng)該由軟件滿足的部分，將其映射為軟件行為，產(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)的開發(fā)和應(yīng)用具有發(fā)言權(quán)和決定權(quán)的人統(tǒng)稱為涉眾。 10、按照媒介載體進(jìn)行分類，原型可分為：樣板原型和紙上向?qū)г汀?11、演示原型主要

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

19、要注意原型的健壯性和代碼的質(zhì)量。 19、使用實(shí)驗(yàn)式開發(fā)方法，需要實(shí)現(xiàn)多種技術(shù)方案，考察重要的系統(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é)同問(wèn)題都具有突現(xiàn)的情景性。 23、民族志的一個(gè)主要應(yīng)用目的就是研究和解決復(fù)雜的協(xié)同問(wèn)題。 24、復(fù)雜的工作總會(huì)同時(shí)存在著正常流程和異常流程，異常流程大多是一些特殊情況下的處理，限定了異常處理的上下文環(huán)境，即異常處理具有局部的情景性。 25、有很多重要工作的

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

21、信息的整理和歸類，其中模型驅(qū)動(dòng)方法所建立的模型是進(jìn)行信息整理和歸類的很好的框架依據(jù)。 32、模型驅(qū)動(dòng)方法的模型是在前期需求階段的分析中建立的。 33、目標(biāo)模型的一個(gè)核心要素是元素之間的關(guān)系，稱為鏈接。 34、目標(biāo)模型的鏈接有兩類：一類是目標(biāo)之間的鏈接；另一類是目標(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)敘

22、述性地描述系統(tǒng)的使用。 38、靜態(tài)外觀的場(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)景提供交互性，它允許用戶在一定程度上控制和改變場(chǎng)景的變化時(shí)序或者效果。 41、具體場(chǎng)景，又稱為實(shí)例場(chǎng)景，是對(duì)個(gè)別行為者、事件、情節(jié)的細(xì)節(jié)描述。 42、抽象場(chǎng)景，又稱為類型場(chǎng)景，是以經(jīng)驗(yàn)中的類別和抽象概念來(lái)描述事實(shí)。 43、探索性場(chǎng)景可以用來(lái)進(jìn)行需求獲取和需求建模與分析。 44、每個(gè)用例是對(duì)相關(guān)場(chǎng)景集合的敘述性的文本描述，這些場(chǎng)景是用戶和系統(tǒng)之間的交互行為序列

23、，幫助實(shí)現(xiàn)用戶的目的。 45、用例是場(chǎng)景方法中的一種，是靜態(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)生三類重要的文檔：項(xiàng)目前景和范圍文檔、用戶需求文檔以及需求規(guī)格說(shuō)明。用例文檔通常被用來(lái)代替用戶需求文檔，起到記錄、交流領(lǐng)域信息和用戶期望的作用。 50、需求獲取得到的信息和需求開發(fā)應(yīng)該建立的軟件系統(tǒng)解決方案之間有著很大的差距。需求分析就是用來(lái)解決

24、這個(gè)差距的需求工程活動(dòng)。 51、需求分析的根本任務(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)自于軟件的模型，稱為計(jì)算模型。 54、模型語(yǔ)言的三要素：語(yǔ)法、語(yǔ)義、語(yǔ)用。其中語(yǔ)用給出了一個(gè)模型元素描述的更寬廣的上下文，以及影響該模型元素意義的約束和假定。 55、互相之間建立了語(yǔ)義聯(lián)系的多個(gè)模型，集成在一起通常被稱為視圖。 56、需求分析方法主要有：結(jié)構(gòu)化方法、信息工程方法和面向

25、對(duì)象方法。其中面向?qū)ο蠓椒ㄊ悄壳肮I(yè)界使用的主流方法。 57、信息工程和結(jié)構(gòu)化方法的本質(zhì)差別在于解決問(wèn)題的策略不同。 58、前期需求階段分析的重點(diǎn)是理解問(wèn)題世界，因此它關(guān)注的是整個(gè)問(wèn)題世界，注重于系統(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)，是對(duì)系統(tǒng)功能的詳細(xì)信息的分析。 60、以軟件復(fù)用為核心，建立產(chǎn)品族的方法被稱為產(chǎn)品線。 61、需求協(xié)商活動(dòng)既包括對(duì)目標(biāo)沖突的處理，也包括對(duì)需求細(xì)節(jié)沖突的處理。 62、微規(guī)格說(shuō)明被用來(lái)描述DFD

26、過(guò)程分解結(jié)構(gòu)中最底層過(guò)程的處理邏輯。 63、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ò)程稱為父過(guò)程，分解后產(chǎn)生的揭示更多細(xì)節(jié)的DFD圖稱為子圖。 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、

27、DFD中對(duì)0層圖的過(guò)程分解產(chǎn)生的子圖稱為1層圖。 69、數(shù)據(jù)建模建立的模型稱為數(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)解釋，也可以用解系統(tǒng)的語(yǔ)言來(lái)解釋，還可以用介于問(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á)成的效果，所以稱這類實(shí)

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

29、由其他屬性的值計(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ù)是指，對(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、用例模型的基本元素有四種：用例、參與者、關(guān)系和系統(tǒng)邊界。 88、UM

30、L行為模型是用例模型的實(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)證常見方法有：需求評(píng)審、原型與模擬、測(cè)試用例開發(fā)、用戶手冊(cè)編制、利用跟蹤關(guān)系和自動(dòng)化分析。 94、評(píng)審又被稱為同級(jí)評(píng)審，是指由作者之外的其他人來(lái)檢查產(chǎn)品問(wèn)題的方法。 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)源于哪些涉眾的