我們知道現代項目管理的六要素是：時(shí)間、成本、質(zhì)量、組織、范圍、客戶(hù)滿(mǎn)意度，實(shí)際上，要滿(mǎn)足這六個(gè)要素，計劃一個(gè)良好的需求分析是實(shí)現這六因素的前提，如果我們在項目生命周期的某些階段出了問(wèn)題，而我們可能還不知道，這將影響整個(gè)項目周期，無(wú)論該計劃如何詳盡，如果需求有誤和需求分析不到位，項目的控制將沒(méi)有任何價(jià)值，IT軟件項目中百分之四十至百分之六十的問(wèn)題都是在需求分析階段埋下的“禍根”(Leffingwell 1997)，從某種意義來(lái)講，項目的成功基于項目的需求管理的成功。
1 需求的定義及特點(diǎn) 項目管理者聯(lián)盟文章
根據IEEE項目工程標準詞匯表(1997)年中對需求的描述如下：業(yè)主解決問(wèn)題或達到目的所需的條件或權能，和系統或系統部件要滿(mǎn)足合同、標準、規范或其他正式規定文檔所需具有的條件或權能。在PMBOK中，項目需求就是在“項目范圍”約定的。
需求最顯著(zhù)的特點(diǎn)是“隨著(zhù)項目而改變、隨著(zhù)項目而漸進(jìn)明晰”，項目管理的特點(diǎn)是隨著(zhù)進(jìn)展而漸進(jìn)明細化，可以看出需求管理和項目管理一樣，這就意味著(zhù)需求在項目的整個(gè)生命周期都可能存在的，這樣項目管理的過(guò)程，也必不可少需求的管理。
2 如何獲取需求
獲得需求的方式可以有多種多樣：電話(huà)詢(xún)問(wèn)、現場(chǎng)考察、聆聽(tīng)用戶(hù)講解、閱讀用戶(hù)編制的相關(guān)文件(如招標書(shū))，其實(shí)這些方法都是GET方式，我們可以通過(guò)以下兩類(lèi)技術(shù)手段來(lái)達到：GET(獲取)和PUSH(引導、反饋、激發(fā))相互結合的方式來(lái)得到我們真正的需求，而這兩個(gè)過(guò)程都是必須交互進(jìn)行的，一般我們可以篩選一名非常有經(jīng)驗(包括談判技巧、深厚的業(yè)務(wù)和技術(shù)背景、人緣很好、勤奮努力)的人士擔任需求工程師，長(cháng)期在客戶(hù)那里工作，他的工作主要是界定項目的范圍和需求變更管理，通過(guò)我們編制的各類(lèi)模板文檔來(lái)實(shí)現需求變更的控制;
一般來(lái)講IT集成需求包含三個(gè)不同的層次-業(yè)務(wù)需求、用戶(hù)需求和功能需求-也包括非功能需求:業(yè)務(wù)需求提供給客戶(hù)和產(chǎn)品開(kāi)發(fā)商的新系統的最初利益,反映了組織機構或客戶(hù)對系統、產(chǎn)品高層次的目標要求，它們在項目視圖與范圍文檔中予以說(shuō)明;用戶(hù)需求文檔描述了用戶(hù)使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例文檔或方案腳本說(shuō)明中予以說(shuō)明;功能需求定義了開(kāi)發(fā)人員必須實(shí)現的軟件功能，使得用戶(hù)能完成他們的任務(wù)，從而滿(mǎn)足了業(yè)務(wù)需求，必須具備一定的業(yè)務(wù)背景和技術(shù)背景，能從三個(gè)不同的層次發(fā)掘客戶(hù)的需求。
根據我們在某市網(wǎng)上審批項目中的經(jīng)驗，我們采用如下方法，其中每項工作都記錄文檔備案：如查閱了大量資料和病歷資料格式、各類(lèi)應急防御措施、統計分析報表、系統規劃書(shū)、舊系統業(yè)務(wù)狀況、歷史資料、還訪(fǎng)談了操作員的應用感受、多次技術(shù)交流、專(zhuān)題討論等多種形式的交互式討論和分析。這樣無(wú)論是業(yè)務(wù)、功能、用戶(hù)詳盡的期望我們都了解的比較透徹。
3 需求管理
獲取了需求接著(zhù)要作的的工作就是對需求分析、消化和評審、基線(xiàn)制定、需求說(shuō)明書(shū)制定，這里我們主要集中在需求分析和需求說(shuō)明書(shū)兩方面來(lái)。
3.1需求分析
1)建立需求關(guān)聯(lián)圖：需求關(guān)聯(lián)圖是用于定義系統與系統外部實(shí)體間的界限和接口的簡(jiǎn)單模型，同時(shí)它也明確了通過(guò)接口的信息流和物質(zhì)流，通過(guò)關(guān)聯(lián)圖，對用戶(hù)需求的約定和確認以及CCB的評審都是非常關(guān)鍵的。
2)創(chuàng )建開(kāi)發(fā)原型：創(chuàng )建用戶(hù)接口原型可以在如下應用如下情況：如果開(kāi)發(fā)人員或用戶(hù)不能確定需求時(shí)，開(kāi)發(fā)一個(gè)用戶(hù)接口原型，這樣使得許多概念和可能發(fā)生的事更為直觀(guān)明了。用戶(hù)通過(guò)評價(jià)原型將使項目參與者能更好地相互理解所要解決的問(wèn)題。通過(guò)開(kāi)發(fā)原形，業(yè)主和集成商都可以相互了解業(yè)務(wù)，發(fā)掘潛在的信息，避免用戶(hù)需求的不必要變更。
3)分析可行性：分析需求可行性在允許的成本、性能要求下，分析每項需求實(shí)施的可行性，明確與每項需求實(shí)現相聯(lián)系的風(fēng)險，包括與其它需求的沖突，對外界因素的依賴(lài)和技術(shù)障礙，這個(gè)主要用于內部評審和制定技術(shù)線(xiàn)路提供依據，如在什么情況下采用.NET技術(shù),什么情況下采用J2EE技術(shù),我們在2003年電子政務(wù)網(wǎng)上審批系統中充分對需求(業(yè)務(wù)、技術(shù)、用戶(hù)操作人員需求、現有系統需求等)做整體提取分析來(lái)確定技術(shù)線(xiàn)路的選型。
4)確定需求優(yōu)先級：確定需求的優(yōu)先級別應用分析方法來(lái)確定使用實(shí)例、產(chǎn)品特性或單項需求實(shí)現的優(yōu)先級別。以?xún)?yōu)先級為基礎確定產(chǎn)品版本將包括哪些特性或哪類(lèi)需求。當允許需求變更時(shí)，在特定的版本中加入每一項變更，并在那個(gè)版本計劃中作出需要的變更。
5)為需求建立模型：為需求建立模型需求的圖形分析模型是軟件需求規格說(shuō)明極好的補充說(shuō)明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對話(huà)框圖、對象類(lèi)及交互作用圖。
6)編寫(xiě)數據字典：在需求階段，很難使團隊的思路一致，建立一個(gè)合適的機制是完全必要的，這就是數據字典，數據字典是對系統用到的所有數據項和結構的定義，以確保開(kāi)發(fā)人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶(hù)數據項以確�？蛻�(hù)與開(kāi)發(fā)小組是使用一致的定義和術(shù)語(yǔ)。分析和設計工具通常包括數據字典組件。
3.2建立需求與產(chǎn)品質(zhì)量的關(guān)系模型
需求是項目正確實(shí)施的一個(gè)前提,如果沒(méi)有抓住用戶(hù)的需求,那么很可能是漏洞百出，最終產(chǎn)品將不是一個(gè)真正的可交付物。我們知道，質(zhì)量是一個(gè)客戶(hù)滿(mǎn)意度的一個(gè)主要因素，質(zhì)量在項目中又有許多影響因素，這里我們著(zhù)重從需求的角度出發(fā)來(lái)討論需求與質(zhì)量的關(guān)系，那么如何來(lái)從需求的角度出發(fā)建立與質(zhì)量的控制呢?
我們來(lái)建立一個(gè)思路如下：客戶(hù)所有的期望 需求產(chǎn)生 轉換矩陣 產(chǎn)品開(kāi)發(fā) 可交付物 客戶(hù)滿(mǎn)意。在這里轉換矩陣就非常關(guān)鍵了，如何來(lái)實(shí)現需求與質(zhì)量的關(guān)聯(lián)呢，可以通過(guò)質(zhì)量功能調配(QFD)來(lái)實(shí)現，通過(guò)QFD可以把需求(用戶(hù)期望)、產(chǎn)品特性關(guān)聯(lián)起來(lái)，這里要用到一個(gè)工具：質(zhì)量屋(House of Quality)，我現在用一個(gè)案例來(lái)說(shuō)明這個(gè)工具，在做某市網(wǎng)上審批項目中，我們從客戶(hù)哪里收集和整理了許多需求：審批項目、報表要求、認證方式、工作流要求、數據范圍及格式、操作界面、醫藥管理規范等等;我們通過(guò)建立質(zhì)量屋完成了需求與如何去實(shí)現，如下圖所示：
在QFD技術(shù)中以三種形式來(lái)定性地描述工程特征之間的相關(guān)影響關(guān)系，即正相關(guān)(向相同方向變化)、不相關(guān)和負相關(guān)(向相反方向變化)。對相關(guān)程度還可以進(jìn)一步地細分為強相關(guān)、一般相關(guān)和弱相關(guān)幾種關(guān)系，并給以標度值來(lái)表達相關(guān)程度，這樣我們可以定義一些需求的強弱程度：如不確定需求、一般確定需求、強烈確定需求等，在這個(gè)HOQ中，還要用到其他技術(shù)工具，如：要素加權法等，這樣做的好處是主次分明，可以把需求分析和管理做到隨時(shí)間的推進(jìn)客戶(hù)的變更變限于固定的框架里，符合如下曲線(xiàn)，而不至于走向極端。
3.3需求說(shuō)明書(shū)編寫(xiě)經(jīng)驗談
目前需求說(shuō)明書(shū)有固定的格式和要求,可以從專(zhuān)門(mén)介紹需求說(shuō)明書(shū)的相關(guān)書(shū)籍中獲得,在本論文中,我著(zhù)重闡述需求說(shuō)明書(shū)的經(jīng)驗，編寫(xiě)優(yōu)秀的是沒(méi)有公式化的方法的，這需要大量的經(jīng)驗，要從你在過(guò)去的文檔中發(fā)現的問(wèn)題學(xué)習。
1) 采用IT項目需求規格說(shuō)明模版,要注意的是很多人拿來(lái)需求說(shuō)明書(shū)模板就套用,這就有很大的風(fēng)險,例如:會(huì )出現需求不全、需求范圍界定不到位、需求分類(lèi)不明確等因素，我們應該把需求規格說(shuō)明書(shū)拿來(lái)后先羅列許多要點(diǎn)：約定、法律法規、需求分類(lèi)、技術(shù)限制、采用的技術(shù)和工具等等全面考慮，與項目干系人特別是用戶(hù)進(jìn)行溝通，然后討論，可以采用頭腦風(fēng)暴法和德?tīng)柗品椒▉?lái)討論，確定說(shuō)明書(shū)大綱，而不能照本著(zhù)書(shū)。
2) 附加文檔的管理，值得注意的是需求說(shuō)明書(shū)并非一成不變的，我們可以通過(guò)附加文檔來(lái)跟蹤用戶(hù)的新的需求和需求變更，這樣必須建立一個(gè)配套的文檔集合，隨時(shí)跟蹤需求，保證開(kāi)發(fā)團體步進(jìn)統一，一般這些文件是要考慮的：《需求(或功能)變更申請書(shū)》、《需求(或功能)變更規格書(shū)》、《需求清單一覽表》等。這樣做的好處是對需求時(shí)實(shí)監控，保證項目的安排，同時(shí)讓用戶(hù)知道變更是一件很?chē)烂C的事情，可以防止個(gè)別人提出無(wú)法界定的需求(因為現實(shí)IT項目中，很多問(wèn)題是其他系統的遺留而又超出本項目技術(shù)線(xiàn)路可以彌補的問(wèn)題等)。項目管理論壇
3) 編寫(xiě)需求說(shuō)明書(shū)的時(shí)候，可能還會(huì )遇到一些解決不了的需求，我們也一定用專(zhuān)門(mén)的章節要羅列出來(lái)，防止漏項，同時(shí)也利于我們在做實(shí)施計劃的時(shí)候來(lái)采取那種措施，采購其他設備、投入相關(guān)人力或其他辦法。
4) 需求必須要客戶(hù)確認，許多項目，可能開(kāi)發(fā)商為了保護自己的“利益”很多事情都沒(méi)有得到客戶(hù)的確認，其實(shí)在需求階段，我們的需求是要跟客戶(hù)確認的，比如數據字典、界面選型、技術(shù)線(xiàn)路、功能模塊等，這樣做的好處是防止需求把握不得當，缺少了用戶(hù)必要的功能，另一個(gè)就是防止了開(kāi)發(fā)商需求鍍金，提供了不必要的功能。
4 總結
經(jīng)過(guò)以上各個(gè)方面來(lái)討論需求管理在整個(gè)項目生命期所起到的作用，結合自身的經(jīng)驗，和一個(gè)案例《某市網(wǎng)上審批系統》綜合分析了需求管理的辦法和用到的工具，根據自身經(jīng)驗提出編寫(xiě)需求說(shuō)明書(shū)要注意的地方。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
