我們知道現代項目管理的六要素是：時間、成本、質量、組織、范圍、客戶滿意度，實際上，要滿足這六個要素，計劃一個良好的需求分析是實現這六因素的前提，如果我們在項目生命周期的某些階段出了問題，而我們可能還不知道，這將影響整個項目周期，無論該計劃如何詳盡，如果需求有誤和需求分析不到位，項目的控制將沒有任何價值，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)編寫數據字典：在需求階段，很難使團隊的思路一致，建立一個合適的機制是完全必要的，這就是數據字典，數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確�？蛻襞c開發小組是使用一致的定義和術語。分析和設計工具通常包括數據字典組件。
3.2建立需求與產品質量的關系模型
需求是項目正確實施的一個前提,如果沒有抓住用戶的需求,那么很可能是漏洞百出，最終產品將不是一個真正的可交付物。我們知道，質量是一個客戶滿意度的一個主要因素，質量在項目中又有許多影響因素，這里我們著重從需求的角度出發來討論需求與質量的關系，那么如何來從需求的角度出發建立與質量的控制呢?
我們來建立一個思路如下：客戶所有的期望 需求產生 轉換矩陣 產品開發 可交付物 客戶滿意。在這里轉換矩陣就非常關鍵了，如何來實現需求與質量的關聯呢，可以通過質量功能調配(QFD)來實現，通過QFD可以把需求(用戶期望)、產品特性關聯起來，這里要用到一個工具：質量屋(House of Quality)，我現在用一個案例來說明這個工具，在做某市網上審批項目中，我們從客戶哪里收集和整理了許多需求：審批項目、報表要求、認證方式、工作流要求、數據范圍及格式、操作界面、醫藥管理規范等等;我們通過建立質量屋完成了需求與如何去實現，如下圖所示：
在QFD技術中以三種形式來定性地描述工程特征之間的相關影響關系，即正相關(向相同方向變化)、不相關和負相關(向相反方向變化)。對相關程度還可以進一步地細分為強相關、一般相關和弱相關幾種關系，并給以標度值來表達相關程度，這樣我們可以定義一些需求的強弱程度：如不確定需求、一般確定需求、強烈確定需求等，在這個HOQ中，還要用到其他技術工具，如：要素加權法等，這樣做的好處是主次分明，可以把需求分析和管理做到隨時間的推進客戶的變更變限于固定的框架里，符合如下曲線，而不至于走向極端。
3.3需求說明書編寫經驗談
目前需求說明書有固定的格式和要求,可以從專門介紹需求說明書的相關書籍中獲得,在本論文中,我著重闡述需求說明書的經驗，編寫優秀的是沒有公式化的方法的，這需要大量的經驗，要從你在過去的文檔中發現的問題學習。
1) 采用IT項目需求規格說明模版,要注意的是很多人拿來需求說明書模板就套用,這就有很大的風險,例如:會出現需求不全、需求范圍界定不到位、需求分類不明確等因素，我們應該把需求規格說明書拿來后先羅列許多要點：約定、法律法規、需求分類、技術限制、采用的技術和工具等等全面考慮，與項目干系人特別是用戶進行溝通，然后討論，可以采用頭腦風暴法和德爾菲方法來討論，確定說明書大綱，而不能照本著書。
2) 附加文檔的管理，值得注意的是需求說明書并非一成不變的，我們可以通過附加文檔來跟蹤用戶的新的需求和需求變更，這樣必須建立一個配套的文檔集合，隨時跟蹤需求，保證開發團體步進統一，一般這些文件是要考慮的：《需求(或功能)變更申請書》、《需求(或功能)變更規格書》、《需求清單一覽表》等。這樣做的好處是對需求時實監控，保證項目的安排，同時讓用戶知道變更是一件很嚴肅的事情，可以防止個別人提出無法界定的需求(因為現實IT項目中，很多問題是其他系統的遺留而又超出本項目技術線路可以彌補的問題等)。項目管理論壇
3) 編寫需求說明書的時候，可能還會遇到一些解決不了的需求，我們也一定用專門的章節要羅列出來，防止漏項，同時也利于我們在做實施計劃的時候來采取那種措施，采購其他設備、投入相關人力或其他辦法。
4) 需求必須要客戶確認，許多項目，可能開發商為了保護自己的“利益”很多事情都沒有得到客戶的確認，其實在需求階段，我們的需求是要跟客戶確認的，比如數據字典、界面選型、技術線路、功能模塊等，這樣做的好處是防止需求把握不得當，缺少了用戶必要的功能，另一個就是防止了開發商需求鍍金，提供了不必要的功能。
4 總結
經過以上各個方面來討論需求管理在整個項目生命期所起到的作用，結合自身的經驗，和一個案例《某市網上審批系統》綜合分析了需求管理的辦法和用到的工具，根據自身經驗提出編寫需求說明書要注意的地方。
文章來源于領測軟件測試網 http://www.k11sc111.com/
