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

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

2、（A）屬性和狀態(tài)（B）實體和狀態(tài)（C）實體和操作（D）狀態(tài)和操作5、功能需求通常分為三個層次，即業(yè)務(wù)需求、用戶需求和（）。（A）硬件需求（B）軟件需求（C）質(zhì)量屬性（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)這個最終物件，那么這個中間物件就被認為是最終物件在該廣度和深度上的（）。（A）模擬（B）構(gòu)造（C）原型（D）模型8、按照使用方式進行分類，原

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

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

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

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

7、和生命周期（C）描述和外觀（D）描述和目的26、描述場景所使用的表示法要符合正規(guī)性要求，一般可使用非形式化語言、半形式化語言和形式化語言。在實踐中，（）是主要的描述方式。（B）非形式化的自然語言（D）非形式化的設(shè)計語言（A）形式化的程序語言（C）形式化的圖形工具27、外觀是指場景被表達出來時的效果，主要有（A）靜態(tài)、動態(tài)和結(jié)構(gòu)化 （B）線性、非線性和交互（C）靜態(tài)、動態(tài)和動靜結(jié)合（D）靜態(tài)、動態(tài)和交互28、場景的內(nèi)容是指場景所表達的知識類型。它被分為 6個不同的方面。下列（）三種類型。）不是場景的內(nèi)容。（A）主要關(guān)注點 （B）環(huán)境范圍 （C）目的 （D）抽象層次29、需求工程利用場景的目的可能

8、有三種：即：（）。（A）描述、探索和解釋（C）描述、探索和發(fā)現(xiàn)（B）描述、表示和探索（D）表示、解釋和證明30、使用解釋性場景在需求分析時能夠（），或者被用于進行需求的驗證。（A）提高模型的復雜性 （B）降低模型的復雜性3請預(yù)覽后下載！ （C）提高預(yù)見性31、下列（D）降低編程量）不是場景方法在需求工程中的應(yīng)用。（A）幫助進行詳細的需求分析（B）編寫系統(tǒng)需求規(guī)格說明（C）結(jié)合面向目標的方法，指導需求獲取活動的開展（D）組織需求獲取得到的信息32、下列（）是組織場景時可用的場景關(guān)系。（A）合取關(guān)系（B）定性關(guān)系 （C）定量關(guān)系（D）演繹關(guān)系33、與其他的場景方法相比，用例最大的特點是采用了（）的

9、描述方式。（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、用例之間的關(guān)系主要有（A）包含、擴展和簡化（C）包含、多態(tài)和繼承（B）合取、析取和擴展（D）包含、擴展和泛化35、分析的活動主要包括識別、定義和結(jié)構(gòu)化，它的目的是獲取某個可以轉(zhuǎn)換為知識的事物的信息，這種分析活動被稱為（A）需求信息獲?。?。（B）建立軟件系統(tǒng)解決方案（D）建立需求分析模型（C）需求信息轉(zhuǎn)化36、（）是建模最為常用的兩種手段。（A）具體和抽象（B）抽象和分解（C）分解和細化（D）抽象和細化37、抽象通過強調(diào)本質(zhì)的特征，（）了問題的復雜性。（A）調(diào)整（B）避免（C）增加 （D）

10、減少38、需求分析僅僅需要描述解決方案，不需要探索實現(xiàn)細節(jié)的情況下，分析模型又是（）的，尤為適用。（A）形式化（B）半形式化（C）結(jié)構(gòu)化（D）非結(jié)構(gòu)化39、上下文圖描述系統(tǒng)與環(huán)境中外部實體之間的界限和聯(lián)系。它從現(xiàn)實世界的角度說明了系統(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）實體聯(lián)系圖 ERD（C）狀態(tài)轉(zhuǎn)換圖（D）上下文圖41、結(jié)構(gòu)化、信息工程和面向?qū)ο笕N方法學下的需求分析技術(shù)都是（A）面向問題域 （B）面向

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

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

13、這種存在才是）。（D）進程實體數(shù)據(jù)，被稱為屬性的（）。（A）域（B）實例（C）說明（D）值51、ERD中關(guān)系的度數(shù)（Degree）是指參與關(guān)系的實體數(shù)量，是度量關(guān)系（）的一個指標。（A）模型52、ERD中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最大基數(shù)又被稱為（A）鍵約束 （B）參與約束（C）自然約束 （D）一般約束53、在實體之間建立關(guān)系時，可能會產(chǎn)生一些附帶的實體，被稱為關(guān)聯(lián)實體，最常見（B）復雜度（C）精確度（D）屬性值）。的形式是（）。（A）邏輯實體（B）進程實體 （C）概念實體（D）自然實體54、在實現(xiàn) ERD與過程模型同步的技術(shù)中，（）是一種較為常見的技術(shù)。（A）用例圖55、下列（A）屬

14、性（B）數(shù)據(jù)流圖（C）功能實體矩陣（D）微規(guī)格說明）不是用例模型中的關(guān)系？（B）關(guān)聯(lián)（C）泛化（D）包含56、系統(tǒng)邊界是指一個系統(tǒng)所包含的系統(tǒng)成分與系統(tǒng)外事物的分界線。用例模型使用一個（）來表示系統(tǒng)邊界，以顯示系統(tǒng)的上下文環(huán)境。（A）圓形框（B）菱形框（C）虛線框 （D）矩形框57、UML使用的行為模型有三種，即：（）。（A）交互圖、狀態(tài)圖和順序圖（C）交互圖、狀態(tài)圖和活動圖（B）順序圖、通信圖和時間圖（D）交互概述圖、通信圖和時間圖58、項目的前景和范圍文檔、用戶需求文檔都被視為屬于（），重點都是用戶的現(xiàn)實世界。（A）開發(fā)文檔（B）需求文檔 （C）前景文檔（D）用戶文檔59、系統(tǒng)需求規(guī)格說明

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

16、目的），找出需要軟件解決的問題，理解應(yīng)用環(huán)境中的領(lǐng)域知識，保證功能的模擬性。5、需求工程是所有需求處理活動的總和，它收集信息、分析問題、整合觀點、記錄需求并驗證其正確性，最終反映軟件被應(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個特性，即完整性、正確性、精確性、可行性、必要性、無歧義和可驗證。9、所有對軟件系統(tǒng)的開發(fā)和應(yīng)用具有發(fā)言權(quán)和決定權(quán)的人統(tǒng)稱為涉眾。10、按照媒介載體進行分類，原型可分為：樣板原型和紙上向?qū)г汀?/p>

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

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

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

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

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

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

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

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

25、中所有的外部實體聯(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ù)的運動，它是系統(tǒng)與其環(huán)境之間或者系統(tǒng)內(nèi)兩個過程之間的通信形式。65、DFD的 0層圖中的每個過程都可以進行分解，被分解的過程稱為父過程，分解后產(chǎn)生的揭示更多細節(jié)的DFD圖稱為子圖。66、DFD的 0層圖通常被用來作為整個系統(tǒng)的功能概圖。67、為了保證DFD圖的可理解性，0層圖應(yīng)該被描述的簡潔、清晰，所以在描述復雜的系統(tǒng)時，0層圖中不應(yīng)出現(xiàn)太過具體的過程和數(shù)據(jù)存儲。68、DFD中對 0層圖的過程分解產(chǎn)生的子圖稱為1層圖。69、

26、數(shù)據(jù)建模建立的模型稱為數(shù)據(jù)模型，是問題域和解系統(tǒng)共享的知識集合，通常能夠反映企業(yè)業(yè)務(wù)的核心知識。70、數(shù)據(jù)模型的內(nèi)容是問題域和解系統(tǒng)所共享的知識模型，可以用問題域的語言來解釋，也可以用解系統(tǒng)的語言來解釋，還可以用介于問題域和解系統(tǒng)之間的中立語言來解釋。71、在需求工程中，數(shù)據(jù)建模建立的是概念數(shù)據(jù)模型和邏輯數(shù)據(jù)模型，不涉及物理數(shù)據(jù)模型。72、ERD的邏輯實體是對概念實體的細化，擁有完整的特征描述。73、數(shù)據(jù)建模中對行為和事件的建模需要是為了了解它們在某些時刻的快照或者運行環(huán)境信息，而不是它們所體現(xiàn)出來的功能和達成的效果，所以稱這類實體為進程實體。74、ERD中屬性就是可以對實體進行描述的特征，一

27、系列屬性的存在集成起來就可以描述一個實體的實例。75、ERD中屬性取值的受限制范圍稱為域（Domain）。76、ERD為實體指定一個屬性或多個屬性的組合，可以用來唯一地確定和標識每個實例，這些屬性或?qū)傩缘慕M合稱為實體的標識符，又稱為鍵。77、一個實體可能有多個鍵，這些鍵都被稱為候選鍵。78、通常人們從多個候選鍵中選擇和使用固定的某一個鍵來進行實例的標識，這個被選中的候選鍵被稱為主鍵，沒有被選做主鍵的候選鍵被稱為替代鍵。79、實體實例大多數(shù)屬性的值都是需要從現(xiàn)實中獲取的，稱為存儲屬性。80、有些實體實例的屬性的值是可以由其他屬性的值計算得出的，稱為導出屬性。81、關(guān)系是存在于一個或多個實體之間的

28、自然業(yè)務(wù)聯(lián)系。82、只有一個實體參與的關(guān)系存在于實體的不同實例之間，稱為一元關(guān)系，又稱為遞歸關(guān)系。83、ERD中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最小基數(shù)又被稱為參與約束。84、ERD中一個實體在關(guān)系中的最大基數(shù)是指，對關(guān)系中任意的其他實體實例，該實體可能參與關(guān)系的最大數(shù)量。85、ERD中一個實體在關(guān)系中的最小基數(shù)是指，對關(guān)系中任意的其他實體實例，該實8請預(yù)覽后下載！ 體可能參與關(guān)系的最小數(shù)量。86、ERD中被關(guān)系影響的實體主要是弱實體和關(guān)聯(lián)實體。87、用例模型的基本元素有四種：用例、參與者、關(guān)系和系統(tǒng)邊界。88、UML行為模型是用例模型的實現(xiàn)，以更加詳細的方式說明用例所描述的系統(tǒng)行為。89、

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

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

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

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

33、具體的需求獲取行為，還要求成功地處理多次獲取行為之間的關(guān)系。（）19、軟目標是一類無法清晰判斷是否滿足的目標，所以可以用 AND和 OR鏈接直接應(yīng)用于軟目標。（）20、子目標的實現(xiàn)只能促進父目標的實現(xiàn)。（）21、AND和 OR鏈接用于描述目標的分解和細化關(guān)系。（）22、目標的發(fā)現(xiàn)并是一個自上而下分解的過程，也就是一個不斷發(fā)現(xiàn)和細化的過程。（）23、對系統(tǒng)的現(xiàn)狀和背景進行分析往往能夠發(fā)現(xiàn)重要的目標，得到一些明確的問題和缺陷，它們的反面就是系統(tǒng)需要實現(xiàn)的目標。（）24、場景被人們廣泛接受的原因是因為人們更傾向于會對真實事件和真實事物的描述產(chǎn)生反應(yīng)。（）25、描述場景時所使用的常見媒介形式主要有：敘

34、述性的自由文本、結(jié)構(gòu)化文本。強限制文本、表格、圖表、圖像等。（）26、在實踐中，以動態(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)實世界的探索中或者是在對需求規(guī)格說明的解釋中產(chǎn)生的，是通過功能分解的方式創(chuàng)建的。（）33、抽象用例是不能被實例化的，它必須被包含在其他用例中才能得以執(zhí)行。（）34、用例間的泛化關(guān)系是指子用例繼承了父用例的特征。（）并增加了新的特征35、抽象一方面要求人們關(guān)注重要的信息，同時又不能忽略次要的內(nèi)容。另一方面也要求人們將認知保留在適當?shù)膶哟危帘胃顚哟蔚募毠?jié)。（）36、由于計算模型的形式化特征不適合于需求工程階