《軟件需求工程》習題集
一、單項選擇題
1、 軟件生產中產生需求問題的最大原因在於對應用軟件的（ ）理解不透徹或應用不堅決。
（A） 復雜性 （B）目的性 （C）模擬性 （D）正確性
2、 需求分析的目的是保證需求的（ ）。
（A） 目的性和一致性 （B）完整性和一致性
（C）正確性和目的性 （D）完整性和目的性
3、 系統需求開發的結果最終會寫入（ ）。
（A） 可行性研究報告 （B）前景和范圍文檔
（C）用戶需求說明 （D）系統需求規格說明
4、 現實世界中的（ ）構成了問題解決的基本范圍，稱為該問題的問題域。
（A） 屬性和狀態 （B）實體和狀態 （C）實體和操作 （D）狀態和操作
5、 功能需求通常分為三個層次，即業務需求、用戶需求和（ ）。
（A） 硬件需求 （B）軟件需求 （C）質量屬性 （D）系統需求
6、 如果在最終的物件（Final Artifact）產生之前，一個中間物件（Mediate Artifact）被用來在一定廣度和深度范圍內表現這個終物件，那么這個中間物件就被認為是最終物件在該廣度和深度上的（ ）。
（A） 模擬 （B）構造 （C）原型 （D）模型
7、 按照開發方法進行分類，原型可分為：演化式原型和（ ）原型。
（A） 演示原型 （B）紙面原型
（C）拋棄式原型 （D）樣板原型
8、 按照涉及的功能進行分類，原型可分為：水平型原型和（ ）原型。
（A） 屏幕流原型 （B）情景串聯原型
（C）垂直型原型 （D）深度模擬原型
9、 原型的需求內容可以從三個緯度上分析：即（ ）。
（A） 外觀、角色和實現 （B）開發、實現和作用
（C）成本、技術和實現 （D）需求、作用和角色
10、當用戶無法完成主動的信息告知，或與需求工程師之間的語言交流無法產生有效的結果時，有必要采用（ ）。
（A） 民族志 （B）觀察法 （C）話語分析 （D）任務分析
11、下列（ ）不是需求獲取常見的模型驅動方法？
（A） 面向目標的方法 （B）基於場景的方法。
（C）基於用例的方法 （D）基於采樣的方法
12、功能目標可以分為 ( )。
（A） 安全目標和可用性目標 （B）滿足型目標和信息型目標
（C）軟目標和硬目標 （D）維護目標和實現目標
13、面向目標方法的目標分析階段的主要任務是（ ）。
（A） 獲取目標 （B）確定解決方案
（C）建立目標模型 （D）發現問題和缺陷 14、描述場景所使用的表示法要符合正規性要求，一般可使用非形式化語言、半形式化語言和形式化語言。在實踐中，（ ）是主要的描述方式。
（A）形式化的程序語言 （B）非形式化的自然語言
（C）形式化的圖形工具 （D）非形式化的設計語言
15、下列（ ）不是場景方法在需求工程中的應用。
（A） 幫助進行詳細的需求分析
（B） 編寫系統需求規格說明
（C） 結合面向目標的方法，指導需求獲取活動的開展
（D） 組織需求獲取得到的信息
16、與其他的場景方法相比，用例最大的特點是采用了（ ）的描述方式。
（A） 靜態非結構化文本 （B）動態非結構化文本
（C）靜態結構化文本 （D）動態結構化文本
17、用例之間的關系主要有（ ）三種。
（A） 包含、擴展和簡化 （B）合取、析取和擴展
（C）包含、多態和繼承 （D）包含、擴展和泛化
18、分析的活動主要包括識別、定義和結構化，它的目的是獲取某個可以轉換為知識的事物的信息，這種分析活動被稱為（ ）。
（A） 需求信息獲取 （B）建立軟件系統解決方案
（C）需求信息轉化 （D）建立需求分析模型
19、（ ）是建模 為常用的兩種手段。
（A） 具體和抽象 （B）抽象和分解 （C）分解和細化 （D）抽象和細化
20、抽象通過強調本質的特征，（ ）了問題的復雜性。
（A） 調整 （B）避免 （C）增加 （D）減少
21、需求分析僅僅需要描述解決方案，不需要探索實現細節的情況下，分析模型又是（ ）
的，尤為適用。
（A） 形式化 （B）半形式化 （C）結構化 （D）非結構化
22、22、上下文圖描述系統與環境中外部實體之間的界限和聯系。它從現實世界的角度說明了系統的（ ），並確定了所有的輸入和輸出。
（A）環境與外觀 （B）邊界和聯系 （C）邊界和環境 （D）輸入和輸出
23、（ ）是結構化分析方法的核心技術，它表明系統的輸入、處理、存儲和輸出，以及它
們如何在一起協調工作。
（A） 數據流圖 DFD （B）實體聯系圖 ERD （C）狀態轉換圖 （D）上下文圖
24、需求分析活動的一個重要任務是進行（ ），明確用戶需求的隱含信息，展開為明確的
對軟件系統的行為期望，即系統需求。
（A） 需求整理 （B）需求細化 （C）需求獲取 （D）需求分析
25、下列（ ）不是用例模型中的關系？
（A） 屬性 （B）關聯 （C）泛化 （D）包含
26、系統邊界是指一個系統所包含的系統成分與系統外事物的分界線。用例模型使用一個
（ ）來表示系統邊界，以顯示系統的上下文環境。
（A） 圓形框 （B）菱形框 （C）虛線框 （D）矩形框
27、UML 使用的行為模型有三種，即：（ ）。
（A） 交互圖、狀態圖和順序圖 （B）順序圖、通信圖和時間圖
（C）交互圖、狀態圖和活動圖 （D）交互概述圖、通信圖和時間圖
28、項目的前景和范圍文檔、用戶需求文檔都被視為屬於（ ），重點都是用戶的現實世界。
（A） 開發文檔 （B）需求文檔 （C）前景文檔 （D）用戶文檔
29、系統需求規格說明文檔、軟件需求規格說明文檔、硬件需求規格說明文檔、接口需求規
格說明文檔和人機交互文檔一起被用於系統開發的目的，都被認為是（ ）。
（A） 開發文檔 （B）需求文檔 （C）過程文檔 （D）用戶文檔
30、下列（ ）不是需求規格說明文檔的讀者？
（A） 項目管理者 （B）編程人員 （C）銷售商 （D）律師
二、填空題
1、 傳統的需求分析方法都是從 轉入分析領域的。
2、 應用型軟件分析階段的主要目的是發現人們利用軟件的原因（目的），找出需要軟件解決的問題，理解應用環境中的領域知識，保證功能的 。
3、 需求工程是所有需求處理活動的總和，它包括 和需求管理兩個部分。
4、 軟件需求開發用來確定系統需求中應該由軟件滿足的部分，將其映射為軟件行為，產生 。
5、 優秀的需求應該具備 7 個特性，即完整性、正確性、精確性、可行性、必要性、無歧義和 。
6、 所有對軟件系統的開發和應用具有發言權和決定權的人統稱為 。
7、 按照媒介載體進行分類，原型可分為： 和紙上向導原型。
8、 演示原型主要被用在 階段。
9、 演示原型都是被用來展示用戶想象中的 ，所以它要能夠表現用戶界面的重要特征。
10、如果一個問題的技術解決方案是不清晰的， 也可以被用來展現相應的細節功能以使用戶確信該問題解決的可能性。
11、通常來說，如果用戶需求出現了模糊、不清晰、不完整等具有一定不確定性的特征，就可以考慮使用 方法。
12、 是指原型物件在用戶工作中的價值，也就是說它為什么對用戶是有用的。
13、 是指用戶對原型物件的具體感覺體驗，即用戶在使用原型物件時會看到什么、聽到什么和感覺到什么。
14、實現是指原型物件完成功能的 和方法。
15、使用演化式原型方法，在開發時就需要注意原型的 和代碼的質量。
16、使用實驗式開發方法，需要實現多種技術方案，考察重要的系統的 。
17、選擇使用探索式開發方法，需要盡可能地考慮各種不同的設計選項，比較不同選項下的 。
18、原型方法的最大優點是能夠及早地解決系統開發中的 ，從而降低軟件項目失敗的風險。
19、復雜的工作總會同時存在着正常流程和異常流程，異常流程大多是一些特殊情況下的處理，限定了異常處理的上下文環境，即異常處理具有 的情景性。
20、文檔審查主要獲取對象包括相關產品的 、 和客戶的需求文檔。
21、面向目標方法的處理過程可以分為三個階段：目標獲取、 和目標實現。
22、目標實現階段的主要任務是收集與目標相關的需求信息，討論可能的候選解決方案，確定 終的系統 和解決方案。
23、場景具有重點描述真實世界的特征，它利用情景、 、事件隨時間的演化等方式來敘述性地描述系統的使用。
24、具體場景，又稱為 ，是對個別行為者、事件、情節的細節描述。
25、抽象場景，又稱為 ，是以經驗中的類別和抽象概念來描述事實。
26、探索性場景可以用來進行需求獲取和 。
27、每個 是對相關場景集合的敘述性的文本描述，這些場景是用戶和系統之間的交互行為序列，幫助實現用戶的目的。
28、用例是場景方法中的一種，是 的結構化文本描述。
29、在高層的功能需求獲取完備之前，用例的產生方式中不允許使用 方式。
30、單個用例描述了系統的功能片段，系統的所有用例基於一定的關系組織起來，建立 ，就可以描述整個系統的功能。
31、原有用例和新建立的 的關系即為包含關系。 32、在需求工程中，主要產生三類重要的文檔：項目前景和范圍文檔、用戶需求文檔以及需求規格說明。 通常被用來代替用戶需求文檔，起到記錄、交流領域信息和用戶期望的作用。
33、需求獲取得到的信息和需求開發應該建立的軟件系統解決方案之間有着很大的差距。 就是用來解決這個差距的需求工程活動。
34、需求分析的根本任務是： 並創建解決方案。
35、分解將單個復雜和難以理解的問題分解成多個相對更容易的子問題，並掌握各子問題之間的 。
38、需求分析方法主要有：結構化方法、信息工程方法和面向對象方法。其中 是目前工業界使用的主流方法。
40、后期需求階段分析關注的是解系統解決方案的建立，因此它以軟件系統為中心，注重於分析系統的內部功能以及它與環境的互動，是對 的詳細信息的分析。
41、需求協商活動既包括對目標沖突的處理，也包括對 沖突的處理。
57、用例模型的基本元素有四種：用例、參與者、關系和 。
58、UML 行為模型是用例模型的 ，以更加詳細的方式說明用例所描述的系統行為。
59、UML 行為模型的活動圖是依據 進行的用例實現。
60、UML 行為模型的交互圖通常描述的是單個用例的 。
61、接口需求規格說明文檔是對整個系統中需要軟、硬件 部分的詳細描述。
62、優秀的需求規格說明文檔應該具備：正確性、無歧義、完備性、一致性、根據重要性和穩定性分級、 、可修改、可跟蹤等特性。
63、需求驗證常見方法有：需求評審、 、測試用例開發、用戶手冊編制、利用跟蹤關系和自動化分析。
64、評審又被稱為 ，是指由作者之外的其他人來檢查產品問題的方法。
65、需求基線的維護主要包括配置管理和 。
66、需求跟蹤是以 為基線，在向前和向后兩個方向上，描述需求以及跟蹤需求變化的能力。
67、從需求向后回溯（前向跟蹤的兩種聯系之一）說明軟件需求來源於哪些涉眾的需要和 。
68、后向跟蹤是指 到軟件需求規格說明文檔之后的演化過程。
69、后向跟蹤包括兩種聯系：從需求向前跟蹤和 。
三、判斷題
1、 需求工程包括需求獲取和需求開發兩個方面。（ ）
2、 需求驗證是需求工程中最后一個活動。（）
3、 軟件系統能夠與問題域進行交互和相互影響的原因在於，軟件系統中的某些部分對問題域中的某些部分具有模擬特性。（）
4、 規格說明是問題域為滿足用戶需求而提供的解決方案，規定了解系統的行為特征。
（）
5、 業務需求具有明顯的目的性和較高的抽象性，經過明確和細化的處理，可以直接轉化為系統需求。（）
6、 需求開發的一些特性決定了需求開發過程只能是一個簡單的線性增量過程。（）
7、 對於需求不確定性比較小的項目，用戶參與可以取得比較好的效果，但對於需求不確定性比較大的項目，用戶參與反而可能帶來阻礙作用。（）
8、 按照構建技術進行分類，原型可分為：水平原型和垂直原型。（）
9、 嚴格意義上的原型主要被用在需求分析階段。（）
10、要完成相同的功能，構建拋棄式原型比構建演化式原型所花費的代價要大得多。（）
11、水平原型方法僅僅實現選定功能實現的所有層次，能夠處理較大范圍的功能。（）
12、垂直原型方法會觸及選定功能所有層次中的某些特定層次，處理的功能范圍通常較小。
（）
13、建立外觀原型時重在原型的用戶界面和交互方式，原型的功能和技術實現細節就會被簡化處理。（）
14、 14、如果選擇的開發方法是實驗式或者探索式開發方法，應該盡量花費最小的代價，爭取最快的速度，忽略或簡化不重要的功能處理。（）
15、原型修正主要依據評估人員的反饋，可以忽略事先的原型調整計划。（）
16、文檔審查是一種傳統的需求獲取方法，是專門針對文檔進行的需求獲取活動。（）
17、由於文檔是來自於當前計算機或手工系統的產物，因此它是正確的，也正是客戶所需要的。（）
18、成功的需求獲取任務不僅要求成功地執行每一次具體的需求獲取行為，還要求成功地處理多次獲取行為之間的關系。（）
19、對系統的現狀和背景進行分析往往能夠發現重要的目標，得到一些明確的問題和缺陷，它們的反面就是系統需要實現的目標。（）
20、場景被人們廣泛接受的原因是因為人們更傾向於會對真實事件和真實事物的描述產生反應。（）
21、描述場景時所使用的常見媒介形式主要有：敘述性的自由文本、結構化文本。強限制文本、表格、圖表、圖像等。（）
22、描述性場景的目的是為了記錄已經得到的需求，即整理每次需求獲取行為中得到的信息。（）
23、UML 就是以用例來捕獲系統所有的系統需求的。（）
24、用例的內容只能包含有正常流程，而不能包含有異常流程。（）
25、用例可以用於各種目的的應用，包括描述、探索和解釋。（）
26、用例是在對現實世界的探索中或者是在對需求規格說明的解釋中產生的，是通過功能分解的方式創建的。（）
27、抽象用例是不能被實例化的，它必須被包含在其他用例中才能得以執行。（）
28、用例間的泛化關系是指子用例繼承了父用例的特征。（）並增加了新的特征
29、抽象一方面要求人們關注重要的信息，同時又不能忽略次要的內容。另一方面也要求人們將認知保留在適當的層次，屏蔽更深層次的細節。（）
30、由於計算模型的形式化特征不適合於需求工程階段，因此計算模型不適合用於需求分析中的建模。（）
31、具有形式化特征的計算模型是用戶和開發者共同理解的模型。（）
32、由於模型需要描述的內容太過復雜的，因此分析模型對模型語言語用的要求不可能太高。（）
33、軟件需求分析的關鍵是為真實世界的問題建立模型，即問題域建模。（）
34、在“結構化方法－信息工程方法－面向對象方法”的發展歷程中，每一種后來的方法在吸收了前面方法的重要思想的同時也替代前面的方法。（）
35、上下文圖是 DFD 的一個特定層次，被用來說明系統的上下文環境，確定系統的邊界。
（）
36、發起或觸發用例的外部用戶以及其他軟件系統等角色被稱為參與者。（）
37、交互圖是對單個用例的典型場景的實現，適合於事務性業務工作的表示。（）
38、UML 行為模型的狀態圖是以狀態機模型的方式進行的用例實現。狀態圖只能用來實現單個用例。 （）
39、軟件需求規格說明文檔是對部分系統功能分配給軟件部分的詳細描述。（）
40、人機交互文檔是對整個系統功能中需要進行人機交互部分的詳細描述。（）
41、驗證活動同樣普遍存在於需求分析過程中。（）
42、需求驗證並不是一個可以一次結束的活動，它可能需要多次、反復地執行驗證。（）
前向跟蹤是指需求在被獲取到軟件需求規格說明文檔之前的演化過程。（）