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

1、密級：普通標 識:S_RD_XQKFYGLGC版本號：2.0分冊：第1冊/共1冊需求開發(fā)與管理過程湖南創(chuàng)博龍智信息科技股份有限公司湖南創(chuàng)博龍智信息科技股份有限公司對本文件資料享受著作權及其它專屬權利，未經(jīng)書面許可不得將該等文件資料（其全部或任何部分）披露予任何第三方，或進行修改后使用。需求開發(fā)與管理過程文件更改摘要:湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？日期版本號修訂說明修訂人生效日期2006.12.251.0建立陳艷萍2006.12.252008.1.61.1弓1入CPMS系統(tǒng)韓冰2008.2.12008.7.41.2不再使用福求矩陣表，而米用 CPMS系統(tǒng)中的依賴關系進行 需求雙向跟

2、蹤。韓冰2008.8.12009.121.3將評審結(jié)果寫入變更申請單中韓冰2010.1.12010.122.0公司名稱變更韓冰2011.1.1需求開發(fā)與管理過程目錄 TOC o 1-5 h z 目的/方針3范圍3術語3角色與職責3入口準則3輸入3流程圖4主要活動4需求獲取4明確所需獲取信息的來源與渠道(Where) 5獲取需求(HoW 5需求獲取資料的保管 7編寫用戶需求規(guī)格說明書 7需求分析7結(jié)構(gòu)化分析方法 7基于用例的分析方法 8需求定義9定義需求的優(yōu)先級 9編寫需求分析說明書 10需求確認10需求評審10需求承諾11建立需求基線 11需求變更11需求變更申請 錯誤！未定義書簽。需求變更的

3、實施 12需求跟蹤12建立需求跟蹤矩陣 12需求跟蹤矩陣的維護與使用 12輸出12出口準則13資源13引用文檔13湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？需求開發(fā)與管理過程.目的/方針通過定義需求開發(fā)和管理過程，規(guī)范公司項目的需求開發(fā)和管理活動，提高需求質(zhì)量，從而提高生產(chǎn)率，降低開發(fā)成本，改進產(chǎn)品質(zhì)量。應調(diào)查用戶的需求，通過需求分析工作將用戶需求轉(zhuǎn)化為產(chǎn)品需求，同時評審需求的正確性，獲得需求的承諾；應控制需求的變更，并確保項目工作產(chǎn)品與需求的一致性。.范圍適用于公司所有項目。.術語術語或縮略語解釋軟件需求在IEEE軟件工程標準詞匯表（1997年）中定義軟件需求為：（1）用戶解決問 題或達到

4、目標所需的條件或能力。（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。（3） 一種反映上面（1）或（2）所描述的條件或權能的文檔說明。 通俗的講，“需求”就是用戶的需要， 它包括用戶要解決的問題、 達到的目標、以及實現(xiàn)這些目標所需要的條件， 它是一個程序或系統(tǒng)開發(fā)工作的說明，表現(xiàn)形式一般為又檔形式。用例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成對特定參與者可見的價值 結(jié)果，一個用例定義了一組用例實例。需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤和 彌補不足，確保需求文檔正確地反映用戶的真實意圖。需求分析的關鍵就 是對問題域的研究與理解

5、。為了便于理解問題域，現(xiàn)代工程管理所推薦的 做法就是對問題域進行抽象，將其分解為若干基本兀素，然后對兀素之間 的關系進行建模。.角色與職責角色職責項目經(jīng)理負責組織項目的需求分析和管理工作需求分析師負責需求的獲取，分析以及定義評審管理組接受需求評審申請，組織進行需求的評審CM工程師負責建立基線、維護需求跟蹤矩陣QA工程師負責質(zhì)里檢查.入口準則項目策劃6.輸入項目總體計劃湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？需求開發(fā)與管理過程7.流程圖圖1:需求開發(fā)與管理過程活動示意圖8.主要活動項目需求包括了需求開發(fā)和需求管理兩個部分，需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義項目需求。需求開發(fā)的

6、主要活動包括：需求獲取、需求分析和需求定義。需求管理的目的是在客戶與項目組之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求管理的主要活動包括：需求確認，需求變更和需求跟 蹤控制。需求開發(fā)與管理過程的主要活動主要都是通過CPMS系統(tǒng)進行。在項目開始的之后，配置管理員會在 CPMS系統(tǒng)當中建立一個需求庫，需求庫可以理解為SVN庫的一種特殊形式，此時它只是一個目錄， 沒有內(nèi)容，下級目錄結(jié)構(gòu)則需要在需求開發(fā)與管理過程當中進行 補充、完善，建立需求跟蹤矩陣。當配置管理員建立需求庫之后，項目經(jīng)理在項目計劃中明確需求階段需要的資源、進度等，然后項目經(jīng)理或是安排其他人員對建立的

7、需求庫屬性進行定義，如：需求來源、優(yōu)先級 等。（擊需求庫目錄 屬性定義）需求獲取需求獲取的目的是通過各種途徑獲取用戶的需求信息，但是又因為項目/產(chǎn)品所面向的對象不同，所采取的方式也就不一樣。在實際工作中，大部分客戶是無法完整地講述其需求，因此需求獲取是一件看似簡單， 做起來很難的一件事情，需求獲取的質(zhì)量，對后續(xù)的需求分析和需求定義工作將會產(chǎn)生重大 影響。明確需要獲取的信息（What）需求分析師應在需求獲取前明確需要獲取的需求信息，以確保在實施需求獲取時有的放矢。湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？需求開發(fā)與管理過程通常需求獲取要獲取的信息包括三大類：與問題域相關的背景信息（如業(yè)務資料，

8、組織結(jié)構(gòu)圖，業(yè)務處理流程等）與要求解決的問題直接相關的信息；用戶對系統(tǒng)的特別期望與施加的任何約束信息。明確所需獲取信息的來源與渠道（Where）需求分析師在明確了所需要獲取的信息之后，應確定獲取需求信息的來源與渠道，以提高需求分析師在需求獲取階段的工作效率，使得所收集的信息更加有價值、更加全面。需求信息的來源通常包括：來自客戶的需求a）舊系統(tǒng)的用戶或客戶對系統(tǒng)安裝、使用、維護、管理等方面的需求b）系統(tǒng)的潛在用戶或客戶對系統(tǒng)的需求競爭對手的產(chǎn)品優(yōu)勢與不足國家政策、業(yè)務規(guī)則以及相關行業(yè)標準實施產(chǎn)品設計所需滿足的需求執(zhí)行測試驗證工作所需滿足的需求實施系統(tǒng)安裝、維護所需滿足的需求獲取需求信息的渠道包括

9、：用戶或客戶公司研發(fā)管理部門公司技術管理部門項目實施部門營銷管理部門舊有系統(tǒng)的研發(fā)項目組來自項目組內(nèi)獲取需求（HoW在明確須獲取什么需求、需求的來源與獲取渠道后，項目經(jīng)理應選擇至少一種需求獲取 技術獲取相關的需求，作為需求分析的依據(jù)。需求獲取技術包括但不限于：）用戶訪談用戶訪談的形式包括結(jié)構(gòu)化和非結(jié)構(gòu)化兩種。 結(jié)構(gòu)化是指事先準備好一系列問題， 有針 對性地進行；非結(jié)構(gòu)化是只列出一個粗略的想法， 根據(jù)訪談的具體情況進行發(fā)揮。 有效的訪 談需要靈活的結(jié)合這兩種方法。用戶訪談具有很好的靈活性， 有較廣的應用范圍，但實際操作時存在許多困難， 例如客 戶經(jīng)常很忙，難以獲得充足的訪談時間； 客戶訪談需要需

10、求分析師有很強的溝通能力，同時也要求需求分析師有足夠的相關業(yè)務領域知識。）用戶調(diào)查用戶調(diào)查是通過精心設計提問問題形成調(diào)查問卷，然后下發(fā)到相關人員手中，讓他們填寫答案，來獲取用戶需求。用戶調(diào)查的方法最大的缺點是缺乏靈活性，由于缺乏面多面的交流，所獲取的信息量也湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？需求開發(fā)與管理過程比較有限。因此在實際工作中， 我們建議可以先采用用戶調(diào)查的方式獲取一定量的信息，然后有針對性地開展用戶訪談。3）現(xiàn)場觀摩用戶的工作流程，觀察用戶的實際操作俗話說，“百聞不如一見”，對于一些較為復雜的流程和操作而言， 是比較難以用語言和 文字進行表達的，對于這種情況，可以采用到客戶

11、的工作現(xiàn)場， 一邊觀察，一邊聽客戶講解， 從而更直觀的了解客戶需求。4）從行業(yè)標準、規(guī)則中提取需求如果用戶要求所開發(fā)的項目產(chǎn)品必須滿足一定的行業(yè)標準和業(yè)務規(guī)則，需求分析師可以通過閱讀政策法規(guī)、業(yè)務規(guī)則以及行業(yè)標準等各類相關的文檔，并與相關領域的業(yè)務專家進行業(yè)務交流來了解客戶的需求。這種方法要求需求分析師有一定的行業(yè)從業(yè)經(jīng)驗，能夠了解行業(yè)的發(fā)展動向，這對從技術出生的需求分析師來說是一個巨大的考驗。5）文檔考古對于一些數(shù)據(jù)流比較復雜的、工作表單較多的項目，有時是難以通過說或者觀察來了解 需求細節(jié)的。這個時候就可以通過對歷史存在的一些文檔進行研究，考古一詞非常形象地說明了其主要的工作重心是通過已經(jīng)填

12、寫完畢的、也就是帶有數(shù)據(jù)的文件、表單、報告，獲得 所需的信息。6）需求討論會這是一種相對來說成本較高的需求獲取方法，但也是十分有效的一種。它通過聯(lián)合各個關鍵客戶代表，分析人員，開發(fā)人員，通過有組織的會議來討論需求。在會議之前，應該將與討論主體相關的材料提前分發(fā)給所有將要參加會議的人。在會議開始之后，先針對材料所列舉的問題進行逐項專題討論， 然后對原有系統(tǒng)、 類似系統(tǒng)的不足 進行開放性交流，并在此基礎上對新的解決方案進行構(gòu)思， 在此過程中將所有的想法、問題 和不足記錄下來，形成一個要點清單，作為后續(xù)需求分析的依據(jù)。7）原型法原型（prototype）即把系統(tǒng)主要功能和接口通過快速開發(fā)制作為軟件樣

13、機”，以可視化的形式展現(xiàn)給用戶，及時征求用戶意見，從而明確無誤地確定用戶需求。同時，原型也可用于 征求內(nèi)部意見，作為分析和設計的接口之一，可方便于溝通。原型法主要價值是可視化，強 化溝通，降低風險，節(jié)省后期變更成本，提高項目成功率。原型的基本步驟：根據(jù)客戶原始需求、項目建議書、市場需求或合同要求，確定系統(tǒng)要做什么，即 系統(tǒng)的邊界、主要業(yè)務或功能、系統(tǒng)的接口；根據(jù)這些需求，形成系統(tǒng)原型。對于所形成的原型的基本要求包括：體現(xiàn)主要的功能；提供基本的界面風格；展示比較模糊的部分，以便于確認或進一步明確，防患于未然。原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。進行原型評價并獲取系統(tǒng)的需

14、求，原型評價可以從幾個方面進行：在公司內(nèi)部演示、評審，進一步獲取內(nèi)部信息，并求得共識與用戶進行演示與交流，挖掘用戶需求，從而確定軟件的目標和需求根據(jù)原型評價的意見修改原型，直到求得共識原型法的優(yōu)點是：1 ）鼓勵業(yè)務管理者的積極參與；2 ）有助于解決業(yè)務管理者之間的 差異；3）能給業(yè)務管理者一個對最終系統(tǒng)的直觀感受；4）周期短；5）成本低；6）用 戶較滿意。湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？需求開發(fā)與管理過程但原型法也有缺點，主要為：1 ）導致人們認為最終系統(tǒng)將很快產(chǎn)生；2）對系統(tǒng)操作 權限的說明較弱；3）不適合于開發(fā)大系統(tǒng)；4）開發(fā)過程管理困難。需求獲取資料的保管根據(jù)所采用的需求獲取

15、技術，在需求獲取過程中將產(chǎn)生不同的記錄和原始資料，項目組應將這些記錄納入開發(fā)庫進行配置管理。需求獲取的記錄與資料包括但不限于：用戶編寫的原始需求文檔；用戶填寫的需求調(diào)查表；用戶訪談的訪談紀要；需求研討會的會議紀要；相關的政策法規(guī)文件，業(yè)務規(guī)則文件以及行業(yè)標準文件；需求原型。編寫用戶需求規(guī)格說明書在需求獲取結(jié)束后， 需求分析師應根據(jù)需求獲取得到的記錄與資料，整理編寫用戶需求規(guī)格說明書，用戶需求規(guī)格說明書主要采用自然語言（和應用域術語）來表達用戶需 求，其主要內(nèi)容應該包括但不局限于：產(chǎn)品介紹，描述產(chǎn)品的用途和開發(fā)背景；產(chǎn)品潛在的最終用戶群體及其特征；產(chǎn)品應該遵循的業(yè)務規(guī)范和標準；產(chǎn)品的功能性需求；

16、產(chǎn)品的非功能性需求。對于工作量小于5人的小型項目、使用了原型法獲取需求的項目、沒有明確的目標客戶的項目、直接引用用戶提供的需求說明書的項目，可以不用編制用戶需求規(guī)格說明書。用戶需求規(guī)格說明書可以作為需求分析說明書的一部分，也可以單獨成冊。需求分析在完成需求獲取所得到的記錄與資料的分析與整理后，項目經(jīng)理應組織項目的需求分析工作。需求分析的方法種類繁多，但常見的需求分析方法主要是結(jié)構(gòu)化分析方法和基于用例的 需求分析方法。需求分析方法由項目經(jīng)理根據(jù)項目的實際需要進行組內(nèi)培訓，培訓組織與記錄是通過 CPMS的培訓管理模塊進行。結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法的主要特點是“自頂向下、逐層分解”，它把系統(tǒng)看作

17、一個過程的集合體，利用圖形等半形式化的描述方式表達需求，對問題進行分析，描述工具有：數(shù)據(jù)流圖（Data Flow Diagram , DFD）：數(shù)據(jù)流圖是一種圖形化的系統(tǒng)模型，它在一湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？需求開發(fā)與管理過程張圖中展示信息系統(tǒng)的主要需求，即輸入、輸出、處理過程、數(shù)據(jù)存儲。數(shù)據(jù)字典(Data Dictionary , DD )：數(shù)據(jù)字典技術是一種有效表達數(shù)據(jù)格式的手段， 它是對所有與系統(tǒng)相關的數(shù)據(jù)元素的一個有組織的列表和精確、嚴格的定義，從而 使用戶和系統(tǒng)分析員對于輸入、輸出、存儲成分和中間計算機有共同的理解。結(jié)構(gòu)化語言：結(jié)構(gòu)化語言是結(jié)構(gòu)化編程語言與自然語言的

18、有機結(jié)合，可以采用順序 結(jié)構(gòu)，分支機構(gòu)、循環(huán)結(jié)構(gòu)等機制，來說明加工的處理流程。判定表和判定樹：判定表是一種處理邏輯的表格表示方法，其中包括決策變量，決 策變量值、參與者或公式；而判定樹則使用像樹枝一樣的線條對過程邏輯進行圖表 化的描述。判定表和判定樹用來描述復雜決策邏輯，要遠遠優(yōu)于使用結(jié)構(gòu)化語言。實體-關系圖(Entity Relationship Diagram , E-R圖)：E-R圖可以用來描述數(shù)據(jù)的存 儲需求，包括數(shù)據(jù)實體，數(shù)據(jù)實體的屬性以及它們之間的關系等。結(jié)構(gòu)化分析方法從總體上看是一種強烈依賴數(shù)據(jù)流圖的自上而下的建模方法，它不僅是需求分析計劃，也是完成需求規(guī)格化的有效技術手段，使用

19、結(jié)構(gòu)化分析方法時可遵循下列活動：建立系統(tǒng)的物理模型首先，畫出系統(tǒng)得數(shù)據(jù)流圖，說明系統(tǒng)的輸入、輸出數(shù)據(jù)流，說明系統(tǒng)的數(shù)據(jù)流情況， 以及經(jīng)歷了哪些處理過程。在這個數(shù)據(jù)流圖中， 可以包括一些非計算機系統(tǒng)中數(shù)據(jù)流及處理過程的名稱，如部門名、崗位名、報表名等。這個過成可以幫助分析人員有效地理解業(yè)務環(huán) 境。建立系統(tǒng)的邏輯模型在物理模型建立之后， 接下來的工作就是畫出相對于真實系統(tǒng)的等價邏輯數(shù)據(jù)流圖。將所有自然數(shù)據(jù)流圖轉(zhuǎn)換為等價的邏輯流。劃清人機界限最后，確定在系統(tǒng)邏輯模型中，哪些部分將采用自動化完成，哪些部分仍然保留手工操作，從而清晰的劃清系統(tǒng)的范圍?；谟美姆治龇椒◤亩x中我們得知用例是由一組用例實例

20、組成的，用例實例也稱為“使用場景”，是用戶使用系統(tǒng)的一個實際的、特定場景。用例是應用程序開發(fā)中的一個關鍵技術，主要用來捕獲系統(tǒng)的高層次(High Level )用戶功能性需求。用例分析技術是一種需求合成技術，它利 用現(xiàn)有的需求獲取技術從客戶、原有系統(tǒng)、文檔中找到需求，記錄下來，然后從這些零散的 需求、特性中進行整理、提煉，從而建立用例模型。使用用例分析方法時可遵循以下步驟：1)識別系統(tǒng)參與者，確定誰會直接使用該系統(tǒng)。參與者是同系統(tǒng)交互的所有事物， 該角色不僅可以由人承擔，還可以是其它系統(tǒng)、硬件設備、甚至是時鐘。2)合并需求獲得用例。找到所有參與者之后，根據(jù)需求獲取所得到的用戶需求，定 義每個參

21、與者希望系統(tǒng)做什么，參與者希望系統(tǒng)作的每件事將成為一個用例。3)繪制用例圖。將所識別的參與者以及所定義的用例通過用例圖的形式整理出來， 以獲得例模型的框架。4)細化用例描述。用例描述包括以下幾個部分：用例名稱；用例參與者；用自然語言對用例進行簡要的描述;湖南創(chuàng)博龍智信息科技股份有限公司？版權所有？需求開發(fā)與管理過程描述參與者何時使用該用例，即用例的觸發(fā)條件；描述在一般情況下，參與者使用該用例時會發(fā)生什么事情，即用例的基本過程; 在基本過程的基礎上，考慮一些可變情況，把他們創(chuàng)建為擴展用例。需求分析工作完成之后所產(chǎn)生的工作成果都會錄入到CPMS系統(tǒng)。具體操作如下：1）明確需求模塊與需求元素：整理各

22、需求元素之間的關系，將功能類似的需求元素匯總到一起，此時這些匯總到一些的需求元素的集合可統(tǒng)稱為模塊，然后將這些集合按功能進行命名；明確各需求元素的優(yōu)先級、來源等屬性。2）模塊名與需求元素確定之后，下一步就是完善CPMS的需求庫：完善需求庫子目錄：在需求庫下一級建立目錄，這些目錄命名則是參考模塊的命名（右擊需求庫目錄建立目錄 輸入該目錄名稱）；完善需求庫文件：當需求庫子目錄按需求模塊建立完成之后，再根據(jù)需求元素與模塊對應關系，將與模塊相對應的需求元素錄入至子目錄下一級。（雙擊需求庫 點擊需求庫子目錄右擊需求庫子目錄建立文件 輸入與該子目錄對應的需求元素相關信息）需求定義需求定義的目的是根據(jù)需求獲

23、取和需求分析的結(jié)果，進一步定義軟件需求， 具體的需求元素都可以通過 CPMS進行查詢，最后將 CPMS當中所有的功能點按模塊進行匯總，最后 產(chǎn)生需求分析說明書。定義需求的優(yōu)先級需求分析師應確定每個需求的優(yōu)先級并寫入需求分析說明書，需求的優(yōu)先級的評價標準如下:級別定義判斷標準采取的措施高滿足以下任條時：1）需求實現(xiàn)的緊急程度為特急或緊急2）國家或行業(yè)法律法規(guī)、標準要求的，客戶明確 要求的，滿足正常業(yè)務必須的。對于這些需求在項目實施過程中需重 點投入資源，優(yōu)先實現(xiàn)，只有在這些 需求上達成一致意見，產(chǎn)品才會被接 受；必須完美地實現(xiàn)。通常這類需求 在當前版本必須實現(xiàn)。中滿足以下任意一條時：1）客戶隱含

24、要求，對正常業(yè)務影響程度不大2）需求實現(xiàn)的緊急程度為中3）支持必要的系統(tǒng)操作，實現(xiàn)這些需求將增強產(chǎn) 品的性能，是產(chǎn)品最終所要求的。這些需求必須被實現(xiàn)，但如果項目實 施中出現(xiàn)進度、資源等方面的沖突時， 如果有必要，可以延遲到下一版本； 需要付出努力，但不必做得太完美。低滿足以下任意一條時：1）功能或質(zhì)量上的附加功能；實現(xiàn)或不實現(xiàn)均可；可以在項目組有 較足夠的時間時考慮這些需求的實現(xiàn)湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？第9頁需求開發(fā)與管理過程2）實現(xiàn)這些需求會使產(chǎn)品更完美，若不實現(xiàn)也不影響產(chǎn)品的功能與性能，屬于錦上添花；3 ）需求實現(xiàn)的緊急程度為低；優(yōu)先級的定義有利于幫助項目組在項目的范圍

25、、 進度、資源、預算等相關制約因素之間 產(chǎn)生沖突時，能夠正確地對需求實現(xiàn)的范圍或?qū)崿F(xiàn)的優(yōu)先程度做出取舍。 一個實現(xiàn)這種權衡 的方法是：當接受一個新的高優(yōu)先級的需求或者其它項目環(huán)境變化時， 刪除低優(yōu)先級的需求， 或者把它們推遲到下一版本中去實現(xiàn)。編寫需求分析說明書需求分析師在需求分析過程中根據(jù)分析步驟逐步編制形成需求分析說明書（其中功能模塊在CPMS當中以需求庫的子目錄顯示，需求元素則是以文件顯示）。編寫需求規(guī)格說明書應遵循以下規(guī)則：根據(jù)客戶需求中的業(yè)務，抽象軟件系統(tǒng)功能、業(yè)務流程、對照產(chǎn)品組件等等；相關的需求都得到了識別與描述，以確保需求的完整性；各個需求之間不沖突，算法之間不相互矛盾，以確保

26、需求的一致性；正確描述系統(tǒng)需求，引用的資料有正規(guī)的出處，以確保需求的正確性；定義必要的術語，適當結(jié)合圖形、結(jié)構(gòu)圖等方式進行描述，以確保需求無二義性；使用較好的文檔結(jié)構(gòu)與需求標識，使需求能夠方便地與其它工作產(chǎn)品相對應，以確 保需求易于追溯；確保所描述的需求可以通過適當?shù)氖侄蔚玫津炞C，即需求的可測試性；考慮系統(tǒng)的接口；考慮了各個層次的需求，確定了需求的優(yōu)先級，以確保需求的可行性。需求確認需求確認是指項目組和客戶（或客戶代表）共同對需求分析說明書進行評審，評審 工作（評審會議通知、預審、過程記錄、評審總結(jié)等）都通過 CPMS系統(tǒng)進行統(tǒng)一管理。 需求確認包含兩個重要工作：需求評審”和 需求承諾”。需求

27、評審應對所形成的需求文檔進行評審，以便作為下一階段工作的基礎。需求評審的方式分為“會議評審”與“會簽”兩種。所有評審工作全部由CPMS進行管理。當需要召開技術評審會議時，由項目組成員在 CPMS中創(chuàng)建評審的內(nèi)容，然后按CPMS的流程進行相關評審工作。技術評審會議要求如下：評審組組織：評審管理組評審組成員：a）項目組代表b）部門經(jīng)理c）測試組代表d）公司的技術專家與業(yè)務專家e）客戶服務部門代表湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？第10頁需求開發(fā)與管理過程f） QA工程師輸入：需求分析說明書以及相關文檔輸出：評審記錄（CPMS中可查看評審過程的所有內(nèi)容） 檢查單：需求評審檢查單項目組根據(jù)需

28、求分析的進展情況，采用“會簽”的方式分階段對需求分析的階段成果進行評審，分階段評審可以將原本需要進行的大規(guī)模評審拆分成各個小規(guī)模的評審，降低了需求返工的風險，提高了評審的質(zhì)量。會簽評審要求： 評審組長：項目經(jīng)理；評審組成員：需求分析師、系統(tǒng)分析師、測試工程師，適當邀請組外專家參與； 輸入：需求分析說明書初稿，或用戶需求規(guī)格說明書 輸出：會簽記錄（CPMS中可查看評審過程的所有內(nèi)容） 檢查單：需求評審檢查單關于評審的具體要求詳見評審規(guī)程 。需求承諾項目經(jīng)理將評審通過的需求分析說明書提交給客戶（或客戶代表）、系統(tǒng)關聯(lián)項目組進行確認，確認的方式可以是以下方式之一：直接簽字：由承諾方在評審報告上直接簽

29、字或蓋章確認；郵件方式：由項目經(jīng)理將需求分析說明書與評審報告通過郵件發(fā)送給接收方，并明確確認通過的準則（如：如果在一周內(nèi)未予以回復則默認為確認通過）；發(fā)送會議紀要函：如果承諾方參加了評審會議并在會上達成了共識，則可以編制會議紀要在紀要中描述參加評審的人員、評審的結(jié)論等，并通過紀要函的方式發(fā)送給承諾方。建立需求基線項目的需求分析說明書經(jīng)過評審與確認后，除了將項目的需求分析說明書上傳至SVN的開發(fā)庫，還需要在 CPMS當中建立需求基線，并將與之有關聯(lián)的模塊進行勾選（項目 工作內(nèi)容 基線與版本 查看項目基線創(chuàng)建基線）。需求變更對一個項目來說，無論最初的需求分析有多么明確，開發(fā)過程中的需求變化也還是不可避免的。這主要有以下幾種原因：1）產(chǎn)品所應用的外部環(huán)境發(fā)生變化；2）隨著用戶對產(chǎn)品的熟悉和應用，又提出新的需求；3）項目組進行需求分析時未能徹底分析用戶的需求，或分析錯誤;4）用戶在開始時不能很全面的知道所需產(chǎn)品的功能。湖南創(chuàng)博龍智信息科技股份有限公司?版權所有？第11頁