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

《《軟件需求分析》習(xí)題集(總38頁)》由會員分享，可在線閱讀，更多相關(guān)《《軟件需求分析》習(xí)題集(總38頁)（38頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 《軟件需求分析》習(xí)題集 《軟件需求分析》課程組編 2012年 4月 目 錄 一、單項(xiàng)選擇題………………………………………………2 二、填空題……………………………………………………5 三、判斷題……………………………………………………9 四、名詞解釋題………………………………………………11 五、問答題……………………………………………………14 六、案例分析題………………………………………………28 1 《軟件需求分析》習(xí)題集 一、單項(xiàng)選擇題 1、軟件生產(chǎn)中產(chǎn)生需求問題的最大原因在于對應(yīng)用軟件的（ ）理解不透徹或應(yīng)用不 堅

2、決。 （A）復(fù)雜性（B）目的性 （C）模擬性（D）正確性 2、需求分析的目的是保證需求的（ ）。 （A）目的性和一致性 （B）完整性和一致性 （C）正確性和目的性 （D）完整性和目的性 3、系統(tǒng)需求開發(fā)的結(jié)果最終會寫入（ ）。 （A）可行性研究報告 （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、功能需求通常分為三個層次，即業(yè)務(wù)需求、用戶需求和（ ）。 （A）硬件需求（B）軟件需求 （C）質(zhì)量屬性

3、（D）系統(tǒng)需求 6、比較容易發(fā)現(xiàn)的涉眾稱為初始涉眾，又稱為（ ），通常包括客戶、管理者和相關(guān) 的投資者。 （A）關(guān)鍵涉眾（B）涉眾基線 （C）普通涉眾 （D）一般涉眾 7、如果在最終的物件（Final Artifact）產(chǎn)生之前，一個中間物件（Mediate Artifact）被 用來在一定廣度和深度范圍內(nèi)表現(xiàn)這個最終物件，那么這個中間物件就被認(rèn)為是最終物件在 該廣度和深度上的（ ）。 （A）模擬 （B）構(gòu)造 （C）原型 （D）模型 8、按照使用方式進(jìn)行分類，原型可分為：演示原型、（ ）、試驗(yàn)原型和引示系統(tǒng)原 型。 （A）非操作原型（B）系列首發(fā)原型（C）選

4、定特征原型（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)容可以從三個緯度上分析：即（ ）。 （A）外觀、角色和實(shí)現(xiàn) （C）成本、技術(shù)和實(shí)現(xiàn) （B）開發(fā)、實(shí)現(xiàn)和作用 （D）需求、作用和角色 1

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

6、 17、下列（ （B）規(guī)章手冊 （C）統(tǒng)計報表 （D）備忘錄 ）屬于定性硬數(shù)據(jù)？ （A）數(shù)據(jù)收集表 （B）月報表 （C）年報表 （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ì)化時使用的 AND Contribution鏈接和 OR Contribution鏈 接，Contribution的作用是（ （A）積極的 （B）消極的 20、AND鏈接將一個父目標(biāo)連接到一系列細(xì)化的子目標(biāo)，意思是如果能夠滿足所有細(xì) ）。 （C

7、）積極的或消極的 （D）不能確定 化的子目標(biāo)，那么將（ ）父目標(biāo)。 （A）無法確定 （B）阻礙 （C）不能滿足 （D）足以滿足 21、OR鏈接是將一個父目標(biāo)連接到一系列細(xì)化的子目標(biāo)，意思是如果能夠滿足所有細(xì) 化子目標(biāo)中的（ ），那么將足以滿足父目標(biāo)。 （A）每一個（B）任何一個 （C）特定的（D）某一個 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)問題和缺陷

8、24、場景的分類框架將場景方法從場景的（ ）4個方面進(jìn)行了分類和描述。 （A）形式、目的、內(nèi)容和生命周期 （C）描述、目的、內(nèi)容和形式 （B）外觀、目的、內(nèi)容和生命周期 （D）描述、外觀、目的和內(nèi)容 25、場景的形式是指場景的表達(dá)模式，從形式上分為兩個方面：（ ） （A）內(nèi)容和目的（B）內(nèi)容和生命周期（C）描述和外觀（D）描述和目的 26、描述場景所使用的表示法要符合正規(guī)性要求，一般可使用非形式化語言、半形式 化語言和形式化語言。在實(shí)踐中，（ ）是主要的描述方式。 （B）非形式化的自然語言 （D）非形式化的設(shè)計語言 （A）形式化的程序語言 （C）形式化的圖形工具

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

10、性 （B）降低模型的復(fù)雜性 3 （C）提高預(yù)見性 31、下列（ （D）降低編程量 ）不是場景方法在需求工程中的應(yīng)用。 （A）幫助進(jìn)行詳細(xì)的需求分析 （B）編寫系統(tǒng)需求規(guī)格說明 （C）結(jié)合面向目標(biāo)的方法，指導(dǎo)需求獲取活動的開展 （D）組織需求獲取得到的信息 32、下列（ ）是組織場景時可用的場景關(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）動態(tài)非結(jié)構(gòu)化文本 （D）動態(tài)結(jié)構(gòu)化文本 ）三種。 34、

11、用例之間的關(guān)系主要有（ （A）包含、擴(kuò)展和簡化 （C）包含、多態(tài)和繼承 （B）合取、析取和擴(kuò)展 （D）包含、擴(kuò)展和泛化 35、分析的活動主要包括識別、定義和結(jié)構(gòu)化，它的目的是獲取某個可以轉(zhuǎn)換為知識的 事物的信息，這種分析活動被稱為（ （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、需

12、求分析僅僅需要描述解決方案，不需要探索實(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)的輸入、處理、存儲和輸出，以 及它們?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)化、信息工程和面向

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

14、，DFD定義了三個層次類別的 DFD圖：（ （A）1層圖 （B）底層圖 （C）上下文圖 （D）頂視圖 46、因?yàn)閿?shù)據(jù)存儲是系統(tǒng)內(nèi)部的功能實(shí)現(xiàn)，所以在將系統(tǒng)視為黑盒的情況下，上下文 ）、0層圖和 N層圖。 圖中不會出現(xiàn)（ ）。 4 （A）實(shí)體 （B）數(shù)據(jù)存儲實(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)的其他（

15、）。 （A）模型 （B）特征（即屬性） （C）關(guān)系 （D）處理 49、在 ERD建模中，實(shí)體通常所指的就是（ （A）邏輯實(shí)體 （B）概念實(shí)體 （C）物理實(shí)體 50、ERD中屬性是實(shí)體的特征，不是數(shù)據(jù)。屬性會以一定的形式存在，這種存在才是 ）。 （D）進(jìn)程實(shí)體 數(shù)據(jù)，被稱為屬性的（ ）。 （A）域 （B）實(shí)例 （C）說明 （D）值 51、ERD中關(guān)系的度數(shù)（Degree）是指參與關(guān)系的實(shí)體數(shù)量，是度量關(guān)系（ ）的 一個指標(biāo)。 （A）模型 52、ERD中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最大基數(shù)又被稱為（ （A）鍵約束 （B）參與約束（C）自然約束 （D）一

16、般約束 53、在實(shí)體之間建立關(guān)系時，可能會產(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)邊界是指一個系統(tǒng)所包含的系統(tǒng)成分與系統(tǒng)外事物的分界線。用例模型使用 一個（ ）來表示系統(tǒng)邊界

17、，以顯示系統(tǒng)的上下文環(huán)境。 （A）圓形框 （B）菱形框 （C）虛線框 （D）矩形框 57、UML使用的行為模型有三種，即：（ ）。 （A）交互圖、狀態(tài)圖和順序圖 （C）交互圖、狀態(tài)圖和活動圖 （B）順序圖、通信圖和時間圖 （D）交互概述圖、通信圖和時間圖 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ā)文檔。

18、（A）開發(fā)文檔 60、下列（ （B）需求文檔 （C）過程文檔 （D）用戶文檔 ）不是需求規(guī)格說明文檔的讀者？ （A）項(xiàng)目管理者 （B）編程人員 （C）銷售商 （D）律師 二、填空題 1、傳統(tǒng)的需求分析方法都是從設(shè)計領(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)域知識，保證功

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

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

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

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

23、的需求并加入到新的需求文檔之中。 31、需求工程師可以使用模型驅(qū)動方法來進(jìn)行信息的整理和歸類，其中模型驅(qū)動方法所 6 建立的模型是進(jìn)行信息整理和歸類的很好的框架依據(jù)。 32、模型驅(qū)動方法的模型是在前期需求階段的分析中建立的。 33、目標(biāo)模型的一個核心要素是元素之間的關(guān)系，稱為鏈接。 34、目標(biāo)模型的鏈接有兩類：一類是目標(biāo)之間的鏈接；另一類是目標(biāo)與其他模型元素之 間的鏈接。 35、面向目標(biāo)方法的處理過程可以分為三個階段：目標(biāo)獲取、目標(biāo)分析（即目標(biāo)模型的 建立）和目標(biāo)實(shí)現(xiàn)。 36、目標(biāo)實(shí)現(xiàn)階段的主要任務(wù)是收集與目標(biāo)相關(guān)的需求信息，討論可能的候選解決方案， 確定最終

24、的系統(tǒng)詳細(xì)需求和解決方案。 37、場景具有重點(diǎn)描述真實(shí)世界的特征，它利用情景、行為者之間的交互、事件隨時間 的演化等方式來敘述性地描述系統(tǒng)的使用。 38、靜態(tài)外觀的場景被展現(xiàn)為一個或者數(shù)個描述性的文本或者圖片。 39、動態(tài)外觀的場景會被以動態(tài)的方式展現(xiàn)出來，人們可能會要求按時序向前或者向后 瀏覽場景，也可能會要求跳轉(zhuǎn)到場景的某一個時刻進(jìn)行觀察。 40、交互外觀的場景提供交互性，它允許用戶在一定程度上控制和改變場景的變化時序 或者效果。 41、具體場景，又稱為實(shí)例場景，是對個別行為者、事件、情節(jié)的細(xì)節(jié)描述。 42、抽象場景，又稱為類型場景，是以經(jīng)驗(yàn)中的類別和抽象概念來描述事實(shí)。

25、 43、探索性場景可以用來進(jìn)行需求獲取和需求建模與分析。 44、每個用例是對相關(guān)場景集合的敘述性的文本描述，這些場景是用戶和系統(tǒng)之間的交 互行為序列，幫助實(shí)現(xiàn)用戶的目的。 45、用例是場景方法中的一種，是靜態(tài)的結(jié)構(gòu)化文本描述。 46、在高層的功能需求獲取完備之前，用例的產(chǎn)生方式中不允許使用功能分解方式。 47、單個用例描述了系統(tǒng)的功能片段，系統(tǒng)的所有用例基于一定的關(guān)系組織起來，建立 用例模型，就可以描述整個系統(tǒng)的功能。 48、原有用例和新建立的抽象用例的關(guān)系即為包含關(guān)系。 49、在需求工程中，主要產(chǎn)生三類重要的文檔：項(xiàng)目前景和范圍文檔、用戶需求文檔以 及需求規(guī)格說明。用例文

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

27、給出了一個模型元素描述的更 寬廣的上下文，以及影響該模型元素意義的約束和假定。 55、互相之間建立了語義聯(lián)系的多個模型，集成在一起通常被稱為視圖。 56、需求分析方法主要有：結(jié)構(gòu)化方法、信息工程方法和面向?qū)ο蠓椒?。其中面向?qū)? 象方法是目前工業(yè)界使用的主流方法。 57、信息工程和結(jié)構(gòu)化方法的本質(zhì)差別在于解決問題的策略不同。 58、前期需求階段分析的重點(diǎn)是理解問題世界，因此它關(guān)注的是整個問題世界，注重 7 于系統(tǒng)的環(huán)境、開發(fā)組織的業(yè)務(wù)背景、涉眾的特征以及目標(biāo)等等，軟件系統(tǒng)只是整個背景下 的一個要素。 59、后期需求階段分析關(guān)注的是解系統(tǒng)解決方案的建立，因此它以軟件系

28、統(tǒng)為中心， 注重于分析系統(tǒng)的內(nèi)部功能以及它與環(huán)境的互動，是對系統(tǒng)功能的詳細(xì)信息的分析。 60、以軟件復(fù)用為核心，建立產(chǎn)品族的方法被稱為產(chǎn)品線。 61、需求協(xié)商活動既包括對目標(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)動，它是系統(tǒng)與其環(huán)境之間或者系統(tǒng)內(nèi)兩個過程之間的通信 形式。 65、DFD的 0層圖中的每個過程都

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

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

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

32、稱為參與約束。 84、ERD中一個實(shí)體在關(guān)系中的最大基數(shù)是指，對關(guān)系中任意的其他實(shí)體實(shí)例，該實(shí) 體可能參與關(guān)系的最大數(shù)量。 85、ERD中一個實(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行為模型的活動圖是依據(jù)處理流程進(jìn)行的用例實(shí)現(xiàn)。 90、UML行為模型的交互圖通常描述的是單個用例的典型場景。 91、

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

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

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

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

37、） 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)并是一個自上而下分解的過程，也就是一個不斷發(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)?/p>

38、人們更傾向于會對真實(shí)事件和真實(shí)事物的描述產(chǎn) 生反應(yīng)。（√） 25、描述場景時所使用的常見媒介形式主要有：敘述性的自由文本、結(jié)構(gòu)化文本。強(qiáng)限 制文本、表格、圖表、圖像等。（√） 26、在實(shí)踐中，以動態(tài)的場景外觀為主。（） 27、場景內(nèi)包含的知識只能是關(guān)于未來的。（） 28、描述性場景的目的是為了記錄已經(jīng)得到的需求，即整理每次需求獲取行為中得到的 信息。（√） 29、UML就是以用例來捕獲系統(tǒng)所有的系統(tǒng)需求的。（） 30、用例的內(nèi)容只能包含有正常流程，而不能包含有異常流程。（） 31、用例可以用于各種目的的應(yīng)用，包括描述、探索和解釋。（√） 32、用例是在對現(xiàn)實(shí)世界的探索中或

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

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

41、44、上下文圖以黑盒看待和描述系統(tǒng)的方式使它非常適合描述系統(tǒng)的應(yīng)用環(huán)境、定義系 10 統(tǒng)的邊界，這正是 DFD在層次結(jié)構(gòu)中將其置于最高層的原因。（√） 45、數(shù)據(jù)模型說明了問題域和解系統(tǒng)共享的事物、對共享事物的描述和共享事物之間 的關(guān)系。（√） 46、ERD關(guān)系表達(dá)的不是邏輯上的鏈接（例如整體部分關(guān)系），而是實(shí)體物理上的聯(lián)系。 （） 47、ERD中存在于兩個實(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)證過程模型

42、和數(shù)據(jù)模塊的正確性，發(fā)現(xiàn)其中 的錯誤、遺漏、冗余和不一致。（√） 50、發(fā)起或觸發(fā)用例的外部用戶以及其他軟件系統(tǒng)等角色被稱為參與者。（√） 51、交互圖是對單個用例的典型場景的實(shí)現(xiàn)，適合于事務(wù)性業(yè)務(wù)工作的表示。（√） 52、UML行為模型的狀態(tài)圖是以狀態(tài)機(jī)模型的方式進(jìn)行的用例實(shí)現(xiàn)。狀態(tài)圖只能用來 實(shí)現(xiàn)單個用例。（） 53、OCL無法被用來描述程序的控制邏輯和工作流程。（√） 54、OCL的表達(dá)式定義可以在程序中得到直接的執(zhí)行。（） 55、軟件需求規(guī)格說明文檔是對部分系統(tǒng)功能分配給軟件部分的詳細(xì)描述。（） 56、硬件需求規(guī)格說明文檔是對整個系統(tǒng)功能當(dāng)中分配給硬件部分的詳細(xì)描述。

43、（√） 57、人機(jī)交互文檔是對整個系統(tǒng)功能中需要進(jìn)行人機(jī)交互部分的詳細(xì)描述。（√） 58、驗(yàn)證活動同樣普遍存在于需求分析過程中。（） 59、需求驗(yàn)證并不是一個可以一次結(jié)束的活動，它可能需要多次、反復(fù)地執(zhí)行驗(yàn)證。（√） 60、前向跟蹤是指需求在被獲取到軟件需求規(guī)格說明文檔之前的演化過程。（）定義 四、名詞解釋題 1、需求工程：需求工程是軟件工程的一個分支，它關(guān)注于軟件系統(tǒng)所應(yīng)予實(shí)現(xiàn)的現(xiàn)實(shí) 世界目標(biāo)、軟件系統(tǒng)的功能和軟件系統(tǒng)應(yīng)當(dāng)遵守的約束，同時它也關(guān)注以上因素和準(zhǔn)確的軟 件行為規(guī)格說明之間的聯(lián)系，關(guān)注以上因素與其隨時間或跨產(chǎn)品族而演化之后的相關(guān)因素之 間的聯(lián)系。 2、需求：IE

44、EE對需求的定義為： ①用戶為了解決問題或達(dá)到某些目標(biāo)所需要的條件或能力。 ②系統(tǒng)或系統(tǒng)部件為了滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔所規(guī)定的要求而需要具備 的條件或能力。 ③對①或②中的一個條件或一種能力的一種文檔化表述。 3、需求分析：需求分析是利用建模與分析技術(shù)對獲取筆錄的內(nèi)容進(jìn)行明確、整理、匯 總，建立一個綜合考慮問題域特性和需求的系統(tǒng)模型，然后根據(jù)系統(tǒng)模型將用戶需求轉(zhuǎn)化為 系統(tǒng)需求的需求工程活動。 4、前景（Vision）：前景描述了產(chǎn)品的作用以及最終的功能，它將所有涉眾都統(tǒng)一到一 個方向上。 5、范圍（scope）：范圍指出當(dāng)前項(xiàng)目是要解決產(chǎn)品長遠(yuǎn)規(guī)劃中的哪一部分，

45、范圍聲明 它為項(xiàng)目劃定了需求的界線。 11 6、用戶參與（User Involvement）：是以用戶為中心的設(shè)計方法的核心思想，它要求開 發(fā)者建立和用戶的直接聯(lián)系，盡早地關(guān)注于用戶和用戶的任務(wù)執(zhí)行過程，通過及時獲得用戶 的反饋來調(diào)整軟件設(shè)計，以完成高質(zhì)量的設(shè)計。另一方面，用戶參與就是反對通過和市場人 員、管理者等中間媒介來了解用戶，因?yàn)檫@些間接的聯(lián)系會減少或歪曲用戶的信息。 7、硬數(shù)據(jù)：表格和文檔資料是用戶對實(shí)際業(yè)務(wù)進(jìn)行加工和抽象之后的結(jié)果，是一種精 化過的知識。這些文檔資料被稱為硬數(shù)據(jù)。硬數(shù)據(jù)分為定量硬數(shù)據(jù)和定性硬數(shù)據(jù)兩種類型。 8、結(jié)構(gòu)化面談：結(jié)構(gòu)化面談指

46、在面談的過程中，會見者會完全按照事先的問題和結(jié)構(gòu) 來控制面談。結(jié)構(gòu)化面談通常被用來獲取一些比較確定或者選擇空間比較有限的信息，一些 統(tǒng)計性傾向信息的獲取也可以使用結(jié)構(gòu)化面談。 9、半結(jié)構(gòu)化面談：半結(jié)構(gòu)化面談指在面談的過程中，事先需要根據(jù)面談內(nèi)容準(zhǔn)備面談 的問題和面談結(jié)構(gòu)。但在面談過程中，會見者可以根據(jù)實(shí)際情況采取一些靈活的策略。半結(jié) 構(gòu)化面談是在需求獲取中應(yīng)用最多的一種面談類型，能夠處理大部分的需求獲取任務(wù)。 10、非結(jié)構(gòu)化面談：在非結(jié)構(gòu)化面談的過程中，沒有事先預(yù)定的議程安排。在比較極 端的情況下，會見者甚至?xí)跊]有太多事前準(zhǔn)備的情況下就直接到訪被會見者的工作地，就 某個主題開

47、展會談。 11、頭腦風(fēng)暴（Brainstorming）：是一種特殊的群體面談方式，它的目的不是發(fā)現(xiàn)需求， 而是“發(fā)明”需求，或者說是發(fā)現(xiàn)“潛在”需求。它鼓勵參與者在無約束的環(huán)境下進(jìn)行某些 問題的自由思考和自由討論，以產(chǎn)生新的想法。它是需求獲取中用于“發(fā)明”需求的方法， 但它會增加需求的數(shù)量。 12、原型：原型是一個系統(tǒng)，它內(nèi)化了（Capture）一個更遲系統(tǒng)（Later System）的本 質(zhì)特征。原型系統(tǒng)通常被構(gòu)造為不完整的系統(tǒng)，以在將來進(jìn)行改進(jìn)、補(bǔ)充或者替代?！? 13、嚴(yán)格意義上的原型：嚴(yán)格意義上的原型主要被用在需求分析階段，是開發(fā)者在建 立系統(tǒng)信息模型的同時建立的原型，通

48、常被用來闡明用戶界面或者系統(tǒng)功能的某些特定方 面，幫助人們及時地澄清問題。 14、場景：場景是對系統(tǒng)和環(huán)境行為的局部描述，或者說場景是對行為或者事件序列 的描述，序列中的行為和事件是系統(tǒng)需要完成的一個任務(wù)的特殊示例。 （也可以說，場景是用戶為了達(dá)到某個目標(biāo)而和軟件系統(tǒng)發(fā)生的行為交互序列，是開 發(fā)者描述軟件功能和需求的一種重要形式。） 15、情境性：情景性是指某些事件只有和它們發(fā)生時的具體環(huán)境聯(lián)系起來，才能得到 理解，它也是用戶無法完成主動信息告知的主要原因。 16、民族志：民族志是由人類學(xué)家最早提出來的，用來理解原始社會（Primitive Societies） 的社會機(jī)制。

49、它要求人類學(xué)家花費(fèi)長期的時間（通常是數(shù)年）在被研究的社會中生活并且仔 細(xì)觀察該社會中的實(shí)際活動，得到第一手的觀察數(shù)據(jù)。對這些觀察數(shù)據(jù)的分析可以揭示被研 究社會的社會結(jié)構(gòu)、組織方法和具體活動。 12 17、模型驅(qū)動法：模型驅(qū)動法是一類以定義明確的模型為理論基礎(chǔ)，依據(jù)模型指導(dǎo)和 組織活動開展的需求工程方法。 18、用例驅(qū)動法：用例是一種場景的文本化表現(xiàn)方式，使用敘述性的文本來描述場景。 以用例為核心，圍繞用例開展活動的軟件開發(fā)方法被稱為用例驅(qū)動的軟件開發(fā)方法。 19、企業(yè)建模：企業(yè)建模是以使用產(chǎn)品的組織團(tuán)體為系統(tǒng)的環(huán)境，進(jìn)行分析。它主要 用來理解組織的結(jié)構(gòu)、行為規(guī)則、

50、目標(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)功能的最高抽象，它將整個系 統(tǒng)看做是一個過程，這個過程實(shí)現(xiàn)系統(tǒng)的所有功能。上下文圖中存在且僅存在一個過程，表 示整個系統(tǒng)。這個單一的過程通常編號為 0。 22、概念數(shù)

51、據(jù)模型：概念數(shù)據(jù)模型是以問題域的語言解釋數(shù)據(jù)模型，反映了用戶對共 享事物的描述和看法，由一系列應(yīng)用領(lǐng)域的概念組成。 23、物理數(shù)據(jù)模型：物理數(shù)據(jù)模型是對數(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ù)模型的描述。 這種中立的語言使用更加傾向于用戶的概念和詞匯，同時使用更加傾向于解系統(tǒng)語言的表達(dá) 方式。 25、關(guān)系的基數(shù)：關(guān)系的基數(shù)是衡量關(guān)系復(fù)雜性的指標(biāo)之一，又被稱為關(guān)系的約束。 一個實(shí)體在關(guān)系

52、中的基數(shù)定義了在關(guān)系中其他實(shí)體實(shí)例確定的情況下，該實(shí)體實(shí)例可能參與 關(guān)系的數(shù)量。 26、交互圖（UML行為模型）：交互圖用于描述在特定上下文環(huán)境中一組對象的交互行 為，該上下文環(huán)境就是被實(shí)現(xiàn)用例的某個場景。所以，交互圖通常描述的是單個用例的典型 場景。交互圖中的每一個交互都描述了環(huán)境中的對象為了實(shí)現(xiàn)某個目標(biāo)而執(zhí)行的一系列消息 交換。 27、OCL（語言）：OCL（Object Constraint Language）稱為對象約束語言。OCL不是編 程語言而是一種建模語言，它在保證一定表達(dá)能力的前提下，注重于語言的簡潔性和抽象性。 但它無法被用來描述程序的控制邏輯和工作流程，而且

53、它的表達(dá)式定義也無法在程序中得到 直接的執(zhí)行。 13 28、基線：基線是已經(jīng)通過正式評審和批準(zhǔn)的規(guī)格說明或產(chǎn)品，可以作為進(jìn)一步開發(fā)的 基礎(chǔ)，并且只有通過正式的變更控制過程才能修改它。 29、需求基線：需求基線（Requirements Baseline）就是被明確和固定的需求集合，是 項(xiàng)目團(tuán)隊需要在某一特定產(chǎn)品版本中實(shí)現(xiàn)的特征和需求集合。 30、需求跟蹤：需求跟蹤是一種有效的控制手段，能夠在涉眾的需求變化中協(xié)調(diào)系統(tǒng)的 演化，保持各項(xiàng)開發(fā)工作對需求的一致性。需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在 向前和向后兩個方向上，描述需求以及跟蹤需求變化的能力，分為前向跟

54、蹤（ Pre— Traceabmty）和后向跟蹤（Post—Traceability）兩種。 五、問答題 1、簡述需求工程的主要任務(wù)。 答： 需求工程有以下三個主要任務(wù)： ①需求工程必須說明軟件系統(tǒng)將被應(yīng)用的環(huán)境及其目標(biāo)，說明用來達(dá)成這些目標(biāo)的軟 件功能，還要說明在設(shè)計和實(shí)現(xiàn)這些功能時上下文環(huán)境對軟件完成任務(wù)所用方式、方法所施 加的限制和約束，也即要同時說明軟件需要“做什么”和“為什么”需要做。 ②需求工程必須將目標(biāo)、功能和約束反映到軟件系統(tǒng)中，映射為可行的軟件行為，并 對軟件行為進(jìn)行準(zhǔn)確的規(guī)格說明。需求規(guī)格說明是需求工程最為重要的成果，是項(xiàng)目規(guī)劃、

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

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

57、用戶，這些 用戶關(guān)于需求的目標(biāo)互相沖突，需求工程師于是采用了模糊化的處理方法。正確解決方法是 在項(xiàng)目前景的指導(dǎo)下，促進(jìn)用戶之間的協(xié)商解決。 ③信息遺漏。 14 信息遺漏也是一類常見的問題，包括明顯的信息遺漏和不明顯的信息遺漏。 明顯的信息遺漏，其主要原因在于項(xiàng)目的范圍定義不當(dāng)，可以通過加強(qiáng)對業(yè)務(wù)需求的 處理得以解決。 不明顯的信息遺漏，是因?yàn)橄嚓P(guān)信息難以發(fā)現(xiàn)，只能靠需求工程師的經(jīng)驗(yàn)來加以避免。 ④不必要的需求。 產(chǎn)生不必要需求的原因主要是： 其一是用戶將一些不必要的需求作為和開發(fā)人員談判的籌碼，然后通過自己對不必要 需求的要求而在和開發(fā)人員的談判當(dāng)中取得真正

58、想要的利益，例如金錢。對此問題，唯一需 要的就是開發(fā)人員代表的談判技巧。 其二是用戶在交流中，總是害怕信息有所遺漏，并因此產(chǎn)生不利后果，因此用戶總是傾 向于表達(dá)各種各樣的需要。要解決這個問題，就需要開發(fā)人員在進(jìn)行用戶需求的獲取之前， 先定義明確的業(yè)務(wù)需求，然后根據(jù)業(yè)務(wù)需求進(jìn)行用戶需求的過濾和選擇。 其三是需求開發(fā)人員“畫蛇添足”，添加“用戶肯定會喜歡”的功能，該類功能既會造 成項(xiàng)目額外的耗費(fèi)，又不會給用戶帶來更多的幫助。這就要求需求開發(fā)人員要保持以用戶為 中心。 ⑤不切實(shí)際的期望。 不切實(shí)際的期望也是實(shí)踐中常見的需求定義問題，而且它在很大程度上影響著項(xiàng)目的 成敗。 面對不

59、切實(shí)際的期望，要求軟件開發(fā)者提供可行性、成本等足夠的技術(shù)參考信息，幫 助用戶對其進(jìn)行取舍和調(diào)整。 3、簡要說明需求獲取活動的過程。 答： （1）收集和應(yīng)用背景資料，建立初始的知識框架。分析涉眾的高層次問題，總結(jié)出系 統(tǒng)的業(yè)務(wù)需求。 （2）設(shè)計一個高層次的解決方案，并確定解決方案需要具備的系統(tǒng)特性。高層次的解 決方案和系統(tǒng)特性定義了項(xiàng)目的前景和范圍。 （3）在項(xiàng)目的業(yè)務(wù)范圍內(nèi)，需求工程要尋找相關(guān)的涉眾，并分析和涉眾選擇。 （4）對組織里存在大量的表格、單據(jù)等與業(yè)務(wù)相關(guān)的硬數(shù)據(jù)進(jìn)行采樣，它們是需求獲 取活動中一個重要的信息來源。 （5）針對某一次具體的需求獲取活動，要依據(jù)項(xiàng)目

60、范圍確定主題和內(nèi)容，涉眾特征和 硬數(shù)據(jù)，從而確定信息來源。獲取方法通常只有綜合內(nèi)容、來源和系統(tǒng)環(huán)境三者才能做出正 確的決定。 在內(nèi)容、來源和方法都確定之后，需求工程師就可以開展具體的獲取活動，獲取用戶 需求和問題域特性。 獲取得到的具體信息要記錄下來，以獲取筆錄的形式進(jìn)行保存。 4、簡述涉眾識別的基本過程。 答： 涉眾識別的基本過程如下： ①將初始涉眾集中起來，進(jìn)行一次頭腦風(fēng)暴，盡可能地列出一個涉眾類別列表。 ②對上一步產(chǎn)生的涉眾類別列表進(jìn)行分析，判斷它們和軟件系統(tǒng)的相關(guān)性，找出其中的 鍵涉眾類別。 ③為上一步的各個關(guān)鍵涉眾類別選擇代表，集中起來進(jìn)行進(jìn)一步的頭腦風(fēng)暴，列

61、出新的 15 涉眾類別列表。如果新列出的涉眾類別列表趨于穩(wěn)定，就可以結(jié)束涉眾識別過程。如果新列 出的涉眾類別列表有了新的發(fā)現(xiàn)，就提交新的涉眾類別列表，轉(zhuǎn)向第②步。 5、試比較面談問題組織的三種結(jié)構(gòu)。 答： （1）金字塔結(jié)構(gòu) 面談問題的歸納式組織被看做是金字塔形狀。使用這種形式時，會見者以很具體的問題 （通常是封閉式的問題）開始，然后逐漸提高問題的開放度，同時允許被會見者用越來越籠 統(tǒng)的答案來回答問題。 在主動的情況下，如果會見者認(rèn)為被會見者需要對話題進(jìn)行預(yù)熱，可以采用金字塔結(jié)構(gòu)， 通過逐步的引導(dǎo)使被會見者進(jìn)入討論。 在被動的情況下，如果會見者發(fā)現(xiàn)自己事先對事

62、實(shí)的確認(rèn)存在較大偏差或者被會見者看 上去不情愿討論某個話題，也可以采用金字塔結(jié)構(gòu)。 在某個話題討論結(jié)束的時候，使用金字塔結(jié)構(gòu)的提問順序也是有用的。 （2）漏斗結(jié)構(gòu) 在這種結(jié)構(gòu)中，會見者使用演繹的方法，以一般的、開放式的問題開始，然后用封閉式 的問題縮小可能的答復(fù)。這種面談結(jié)構(gòu)可看做是漏斗型。 在主動的情況下，漏斗結(jié)構(gòu)為開始一場面談提供了一種容易而輕松的途徑。答復(fù)者即使 答錯了開放式問題，也不會感到壓力。 在被動的情況下，當(dāng)被會見者對話題有情緒，并且需要自由表達(dá)這些情緒的時候，需要 采用漏斗型提問順序?；蛘咴跁娬呤孪葘κ聦?shí)了解不多時，也應(yīng)該采用漏斗結(jié)構(gòu)的問題組 織方式。

63、使用漏斗結(jié)構(gòu)的一個好處是：用這種方式組織面談能得出很多的詳細(xì)信息，以至于沒有 必要使用長序列的封閉式問題。 （3）菱形結(jié)構(gòu) 人們在面談中常常會將上述兩種結(jié)構(gòu)結(jié)合起來使用，其中菱形結(jié)構(gòu)就是一種最好的結(jié)合 結(jié)果。這種結(jié)構(gòu)以一種非常明確的方式開始，然后考察一般問題，最后得出一個非常明確的 結(jié)論。 會見者首先提出一些簡單的、封閉式的問題，為面談過程做好鋪墊。在面談的中間階段， 向被會見者提出明顯沒有“正確答案”的一般話題的看法。然后，會見者再次限制問題以獲 得明確的答復(fù)，這樣就為會見者和被會見者提供了面談的結(jié)束時機(jī)。 菱形結(jié)構(gòu)結(jié)合了其他兩種結(jié)構(gòu)的長處，但是也有缺點(diǎn)，即所花的時間比其他

64、任何一個都 長。 6、簡述軟件開發(fā)中為何使用原型工具以及使用的好處。 答： 因?yàn)樵褪窃谧罱K系統(tǒng)產(chǎn)生之前的一個局部真實(shí)表現(xiàn)，所以原型方法可以讓人們在系統(tǒng) 的開發(fā)過程中，就能夠?qū)σ恍┚唧w問題進(jìn)行基于實(shí)物的有效溝通，從而幫助人們盡早解決軟 件開發(fā)過程中存在的各種不確定性。不確定性是指人們已經(jīng)擁有的知識是不充分的，不足以 預(yù)測將來的事件發(fā)展，或者不足以清晰、準(zhǔn)確地描述某個事物。 實(shí)踐證明，利用原型有如下好處： ①及時、有力地響應(yīng)用戶需求的變化。 ②減少返工。 ③幫助控制不完整需求所帶來的風(fēng)險。 16 ④可以將一個大的難以處理的開發(fā)過程細(xì)分成一些更小更容易處理的步

65、驟。 ⑤減少開發(fā)成本，提高經(jīng)濟(jì)效益。 ⑥增加開發(fā)者之間的交流，幫助確定技術(shù)解決方案的可行性。 ⑦有效地識別風(fēng)險和解決風(fēng)險，幫助進(jìn)行風(fēng)險管理。 ⑧提高用戶在軟件開發(fā)中的參與程度。 7、試說明在哪些情景下原型法可以幫助需求工程師及早解決需求的不確定性。 答： ①產(chǎn)品以前從未存在過，而且難以可視化。這些產(chǎn)品屬于創(chuàng)新性產(chǎn)品，它們的基本需求 是潛在的，有著很大的不確定性。 ②產(chǎn)品的用戶對相關(guān)類別的產(chǎn)品沒有經(jīng)驗(yàn)，而且對將要采用的技術(shù)也沒有經(jīng)驗(yàn)。此時用 戶無法明確工作的具體細(xì)節(jié)，產(chǎn)品的細(xì)節(jié)需求存在著不確定性。 ③用戶進(jìn)行自己的工作已經(jīng)有一段時間了，但在完成工作的方式上仍然存在障礙。此時

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