需求工程簡答題-復習資料

1、方法。18、用例驅動法：用例是一種場景的文本化表現(xiàn)方式，使用敘述性的文本來描述場景。以用例為核心，圍繞 用例開展活動的軟件開發(fā)方法被稱為用例驅動的軟件開發(fā)方法。19、企業(yè)建模：企業(yè)建模是以使用產(chǎn)品的組織團體為系統(tǒng)的環(huán)境，進行分析。它主要用來理解組織的結構、行 為規(guī)則、目標、重要成員的任務與職責、操縱的數(shù)據(jù)等。企業(yè)建模利用企業(yè)的目標、任務、策略、資源等來刻畫組 織的行為，并依此來發(fā)現(xiàn)組織開發(fā)系統(tǒng)的目的，建立系統(tǒng)的業(yè)務需求20、過程建模：過程建模是結構化分析方法的典型技術。過程建模將系統(tǒng)看做是過程的集合，其中一些由人來 執(zhí)行，另一些由軟件系統(tǒng)來執(zhí)行。過程建模使用的主要技術有上下文圖、數(shù)據(jù)流圖、微規(guī)

2、格說明和數(shù)據(jù)字典等21、上下文圖：上下文圖是DFD最高層次的圖，是系統(tǒng)功能的最高抽象，它將整個系統(tǒng)看做是一個過程，這個 過程實現(xiàn)系統(tǒng)的所有功能。上下文圖中存在且僅存在一個過程，表示整個系統(tǒng)。這個單一的過程通常編號為）。26、交互圖（行為模型）：交互圖用于描述在特定上下文環(huán)境中一組對象的交互行為，該上下文環(huán)境就是被 實現(xiàn)用例的某個場景。所以，交互圖通常描述的是單個用例的典型場景。交互圖中的每一個交互都描述了環(huán)境中的 對象為了實現(xiàn)某個目標而執(zhí)行的一系列消息交換28、基線：基線是已經(jīng)通過正式評審和批準的規(guī)格說明或產(chǎn)品，可以作為進一步開發(fā)的基礎，并且只有通過正 式的變更控制過程才能修改它。29、需求基

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

4、需求而提供的解決方案，規(guī)定了解系統(tǒng)的行為特征。用戶需求：就是執(zhí)行實際工作的用戶，對系統(tǒng)所能完成的具體任務的期虱描述了系統(tǒng)能夠幫助用戶做什么。涉眾:軟件系統(tǒng)的涉眾可以定義為:所有能夠影響軟件系統(tǒng)的實現(xiàn)，或者會被實現(xiàn)后的軟件所影響的個人和團體。文檔審查：是一種傳統(tǒng)的需求獲取方法，是針對文檔進行的需求獲取活動用例：在系統(tǒng)和外部對象的交互當中所執(zhí)行的行為序列的描述，包括各種不同的序列和錯誤的序列，它們能夠聯(lián) 合提供一種有價值的服務10撤規(guī)格說明：是一種被用來描述過程處理邏輯的技術，主要有三種：a.結構化英語b.行為圖c-決策表/樹11.交互圖：交互圖是用于描述在特定上下文環(huán)境中的一組對象的交互行為，該

5、上下文環(huán)境就是被實現(xiàn)用例的某個 場景四、名詞解釋題1、需求工程：需求工程是軟件工程的一個分支，它關注于軟件系統(tǒng)所應予實現(xiàn)的現(xiàn)實世界目標、軟件系統(tǒng)的功 能和軟件系統(tǒng)應當遵守的約束，同時它也關注以上因素和準確的軟件行為規(guī)格說明之間的聯(lián)系，關注以上因素與其 隨時間或跨產(chǎn)品族而演化之后的相關因素之間的聯(lián)系。需求：需求是用戶對問題域中的實體狀態(tài)或事件的期望描述。2、需求：IEEE對需求的定義為：標準、規(guī)范或其他正式文檔所規(guī)定的要求而需要具備的條件或能力。用戶為了解決問題或達到某些目標所需要的條件或能力系統(tǒng)或系統(tǒng)部件為了滿足合同 對或中的一條件或一種能力的一種文檔化表述。3、需求分析：需求分析是利用建模與

6、分析技術對獲取筆錄的內容進行明確、整理、匯總，建立一個綜合考慮問 題域特性和需求的系統(tǒng)模型，然后根據(jù)系統(tǒng)模型將用戶需求轉化為系統(tǒng)需求的需求工程活動。4、前景（Vision）:前景描述了產(chǎn)品的作用以及最終的功能，它將所有涉眾都統(tǒng)一到一個方向上5、范圍（scope）:范圍指出當前項目是要解決產(chǎn)品長遠規(guī)劃中的哪一部分，范圍聲明它為項目劃定了需求的界 線。7、硬數(shù)據(jù)：表格和文檔資料是用戶對實際業(yè)務進行加工和抽象之后的結果，是一種精化過的知識。這些文檔資 料被稱為硬數(shù)據(jù)。硬數(shù)據(jù)分為定量硬數(shù)據(jù)和定性硬數(shù)據(jù)兩種類型8、結構化面談：結構化面談指在面談的過程中，會見者會完全按照事先的問題和結構來控制面談。結構化

7、面談 通常被用來獲取一些比較確定或者選擇空間比較有限的信息，一些統(tǒng)計性傾向信息的獲取也可以使用結構化面談y L rnj 女9、半結構化面談：半結構化面談指在面談的過程中，事先需要根據(jù)面談內容準備面談的問題和面談結構。但在 面談過程中，會見者可以根據(jù)實際情況采取一些靈活的策略。半結構化面談是在需求獲取中應用最多的一種面談類 型，能夠處理大部分的需求獲取任務。10、非結構化面談：在非結構化面談的過程中，沒有事先預定的議程安排。在比較極端的情況下，會見者甚至 會在沒有太多事前準備的情況下就直接到訪被會見者的工作地，就某個主題開展會談11、頭腦風暴（Brainstorming）:是一種特殊的群體面談方

8、式，它的目的不是發(fā)現(xiàn)需求，而是“發(fā)明”需求，或者 說是發(fā)現(xiàn)“潛在”需求。它鼓勵參與者在無約束的環(huán)境下進行某些問題的自由思考和自由討論，以產(chǎn)生新的想法。它 是需求獲取中用于“發(fā)明”需求的方法，但它會增加需求的數(shù)量。12、原型：原型是一個系統(tǒng)，它內化了（Capture）一個更遲系統(tǒng)（Later System）的本質特征。原型系統(tǒng)通常 被構造為不完整的系統(tǒng)，以在將來進行改進、補充或者替代。”13、嚴格意義上的原型：嚴格意義上的原型主要被用在需求分析階段，是開發(fā)者在建立系統(tǒng)信息模型的同時建 立的原型，通常被用來闡明用戶界面或者系統(tǒng)功能的某些特定方面，幫助人們及時地澄清問題。14、場景：場景是對系統(tǒng)和環(huán)

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

10、據(jù)的分析可以揭示被研究社會的社會結構、組織方法和具體活動17、模型驅動法：模型驅動法是一類以定義明確的模型為理論基礎，依據(jù)模型指導和組織活動開展的需求工程五、問答題1、簡述需求工程的主要任務。答：需求工程有以下三個主要任務：需求工程必須說明軟件系統(tǒng)將被應用的環(huán)境及其目標，說明用來達成這些目標的軟件功能，還要說明在設計 和實現(xiàn)這些功能時上下文環(huán)境對軟件完成任務所用方式、方法所施加的限制和約束，也即要同時說明軟件需要“做 什么和“為什么需要做。需求工程必須將目標、功能和約束反映到軟件系統(tǒng)中，映射為可行的軟件行為，并對軟件行為進行準確的規(guī) 格說明。需求規(guī)格說明是需求工程最為重要的成果，是項目規(guī)劃、設

11、計、測試、用戶手冊編寫等很多后繼軟件開發(fā) 階段的工作基礎?，F(xiàn)實世界是不斷變化的世界，因此需求工程還需要妥善處理目標、功能和約束隨著時間的演化情況。同時， 為了節(jié)省開支和進行需求規(guī)格說明的重用，需求工程還需要對目標、功能和約束在軟件產(chǎn)品族中的演化和分布情況 進行綜合考慮與處理。2、簡述常見的需求定義錯誤。答:需求并沒有反映用戶的真實需要。模糊和歧義的需求。信息潰漏。不必要的需求。不切實際的期望。3、簡要說明需求獲取活動的過程。答:(1)收集和應用背景資料，建立初始的知識框架。分析涉眾的高層次問題，總結出系統(tǒng)的業(yè)務需求。設計一個高層次的解決方案，并確定解決方案需要具備的系統(tǒng)特性。高層次的解決方案和

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

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

14、熱，可以采用金字塔結構，通過逐步的引導使被 會見者進入討論。在被動的情況下，如果會見者發(fā)現(xiàn)自己事先對事實的確認存在較大偏差或者被會見者看上去不情愿討論某個話 題，也可以采用金字塔結構。在某個話題討論結束的時候，使用金字塔結構的提問順序也是有用的。(2 )漏斗結構在這種結構中，會見者使用演繹的方法，以一般的、開放式的問題開始，然后用封閉式的問題縮小可能的答復。 這種面談結構可看做是漏斗型。在主動的情況下，漏斗結構為開始一場面談提供了一種容易而輕松的途徑。答復者即使答錯了開放式問題，也 不會感到壓力。在被動的情況下，當被會見者對話題有情緒，并且需要自由表達這些情緒的時候，需要采用漏斗型提問順序。

15、或者在會見者事先對事實了解不多時，也應該采用漏斗結構的問題組織方式。(3 )菱形結構人們在面談中常常會將上述兩種結構結合起來使用，其中菱形結構就是一種最好的結合結果。這種結構以一種 非常明確的方式開始，然后考察一般問題，最后得出一個非常明確的結論。會見者首先提出一些簡單的、封閉式的問題，為面談過程做好鋪墊。在面談的中間階段，向被會見者提出明顯 沒有“正確答案的一般話題的看法。然后，會見者再次限制問題以獲得明確的答復，這樣就為會見者和被會見者提 供了面談的結束時機。菱形結構結合了其他兩種結構的長處，但是也有缺點，即所花的時間比其他任何一個都長。9、試述在需求獲取中使用原型方法的主要步驟。答：確定

16、原型需求。搞清楚為什么要開發(fā)原型，擁有的起始點是什么，期望的結束標準是什么？原型開發(fā)。依據(jù)原型的需求特點和開發(fā)目的，選擇原型的開發(fā)方法和構建技術，建立初始原型。原型評估。對上一階段產(chǎn)生的原型進行評估，根據(jù)評估者的反饋判斷原型是否滿足結束標準。評估者一般是用戶 和開發(fā)者。原型修正。如果已經(jīng)建立的原型達到了目的，就結束原型方法過程。否則根據(jù)評估者反饋的不足進行原型調整， 調整完成后準備再次進行原型評估。使用漏斗結構的一個好處是：用這種方式組織面談能得出很多的詳細信息，以至于沒有必要使用長序列的封閉 式問題。8、試比較原型開發(fā)方法的三種類型。答:（1）探索式探索式原型法是以缺陷需求開始繼而不斷調整和

17、修正需求的原型開發(fā)方式。（2）實驗式（3）演化式在演化式的原型方法中，原型的開發(fā)并不是一個獨立的活動，而是整個項目的持續(xù)開發(fā)過程中的一個部分實驗式的原型方法初始時擁有清晰的用戶需求，但是開發(fā)者對這些需求的實現(xiàn)方法、實現(xiàn)效果和可行性沒有太 大的把握。拋棄式原型的貢獻不在于它的代碼,而是它所包含的內容，它說明了正確的需求和正確的技術方室。因為拋棄式原型的代碼是要被拋棄的，所以在建立拋棄式原型時，應該盡量花費最小的代價，爭取最快的速度在探索式、實驗式和演化式這三種原型方法中，前兩種方法產(chǎn)生的原型往往是在經(jīng)歷了很多次錯誤的嘗試之后 才產(chǎn)生的。為此.探索式和實驗式方法產(chǎn)式的原型產(chǎn)品又被稱為拋棄式原型（T

18、hrowaway Prototype）o為此,原型的開發(fā)者會使用一些簡易的開發(fā)T具和不成熟的構誥技術,忽略或簡化一些和原型目標不相關的功能特19、筒述使用DFD描述系統(tǒng)過程模型是必須遵守哪些規(guī)則。答：使用DFD描述系統(tǒng)過程模型是必須遵守一些規(guī)則，這些規(guī)則可以保證過程模型的正確性。這些規(guī)則有：過程是對數(shù)據(jù)的處理，必須有輸入，也必須有輸出，而且輸入數(shù)據(jù)集和輸出數(shù)據(jù)集應該存在差異。如果過程在沒有輸入的情況下產(chǎn)生了輸出，稱之為“奇跡”，即輸出數(shù)據(jù)在沒有任何可見來源的情況下就奇跡般 產(chǎn)生了。如果過程接收了數(shù)據(jù)輸入?yún)s沒有產(chǎn)生輸出，稱之為“黑洞”。它浪費了輸入的數(shù)據(jù)資源，卻沒有做出應有的貢獻 過程是對數(shù)據(jù)的

19、處理，這種處理是要產(chǎn)生附加價值的，即進行了數(shù)據(jù)的加工和變換，而不是簡單的數(shù)據(jù)轉移數(shù)據(jù)流是必須和過程產(chǎn)生關聯(lián)的，它要么是過程的數(shù)據(jù)輸入，要么是過程的數(shù)據(jù)輸出。DFD當中所有的對象都應該有一個可以唯一標識自己的名稱。過程使用動詞，外部實體、數(shù)據(jù)流和數(shù)據(jù)存儲 使用名詞。20、請說明DFDB次結構的建立的主要步驟。答：創(chuàng)建上下文圖。發(fā)現(xiàn)并建立DFD片斷。根據(jù)DFD片斷組合產(chǎn)生0層圖。對0層圖的過程進行功能分解，產(chǎn)生N層圖。21、請說明DFD圖質量評判的準則是什么？答：遵守相應的規(guī)則，沒有語法錯誤具有良好的語義，過程的功能設置要高內聚、低耦合。保持數(shù)據(jù)一致性，過程的輸人流要足以產(chǎn)生數(shù)據(jù)輸出。同時過程的輸

20、出流是在充分利用輸入數(shù)據(jù)的基礎上產(chǎn) 生的，不存在輸入數(shù)據(jù)的浪費。控制復雜度，不要一次在圖中顯示太多的信息。一般情況下，一個圖中的過程數(shù)量最好控制奄9 （人腦的 最佳信息處理量）個。而且圖中的數(shù)據(jù)流數(shù)量越少越好，越簡潔越好（接口最小化） 24、筒述：皿的創(chuàng)建步驟。素。答:從描述信息中辨識實體。從描述信息中尋找系統(tǒng)需要收集和存儲的信息，然后將其建模為實體。尋找時， 可以重點關注描述信息中的名詞，并以系統(tǒng)是否需要收集其相關的特征為依據(jù)來判定是否將其建立為獨立的實體元確定實體的標識符。為每個實體選擇能夠唯一標識實例且比較穩(wěn)定的屬性為標識符添加詳細的描述信息、。在得到一個初步的框架之后,進一步從描述中挖

21、掘信息,為數(shù)據(jù)模型添加詳細的描述 信息，包括實體的詳細屬性和關系的基數(shù)。建立實體之間的關系。從描述信息中辨識實體之間存在的業(yè)務聯(lián)系，描述為獨立的關系元素。并判斷各個關 系的建立是否會產(chǎn)生新的關聯(lián)實體或者影響已有的實體特性25、請說明為什么要編寫需求規(guī)格說明文檔？答：（1）編寫需求規(guī)格說明文檔的必要性：在一個復雜軟件系統(tǒng)的開發(fā)中，編寫需求規(guī)格說明文檔是非常必要的一方面，清晰、明確、結構化的文檔可以將軟件系統(tǒng)的需求信息和解決方案更好的傳遞給所有的開發(fā)者另一方面，文檔可以拓展人們的知識記憶能力。編寫需求規(guī)格說明文檔的他好處：需求規(guī)格說明文檔可以成為各方人員之間有關軟件系統(tǒng)的協(xié)議基準需求規(guī)格說明文檔可

22、以成為項目開發(fā)活動的一個重要依據(jù)目的工作量在需求規(guī)格說明文檔的編寫過程中，可以盡早的發(fā)現(xiàn)和減小可能的需求錯誤,從而減小項目的返T，降低項需求規(guī)格說明文檔可以成為有效的智力資產(chǎn)。為了解決需求獲取普遍存在困難，需求獲取活動至少要做到：a.研究應用背景，建立初始的知識框架b.根據(jù)獲取 的需要，采用必要的獲取方法和技巧c.先行確定獲取的內容和主題，設定場景d.分析用戶的高層目標，理解用戶的 意圖e.進行涉眾分析，針對涉眾的特點開展工作顧客向系統(tǒng)提起查詢請求主要有:a.需求：需求是獲取的主要對象，是系統(tǒng)期望達到的目標b.問題域描述：問題 描述是用來承載和解釋需求的問題域特性，主要是現(xiàn)實世界的業(yè)務運行狀況

23、c.環(huán)境與約束：屬于一種特殊的問題域 特性，限定了解系統(tǒng)部署的環(huán)境和條件必答：無論是需求，問題域描述，還是環(huán)境與約束，它們都要和項目前景保持一致，都要介于項目的范圍之內。涉眾的識別基本過程：3.將初始涉眾集中起來，進行一次頭腦風暴，盡可能的列出一個涉眾類別列表。b.對上一步 產(chǎn)生的涉眾類別列表進行分析，判斷它們和軟件系統(tǒng)的相關性，找出其中關鍵的涉眾類別c.為上一步的各個關鍵涉 眾類別選擇代表，集中起來進行進一步的頭腦風暴，列出行的涉眾類別列表1.如果新列出的涉眾類別列表有了新的 發(fā)現(xiàn)，就提交新的涉眾類別列表，轉向第二步面談結構：a .金字塔結構：會見者以很具體的問題開始，然后逐漸提高問題的開放

24、度，同時允許被會見者用越來 越籠統(tǒng)的答案來回答問題b.漏斗結構：會見者使用演繹的方法，以一般的，開放式的問題開始，然后用封閉式的問 題縮小可能的答復c.菱形結構：以一種非常明確的方式開始，然后考察一般問題，最后得出一個非常明確的結論。 是金字塔和漏斗結構的結合民族志的優(yōu)缺點：/優(yōu)點:a.民族志的最大優(yōu)點就是他能夠得到信息的深度理解b.第二個優(yōu)點是能夠讓真實世界的社會性因素可見化c.通過民族志得到的知識是真實的知識，他可以打破人們已有的一些錯誤假設和錯誤觀念，避免 一些嚴重后果的發(fā)生缺點：a.需要耗費很多時間b.調研結果很難傳遞到開發(fā)過程什么是模型驅動方法：是一類以定義明確的模型為理論基礎，依據(jù)

25、模型指導和組織活動開展的需求工程方法 常見的模型驅動方法有：a.面向目標的方法b.基于場景的方法c.基于用戶的方法面向問題域的分析方法:a.研究所有可能的問題域，從中發(fā)現(xiàn)一些重復出現(xiàn)的簡單的問題類型，這些問題類型背 稱為問題框架b.分析每一種問題框架的特性。確定問題的理解和解決方法c.將問題框架的建立分類系統(tǒng)化，將復雜 的問題簡單化解決需求分析的子活動有：/a.問題分析b.確定系統(tǒng)邊界c.需求建模d.需求細化e.確定需求優(yōu)先級f.需求協(xié)商使用DFD建模需要遵守的規(guī)則：a.過程是對數(shù)據(jù)的處理，必須有輸入和輸出，且輸入數(shù)據(jù)集和輸出數(shù)據(jù)集應該存 在差異b.數(shù)據(jù)流是必須和過程產(chǎn)生關聯(lián)的，要么是過程的數(shù)

26、據(jù)輸入，要么是過程的數(shù)據(jù)輸出c.DFD當中所有的對象 都應該有一個可以唯一標識自己的名稱（一）什么是需求：用戶為解決問題或達到某些目標所需要的條件或能力；系統(tǒng)或系統(tǒng)部件為滿足合同、標準、規(guī) 范或其它正式文檔所規(guī)定的要求而需要具備的條件或能力；對它們的一種文檔化表述。需求的分類：1.功能需求：和系統(tǒng)主要工作相關的需求，即在不考慮物理約束的情況下，用戶希望系統(tǒng)所能夠執(zhí)行 的活動，這些活動可以幫助用戶完成任務。功能需求主要表現(xiàn)為系統(tǒng)和環(huán)境之間的行為交互。2.性能需求：系統(tǒng)整ERD的創(chuàng)建工作步驟：/a.從描述信息中辨識實體b.確定實體的標識符c.建立實體之間的關系d.添加詳細的描述 信息體或系統(tǒng)組成部

27、分應該擁有的性能特征，例如CPU使用率、內存使用率等。3.質量屬性：系統(tǒng)完成工作的質量，即 系統(tǒng)需要在一個“好的程度上實現(xiàn)功能需求，例如可靠性程度、可維護性程度等。4.對外接口 ：系統(tǒng)和環(huán)境中其他 系統(tǒng)之間需要建立的接口，包括硬件接口、軟件接口、數(shù)據(jù)庫接口等等。（二）需求工程：是所有需求處理活動總和，它收集信息、分析問題、整理觀點、記錄需求并驗證其正確性，最終 反映軟件被應用后與其環(huán)境互動形成的期望效應.需求工程的活動包括：需求開發(fā)和需求管理需求開發(fā)包括：1.需求獲取2.需求分析3.需求規(guī)格說明4.需求驗證5.需求管理（三）需求規(guī)格說明：就是將需求及其軟件的解決方案進行定義和文檔化，并傳遞給開

28、發(fā)人員；為什么要建需求規(guī)格說明：1）更好的傳遞軟件系統(tǒng)的需求信息和解決方案給所有的開發(fā)者2）拓展人們的知識記憶能 力：復雜系統(tǒng)信息含量較多書面的文檔可以彌補人的記憶能力不足3）開發(fā)者和客戶作為合同協(xié)議的重要部分;4）作 為項目開發(fā)活動的一個重要依據(jù)；5）發(fā)現(xiàn)和減少可能的需求錯誤，減少項目的返工，降低項目的工作量；6）作為有效 的智力資產(chǎn)，可以幫助新加入成員更快融入項目需求規(guī)格說明文檔常見讀者：項目管理者2）設計人員與程序員3）測試人員4）文檔寫作人員5）涉眾（用戶）（四）需求管理：就是這樣一個管理活動，在需求開發(fā)之后的產(chǎn)品生命周期當中保證需求作用的有效發(fā)揮；需求管理的主要任務有：1）交流涉眾需

29、要什么；2）將需求應用、實施到解決方案；3）驅動設計和實現(xiàn)工作；4） 控制變更；5）將需求分配到子系統(tǒng)；6）測試和驗證最終產(chǎn)品；7）控制迭代式開發(fā)中的變化；8）輔助項目管理； 需求管理的3個活動：1）維護需求基線：將需求基線納入配置管理2）實現(xiàn)需求跟蹤：以軟件需求規(guī)格說明文檔為基 線，在前向和后向兩個方向上，描述需求以及跟蹤需求變化的能力3）控制需求變更以可控、一致的方式進行需求基 線中需求的變更處理 需求分析的根本任務：1.建立分析模型2.建立解決方案 需要執(zhí)行活動：1.問題分析2.確定系統(tǒng)邊界3.需求建模4.需求細化5.確定需求優(yōu)先級6.需求協(xié)商（五）需求驗證：是專指在需求規(guī)格說明完成之后

30、，對需求規(guī)格說明文檔進行的驗證活動。常用的方法：需求評審、原型與模擬、測試用例開發(fā)、用戶手冊編寫、利用跟蹤關系和自動化分析 問題修正方法：1）需求澄清：理解偏差：重新進行分析工作；分析遺漏：重新分析和文檔化這部分信息；表達不當：重新以合適 的方式表達2.缺失需求：重新執(zhí)行需求獲取等一系列工作3.需求沖突：協(xié)商解決4）不切實際的期望：項目調整與需 求協(xié)商（六）需求跟蹤：以軟件需求規(guī)格說明文檔為基線，在前向和后向兩個方向上，描述需求以及跟蹤需求變化的能力 前向跟蹤1=1=、:是指被定義到軟件需求規(guī)格說明文檔之前的需求演化過程為什么要執(zhí)行需求管理：在需求開發(fā)結束之后，需要有一種力量保證后續(xù)的系統(tǒng)開發(fā)

31、活動依照需求的基線進行展開， 保證系統(tǒng)的質量；后向跟蹤:是指被定義到軟件需求規(guī)格說明文檔之后的需求演化過程需求跟蹤的實現(xiàn)方法主要有哪3種：1.需求跟蹤矩陣2.實體關系模型3.交叉引用（七）需求變更控制的過程如下：提出需求變更2.接受變更請求3.變更評估4.變更決策5.執(zhí)行變更6.變更驗證（八）前景：描述了產(chǎn)品的作用以及最終的功能；范圍：為項目劃定了需求的界限；確定項目前景與范圍的流程：1.問題分析2.發(fā)現(xiàn)業(yè)務需求3.定義解決方案及系統(tǒng)特性（九）硬數(shù)據(jù)：人們在實際工作中產(chǎn)生的各種各樣的表格和文檔資料；常見硬數(shù)據(jù)分為定量硬數(shù)據(jù)和定性硬數(shù)據(jù)兩種類型；1.定量硬數(shù)據(jù):指經(jīng)過仔細設計、具有嚴格規(guī)范要求的

32、格式化文 檔；2.定性硬數(shù)據(jù)：使用自然語言進行描述的文本資料（十）1.金字塔組織形式：會見者以很具體的問題開始，然后逐漸提高問題的開放度，同時允許被會見者越來越籠 統(tǒng)的答案來回答問題；斗型；3.菱形結構：就是將上述2中方法集合起來使用；該結構會見者首先提出一些簡單、封閉式的問題，為面談過程做 好鋪墊；在面談中間階段向被會見者提出明顯沒有“正確答案的一般話題看法；然后會見者再次限制問題以獲得明 確答復；漏斗結構：以一般、開放式的問題開始，然后采用封閉式的問題縮小可能的答復；這種面談結構可以看作一個漏（十一）面向對象建模：是一種用于辨識系統(tǒng)環(huán)境中的對象及這些對象之間關系的技術;UML面向對象建模中

33、用到哪些技術：1.對象模型2.用例模型3.行為模型4.狀態(tài)機模型5.對象約束語言OCL用例模型：就是以用例為基本單位建立的一個系統(tǒng)功能展示模型，它是系統(tǒng)所有用例的集合，以統(tǒng)一、圖形化方 式展示系統(tǒng)的功能和行為特性；行為模型：是實現(xiàn)用例模型到對象模型的橋梁，以更加詳細的方式說明了用例所描述的系統(tǒng)行為；對象模型：以對象和類的概念為基礎，描述了系統(tǒng)中的對象和這些對象之間的關系；三者關系：對象模型無法直接被用來記錄和描述從用戶那里得到的信息。因此，面向對象建模方法提出了用例模型， 用來處理開發(fā)人員直接從用戶那里得到的信息，行為模型就是實現(xiàn)用例模型到對象模型的橋梁狀態(tài)機模型：以狀態(tài)機理論為基礎建立的對系統(tǒng)行為的描述手段；描述系統(tǒng)的各個方面；（十二）過程建模：就是分析需求獲取活動獲得的信息，根據(jù)數(shù)據(jù)在系統(tǒng)中的流動，發(fā)現(xiàn)系統(tǒng)的功能和其與外界的 交互，建立能夠實現(xiàn)系統(tǒng)功能的過程分解結構，形成系統(tǒng)的過程模型，并用圖行的方式將過程模型描述出