1、-?軟件需求分析?習(xí)題集 ?軟件需求分析?課程組編2021年 4月. z-目 錄一、單項選擇題2二、填空題5三、判斷題9四、名詞解釋題11五、問答題14六、案例分析題281. z-?軟件需求分析?習(xí)題集一、單項選擇題1、軟件生產(chǎn)中產(chǎn)生需求問題的最大原因在于對應(yīng)用軟件的理解不透徹或應(yīng)用不堅決。A復(fù)雜性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)成了問題解決的根本圍，稱為該問題的問題域。A屬性和狀態(tài)B實體和

2、狀態(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被用來在一定廣度和深度圍表現(xiàn)這個最終物件，則這個中間物件就被認為是最終物件在該廣度和深度上的。A模擬B構(gòu)造C原型D模型8、按照使用方式進展分類，原型可分為：演示原型、試驗原型和引示系統(tǒng)原型。A非操作原型B系列首發(fā)原型C選定特征原型D嚴格意義上的原型9、按照

3、功能特征進展分類，原型可分為： 、非操作原型、系列首發(fā)原型和選定特征原型。A拼湊原型B樣板原型C紙上向?qū)г虳嚴格意義上的原型10、按照開發(fā)方法進展分類，原型可分為：演化式原型和拋棄式原型，其中拋棄式原型又被細分為。A演示原型和試驗原型C探索式原型和實驗式原型B系列首發(fā)原型和選定特征原型D樣板原型和紙上向?qū)г?1、原型的需求容可以從三個緯度上分析：即。A外觀、角色和實現(xiàn)C本錢、技術(shù)和實現(xiàn)B開發(fā)、實現(xiàn)和作用D需求、作用和角色12、當(dāng)用戶無法完成主動的信息告知，或與需求工程師之間的語言交流無法產(chǎn)生有效的結(jié)果時，有必要采用。A民族志13、以下A突現(xiàn)14、以下A全局B觀察法C話語分析D任務(wù)分析D模糊

4、D即時不是情景性的重要性質(zhì).B涉身C完善是情景性的重要性質(zhì).B開放 C交互2. z-15、以下不是需求獲取常見的模型驅(qū)動方法.A面向目標(biāo)的方法C基于用例的方法B基于場景的方法。D基于采樣的方法16、以下屬于定量硬數(shù)據(jù).A工作手冊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維護目標(biāo)和實現(xiàn)目標(biāo)19、在表達軟目標(biāo)的分解和細化時使用的 AND Contribution和 OR Contribution鏈接，Contribution的作用是A積極的 B消極的20

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

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

7、抽象層次29、需求工程利用場景的目的可能有三種：即：。A描述、探索和解釋C描述、探索和發(fā)現(xiàn)B描述、表示和探索D表示、解釋和證明30、使用解釋性場景在需求分析時能夠，或者被用于進展需求的驗證。A提高模型的復(fù)雜性 B降低模型的復(fù)雜性3. z-C提高預(yù)見性31、以下D降低編程量不是場景方法在需求工程中的應(yīng)用。A幫助進展詳細的需求分析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、與其他的場景方法相比，用例最大的特點是采用了的描述方式。A靜態(tài)非構(gòu)造化文本C靜態(tài)構(gòu)造化文本B動態(tài)

8、非構(gòu)造化文本D動態(tài)構(gòu)造化文本三種。34、用例之間的關(guān)系主要有A包含、擴展和簡化C包含、多態(tài)和繼承B合取、析取和擴展D包含、擴展和泛化35、分析的活動主要包括識別、定義和構(gòu)造化，它的目的是獲取*個可以轉(zhuǎn)換為知識的事物的信息，這種分析活動被稱為A需求信息獲取。B建立軟件系統(tǒng)解決方案D建立需求分析模型C需求信息轉(zhuǎn)化36、是建模最為常用的兩種手段。A具體和抽象B抽象和分解C分解和細化D抽象和細化37、抽象通過強調(diào)本質(zhì)的特征，了問題的復(fù)雜性。A調(diào)整B防止C增加 D減少38、需求分析僅僅需要描述解決方案，不需要探索實現(xiàn)細節(jié)的情況下，分析模型又是的，尤為適用。A形式化B半形式化C構(gòu)造化D非構(gòu)造化39、上下文

9、圖描述系統(tǒng)與環(huán)境中外部實體之間的界限和聯(lián)系。它從現(xiàn)實世界的角度說明了系統(tǒng)的，并確定了所有的輸入和輸出。A環(huán)境與外觀40、B邊界和聯(lián)系C邊界和環(huán)境 D輸入和輸出是構(gòu)造化分析方法的核心技術(shù)，它說明系統(tǒng)的輸入、處理、存儲和輸出，以及它們?nèi)绾卧谝黄饏f(xié)調(diào)工作。A數(shù)據(jù)流圖 DFDB實體聯(lián)系圖 ERDC狀態(tài)轉(zhuǎn)換圖D上下文圖41、構(gòu)造化、信息工程和面向?qū)ο笕N方法學(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全過程的。需求階段

10、的分析。需求階段的分析。44、需求分析活動的一個重要任務(wù)是進展，明確用戶需求的隱含信息，展開為明確的對軟件系統(tǒng)的行為期望，即系統(tǒng)需求。A需求整理B需求細化 C需求獲取D需求分析45、在分層構(gòu)造中，DFD定義了三個層次類別的 DFD圖：A1層圖 B底層圖 C上下文圖 D頂視圖46、因為數(shù)據(jù)存儲是系統(tǒng)部的功能實現(xiàn)，所以在將系統(tǒng)視為黑盒的情況下，上下文、0層圖和 N層圖。圖中不會出現(xiàn)。4. z-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、。概念實體是一種抽象概念，不考慮概念

11、背后的物理存在，所以通常不包含與之相關(guān)聯(lián)的其他。A模型B特征即屬性C關(guān)系 D處理49、在 ERD建模中，實體通常所指的就是A邏輯實體 B概念實體 C物理實體50、ERD中屬性是實體的特征，不是數(shù)據(jù)。屬性會以一定的形式存在，這種存在才是。D進程實體數(shù)據(jù)，被稱為屬性的。A域B實例C說明D值51、ERD中關(guān)系的度數(shù)Degree是指參與關(guān)系的實體數(shù)量，是度量關(guān)系的一個指標(biāo)。A模型52、ERD中關(guān)系的基數(shù)分為最大基數(shù)和最小基數(shù)。最大基數(shù)又被稱為A鍵約束 B參與約束C自然約束 D一般約束53、在實體之間建立關(guān)系時，可能會產(chǎn)生一些附帶的實體，被稱為關(guān)聯(lián)實體，最常見B復(fù)雜度C準(zhǔn)確度D屬性值。的形式是。A邏輯實

12、體B進程實體 C概念實體D自然實體54、在實現(xiàn) ERD與過程模型同步的技術(shù)中，是一種較為常見的技術(shù)。A用例圖55、以下A屬性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前景文

13、檔D用戶文檔59、系統(tǒng)需求規(guī)格說明文檔、軟件需求規(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. z-有效的功能配置。4、應(yīng)用型軟件分析階段的主要目的是發(fā)現(xiàn)人們利用軟件的原因目的，找出

14、需要軟件解決的問題，理解應(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個特性，即完整性、正確性、準(zhǔn)確性、可行性、必要性、無歧義和可驗證。9、所有對軟件系統(tǒng)的開發(fā)和應(yīng)用具有發(fā)言權(quán)和決定權(quán)的人統(tǒng)稱為涉眾。10、按照媒介載體進展分類，原型可分為：樣板原型和紙上向?qū)г汀?1、演示原

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

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

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

18、所6. z-建立的模型是進展信息整理和歸類的很好的框架依據(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)實現(xiàn)。36、目標(biāo)實現(xiàn)階段的主要任務(wù)是收集與目標(biāo)相關(guān)的需求信息，討論可能的候選解決方案，確定最終的系統(tǒng)詳細需求和解決方案。37、場景具有重點描述真實世界的特征，它利用情景、行為者之間的交互、事件隨時間的演化等方式來表達性地描述系統(tǒng)的使用。38、靜態(tài)外觀的場景被展現(xiàn)為一個或

19、者數(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、用例是場景方法中的一種，是靜態(tài)的構(gòu)造化文本

20、描述。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、需求分析的根本任務(wù)是：建立分析模型并創(chuàng)立解決方案。52

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

22、決問題的策略不同。58、前期需求階段分析的重點是理解問題世界，因此它關(guān)注的是整個問題世界，注重7. z-于系統(tǒng)的環(huán)境、開發(fā)組織的業(yè)務(wù)背景、涉眾的特征以及目標(biāo)等等，軟件系統(tǒng)只是整個背景下的一個要素。59、后期需求階段分析關(guān)注的是解系統(tǒng)解決方案的建立，因此它以軟件系統(tǒng)為中心，注重于分析系統(tǒng)的部功能以及它與環(huán)境的互動，是對系統(tǒng)功能的詳細信息的分析。60、以軟件復(fù)用為核心，建立產(chǎn)品族的方法被稱為產(chǎn)品線。61、需求協(xié)商活動既包括對目標(biāo)沖突的處理，也包括對需求細節(jié)沖突的處理。62、微規(guī)格說明被用來描述DFD過程分解構(gòu)造中最底層過程的處理邏輯。63、DFD中所有的外部實體聯(lián)合起來構(gòu)成了軟件系統(tǒng)的外部上下文環(huán)

23、境，它們與軟件系統(tǒng)的交互流就是軟件系統(tǒng)與其外部環(huán)境的接口，這些接口聯(lián)合起來定義了軟件系統(tǒng)的系統(tǒng)邊界。64、數(shù)據(jù)流是指數(shù)據(jù)的運動，它是系統(tǒng)與其環(huán)境之間或者系統(tǒng)兩個過程之間的通信形式。65、DFD的 0層圖中的每個過程都可以進展分解，被分解的過程稱為父過程，分解后產(chǎn)生的提醒更多細節(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)共享的

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

25、RD中屬性取值的受限制圍稱為域Domain。76、ERD為實體指定一個屬性或多個屬性的組合，可以用來唯一地確定和標(biāo)識每個實例，這些屬性或?qū)傩缘慕M合稱為實體的標(biāo)識符，又稱為鍵。77、一個實體可能有多個鍵，這些鍵都被稱為候選鍵。78、通常人們從多個候選鍵中選擇和使用固定的*一個鍵來進展實例的標(biāo)識，這個被選中的候選鍵被稱為主鍵，沒有被選做主鍵的候選鍵被稱為替代鍵。79、實體實例大多數(shù)屬性的值都是需要從現(xiàn)實中獲取的，稱為存儲屬性。80、有些實體實例的屬性的值是可以由其他屬性的值計算得出的，稱為導(dǎo)出屬性。81、關(guān)系是存在于一個或多個實體之間的自然業(yè)務(wù)聯(lián)系。82、只有一個實體參與的關(guān)系存在于實體的不同實例

26、之間，稱為一元關(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. z-體可能參與關(guān)系的最小數(shù)量。86、ERD中被關(guān)系影響的實體主要是弱實體和關(guān)聯(lián)實體。87、用例模型的根本元素有四種：用例、參與者、關(guān)系和系統(tǒng)邊界。88、UML行為模型是用例模型的實現(xiàn)，以更加詳細的方式說明用例所描述的系統(tǒng)行為。89、UML行為模型的活動圖是依據(jù)處理流程進展的用例實現(xiàn)。90、UML行為模

27、型的交互圖通常描述的是單個用例的典型場景。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、需求基線的維護主要包括配置管理和狀態(tài)維護。97、需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在向前和

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

29、和較高的抽象性，經(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、垂直原型方法會觸及選定功能

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

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

32、文本。強限制文本、表格、圖表、圖像等。26、在實踐中，以動態(tài)的場景外觀為主。×27、場景包含的知識只能是關(guān)于未來的。×28、描述性場景的目的是為了記錄已經(jīng)得到的需求，即整理每次需求獲取行為中得到的信息。29、UML就是以用例來捕獲系統(tǒng)所有的系統(tǒng)需求的。×30、用例的容只能包含有正常流程，而不能包含有異常流程。×31、用例可以用于各種目的的應(yīng)用，包括描述、探索和解釋。32、用例是在對現(xiàn)實世界的探索中或者是在對需求規(guī)格說明的解釋中產(chǎn)生的，是通過功能分解的方式創(chuàng)立的。×33、抽象用例是不能被實例化的，它必須被包含在其他用例中才能得以執(zhí)行。34、用例間

33、的泛化關(guān)系是指子用例繼承了父用例的特征。×并增加了新的特征35、抽象一方面要求人們關(guān)注重要的信息，同時又不能忽略次要的容。另一方面也要求人們將認知保存在適當(dāng)?shù)膶哟?，屏蔽更深層次的細?jié)。×36、由于計算模型的形式化特征不適合于需求工程階段，因此計算模型不適合用于需求分析中的建模。37、具有形式化特征的計算模型是用戶和開發(fā)者共同理解的模型。×38、由于模型需要描述的容太過復(fù)雜的，因此分析模型對模型語言語用的要求不可能太高。×39、軟件需求分析的關(guān)鍵是為真實世界的問題建立模型，即問題域建模。40、在“構(gòu)造化方法一信息工程方法一面向?qū)ο蠓椒ǖ拈_展歷程中，每一種后

34、來的方法在吸收了前面方法的重要思想的同時也替代前面的方法。×41、構(gòu)造化、信息工程和面向?qū)ο笕N方法學(xué)下的需求分析技術(shù)都適合于需求階段全過程的分析任務(wù)。×后期42、上下文圖是 DFD的一個特定層次，被用來說明系統(tǒng)的上下文環(huán)境，確定系統(tǒng)的邊界。43、外部實體是指處于待構(gòu)建系統(tǒng)之外的人、組織、設(shè)備或者其他軟件系統(tǒng)，但它們要受系統(tǒng)的控制，開發(fā)者可以以任何方式操縱它們。×44、上下文圖以黑盒對待和描述系統(tǒng)的方式使它非常適合描述系統(tǒng)的應(yīng)用環(huán)境、定義系10. z-統(tǒng)的邊界，這正是 DFD在層次構(gòu)造中將其置于最高層的原因。45、數(shù)據(jù)模型說明了問題域和解系統(tǒng)共享的事物、對共享事物

35、的描述和共享事物之間的關(guān)系。46、ERD關(guān)系表達的不是邏輯上的例如整體局部關(guān)系，而是實體物理上的聯(lián)系。×47、ERD中存在于兩個實體之間的關(guān)系是最常見的關(guān)系，稱為二元關(guān)系。48、ERD中子類型關(guān)系是實體間自然的業(yè)務(wù)聯(lián)系，而不是人為施加的構(gòu)造關(guān)系，是一種特殊的實體間關(guān)系。×49、建立功能實體矩陣的過程可以幫助驗證過程模型和數(shù)據(jù)模塊的正確性，發(fā)現(xiàn)其中的錯誤、遺漏、冗余和不一致。50、發(fā)起或觸發(fā)用例的外部用戶以及其他軟件系統(tǒng)等角色被稱為參與者。51、交互圖是對單個用例的典型場景的實現(xiàn)，適合于事務(wù)性業(yè)務(wù)工作的表示。52、UML行為模型的狀態(tài)圖是以狀態(tài)機模型的方式進展的用例實現(xiàn)。狀態(tài)

36、圖只能用來實現(xiàn)單個用例。×53、OCL無法被用來描述程序的控制邏輯和工作流程。54、OCL的表達式定義可以在程序中得到直接的執(zhí)行。×55、軟件需求規(guī)格說明文檔是對局部系統(tǒng)功能分配給軟件局部的詳細描述。×56、硬件需求規(guī)格說明文檔是對整個系統(tǒng)功能當(dāng)中分配給硬件局部的詳細描述。57、人機交互文檔是對整個系統(tǒng)功能中需要進展人機交互局部的詳細描述。58、驗證活動同樣普遍存在于需求分析過程中。×59、需求驗證并不是一個可以一次完畢的活動，它可能需要屢次、反復(fù)地執(zhí)行驗證。60、前向跟蹤是指需求在被獲取到軟件需求規(guī)格說明文檔之前的演化過程。×定義四、名詞解釋

37、題1、需求工程：需求工程是軟件工程的一個分支，它關(guān)注于軟件系統(tǒng)所應(yīng)予實現(xiàn)的現(xiàn)實世界目標(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、需求：IEEE對需求的定義為：用戶為了解決問題或到達*些目標(biāo)所需要的條件或能力。系統(tǒng)或系統(tǒng)部件為了滿足合同、標(biāo)準(zhǔn)、規(guī)或其他正式文檔所規(guī)定的要求而需要具備的條件或能力。對或中的一個條件或一種能力的一種文檔化表述。3、需求分析：需求分析是利用建模與分析技術(shù)對獲取筆錄的容進展明確、整理、匯總，建立一個綜合考慮問題域特性和需求的系統(tǒng)模型，然后根據(jù)系統(tǒng)模型

38、將用戶需求轉(zhuǎn)化為系統(tǒng)需求的需求工程活動。4、前景Vision：前景描述了產(chǎn)品的作用以及最終的功能，它將所有涉眾都統(tǒng)一到一個方向上。5、圍scope：圍指出當(dāng)前工程是要解決產(chǎn)品長遠規(guī)劃中的哪一局部，圍聲明它為工程劃定了需求的界限。11. z-6、用戶參與User Involvement：是以用戶為中心的設(shè)計方法的核心思想，它要求開發(fā)者建立和用戶的直接聯(lián)系，盡早地關(guān)注于用戶和用戶的任務(wù)執(zhí)行過程，通過及時獲得用戶的反響來調(diào)整軟件設(shè)計，以完成高質(zhì)量的設(shè)計。另一方面，用戶參與就是反對通過和市場人員、管理者等中間媒介來了解用戶，因為這些間接的聯(lián)系會減少或歪曲用戶的信息。7、硬數(shù)據(jù)：表格和文檔資料是用戶對實

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

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

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

42、es的社會機制。它要求人類學(xué)家花費長期的時間通常是數(shù)年在被研究的社會中生活并且仔細觀察該社會中的實際活動，得到第一手的觀察數(shù)據(jù)。對這些觀察數(shù)據(jù)的分析可以提醒被研究社會的社會構(gòu)造、組織方法和具體活動。12. z-17、模型驅(qū)動法：模型驅(qū)動法是一類以定義明確的模型為理論根底，依據(jù)模型指導(dǎo)和組織活動開展的需求工程方法。18、用例驅(qū)動法：用例是一種場景的文本化表現(xiàn)方式，使用表達性的文本來描述場景。以用例為核心，圍繞用例開展活動的軟件開發(fā)方法被稱為用例驅(qū)動的軟件開發(fā)方法。19、企業(yè)建模：企業(yè)建模是以使用產(chǎn)品的組織團體為系統(tǒng)的環(huán)境，進展分析。它主要用來理解組織的構(gòu)造、行為規(guī)則、目標(biāo)、重要成員的任務(wù)與職責(zé)、

43、操縱的數(shù)據(jù)等。企業(yè)建模利用企業(yè)的目標(biāo)、任務(wù)、策略、資源等來刻畫組織的行為，并依此來發(fā)現(xiàn)組織開發(fā)系統(tǒng)的目的，建立系統(tǒng)的業(yè)務(wù)需求。20、過程建模：過程建模是構(gòu)造化分析方法的典型技術(shù)。過程建模將系統(tǒng)看做是過程的集合，其中一些由人來執(zhí)行，另一些由軟件系統(tǒng)來執(zhí)行。過程建模使用的主要技術(shù)有上下文圖、數(shù)據(jù)流圖、微規(guī)格說明和數(shù)據(jù)字典等。21、上下文圖：上下文圖是 DFD最高層次的圖，是系統(tǒng)功能的最高抽象，它將整個系統(tǒng)看做是一個過程，這個過程實現(xiàn)系統(tǒng)的所有功能。上下文圖中存在且僅存在一個過程，表示整個系統(tǒng)。這個單一的過程通常編號為 0。22、概念數(shù)據(jù)模型：概念數(shù)據(jù)模型是以問題域的語言解釋數(shù)據(jù)模型，反映了用戶對共

44、享事物的描述和看法，由一系列應(yīng)用領(lǐng)域的概念組成。23、物理數(shù)據(jù)模型：物理數(shù)據(jù)模型是對數(shù)據(jù)模型的解系統(tǒng)語言的解釋，它描述的是共享事物在解系統(tǒng)中的實現(xiàn)形式，是形式化的定義。24、邏輯數(shù)據(jù)模型：邏輯數(shù)據(jù)模型是為了緩解開發(fā)人員將概念數(shù)據(jù)模型轉(zhuǎn)換成物理數(shù)據(jù)模型的困難，而使用一種介于問題域和解系統(tǒng)之間的中立語言來進展的數(shù)據(jù)模型的描述。這種中立的語言使用更加傾向于用戶的概念和詞匯，同時使用更加傾向于解系統(tǒng)語言的表達方式。25、關(guān)系的基數(shù)：關(guān)系的基數(shù)是衡量關(guān)系復(fù)雜性的指標(biāo)之一，又被稱為關(guān)系的約束。一個實體在關(guān)系中的基數(shù)定義了在關(guān)系中其他實體實例確定的情況下，該實體實例可能參與關(guān)系的數(shù)量。26、交互圖UML行為

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

46、只有通過正式的變更控制過程才能修改它。29、需求基線：需求基線Requirements Baseline就是被明確和固定的需求集合，是工程團隊需要在*一特定產(chǎn)品版本中實現(xiàn)的特征和需求集合。30、需求跟蹤：需求跟蹤是一種有效的控制手段，能夠在涉眾的需求變化中協(xié)調(diào)系統(tǒng)的演化，保持各項開發(fā)工作對需求的一致性。需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在向前和向后兩個方向上，描述需求以及跟蹤需求變化的能力，分為前向跟蹤 PreTraceabmty和后向跟蹤PostTraceability兩種。五、問答題1、簡述需求工程的主要任務(wù)。答：需求工程有以下三個主要任務(wù)：需求工程必須說明軟件系統(tǒng)將被應(yīng)用的環(huán)境及其

47、目標(biāo)，說明用來達成這些目標(biāo)的軟件功能，還要說明在設(shè)計和實現(xiàn)這些功能時上下文環(huán)境對軟件完成任務(wù)所用方式、方法所施加的限制和約束，也即要同時說明軟件需要“做什么和“為什么需要做。需求工程必須將目標(biāo)、功能和約束反映到軟件系統(tǒng)中，映射為可行的軟件行為，并對軟件行為進展準(zhǔn)確的規(guī)格說明。需求規(guī)格說明是需求工程最為重要的成果，是工程規(guī)劃、設(shè)計、測試、用戶手冊編寫等很多后繼軟件開發(fā)階段的工作根底?，F(xiàn)實世界是不斷變化的世界，因此需求工程還需要妥善處理目標(biāo)、功能和約束隨著時間的演化情況。同時，為了節(jié)省開支和進展需求規(guī)格說明的重用，需求工程還需要對目標(biāo)、功能和約束在軟件產(chǎn)品族中的演化和分布情況進展綜合考慮與處理。2

48、、簡述常見的需求定義錯誤。答：劃線局部為必答要點在實踐和研究過程中，人們發(fā)現(xiàn)關(guān)于需求定義的具體的錯誤主要有以下幾種：需求并沒有反映用戶的真實需要。實踐說明，獲取用戶的真實需非常困難的。原因之一是用戶在表達自己的需要時，可能會在潛意識下進展一定的加工。為了發(fā)現(xiàn)用戶的真實需求，需求工程師一定要進展問題分析，盡力發(fā)現(xiàn)問題背后的問題。原因之二是在人際交流中，信息會發(fā)生自然的衰減，甚至扭曲，導(dǎo)致需求丁程師理解的并非是用戶所表達的。解決方法是在需求傳遞給開發(fā)人員之前，請?zhí)岢鲂枨蟮挠脩暨M展仔細地檢查和確認。模糊和歧義的需求。在實踐中，人們總是會有意和無意地寫出模糊和歧義的需求定義。無意中寫出模糊和歧義的需求

49、定義往往是因為選詞造句不當(dāng)，導(dǎo)致不同的人對同一項需求產(chǎn)生了不同的理解。解決方法是為工程中重要的詞匯建立一個公共的可共同理解的詞匯表，然后在詞匯表的根底之上進展需求的定義。有意產(chǎn)生的模糊和歧義的需求定義往往是為了應(yīng)付對需求持有不同立場的用戶，這些用戶關(guān)于需求的目標(biāo)互相沖突，需求工程師于是采用了模糊化的處理方法。正確解決方法是在工程前景的指導(dǎo)下，促進用戶之間的協(xié)商解決。信息遺漏。14. z-信息遺漏也是一類常見的問題，包括明顯的信息遺漏和不明顯的信息遺漏。明顯的信息遺漏，其主要原因在于工程的圍定義不當(dāng)，可以通過加強對業(yè)務(wù)需求的處理得以解決。不明顯的信息遺漏，是因為相關(guān)信息難以發(fā)現(xiàn)，只能靠需求工程師的經(jīng)歷來加以防止。不必要的需求。產(chǎn)生不必要需求的原因主要是：其一是用戶將一些不必要的需求作為和開發(fā)人員談判的籌碼，然后通過自己對不必要需求的要求而在和開發(fā)人員的談判當(dāng)中取得真正想要的利益，例如金錢。對此問題，唯一需要的就是開發(fā)人員代表的談判技巧。其二是用戶在交流中，總是害怕信息有所遺漏，并因此產(chǎn)生不利后果，因此用戶總是傾向于表達各種各樣的需要。要解決這個問題，就需要開發(fā)人員在進展用戶需求的獲取之前，先定義明確的業(yè)務(wù)需求