論信息系統項目的需求管理和范圍管理

彭文

【摘 要】以某高校數字化圖書館信息管理系統集成項目開發為例，首先介紹了項目基本情況以及作者在其中所承擔的主要工作和職責介紹，詳細論述了對需求管理和范圍管理的認識及它們之間的區別與聯系，對項目范圍管理過程中采用的具體方法和工具作了闡述，結尾總結了從該項目中所獲得的寶貴經驗。

【關鍵詞】需求管理；范圍管理；信息化建設；圖書館；數字化；

中圖分類號：TP311 文獻標識碼：A

一、引言

本文作者在研讀《信息系統項目管理師》和PMBOK項目管理知識體系后，為了理論與實踐相結合，有幸作為某公司項目經理助理身份，參與了某高校數字化圖書館項目建設為例，探討項目需求管理和范圍管理在項目實施過程中的重要性，結合實例全面闡述項目需求與范圍管理過程，以及個人的經驗教訓。

二、項目背景、范圍、需求概況

2013年6月，我作為某公司的項目經理助理參與了某高校數字化圖書館的項目建設。該項目投資約500萬元，采用招標的方式進行。我公司為最終中標單位，該項目建設周期為3個月。該項目涉及到網絡建設、服務器集群、SAN存儲、應用軟件二次開發等方面，該項目跨專業，跨行業，屬于典型的信息系統集成項目，存在的風險高。

需求是指用戶對目標系統在功能、行為、性能、設計約束等方面的期望。需求工程包括需求開發和需求管理，是個不斷反復的需求定義、文檔記錄、需求演進的過程，可以劃分為：需求獲取、需求建模、形成需求規格、需求驗證、需求管理。而項目范圍則是為了達到項目的目標，為了交付具有某種特征的產品和服務，項目所規定要做的。范圍管理就是要確定哪些工作是項目應該做的，哪些工作不應該包括在項目里。首先通過需求開發來獲取項目需求，在此基礎上確定項目范圍，進行項目范圍管理。需求管理是對已批準的需求進行生命周期管理。只有通過需求分析過程之后才能確定項目的范圍，需求的并更會導致項目范圍的變更。針對業務需求不確定性高、項目范圍廣等特點，在需求管理和范圍管理中都采取了如下的措施：

三、用簡化的原型法來進行需求分析

需求分析對項目有舉足輕重的作用，充分的需求分析可以使得開發和測試更能夠了解客戶的需求，把一些技術難點和可能遇到的難點問題提出來，盡早解決，并且達到一致，避免項目后期返工，減少缺陷成本。為了做好需求分析，我們在該項目的需求分析中采用了簡化的原形法。

首先對業務需求《數字化圖書館信息系統業務需求文檔》進行快速的分析，弄清楚業務部門的對數字化圖書館信息系統的基本需求，詳細闡述該項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準，未來發展的接口預留等一個基本的業務需求規格說明，并提交給3名業務人員。由業務和開發人員共同討論確定初始需求的可用性，形成初步一致意見。接著在基本的業務需求規格說明上，搭建簡易的原型系統，該原型系統包括簡單的客戶端信息交互需求和業務邏輯處理服務，盡量仿真實際工作環境下的功能需求，要與實際系統的操作過程完全相同，由于圖書管理系統是現有系統的遷移，故考慮可用性但不用實現。最后由業務人員和開發人員共同評價和改進原型，最終完成了《數字化圖書館信息系統項目軟件需求規格說明書》，業務人員對該文檔進行了簽字確認。

四、工作分解結構WBS的滾動式規劃

工作分解結構WBS可以清晰的展示項目工作之間的相關關聯，在該項目的范圍規劃和管理中，我使用project 2010來進行WBS分解，分多個層次。第一層分解為計劃階段、需求分析、設計階段、編碼實施（包括編碼開發和單元測試）、集成測試、系統測試、驗收測試、試運行。第二層，針對各個階段再按照各個階段產出物的領域進行分解，如：需求分析分解為：頁面展示分析、功能流程分析、非功能性需求分析流程、運行維護需求；設計階段分解為：系統概要設計、系統詳細設計、數據庫表設計；編碼實施分解為：手機WEB客戶端、業務邏輯應用服務開發、交易網關改造；系統測試分解為：系統功能測試、系統性能測試；接著再向下分解。

當然工作分解結構也是個漸進明細的過程，需要滾動式規劃，剛開始進行規劃時設計、開發的工作包可以具體到每個人2-3個工作日的工作內容，但是系統測試、驗收測試的工作包只是做了大致的整體估算；但隨著項目實施的展開，當開發編碼工作進入尾期的時候，就可以對測試的工作包進行細化，當系統測試工作進入尾期的時候，就可以對驗收測試、試運行的工作包進行細化。分解的粒度逐步變小，總的原則就是能清晰計劃、估算、監控、管理項目具體執行工作為準。

五、建立縱向需求跟蹤矩陣，并定期審查跟蹤

需求跟蹤矩陣是在項目范圍管理和需求變更控制過程中一個一個非常有效的方法，但對于復雜項目來說建立和維護這個需求跟蹤矩陣的工作量是非常巨大、煩瑣的。我在該項目中平衡項目管理的投入和產出，分別建立用戶需求和系統設計、用戶需求和測試用例的需求跟蹤矩陣，簡化需求跟蹤矩陣的復雜度；對用戶需求、系統設計、測試用例都采用統一編號的方式，并采取分層編號方式，便于實現跟蹤和管理。針對不同的用戶需求，考慮需求、設計、代碼、測試用例的顆粒度大小。比如對于功能性需求的實現，設計一般細化到功能組件，代碼細化到具體的應用程序，測試用例則是一組測試用例的集合。通過適度的顆粒度降低需求跟蹤矩陣的復雜度。

六、制定需求變更流程來管理需求變更

需求管理和項目管理的一個核心內容就是需求和范圍的變更管理，需求管理會導致范圍變更，而范圍變更可能會造成需求無法實現或遺漏。我深知需求和范圍變更的好壞直接關系著項目的成敗，所以在項目規劃初期就成立了變更控制委員會CCB，由我、技術經理、業務經理、測試經理、配置管理員、質量管理員組成，并明確了通過Butterfly變更管理工具來管理變更流程。需求變更流程根據變更的嚴重程度來分層次進行管理和審批，變更可以分為：輕微變更、嚴重變更、極其嚴重變更。

我具體了解情況后，認識到項目成員對需求管理和范圍管理的認識和貫徹程度存在問題。于是我立即組織全體項目成員進行需求管理和范圍管理的培訓，并要求所有的需求和范圍變更都需要通過Butterfly變更管理工具來管理，經過變更影響評價后，由擁有不同層次批準權限的技術經理、項目經理助理和CBB來決定是否給予批準或拒絕。同時加大對變更請求的后續檢查，包括批準和拒絕的范圍。在項目例會上通報未經批準的變更，一定程度上保證了需求變更管理的實效，防止了項目范圍蔓延。

七、明確項目范圍說明書，并且不斷修改和優化

項目范圍說明書是項目最重要的文檔，它說明了為什么要進行這個項目，明確項目的目標和可交付成果，是業務需求部門和技術實施部門之間的協議基礎。主要包括：項目目標、項目可交付物、項目邊界、產品驗收標準、約束條件、項目的假定。主要是包括三方面內容：項目的合理性說明、項目的目標、項目的可交付物，在項目啟動后就應該盡快編寫出來，而且隨著項目的深入，不斷地堆項目范圍說明書進行修改和細化。通過上述的需求管理和范圍管理的措施及一些具體操作細節，數字化圖書館信息系統于2013年9月順利完成，得到了用戶方的肯定和好評。

【參考文獻】

[1]柳純錄.信息系統項目管理師教程[M].北京：清華大學出版社，2012.

[2]袁慧香.地質資料業務管理信息系統項目需求管理的過程與分析[D].中國地質大學（北京），2014.

[3]陳世昌.范圍管理在信息系統集成項目中的探討[J].經營管理者，2015，17：81.

[4]孫堯.信息系統集成項目中的范圍管理[D].北京郵電大學，2008.