《軟件需求分析》習(xí)題集(共38頁(yè))

《《軟件需求分析》習(xí)題集(共38頁(yè))》由會(huì)員分享，可在線閱讀，更多相關(guān)《《軟件需求分析》習(xí)題集(共38頁(yè))（38頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、精選優(yōu)質(zhì)文檔-----傾情為你奉上 《軟件需求分析》習(xí)題集 《軟件需求分析》課程組編 2012年 4月 專心---專注---專業(yè) 目 錄 一、單項(xiàng)選擇題………………………………………………2 二、填空題……………………………………………………5 三、判斷題……………………………………………………9 四、名詞解釋題………………………………………………11 五、問答題……………………………………………………14 六、案例分析題………………………………………………28 1 《軟件需求分析》習(xí)題集 一、單項(xiàng)選擇題 1、軟件生產(chǎn)中產(chǎn)生

2、需求問題的最大原因在于對(duì)應(yīng)用軟件的（ ）理解不透徹或應(yīng)用不 堅(jiān)決。 （A）復(fù)雜性（B）目的性 （C）模擬性（D）正確性 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ù)需求、用戶需求

3、和（ ）。 （A）硬件需求（B）軟件需求 （C）質(zhì)量屬性 （D）系統(tǒng)需求 6、比較容易發(fā)現(xiàn)的涉眾稱為初始涉眾，又稱為（ ），通常包括客戶、管理者和相關(guān) 的投資者。 （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)原型

4、和引示系統(tǒng)原 型。 （A）非操作原型（B）系列首發(fā)原型（C）選定特征原型（D）嚴(yán)格意義上的原型 9、按照功能特征進(jìn)行分類，原型可分為：（ ）、非操作原型、系列首發(fā)原型和選定 特征原型。 （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）成本、技

5、術(shù)和實(shí)現(xiàn) （B）開發(fā)、實(shí)現(xiàn)和作用 （D）需求、作用和角色 12、當(dāng)用戶無法完成主動(dòng)的信息告知，或與需求工程師之間的語言交流無法產(chǎn)生有效 的結(jié)果時(shí)，有必要采用（ ）。 （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）基于場(chǎng)景的方法。 （D）基于采

6、樣的方法 16、下列（ ）屬于定量硬數(shù)據(jù)？ （A）工作手冊(cè) 17、下列（ （B）規(guī)章手冊(cè) （C）統(tǒng)計(jì)報(bào)表 （D）備忘錄 ）屬于定性硬數(shù)據(jù)？ （A）數(shù)據(jù)收集表 （B）月報(bào)表 （C）年報(bào)表 （D）規(guī)章手冊(cè) 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)

7、連接到一系列細(xì)化的子目標(biāo)，意思是如果能夠滿足所有細(xì) ）。 （C）積極的或消極的 （D）不能確定 化的子目標(biāo)，那么將（ ）父目標(biāo)。 （A）無法確定 （B）阻礙 （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）場(chǎng)景 （C）操作 （D）概念 ）。 （A）獲取目標(biāo) （

8、B）確定解決方案 （C）建立目標(biāo)模型 （D）發(fā)現(xiàn)問題和缺陷 24、場(chǎng)景的分類框架將場(chǎng)景方法從場(chǎng)景的（ ）4個(gè)方面進(jìn)行了分類和描述。 （A）形式、目的、內(nèi)容和生命周期 （C）描述、目的、內(nèi)容和形式 （B）外觀、目的、內(nèi)容和生命周期 （D）描述、外觀、目的和內(nèi)容 25、場(chǎng)景的形式是指場(chǎng)景的表達(dá)模式，從形式上分為兩個(gè)方面：（ ） （A）內(nèi)容和目的（B）內(nèi)容和生命周期（C）描述和外觀（D）描述和目的 26、描述場(chǎng)景所使用的表示法要符合正規(guī)性要求，一般可使用非形式化語言、半形式 化語言和形式化語言。在實(shí)踐中，（ ）是主要的描述方式。 （B）非形式化的自然語言 （D）非形式

9、化的設(shè)計(jì)語言 （A）形式化的程序語言 （C）形式化的圖形工具 27、外觀是指場(chǎng)景被表達(dá)出來時(shí)的效果，主要有（ （A）靜態(tài)、動(dòng)態(tài)和結(jié)構(gòu)化 （B）線性、非線性和交互 （C）靜態(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í)類型。它被分為 6個(gè)不同的方面。下列（ ）三種類型。 ） 不是場(chǎng)景的內(nèi)容。 （A）主要關(guān)注點(diǎn) （B）環(huán)境范圍 （C）目的 （D）抽象層次 29、需求工程利用場(chǎng)景的目的可能有三種：即：（ ）。 （A）描述、探索和解釋 （C）描述、探索和發(fā)現(xiàn) （B）描述、表示和探索 （D）表示、解釋和證明 30、使用解釋性場(chǎng)景在需求分析

10、時(shí)能夠（ ），或者被用于進(jìn)行需求的驗(yàn)證。 （A）提高模型的復(fù)雜性 （B）降低模型的復(fù)雜性 3 （C）提高預(yù)見性 31、下列（ （D）降低編程量 ）不是場(chǎng)景方法在需求工程中的應(yīng)用。 （A）幫助進(jìn)行詳細(xì)的需求分析 （B）編寫系統(tǒng)需求規(guī)格說明 （C）結(jié)合面向目標(biāo)的方法，指導(dǎo)需求獲取活動(dòng)的開展 （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)是采用了（ ）的描述方式。 （A）靜態(tài)非結(jié)構(gòu)化文本 （C）靜態(tài)結(jié)構(gòu)化文本 （

11、B）動(dòng)態(tài)非結(jié)構(gòu)化文本 （D）動(dòng)態(tài)結(jié)構(gòu)化文本 ）三種。 34、用例之間的關(guān)系主要有（ （A）包含、擴(kuò)展和簡(jiǎn)化 （C）包含、多態(tài)和繼承 （B）合取、析取和擴(kuò)展 （D）包含、擴(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ù)雜性。

12、 （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í)世界的角度說明 了系統(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)系圖 E

13、RD（C）狀態(tài)轉(zhuǎn)換圖（D）上下文圖 41、結(jié)構(gòu)化、信息工程和面向?qū)ο笕N方法學(xué)下的需求分析技術(shù)都是（ （A）面向問題域 （B）面向解系統(tǒng) （C）面向設(shè)計(jì) （D）面向需求 42、使用面向問題的技術(shù)對(duì)問題世界的建模就被稱為（ （A）前期 （B）中期 （C）后期 （D）全過程 43、使用面向解系統(tǒng)的技術(shù)對(duì)軟件系統(tǒng)解決方案的描述稱為（ （A）前期 （B）中期 （C）后期 （D）全過程 ）的。 ）需求階段的分析。 ）需求階段的分析。 44、需求分析活動(dòng)的一個(gè)重要任務(wù)是進(jìn)行（ ），明確用戶需求的隱含信息，展開為 明確的對(duì)軟件系統(tǒng)的行為期望，即系統(tǒng)需求。 （A）需求整理 （B

14、）需求細(xì)化 （C）需求獲取 （D）需求分析 45、在分層結(jié)構(gòu)中，DFD定義了三個(gè)層次類別的 DFD圖：（ （A）1層圖 （B）底層圖 （C）上下文圖 （D）頂視圖 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í)體是一種抽象概念，

15、不考慮概念背后的物理存在，所以通常不包含與之相 關(guān)聯(lián)的其他（ ）。 （A）模型 （B）特征（即屬性） （C）關(guān)系 （D）處理 49、在 ERD建模中，實(shí)體通常所指的就是（ （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ù)

16、又被稱為（ （A）鍵約束 （B）參與約束（C）自然約束 （D）一般約束 53、在實(shí)體之間建立關(guān)系時(shí)，可能會(huì)產(chǎn)生一些附帶的實(shí)體，被稱為關(guān)聯(lián)實(shí)體，最常見 （B）復(fù)雜度 （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)成

17、分與系統(tǒng)外事物的分界線。用例模型使用 一個(gè)（ ）來表示系統(tǒng)邊界，以顯示系統(tǒng)的上下文環(huán)境。 （A）圓形框 （B）菱形框 （C）虛線框 （D）矩形框 57、UML使用的行為模型有三種，即：（ ）。 （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ī)格說明文

18、檔和人機(jī)交互文檔一起被用于系統(tǒng)開發(fā)的目的，都被認(rèn)為是開發(fā)文檔。 （A）開發(fā)文檔 60、下列（ （B）需求文檔 （C）過程文檔 （D）用戶文檔 ）不是需求規(guī)格說明文檔的讀者？ （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í) 5 有效的功能配置。 4、應(yīng)用型軟件分析階段的主要目的是發(fā)現(xiàn)人們利用軟件的原因（目

19、的），找出需要軟件 解決的問題，理解應(yīng)用環(huán)境中的領(lǐng)域知識(shí)，保證功能的模擬性。 5、需求工程是所有需求處理活動(dòng)的總和，它收集信息、分析問題、整合觀點(diǎn)、記錄需 求并驗(yàn)證其正確性，最終反映軟件被應(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、所有對(duì)軟件系統(tǒng)的開發(fā)和應(yīng)用具有發(fā)言權(quán)和決定權(quán)的人統(tǒng)稱為涉眾。 10、按照媒介載體進(jìn)行分類

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

21、17、實(shí)現(xiàn)是指原型物件完成功能的細(xì)節(jié)技術(shù)和方法。 18、使用演化式原型方法，在開發(fā)時(shí)就需要注意原型的健壯性和代碼的質(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é)同問題都具有突現(xiàn)的情景性。 23、民族志的一個(gè)主要應(yīng)用目的就是研究和解決復(fù)雜的協(xié)同問題。 24、復(fù)雜的工作總會(huì)同時(shí)存在著正常流程和異常流程，異常流

22、程大多是一些特殊情況下 的處理，限定了異常處理的上下文環(huán)境，即異常處理具有局部的情景性。 25、有很多重要工作的進(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í)間間隔來觀察用戶的活動(dòng)情況。 28、文檔審查主要獲取對(duì)象包括相關(guān)產(chǎn)品的需求規(guī)格說明、硬數(shù)據(jù)和客戶的需求文檔。 29、文檔分析通常是數(shù)據(jù)建模方法的一個(gè)基礎(chǔ)部分，它是通過檢查采集的硬數(shù)據(jù)來確定 潛在的需求。 30、如果當(dāng)前存在一

23、份客戶的需求文檔，就可以使用需求剝離技術(shù)，從需求文檔中抽取 單個(gè)的需求并加入到新的需求文檔之中。 31、需求工程師可以使用模型驅(qū)動(dòng)方法來進(jìn)行信息的整理和歸類，其中模型驅(qū)動(dòng)方法所 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)階段的主要任

24、務(wù)是收集與目標(biāo)相關(guān)的需求信息，討論可能的候選解決方案， 確定最終的系統(tǒng)詳細(xì)需求和解決方案。 37、場(chǎng)景具有重點(diǎn)描述真實(shí)世界的特征，它利用情景、行為者之間的交互、事件隨時(shí)間 的演化等方式來敘述性地描述系統(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)出來，人們可能會(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

25、、抽象場(chǎng)景，又稱為類型場(chǎng)景，是以經(jīng)驗(yàn)中的類別和抽象概念來描述事實(shí)。 43、探索性場(chǎng)景可以用來進(jìn)行需求獲取和需求建模與分析。 44、每個(gè)用例是對(duì)相關(guān)場(chǎng)景集合的敘述性的文本描述，這些場(chǎng)景是用戶和系統(tǒng)之間的交 互行為序列，幫助實(shí)現(xiàn)用戶的目的。 45、用例是場(chǎng)景方法中的一種，是靜態(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)生三類重要的

26、文檔：項(xiàng)目前景和范圍文檔、用戶需求文檔以 及需求規(guī)格說明。用例文檔通常被用來代替用戶需求文檔，起到記錄、交流領(lǐng)域信息和用戶 期望的作用。 50、需求獲取得到的信息和需求開發(fā)應(yīng)該建立的軟件系統(tǒng)解決方案之間有著很大的差 距。需求分析就是用來解決這個(gè)差距的需求工程活動(dòng)。 51、需求分析的根本任務(wù)是：建立分析模型并創(chuàng)建解決方案。 52、分解將單個(gè)復(fù)雜和難以理解的問題分解成多個(gè)相對(duì)更容易的子問題，并掌握各子 問題之間的聯(lián)系。 53、基于軟件構(gòu)建單位及其之間的關(guān)系建立的模型，用來說明軟件邏輯上的構(gòu)建方式 和實(shí)現(xiàn)方式，由于它使用的組元及其關(guān)系都是軟件的元素，因此它是來自于軟件的模型，稱

27、為計(jì)算模型。 54、模型語言的三要素：語法、語義、語用。其中語用給出了一個(gè)模型元素描述的更 寬廣的上下文，以及影響該模型元素意義的約束和假定。 55、互相之間建立了語義聯(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è)要素。

28、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ī)格說明被用來描述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è)

29、過程之間的通信 形式。 65、DFD的 0層圖中的每個(gè)過程都可以進(jìn)行分解，被分解的過程稱為父過程，分解后 產(chǎn)生的揭示更多細(xì)節(jié)的DFD圖稱為子圖。 66、DFD的 0層圖通常被用來作為整個(gè)系統(tǒng)的功能概圖。 67、為了保證DFD圖的可理解性，0層圖應(yīng)該被描述的簡(jiǎn)潔、清晰，所以在描述復(fù)雜的 系統(tǒng)時(shí)，0層圖中不應(yīng)出現(xiàn)太過具體的過程和數(shù)據(jù)存儲(chǔ)。 68、DFD中對(duì) 0層圖的過程分解產(chǎn)生的子圖稱為1層圖。 69、數(shù)據(jù)建模建立的模型稱為數(shù)據(jù)模型，是問題域和解系統(tǒng)共享的知識(shí)集合，通常能 夠反映企業(yè)業(yè)務(wù)的核心知識(shí)。 70、數(shù)據(jù)模型的內(nèi)容是問題域和解系統(tǒng)所共享的知識(shí)模型，可以用問題域的語言來解

30、 釋，也可以用解系統(tǒng)的語言來解釋，還可以用介于問題域和解系統(tǒng)之間的中立語言來解釋。 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)出來的功能和達(dá)成的效果，所以稱這類實(shí)體為進(jìn)程實(shí)體。 74、ERD中屬性就是可以對(duì)實(shí)體進(jìn)行描述的特征，一系列屬性的存在集成起來就可以 描述一個(gè)實(shí)體的實(shí)例。 75、ERD中屬性取值的受限制范圍稱為域（Domain）。 76、ERD為實(shí)體指定一個(gè)

31、屬性或多個(gè)屬性的組合，可以用來唯一地確定和標(biāo)識(shí)每個(gè)實(shí) 例，這些屬性或?qū)傩缘慕M合稱為實(shí)體的標(biāo)識(shí)符，又稱為鍵。 77、一個(gè)實(shí)體可能有多個(gè)鍵，這些鍵都被稱為候選鍵。 78、通常人們從多個(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)系

32、。 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í) 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

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

34、97、需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在向前和向后兩個(gè)方向上，描述需 求以及跟蹤需求變化的能力。 98、從需求向后回溯（前向跟蹤的兩種聯(lián)系之一）說明軟件需求來源于哪些涉眾的需 要和目標(biāo)。 99、后向跟蹤是指需求被定義到軟件需求規(guī)格說明文檔之后的演化過程。 100、后向跟蹤包括兩種聯(lián)系：從需求向前跟蹤和回溯到需求的跟蹤。 三、判斷題 1、需求工程包括需求獲取和需求開發(fā)兩個(gè)方面。（×） 2、需求驗(yàn)證是需求工程中最后一個(gè)活動(dòng)。（×） 3、軟件系統(tǒng)能夠與問題域進(jìn)行交互和相互影響的原因在于，軟件系統(tǒng)中的某些部分對(duì)問 題域中的某些部分具有模擬特性。（√） 4、規(guī)格說明是問題域

35、為滿足用戶需求而提供的解決方案，規(guī)定了解系統(tǒng)的行為特征。（×） 5、業(yè)務(wù)需求具有明顯的目的性和較高的抽象性，經(jīng)過明確和細(xì)化的處理，可以直接轉(zhuǎn)化 為系統(tǒng)需求。（×） 6、需求開發(fā)的一些特性決定了需求開發(fā)過程只能是一個(gè)簡(jiǎn)單的線性增量過程。（×） 7、對(duì)于需求不確定性比較小的項(xiàng)目，用戶參與可以取得比較好的效果，但對(duì)于需求不確 定性比較大的項(xiàng)目，用戶參與反而可能帶來阻礙作用。（×） 8、按照構(gòu)建技術(shù)進(jìn)行分類，原型可分為：水平原型和垂直原型。（√） 9、嚴(yán)格意義上的原型主要被用在需求分析階段。（√） 10、要完成相同的功能，構(gòu)建拋棄式原型比構(gòu)建演化式原型所花費(fèi)的代價(jià)要大得多。（×） 1

36、1、水平原型方法僅僅實(shí)現(xiàn)選定功能實(shí)現(xiàn)的所有層次，能夠處理較大范圍的功能。（×） 12、垂直原型方法會(huì)觸及選定功能所有層次中的某些特定層次，處理的功能范圍通常較 小。（×） 13、建立外觀原型時(shí)重在原型的用戶界面和交互方式，原型的功能和技術(shù)實(shí)現(xiàn)細(xì)節(jié)就會(huì) 被簡(jiǎn)化處理。（√） 14、如果選擇的開發(fā)方法是實(shí)驗(yàn)式或者探索式開發(fā)方法，應(yīng)該盡量花費(fèi)最小的代價(jià)，爭(zhēng) 取最快的速度，忽略或簡(jiǎn)化不重要的功能處理。（√） 15、原型修正主要依據(jù)評(píng)估人員的反饋，可以忽略事先的原型調(diào)整計(jì)劃。（×） 9 16、文檔審查是一種傳統(tǒng)的需求獲取方法，是專門針對(duì)文檔進(jìn)行的需求獲取活動(dòng)。（√） 17、

37、由于文檔是來自于當(dāng)前計(jì)算機(jī)或手工系統(tǒng)的產(chǎn)物，因此它是正確的，也正是客戶所 需要的。（×） 18、成功的需求獲取任務(wù)不僅要求成功地執(zhí)行每一次具體的需求獲取行為，還要求成功 地處理多次獲取行為之間的關(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、對(duì)系統(tǒng)的現(xiàn)狀和背景進(jìn)行分析往往能夠發(fā)現(xiàn)重要的目標(biāo)，得到一些明確的問

38、題和缺 陷，它們的反面就是系統(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é)構(gòu)化文本。強(qiáng)限 制文本、表格、圖表、圖像等。（√） 26、在實(shí)踐中，以動(dòng)態(tài)的場(chǎng)景外觀為主。（×） 27、場(chǎng)景內(nèi)包含的知識(shí)只能是關(guān)于未來的。（×） 28、描述性場(chǎng)景的目的是為了記錄已經(jīng)得到的需求，即整理每次需求獲取行為中得到的 信息。（√） 29、UML就是以用例來捕獲系統(tǒng)所有的系統(tǒng)需求的。（×） 30、用例的內(nèi)容只能包含有正常流程，而不能包含有異常流程。（×）

39、 31、用例可以用于各種目的的應(yīng)用，包括描述、探索和解釋。（√） 32、用例是在對(duì)現(xiàn)實(shí)世界的探索中或者是在對(duì)需求規(guī)格說明的解釋中產(chǎn)生的，是通過功 能分解的方式創(chuàng)建的。（×） 33、抽象用例是不能被實(shí)例化的，它必須被包含在其他用例中才能得以執(zhí)行。（√） 34、用例間的泛化關(guān)系是指子用例繼承了父用例的特征。（×）并增加了新的特征 35、抽象一方面要求人們關(guān)注重要的信息，同時(shí)又不能忽略次要的內(nèi)容。另一方面也要 求人們將認(rèn)知保留在適當(dāng)?shù)膶哟?，屏蔽更深層次的?xì)節(jié)。（×） 36、由于計(jì)算模型的形式化特征不適合于需求工程階段，因此計(jì)算模型不適合用于需求 分析中的建模。（√） 37、具有形式

40、化特征的計(jì)算模型是用戶和開發(fā)者共同理解的模型。（×） 38、由于模型需要描述的內(nèi)容太過復(fù)雜的，因此分析模型對(duì)模型語言語用的要求不可能 太高。（×） 39、軟件需求分析的關(guān)鍵是為真實(shí)世界的問題建立模型，即問題域建模。（√） 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í)體是指

41、處于待構(gòu)建系統(tǒng)之外的人、組織、設(shè)備或者其他軟件系統(tǒng)，但它們要 受系統(tǒng)的控制，開發(fā)者可以以任何方式操縱它們。（×） 44、上下文圖以黑盒看待和描述系統(tǒng)的方式使它非常適合描述系統(tǒng)的應(yīng)用環(huán)境、定義系 10 統(tǒng)的邊界，這正是 DFD在層次結(jié)構(gòu)中將其置于最高層的原因。（√） 45、數(shù)據(jù)模型說明了問題域和解系統(tǒng)共享的事物、對(duì)共享事物的描述和共享事物之間 的關(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è)

42、務(wù)聯(lián)系，而不是人為施加的結(jié)構(gòu)關(guān)系，是一 種特殊的實(shí)體間關(guān)系。（×） 49、建立功能／實(shí)體矩陣的過程可以幫助驗(yàn)證過程模型和數(shù)據(jù)模塊的正確性，發(fā)現(xiàn)其中 的錯(cuò)誤、遺漏、冗余和不一致。（√） 50、發(fā)起或觸發(fā)用例的外部用戶以及其他軟件系統(tǒng)等角色被稱為參與者。（√） 51、交互圖是對(duì)單個(gè)用例的典型場(chǎng)景的實(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ī)格說明

43、文檔是對(duì)部分系統(tǒng)功能分配給軟件部分的詳細(xì)描述。（×） 56、硬件需求規(guī)格說明文檔是對(duì)整個(gè)系統(tǒng)功能當(dāng)中分配給硬件部分的詳細(xì)描述。（√） 57、人機(jī)交互文檔是對(duì)整個(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ī)格說明文檔之前的演化過程。（×）定義 四、名詞解釋題 1、需求工程：需求工程是軟件工程的一個(gè)分支，它關(guān)注于軟件系統(tǒng)所應(yīng)予實(shí)現(xiàn)的現(xiàn)實(shí) 世界目標(biāo)、軟件系統(tǒng)的功能和軟件系統(tǒng)應(yīng)當(dāng)遵守的約束，同時(shí)它也關(guān)注以

44、上因素和準(zhǔn)確的軟 件行為規(guī)格說明之間的聯(lián)系，關(guān)注以上因素與其隨時(shí)間或跨產(chǎn)品族而演化之后的相關(guān)因素之 間的聯(lián)系。 2、需求：IEEE對(duì)需求的定義為： ①用戶為了解決問題或達(dá)到某些目標(biāo)所需要的條件或能力。 ②系統(tǒng)或系統(tǒng)部件為了滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔所規(guī)定的要求而需要具備 的條件或能力。 ③對(duì)①或②中的一個(gè)條件或一種能力的一種文檔化表述。 3、需求分析：需求分析是利用建模與分析技術(shù)對(duì)獲取筆錄的內(nèi)容進(jìn)行明確、整理、匯 總，建立一個(gè)綜合考慮問題域特性和需求的系統(tǒng)模型，然后根據(jù)系統(tǒng)模型將用戶需求轉(zhuǎn)化為 系統(tǒng)需求的需求工程活動(dòng)。 4、前景（Vision）：前景描述了產(chǎn)品的作

45、用以及最終的功能，它將所有涉眾都統(tǒng)一到一 個(gè)方向上。 5、范圍（scope）：范圍指出當(dāng)前項(xiàng)目是要解決產(chǎn)品長(zhǎng)遠(yuǎn)規(guī)劃中的哪一部分，范圍聲明 它為項(xiàng)目劃定了需求的界線。 11 6、用戶參與（User Involvement）：是以用戶為中心的設(shè)計(jì)方法的核心思想，它要求開 發(fā)者建立和用戶的直接聯(lián)系，盡早地關(guān)注于用戶和用戶的任務(wù)執(zhí)行過程，通過及時(shí)獲得用戶 的反饋來調(diào)整軟件設(shè)計(jì)，以完成高質(zhì)量的設(shè)計(jì)。另一方面，用戶參與就是反對(duì)通過和市場(chǎng)人 員、管理者等中間媒介來了解用戶，因?yàn)檫@些間接的聯(lián)系會(huì)減少或歪曲用戶的信息。 7、硬數(shù)據(jù)：表格和文檔資料是用戶對(duì)實(shí)際業(yè)務(wù)進(jìn)行加工和抽象之后

46、的結(jié)果，是一種精 化過的知識(shí)。這些文檔資料被稱為硬數(shù)據(jù)。硬數(shù)據(jù)分為定量硬數(shù)據(jù)和定性硬數(shù)據(jù)兩種類型。 8、結(jié)構(gòu)化面談：結(jié)構(gòu)化面談指在面談的過程中，會(huì)見者會(huì)完全按照事先的問題和結(jié)構(gòu) 來控制面談。結(jié)構(gòu)化面談通常被用來獲取一些比較確定或者選擇空間比較有限的信息，一些 統(tǒng)計(jì)性傾向信息的獲取也可以使用結(jié)構(gòu)化面談。 9、半結(jié)構(gòu)化面談：半結(jié)構(gòu)化面談指在面談的過程中，事先需要根據(jù)面談內(nèi)容準(zhǔn)備面談 的問題和面談結(jié)構(gòu)。但在面談過程中，會(huì)見者可以根據(jù)實(shí)際情況采取一些靈活的策略。半結(jié) 構(gòu)化面談是在需求獲取中應(yīng)用最多的一種面談?lì)愋?，能夠處理大部分的需求獲取任務(wù)。 10、非結(jié)構(gòu)化面談：在非結(jié)構(gòu)化面談的過程中

47、，沒有事先預(yù)定的議程安排。在比較極 端的情況下，會(huì)見者甚至?xí)跊]有太多事前準(zhǔn)備的情況下就直接到訪被會(huì)見者的工作地，就 某個(gè)主題開展會(huì)談。 11、頭腦風(fēng)暴（Brainstorming）：是一種特殊的群體面談方式，它的目的不是發(fā)現(xiàn)需求， 而是“發(fā)明”需求，或者說是發(fā)現(xiàn)“潛在”需求。它鼓勵(lì)參與者在無約束的環(huán)境下進(jìn)行某些 問題的自由思考和自由討論，以產(chǎn)生新的想法。它是需求獲取中用于“發(fā)明”需求的方法， 但它會(huì)增加需求的數(shù)量。 12、原型：原型是一個(gè)系統(tǒng)，它內(nèi)化了（Capture）一個(gè)更遲系統(tǒng)（Later System）的本 質(zhì)特征。原型系統(tǒng)通常被構(gòu)造為不完整的系統(tǒng)，以在將來進(jìn)行改進(jìn)、補(bǔ)

48、充或者替代?！? 13、嚴(yán)格意義上的原型：嚴(yán)格意義上的原型主要被用在需求分析階段，是開發(fā)者在建 立系統(tǒng)信息模型的同時(shí)建立的原型，通常被用來闡明用戶界面或者系統(tǒng)功能的某些特定方 面，幫助人們及時(shí)地澄清問題。 14、場(chǎng)景：場(chǎng)景是對(duì)系統(tǒng)和環(huán)境行為的局部描述，或者說場(chǎng)景是對(duì)行為或者事件序列 的描述，序列中的行為和事件是系統(tǒng)需要完成的一個(gè)任務(wù)的特殊示例。 （也可以說，場(chǎng)景是用戶為了達(dá)到某個(gè)目標(biāo)而和軟件系統(tǒng)發(fā)生的行為交互序列，是開 發(fā)者描述軟件功能和需求的一種重要形式。） 15、情境性：情景性是指某些事件只有和它們發(fā)生時(shí)的具體環(huán)境聯(lián)系起來，才能得到 理解，它也是用戶無法完成主動(dòng)信息告知的主

49、要原因。 16、民族志：民族志是由人類學(xué)家最早提出來的，用來理解原始社會(huì)（Primitive Societies） 的社會(huì)機(jī)制。它要求人類學(xué)家花費(fèi)長(zhǎng)期的時(shí)間（通常是數(shù)年）在被研究的社會(huì)中生活并且仔 細(xì)觀察該社會(huì)中的實(shí)際活動(dòng)，得到第一手的觀察數(shù)據(jù)。對(duì)這些觀察數(shù)據(jù)的分析可以揭示被研 究社會(huì)的社會(huì)結(jié)構(gòu)、組織方法和具體活動(dòng)。 12 17、模型驅(qū)動(dòng)法：模型驅(qū)動(dòng)法是一類以定義明確的模型為理論基礎(chǔ)，依據(jù)模型指導(dǎo)和 組織活動(dòng)開展的需求工程方法。 18、用例驅(qū)動(dòng)法：用例是一種場(chǎng)景的文本化表現(xiàn)方式，使用敘述性的文本來描述場(chǎng)景。 以用例為核心，圍繞用例開展活動(dòng)的軟件開發(fā)方法被稱為用例驅(qū)

50、動(dòng)的軟件開發(fā)方法。 19、企業(yè)建模：企業(yè)建模是以使用產(chǎn)品的組織團(tuán)體為系統(tǒng)的環(huán)境，進(jìn)行分析。它主要 用來理解組織的結(jié)構(gòu)、行為規(guī)則、目標(biāo)、重要成員的任務(wù)與職責(zé)、操縱的數(shù)據(jù)等。企業(yè)建模 利用企業(yè)的目標(biāo)、任務(wù)、策略、資源等來刻畫組織的行為，并依此來發(fā)現(xiàn)組織開發(fā)系統(tǒng)的目 的，建立系統(tǒng)的業(yè)務(wù)需求。 20、過程建模：過程建模是結(jié)構(gòu)化分析方法的典型技術(shù)。過程建模將系統(tǒng)看做是過程 的集合，其中一些由人來執(zhí)行，另一些由軟件系統(tǒng)來執(zhí)行。過程建模使用的主要技術(shù)有上下 文圖、數(shù)據(jù)流圖、微規(guī)格說明和數(shù)據(jù)字典等。 21、上下文圖：上下文圖是 DFD最高層次的圖，是系統(tǒng)功能的最高抽象，它將整個(gè)系 統(tǒng)看做是一

51、個(gè)過程，這個(gè)過程實(shí)現(xiàn)系統(tǒng)的所有功能。上下文圖中存在且僅存在一個(gè)過程，表 示整個(gè)系統(tǒng)。這個(gè)單一的過程通常編號(hào)為 0。 22、概念數(shù)據(jù)模型：概念數(shù)據(jù)模型是以問題域的語言解釋數(shù)據(jù)模型，反映了用戶對(duì)共 享事物的描述和看法，由一系列應(yīng)用領(lǐng)域的概念組成。 23、物理數(shù)據(jù)模型：物理數(shù)據(jù)模型是對(duì)數(shù)據(jù)模型的解系統(tǒng)語言的解釋，它描述的是共 享事物在解系統(tǒng)中的實(shí)現(xiàn)形式，是形式化的定義。 24、邏輯數(shù)據(jù)模型：邏輯數(shù)據(jù)模型是為了緩解開發(fā)人員將概念數(shù)據(jù)模型轉(zhuǎn)換成物理數(shù) 據(jù)模型的困難，而使用一種介于問題域和解系統(tǒng)之間的中立語言來進(jìn)行的數(shù)據(jù)模型的描述。 這種中立的語言使用更加傾向于用戶的概念和詞匯，同時(shí)使用更

52、加傾向于解系統(tǒng)語言的表達(dá) 方式。 25、關(guān)系的基數(shù)：關(guān)系的基數(shù)是衡量關(guān)系復(fù)雜性的指標(biāo)之一，又被稱為關(guān)系的約束。 一個(gè)實(shí)體在關(guān)系中的基數(shù)定義了在關(guān)系中其他實(shí)體實(shí)例確定的情況下，該實(shí)體實(shí)例可能參與 關(guān)系的數(shù)量。 26、交互圖（UML行為模型）：交互圖用于描述在特定上下文環(huán)境中一組對(duì)象的交互行 為，該上下文環(huán)境就是被實(shí)現(xiàn)用例的某個(gè)場(chǎng)景。所以，交互圖通常描述的是單個(gè)用例的典型 場(chǎng)景。交互圖中的每一個(gè)交互都描述了環(huán)境中的對(duì)象為了實(shí)現(xiàn)某個(gè)目標(biāo)而執(zhí)行的一系列消息 交換。 27、OCL（語言）：OCL（Object Constraint Language）稱為對(duì)象約束語言。OCL不是編 程

53、語言而是一種建模語言，它在保證一定表達(dá)能力的前提下，注重于語言的簡(jiǎn)潔性和抽象性。 但它無法被用來描述程序的控制邏輯和工作流程，而且它的表達(dá)式定義也無法在程序中得到 直接的執(zhí)行。 13 28、基線：基線是已經(jīng)通過正式評(píng)審和批準(zhǔn)的規(guī)格說明或產(chǎn)品，可以作為進(jìn)一步開發(fā)的 基礎(chǔ)，并且只有通過正式的變更控制過程才能修改它。 29、需求基線：需求基線（Requirements Baseline）就是被明確和固定的需求集合，是 項(xiàng)目團(tuán)隊(duì)需要在某一特定產(chǎn)品版本中實(shí)現(xiàn)的特征和需求集合。 30、需求跟蹤：需求跟蹤是一種有效的控制手段，能夠在涉眾的需求變化中協(xié)調(diào)系統(tǒng)的 演化，保持各項(xiàng)開

54、發(fā)工作對(duì)需求的一致性。需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在 向前和向后兩個(gè)方向上，描述需求以及跟蹤需求變化的能力，分為前向跟蹤（ Pre— Traceabmty）和后向跟蹤（Post—Traceability）兩種。 五、問答題 1、簡(jiǎn)述需求工程的主要任務(wù)。 答： 需求工程有以下三個(gè)主要任務(wù)： ①需求工程必須說明軟件系統(tǒng)將被應(yīng)用的環(huán)境及其目標(biāo)，說明用來達(dá)成這些目標(biāo)的軟 件功能，還要說明在設(shè)計(jì)和實(shí)現(xiàn)這些功能時(shí)上下文環(huán)境對(duì)軟件完成任務(wù)所用方式、方法所施 加的限制和約束，也即要同時(shí)說明軟件需要“做什么”和“為什么”需要做。 ②需求工程必須將目標(biāo)、功能和

55、約束反映到軟件系統(tǒng)中，映射為可行的軟件行為，并 對(duì)軟件行為進(jìn)行準(zhǔn)確的規(guī)格說明。需求規(guī)格說明是需求工程最為重要的成果，是項(xiàng)目規(guī)劃、 設(shè)計(jì)、測(cè)試、用戶手冊(cè)編寫等很多后繼軟件開發(fā)階段的工作基礎(chǔ)。 ③現(xiàn)實(shí)世界是不斷變化的世界，因此需求工程還需要妥善處理目標(biāo)、功能和約束隨著 時(shí)間的演化情況。同時(shí)，為了節(jié)省開支和進(jìn)行需求規(guī)格說明的重用，需求工程還需要對(duì)目標(biāo)、 功能和約束在軟件產(chǎn)品族中的演化和分布情況進(jìn)行綜合考慮與處理。 2、簡(jiǎn)述常見的需求定義錯(cuò)誤。 答：（劃線部分為必答要點(diǎn)） 在實(shí)踐和研究過程中，人們發(fā)現(xiàn)關(guān)于需求定義的具體的錯(cuò)誤主要有以下幾種： ①需求并沒有反映用戶的真實(shí)需要。 實(shí)踐表

56、明，獲取用戶的真實(shí)需求是非常困難的。 原因之一是用戶在表達(dá)自己的需要時(shí)，可能會(huì)在潛意識(shí)下進(jìn)行一定的加工。為了發(fā)現(xiàn) 用戶的真實(shí)需求，需求工程師一定要進(jìn)行問題分析，盡力發(fā)現(xiàn)問題背后的問題。 原因之二是在人際交流中，信息會(huì)發(fā)生自然的衰減，甚至扭曲，導(dǎo)致需求丁程師理解 的并非是用戶所表達(dá)的。解決方法是在需求傳遞給開發(fā)人員之前，請(qǐng)?zhí)岢鲂枨蟮挠脩暨M(jìn)行仔 細(xì)地檢查和確認(rèn)。 ②模糊和歧義的需求。 在實(shí)踐中，人們總是會(huì)有意和無意地寫出模糊和歧義的需求定義。 無意中寫出模糊和歧義的需求定義往往是因?yàn)檫x詞造句不當(dāng)，導(dǎo)致不同的人對(duì)同一項(xiàng) 需求產(chǎn)生了不同的理解。解決方法是為項(xiàng)目中重要的詞匯建立一個(gè)公共

57、的可共同理解的詞匯 表，然后在詞匯表的基礎(chǔ)之上進(jìn)行需求的定義。 有意產(chǎn)生的模糊和歧義的需求定義往往是為了應(yīng)付對(duì)需求持有不同立場(chǎng)的用戶，這些 用戶關(guān)于需求的目標(biāo)互相沖突，需求工程師于是采用了模糊化的處理方法。正確解決方法是 在項(xiàng)目前景的指導(dǎo)下，促進(jìn)用戶之間的協(xié)商解決。 ③信息遺漏。 14 信息遺漏也是一類常見的問題，包括明顯的信息遺漏和不明顯的信息遺漏。 明顯的信息遺漏，其主要原因在于項(xiàng)目的范圍定義不當(dāng)，可以通過加強(qiáng)對(duì)業(yè)務(wù)需求的 處理得以解決。 不明顯的信息遺漏，是因?yàn)橄嚓P(guān)信息難以發(fā)現(xiàn)，只能靠需求工程師的經(jīng)驗(yàn)來加以避免。 ④不必要的需求。 產(chǎn)生不必要需求的原因

58、主要是： 其一是用戶將一些不必要的需求作為和開發(fā)人員談判的籌碼，然后通過自己對(duì)不必要 需求的要求而在和開發(fā)人員的談判當(dāng)中取得真正想要的利益，例如金錢。對(duì)此問題，唯一需 要的就是開發(fā)人員代表的談判技巧。 其二是用戶在交流中，總是害怕信息有所遺漏，并因此產(chǎn)生不利后果，因此用戶總是傾 向于表達(dá)各種各樣的需要。要解決這個(gè)問題，就需要開發(fā)人員在進(jìn)行用戶需求的獲取之前， 先定義明確的業(yè)務(wù)需求，然后根據(jù)業(yè)務(wù)需求進(jìn)行用戶需求的過濾和選擇。 其三是需求開發(fā)人員“畫蛇添足”，添加“用戶肯定會(huì)喜歡”的功能，該類功能既會(huì)造 成項(xiàng)目額外的耗費(fèi)，又不會(huì)給用戶帶來更多的幫助。這就要求需求開發(fā)人員要保持以用戶

59、為 中心。 ⑤不切實(shí)際的期望。 不切實(shí)際的期望也是實(shí)踐中常見的需求定義問題，而且它在很大程度上影響著項(xiàng)目的 成敗。 面對(duì)不切實(shí)際的期望，要求軟件開發(fā)者提供可行性、成本等足夠的技術(shù)參考信息，幫 助用戶對(duì)其進(jìn)行取舍和調(diào)整。 3、簡(jiǎn)要說明需求獲取活動(dòng)的過程。 答： （1）收集和應(yīng)用背景資料，建立初始的知識(shí)框架。分析涉眾的高層次問題，總結(jié)出系 統(tǒng)的業(yè)務(wù)需求。 （2）設(shè)計(jì)一個(gè)高層次的解決方案，并確定解決方案需要具備的系統(tǒng)特性。高層次的解 決方案和系統(tǒng)特性定義了項(xiàng)目的前景和范圍。 （3）在項(xiàng)目的業(yè)務(wù)范圍內(nèi)，需求工程要尋找相關(guān)的涉眾，并分析和涉眾選擇。 （4）對(duì)組織里存在大量的表

60、格、單據(jù)等與業(yè)務(wù)相關(guān)的硬數(shù)據(jù)進(jìn)行采樣，它們是需求獲 取活動(dòng)中一個(gè)重要的信息來源。 （5）針對(duì)某一次具體的需求獲取活動(dòng)，要依據(jù)項(xiàng)目范圍確定主題和內(nèi)容，涉眾特征和 硬數(shù)據(jù)，從而確定信息來源。獲取方法通常只有綜合內(nèi)容、來源和系統(tǒng)環(huán)境三者才能做出正 確的決定。 在內(nèi)容、來源和方法都確定之后，需求工程師就可以開展具體的獲取活動(dòng)，獲取用戶 需求和問題域特性。 獲取得到的具體信息要記錄下來，以獲取筆錄的形式進(jìn)行保存。 4、簡(jiǎn)述涉眾識(shí)別的基本過程。 答： 涉眾識(shí)別的基本過程如下： ①將初始涉眾集中起來，進(jìn)行一次頭腦風(fēng)暴，盡可能地列出一個(gè)涉眾類別列表。 ②對(duì)上一步產(chǎn)生的涉眾類別列表進(jìn)行分

61、析，判斷它們和軟件系統(tǒng)的相關(guān)性，找出其中的 鍵涉眾類別。 ③為上一步的各個(gè)關(guān)鍵涉眾類別選擇代表，集中起來進(jìn)行進(jìn)一步的頭腦風(fēng)暴，列出新的 15 涉眾類別列表。如果新列出的涉眾類別列表趨于穩(wěn)定，就可以結(jié)束涉眾識(shí)別過程。如果新列 出的涉眾類別列表有了新的發(fā)現(xiàn)，就提交新的涉眾類別列表，轉(zhuǎn)向第②步。 5、試比較面談問題組織的三種結(jié)構(gòu)。 答： （1）金字塔結(jié)構(gòu) 面談問題的歸納式組織被看做是金字塔形狀。使用這種形式時(shí)，會(huì)見者以很具體的問題 （通常是封閉式的問題）開始，然后逐漸提高問題的開放度，同時(shí)允許被會(huì)見者用越來越籠 統(tǒng)的答案來回答問題。 在主動(dòng)的情況下，如果會(huì)見者認(rèn)為

62、被會(huì)見者需要對(duì)話題進(jìn)行預(yù)熱，可以采用金字塔結(jié)構(gòu)， 通過逐步的引導(dǎo)使被會(huì)見者進(jìn)入討論。 在被動(dòng)的情況下，如果會(huì)見者發(fā)現(xiàn)自己事先對(duì)事實(shí)的確認(rèn)存在較大偏差或者被會(huì)見者看 上去不情愿討論某個(gè)話題，也可以采用金字塔結(jié)構(gòu)。 在某個(gè)話題討論結(jié)束的時(shí)候，使用金字塔結(jié)構(gòu)的提問順序也是有用的。 （2）漏斗結(jié)構(gòu) 在這種結(jié)構(gòu)中，會(huì)見者使用演繹的方法，以一般的、開放式的問題開始，然后用封閉式 的問題縮小可能的答復(fù)。這種面談結(jié)構(gòu)可看做是漏斗型。 在主動(dòng)的情況下，漏斗結(jié)構(gòu)為開始一場(chǎng)面談提供了一種容易而輕松的途徑。答復(fù)者即使 答錯(cuò)了開放式問題，也不會(huì)感到壓力。 在被動(dòng)的情況下，當(dāng)被會(huì)見者對(duì)話題有情緒，并且

63、需要自由表達(dá)這些情緒的時(shí)候，需要 采用漏斗型提問順序?；蛘咴跁?huì)見者事先對(duì)事實(shí)了解不多時(shí)，也應(yīng)該采用漏斗結(jié)構(gòu)的問題組 織方式。 使用漏斗結(jié)構(gòu)的一個(gè)好處是：用這種方式組織面談能得出很多的詳細(xì)信息，以至于沒有 必要使用長(zhǎng)序列的封閉式問題。 （3）菱形結(jié)構(gòu) 人們?cè)诿嬲勚谐３?huì)將上述兩種結(jié)構(gòu)結(jié)合起來使用，其中菱形結(jié)構(gòu)就是一種最好的結(jié)合 結(jié)果。這種結(jié)構(gòu)以一種非常明確的方式開始，然后考察一般問題，最后得出一個(gè)非常明確的 結(jié)論。 會(huì)見者首先提出一些簡(jiǎn)單的、封閉式的問題，為面談過程做好鋪墊。在面談的中間階段， 向被會(huì)見者提出明顯沒有“正確答案”的一般話題的看法。然后，會(huì)見者再次限制問題以獲

64、 得明確的答復(fù)，這樣就為會(huì)見者和被會(huì)見者提供了面談的結(jié)束時(shí)機(jī)。 菱形結(jié)構(gòu)結(jié)合了其他兩種結(jié)構(gòu)的長(zhǎng)處，但是也有缺點(diǎn)，即所花的時(shí)間比其他任何一個(gè)都 長(zhǎng)。 6、簡(jiǎn)述軟件開發(fā)中為何使用原型工具以及使用的好處。 答： 因?yàn)樵褪窃谧罱K系統(tǒng)產(chǎn)生之前的一個(gè)局部真實(shí)表現(xiàn)，所以原型方法可以讓人們?cè)谙到y(tǒng) 的開發(fā)過程中，就能夠?qū)σ恍┚唧w問題進(jìn)行基于實(shí)物的有效溝通，從而幫助人們盡早解決軟 件開發(fā)過程中存在的各種不確定性。不確定性是指人們已經(jīng)擁有的知識(shí)是不充分的，不足以 預(yù)測(cè)將來的事件發(fā)展，或者不足以清晰、準(zhǔn)確地描述某個(gè)事物。 實(shí)踐證明，利用原型有如下好處： ①及時(shí)、有力地響應(yīng)用戶需求的變化。 ②減

65、少返工。 ③幫助控制不完整需求所帶來的風(fēng)險(xiǎn)。 16 ④可以將一個(gè)大的難以處理的開發(fā)過程細(xì)分成一些更小更容易處理的步驟。 ⑤減少開發(fā)成本，提高經(jīng)濟(jì)效益。 ⑥增加開發(fā)者之間的交流，幫助確定技術(shù)解決方案的可行性。 ⑦有效地識(shí)別風(fēng)險(xiǎn)和解決風(fēng)險(xiǎn)，幫助進(jìn)行風(fēng)險(xiǎn)管理。 ⑧提高用戶在軟件開發(fā)中的參與程度。 7、試說明在哪些情景下原型法可以幫助需求工程師及早解決需求的不確定性。 答： ①產(chǎn)品以前從未存在過，而且難以可視化。這些產(chǎn)品屬于創(chuàng)新性產(chǎn)品，它們的基本需求 是潛在的，有著很大的不確定性。 ②產(chǎn)品的用戶對(duì)相關(guān)類別的產(chǎn)品沒有經(jīng)驗(yàn)，而且對(duì)將要采用的技術(shù)也沒有經(jīng)驗(yàn)。此時(shí)用 戶無

66、法明確工作的具體細(xì)節(jié)，產(chǎn)品的細(xì)節(jié)需求存在著不確定性。 ③用戶進(jìn)行自己的工作已經(jīng)有一段時(shí)間了，但在完成工作的方式上仍然存在障礙。此時(shí) 用戶無法判斷問題的解決方案是否現(xiàn)實(shí)可行，所以產(chǎn)品在整體方案的可行性上存在著不確定 性。 ④用戶在清晰說明他們的需求方面存在困難，例如默認(rèn)需求或者潛在需求。這些相關(guān)的 需求是有著不確定性的需求。 ⑤需求工程師在理解用戶的需求上存在困難。在澄清和理解之前，這些需求存在著不確 定性。 ⑥需求的可行性值得懷疑，即具體需求的可滿足性存在著不確定性。 8、試比較原型開發(fā)方法的三種類型。 答：（劃線部分為必答要點(diǎn)） （1）探索式 探索式原型法是以缺陷需求開始繼而不斷調(diào)整和修正需求的原型開發(fā)方式。探索式的 原型方法通常要盡可能地調(diào)整各種設(shè)計(jì)選項(xiàng)（例如需求內(nèi)容、軟件化內(nèi)容以及軟件支持方式 等），并比較多種設(shè)計(jì)方案下的用戶反饋以得到理想的用戶需求。探索式的原型方法能夠幫 助開發(fā)者更深入地了解用戶的業(yè)務(wù)、問題和期望。 （2）實(shí)驗(yàn)式 實(shí)驗(yàn)式的原型方法初始時(shí)擁有清晰的用戶需求，但是開發(fā)者對(duì)這些需求的實(shí)現(xiàn)方法、 實(shí)現(xiàn)效果和可行性沒有太大的把握。實(shí)驗(yàn)