《軟件需求分析》習題集

1、軟件需求分析習題集軟件需求分析課程組編20122012年 4 4月目 錄一、單項選擇題 .2二、填空題 .5二、判斷題.9四、名詞解釋題 .11五、問答題 . 14六、案例分析題 .28）理解不透徹或應用不軟件需求分析習題集一、單項選擇題1、軟件生產中產生需求問題的最大原因在于對應用軟件的（ 堅決。（A）復雜性（B）目的性（C）模擬性（D）正確性2、 需求分析的目的是保證需求的（）。（A）目的性和一致性（B）完整性和一致性（C）正確性和目的性（D）完整性和目的性3、系統(tǒng)需求開發(fā)的結果最終會寫入（）。（A）可行性研究報告（B）前景和范圍文檔（C）用戶需求說明4、（現(xiàn)實屬性和中的（B）（D）系統(tǒng)需

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

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

4、）開發(fā)、實現(xiàn)和作用（C）成本、技術和實現(xiàn)（D）需求、作用和角色12、當用戶無法完成主動的信息告知，或與需求工程師之間的語言交流無法產生有效的結果時，有必要采用（）。（A）民族志13、 以下（A）突現(xiàn)14、 以下（B）觀察法（C）話語分析（D）任務分析）不是情景性的重要性質（B）涉身（C）完善）是情景性的重要性質（D）模糊（D）即時（B）開放（C）交互（A）全局（A）面向目標的方法（B）基于場景的方法。（C）基于用例的方法（D16、下列（ ）屬于定量硬數(shù)據（A）工作手冊（B）規(guī)章手冊仃、下列（ ）屬于定性硬數(shù)據（A）數(shù)據收集表 （B）月報表18、功能目標可以分為（基于采樣的方法（C統(tǒng)計報表（C）

5、年報表（D備忘錄（D）規(guī)章手冊（A）安全目標和可用性目標(B)滿足型目標和信息型目標（D）解和細化時使用的維護目標和實現(xiàn)目標AND Co ntributi on 鏈接和 OR Co ntribution接，Contribution的作用是（）。（A）積極的（B）消極的（C）積極的或消極的（D）不能確定化的子目標，D鏈接將將一個父目標連接到一系列細化的子目標，意思是如果能夠滿足所有細（A）無法確定（B）阻礙（C）不能滿足（D）足以滿足21、OF鏈接是將一個父目標連接到一系列細化的子目標，意思是如果能夠滿足所有細 化子目標中的（），那么將足以滿足父目標。（A）每一個（B）任何一個（C）特定的（D）

6、某一個22、下列選項中，（）不是在目標模型中使用的其他模型元素。（D）概念）。24、場景的分類框架將場景方法從場景的（）4個方面進行了分類和描述。（A）形式、目的、內容和生命周期（B）外觀、目的、內容和生命周期（C）描述、目的、內容和形式（D）描述、外觀、目的和內容25、場景的形式是指場景的表達模式，從形式上分為兩個方面：（）（A）內容和目的（B）內容和生命周期（C）描述和外觀（D）描述和目的26、描述場景所使用的表示法要符合正規(guī)性要求，一般可使用非形式化語言、半形式 化語言和形式化語言。在實踐中，（）是主要的描述方式。（A）形式化的程序語言（B）非形式化的自然語言（C）形式化的圖形工具/、亠

7、27、外觀是指場景被表達出來時的效果，主形式化的設計語言）三種類型。（A）靜態(tài)、動態(tài)和結構化（B）線性、非線性和交互（C）靜態(tài)、動態(tài)和動靜結合（D）靜態(tài)、動態(tài)和交互不是場景的場景的內容是指場景所表達的知識類型。它被分為6個不同的方面。下列（A）主要關注點（B）環(huán)境范圍 （C）目的 （D）抽象層次29、需求工程利用場景的目的可能有三種：即：（A）描述、探索和解釋（B）描述、表示和探索（C）描述、探索和發(fā)現(xiàn)（D）表示、解釋和證明30、使用解釋性場景在需求分析時能夠（），或者被用于進行需求的驗證。（A）提高模型的復雜性（B）降低模型的復雜性15、下列（）不是需求獲取常見的模型驅動方法（A）行為者（B

8、）場景（C）操作（C）建立目標模型（D）發(fā)現(xiàn)問題和缺陷（C）提高預見性（D）降低編程量31、(A)卜列（）不是場景方法在需求工程中的應用。幫助進行詳細的需求分析（D）演繹關系）的描述方式。（D）動態(tài)結構化文本（）三合取、 析取和擴展（B）編寫系統(tǒng)需求規(guī)格說明（C）結合面向目標的方法，指導需求獲取活動的開展（D）組織需求獲取得到的信息32、 下列（）是組織場景時可用的場景關系。（A）合取關系（B）定性關系（C）定量關系33、 與其他的場景方法相比，用例最大的特點是采用了（A）靜態(tài)非結構化文本（B）動態(tài)非結構化文本（C）靜態(tài)結構化文本34、用例之間的關系主要有（A）包含、擴展和簡化（D）包含、擴展

9、和泛化、定義和結構化，它的目的是獲取某個可以轉換為知識的事物的信息，這種分析活動被稱為（）。（A）需求信息獲?。˙）建立軟件系統(tǒng)解決方案（C）需求信息轉化（D）建立需求分析模型36、 （）是建模最為常用的兩種手段。（A）具體和抽象（B）抽象和分解（C）分解和細化（D）抽象和細化37、 抽象通過強調本質的特征，（）了問題的復雜性。（A）調整（B）避免（C）增加 （D）減少38、 需求分析僅僅需要描述解決方案，不需要探索實現(xiàn)細節(jié)的情況下，分析模型又是（）的，尤為適用。（A）形式化（B）半形式化（C）結構化（D）非結構化39、上下文圖描述系統(tǒng)與環(huán)境中外部實體之間的界限和聯(lián)系。它從現(xiàn)實世界的角度說明

10、了系統(tǒng)的（ ），并確定了所有的輸入和輸出。（A）環(huán)境與外觀（B）邊界和聯(lián)系 （C）邊界和環(huán)境 （D）輸入和輸出40、 （）是結構化分析方法的核心技術，它表明系統(tǒng)的輸入、處理、存儲和輸出，以 及它們如何在一起協(xié)調工作。（A）數(shù)據流圖DFD（ B）實體聯(lián)系圖 ERD （ C）狀態(tài)轉換圖（D）上下文圖41、 結構化、信息工程和面向對象三種方法學下的需求分析技術都是（）的。（A）面向問題域 （B）面向解系統(tǒng) （C）面向設計 （D）面向需求一）需求階段的分析。42、 使用面向冋題的技術對冋題世界的建模就被稱為（A）前期（B）中期（C）后期 （D）全過程）需求階段的分析。43、 使用面向解系統(tǒng)的技術對軟件

11、系統(tǒng)解決方案的描述稱為（44、 需求分析活動中期個重要任務是進行（D）全過程），明確用戶需求的隱含信息，展開為 明確的對軟件系統(tǒng)的行為期望，即系統(tǒng)需求。（A）需求整理（B）需求細化 （C）需求獲?。―）需求分析45、 在分層結構中，DFD定義了三個層次類別的 DFD圖：（）、0層圖和N層圖。（A） 1層圖（B）底層圖（C）上下文圖（D）頂視圖圖中不會出現(xiàn)為數(shù)據存儲是系統(tǒng)內部的功能實現(xiàn)，所以在將系統(tǒng)視為黑盒的情況下，上下文。（C）虛線框（D）矩形框。（B）順序圖、通信圖和時間圖（D）交互概述圖、通信圖和時間圖（C）交互圖、狀態(tài)圖和活動圖），重點都是用戶的現(xiàn)（A）實體（B）數(shù)據存儲實例（C）需求信

12、息（D）過程處理47、 數(shù)據建模技術能夠彌補過程建模在（）方面的缺陷，它描述數(shù)據的定義、結構和關系等特性。（A）需求分析（B）數(shù)據轉換 （C）數(shù)據說明（D）數(shù)據分析48、 。概念實體是一種抽象概念，不考慮概念背后的物理存在，所以通常不包含與之相關聯(lián)的其他（）。（A）模型（B）特征（即屬性）（C）關系 （D）處理49、 在ERD建模中，實體通常所指的就是（）。（A）邏輯實體 （B）概念實體 （C）物理實體（D）進程實體數(shù)據5被稱為屬屬性是實體的特征，不是數(shù)據。屬性會以一定的形式存在，這種存在才是（A）域（B）實例（C）說明（D）值51、 ERD關系的度數(shù)（Degree）是指參與關系的實體數(shù)量，是

13、度量關系（）的一個指標。（A）模型（B）復雜度（C）精確度（D）屬性值52、 ERD關系的基數(shù)分為最大基數(shù)和最小基數(shù)。最大基數(shù)又被稱為（）。（A）鍵約束（B）參與約束（C）自然約束 （D） 般約束 的形式是在實體之間建立關系時，可能會產生一些附帶的實體，被稱為關聯(lián)實體，最常見（A）邏輯實體（B）進程實體（C）概念實體（D）自然實體54、在實現(xiàn)ERD與過程模型同步的技術中，（）是一種較為常見的技術。（A）用例圖（B）數(shù)據流圖（C）功能/實體矩陣（D）微規(guī)格說明55、 下列（）不是用例模型中的關系（B）關聯(lián)（C）泛化（D）包含56、系統(tǒng)性邊界是指一個系統(tǒng)所包含的系統(tǒng)成分與系統(tǒng)外事物的分界線。用例模

14、型使用一個（）來表示系統(tǒng)邊界，以顯示系統(tǒng)的上下文環(huán)境。（A）圓形框 （B）菱形框57、UM使用的行為模型有三種，即:（A）交互圖、狀態(tài)圖和順序圖58、項目的前景和范圍文檔、用戶需求文檔都被視為屬于（ 實世界。（A）開發(fā)文檔（B）需求文檔（C）前景文檔（D）用戶文檔59、 系統(tǒng)需求規(guī)格說明文檔、軟件需求規(guī)格說明文檔、硬件需求規(guī)格說明文檔、接口 需求規(guī)格說明文檔和人機交互文檔一起被用于系統(tǒng)開發(fā)的目的，都被認為是開發(fā)文檔。（A）開發(fā)文檔（B）需求文檔（C）過程文檔（D）用戶文檔60、 下列（）不是需求規(guī)格說明文檔的讀者（A）項目管理者（B）編程人員（C）銷售商（D）律師、填空題1、傳統(tǒng)的需求分析方法

15、都是從設計領域轉入分析領域的。2、面向專業(yè)用戶的純工具型軟件分析階段的主要目的是為充分利用創(chuàng)新優(yōu)勢而進行巧 妙的功能安排。3、面向普通用戶的純工具型軟件進行分析的主要目的是進行方案權衡，尋找一套切實產生軟件需求規(guī)格說明系統(tǒng)影響，卻會給解系統(tǒng)帶來極大影響的問題域特性有效的功能配置。4、應用型軟件分析階段的主要目的是發(fā)現(xiàn)人們利用軟件的原因（目的），找出需要軟件 解決的問題，理解應用環(huán)境中的領域知識，保證功能的模擬性-5、需求工程是所有需求處理活動的總和，它收集信息、分析問題、整合觀點、記錄需 求并驗證其正確性，最終反映軟件被應用后與其環(huán)境互動形成的期望效應。6、軟件需求開發(fā)用來確定系統(tǒng)需求中應該由

16、軟件滿足的部分，將其映射為軟件行為,8、優(yōu)秀的需求應該具備 7個特性，即完整性、正確性、精確性、可行性、必要性、無11、演示原型主是被用在項目啟戶想段中的系統(tǒng)視圖，所以它要能夠表現(xiàn)用戶界面的重 要特征。13、 ，如果一個問題的技術解決方案是不清晰的，演示原型也可以被用來展現(xiàn)相應的細 節(jié)功能以使用戶確信該問題解決的可能性。14、 通常來說，如果用戶需求出現(xiàn)了模糊、不清晰、不完整等具有一定不確定性的特征, 就可以考慮使用原型方法。15、角色是指原型物件在用戶工作中的價值，也就是說它為什么對用戶是有用的。16、外觀是指用戶對原型物件的具體感覺體驗，即用戶在使用原型物件時會看到什么、 聽到什么和感覺是

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

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

19、可以使用模型驅動方法來進行信息的整理和歸類，其中模型驅動方法所建立的模型是進行信息整理和歸類的很好的框架32、 模型驅動方法的模型是在前期需求階段的分析中建立的。33、 目標模型的一個核心要素是元素之間的關系，稱為鏈接。10、按照媒介載體進行分類，原型可分為：樣板原型和紙上向導原型。34、 目標模型的鏈接有兩類：一類是目標之間的鏈接；另一類是目標與其他模型元素之 間的鏈接。面向目標方法的處理過程可以分為三個階段：目標獲取、目標分析（即目標模型的 建立）和目標實現(xiàn)。36、 目標實現(xiàn)階段的主要任務是收集與目標相關的需求信息，討論可能的候選解決方案, 確定最終的系統(tǒng)詳細需求和解決方案。37、 場景具

20、有重點描述真實世界的特征，它利用情景、行為者之間的交互、事件隨時間 的演化等方式來敘述性地描述系統(tǒng)的使用。38、 靜態(tài)外觀的場景被展現(xiàn)為一個或者數(shù)個描述性的文本或者圖片。39、 動態(tài)外觀的場景會被以動態(tài)的方式展現(xiàn)出來，人們可能會要求按時序向前或者向后瀏覽場景，也可能會要求跳轉到場景的某一個時刻進行觀察。_40、 交互外觀的場景提供交互性，它允許用戶在一定程度上控制和改變場景的變化時序 或者效果。具體場景，又稱為實例場景，是對個別行為者、事件、情節(jié)的細節(jié)描述。42、 抽象場景，又稱為類型場景，是以經驗中的類別和抽象概念來描述事實。43、 探索性場景可以用來進行需求獲取和需求建模與分析。44、 每

21、個用例是對相關場景集合的敘述性的文本描述，這些場景是用戶和系統(tǒng)之間的交 互行為序列用例是場景方法中的的目一種，是靜態(tài)的結構化文本描述。46、 在高層的功能需求獲取完備之前，用例的產生方式中不允許使用功能分解47、 單個用例描述了系統(tǒng)的功能片段，系統(tǒng)的所有用例基于一定的關系組織起來，建立 用例模型，原就有用例和新個系統(tǒng)的功用例的咲系即為包含關系。49、在需求工程中，主要產生三類重要的文檔：項目前景和范圍文檔、用戶需求文檔以 及需求規(guī)格說明。用例文檔通常被用來代替用戶需求文檔，起到記錄、交流領域信息和用戶 期望的0作用需求獲取得到的信息和需求開發(fā)應該建立的軟件系統(tǒng)解決方案之間有著很大的差 距。需求

22、分析就是用來解決這個差距的需求工程活動。51、 需求分析的根本任務是：建立分析模型并創(chuàng)建解決方案。52、 分解將單個復雜和難以理解的問題分解成多個相對更容易的子問題，并掌握各子 冋題之間白基于軟件構建單位及其之間的關系建立的模型，用來說明軟件邏輯上的構建方式 和實現(xiàn)方式，由于它使用的組元及其關系都是軟件的元素，因此它是來自于軟件的模型，稱 為計算模型。型語言的三要素：語法、語義、語用。其中語用給出”個模型元素描述的更 寬廣的上下文，以及影響該模型元素意義的約束和假定。55、 互相之間建立了語義聯(lián)系的多個模型，集成在一起通常被稱為視圖。56、 需求分析方法主要有：結構化方法、信息工程方法和面向對

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

24、。63、DFD中所有的外部實體聯(lián)合起來構成了軟件系統(tǒng)的外部上下文環(huán)境，它們與軟件65、DFD勺0層圖中的每個過程都可以進行分解，被分解的過程稱為父過程，分解后 產生的揭示更多細節(jié)的 DFD圖稱為子圖。66、 DFD勺0層圖通常被用來作為整個系統(tǒng)的功能67、 為了保證DFE圖的可理解性，0層圖應該被描述的簡潔、清晰，所以在描述復雜的 系統(tǒng)時，0 層圖中不應出現(xiàn)太過具體的過程和數(shù)據存儲。68、 DF沖對0層圖的過程分解產生的子圖稱為1層圖。69、 數(shù)據建模建立的模型稱為數(shù)據模型，是問題域和解系統(tǒng)共享的知識集合，通常能 夠反映企業(yè)業(yè)務的核心知識。70、數(shù)據模型的內容是問題域和解系統(tǒng)所共享的知識模型，

25、可以用問題域的語言來解 釋，也可以用解系統(tǒng)的語言來解釋，還可以用介于問題域和解系統(tǒng)之間的中立語言來解釋。_ 、在需求工程中，數(shù)據建模建立的是概念數(shù)據模型和邏輯數(shù)據模型，不涉及物理數(shù)據模型2、ERD勺邏輯實體是對概念實體的細化，擁有完整的特征扌 -73、數(shù)據建模中對行為和事件的建模需要是為了了解它們在某些時刻的快照或者運行 環(huán)境信息，而不是它們所體現(xiàn)出來的功能和達成的效果，所以稱這類實體為進程實體。74、ER沖屬性就是可以對實體進行描述的特征，一系列屬性的存在集成起來就可以 描述一個實體D中屬性取值的受限制范圍稱為域（Domain）。76、ERD實體指定一個屬性或多個屬性的組合，可以用來唯一地確

26、定和標識每個實 例，這些屬性或屬性的組合稱為實體的標識符，又稱為鍵。78、 一個人們可多有候選鍵中這些鍵使被稱定的選一。鍵來進行實例的標識，這個被 選中的候選鍵被稱為主鍵，沒有被選做主鍵的候選鍵被稱為替代鍵。79、 實體實例大多數(shù)屬性的值都是需要從現(xiàn)實中獲取的，稱為存儲屬性。80、 有些實體實例的屬性的值是可以由其他屬性的值計算得出的，稱為導出屬性。82、只有是個實體參與的關系存在于實體的不同實例之間，稱為一元關系，又稱為遞 歸關系。83、 ER沖關系的基數(shù)分為最大基數(shù)和最小基數(shù)。最小基數(shù)又被稱為參與約 -84、 ER沖一個實體在關系中的最大基數(shù)是指，對關系中任意的其他實體實例，該實 體可能參

27、與關系的最大數(shù)量關系中的最小基數(shù)是指，對關系中任意的其他實體實例，該實體可能參與關系的最小數(shù)量。86、 ER沖被關系影響的實體主要是弱實體和關聯(lián)實體。87、 用例模型的基本兀素有四種：用例、參與者、關系和系統(tǒng)邊88、 UML亍為模型是用例模型的實現(xiàn)，以更加詳細的方式說明用例所描述的系統(tǒng)行為。89、 UML亍為模型的活動圖是依據處理流程進行的用例實現(xiàn) -90、 UML亍為模型的交互圖通常描述的是單個用例的典型場景。91、接口需求規(guī)格說明文檔是對整個系統(tǒng)中需要軟、硬件協(xié)同實現(xiàn)部分的詳細描述。利性跟蹤關性和級動化驗析?？尚薷?、可跟蹤等特性。94、 評審又被稱為同級評審，是指由作者之外的其他人來檢查產

28、品問題的方法。95、在系統(tǒng)驗證中，評審是主要的靜態(tài)分析手段，所以評審也是需求評審的一種主要 方法。96、需求基線的維護主要包括配置管理和狀態(tài)97、需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在向前和向后兩個方向上，描述需 求以及跟蹤需求變化的能力。98、 從需求向后回溯（前向跟蹤的兩種聯(lián)系之一）說明軟件需求來源于哪些涉眾的需 要和目標。99、 后向跟蹤是指需求被定義到軟件需求規(guī)格說明文檔之后的演化過程。100、 后向跟蹤包括兩種聯(lián)系：從需求向前跟蹤和回溯至 三、判斷題1、需求工程包括需求獲取和需求開發(fā)兩個方面。（X）2、需求驗證是需求工程中最后一個活動。（X）3、軟件系統(tǒng)能夠與問題域進行交互和相互

29、影響的原因在于，軟件系統(tǒng)中的某些部分對問 題域中的某格說明是問題域為滿足用戶需求而提供的解決方案，規(guī)定了解系統(tǒng)的行為特征。（X）5、業(yè)務需求具有明顯的目的性和較高的抽象性，經過明確和細化的處理，可以直接轉化 為系統(tǒng)需求。（X）6、需求開發(fā)的一些特性決定了需求開發(fā)過程只能是一個簡單的線性增量過程。（X）7、對于需求不確定性比較小的項目，用戶參與可以取得比較好的效果，但對于需求不確 定性比較大的項!技術進行分反而原型可分阻礙作用原型和垂直原型。（9、嚴格意義上的原型主要被用在需求分析階段。（V）10、 要完成相同的功能，構建拋棄式原型比構建演化式原型所花費的代價要大得多。（X）11、水平原型方法僅

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

31、也正是客戶所 需要的。（X）18、 成功的需求獲取任務不僅要求成功地執(zhí)行每一次具體的需求獲取行為，還要求成功地處理多次獲取行為之間的關系。（V）19、 軟目標是一類無法清晰判斷是否滿足的目標，所以可以用AND和OR鏈接直接應 用于軟目標。（X）20、 子目標的實現(xiàn)只能促進父目標的實現(xiàn)。（X）21、 AN和OR鏈接用于描述目標的分解和細化關系。（V）22、 目標的發(fā)現(xiàn)并是一個自上而下分解的過程，也就是一個不斷發(fā)現(xiàn)和細化的過程。（X）23、 對系統(tǒng)的現(xiàn)狀和背景進行分析往往能夠發(fā)現(xiàn)重要的目標，得到一些明確的問題和缺陷，它們的反面就是系統(tǒng)需要實現(xiàn)的目標。（V）24、 場景被人們廣泛接受的原因是因為人們

32、更傾向于會對真實事件和真實事物的描述產 生反應。（V）25、 描述場景時所使用的常見媒介形式主要有：敘述性的自由文本、結構化文本。強限 制文本、表格、圖表、圖像等。（V）26、 在實踐中，以動態(tài)的場景外觀為主。（X）27、 場景內包含的知識只能是關于未來的。（X）28、 描述性場景的目的是為了記錄已經得到的需求，即整理每次需求獲取行為中得到的 彳信息。（）口心29、UM就是以用例來捕獲系統(tǒng)所有的系統(tǒng)需求的。（X）30、 用例的內容只能包含有正常流程，而不能包含有異常流程。（X）31、 用例可以用于各種目的的應用，包括描述、探索和解釋。（V）32、 用例是在對現(xiàn)實世界的探索中或者是在對需求規(guī)格說

33、明的解釋中產生的，是通過功 能分解的方式創(chuàng)例是不能被實例化的，它必須被包含在其他用例中才能得以執(zhí)行。（V）34、 用例間的泛化關系是指子用例繼承了父用例的特征。（X）并增加了新的特征35、 抽象一方面要求人們關注重要的信息，同時又不能忽略次要的內容。另一方面也要 求人們將認知保留在適當?shù)膶哟?，屏蔽更深層次的細?jié)。（X）36、 由于計算模型的形式化特征不適合于需求工程階段，因此計算模型不適合用于需求 分析中的建有形式化特征的計算模型是用戶和開發(fā)者共同理解的模型。（X）38、由于模型需要描述的內容太過復雜的，因此分析模型對模型語言語用的要求不可能 太咼39（緞件需求分析的關鍵是為真實世界的問題建立

34、模型，即問題域建模。（V）40、 在“結構化方法一信息工程方法一面向對象方法”的發(fā)展歷程中，每一種后來的方 法在吸收了前面方法的重要思想的同時也替代前面的方法。（X）41、 結構化、信息工程和面向對象三種方法學下的需求分析技術都適合于需求階段全過 程的分析任務下文圖是后期D的一個特定層次，被用來說明系統(tǒng)的上下文環(huán)境，確定系統(tǒng)的邊 界。（V）43、 外部實體是指處于待構建系統(tǒng)之外的人、組織、設備或者其他軟件系統(tǒng)，但它們要 受系統(tǒng)的控制，開發(fā)者可以以任何方式操縱它們。（X）44、 上下文圖以黑盒看待和描述系統(tǒng)的方式使它非常適合描述系統(tǒng)的應用環(huán)境、定義系統(tǒng)的邊界，這正是 DFD在層次結構中將其置于最

35、高層的原因。（V）45、數(shù)據模型說明了問題域和解系統(tǒng)共享的事物、對共享事物的描述和共享事物之間 的關系6、僅）關系表達的不是邏輯上的鏈接（例如整體部分關系），而是實體物理上的聯(lián)系。（X）47、 ER中存在于兩個實體之間的關系是最常見的關系，稱為二兀關系。（V）48、 ER呼子類型關系是實體間自然的業(yè)務聯(lián)系，而不是人為施加的結構關系，是一 種特殊的實體間功能系。實體矩陣的過程可以幫助驗證過程模型和數(shù)據模塊的正確性，發(fā)現(xiàn)其中 的錯誤、遺漏、冗余和不一致。（V）50、 發(fā)起或觸發(fā)用例的外部用戶以及其他軟件系統(tǒng)等角色被稱為參與者。（V）51、 交互圖是對單個用例的典型場景的實現(xiàn)，適合于事務性業(yè)務工作的

36、表示。（V）52、 UML亍為模型的狀態(tài)圖是以狀態(tài)機模型的方式進行的用例實現(xiàn)。狀態(tài)圖只能用來 實現(xiàn)單個用例無法被用來描述程序的控制邏輯和工作流程。（V）54、OC的表達式定義可以在程序中得到直接的執(zhí)行。（X）55、軟件需求規(guī)格說明文檔是對部分系統(tǒng)功能分配給軟件部分的詳細描述。（X）56、硬件需求規(guī)格說明文檔是對整個系統(tǒng)功能當中分配給硬件部分的詳細描述。（V）57、人機交互文檔是對整個系統(tǒng)功能中需要進行人機交互部分的詳細描述。（V）60、前向跟蹤是指需求在被獲取到軟件需求規(guī)格說明文檔之前的演化過程。（X）定義 四、名詞解釋題1、需求工程：需求工程是軟件工程的一個分支，它關注于軟件系統(tǒng)所應予實現(xiàn)的

37、現(xiàn)實 世界目標、軟件系統(tǒng)的功能和軟件系統(tǒng)應當遵守的約束，同時它也關注以上因素和準確的軟 件行為規(guī)格說明之間的聯(lián)系，關注以上因素與其隨時間或跨產品族而演化之后的相關因素之 間的聯(lián)系。2、需求：IEEE對需求的定義為： 用戶為了解決問題或達到某些目標所需要的條件或能力。 系統(tǒng)或系統(tǒng)部件為了滿足合同、標準、規(guī)范或其他正式文檔所規(guī)定的要求而需要具備 的條件或能或中的一個條件或一種能力的一種文檔化表述。3、需求分析：需求分析是利用建模與分析技術對獲取筆錄的內容進行明確、整理、匯 總，建立一個綜合考慮問題域特性和需求的系統(tǒng)模型，然后根據系統(tǒng)模型將用戶需求轉化為 系統(tǒng)需求的需求工程活動。4、前景（Visio

38、n ）:前景描述了產品的作用以及最終的功能，它將所有涉眾都統(tǒng)一到一 個方向上。5、范圍（scope）:范圍指出當前項目是要解決產品長遠規(guī)劃中的哪一部分，范圍聲明 它為項目劃定了需求的界線。6、 用戶參與(User Involvement ):是以用戶為中心的設計方法的核心思想，它要求開 發(fā)者建立和用戶的直接聯(lián)系，盡早地關注于用戶和用戶的任務執(zhí)行過程，通過及時獲得用戶的反饋來調整軟件設計，以完成高質量的設計。另一方面，用戶參與就是反對通過和市場人 員、管理者等中間媒介來了解用戶，因為這些間接的聯(lián)系會減少或歪曲用戶的信息。59、反復地執(zhí)行驗證。7、 硬數(shù)據：表格和文檔資料是用戶對實際業(yè)務進行加工和

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

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

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

42、提出來的，用來理解原始社會(Primitive Societies )的社會機制。它要求人類學家花費長期的時間(通常是數(shù)年)在被研究的社會中生活并且仔細觀察該社會中的實際活動，得到第一手的觀察數(shù)據。對這些觀察數(shù)據的分析可以揭示被研 究社會的社會結構、組織方法和具體活動。17、 模型驅動法：模型驅動法是一類以定義明確的模型為理論基礎，依據模型指導和 組織活動開展的需求工程方法。18、 用例驅動法：用例是一種場景的文本化表現(xiàn)方式，使用敘述性的文本來描述場景。 以用例為核心，圍繞用例開展活動的軟件開發(fā)方法被稱為用例驅動的軟件開發(fā)方法。19、 企業(yè)建模：企業(yè)建模是以使用產品的組織團體為系統(tǒng)的環(huán)境，進行

43、分析。它主要 用來理解組織的結構、行為規(guī)則、目標、重要成員的任務與職責、操縱的數(shù)據等。企業(yè)建模 利用企業(yè)的目標、任務、策略、資源等來刻畫組織的行為，并依此來發(fā)現(xiàn)組織開發(fā)系統(tǒng)的目 的，建立系統(tǒng)的業(yè)務需求。20、 過程建模：過程建模是結構化分析方法的典型技術。過程建模將系統(tǒng)看做是過程 的集合，其中一些由人來執(zhí)行，另一些由軟件系統(tǒng)來執(zhí)行。過程建模使用的主要技術有上下 文圖、數(shù)據流圖、微規(guī)格說明和數(shù)據字典等。21、 上下文圖：上下文圖是 DFD最高層次的圖，是系統(tǒng)功能的最高抽象，它將整個系統(tǒng)看做是一個過程，這個過程實現(xiàn)系統(tǒng)的所有功能。上下文圖中存在且僅存在一個過程，表 示整個系統(tǒng)。這個單一的過程通常編

44、號為0。22、 概念數(shù)據模型：概念數(shù)據模型是以問題域的語言解釋數(shù)據模型，反映了用戶對共 享事物的描述和看法，由一系列應用領域的概念組成。23、 物理數(shù)據模型：物理數(shù)據模型是對數(shù)據模型的解系統(tǒng)語言的解釋，它描述的是共 享事物在解系統(tǒng)中的實現(xiàn)形式，是形式化的定義。24、 邏輯數(shù)據模型：邏輯數(shù)據模型是為了緩解開發(fā)人員將概念數(shù)據模型轉換成物理數(shù) 據模型的困難，而使用一種介于問題域和解系統(tǒng)之間的中立語言來進行的數(shù)據模型的描述。 這種中立的語言使用更加傾向于用戶的概念和詞匯，同時使用更加傾向于解系統(tǒng)語言的表達 方式。25、 關系的基數(shù)：關系的基數(shù)是衡量關系復雜性的指標之一，又被稱為關系的約束。 一個實體在

45、關系中的基數(shù)定義了在關系中其他實體實例確定的情況下，該實體實例可能參與 關系的數(shù)量。26、 交互圖（UM行為模型）：交互圖用于描述在特定上下文環(huán)境中一組對象的交互行 為，該上下文環(huán)境就是被實現(xiàn)用例的某個場景。所以，交互圖通常描述的是單個用例的典型 場景。交互圖中的每一個交互都描述了環(huán)境中的對象為了實現(xiàn)某個目標而執(zhí)行的一系列消息 交換。27、 OCL（語言）：OCL（Object Constraint Language）稱為對象約束語言。OC不是編程語言而是一種建模語言，它在保證一定表達能力的前提下，注重于語言的簡潔性和抽象性。但它無法被用來描述程序的控制邏輯和工作流程，而且它的表達式定義也無法

46、在程序中得到 直接的執(zhí)行。28、基線：基線是已經通過正式評審和批準的規(guī)格說明或產品，可以作為進一步開發(fā)的 基礎，并且只有通過正式的變更控制過程才能修改它。29、 需求基線：需求基線(Requirements Baseline)就是被明確和固定的需求集合，是 項目團隊需要在某一特定產品版本中實現(xiàn)的特征和需求集合。30、需求跟蹤：需求跟蹤是一種有效的控制手段，能夠在涉眾的需求變化中協(xié)調系統(tǒng)的 演化，保持各項開發(fā)工作對需求的一致性。需求跟蹤是以軟件需求規(guī)格說明文檔為基線，在 向前和向后兩個方向上，描述需求以及跟蹤需求變化的能力，分為前向跟蹤(PreTraceabmty )和后向跟蹤(Post Tra

47、ceability )兩種。五、問答題1、簡述需求工程的主要任務。答：需求工程有以下三個主要任務： 需求工程必須說明軟件系統(tǒng)將被應用的環(huán)境及其目標，說明用來達成這些目標的軟 件功能，還要說明在設計和實現(xiàn)這些功能時上下文環(huán)境對軟件完成任務所用方式、方法所施 加的限制和約束，也即要同時說明軟件需要“做什么”和“為什么”需要做。 需求工程必須將目標、功能和約束反映到軟件系統(tǒng)中，映射為可行的軟件行為，并 對軟件行為進行準確的規(guī)格說明。需求規(guī)格說明是需求工程最為重要的成果，是項目規(guī)劃、 設計、測試、用戶手冊編寫等很多后繼軟件開發(fā)階段的工作基礎。 現(xiàn)實世界是不斷變化的世界，因此需求工程還需要妥善處理目標、

48、功能和約束隨著 時間的演化情況。同時，為了節(jié)省開支和進行需求規(guī)格說明的重用，需求工程還需要對目標、 功能和約簡述常件產品族定義錯化和分布情況進行綜合考慮與處理。答：(劃線部分為必答要點)在實踐和研究過程中，人們發(fā)現(xiàn)關于需求定義的具體的錯誤主要有以下幾種：需求并沒有反映用戶的真實需要。實踐表明，獲取用戶的真實需求是非常困難的。原因之一是用戶在表達自己的需要時，可能會在潛意識下進行一定的加工。為了發(fā)現(xiàn) 用戶的真實需求，需求工程師一定要進行問題分析，盡力發(fā)現(xiàn)問題背后的問題。原因之二是在人際交流中，信息會發(fā)生自然的衰減，甚至扭曲，導致需求丁程師理解 的并非是用戶所表達的。解決方法是在需求傳遞給開發(fā)人員

49、之前，請?zhí)岢鲂枨蟮挠脩暨M行仔 細模檢和歧義認需求。在實踐中，人們總是會有意和無意地寫出模糊和歧義的需求定義。無意中寫出模糊和歧義的需求定義往往是因為選詞造句不當，導致不同的人對同一項 需求產生了不同的理解。解決方法是為項目中重要的詞匯建立一個公共的可共同理解的詞匯 表，然后意產生的模的基礎之上的需求定義往往是為了應付對需求持有不同立場的用戶，這些 用戶關于需求的目標互相沖突，需求工程師于是采用了模糊化的處理方法。正確解決方法是 在項目前景的指導下，促進用戶之間的協(xié)商解決。信息遺漏。信息遺漏也是-類常見的問題，包括明顯的信息遺漏和不明顯的信息遺漏。-明顯的信息遺漏，其主要原因在于項目的范圍定義不

50、當，可以通過加強對業(yè)務需求的 處理得以解決。不明顯的信息遺漏，是因為相關信息難以發(fā)現(xiàn)，只能靠需求工程師的經驗來加以避免。不必要的需求。產生不必要需求的原因主要是：其一是用戶將一些不必要的需求作為和開發(fā)人員談判的籌碼，然后通過自己對不必要 需求的要求而在和開發(fā)人員的談判當中取得真正想要的利益，例如金錢。對此問題，唯一需 要的就是是用戶員代表中炎總是害怕信息有所遺漏，并因此產生不利后果，因此用戶總是傾 向于表達各種各樣的需要。要解決這個問題，就需要開發(fā)人員在進行用戶需求的獲取之前， 先定義明確的業(yè)務需求，然后根據業(yè)務需求進行用戶需求的過濾和選擇。其三是需求開發(fā)人員“畫蛇添足”，添加“用戶肯定會喜歡

51、”的功能，該類功能既會造 成項目額外的耗費，又不會給用戶帶來更多的幫助。這就要求需求開發(fā)人員要保持以用戶為 中心不切實際的期望。心。不切實際的期望也是實踐中常見的需求定義問題，而且它在很大程度上影響著項目的 成敗。面對不切實際的期望，要求軟件開發(fā)者提供可行性、成本等足夠的技術參考信息，幫 助用戶對其進行取舍和調整。3、簡要說明需求獲取活動的過程。答：（1）收集和應用背景資料，建立初始的知識框架。分析涉眾的高層次問題，總結出系 統(tǒng)的業(yè)務需求。（2）設計一個高層次的解決方案，并確定解決方案需要具備的系統(tǒng)特性。高層次的解 決方案和系統(tǒng)特性定義了項目的前景和范圍。（3）在項目的業(yè)務范圍內，需求工程要尋

52、找相關的涉眾，并分析和涉眾選擇。（4）對組織里存在大量的表格、單據等與業(yè)務相關的硬數(shù)據進行采樣，它們是需求獲 取活動中5）個重要的信息來源需求獲取活動，要依據項目范圍確定主題和內容，涉眾特征和 硬數(shù)據，從而確定信息來源。獲取方法通常只有綜合內容、來源和系統(tǒng)環(huán)境三者才能做出正 確的決定內容、來源和方法都確定之后，需求工程師就可以開展具體的獲取活動，獲取用戶 需求和問題域特性。獲取得到的具體信息要記錄下來，以獲取筆錄的形式進行保存。4、簡述涉眾識別的基本過程。答：涉眾識別的基本過程如下： 將初始涉眾集中起來，進行一次頭腦風暴，盡可能地列出一個涉眾類別列表。對上一步產生的涉眾類別列表進行分析，判斷它

53、們和軟件系統(tǒng)的相關性，找出其中的 鍵涉眾類為上一步的各個關鍵涉眾類別選擇代表，集中起來進行進一步的頭腦風暴，列出新的 涉眾類別列表。如果新列出的涉眾類別列表趨于穩(wěn)定，就可以結束涉眾識別過程。如果新列 出的涉眾類別列表有了新的發(fā)現(xiàn)，就提交新的涉眾類別列表，轉向第步。5、試比較面談問題組織的三種結構。答：（1）金字塔結構面談問題的歸納式組織被看做是金字塔形狀。使用這種形式時，會見者以很具體的問題 （通常是封閉式的問題）開始，然后逐漸提高問題的開放度，同時允許被會見者用越來越籠 統(tǒng)的答主回情況題。如果會見者認為被會見者需要對話題進行預熱，可以采用金字塔結構, 通過逐步的引導使被會見者進入討論。在被動

54、的情況下，如果會見者發(fā)現(xiàn)自己事先對事實的確認存在較大偏差或者被會見者看 上去不情愿討論某個話題，也可以采用金字塔結構。在某個話題討論結束的時候，使用金字塔結構的提問順序也是有用的。在這種結斗結構會見者使用演繹的方法，以一般的、開放式的問題開始，然后用封閉式 的問題縮小可能的答復。這種面談結構可看做是漏斗型。在主動的情況下，漏斗結構為開始一場面談提供了一種容易而輕松的途徑。答復者即使 答錯在被動的情況下也不會感到壓對話題有情緒，并且需要自由表達這些情緒的時候，需要 采用漏斗型提問順序?；蛘咴跁娬呤孪葘κ聦嵙私獠欢鄷r，也應該采用漏斗結構的問題組 織方式用漏斗結構的一個好處是：用這種方式組織面談能

55、得出很多的詳細信息，以至于沒有 必要使用長序列的封閉式問題。（3）菱形結構人們在面談中常常會將上述兩種結構結合起來使用，其中菱形結構就是一種最好的結合 結果。這種結構以一種非常明確的方式開始，然后考察一般問題，最后得出一個非常明確的 結士彳論結論。會見者首先提出一些簡單的、封閉式的問題，為面談過程做好鋪墊。在面談的中間階段, 向被會見者提出明顯沒有“正確答案”的一般話題的看法。然后，會見者再次限制問題以獲 得明確的答復，這樣就為會見者和被會見者提供了面談的結束時機。菱形結構結合了其他兩種結構的長處，但是也有缺點，即所花的時間比其他任何一個都 長。6、簡述軟件開發(fā)中為何使用原型工具以及使用的好處

56、。答：因為原型是在最終系統(tǒng)產生之前的一個局部真實表現(xiàn)，所以原型方法可以讓人們在系統(tǒng) 的開發(fā)過程中，就能夠對一些具體問題進行基于實物的有效溝通，從而幫助人們盡早解決軟 件開發(fā)過程中存在的各種不確定性。不確定性是指人們已經擁有的知識是不充分的，不足以 預測將來的事件發(fā)展，或者不足以清晰、準確地描述某個事物。 踐證明，力用響型有如下好處變化。 減少返工。 幫助控制不完整需求所帶來的風險。 可以將一個大的難以處理的開發(fā)過程細分成一些更小更容易處理的步驟。 減少開發(fā)成本，提高經濟效益。 增加開發(fā)者之間的交流，幫助確定技術解決方案的可行性。 有效地識別風險和解決風險，幫助進行風險管理。 提高用戶在軟件開發(fā)

57、中的參與程度。7、試說明在哪些情景下原型法可以幫助需求工程師及早解決需求的不確定性。答： 產品以前從未存在過，而且難以可視化。這些產品屬于創(chuàng)新性產品，它們的基本需求 是潛在的，有著很大的不確定性。 產品的用戶對相關類別的產品沒有經驗，而且對將要采用的技術也沒有經驗。此時用 戶無法明確工作的具體細節(jié)，產品的細節(jié)需求存在著不確定性。 用戶進行自己的工作已經有一段時間了，但在完成工作的方式上仍然存在障礙。此時 用戶無法判斷問題的解決方案是否現(xiàn)實可行，所以產品在整體方案的可行性上存在著不確定 性。用戶在清晰說明他們的需求方面存在困難，例如默認需求或者潛在需求。這些相關的 需求是有著不確定性的需求。 需

58、求工程師在理解用戶的需求上存在困難。在澄清和理解之前，這些需求存在著不確 定性。 需求的可行性值得懷疑，即具體需求的可滿足性存在著不確定性。8、試比較原型開發(fā)方法的三種類型。答：（劃線部分為必答要點）（1）探索式探索式原型法是以缺陷需求開始繼而不斷調整和修正需求的原型開發(fā)方式。探索式的 原型方法通常要盡可能地調整各種設計選項（例如需求內容、軟件化內容以及軟件支持方式 等），并比較多種設計方案下的用戶反饋以得到理想的用戶需求。探索式的原型方法能夠幫 助開發(fā)者更深入地了解用戶的業(yè)務、問題和期望。實驗式的原型方法初始時擁有清晰的用戶需求，但是開發(fā)者對，這些需求的實現(xiàn)方法、 實現(xiàn)效果和可行性沒有太大的

59、把握。實驗式的原型方法需要首先定義一個對原型的評估方 法，確定評估的屬性（例如可行性、適用性、效率、吞吐量等），據此評估各種技術方案下 的原型，演需求的可行性和有效的技術實現(xiàn)方案。在演化式的原型方法中，原型的開發(fā)并不是 個獨立的活動，而是整個項目的持續(xù)開 發(fā)過程中的一個部分。原型開發(fā)的初始點既有要求原型化的需求，也有項目積累下來的原型 資產。積累下的原型資產所沒有實現(xiàn)的需求，往往是清晰的需求。在開發(fā)原型時，還要能夠 以一個整體的方式傳遞給下一個原型開發(fā)過程。這個被不斷傳遞和不斷增強的原型資產將成 為最終的軟件系統(tǒng)。通過在持續(xù)開發(fā)過程中使用原型方法，可以使軟件開發(fā)過程更好地處理 用戶了很多次錯誤

60、的嘗試之后才產生的。這些錯誤的嘗試過程會在最終的原型產品中留下痕跡， 原型中的一些代碼是在錯誤的前提（錯誤的需求、錯誤的技術方案）下完成的，它們會使原 型產品具有很差的質量，所以人們在得到正確的嘗試之后往往會拋棄這些原型產品，另起爐灶。為此，- Throwaway Prototype )。拋棄式原型的貢獻不在于它的代碼，而是它所包含的內容，它說明了正確的需求和正確的-的代價，爭取最快的速度。為此，原型的開發(fā)者會使用一些簡易的開發(fā)工具和不成熟的構造 技術，忽略或簡化一些和原型目標不相關的功能特征。9、試述在需求獲取中使用原型方法的主要步驟。答：在需求獲取中使用原型方法的主要步驟包括： 確定原型需