一、單項選擇題
1、 軟件生產中產生需求問題的最大原因在於對應用軟件的（ C ）理解不透徹或應用不堅決。
（A） 復雜性 （B）目的性 （C）模擬性 （D）正確性
2、 需求分析的目的是保證需求的（ B ）。
（A） 目的性和一致性 （B）完整性和一致性
（C）正確性和目的性 （D）完整性和目的性
3、 系統需求開發的結果最終會寫入（ D ）。
（A） 可行性研究報告 （B）前景和范圍文檔
（C）用戶需求說明 （D）系統需求規格說明
4、 現實世界中的（ B ）構成了問題解決的基本范圍，稱為該問題的問題域。
（A） 屬性和狀態 （B）實體和狀態 （C）實體和操作 （D）狀態和操作
5、 功能需求通常分為三個層次，即業務需求、用戶需求和（ D ）。
（A） 硬件需求 （B）軟件需求 （C）質量屬性 （D）系統需求
6、 如果在最終的物件（Final Artifact）產生之前，一個中間物件（Mediate Artifact）被用來在一定廣度和深度范圍內表現這個終物件，那么這個中間物件就被認為是最終物件在該廣度和深度上的（ C ）。
（A） 模擬 （B）構造 （C）原型 （D）模型
7、 按照開發方法進行分類，原型可分為：演化式原型和（ C ）原型。
（A） 演示原型 （B）紙面原型
（C）拋棄式原型 （D）樣板原型
8、 按照涉及的功能進行分類，原型可分為：水平型原型和（ C ）原型。
（A） 屏幕流原型 （B）情景串聯原型
（C）垂直型原型 （D）深度模擬原型
9、 原型的需求內容可以從三個緯度上分析：即（ A ）。
（A） 外觀、角色和實現 （B）開發、實現和作用
（C）成本、技術和實現 （D）需求、作用和角色
10、當用戶無法完成主動的信息告知，或與需求工程師之間的語言交流無法產生有效的結果時，有必要采用（ B ）。 無法主動告知——需要被動得知——被觀察——觀察法
（A） 民族志 （B）觀察法 （C）話語分析 （D）任務分析
11、下列（ D ）不是需求獲取常見的模型驅動方法？
（A） 面向目標的方法 （B）基於場景的方法。
（C）基於用例的方法 （D）基於采樣的方法
12、功能目標可以分為 ( B )。
（A） 安全目標和可用性目標 （B）滿足型目標和信息型目標
（C）軟目標和硬目標 （D）維護目標和實現目標
13、面向目標方法的目標分析階段的主要任務是（ C ）。
（A） 獲取目標 （B）確定解決方案
（C）建立目標模型 （D）發現問題和缺陷 14、描述場景所使用的表示法要符合正規性要求，一般可使用非形式化語言、半形式化語言和形式化語言。在實踐中，（ B ）是主要的描述方式。 實踐中一般都靠說來完成，說話屬於非形式化的自然語言。
（A）形式化的程序語言 （B）非形式化的自然語言
（C）形式化的圖形工具 （D）非形式化的設計語言
15、下列（ B ）不是場景方法在需求工程中的應用。
（A） 幫助進行詳細的需求分析
（B） 編寫系統需求規格說明
（C） 結合面向目標的方法，指導需求獲取活動的開展
（D） 組織需求獲取得到的信息
16、與其他的場景方法相比，用例最大的特點是采用了（ C ）的描述方式。 用例無動作，但有固定結構。
（A） 靜態非結構化文本 （B）動態非結構化文本
（C）靜態結構化文本 （D）動態結構化文本
17、用例之間的關系主要有（ D ）三種。
（A） 包含、擴展和簡化 （B）合取、析取和擴展
（C）包含、多態和繼承 （D）包含、擴展和泛化
18、分析的活動主要包括識別、定義和結構化，它的目的是獲取某個可以轉換為知識的事物的信息，這種分析活動被稱為（ D ）。 所有的目的、目標、任務都是建模。
（A） 需求信息獲取 （B）建立軟件系統解決方案
（C）需求信息轉化 （D）建立需求分析模型
19、（ B）是建模 為常用的兩種手段。
（A） 具體和抽象 （B）抽象和分解 （C）分解和細化 （D）抽象和細化
20、抽象通過強調本質的特征，（ D ）了問題的復雜性。 問題無法避免，只能盡量減少。
（A） 調整 （B）避免 （C）增加 （D）減少
21、需求分析僅僅需要描述解決方案，不需要探索實現細節的情況下，分析模型又是（ B ）
的，尤為適用。
（A） 形式化 （B）半形式化 （C）結構化 （D）非結構化
22、22、上下文圖描述系統與環境中外部實體之間的界限和聯系。它從現實世界的角度說明了系統的（ C ），並確定了所有的輸入和輸出。
（A）環境與外觀 （B）邊界和聯系 （C）邊界和環境 （D）輸入和輸出
23、（ A ）是結構化分析方法的核心技術，它表明系統的輸入、處理、存儲和輸出，以及它
們如何在一起協調工作。
（A） 數據流圖 DFD （B）實體聯系圖 ERD （C）狀態轉換圖 （D）上下文圖
24、需求分析活動的一個重要任務是進行（ B ），明確用戶需求的隱含信息，展開為明確的
對軟件系統的行為期望，即系統需求。
（A） 需求整理 （B）需求細化 （C）需求獲取 （D）需求分析
25、下列（ A ）不是用例模型中的關系？
（A） 屬性 （B）關聯 （C）泛化 （D）包含
26、系統邊界是指一個系統所包含的系統成分與系統外事物的分界線。用例模型使用一個
（ D ）來表示系統邊界，以顯示系統的上下文環境。
（A） 圓形框 （B）菱形框 （C）虛線框 （D）矩形框
27、UML 使用的行為模型有三種，即：（ C ）。
（A） 交互圖、狀態圖和順序圖 （B）順序圖、通信圖和時間圖
（C）交互圖、狀態圖和活動圖 （D）交互概述圖、通信圖和時間圖
28、項目的前景和范圍文檔、用戶需求文檔都被視為屬於（ D ），重點都是用戶的現實世界。 用戶的世界就是用戶文檔，開發為目的就是開發文檔。
（A） 開發文檔 （B）需求文檔 （C）前景文檔 （D）用戶文檔
29、系統需求規格說明文檔、軟件需求規格說明文檔、硬件需求規格說明文檔、接口需求規
格說明文檔和人機交互文檔一起被用於系統開發的目的，都被認為是( A )。 用戶的世界就是用戶文檔，開發為目的就是開發文檔。
（A） 開發文檔 （B）需求文檔 （C）過程文檔 （D）用戶文檔
30、下列（ C ）不是需求規格說明文檔的讀者？
（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、分解將單個復雜和難以理解的問題分解成多個相對更容易的子問題，並掌握各子問題之間的聯系。
36、需求分析方法主要有：結構化方法、信息工程方法和面向對象方法。其中面向對象方法是目前工業界使用的主流方法。
37、后期需求階段分析關注的是解系統解決方案的建立，因此它以軟件系統為中心，注重於分析系統的內部功能以及它與環境的互動，是對系統功能的詳細信息的分析。
38、需求協商活動既包括對目標沖突的處理，也包括對需求細節沖突的處理。
57、用例模型的基本元素有四種：用例、參與者、關系和系統邊界。
58、UML 行為模型是用例模型的實現，以更加詳細的方式說明用例所描述的系統行為。
59、UML 行為模型的活動圖是依據處理流程進行的用例實現。
60、UML 行為模型的交互圖通常描述的是單個用例的典型場景。
61、接口需求規格說明文檔是對整個系統中需要軟、硬件協同實現部分的詳細描述。
62、優秀的需求規格說明文檔應該具備：正確性、無歧義、完備性、一致性、根據重要性和穩定性分級、可驗證、可修改、可跟蹤等特性。
63、需求驗證常見方法有：需求評審、原型與模擬、測試用例開發、用戶手冊編制、利用跟蹤關系和自動化分析。
64、評審又被稱為同級評審，是指由作者之外的其他人來檢查產品問題的方法。
65、需求基線的維護主要包括配置管理和狀態維護。
66、需求跟蹤是以軟件需求規格說明文檔為基線，在向前和向后兩個方向上，描述需求以及跟蹤需求變化的能力。
67、從需求向后回溯（前向跟蹤的兩種聯系之一）說明軟件需求來源於哪些涉眾的需要和目標。
68、后向跟蹤是指需求被定義到軟件需求規格說明文檔之后的演化過程。
后向跟蹤包括兩種聯系：從需求向前跟蹤和回溯到需求的跟蹤。
三、判斷題
1、 需求工程包括需求獲取和需求開發兩個方面。（×）
2、 需求驗證是需求工程中最后一個活動。（×）
3、 軟件系統能夠與問題域進行交互和相互影響的原因在於，軟件系統中的某些部分對問題域中的某些部分具有模擬特性。（√）
4、 規格說明是問題域為滿足用戶需求而提供的解決方案，規定了解系統的行為特征。
（×）
5、 業務需求具有明顯的目的性和較高的抽象性，經過明確和細化的處理，可以直接轉化為系統需求。（×）
6、 需求開發的一些特性決定了需求開發過程只能是一個簡單的線性增量過程。（×）
7、 對於需求不確定性比較小的項目，用戶參與可以取得比較好的效果，但對於需求不確定性比較大的項目，用戶參與反而可能帶來阻礙作用。（×）
8、 按照構建技術進行分類，原型可分為：水平原型和垂直原型。（√）
9、 嚴格意義上的原型主要被用在需求分析階段。（√）
10、要完成相同的功能，構建拋棄式原型比構建演化式原型所花費的代價要大得多。（×）
11、水平原型方法僅僅實現選定功能實現的所有層次，能夠處理較大范圍的功能。（×）
12、垂直原型方法會觸及選定功能所有層次中的某些特定層次，處理的功能范圍通常較小。
（×）
13、建立外觀原型時重在原型的用戶界面和交互方式，原型的功能和技術實現細節就會被簡化處理。（√） 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、需求驗證並不是一個可以一次結束的活動，它可能需要多次、反復地執行驗證。（√）
43、前向跟蹤是指需求在被獲取到軟件需求規格說明文檔之前的演化過程。（×）定義
四、名詞解釋題
1、 需求工程：需求工程是軟件工程的一個分支，它關注於軟件系統所應予實現的現實世界目標、軟件系統的功能和軟件系統應當遵守的約束，同時它也關注以上因素和准確的軟件行為規格說明之間的聯系，關注以上因素與其隨時間或跨產品族而演化之后的相關因素之間的聯系。
2、 需求：IEEE 對需求的定義為：
①用戶為了解決問題或達到某些目標所需要的條件或能力。
②系統或系統部件為了滿足合同、標准、規范或其他正式文檔所規定的要求而需要具備的條件或能力。
③對①或②中的一個條件或一種能力的一種文檔化表述。
3、 需求分析：需求分析是利用建模與分析技術對獲取筆錄的內容進行明確、整理、匯總，建立一個綜合考慮問題域特性和需求的系統模型，然后根據系統模型將用戶需求轉化為系統需求的需求工程活動。
4、 前景（Vision）：前景描述了產品的作用以及 終的功能，它將所有涉眾都統一到一個方向上。
5、 范圍（scope）：范圍指出當前項目是要解決產品長遠規划中的哪一部分，范圍聲明它為項目划定了需求的界線。
6、 用戶參與（User Involvement）：是以用戶為中心的設計方法的核心思想，它要求開發
者建立和用戶的直接聯系，盡早地關注於用戶和用戶的任務執行過程，通過及時獲得用戶的反饋來調整軟件設計，以完成高質量的設計。另一方面，用戶參與就是反對通過和市場人員、管理者等中間媒介來了解用戶，因為這些間接的聯系會減少或歪曲用戶的信息。
7、 結構化面談：結構化面談指在面談的過程中，會見者會完全按照事先的問題和結構來控制面談。結構化面談通常被用來獲取一些比較確定或者選擇空間比較有限的信息，一些統計性傾向信息的獲取也可以使用結構化面談。
8、 半結構化面談：半結構化面談指在面談的過程中，事先需要根據面談內容准備面談的問題和面談結構。但在面談過程中，會見者可以根據實際情況采取一些靈活的策略。半結構化面談是在需求獲取中應用 多的一種面談類型，能夠處理大部分的需求獲取任務。
9、 非結構化面談：在非結構化面談的過程中，沒有事先預定的議程安排。在比較極端的情況下，會見者甚至會在沒有太多事前准備的情況下就直接到訪被會見者的工作地，就某個主題開展會談。
10、頭腦風暴（Brainstorming）：是一種特殊的群體面談方式，它的目的不是發現需求，而是“發明”需求，或者說是發現“潛在”需求。它鼓勵參與者在無約束的環境下進行某些問題的自由思考和自由討論，以產生新的想法。它是需求獲取中用於“發明”需求的方法，但它會增加需求的數量。
11、原型：原型是一個系統，它內化了（Capture）一個更遲系統（Later System）的本質特征。原型系統通常被構造為不完整的系統，以在將來進行改進、補充或者替代。”
12、場景：場景是對系統和環境行為的局部描述，或者說場景是對行為或者事件序列的描
述，序列中的行為和事件是系統需要完成的一個任務的特殊示例。
（也可以說，場景是用戶為了達到某個目標而和軟件系統發生的行為交互序列，是開發者描述軟件功能和需求的一種重要形式。）
13、交互圖（UML 行為模型）：交互圖用於描述在特定上下文環境中一組對象的交互行為，該上下文環境就是被實現用例的某個場景。所以，交互圖通常描述的是單個用例的典型場景。交互圖中的每一個交互都描述了環境中的對象為了實現某個目標而執行的一系列消息交換。
14、需求基線：需求基線（Requirements Baseline）就是被明確和固定的需求集合，是項目團隊需要在某一特定產品版本中實現的特征和需求集合。
15、需求跟蹤：需求跟蹤是一種有效的控制手段，能夠在涉眾的需求變化中協調系統的演化，保持各項開發工作對需求的一致性。需求跟蹤是以軟件需求規格說明文檔為基線，
在向前和向后兩個方向上，描述需求以及跟蹤需求變化的能力，分為前向跟蹤（Pre-
Traceabmty）和后向跟蹤（Post-Traceability）兩種。
五、問答題
1、 簡述需求工程的主要任務。
答：
需求工程有以下三個主要任務：
①需求工程必須說明軟件系統將被應用的環境及其目標，說明用來達成這些目標的軟件功能，還要說明在設計和實現這些功能時上下文環境對軟件完成任務所用方式、方法所施加的限制和約束，也即要同時說明軟件需要“做什么”和“為什么”需要做。
②需求工程必須將目標、功能和約束反映到軟件系統中，映射為可行的軟件行為，並對軟件行為進行准確的規格說明。需求規格說明是需求工程 為重要的成果，是項目規划、設計、測試、用戶手冊編寫等很多后繼軟件開發階段的工作基礎。
③現實世界是不斷變化的世界，因此需求工程還需要妥善處理目標、功能和約束隨着時間的演化情況。同時，為了節省開支和進行需求規格說明的重用，需求工程還需要對目標、功能和約束在軟件產品族中的演化和分布情況進行綜合考慮與處理。
2、 簡述常見的需求定義錯誤。
答：（划線部分為必答要點）
在實踐和研究過程中，人們發現關於需求定義的具體的錯誤主要有以下幾種：
①需求並沒有反映用戶的真實需要。
實踐表明，獲取用戶的真實需求是非常困難的。
原因之一是用戶在表達自己的需要時，可能會在潛意識下進行一定的加工。為了發現用戶的真實需求，需求工程師一定要進行問題分析，盡力發現問題背后的問題。
原因之二是在人際交流中，信息會發生自然的衰減，甚至扭曲，導致需求丁程師理解的並非是用戶所表達的。解決方法是在需求傳遞給開發人員之前，請提出需求的用戶進行仔細地檢查和確認。
②模糊和歧義的需求。
在實踐中，人們總是會有意和無意地寫出模糊和歧義的需求定義。
無意中寫出模糊和歧義的需求定義往往是因為選詞造句不當，導致不同的人對同一項需求產生了不同的理解。解決方法是為項目中重要的詞匯建立一個公共的可共同理解的詞匯表，然后在詞匯表的基礎之上進行需求的定義。
有意產生的模糊和歧義的需求定義往往是為了應付對需求持有不同立場的用戶，這些用戶關於需求的目標互相沖突，需求工程師於是采用了模糊化的處理方法。正確解決方法是在項目前景的指導下，促進用戶之間的協商解決。
③信息遺漏。
信息遺漏也是一類常見的問題，包括明顯的信息遺漏和不明顯的信息遺漏。
明顯的信息遺漏，其主要原因在於項目的范圍定義不當，可以通過加強對業務需求的處理得以解決。
不明顯的信息遺漏，是因為相關信息難以發現，只能靠需求工程師的經驗來加以避免。
④不必要的需求。
產生不必要需求的原因主要是：
其一是用戶將一些不必要的需求作為和開發人員談判的籌碼，然后通過自己對不必要需求的要求而在和開發人員的談判當中取得真正想要的利益，例如金錢。對此問題，唯一需要的就是開發人員代表的談判技巧。
其二是用戶在交流中，總是害怕信息有所遺漏，並因此產生不利后果，因此用戶總是傾向於表達各種各樣的需要。要解決這個問題，就需要開發人員在進行用戶需求的獲取之前，先定義明確的業務需求，然后根據業務需求進行用戶需求的過濾和選擇。
其三是需求開發人員“畫蛇添足”，添加“用戶肯定會喜歡”的功能，該類功能既會造成項目額外的耗費，又不會給用戶帶來更多的幫助。這就要求需求開發人員要保持以用戶為中心。
⑤不切實際的期望。
不切實際的期望也是實踐中常見的需求定義問題，而且它在很大程度上影響着項目的成敗。
面對不切實際的期望，要求軟件開發者提供可行性、成本等足夠的技術參考信息，幫助用戶對其進行取舍和調整。
3、 簡要說明需求獲取活動的過程。
答：
（1） 收集和應用背景資料，建立初始的知識框架。分析涉眾的高層次問題，總結出系統的業務需求。
（2） 設計一個高層次的解決方案，並確定解決方案需要具備的系統特性。高層次的解決方案和系統特性定義了項目的前景和范圍。
（3） 在項目的業務范圍內，需求工程要尋找相關的涉眾，並分析和涉眾選擇。
（4） 對組織里存在大量的表格、單據等與業務相關的硬數據進行采樣，它們是需求獲取活動中一個重要的信息來源。
（5） 針對某一次具體的需求獲取活動，要依據項目范圍確定主題和內容，涉眾特征和硬數據，從而確定信息來源。獲取方法通常只有綜合內容、來源和系統環境三者才能做出正確的決定。
在內容、來源和方法都確定之后，需求工程師就可以開展具體的獲取活動，獲取用戶需求和問題域特性。
獲取得到的具體信息要記錄下來，以獲取筆錄的形式進行保存。
4、 簡述涉眾識別的基本過程。
答：
涉眾識別的基本過程如下：
①將初始涉眾集中起來，進行一次頭腦風暴，盡可能地列出一個涉眾類別列表。
②對上一步產生的涉眾類別列表進行分析，判斷它們和軟件系統的相關性，找出其中的鍵涉眾類別。
③為上一步的各個關鍵涉眾類別選擇代表，集中起來進行進一步的頭腦風暴，列出新的涉眾類別列表。如果新列出的涉眾類別列表趨於穩定，就可以結束涉眾識別過程。如果新列出的涉眾類別列表有了新的發現，就提交新的涉眾類別列表，轉向第②步。
6、 簡述軟件開發中為何使用原型工具以及使用的好處。
答：
因為原型是在 終系統產生之前的一個局部真實表現，所以原型方法可以讓人們在系統的開發過程中，就能夠對一些具體問題進行基於實物的有效溝通，從而幫助人們盡早解決軟件開發過程中存在的各種不確定性。不確定性是指人們已經擁有的知識是不充分的，不足以預測將來的事件發展，或者不足以清晰、准確地描述某個事物。
實踐證明，利用原型有如下好處：
①及時、有力地響應用戶需求的變化。
②減少返工。
③幫助控制不完整需求所帶來的風險。 ④可以將一個大的難以處理的開發過程細分成一些更小更容易處理的步驟。
⑤減少開發成本，提高經濟效益。
⑥增加開發者之間的交流，幫助確定技術解決方案的可行性。
⑦有效地識別風險和解決風險，幫助進行風險管理。
⑧提高用戶在軟件開發中的參與程度。
7、 試說明在哪些情景下原型法可以幫助需求工程師及早解決需求的不確定性。
答：
①產品以前從未存在過，而且難以可視化。這些產品屬於創新性產品，它們的基本需求是潛在的，有着很大的不確定性。
②產品的用戶對相關類別的產品沒有經驗，而且對將要采用的技術也沒有經驗。此時用戶無法明確工作的具體細節，產品的細節需求存在着不確定性。
③用戶進行自己的工作已經有一段時間了，但在完成工作的方式上仍然存在障礙。此時用戶無法判斷問題的解決方案是否現實可行，所以產品在整體方案的可行性上存在着不確定性。
④用戶在清晰說明他們的需求方面存在困難，例如默認需求或者潛在需求。這些相關的需求是有着不確定性的需求。
⑤需求工程師在理解用戶的需求上存在困難。在澄清和理解之前，這些需求存在着不確定性。
⑥需求的可行性值得懷疑，即具體需求的可滿足性存在着不確定性。
8、 試比較原型開發方法的三種類型。
答：（划線部分為必答要點）
（1）探索式
探索式原型法是以缺陷需求開始繼而不斷調整和修正需求的原型開發方式。探索式的原型方法通常要盡可能地調整各種設計選項（例如需求內容、軟件化內容以及軟件支持方式等），並比較多種設計方案下的用戶反饋以得到理想的用戶需求。探索式的原型方法能夠幫助開發者更深入地了解用戶的業務、問題和期望。
（2）實驗式
實驗式的原型方法初始時擁有清晰的用戶需求，但是開發者對這些需求的實現方法、實現效果和可行性沒有太大的把握。實驗式的原型方法需要首先定義一個對原型的評估方法，確定評估的屬性（例如可行性、適用性、效率、吞吐量等），據此評估各種技術方案下的原型，明確需求的可行性和有效的技術實現方案。
（3）演化式
在演化式的原型方法中，原型的開發並不是一個獨立的活動，而是整個項目的持續開發過程中的一個部分。原型開發的初始點既有要求原型化的需求，也有項目積累下來的原型資產。積累下的原型資產所沒有實現的需求，往往是清晰的需求。在開發原型時，還要能夠以一個整體的方式傳遞給下一個原型開發過程。這個被不斷傳遞和不斷增強的原型資產將成為 終的軟件系統。通過在持續開發過程中使用原型方法，可以使軟件開發過程更好地處理用戶需求的不斷變動。
在探索式、實驗式和演化式這三種原型方法中，前兩種方法產生的原型往往是在經歷了很多次錯誤的嘗試之后才產生的。這些錯誤的嘗試過程會在 終的原型產品中留下痕跡，原型中的一些代碼是在錯誤的前提（錯誤的需求、錯誤的技術方案）下完成的，它們會使原型產品具有很差的質量，所以人們在得到正確的嘗試之后往往會拋棄這些原型產品，另起爐
灶。為此，探索式和實驗式方法產生的原型產品又被稱為拋棄式原型（Throwaway
Prototype）。
拋棄式原型的貢獻不在於它的代碼，而是它所包含的內容，它說明了正確的需求和正確的技術方案。
因為拋棄式原型的代碼是要被拋棄的，所以在建立拋棄式原型時，應該盡量花費 小的代價，爭取 快的速度。為此，原型的開發者會使用一些簡易的開發工具和不成熟的構造技術，忽略或簡化一些和原型目標不相關的功能特征。
9、 試述在需求獲取中使用原型方法的主要步驟。
答：
在需求獲取中使用原型方法的主要步驟包括：
①確定原型需求。搞清楚為什么要開發原型，擁有的起始點是什么，期望的結束標准是什么?
②原型開發。依據原型的需求特點和開發目的，選擇原型的開發方法和構建技術，建立初始原型。
③原型評估。對上一階段產生的原型進行評估，根據評估者的反饋判斷原型是否滿足結束標准。評估者一般是用戶和開發者。
④原型修正。如果已經建立的原型達到了目的，就結束原型方法過程。否則根據評估者反饋的不足進行原型調整，調整完成后准備再次進行原型評估。
10、 簡述使用原型方法的主要風險。
答：
原型方法的 大優點是能夠及早地解決系統開發中的不確定性，從而降低軟件項目失敗的風險，但原型方法的復雜性使得它在降低風險的同時也引人了新的風險。
（1） 原型方法 大的風險就是涉眾看到了一個正在運行的原型，從而得出產品幾乎已經完成的結論，從而提出快速交付產品的不當要求。
（2） 原型方法的另一個風險是用戶可能會被原型所表現出來的非功能特性遮蔽了眼睛，從而忽略了他們更應該重視的功能特性。
（3） 原型方法的第三個風險是原型方法在澄清需求不確定性的同時也可能會掩蓋一些用戶的假設，這些假設將會無從發現。，原型的開發者要仔細地分析原型的
（4） 后，還應該避免對原型開發工作投入太多的工作，使開發團隊消耗了過多的時間和過大的成本， 后被迫只能匆匆忙忙實現一個產品，甚至只是交付一個原型。
17、請說明為何要確定需求的優先級。
答：（划線部分為必答要點）
在理想的情況下，開發者應該讓 終的軟件系統完美地滿足用戶提出來的所有需求。但是這種理想的情況並不總是會在現實中發生，甚至是很少在現實中發生。作為一項工程，軟件開發總是在一定的環境限制下進行的，成本效益比是它成功的一個基本衡量標准。因此，在工程環境下，需求與需求之間並不是同等重要的，一些需求應該優於另一些需求得到更多的實現保證，這就是要確定需求優先級的原因。在實踐中，確定優先級的活動尤為重要的情況有：
①一個項目的資源（時間、人力、成本等）有限，無法滿足用戶的所有需求。此時項目管理者就需要確定一種 佳方案，在既定的成本下取得 大的效益。需求優先級就是項目管理者進行此項工作的重要基礎。
②項目采用了分階段的開發方式。為了 大化地體現項目的成本效益，項目應該在第一階段就交付用戶 重要和 緊急的需求，並將用戶 不重要和 不緊急的需求放在開發的后一個階段。這就需要通過確定需求優先級的方式來划分需求的重要性和緊急性等級。
③在項目的開始階段，並不能明確所有的用戶需求，或者無法保證會 終滿足所有的用戶需求。這個情況是實踐中 為常見的情況，迭代式的開發基本都屬於這種情況。對這種情
況，要區分用戶需求的優先級，優先迭代級別高的需求，保證項目 終 大程度地滿足了用戶的需求。
18、請說明需求分析人員在需求協商當中應該予以確保的三個原則。
答：（划線部分為必答要點）
需求分析人員在需求協商當中應該予以確保的三個原則是：
①明確沖突的因素，避免情緒上的沖突。需求分析人員應該從技術上發現和描述沖突背
后的本質原因，並幫助避免和解決涉眾在協商中間可能產生的情緒沖突（Emotional conflict）。
②明確沖突的解決空間。需求分析人員應該引導涉眾之間的協商，在涉眾協作中發現和明確各種可能的解決方式（Alternatiyes）、論據（Argumentations）和理由
（Rationales）。
③確定 佳解決方案。需求分析人員應該提供足夠的技術信息支持，幫助涉眾在既有的解決空間內達成 佳的解決方案。
25、 請說明為什么要編寫需求規格說明文檔？答：（划線部分為必答要點）
（1）編寫需求規格說明文檔的必要性：在一個復雜軟件系統的開發中，編寫需求規格說明文檔是非常必要的。
一方面，清晰、明確、結構化的文檔可以將軟件系統的需求信息和解決方案更好的傳遞給所有的開發者。
另一方面，文檔可以拓展人們的知識記憶能力。
（2）編寫需求規格說明文檔的他好處：
①需求規格說明文檔可以成為各方人員之間有關軟件系統的協議基准。開發者和客戶可以使用它作為合同協議的重要部分，涉眾也可以利用它在相互間達成一致。
②需求規格說明文檔可以成為項目開發活動的一個重要依據。它可以作為軟件估算和
項目進度安排的基礎，也可以作為開發人員判斷設計、測試等工作的進行是否正確的依據。
③在需求規格說明文檔的編寫過程中，可以盡早的發現和減少可能的需求錯誤，從而減少項目的返工，降低項目的工作量。
④需求規格說明文檔可以成為有效的智力資產。這個智力資產可以幫助新加入的團隊成員更快的融入項目，可以幫助更好地將軟件產品移交給新客戶，也可以幫助開發者更好地進行其他類似項目或者后續增強項目的開發。
26、 試比較編寫需求規格說明文檔所使用的三種語言。
答：（划線部分為必答要點）需求工程師在描述需求規格說明文檔時使用的語言分為三類：
①非形式化語言，即自然語言。
②半形式化語言，比自然語言具有更豐富的語義和更嚴格的語法同時又沒有嚴格到完全基於數學方法的語言，例如 ERD、DFD、UML 等圖形語言。 ③形式化語言，基於數學的語言，例如 VDM、Z 語言等。
自然語言具有復雜的規則和多樣化的表達方式，所以它的表達能力 為強大。而且自然語言屬於普通人的語言，每個人都熟知其規則、表達方式和特點，所以非常利於用戶的理解。但同時自然語言也具有松散、模糊、歧義、凌亂等不好的特性。這使得它無法被機器所理解，它所描述的信息內容也無法准確地映射為機器行為。
形式化語言是基於數學方法的語言，具有數學的表示法特性。使用形式化語言描述的信息內容是可以進行邏輯一致性推導和證明的，所以它能夠保證信息的正確性。而且形式化的信息描述能夠被機器所理解，它所描述的信息內容可以准確地映射為機器行為。但是形式化描述的信息要求讀者具備謂詞演算方面的知識，這對普通的用戶而言顯然要求過高，以至於大多數用戶無法讀懂以形式化方法描述的信息。形式化方法所能描述的內容也是有限的，具體的有限性因形式化方法的不同而各異。
半形式化語言是介於自然語言和形式化語言之間的描述語言。一方面，半形式化語言具有嚴格的語法，定義方式比自然語言更加嚴格，這使得它可以避免自然語言模糊、松散、歧義、凌亂等不好的特性。另一方面，半形式化語言具有豐富的語義，使用規則比形式化語言更復雜和多樣，這使得它具有比形式化方法更強的表達能力。但是，豐富的語義使得半形式化語言的語法無法嚴格到可以等價於數學方法的程度，所以它描述的信息還需要進行額外的處理才能夠被機器所理解或者准確地映射為機器行為。同時，嚴格的語法限制也使得半形式語言的表達能力無法達到自然語言的程度。而且因為具有獨特的語法和語義，所以半形式語言對普通用戶而言無異於一門全新的語言，它所描述的信息很難被用戶所理解。
自然語言采用了以文本為主的描述方式；形式化語言也是使用以文本為主的描述方式；半形式化語言采用了以圖形為主的描述方式，因為：
①半形式化語言的語法限制使得它用於信息描述的基本元素是有限的，這個有限性使得它以限定文本或者限定圖形符號為描述方式成為可能。
②半形式化語言追求表達語義的豐富性，而在這一點上圖形符號是勝過限定文本的，所以人們傾向於選擇使用圖形符號的描述方式。
在進行需求規格說明文檔的編寫時，用戶傾向於使用自然語言，因為其他兩種類別的語言難以理解。開發人員傾向於使用半形式語言和形式化語言，因為自然語言的表達不夠嚴格和准確。形式化語言在實踐中的應用很少，因為需求規格說明對語言的語義和表達能力有着較高的要求，而這恰恰是形式化語言有所欠缺的。
為了讓需求規格說明文檔的內容能夠同時滿足用戶和開發人員的需要，需求工程師在實踐中更多時候會綜合使用自然語言、半形式化語言和形式化語言。
27、簡述評審的過程並說明何時可以結束評審？答：（划線部分為必答要點） 常見的評審過程可以分為 6 個階段：
（1） 規划階段（Planning），作者和仲裁者共同制定審查計划，決定審查會議的次數，安排每次審查會議的時間、地點、參與人員、審查內容。
（2） 總體部署階段（Overview），作者和仲裁者向所有參與審查會議的人員描述待審查材料的內容、審查的目標以及一些假設，並分發文檔。
（3） 准備階段（Preparation），審查人員各自獨立執行檢查任務。在檢查的過程中，他們
可能會被要求使用檢查清單、場景等檢查方法，記錄下來檢查中發現的問題，以准備開會討論或者提交給收集人員。
（4） 審查會議階段（Inspection Meeting），通過會議討論，識別、確認和分類發現的錯
誤。在審查會議結束時，還可以根據審查發現的問題嚴重程度來確定軟件需求規格說明文檔是可以在修正后接受，還是需要在修正后再次進行評審。
（5） 返工階段（Rework），作者修改發現的缺陷。
（6） 跟蹤階段（Follow-up），仲裁者要確認所有發現的問題都得到了解決，所有的錯誤都得到了修正。仲裁者還要判斷修正后的文檔是否已滿足審查的結束標准，如果不滿足就需要再次進行評審。
若滿足下列情況，審查工作可以結束。
①審查期間審查人員提出的所有問題都已解決。
②文檔中和相關的工作產品中的所有更改都已正確完成。
③修訂過的文檔已經進行了拼寫檢查。
④所有標識為 TBD(待確定)的問題都已經解決，或者已經對每個待確定問題的解決過程、計划解決的目標日期和由誰來解決等編制了文檔。
⑤文檔已經在項目的配置管理系統中作了登記。
28、簡述需求管理的主要作用。
答：（划線部分為必答要點）在實踐中發現的需求管理的作用有：
①增強了項目涉眾對復雜產品特征在細節和相互依賴關系上的理解。需求管理將需求基線納入了項目的知識管理，能夠幫助項目涉眾更好地獲得並理解這些知識，從而增強了項目涉眾對需求(尤其是復雜需求)的掌握。
②增進了項目涉眾之間的交流。需求管理為項目涉眾提供了一個共同的需求理解，從而有助於項目涉眾之間的交流，減少了可能的誤解和交流偏差。
③減少了工作量的浪費，提高了生產力。需求管理能夠更加有效地處理需求的變更，減少因此產生的返工工作，從而提高了項目的生產率。
④准確反映項目的狀態，有助於項目決策。需求管理收集的需求跟蹤信息能夠更加准確地反映項目的進展情況，從而幫助項目管理者更好地掌握項目狀態，做出更加符合實際情況的合理決策。
⑤改變項目文化，使得需求的作用得到重視和有效發揮。需求管理可以為項目涉眾帶
來很多的好處，使得項目涉眾認識到需求在項目工作中的重要性，並依照需求開展工作。
29、 簡述需求管理的重要任務答：
需求管理的重要任務有：
①交流涉眾的需要。
②將需求應用、實施到解決方案。
③驅動設計和實現工作。
④控制變更。
⑤將需求分配到子系統。
⑥測試和驗證 終產品。
⑦控制迭代式開發中的變化。
⑧輔助項目管理。
30、 簡述如何進行需求變更控制？
答：（划線部分為必答要點）
需求開發是一個獲取、明確並定義需求的過程，但需求並不是在需求開發結束之后就會恆定不變的。
為了解決需求變化給項目帶來的影響，需要正確地處理需求變化，首先要認識到在很多情況下，需求的變化是正當和不可避免的：
①問題發生了改變。軟件被創建的目的在於解決用戶的問題，可是隨着時間的發展，形勢可能會發生變化，導致用戶的問題也發生了變化。原來的問題可能因為各種原因不解白破，或者用戶將原來的主要問題降為次要問題，而將原來的次要問題升級為主要問題等。所有這些都意味着軟件的需求應該發生變化，否則創建的軟件將會減小甚至失去服務用戶的作用。
②環境發生了改變。軟件是通過與其周圍環境進行交互的方式來解決用戶的問題的。如果軟件的環境發生了改變（例如法律變化、業務變化等），那么即使用戶的問題依舊，軟件的需求也應該發生改變。否則， 終的軟件將不能像設想的那樣有效地解決用戶的問題，因為舊有的模式已經無法和新的環境形成有效互動。
③需求基線存在缺陷。需求開發的理想結果當然是建立一個完全無缺陷的需求基線，但這是不可能達到的目標。因為需求工程的復雜性，需求開發得到的需求基線總是或多或少的會遺留下一些缺陷。當這些缺陷在開發或者使用中暴露出來時，必須予以及時解決。
④用戶變動。在開發和使用中，軟件產品的用戶可能發生的人員更替，這時新的用戶就可能會提出和原有用戶不同的要求。在維護期間和比較長的開發周期中往往會發生這類變更。
⑤用戶對軟件的認識變化。隨着對軟件開發和使用的直接參與，用戶會對軟件領域有越來越多的了解，這時他們也往往會提出越來越多、越來越具體的需求，其中就夾雜着對原有需求的修改要求。在一個全新的領域或者為一個沒有軟件經驗的企業開發軟件時，這種情況非常常見。
⑥相關產品的出現。在產品開發的過程中，可能會有競爭產品、類似產品或者需要交互的其他產品等相關產品出現，這時往往需要開發者根據相關產品的新鮮知識，變更原有的軟件需求和開發計划。