軟件需求分析筆試題庫(kù)

1、軟件需求分析題庫(kù)軟件需求分析課程組編2012年 4月目錄一、單項(xiàng)選擇題2二、填空題5三、判斷題9四、名詞解釋題11五、問(wèn)答題14六、案例分析題28軟件需求分析習(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ì)寫入（）。（ A ）可行性研究報(bào)告（C）用戶需求說(shuō)明4、現(xiàn)實(shí)世界中的（B）前景和范圍文檔（D）系統(tǒng)需求規(guī)格說(shuō)明）構(gòu)成了問(wèn)題解決的基本范圍 , 稱

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

3、）構(gòu)造（C）原型（D）模型8、按照使用方式進(jìn)行分類 , 原型可分為：演示原型、（）、試驗(yàn)原型和引示系統(tǒng)原型。（A）非操作原型（B）系列首發(fā)原型（C）選定特征原型（D）嚴(yán)格意義上的原型9、按照功能特征進(jìn)行分類 , 原型可分為：（ ）、非操作原型、系列首發(fā)原型和選定 特征原型。（A）拼湊原型（B）樣板原型（C）紙上向?qū)г停―）嚴(yán)格意義上的原型10、按照開(kāi)發(fā)方法進(jìn)行分類 , 原型可分為：演化式原型和拋棄式原型 , 其中拋棄式原 型又被細(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)用戶無(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í)15、下列（ ）不是需求獲取常見(jiàn)的模型驅(qū)動(dòng)方法？（A）面向目標(biāo)的方法（B）基于場(chǎng)景的方法。（C）基于用例的方法（D）基于采樣的方法16、下列（ ）屬于定量硬數(shù)據(jù)？（A

5、）工作手冊(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)表（D）備忘錄（C）年報(bào)表（D ）規(guī)章手冊(cè)（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）消極的（C）積極的或消極的（D ）不能確定20、AND鏈接將一個(gè)父目標(biāo)連接到一系列細(xì)化的子目標(biāo) 化的子目標(biāo) ,那么將（ ）父目標(biāo)。（A ）無(wú)法確定

6、（B）阻礙（C）不能滿足21、OR鏈接是將一個(gè)父目標(biāo)連接到一系列細(xì)化的子目標(biāo) 化子目標(biāo)中的（ ） ,那么將足以滿足父目標(biāo)。, 意思是如果能夠滿足所有細(xì)（D）足以滿足,意思是如果能夠滿足所有細(xì)（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)景的分類框架將場(chǎng)景方法從場(chǎng)景的（A）形式、目的、內(nèi)容和生命周期（C）描述、目的、內(nèi)容和形式） 4個(gè)方面進(jìn)行了分類和描述。B

7、 ）外觀、目的、內(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í)的效果, 主要有（ ）三種類型。（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)

8、景的內(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）描述、探索和解釋（B）描述、表示和探索（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）編寫系統(tǒng)需求規(guī)格說(shuō)明（C）結(jié)合面向目標(biāo)的方法，指導(dǎo)需求獲取活動(dòng)的開(kāi)展（D）組織需求獲

9、取得到的信息32、下列（ A ）合取關(guān)系33、與其他的場(chǎng)景方法相比（ 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í)別、 事物的信息 , 這種分析活動(dòng)被稱為（ A ）需求信息獲?。–）需求信息轉(zhuǎn)化）是組織場(chǎng)景時(shí)可用的場(chǎng)景關(guān)系。（B ）定性關(guān)系 （C）定量關(guān)系（D）演繹關(guān)系, 用例最大的特點(diǎn)是采用了（）的描述方式。（ B ）動(dòng)態(tài)非結(jié)構(gòu)化文本（D）動(dòng)態(tài)結(jié)構(gòu)化文本 ）三種。（ B ）合取、（D）包含、 定義和結(jié)構(gòu)化）。析取和擴(kuò)展擴(kuò)展和泛化, 它的目的是獲取某個(gè)可以轉(zhuǎn)換為知識(shí)的B ）建立軟件系統(tǒng)解決方

10、案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)境與外觀（B）邊界和聯(lián)系40、（ ）是結(jié)構(gòu)化分析方法的核心技術(shù) 及它們?nèi)绾卧谝黄饏f(xié)調(diào)

11、工作。（A ）數(shù)據(jù)流圖 DFD（ B）實(shí)體聯(lián)系圖（C）邊界和環(huán)境 （D）輸入和輸出, 它表明系統(tǒng)的輸入、處理、存儲(chǔ)和輸出 , 以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)題世界的建模就被稱為（A）前期 （B）中期（C）后期（D）全過(guò)程43、使用面向解系統(tǒng)的技術(shù)對(duì)軟件系統(tǒng)解決方案的描述稱為（A）前期 （B）中期（C）后期（D）全過(guò)程44、 需求分析活動(dòng)的一個(gè)重要任務(wù)是進(jìn)行（） ,明確用戶需求的隱含信息 ,展

12、開(kāi)為 明確的對(duì)軟件系統(tǒng)的行為期望 ,即系統(tǒng)需求。（A）需求整理（B）需求細(xì)化 （C）需求獲?。―）需求分析45、 在分層結(jié)構(gòu)中，DFD定義了三個(gè)層次類別的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ò)程建模在（）方面的缺陷 , 它描述數(shù)據(jù)的定義、結(jié) 構(gòu)和關(guān)系等特性。（A）需求分析（B）數(shù)據(jù)轉(zhuǎn)換 （C）數(shù)據(jù)說(shuō)明（D）數(shù)據(jù)分析48、。概念實(shí)體是一種抽象概念 ,不考慮

13、概念背后的物理存在 , 所以通常不包含與之相 關(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ù) ， 被稱為屬性的（）。（A）域（B）實(shí)例 （C）說(shuō)明 （D）值51、 ERD中關(guān)系的度數(shù)（Degree）是指參與關(guān)系的實(shí)體數(shù)量,是度量關(guān)系（）的 一個(gè)指標(biāo)。（A）模型 （B）復(fù)雜度（C）精確度 （D）屬性值52、ERD中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最大基數(shù)又被稱為（）。（A）鍵約束 （

14、B）參與約束（C）自然約束（D ）一般約束53、在實(shí)體之間建立關(guān)系時(shí) , 可能會(huì)產(chǎn)生一些附帶的實(shí)體 , 被稱為關(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、系統(tǒng)邊界是指一個(gè)系統(tǒng)所包含的系統(tǒng)成分與系統(tǒng)外事物的分界線。用例模型使用一個(gè)（ ）來(lái)表示系統(tǒng)邊界 , 以顯示系統(tǒng)的上下文環(huán)境。（A）圓形框（B）菱形框（C）虛線框 （D）矩形框5

15、7、UML 使用的行為模型有三種（A）交互圖、狀態(tài)圖和順序圖（C）交互圖、狀態(tài)圖和活動(dòng)圖, 即：（）。（B）順序圖、通信圖和時(shí)間圖（D）交互概述圖、通信圖和時(shí)間圖） , 重點(diǎn)都是用戶的現(xiàn)（D ）用戶文檔58、項(xiàng)目的前景和范圍文檔、用戶需求文檔都被視為屬于（ 實(shí)世界。（A ）開(kāi)發(fā)文檔（B ）需求文檔 （C）前景文檔59、系統(tǒng)需求規(guī)格說(shuō)明文檔、軟件需求規(guī)格說(shuō)明文檔、硬件需求規(guī)格說(shuō)明文檔、接口, 都被認(rèn)為是開(kāi)發(fā)文檔。需求規(guī)格說(shuō)明文檔和人機(jī)交互文檔一起被用于系統(tǒng)開(kāi)發(fā)的目的（A）開(kāi)發(fā)文檔（B）需求文檔（C）過(guò)程文檔（D）用戶文檔60、下列（）不是需求規(guī)格說(shuō)明文檔的讀者？（A）項(xiàng)目管理者（B ）編程人員（

16、C）銷售商 （D）律師、填空題1、傳統(tǒng)的需求分析方法都是從設(shè)計(jì)領(lǐng)域轉(zhuǎn)入分析領(lǐng)域的。2、面向?qū)I(yè)用戶的純工具型軟件分析階段的主要目的是為充分利用創(chuàng)新優(yōu)勢(shì)而進(jìn)行巧 妙的功能安排。, 尋找一套切實(shí)3、面向普通用戶的純工具型軟件進(jìn)行分析的主要目的是進(jìn)行方案權(quán)衡 有效的功能配置。4、應(yīng)用型軟件分析階段的主要目的是發(fā)現(xiàn)人們利用軟件的原因（目的）, 找出需要軟件解決的問(wèn)題 , 理解應(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、軟件需求開(kāi)發(fā)用來(lái)確定系統(tǒng)需求中應(yīng)該

17、由軟件滿足的部分, 將其映射為軟件行為 ,產(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)稱為涉眾。10、按照媒介載體進(jìn)行分類 , 原型可分為：樣板原型和紙上向?qū)г汀?1、演示原型主要被用在項(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)題

18、解決的可能性。14、通常來(lái)說(shuō) , 如果用戶需求出現(xiàn)了模糊、不清晰、不完整等具有一定不確定性的特征 就可以考慮使用原型方法。15、角色是指原型物件在用戶工作中的價(jià)值 , 也就是說(shuō)它為什么對(duì)用戶是有用的。16、外觀是指用戶對(duì)原型物件的具體感覺(jué)體驗(yàn) , 即用戶在使用原型物件時(shí)會(huì)看到什么、 聽(tīng)到什么和感覺(jué)到什么。17、實(shí)現(xiàn)是指原型物件完成功能的細(xì)節(jié)技術(shù)和方法。18、使用演化式原型方法 , 在開(kāi)發(fā)時(shí)就需要注意原型的健壯性和代碼的質(zhì)量。19、使用實(shí)驗(yàn)式開(kāi)發(fā)方法 , 需要實(shí)現(xiàn)多種技術(shù)方案 , 考察重要的系統(tǒng)的質(zhì)量屬性。20、選擇使用探索式開(kāi)發(fā)方法 , 需要盡可能地考慮各種不同的設(shè)計(jì)選項(xiàng) ,比較不同選項(xiàng) 下的

19、用戶反饋。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)行需要用戶具備一定的認(rèn)知 , 認(rèn)知要求已經(jīng)成了用戶工作必備 的部分 , 即工作具有涉身的情景性。26、采樣觀察是最簡(jiǎn)單的觀察方法 ,應(yīng)用目的是發(fā)現(xiàn)異常流程 , 驗(yàn)證用戶所述知識(shí)和實(shí)

20、際的一致性 , 以及發(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)行信息的整理和歸類 , 其中模型驅(qū)動(dòng)方法所 建立的模型是進(jìn)行信息整理和歸類的很好的框架依據(jù)。32、模型驅(qū)動(dòng)方法的模型是在前期需求階段的分析中建立的。33、目標(biāo)模

21、型的一個(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)敘述性地描述系統(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ì)要

22、求按時(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)之間的交 互行為序列 , 幫助實(shí)現(xiàn)用戶的目的。45、用例是場(chǎng)景方法中的一種 , 是靜態(tài)的結(jié)構(gòu)化文本描述。46、在高層的功能需求獲取完備之前 , 用

23、例的產(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、需求獲取得到的信息和需求開(kāi)發(fā)應(yīng)該建立的軟件系統(tǒng)解決方案之間有著很大的差 距。需求分析就是用來(lái)解決這個(gè)差距的需求工程活動(dòng)。51、需求分析的根本任務(wù)是：建立分析模型并創(chuàng)建解決方案。52、分解將單個(gè)復(fù)雜和

24、難以理解的問(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)化方法、信息工程方法和面向?qū)ο蠓椒?。其中面向?qū)?象方法是目前工業(yè)界使用的主流方法。57、信息工程和結(jié)構(gòu)化方法的本質(zhì)差別

25、在于解決問(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ǎn)品線。61、 需求協(xié)商活動(dòng)既包括對(duì)目標(biāo)沖突的處理，也包括對(duì)需求細(xì)節(jié)沖突的處理。62、微規(guī)格說(shuō)明被用來(lái)描述 DFD過(guò)程分解結(jié)構(gòu)中最底層過(guò)程的處理邏輯。63、 DFD中所有的外部實(shí)體聯(lián)合起來(lái)構(gòu)成了軟件系統(tǒng)的外

26、部上下文環(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、 DFD中對(duì)0層圖的過(guò)程分解產(chǎn)生的子圖稱為1層圖。69、 數(shù)據(jù)建模建立的模型稱為數(shù)據(jù)模型

27、，是問(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í)體為進(jìn)程實(shí)體。74、 ERD中屬性就是可以對(duì)實(shí)體進(jìn)行描述的特征，一系列屬性的存在集

28、成起來(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í)例的屬性的值是可以由其他屬性的值計(jì)算得出的，稱為導(dǎo)出屬性。81、關(guān)系是存在于一個(gè)或多個(gè)實(shí)體之間的自

29、然業(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、UML 行為模型是用例模型的實(shí)現(xiàn) , 以更加詳細(xì)的方式說(shuō)明用例所描述的系統(tǒng)行為。89、UM

30、L 行為模型的活動(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ā)、用戶手冊(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、需求基線的

31、維護(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è)方面。（X）2、需求驗(yàn)證是需求工程中最后一個(gè)活動(dòng)。（X）3、 軟件系統(tǒng)能夠與問(wèn)題域進(jìn)行交互和相互影響的原因在于, 軟件系統(tǒng)中的某些部分對(duì)問(wèn) 題域中的某些部分具有模擬特性。（V）4、 規(guī)格說(shuō)明

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

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

34、統(tǒng)的產(chǎn)物, 因此它是正確的 , 也正是客戶所 需要的。（X）18、 成功的需求獲取任務(wù)不僅要求成功地執(zhí)行每一次具體的需求獲取行為， 還要求成功 地處理多次獲取行為之間的關(guān)系。（V）19、 軟目標(biāo)是一類無(wú)法清晰判斷是否滿足的目標(biāo)，所以可以用 AND和OR鏈接直接應(yīng) 用于軟目標(biāo)。（X）20、子目標(biāo)的實(shí)現(xiàn)只能促進(jìn)父目標(biāo)的實(shí)現(xiàn)。（X）21、AND和 OR鏈接用于描述目標(biāo)的分解和細(xì)化關(guān)系。（V）22、 目標(biāo)的發(fā)現(xiàn)并是一個(gè)自上而下分解的過(guò)程，也就是一個(gè)不斷發(fā)現(xiàn)和細(xì)化的過(guò)程。（X）23、 對(duì)系統(tǒng)的現(xiàn)狀和背景進(jìn)行分析往往能夠發(fā)現(xiàn)重要的目標(biāo)，得到一些明確的問(wèn)題和缺 陷，它們的反面就是系統(tǒng)需要實(shí)現(xiàn)的目標(biāo)。（V）2

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

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

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

38、（X）44、上下文圖以黑盒看待和描述系統(tǒng)的方式使它非常適合描述系統(tǒng)的應(yīng)用環(huán)境、定義系統(tǒng)的邊界，這正是 DFD在層次結(jié)構(gòu)中將其置于最高層的原因。（V）45、數(shù)據(jù)模型說(shuō)明了問(wèn)題域和解系統(tǒng)共享的事物、對(duì)共享事物的描述和共享事物之間 的關(guān)系。（V）46、 ERD關(guān)系表達(dá)的不是邏輯上的鏈接（例如整體部分關(guān)系）,而是實(shí)體物理上的聯(lián)系。 （X）47、 ERD中存在于兩個(gè)實(shí)體之間的關(guān)系是最常見(jiàn)的關(guān)系,稱為二兀關(guān)系。（V）48、 ERD中子類型關(guān)系是實(shí)體間自然的業(yè)務(wù)聯(lián)系，而不是人為施加的結(jié)構(gòu)關(guān)系，是一 種特殊的實(shí)體間關(guān)系。（X）49、 建立功能實(shí)體矩陣的過(guò)程可以幫助驗(yàn)證過(guò)程模型和數(shù)據(jù)模塊的正確性, 發(fā)現(xiàn)其中 的

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

40、人機(jī)交互部分的詳細(xì)描述。 （V）58、驗(yàn)證活動(dòng)同樣普遍存在于需求分析過(guò)程中。（X）59、 需求驗(yàn)證并不是一個(gè)可以一次結(jié)束的活動(dòng)，它可能需要多次、反復(fù)地執(zhí)行驗(yàn)證。（V）60、前向跟蹤是指需求在被獲取到軟件需求規(guī)格說(shuō)明文檔之前的演化過(guò)程。（X）定義四、名詞解釋題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)注以上因素和準(zhǔn)確的軟 件行為規(guī)格說(shuō)明之間的聯(lián)系 ， 關(guān)注以上因素與其隨時(shí)間或跨產(chǎn)品族而演化之后的相關(guān)因素之 間的聯(lián)系。2、需求：IEEE對(duì)需求的定義為： 用戶為了解決問(wèn)題或達(dá)到某些目標(biāo)所需要的條件或能力

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

42、戶為中心的設(shè)計(jì)方法的核心思想 , 它要求開(kāi) 發(fā)者建立和用戶的直接聯(lián)系 , 盡早地關(guān)注于用戶和用戶的任務(wù)執(zhí)行過(guò)程 , 通過(guò)及時(shí)獲得用戶 的反饋來(lái)調(diào)整軟件設(shè)計(jì) , 以完成高質(zhì)量的設(shè)計(jì)。另一方面 , 用戶參與就是反對(duì)通過(guò)和市場(chǎng)人 員、管理者等中間媒介來(lái)了解用戶 , 因?yàn)檫@些間接的聯(lián)系會(huì)減少或歪曲用戶的信息。7、硬數(shù)據(jù)：表格和文檔資料是用戶對(duì)實(shí)際業(yè)務(wù)進(jìn)行加工和抽象之后的結(jié)果, 是一種精化過(guò)的知識(shí)。這些文檔資料被稱為硬數(shù)據(jù)。硬數(shù)據(jù)分為定量硬數(shù)據(jù)和定性硬數(shù)據(jù)兩種類型。8、結(jié)構(gòu)化面談：結(jié)構(gòu)化面談指在面談的過(guò)程中, 會(huì)見(jiàn)者會(huì)完全按照事先的問(wèn)題和結(jié)構(gòu)來(lái)控制面談。結(jié)構(gòu)化面談通常被用來(lái)獲取一些比較確定或者選擇空間比

43、較有限的信息 , 一些 統(tǒng)計(jì)性傾向信息的獲取也可以使用結(jié)構(gòu)化面談。9、半結(jié)構(gòu)化面談：半結(jié)構(gòu)化面談指在面談的過(guò)程中, 事先需要根據(jù)面談內(nèi)容準(zhǔn)備面談的問(wèn)題和面談結(jié)構(gòu)。但在面談過(guò)程中 , 會(huì)見(jiàn)者可以根據(jù)實(shí)際情況采取一些靈活的策略。半結(jié) 構(gòu)化面談是在需求獲取中應(yīng)用最多的一種面談?lì)愋? 能夠處理大部分的需求獲取任務(wù)。10、非結(jié)構(gòu)化面談：在非結(jié)構(gòu)化面談的過(guò)程中, 沒(méi)有事先預(yù)定的議程安排。在比較極端的情況下 , 會(huì)見(jiàn)者甚至?xí)跊](méi)有太多事前準(zhǔn)備的情況下就直接到訪被會(huì)見(jiàn)者的工作地 , 就 某個(gè)主題開(kāi)展會(huì)談。11、頭腦風(fēng)暴( Brainstorming )：是一種特殊的群體面談方式 , 它的目的不是發(fā)現(xiàn)需求 而是

44、“發(fā)明”需求 , 或者說(shuō)是發(fā)現(xiàn)“潛在”需求。它鼓勵(lì)參與者在無(wú)約束的環(huán)境下進(jìn)行某些 問(wè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) , 以在將來(lái)進(jìn)行改進(jìn)、補(bǔ)充或者替代?！?3、嚴(yán)格意義上的原型：嚴(yán)格意義上的原型主要被用在需求分析階段, 是開(kāi)發(fā)者在建立系統(tǒng)信息模型的同時(shí)建立的原型 , 通常被用來(lái)闡明用戶界面或者系統(tǒng)功能的某些特定方 面, 幫助人們及時(shí)地澄清問(wèn)題。1 4 、場(chǎng)景：場(chǎng)景是對(duì)系統(tǒng)和環(huán)

45、境行為的局部描述, 或者說(shuō)場(chǎng)景是對(duì)行為或者事件序列的描述 , 序列中的行為和事件是系統(tǒng)需要完成的一個(gè)任務(wù)的特殊示例。(也可以說(shuō) , 場(chǎng)景是用戶為了達(dá)到某個(gè)目標(biāo)而和軟件系統(tǒng)發(fā)生的行為交互序列, 是開(kāi)發(fā)者描述軟件功能和需求的一種重要形式。)15、情境性：情景性是指某些事件只有和它們發(fā)生時(shí)的具體環(huán)境聯(lián)系起來(lái), 才能得到理解,它也是用戶無(wú)法完成主動(dòng)信息告知的主要原因。1 6 、民族志：民族志是由人類學(xué)家最早提出來(lái)的, 用來(lái)理解原始社會(huì)( Primitive Societies )的社會(huì)機(jī)制。它要求人類學(xué)家花費(fèi)長(zhǎng)期的時(shí)間(通常是數(shù)年)在被研究的社會(huì)中生活并且仔 細(xì)觀察該社會(huì)中的實(shí)際活動(dòng) , 得到第一手的

46、觀察數(shù)據(jù)。對(duì)這些觀察數(shù)據(jù)的分析可以揭示被研 究社會(huì)的社會(huì)結(jié)構(gòu)、組織方法和具體活動(dòng)。17、模型驅(qū)動(dòng)法：模型驅(qū)動(dòng)法是一類以定義明確的模型為理論基礎(chǔ), 依據(jù)模型指導(dǎo)和組織活動(dòng)開(kāi)展的需求工程方法。18、用例驅(qū)動(dòng)法：用例是一種場(chǎng)景的文本化表現(xiàn)方式, 使用敘述性的文本來(lái)描述場(chǎng)景。以用例為核心 , 圍繞用例開(kāi)展活動(dòng)的軟件開(kāi)發(fā)方法被稱為用例驅(qū)動(dòng)的軟件開(kāi)發(fā)方法。19、企業(yè)建模：企業(yè)建模是以使用產(chǎn)品的組織團(tuán)體為系統(tǒng)的環(huán)境, 進(jìn)行分析。它主要用來(lái)理解組織的結(jié)構(gòu)、行為規(guī)則、目標(biāo)、重要成員的任務(wù)與職責(zé)、操縱的數(shù)據(jù)等。企業(yè)建模 利用企業(yè)的目標(biāo)、任務(wù)、策略、資源等來(lái)刻畫組織的行為 , 并依此來(lái)發(fā)現(xiàn)組織開(kāi)發(fā)系統(tǒng)的目 的, 建

47、立系統(tǒng)的業(yè)務(wù)需求。20、過(guò)程建模：過(guò)程建模是結(jié)構(gòu)化分析方法的典型技術(shù)。過(guò)程建模將系統(tǒng)看做是過(guò)程 的集合 , 其中一些由人來(lái)執(zhí)行 , 另一些由軟件系統(tǒng)來(lái)執(zhí)行。過(guò)程建模使用的主要技術(shù)有上下 文圖、數(shù)據(jù)流圖、微規(guī)格說(shuō)明和數(shù)據(jù)字典等。21、 上下文圖：上下文圖是DFD最高層次的圖，是系統(tǒng)功能的最高抽象，它將整個(gè)系統(tǒng)看做是一個(gè)過(guò)程 , 這個(gè)過(guò)程實(shí)現(xiàn)系統(tǒng)的所有功能。上下文圖中存在且僅存在一個(gè)過(guò)程, 表示整個(gè)系統(tǒng)。這個(gè)單一的過(guò)程通常編號(hào)為0。22、 概念數(shù)據(jù)模型：概念數(shù)據(jù)模型是以問(wèn)題域的語(yǔ)言解釋數(shù)據(jù)模型， 反映了用戶對(duì)共 享事物的描述和看法 ， 由一系列應(yīng)用領(lǐng)域的概念組成。23、 物理數(shù)據(jù)模型：物理數(shù)據(jù)模型

48、是對(duì)數(shù)據(jù)模型的解系統(tǒng)語(yǔ)言的解釋， 它描述的是共 享事物在解系統(tǒng)中的實(shí)現(xiàn)形式 ， 是形式化的定義。24、邏輯數(shù)據(jù)模型：邏輯數(shù)據(jù)模型是為了緩解開(kāi)發(fā)人員將概念數(shù)據(jù)模型轉(zhuǎn)換成物理數(shù) 據(jù)模型的困難 ， 而使用一種介于問(wèn)題域和解系統(tǒng)之間的中立語(yǔ)言來(lái)進(jìn)行的數(shù)據(jù)模型的描述。 這種中立的語(yǔ)言使用更加傾向于用戶的概念和詞匯 ， 同時(shí)使用更加傾向于解系統(tǒng)語(yǔ)言的表達(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ì)

49、象的交互行 為， 該上下文環(huán)境就是被實(shí)現(xiàn)用例的某個(gè)場(chǎng)景。所以 ， 交互圖通常描述的是單個(gè)用例的典型 場(chǎng)景。交互圖中的每一個(gè)交互都描述了環(huán)境中的對(duì)象為了實(shí)現(xiàn)某個(gè)目標(biāo)而執(zhí)行的一系列消息 交換。27、 OCL （語(yǔ)言）：OCL （ Object Constraint Language ）稱為對(duì)象約束語(yǔ)言。OCL不是編 程語(yǔ)言而是一種建模語(yǔ)言 ， 它在保證一定表達(dá)能力的前提下 ， 注重于語(yǔ)言的簡(jiǎn)潔性和抽象性。 但它無(wú)法被用來(lái)描述程序的控制邏輯和工作流程 ， 而且它的表達(dá)式定義也無(wú)法在程序中得到 直接的執(zhí)行。28、基線：基線是已經(jīng)通過(guò)正式評(píng)審和批準(zhǔn)的規(guī)格說(shuō)明或產(chǎn)品, 可以作為進(jìn)一步開(kāi)發(fā)的基礎(chǔ) , 并且只

50、有通過(guò)正式的變更控制過(guò)程才能修改它。29、需求基線：需求基線( Requirements Baseline )就是被明確和固定的需求集合 , 是 項(xiàng)目團(tuán)隊(duì)需要在某一特定產(chǎn)品版本中實(shí)現(xiàn)的特征和需求集合。30、需求跟蹤：需求跟蹤是一種有效的控制手段 , 能夠在涉眾的需求變化中協(xié)調(diào)系統(tǒng)的 演化 , 保持各項(xiàng)開(kāi)發(fā)工作對(duì)需求的一致性。需求跟蹤是以軟件需求規(guī)格說(shuō)明文檔為基線, 在向前和向后兩個(gè)方向上 , 描述需求以及跟蹤需求變化的能力 , 分為前向跟蹤(PreTraceabmty )和后向跟蹤( Post Traceability )兩種。五、問(wèn)答題1、簡(jiǎn)述需求工程的主要任務(wù)。答：需求工程有以下三個(gè)主要任

51、務(wù)： 需求工程必須說(shuō)明軟件系統(tǒng)將被應(yīng)用的環(huán)境及其目標(biāo) , 說(shuō)明用來(lái)達(dá)成這些目標(biāo)的軟 件功能 , 還要說(shuō)明在設(shè)計(jì)和實(shí)現(xiàn)這些功能時(shí)上下文環(huán)境對(duì)軟件完成任務(wù)所用方式、方法所施 加的限制和約束 , 也即要同時(shí)說(shuō)明軟件需要“做什么”和“為什么”需要做。 需求工程必須將目標(biāo)、功能和約束反映到軟件系統(tǒng)中，映射為可行的軟件行為，并對(duì)軟件行為進(jìn)行準(zhǔn)確的規(guī)格說(shuō)明。需求規(guī)格說(shuō)明是需求工程最為重要的成果, 是項(xiàng)目規(guī)劃、設(shè)計(jì)、測(cè)試、用戶手冊(cè)編寫等很多后繼軟件開(kāi)發(fā)階段的工作基礎(chǔ)。 現(xiàn)實(shí)世界是不斷變化的世界 ， 因此需求工程還需要妥善處理目標(biāo)、功能和約束隨著 時(shí)間的演化情況。同時(shí) ， 為了節(jié)省開(kāi)支和進(jìn)行需求規(guī)格說(shuō)明的重用

52、， 需求工程還需要對(duì)目標(biāo)、 功能和約束在軟件產(chǎn)品族中的演化和分布情況進(jìn)行綜合考慮與處理。2、簡(jiǎn)述常見(jiàn)的需求定義錯(cuò)誤。 答：(劃線部分為必答要點(diǎn)) 在實(shí)踐和研究過(guò)程中 ， 人們發(fā)現(xiàn)關(guān)于需求定義的具體的錯(cuò)誤主要有以下幾種： 需求并沒(méi)有反映用戶的真實(shí)需要。實(shí)踐表明 ， 獲取用戶的真實(shí)需求是非常困難的。 原因之一是用戶在表達(dá)自己的需要時(shí) ， 可能會(huì)在潛意識(shí)下進(jìn)行一定的加工。為了發(fā)現(xiàn) 用戶的真實(shí)需求 ， 需求工程師一定要進(jìn)行問(wèn)題分析 ， 盡力發(fā)現(xiàn)問(wèn)題背后的問(wèn)題。原因之二是在人際交流中 ， 信息會(huì)發(fā)生自然的衰減 ， 甚至扭曲 ， 導(dǎo)致需求丁程師理解 的并非是用戶所表達(dá)的。解決方法是在需求傳遞給開(kāi)發(fā)人員之前

53、， 請(qǐng)?zhí)岢鲂枨蟮挠脩暨M(jìn)行仔細(xì)地檢查和確認(rèn)。 模糊和歧義的需求。在實(shí)踐中 ， 人們總是會(huì)有意和無(wú)意地寫出模糊和歧義的需求定義。 無(wú)意中寫出模糊和歧義的需求定義往往是因?yàn)檫x詞造句不當(dāng) ， 導(dǎo)致不同的人對(duì)同一項(xiàng) 需求產(chǎn)生了不同的理解。解決方法是為項(xiàng)目中重要的詞匯建立一個(gè)公共的可共同理解的詞匯 表， 然后在詞匯表的基礎(chǔ)之上進(jìn)行需求的定義。有意產(chǎn)生的模糊和歧義的需求定義往往是為了應(yīng)付對(duì)需求持有不同立場(chǎng)的用戶， 這些用戶關(guān)于需求的目標(biāo)互相沖突 ， 需求工程師于是采用了模糊化的處理方法。正確解決方法是 在項(xiàng)目前景的指導(dǎo)下 ， 促進(jìn)用戶之間的協(xié)商解決。 信息遺漏。信息遺漏也是一類常見(jiàn)的問(wèn)題 , 包括明顯的信息

54、遺漏和不明顯的信息遺漏。明顯的信息遺漏 , 其主要原因在于項(xiàng)目的范圍定義不當(dāng) , 可以通過(guò)加強(qiáng)對(duì)業(yè)務(wù)需求的 處理得以解決。不明顯的信息遺漏 ,是因?yàn)橄嚓P(guān)信息難以發(fā)現(xiàn) , 只能靠需求工程師的經(jīng)驗(yàn)來(lái)加以避免。 不必要的需求。產(chǎn)生不必要需求的原因主要是： 其一是用戶將一些不必要的需求作為和開(kāi)發(fā)人員談判的籌碼, 然后通過(guò)自己對(duì)不必要需求的要求而在和開(kāi)發(fā)人員的談判當(dāng)中取得真正想要的利益 , 例如金錢。對(duì)此問(wèn)題 , 唯一需 要的就是開(kāi)發(fā)人員代表的談判技巧。其二是用戶在交流中 , 總是害怕信息有所遺漏 , 并因此產(chǎn)生不利后果 , 因此用戶總是傾 向于表達(dá)各種各樣的需要。要解決這個(gè)問(wèn)題 , 就需要開(kāi)發(fā)人員在進(jìn)

55、行用戶需求的獲取之前 , 先定義明確的業(yè)務(wù)需求 , 然后根據(jù)業(yè)務(wù)需求進(jìn)行用戶需求的過(guò)濾和選擇。其三是需求開(kāi)發(fā)人員“畫蛇添足” , 添加“用戶肯定會(huì)喜歡”的功能 , 該類功能既會(huì)造 成項(xiàng)目額外的耗費(fèi) , 又不會(huì)給用戶帶來(lái)更多的幫助。這就要求需求開(kāi)發(fā)人員要保持以用戶為 中心。 不切實(shí)際的期望。不切實(shí)際的期望也是實(shí)踐中常見(jiàn)的需求定義問(wèn)題 , 而且它在很大程度上影響著項(xiàng)目的 成敗。面對(duì)不切實(shí)際的期望 ,要求軟件開(kāi)發(fā)者提供可行性、成本等足夠的技術(shù)參考信息 , 幫 助用戶對(duì)其進(jìn)行取舍和調(diào)整。3、簡(jiǎn)要說(shuō)明需求獲取活動(dòng)的過(guò)程。答：（1）收集和應(yīng)用背景資料 ,建立初始的知識(shí)框架。分析涉眾的高層次問(wèn)題 , 總結(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ì)組織里存在大量的表格、單據(jù)等與業(yè)務(wù)相關(guān)的硬數(shù)據(jù)進(jìn)行采樣, 它們是需求獲取活動(dòng)中一個(gè)重要的信息來(lái)源。（ 5）針對(duì)某一次具體的需求