CMMI3 PA之需求開發(fā)過程域(RD)解釋和實施指南

CMM的時候，是沒有需求開發(fā)這個PA的，需求開發(fā)和需求管理有什么區(qū)別呢？

需求管理強(qiáng)調(diào)的是管理項目產(chǎn)品及產(chǎn)品組件的需求，并界定這些需求與項目計劃及工作產(chǎn)品間的差異,強(qiáng)調(diào)的是需求與項目計劃及工作產(chǎn)品之間的一致性。而需求開發(fā)講究的是用系統(tǒng)的方法識別和獲取真正的全面的能實現(xiàn)的需求，產(chǎn)出并分析客戶、產(chǎn)品及產(chǎn)品組件的需求。

CMMI和CMM相比，增加了很多專門針對軟件工程的PA，其中需求開發(fā)(RD)就是其中之一。需求開發(fā)這個PA，從很高的層次描述了如何做好需求開發(fā)。要理解好本PA，需要先理解清楚以下幾個關(guān)鍵的概念：

1)客戶需求(Customer Requirements)

2)產(chǎn)品需求(Product Requirements)

3)產(chǎn)品組件需求(Product Component Requirements)

客戶需求（需要什么、期望什么、限制什么、外部接口是什麼等）是可以理解成客戶為什么要做本系統(tǒng)，要解決什么問題，客戶對系統(tǒng)有怎樣的期望，希望能具備一些怎樣的特點，簡單的說，就是客戶的需要是什么。一般表現(xiàn)為系統(tǒng)功能、性能、界面等要求；

產(chǎn)品需求是能滿足客戶需求，并對軟件產(chǎn)品規(guī)格進(jìn)行了詳細(xì)描述的需求，產(chǎn)品派生需求（如法規(guī)、習(xí)慣性做法、性能需求等），在產(chǎn)品需求的開發(fā)時增加上去；軟件設(shè)計師可以根據(jù)產(chǎn)品需求進(jìn)行設(shè)計、編碼等工作。

產(chǎn)品組件需求，是對產(chǎn)品需求的進(jìn)一步細(xì)化，產(chǎn)品可能會分割成幾個子系統(tǒng)、幾個部分，每個子系統(tǒng)每部分要具備怎樣的功能、要具備怎樣的性能、接口及界面要求、數(shù)據(jù)庫等，這些可以認(rèn)為是產(chǎn)品組件需求。分配需求（為每個產(chǎn)品組件分配需求）依賴于設(shè)計（技術(shù)解決方案），功能需求是軟件實現(xiàn)、還是硬件實現(xiàn)，是分配到產(chǎn)品組件的硬件還是軟件，如手機(jī)產(chǎn)品撥打電話的功能需求，是通過觸摸屏和軟體實現(xiàn)，還是通過手機(jī)按鍵（硬件）的方式實現(xiàn)，所以產(chǎn)品組件的需求是依賴與設(shè)計（技術(shù)解決方案）；有分配產(chǎn)品組件需求就有接口需求（內(nèi)部和外部接口等），有模塊和組件，就有接口與界面、數(shù)據(jù)庫等；

從另外一個角度，需求可以分為功能性需求和非功能性需求兩類，功能性需求就是系統(tǒng)具備怎樣的功能，能做什么事情，而非功能性需求就是指系統(tǒng)要具備怎樣的性能、安全級別等方面的要求?？蛻粜枨?、產(chǎn)品需求和產(chǎn)品組件需求，都會包含功能需求和非功能需求。

以“短信訂餐系統(tǒng)”為例，其實這個系統(tǒng)，客戶需求很簡單，就是要解決部分員工不方便訂餐的問題。我們看到，如果我們沒有抓住這個客戶需求，一開始就認(rèn)為非要做一個短訊系統(tǒng)，那么就會陷入例子的陷阱中。要解決這個客戶需求，辦法之一就是做短訊訂餐系統(tǒng)，但更合適的辦法可能就是打電話回公司讓別人代訂午飯了。我們很多需求開發(fā)沒有做好的原因，大部分是沒有把握好客戶需求，直接進(jìn)入軟件的細(xì)節(jié)，去討論要做什么功能，界面要怎樣設(shè)計去了，而忘記了軟件的根本目的是為了解決什么問題。

當(dāng)我們明確客戶需求后，就應(yīng)該把客戶需求轉(zhuǎn)變成產(chǎn)品需求和產(chǎn)品組件需求，客戶需求一般都是比較高層次的，而且描述也會比較簡單，我們需要對軟件的規(guī)格進(jìn)行詳細(xì)說明。一般來說，我們寫的軟件規(guī)格說明書都會包含產(chǎn)品需求和產(chǎn)品組件需求的。我們導(dǎo)出產(chǎn)品需求和產(chǎn)品組件需求的時候，要注意產(chǎn)品需求和產(chǎn)品組件需求，必須和客戶需求對應(yīng)起來，通常是多對多的關(guān)系。為什么要對應(yīng)起來？我們要保證，軟件的每一個界面，每一個功能都是有用的，都是“源自”客戶需求的，這樣才能保證我們做的事情都是正確的事情，防止被不相干的事情干擾。

我們經(jīng)常抱怨客戶的需求在變，其實80%的原因是沒有把握住客戶需求，其實客戶經(jīng)常變的是產(chǎn)品需求或者是產(chǎn)品組件需求，客戶需求是很少變的，就是因為我們沒有把握住客戶到底想要什么、需要什么，導(dǎo)致我們認(rèn)為客戶太難“服侍”了。只有把握住客戶真正的需求，我們才能抓住根本，萬變不離其中。

需求開發(fā)的方法：

1.面向結(jié)構(gòu)開發(fā)法，結(jié)合獲取的《用戶需求說明書》，可采用數(shù)據(jù)流圖等分析模型，把系統(tǒng)功能需求、非功能需求按事件流、數(shù)據(jù)流分析方式，逐層細(xì)化到系統(tǒng)操作及操作數(shù)據(jù)的存儲方式，如數(shù)據(jù)的輸入、輸出，并考慮外部接口。結(jié)合數(shù)據(jù)流圖和數(shù)據(jù)字典,詳細(xì)說明系統(tǒng)功能間的輸入、輸出、系統(tǒng)活動及約束條件 ,編制需求規(guī)格說明書。

2.面向?qū)ο箝_發(fā)法，使用UML輔助類圖或其他分析方式來分析已獲取的系統(tǒng)需求、用例模型、類圖、數(shù)據(jù)字典等。結(jié)合圖形化分析模型、類圖、順序圖、關(guān)聯(lián)圖等進(jìn)行說明，準(zhǔn)確描述用戶及系統(tǒng)的交互活動，編制需求規(guī)格說明書。

3.快速原型開發(fā)法，分析已獲取的用戶需求，增量、迭代地明確用戶工作流程、約束條件等，設(shè)定需求的優(yōu)先級排序，在風(fēng)險較小的基礎(chǔ)上分析、設(shè)計和實現(xiàn)系統(tǒng)構(gòu)架結(jié)構(gòu)或用戶界面架構(gòu)。結(jié)合立項時所選用生命周期，迭代進(jìn)行分析活動，編制需求規(guī)格說明書。

需求開發(fā)包含的元素：

1.基于場景的元素——用戶角度表現(xiàn)系統(tǒng)

用例文本、用例圖、活動圖、泳道圖——帶角色的活動圖等

2.面向信息流的元素——通過處理函數(shù)進(jìn)行轉(zhuǎn)換

數(shù)據(jù)流圖、控制流圖、處理說明等

接著下來，我們將從每個SG和每個SP來詳細(xì)講解需求開發(fā)這個PA

RD有三個SG，SG1開發(fā)客戶需求，SG2開發(fā)產(chǎn)品需求，SG3分析和確認(rèn)需求。

前兩個SG講述的是需求開發(fā)由頂而下、由粗到細(xì)的過程，SG3講述的是需求分析和確認(rèn)的過程。下面詳細(xì)闡述：

SG1: 開發(fā)客戶需求

開發(fā)客戶需求：干系人的需要、期望、約束和接口要求被收集，對其加以和解釋并轉(zhuǎn)化為客戶需求。

SP 1.1:引導(dǎo)需求

引導(dǎo)需求：導(dǎo)出干系人對整個產(chǎn)品生命周期各階段的需要和期望（客戶需求、需求規(guī)格說明書、設(shè)計文檔）、約束（前提條件如C語言、100天、開發(fā)人員掌握的技術(shù)、面向?qū)ο箝_發(fā)還是結(jié)構(gòu)化開發(fā)等）和接口要求等。這句話要包含了幾個要點：

 1)干系人（利益關(guān)系人）：干系人除了指甲方的領(lǐng)導(dǎo)、系統(tǒng)的最終用戶，還包括使用本系統(tǒng)的第三方以及與本系統(tǒng)有交互的第三方系統(tǒng)的擁有者、使用者、供應(yīng)商、測試人員、制造人員，與后勤支持人員等，干系人需求是決定客戶需求的重要的基礎(chǔ)等。

2)產(chǎn)品生命周期各階段：干系人對系統(tǒng)的期望不一定只限于軟件功能的，可能還包括數(shù)據(jù)的整理、資料錄入、安裝培訓(xùn)、維護(hù)要求等，干系人可能對軟件生產(chǎn)的過程階段（整個生命周期）都會提出他的要求，獲取需求的時候，要注意干系人在軟件生命周期不同階段有什么要求。

3)需要、期望、約束、接口要求：甲方一般會對系統(tǒng)的目標(biāo)、范圍、解決什么問題、希望系統(tǒng)具備怎樣的一些特性，滿足一些什么接口要求和約束條件等，都會有大致的想法。需求調(diào)研工作，首先要注意搞清楚這些內(nèi)容。

4)導(dǎo)出：客戶的原始想法可能是不明確的，或者是客戶一時難表達(dá)完整的，我們需要用一定的方法，讓客戶能完整無遺漏準(zhǔn)確地表達(dá)出他的想法。通常我們可以通過原型、圖示、類比、問卷等辦法來導(dǎo)出客戶的需求。

SP 1.2: 開發(fā)客戶需求

開發(fā)客戶需求：轉(zhuǎn)化干系人的需要、期望、約束和接口要求為客戶需求。

SP1.1講述的是通過一些方法獲取和記錄客戶和干系人原始的需求信息，而SP1.2講述的就是把客戶和干系人原始的需求信息整理成正式的客戶需求，通常會包括對系統(tǒng)目標(biāo)、范圍、解決問題、軟件特性、接口要求、驗證和確認(rèn)要求等有詳細(xì)的描述。

來自客戶和干系人的各種輸入和需求信息，須經(jīng)合并和檢查是否有遺漏的需求信息，以及解決沖突（如客戶的需求和其他干系人的需求之間，或客戶的需求與需求之間沖突，如客戶要求的功能需求與進(jìn)度、成本矛盾的等）等過程，解決后并記錄為客戶需求，所以在沖突適當(dāng)解決之后，需要轉(zhuǎn)換成被認(rèn)可的客戶需求?？蛻粜枨罂砂ㄅc驗證和確認(rèn)有關(guān)的需要、期望及限制。

客戶需求與其他干系人的需要、期望、限制及接口可能有所沖突， 沖突的解決過程可能需要客戶和其他干系人參與；

代表產(chǎn)品生命周期的所有階段的相關(guān)干系人，應(yīng)包括經(jīng)營方面及技術(shù)功能方面的代表。因此，所有與產(chǎn)品生命周期相關(guān)的過程概念，都應(yīng)與產(chǎn)品的概念同步考?。

客戶需求來自信息充分的決策，同時考?需求在經(jīng)營面與技術(shù)面的影響。也就是說客戶和其他干系人需求要不單要考慮技術(shù)面需求（如產(chǎn)品的功能、性能需求等），也要考慮經(jīng)營面需求（如公司的經(jīng)營策略和經(jīng)營計劃等，如公司定價策略影響項目對成本控制的策略和需求等）

SG2: 開發(fā)產(chǎn)品需求

開發(fā)產(chǎn)品需求：對客戶需求加以精煉和細(xì)化，以用來開發(fā)產(chǎn)品需求和產(chǎn)品組件需求。

SG1講述的是導(dǎo)出客戶需求，而SG2講述的是由客戶需求到產(chǎn)品需求、產(chǎn)品組件需求的過程。

分析客戶需求并開發(fā)操作概念，以衍生更詳細(xì)和精準(zhǔn)的需求，此需求稱為“產(chǎn)品與產(chǎn)品組件需求”?！爱a(chǎn)品與產(chǎn)品組件需求”說明產(chǎn)品生命周期每一階段的相關(guān)需要。衍生需求或派生需求（法規(guī)、習(xí)慣性做法、性能需求），是由限制、對某些隱含議題的考?及某些因素而間接產(chǎn)生，這些議題在客戶需求中并未明確說明；而這些因素是基于所選用的架構(gòu)、設(shè)計，以及開發(fā)者獨特的經(jīng)營考?等而產(chǎn)生。需求須以后續(xù)的、較低階的需求及功能架構(gòu)再檢查，并細(xì)化優(yōu)先的產(chǎn)品概念。

配置需求于產(chǎn)品功能及產(chǎn)品組件，包括對象、人員及過程，并記錄需求到功能、對象、測試、議題，或其他實體的追溯性。已配置的需求及功能是組成技術(shù)解決方案的基礎(chǔ)。當(dāng)開發(fā)內(nèi)部組件時，須定義新增的接口，并建立接口需求。

SP 2.1: 建立和維護(hù)產(chǎn)品或組件需求

建立和維護(hù)產(chǎn)品和產(chǎn)品組件需求，這些產(chǎn)品和產(chǎn)品組件需求是基于客戶需求的。

簡單說，就是要滿足客戶要求，產(chǎn)品和產(chǎn)品組件應(yīng)該有哪些需求；

產(chǎn)品和產(chǎn)品組件需求，是比較細(xì)致的需求，會詳細(xì)描述軟件與用戶是怎樣交互的，用戶需要輸入什么，系統(tǒng)會輸出什么等都會比較詳細(xì)描述出來。而客戶需求一般只描述能實現(xiàn)什么功能、解決什么問題等，比較高層次。客戶需求一般在系統(tǒng)實際的使用環(huán)境下或模擬的使用環(huán)境可以確認(rèn)是否實現(xiàn)和滿足要求，而產(chǎn)品需求和產(chǎn)品組件需求是對軟件規(guī)格的描述，是可以用來做為驗證的標(biāo)準(zhǔn)的。客戶需求對應(yīng)驗收測試用例，產(chǎn)品需求規(guī)格說明書對應(yīng)系統(tǒng)測試用例。

客戶需求可能以客戶術(shù)語表示，且以較不具有技術(shù)的方式描述。產(chǎn)品需求則是以專業(yè)術(shù)語表示這些客戶需求，以方便用來進(jìn)行后續(xù)的設(shè)計的決策?！百|(zhì)量機(jī)能展開”是此轉(zhuǎn)換的范例，它描述客戶期望與技術(shù)參數(shù)（產(chǎn)品和產(chǎn)品組件質(zhì)量和性能、功能等）的對應(yīng)關(guān)系。例如：“結(jié)實的門”可能對應(yīng)到尺寸規(guī)模大小、重?、適合、濕度及共振頻率。針對所需的重要的產(chǎn)品和產(chǎn)品組件所需質(zhì)量和性能、功能，開發(fā)架構(gòu)需求?！爱a(chǎn)品與產(chǎn)品組件需求”強(qiáng)調(diào)客戶、經(jīng)營，以及項目目標(biāo)和相關(guān)屬性(如有效性和負(fù)擔(dān)能力)的滿足。

根據(jù)設(shè)計決策結(jié)果派生出需求（法規(guī)、習(xí)慣性做法、性能需求），派生（衍生）需求也包括其他生命周期階段的成本和績效 (如生產(chǎn)、操作及銷毀)，以與經(jīng)營目標(biāo)兼容（如設(shè)計提高復(fù)用，提高產(chǎn)品質(zhì)量和生產(chǎn)率）。

建立并維護(hù)需求間的關(guān)連性，并考?在變更管理和需求配置時的影響。有關(guān)維護(hù)需求追溯，請參考需求管理過程域，以獲得更多信息。需求間的關(guān)連有助于評估變更的影響。

SP 2.2: 配置或分配產(chǎn)品組件需求

分配產(chǎn)品組件需求。

這個SP將需求開發(fā)與技術(shù)解決方案聯(lián)系起來，所有的需求應(yīng)該與設(shè)計的產(chǎn)品組件對應(yīng)起來，保證需求驅(qū)動后續(xù)的設(shè)計工作，同時也保證設(shè)計都是為了需求服務(wù)的。SP2.2是對SP2.1的進(jìn)一步細(xì)化。

分配需求（為每個產(chǎn)品組件分配需求）依賴于設(shè)計（技術(shù)解決方案），功能需求是軟件實現(xiàn)、還是硬件實現(xiàn)，是分配到產(chǎn)品組件的硬件還是軟件，如手機(jī)產(chǎn)品撥打電話的功能需求，是通過觸摸屏和軟體實現(xiàn)，還是通過手機(jī)按鍵（硬件）的方式實現(xiàn)，所以產(chǎn)品組件的需求是依賴與設(shè)計（技術(shù)解決方案）；有分配產(chǎn)品組件需求就有接口需求（內(nèi)部和外部接口等），有模塊和組件，就有接口與界面、數(shù)據(jù)庫等；

SP 2.3: 識別和定義接口需求

識別和定義接口需求。接口需求包括系統(tǒng)與第三方的系統(tǒng)的接口要求，也包括系統(tǒng)本身各組件、各子系統(tǒng)、各部分之間的接口要求。通常這些接口需求在客戶需求級別的時候，并不是很明細(xì)，需要對客戶需求進(jìn)一步細(xì)分成產(chǎn)品需求、產(chǎn)品組件需求，然后發(fā)掘出接口需求。SP2.3也是對SP2.1的進(jìn)一步深化。

SG3: 分析和確認(rèn)需求

分析和確認(rèn)需求：需求被分析和確認(rèn)，并定義出具體的功能性需求。

分配需求后；建立操作概念和場景；建立工作流（流程）；建立功能性定義、分析需求（有些技術(shù)難度高，有些技術(shù)難度低，成本分析，進(jìn)度，風(fēng)險，達(dá)成一致，）加一些約束；達(dá)成一致后；做不到的需求需要刪除一些需求后，需求平衡好后，才與客戶承諾及確認(rèn)；確認(rèn)的方式：通過示范、演示、原型等方式來評審需求，以保證最終產(chǎn)品將會在用戶環(huán)境中按照預(yù)期運行；

「分析并確認(rèn)需求」特定目標(biāo)的特定執(zhí)行方法，支持「開發(fā)客戶需求」和「開發(fā)產(chǎn)品需求」兩個特定目標(biāo)的需求開發(fā)過程。本特定目標(biāo)的特定執(zhí)行方法涵蓋需求的分析，以及確認(rèn)需求是否符合使用者預(yù)期。

執(zhí)行分析，以決定為求滿足客戶和干系人的需要、期望、限制及接口，對原計劃的操作環(huán)境會產(chǎn)生哪些影響。視產(chǎn)品的范圍而定，可行性、任務(wù)需要、經(jīng)費限制、市場潛力及采購策略等都必須納入考?，并建立必要功能的定義。所有產(chǎn)品的特定使用形式均應(yīng)考?，并產(chǎn)生對時間敏感的功能順序的時間點分析。

分析的目的，在于決定可滿足客戶和干系人需要、期望及限制的產(chǎn)品概念的可能需求，再將這些概念轉(zhuǎn)換為需求。與此活動同時進(jìn)行的是，依據(jù)客戶的輸入和初步的產(chǎn)品概念，決定用以評估產(chǎn)品有效性的參數(shù)。

確認(rèn)需求，以增加最終產(chǎn)品在使用環(huán)境中，可按照期望運作的可能性。

SP 3.1: 建立和維護(hù)操作概念及相關(guān)場景.

建立和維護(hù)操作概念及相關(guān)場景。

一般會產(chǎn)生如下工作產(chǎn)品：操作概念描述，產(chǎn)品或產(chǎn)品組件安裝、操作、維護(hù)和支持概念性描述，部署概念，用例，時間表場景，新需求等?？梢酝ㄟ^如下幾步完成該實踐：一是開發(fā)操作概念和場景，包括適當(dāng)?shù)墓δ?、性能、維護(hù)、支持及銷毀和部署在內(nèi)的操作概念及場景。識別并開發(fā)場景，此場景須與客戶及干系人的需要、預(yù)期及限制一致。二是定義產(chǎn)品或產(chǎn)品組件的操作環(huán)境，包括邊界和約束。三是要審查操作概念和場景，以精煉需求并發(fā)現(xiàn)新需求。操作概念和場景的開發(fā)是個反復(fù)的過程。應(yīng)定期舉行審查，以確保其結(jié)果與需求一致。審查可采用逐步審查的形式。四是當(dāng)選擇產(chǎn)品或產(chǎn)品組件時，一經(jīng)選定，就開發(fā)詳細(xì)的操作概念，以定義產(chǎn)品、最終用戶及環(huán)境的互動，并滿足操作、維護(hù)、支持及銷毀和部署的需要。

SP 3.2: 建立和維護(hù)必要的功能定義

建立和維護(hù)必要的功能定義。（分析量化用戶功能需求、分析需求包括產(chǎn)品功能和子功能、需求分類、需求排序和確定優(yōu)先級、分配客戶需求、分配產(chǎn)品功能和性能）

一般會產(chǎn)生如下工作產(chǎn)品：功能框架圖、活動圖和用例，使用服務(wù)或方法標(biāo)識的面向?qū)ο蠓治??？梢酝ㄟ^如下幾步完成該實踐：一是分析和?化最終用戶的功能需求。二是分析需求，以識別邏輯或功能分割(如子功能)。三基于已確定的標(biāo)準(zhǔn)(如類似的功能、性能或耦合性)，將需求分割成群組，使需求分析更容易、更便于聚焦。四是在產(chǎn)品組件開發(fā)的整個過程，考?具有時效性的功能的順序（時間要求敏感或高的功能）。五是分配客戶需求于功能分割、對象、人員或支持組件，以支持解決方案的整合合。六是分配功能及性能需求于功能及子功能。

SP3.1和SP3.2是對需求描述的要求，要求描述出具體需求的操作場景、上下文，具體的操作步驟，對功能的詳細(xì)描述等。通常我們可以通過功能框架圖、UML的Use Case圖或者是序列圖等來表達(dá)這些內(nèi)容。

SP 3.3: 分析需求

分析需求以確認(rèn)需求是必要的和充分的。

一般會產(chǎn)生如下工作產(chǎn)品：需求缺陷報告，用來解決缺陷的需求變更建議，關(guān)鍵需求，技術(shù)性能（或產(chǎn)品有效性評估的參數(shù)）度?指標(biāo)；可以通過如下幾步完成該實踐：

1.分析干系人的需要、期望、限制及外部接口，以移除矛盾或沖突，并把它們根據(jù)相關(guān)主題組合在一起。

2.分析需求，以決定是否滿足更高階需求的目標(biāo)（比如商業(yè)目標(biāo)等都可以稱為更高級別的需求）。

3.分析需求，以確保是完整、可行、可實現(xiàn)及可驗證的。雖然設(shè)計決定某特殊解決方案的可行性，但分析需求可以了解哪些需求會影響后續(xù)的可行性。

4.識別對成本、進(jìn)度、功能、風(fēng)險或性能有重大影響的關(guān)鍵需求。

5.識別需要在開發(fā)過程中跟蹤的技術(shù)性能（或產(chǎn)品有效性評估的參數(shù)）度?，以便于開發(fā)階段時進(jìn)行追蹤。有關(guān)度?的用途，請參考度?與分析過程域，以獲得更多信息。

6.分析操作觀念及場景，以精煉客戶需要、限制及接口，并發(fā)現(xiàn)新需求。此分析可能產(chǎn)生更詳細(xì)的操作觀念及場景，同時也衍生新需求。

SP 3.4: 分析需求以取得平衡

分析需求平衡以平衡干系人的需要和約束。

一般會形成需求相關(guān)風(fēng)險的評估報告；

可以通過如下幾步完成該實踐：

1. 使用經(jīng)驗證的模型、仿真及原型等，以分析干系人的需要和限制間的平衡。.

分析的結(jié)果，可用以降低產(chǎn)品的成本與開發(fā)產(chǎn)品時的風(fēng)險。

2. 執(zhí)行需求及功能架構(gòu)的風(fēng)險評估。有關(guān)執(zhí)行客戶及產(chǎn)品需求和功能架構(gòu)的風(fēng)險評估，請參考風(fēng)險管理過程域，以獲得更多信息。.

3.研究產(chǎn)品生命周期概念，以分析它對需求風(fēng)險的影響或風(fēng)險沖擊。

SP3.3和SP3.4是對需求的準(zhǔn)確性、全面性、可實現(xiàn)性方面的要求，除了要取得全面準(zhǔn)確的需求，還需要平衡約束條件，保證需求在約束條件下是可實現(xiàn)的。

SP 3.5: 確認(rèn)需求

用各種合適的方法確認(rèn)需求，確保最終產(chǎn)品能在用戶的環(huán)境中按照設(shè)想運行。這是需求開發(fā)的最后一步了，需求導(dǎo)出過程中盡管用了很多辦法，但需求確認(rèn)的時候，仍然需要采取辦法確保獲取的需求是符合最終的使用場景要求。

一般會形成分析方法和結(jié)果的紀(jì)錄；

可以通過如下幾步完成該實踐：

1.分析需求以識別最終產(chǎn)品不能于用戶環(huán)境下適當(dāng)運行的風(fēng)險。

2.以產(chǎn)品展示(如，原型、仿真、模型、情境及場景)，以及取得相關(guān)干系人的回饋，尋求需求的充分性和完整性。有關(guān)產(chǎn)品及產(chǎn)品組件的確認(rèn)及確認(rèn)執(zhí)行，請參考確認(rèn)過程域，以獲得更多信息。

3.于設(shè)計成熟時，在需求確認(rèn)環(huán)境的上下文中進(jìn)行評估，以識別確認(rèn)發(fā)現(xiàn)的問題，并發(fā)現(xiàn)未說明的需要和客戶需求。

SP3.3、SP3.4和SP3.5，通常是通過評審的方法來滿足的。