1、項目管理體系文件需求開發與管理過程編 撰 人：TMO審 核 人：批 準 人：批準日期：2010-9-1保密級別：機密文檔版本：北京中軟國際信息技術有限公司版本歷史日期版本說明作者目 錄 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.術語和縮略語 PAGEREF _Toc272247919 h 4 HYPERLINK l _Toc272247920 1.4.相關文件 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.需求開發準備 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.選擇調研方法和技術 PAGEREF _Toc272247929 h 8 HYPERLINK l _Toc272247930 6.1.4.制訂需求調研計劃 PAGEREF _Toc272247930 h 9 HYPERLINK l _Toc272247931 6.1.5.編制需求調研問卷 PAGEREF _Toc272247931 h 10 HYPERLINK l _Toc272247932 6.2.需求調研 PAGEREF _Toc272247932 h 10 HYPERLINK l _Toc272247933 6.2.1.進行需求

5、調研 PAGEREF _Toc272247933 h 10 HYPERLINK l _Toc272247934 6.2.2.編寫用戶需求調研報告 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.定義需求的優先級 PAGEREF _Toc272247939 h 15 HYPERLINK l _Toc272247940 6.4.編寫需求規格說明書 PAGEREF _Toc272247940 h 15 HYPERLINK l _Toc272247941 6.5.評審需求規格說明書 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引言目的規范公司項目的需求開發和管理活動，以保證對客戶需求的正確理解，確保項目產物與需求的一致性。適用范圍適用于公司合同開發類項目、產品研發類項目的需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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