CSI_01_需求開發(fā)及管理過程

1、項目管理體系文件需求開發(fā)與管理過程編 撰 人：TMO審 核 人：批 準 人：批準日期：2010-9-1保密級別：機密文檔版本：北京中軟國際信息技術(shù)有限公司版本歷史日期版本說明作者目 錄 TOC o 1-3 h z u HYPERLINK l _Toc272247916 1.引言 PAGEREF _Toc272247916 h 4 HYPERLINK l _Toc272247917 1.1.目的 PAGEREF _Toc272247917 h 4 HYPERLINK l _Toc272247918 1.2.適用范圍 PAGEREF _Toc272247918 h 4 HYPERLINK l _T

2、oc272247919 1.3.術(shù)語和縮略語 PAGEREF _Toc272247919 h 4 HYPERLINK l _Toc272247920 1.4.相關(guān)文件 PAGEREF _Toc272247920 h 4 HYPERLINK l _Toc272247921 2.角色和職責 PAGEREF _Toc272247921 h 4 HYPERLINK l _Toc272247922 3.入口準則 PAGEREF _Toc272247922 h 5 HYPERLINK l _Toc272247923 4.輸入 PAGEREF _Toc272247923 h 5 HYPERLINK l _T

3、oc272247924 5.流程圖 PAGEREF _Toc272247924 h 6 HYPERLINK l _Toc272247925 6.主要活動 PAGEREF _Toc272247925 h 7 HYPERLINK l _Toc272247926 6.1.需求開發(fā)準備 PAGEREF _Toc272247926 h 7 HYPERLINK l _Toc272247927 6.1.1.明確項目目標和范圍 PAGEREF _Toc272247927 h 8 HYPERLINK l _Toc272247928 6.1.2.識別需求來源 PAGEREF _Toc272247928 h 8 H

4、YPERLINK l _Toc272247929 6.1.3.選擇調(diào)研方法和技術(shù) PAGEREF _Toc272247929 h 8 HYPERLINK l _Toc272247930 6.1.4.制訂需求調(diào)研計劃 PAGEREF _Toc272247930 h 9 HYPERLINK l _Toc272247931 6.1.5.編制需求調(diào)研問卷 PAGEREF _Toc272247931 h 10 HYPERLINK l _Toc272247932 6.2.需求調(diào)研 PAGEREF _Toc272247932 h 10 HYPERLINK l _Toc272247933 6.2.1.進行需求

5、調(diào)研 PAGEREF _Toc272247933 h 10 HYPERLINK l _Toc272247934 6.2.2.編寫用戶需求調(diào)研報告 PAGEREF _Toc272247934 h 11 HYPERLINK l _Toc272247935 6.3.需求分析 PAGEREF _Toc272247935 h 11 HYPERLINK l _Toc272247936 6.3.1.需求分析方法 PAGEREF _Toc272247936 h 12 HYPERLINK l _Toc272247937 6.3.2.功能需求分解 PAGEREF _Toc272247937 h 14 HYPERL

6、INK l _Toc272247938 .標識需求 PAGEREF _Toc272247938 h 14 HYPERLINK l _Toc272247939 6.3.4.定義需求的優(yōu)先級 PAGEREF _Toc272247939 h 15 HYPERLINK l _Toc272247940 6.4.編寫需求規(guī)格說明書 PAGEREF _Toc272247940 h 15 HYPERLINK l _Toc272247941 6.5.評審需求規(guī)格說明書 PAGEREF _Toc272247941 h 16 HYPERLINK l _Toc272247942 6.6.需求確認 PAGEREF _T

7、oc272247942 h 16 HYPERLINK l _Toc272247943 6.6.1.客戶確認 PAGEREF _Toc272247943 h 16 HYPERLINK l _Toc272247944 6.7.需求變更管理 PAGEREF _Toc272247944 h 17 HYPERLINK l _Toc272247945 6.8.需求跟蹤 PAGEREF _Toc272247945 h 17 HYPERLINK l _Toc272247946 6.8.1.建立需求跟蹤矩陣 PAGEREF _Toc272247946 h 17 HYPERLINK l _Toc272247947

8、 6.8.2.需求跟蹤矩陣的維護與使用 PAGEREF _Toc272247947 h 18 HYPERLINK l _Toc272247948 7.出口準則 PAGEREF _Toc272247948 h 18 HYPERLINK l _Toc272247949 8.輸出 PAGEREF _Toc272247949 h 19 HYPERLINK l _Toc272247950 9.引用過程 PAGEREF _Toc272247950 h 19引言目的規(guī)范公司項目的需求開發(fā)和管理活動，以保證對客戶需求的正確理解，確保項目產(chǎn)物與需求的一致性。適用范圍適用于公司合同開發(fā)類項目、產(chǎn)品研發(fā)類項目的需求

9、開發(fā)和需求管理活動。術(shù)語和縮略語表 SEQ 表 * ARABIC 1術(shù)語和縮略語術(shù)語、縮略語解 釋PD項目總監(jiān)TD技術(shù)總監(jiān)PM項目經(jīng)理相關(guān)文件無角色和職責表 SEQ 表 * ARABIC 2角色和職責角色職責PM負責跟客戶的溝通和協(xié)調(diào)工作；負責需求開發(fā)和需求管理工作的策劃和管理，保證需求開發(fā)工作的進度和質(zhì)量。責任設計師負責需求開發(fā)的組織和管理工作，完成用戶需求調(diào)研報告和需求規(guī)格說明書，并獲得客戶的確認；負責需求管理。工程師（高、中級）協(xié)助需求調(diào)研與分析， 對需求的實現(xiàn)可行性進行驗證；參與需求評審活動。PD指導并監(jiān)控需求開發(fā)和管理過程。TD參與需求評審并對評審內(nèi)容進行核準入口準則項目啟動會輸入項

10、目合同項目計劃流程圖圖 SEQ 圖 * ARABIC 1需求開發(fā)與管理過程流程圖主要活動需求開發(fā)和需求管理是需求工程的兩個組成部分。需求開發(fā)的主要活動包括：需求開發(fā)準備、需求調(diào)研、需求分析、編寫需求規(guī)格說明書和需求確認。需求開發(fā)是通過與用戶溝通，收集用戶資料，理解用戶的術(shù)語、概念、視點和目的，經(jīng)過分析、建模和驗證，確認獲取正確、完整和一致的需求的過程。這些活動在實際應用中不是線性的、順序的完成的，而是交叉的、遞增的和反復的，需求開發(fā)是一個迭代的過程，如下圖所示：需求管理的目的是在客戶與項目組之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求管理的主要活動包括：需求

11、變更和需求跟蹤管理。PD應監(jiān)督需求開發(fā)和管理過程，管控項目執(zhí)行情況，并指導PM對執(zhí)行過程中產(chǎn)生的偏差進行修正。需求開發(fā)準備需求開發(fā)準備階段的工作主要包括以下幾個方面：一是明確項目目標和范圍；二是識別需求的來源，為需求獲取準備相關(guān)資料，例客戶需求調(diào)研問卷等；三是根據(jù)項目規(guī)模和特點，選擇調(diào)研方式；四是收集需求開發(fā)過程可用的知識，充分利用已有的知識和經(jīng)驗策劃整個需求開發(fā)過程，制定需求調(diào)研計劃。明確項目目標和范圍項目目標和范圍通常在項目合同中有定義，在需求開發(fā)工作開始之前，PM應要求所有參與需求開發(fā)工作的人員明確項目目標和范圍，以便相關(guān)人員對產(chǎn)品的業(yè)務目標和范圍有共同的理解，控制項目范圍。識別需求來源

12、識別需求來源是需求開發(fā)的一項重要工作，在需求調(diào)研開始之前PM應組織參與需求調(diào)研的人員進行清楚的識別。需求的來源主要有：1) 組織或用戶高層次的目標：這些目標是軟件系統(tǒng)開發(fā)的動因，但是通常描述不夠清晰，需要需求開發(fā)人員特別的關(guān)注；2) 用戶業(yè)務領(lǐng)域的知識：領(lǐng)域知識幫助需求開發(fā)人員推斷一些用戶當作默認的而沒有說明的需求，或者平衡需求之間的沖突；3) 各層次的用戶：不同層次的用戶對系統(tǒng)的需求不同，這也是需要需求開發(fā)人員要重點獲取的需求。用戶的積極參與是需求開發(fā)成功的關(guān)鍵，因此，在進行需求調(diào)研時，要解決一個重要的問題確定哪些人是需求獲取的合適對象，哪些人對系統(tǒng)的開發(fā)和應用具有發(fā)言權(quán)和決策權(quán)；4) 系統(tǒng)

13、的運行環(huán)境：系統(tǒng)的運行環(huán)境影響軟件的可行性、成本和設計方案的選擇；5) 組織所處的環(huán)境：軟件通常支持組織的業(yè)務流程，必需考慮組織的機構(gòu)劃分、文化背景、內(nèi)部的政治目的，不能強迫要求組織因為軟件進行非計劃的業(yè)務改變，同時還要考慮國家政策、法律法規(guī)以及相關(guān)行業(yè)標準等；6) 競爭對手的產(chǎn)品：通過對競爭對手產(chǎn)品的研究，獲取有競爭力的需求。選擇調(diào)研方法和技術(shù)需求調(diào)研是一個困難的過程，對于需求開發(fā)調(diào)研人員來說，需求獲取不是被動的活動，而應該主動的根據(jù)不同的需求來源采取不同的需求獲取方法進行需求收集。需求獲取的方法和技術(shù)多種多樣，針對不同的項目和不同的調(diào)研對象范圍，可以采用不同的方法，也可以多種方法配合使用。

14、責任設計師應根據(jù)項目情況負責選擇合適的調(diào)研方法和技術(shù)。需求調(diào)研的參考方法如下：表 SEQ 表 * ARABIC 3需求調(diào)研方法方法內(nèi)容輸出面談與用戶面對面的訪談，可以一對一或者一對多，要求準備一個問題列表，用來獲得有關(guān)用戶問題和潛在解決方案的整體特征的信息；需求調(diào)研記錄調(diào)查問卷使用設計好的調(diào)查問卷，以書面的形式收集用戶需求；調(diào)研問卷相關(guān)業(yè)務資料集體討論頭腦風暴會議，提出對現(xiàn)在問題的理解和思考，涉眾提出問題、愿望和潛在解決方案的建議；會議紀要需求調(diào)研記錄在用戶環(huán)境中工作需求調(diào)研人員在用戶的實際環(huán)境中與用戶共同工作一段時間，以更加深入的了解用戶的問題、要求以及應用環(huán)境；需求調(diào)研記錄原型演示展示類似

15、系統(tǒng)的功能，以揭示用戶需要需求調(diào)研記錄制訂需求調(diào)研計劃制定需求調(diào)研計劃（模板詳見：“03.需求CSI_02_需求調(diào)研計劃.doc”）的目的是為了規(guī)劃項目中需求調(diào)研活動的開展，其內(nèi)容主要包括需求調(diào)研的對象、調(diào)研的內(nèi)容、準備采用的技術(shù)和方法、輸出產(chǎn)物、人力安排和時間進度等。需求調(diào)研計劃應該開展需求調(diào)研活動之前完成，由PM和責任設計師共同完成策劃，責任設計師完成制訂，在由項目經(jīng)理跟客戶方項目經(jīng)理一起討論確定，并提前通知所有參加需求調(diào)研的人員。針對不同類別的項目，需求調(diào)研工作過程基本一致，但側(cè)重點有所不同，在制定調(diào)研計劃的時候要分別考慮：業(yè)務流程開發(fā)類項目業(yè)務流程開發(fā)類項目的需求調(diào)研工作重心是要充分理

16、解業(yè)務相關(guān)的信息：系統(tǒng)需要實現(xiàn)的業(yè)務功能范圍；業(yè)務相關(guān)的組織、人員、崗位及相關(guān)職能；業(yè)務處理的流程；關(guān)鍵業(yè)務數(shù)據(jù)及數(shù)據(jù)分布及流向；相關(guān)的業(yè)務表單。數(shù)據(jù)中心類項目數(shù)據(jù)中心類項目的需求調(diào)研工作重心是要弄清楚業(yè)務數(shù)據(jù)的結(jié)構(gòu)和來源以及相關(guān)數(shù)據(jù)分析的需求：基礎(chǔ)數(shù)據(jù)代碼標準及管理需求；業(yè)務數(shù)據(jù)的來源及相關(guān)系統(tǒng)特征；業(yè)務數(shù)據(jù)的結(jié)構(gòu)、范圍、內(nèi)容和質(zhì)量；數(shù)據(jù)及元數(shù)據(jù)管理的需求；相關(guān)指標及管理；報表需求；數(shù)據(jù)分析與決策支持需求。產(chǎn)品研發(fā)類產(chǎn)品研發(fā)類項目側(cè)重點與業(yè)務流程開發(fā)類基本一致。編制需求調(diào)研問卷如果采用面談、調(diào)查問卷、集體討論的調(diào)研方法，參與需求調(diào)研的人員應事先學習相關(guān)的業(yè)務知識，收集相關(guān)的資料并進行分析，在

17、對客戶需求有一定了解的基礎(chǔ)上提前準備需要問的問題，形成需求調(diào)研問卷（模板詳見：“03.需求CSI_03_需求調(diào)研問卷.doc”），以便系統(tǒng)、全面、高效的獲取客戶的需求。需求調(diào)研問卷中列的問題與業(yè)務領(lǐng)域相關(guān)，不同的項目需要根據(jù)項目涉及的業(yè)務領(lǐng)域設計調(diào)研問卷中的問題，問題列的越詳細對需求調(diào)研的幫助越大，如果以前有類似的項目，可復用以往類似項目的成果。需求調(diào)研責任設計師負責按照需求調(diào)研計劃執(zhí)行需求調(diào)研活動，在需求調(diào)研過程中，應及時記錄、整理需求調(diào)研記錄（模板詳見：“03.需求CSI_04_需求調(diào)研記錄.doc”），根據(jù)需求調(diào)研記錄編寫需求調(diào)研報告（模板詳見：“03.需求CSI_05_用戶需求調(diào)研報告

18、.doc”）并請客戶進行確認。 進行需求調(diào)研在進行需求調(diào)研時，應基于需求調(diào)研問卷有效引導客戶提出需求，這個過程的重點工作是：1) 進一步識別并選定用戶代表，避免遺漏重要客戶；2) 明確業(yè)務流程、業(yè)務數(shù)據(jù)、業(yè)務規(guī)則以及每個業(yè)務活動涉及的崗位，同時識別出核心業(yè)務流程等；3) 除了聽取客戶提出的需求以外，還要積極參與討論，引導客戶提出需求和問題，對于有歧義的需求要充分討論，對于客戶提出的超出范圍的或者不現(xiàn)實的需求要積極跟客戶協(xié)商，在共贏的基礎(chǔ)上達成共識；4) 在調(diào)研過程中要及時記錄客戶提出的需求，形成需求調(diào)研記錄；5) 調(diào)研過程中還要注意收集與產(chǎn)品相關(guān)的資料，例如：組織機構(gòu)、部門及崗位職責、規(guī)章制度

19、、業(yè)務流程、業(yè)務單據(jù)及統(tǒng)計報表等，對于業(yè)務單據(jù)和統(tǒng)計報表，最好是收集帶有歷史數(shù)據(jù)的，而不是空的表格，便于后續(xù)對數(shù)據(jù)的需求進行分析。編寫用戶需求調(diào)研報告責任設計師應根據(jù)需求調(diào)研的記錄和收集到的資料，組織整理、編寫用戶需求調(diào)研報告。調(diào)研報告編寫完成進行內(nèi)部評審，執(zhí)行評審過程，TD應負責最終的審核和確認。內(nèi)部評審完成后，須提交客戶并請客戶審閱，在客戶審閱過程中可能還會提出問題，需要進行進一步的調(diào)研并及時修改完善調(diào)研報告，最后獲得用戶認可和簽字。需求分析 在完成需求調(diào)研后，設計師應對產(chǎn)品的原始需求進行分析，建立各需求元素之間的關(guān)系，明確需求的標識、需求的分類、需求的優(yōu)先級等。需求分析的方法種類繁多，但

20、常見的需求分析方法主要是結(jié)構(gòu)化分析方法和基于用例的需求分析方法。需求分析方法結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法的主要特點是“自頂向下、逐層分解”，它把系統(tǒng)看作一個過程的集合體，利用圖形等半形式化的描述方式表達需求，對問題進行分析，描述方式有：數(shù)據(jù)流圖（Data Flow Diagram，DFD）：數(shù)據(jù)流圖是一種圖形化的系統(tǒng)模型，它在一張圖中展示信息系統(tǒng)的主要需求，即輸入、輸出、處理過程、數(shù)據(jù)存儲。數(shù)據(jù)字典（Data Dictionary，DD）：數(shù)據(jù)字典技術(shù)是一種有效表達數(shù)據(jù)格式的手段，它是對所有與系統(tǒng)相關(guān)的數(shù)據(jù)元素的一個有組織的列表和精確、嚴格的定義，從而使用戶和設計師對于輸入、輸出、數(shù)據(jù)存儲和處

21、理過程有共同的理解。結(jié)構(gòu)化語言：結(jié)構(gòu)化語言是結(jié)構(gòu)化編程語言與自然語言的有機結(jié)合，可以采用順序結(jié)構(gòu)，分支機構(gòu)、循環(huán)結(jié)構(gòu)等機制，來說明業(yè)務的處理流程。實體-關(guān)系圖（Entity Relationship Diagram，E-R圖）：E-R圖可以用來描述數(shù)據(jù)的存儲需求，包括數(shù)據(jù)實體，數(shù)據(jù)實體的屬性以及它們之間的關(guān)系等。結(jié)構(gòu)化分析方法從總體上看是一種強烈依賴數(shù)據(jù)流圖的自上而下的建模方法，它是完成需求規(guī)格化的有效技術(shù)手段，使用結(jié)構(gòu)化分析方法時可遵循下列活動： （1）、建立系統(tǒng)的物理模型 畫出系統(tǒng)的數(shù)據(jù)流圖，說明系統(tǒng)的輸入、輸出數(shù)據(jù)流，說明系統(tǒng)的數(shù)據(jù)流情況，以及經(jīng)歷了哪些處理過程。在這個數(shù)據(jù)流圖中，可以包

22、括一些非計算機系統(tǒng)中數(shù)據(jù)流及處理過程的名稱，如部門、崗位、報表等。這個過程可以幫助分析人員有效地理解業(yè)務環(huán)境。（2）、建立系統(tǒng)的邏輯模型在物理模型建立之后，接下來的工作就是畫出相對于真實系統(tǒng)的等價邏輯數(shù)據(jù)流圖。將所有自然數(shù)據(jù)流圖轉(zhuǎn)換為等價的邏輯流。（3）、劃清人機界限最后，確定在系統(tǒng)邏輯模型中，哪些部分將采用自動化完成，哪些部分仍然保留手工操作，從而清晰的劃清系統(tǒng)的范圍。基于用例的分析方法用例是由一組用例實例組成的，是用戶使用系統(tǒng)的一個實際的、特定場景。用例是應用程序開發(fā)中的一個關(guān)鍵技術(shù)，主要用來捕獲系統(tǒng)的高層次用戶功能性需求。用例分析技術(shù)是一種需求合成技術(shù)，它利用現(xiàn)有的需求調(diào)研技術(shù)從客戶、原

23、有系統(tǒng)、文檔中找到需求，記錄下來，然后從這些零散的需求、特性中進行整理、提煉，從而建立用例模型。使用用例分析方法時可遵循以下步驟：1)識別系統(tǒng)參與者，確定誰會直接使用該系統(tǒng)。參與者是同系統(tǒng)交互的所有事物，該角色不僅可以由人承擔，還可以是其它系統(tǒng)、硬件設備、甚至是時鐘。2)合并需求獲得用例。找到所有參與者之后，根據(jù)需求調(diào)研所得到的用戶需求，定義每個參與者希望系統(tǒng)做什么，參與者希望系統(tǒng)作的每件事將成為一個用例。3)繪制用例圖。將所識別的參與者以及所定義的用例通過用例圖的形式整理出來，以獲得用例模型的框架。4)細化用例描述。用例描述包括以下幾個部分：用例名稱；參與者；用自然語言對用例進行簡要的描述；

24、描述參與者何時使用該用例，即用例的觸發(fā)條件；描述在一般情況下，參與者使用該用例時會發(fā)生什么事情，即用例的基本過程；在基本過程的基礎(chǔ)上，考慮一些可變情況，把他們創(chuàng)建為擴展用例。功能需求分解需求分析過程一個很重要的工作就是對就是對需求的分解（WBS），設計師應依據(jù)業(yè)務特點分解功能需求，并形成功能需求列表，如下表：功能需求子功能需求（可多級）標識需求為了確保需求的易跟蹤、易修改，責任設計師應通過需求編號的方式唯一標識每一個需求，明確需求的跟蹤粒度，并體現(xiàn)于需求規(guī)格說明書中。表 SEQ 表 * ARABIC 4需求標識方法方法說明優(yōu)、缺點序列號例如U R - 2或S R S 1 3；序列號的前綴代表了

25、需求類型；例如U R代表“用戶需求”。序列號不能重用。這種簡單的編號方法并不能提供任何相關(guān)需求在邏輯上或?qū)哟紊系膮^(qū)別，而且需求的標識不能提供任何有關(guān)每個需求內(nèi)容的信息。層次化編碼如果功能需求出現(xiàn)在軟件需求規(guī)格說明中第3 .2 部分，那么它們將具有諸如3 . 2 . 4 . 3這樣的標識號。標識號中的數(shù)字越多則表示該需求越詳細，屬于較低層次上的需求。這種方法簡單且緊湊，你使用的字處理程序可能可以自動編排序號。但是當插入、刪除或移去一個需求，那么該需求所在部分其后所有需求的序號將要減少，這些變化將破壞系統(tǒng)其它地方需求的引用。層次化文本標簽基于文本的層次化標簽方案來標識單個需求。層次化文本標簽是結(jié)構(gòu)

26、化的，具有語義上的含義，并且不受增加、刪除或移動其它需求的影響。它們的主要缺點是文本標簽比層次化數(shù)字標識碼復雜。自定義如：SRS_模塊縮寫+序列號SRS表示需求，示例：SRS_SZAG01、SRS_SZAG01.01、SRS_靈活。定義需求的優(yōu)先級責任設計師應確定每個需求的優(yōu)先級并寫入需求規(guī)格說明書（模板詳見：“3.需求CSI_06_需求規(guī)格說明書.doc”）中，需求的優(yōu)先級的評價標準如下：表 SEQ 表 * ARABIC 5優(yōu)先級級別定義級別定義判斷標準高必須被實現(xiàn)的需求，這類需求通?？梢詮囊韵聨讉€方面判斷：客戶核心的業(yè)務流程；強制性的國家或行業(yè)法律法規(guī)、標準要求的；明確或隱含的對用戶使用會

27、造成重要影響的。中應該被實現(xiàn)的需求，這類需求往往具有以下特征：客戶隱含要求，對正常業(yè)務影響程度不大；不影響用戶正常使用，但為了更易用而提出來的一些需求；支持必要的系統(tǒng)操作，實現(xiàn)這些需求將增強產(chǎn)品的性能，是產(chǎn)品最終所要求的。低可以被實現(xiàn)的需求，這些需求一般為裝飾性的要求，如：功能或質(zhì)量上的附加需求；實現(xiàn)這些需求會使產(chǎn)品更完美，若不實現(xiàn)也不影響產(chǎn)品的功能與性能。優(yōu)先級的定義有利于幫助項目組在項目的范圍、進度、資源、預算等相關(guān)制約因素之間產(chǎn)生沖突時，正確地對需求實現(xiàn)的范圍或?qū)崿F(xiàn)的優(yōu)先程度做出取舍。編寫需求規(guī)格說明書編寫需求規(guī)格說明書應遵循以下規(guī)則：相關(guān)的需求都得到了識別與描述，以確保需求的完整性；各

28、個需求之間不沖突，算法之間不相互矛盾，以確保需求的一致性；正確描述系統(tǒng)需求，引用的資料有正規(guī)的出處，以確保需求的正確性；定義必要的術(shù)語，適當結(jié)合圖形、結(jié)構(gòu)圖等方式進行描述，以確保需求無二義性；使用較好的文檔結(jié)構(gòu)與需求標識，使需求能夠方便地與其它工作產(chǎn)品相對應，以確保需求易于追溯；考慮了各個層次的需求，確定了需求的優(yōu)先級，以確保需求的可行性。需求規(guī)格說明書主要內(nèi)容包括：項目概述；業(yè)務流程；數(shù)據(jù)描述；功能需求；非功能需求；界面要求；接口要求。評審需求規(guī)格說明書項目組內(nèi)部對所形成的需求規(guī)格說明書文檔進行評審，以便作為下一階段工作的基礎(chǔ)，評審執(zhí)行評審過程，應根據(jù)評審檢查單（模板詳見：“13.評審CSI

29、_02_評審檢查單.doc”）模板形成需求規(guī)格說明書評審檢查單，TD應負責最終的審核和確認。需求確認客戶確認PM與客戶方項目經(jīng)理組織客戶對需求進行確認。需求確認的目的是獲得客戶對需求的認可并簽字。需求確認前，PM應組織與相關(guān)客戶進行溝通，確認需求是否滿足其需要，必要時輔以原型演示的方式幫助客戶進行需求理解，取得客戶對需求的理解和認同。這是一個迭代的過程，需要PM與客戶進行良好的溝通，才能取得好的效果。 需求的最終確認一般采取會簽或者評審會議的方式。需求評審會：一般由客戶組織，項目經(jīng)理配合客戶準備相關(guān)資料（具體準備哪些資料需要跟客戶方負責人協(xié)商。一般需準備評審會議PPT文件和需求評審報告），通過

30、會議完成對需求的評審并簽字確認。會簽主要是相關(guān)客戶直接對需求進行簽字確認。在會簽或者會議評審的過程中，PM應詳細記錄在評審過程中發(fā)現(xiàn)的問題，明確遺留問題處理措施。獲取客戶提供確認證據(jù)后，結(jié)束需求確認工作。需求變更管理在需求并獲得確認后，需求可能還會因為多種原因?qū)е伦兏?，導致變更的原因可能是客戶方遺漏、表述不清，也可能是項目組理解有誤。需求的變更可能導致項目范圍的變化，帶來額外的工作量，尤其是在設計、開發(fā)、實施階段發(fā)生的需求變化，會造成更大的影響。但需求變更也是不可避免的，因此應建立需求跟蹤機制（見下一節(jié)）并對需求的變更加以嚴格的管理和控制，盡可能減少需求變更和降低需求變更帶來的影響。需求的變更應嚴格遵照變更管理規(guī)程執(zhí)行。需求跟蹤對一個項目來說，當需求確定下來以后，應該保證在設計過程中每個需求都被實現(xiàn)，且項目的其它工作產(chǎn)品與需求保持一致。因此，一個比較好的方法就是建立一種需求雙向跟蹤機制。雙向跟