現代IT項目中的需求管理如何做？

領測軟體測試網

　　我們知道現代項目管理的六要素是：時間、成本、品質、組織、範圍、客戶滿意度，實際上，要滿足這六個要素，計劃一個良好的需求分析是實作這六因素的前提，如果我們在項目生命周期的某些階段出了問題，而我們可能還不知道，這将影響整個項目周期，無論該計劃如何詳盡，如果需求有誤和需求分析不到位，項目的控制将沒有任何價值，IT軟體項目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”(Leffingwell 1997)，從某種意義來講，項目的成功基于項目的需求管理的成功。

　　1　需求的定義及特點 項目管理者聯盟文章

　　根據IEEE項目工程标準詞彙表(1997)年中對需求的描述如下：業主解決問題或達到目的所需的條件或權能，和系統或系統部件要滿足合同、标準、規範或其他正式規定文檔所需具有的條件或權能。在PMBOK中，項目需求就是在“項目範圍”約定的。

　　需求最顯著的特點是“随着項目而改變、随着項目而漸進明晰”，項目管理的特點是随着進展而漸進明細化，可以看出需求管理和項目管理一樣，這就意味着需求在項目的整個生命周期都可能存在的，這樣項目管理的過程，也必不可少需求的管理。

　　2　如何擷取需求

　　獲得需求的方式可以有多種多樣：電話詢問、現場考察、聆聽使用者講解、閱讀使用者編制的相關檔案(如招标書)，其實這些方法都是GET方式，我們可以通過以下兩類技術手段來達到：GET(擷取)和PUSH(引導、回報、激發)互相結合的方式來得到我們真正的需求，而這兩個過程都是必須互動進行的，一般我們可以篩選一名非常有經驗(包括談判技巧、深厚的業務和技術背景、人緣很好、勤奮努力)的人士擔任需求工程師，長期在客戶那裡工作，他的工作主要是界定項目的範圍和需求變更管理，通過我們編制的各類模闆文檔來實作需求變更的控制;

　　一般來講IT內建需求包含三個不同的層次-業務需求、使用者需求和功能需求-也包括非功能需求:業務需求提供給客戶和産品開發商的新系統的最初利益,反映了組織機構或客戶對系統、産品高層次的目标要求，它們在項目視圖與範圍文檔中予以說明;使用者需求文檔描述了使用者使用産品必須要完成的任務，這在使用執行個體文檔或方案腳本說明中予以說明;功能需求定義了開發人員必須實作的軟體功能，使得使用者能完成他們的任務，進而滿足了業務需求，必須具備一定的業務背景和技術背景，能從三個不同的層次發掘客戶的需求。

　　根據我們在某市網上審批項目中的經驗，我們采用如下方法，其中每項工作都記錄文檔備案：如查閱了大量資料和病曆資料格式、各類應急防禦措施、統計分析報表、系統規劃書、舊系統業務狀況、曆史資料、還訪談了操作員的應用感受、多次技術交流、專題讨論等多種形式的互動式讨論和分析。這樣無論是業務、功能、使用者詳盡的期望我們都了解的比較透徹。

　　3　需求管理

　　擷取了需求接着要作的的工作就是對需求分析、消化和評審、基線制定、需求說明書制定，這裡我們主要集中在需求分析和需求說明書兩方面來。

　　3.1需求分析

　　1)建立需求關聯圖：需求關聯圖是用于定義系統與系統外部實體間的界限和接口的簡單模型，同時它也明确了通過接口的資訊流和物質流，通過關聯圖，對使用者需求的約定和确認以及CCB的評審都是非常關鍵的。

　　2)建立開發原型：建立使用者接口原型可以在如下應用如下情況：如果開發人員或使用者不能确定需求時，開發一個使用者接口原型，這樣使得許多概念和可能發生的事更為直覺明了。使用者通過評價原型将使項目參與者能更好地互相了解所要解決的問題。通過開發原形，業主和內建商都可以互相了解業務，發掘潛在的資訊，避免使用者需求的不必要變更。

　　3)分析可行性：分析需求可行性在允許的成本、性能要求下，分析每項需求實施的可行性，明确與每項需求實作相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙，這個主要用于内部評審和制定技術線路提供依據，如在什麼情況下采用.NET技術,什麼情況下采用J2EE技術,我們在2003年電子政務網上審批系統中充分對需求(業務、技術、使用者操作人員需求、現有系統需求等)做整體提取分析來确定技術線路的選型。

　　4)确定需求優先級：确定需求的優先級别應用分析方法來确定使用執行個體、産品特性或單項需求實作的優先級别。以優先級為基礎确定産品版本将包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。

　　5)為需求建立模型：為需求建立模型需求的圖形分析模型是軟體需求規格說明極好的補充說明。它們能提供不同的資訊與關系以有助于找到不正确的、不一緻的、遺漏的和備援的需求。這樣的模型包括資料流圖、實體關系圖、狀态變換圖、對話框圖、對象類及互動作用圖。

　　6)編寫資料字典：在需求階段，很難使團隊的思路一緻，建立一個合适的機制是完全必要的，這就是資料字典，資料字典是對系統用到的所有資料項和結構的定義，以確定開發人員使用統一的資料定義。在需求階段，資料字典至少應定義客戶資料項以確定客戶與開發小組是使用一緻的定義和術語。分析和設計工具通常包括資料字典元件。

　　3.2建立需求與産品品質的關系模型

　　需求是項目正确實施的一個前提,如果沒有抓住使用者的需求,那麼很可能是漏洞百出，最終産品将不是一個真正的可傳遞物。我們知道，品質是一個客戶滿意度的一個主要因素，品質在項目中又有許多影響因素，這裡我們着重從需求的角度出發來讨論需求與品質的關系，那麼如何來從需求的角度出發建立與品質的控制呢?

　　我們來建立一個思路如下：客戶所有的期望 需求産生 轉換矩陣 産品開發 可傳遞物 客戶滿意。在這裡轉換矩陣就非常關鍵了，如何來實作需求與品質的關聯呢，可以通過品質功能調配(QFD)來實作，通過QFD可以把需求(使用者期望)、産品特性關聯起來，這裡要用到一個工具：品質屋(House of Quality)，我現在用一個案例來說明這個工具，在做某市網上審批項目中，我們從客戶哪裡收集和整理了許多需求：審批項目、報表要求、認證方式、工作流要求、資料範圍及格式、操作界面、醫藥管理規範等等;我們通過建立品質屋完成了需求與如何去實作，如下圖所示：

　　在QFD技術中以三種形式來定性地描述工程特征之間的相關影響關系，即正相關(向相同方向變化)、不相關和負相關(向相反方向變化)。對相關程度還可以進一步地細分為強相關、一般相關和弱相關幾種關系，并給以标度值來表達相關程度，這樣我們可以定義一些需求的強弱程度：如不确定需求、一般确定需求、強烈确定需求等，在這個HOQ中，還要用到其他技術工具，如：要素權重法等，這樣做的好處是主次分明，可以把需求分析和管理做到随時間的推進客戶的變更變限于固定的架構裡，符合如下曲線，而不至于走向極端。

　　3.3需求說明書編寫經驗談

　　目前需求說明書有固定的格式和要求,可以從專門介紹需求說明書的相關書籍中獲得,在本論文中,我着重闡述需求說明書的經驗，編寫優秀的是沒有公式化的方法的，這需要大量的經驗，要從你在過去的文檔中發現的問題學習。

　　1) 采用IT項目需求規格說明模版,要注意的是很多人拿來需求說明書模闆就套用,這就有很大的風險,例如:會出現需求不全、需求範圍界定不到位、需求分類不明确等因素，我們應該把需求規格說明書拿來後先羅列許多要點：約定、法律法規、需求分類、技術限制、采用的技術和工具等等全面考慮，與項目幹系人特别是使用者進行溝通，然後讨論，可以采用頭腦風暴法和德爾菲方法來讨論，确定說明書大綱，而不能照本著書。

　　2) 附加文檔的管理，值得注意的是需求說明書并非一成不變的，我們可以通過附加文檔來跟蹤使用者的新的需求和需求變更，這樣必須建立一個配套的文檔集合，随時跟蹤需求，保證開發團體步進統一，一般這些檔案是要考慮的：《需求(或功能)變更申請書》、《需求(或功能)變更規格書》、《需求清單一覽表》等。這樣做的好處是對需求時實監控，保證項目的安排，同時讓使用者知道變更是一件很嚴肅的事情，可以防止個别人提出無法界定的需求(因為現實IT項目中，很多問題是其他系統的遺留而又超出本項目技術線路可以彌補的問題等)。項目管理論壇

　　3) 編寫需求說明書的時候，可能還會遇到一些解決不了的需求，我們也一定用專門的章節要羅列出來，防止漏項，同時也利于我們在做實施計劃的時候來采取那種措施，采購其他裝置、投入相關人力或其他辦法。

　　4) 需求必須要客戶确認，許多項目，可能開發商為了保護自己的“利益”很多事情都沒有得到客戶的确認，其實在需求階段，我們的需求是要跟客戶确認的，比如資料字典、界面選型、技術線路、功能子產品等，這樣做的好處是防止需求把握不得當，缺少了使用者必要的功能，另一個就是防止了開發商需求鍍金，提供了不必要的功能。

　　4　總結

　　經過以上各個方面來讨論需求管理在整個項目生命期所起到的作用，結合自身的經驗，和一個案例《某市網上審批系統》綜合分析了需求管理的辦法和用到的工具，根據自身經驗提出編寫需求說明書要注意的地方。

來源于領測軟體測試網 http://www.ltesting.net/