CMMI3 PA之需求開(kāi)發(fā)過(guò)程域(RD)解釋和實(shí)施指南

CMM的時(shí)候，是沒(méi)有需求開(kāi)發(fā)這個(gè)PA的，需求開(kāi)發(fā)和需求管理有什么區(qū)別呢？

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

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

1)客戶(hù)需求(Customer Requirements)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用例文本、用例圖、活動(dòng)圖、泳道圖——帶角色的活動(dòng)圖等

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

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

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

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

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

SG1: 開(kāi)發(fā)客戶(hù)需求

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

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

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

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

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

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

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

SP 1.2: 開(kāi)發(fā)客戶(hù)需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SP 2.3: 識(shí)別和定義接口需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SP 3.3: 分析需求

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

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

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

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

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

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

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

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

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

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

一般會(huì)形成需求相關(guān)風(fēng)險(xiǎn)的評(píng)估報(bào)告；

可以通過(guò)如下幾步完成該實(shí)踐：

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

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

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

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

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

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

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

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

可以通過(guò)如下幾步完成該實(shí)踐：

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

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

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

SP3.3、SP3.4和SP3.5，通常是通過(guò)評(píng)審的方法來(lái)滿足的。