工程項目需求擷取的幾種方法及其适用環境

    我們知道，一個工程項目，如果從開發方（即承建方）和使用者方（即建設方）對需求的清楚程度來分，大緻可以分為如下四種：開發方和使用者方都清楚項目需求、開發方不清楚項目需求但使用者方清楚、開發方和使用者方都不清楚項目需求、開發方清楚項目需求但使用者方不清楚。

針對這四種類型的項目，我總結出四種對應的需求擷取方法：問卷調查法、會議讨論法、界面原型法和可運作原型系統法。

　　以下逐一解析之。

　　一、問卷調查法

　　所謂“問卷調查法”，是指開發方就使用者需求中的一些個性化的、需要進一步明确的需求（或問題），通過采用向使用者發問卷調查表的方式，達到徹底弄清項目需求的一種需求擷取方法。

　　這種方法适合于開發方和使用者方都清楚項目需求的情況。因為開發方和建設方都清楚項目的需求，則需要雙方進一步溝通的需求（或問題）就比較少，通過采用這種簡單的問卷調查方法就能使問題得到較好的解決。

　　這種方法的一般操作步驟是：

　　步驟一、開發方先根據合同和以往類似項目的經驗，整理出一份《使用者需求說明書》和待澄清需求（或問題）的《問卷調查表》送出給使用者；

　　步驟二、使用者閱讀《使用者需求說明書》，并回答《問卷調查表》中提出的問題，如果《使用者需求說明書》中有描述不正确或未包括的需求，使用者可一并修改或補充；

　　步驟三、開發方拿到使用者傳回的《使用者需求說明書》和《問卷調查表》進行分析，如仍然有問題，則重複步驟二，否則執行步驟四；

　　步驟四、開發方整理出《使用者需求說明書》，送出給使用者方确認簽字。

　　由于這種方法比較簡單、側重點明确，是以能大大縮短需求擷取的時間、減少需求擷取的成本、送出工作效率。

　　二、會議讨論法

　　所謂“會議讨論法”，是指開發方和使用者方召開若幹次需求讨論會議，達到徹底弄清項目需求的一種需求擷取方法。

　　這種方法适合于開發方不清楚項目需求（一般開發方是剛開始做這種業務類型的工程項目）但使用者方清楚項目需求的情況。因為使用者清楚項目的需求，則使用者能準确地表達出他們的需求，而開發方有專業的軟體開發經驗，對使用者提供的需求一般都能準确地描述和把握。

　　這種方法的一般操作步驟是：

　　步驟一、開發方根據雙方制定的《需求調研計劃》召開相關需求主題溝通會；

　　步驟二、會後開發方整理出《需求調研記錄》送出給使用者方确認；

　　步驟三、如果此主題還有未明确的問題則再次溝通，否則開始下一主題；

　　步驟四、所有需求都溝通清楚後，開發方根據曆次《需求調研記錄》整理出《使用者需求說明書》，送出給使用者方确認簽字。

　　由于開發方不清楚項目需求，是以需要花較多的時間和精力進行需求調研和需求整理工作。

　　三、界面原型法

　　所謂“界面原型法”，是指開發方根據自己所了解的使用者需求，描畫出應用系統的功能界面後與使用者進行交流和溝通，通過“界面原型”這一載體，達到雙方逐漸明确項目需求的一種需求擷取的方法。

　　這種方法比較适合于開發方和使用者方都不清楚項目需求的情況。因為開發方和使用者方都不清楚項目需求，是以此時就更需要借助于一定的“載體”來加快對需求的挖掘和雙方對需求了解。這種情況下，采用“可視化”的界面原型法比較可取。

　　這種方法的一般操作步驟是：

　　步驟一、開發方根據其所了解到的需求（如通過合同或與使用者交流），采用界面制作工作描畫出應用系統的功能界面；

　　步驟二、将應用系統的功能界面送出給使用者并與使用者溝通，挖掘出新需求或就需求達成了解上的一緻；

　　步驟三、開發方就不斷擷取的需求進行增量式整理，根據新的需求豐富和細化界面原型；

　　步驟四、雙方經過多次界面原型的互動，開發方最終整理出《使用者需求說明書》，送出給使用者方确認簽字。

　　由于開發方和使用者方都不清楚項目需求，是以此時需求擷取工作将會比較困難，可能導緻的風險也比較大。采用這種“界面原型”的方式，能加速項目需求的“浮現”和雙方對需求的一緻了解，進而減小由于需求問題可能給項目帶來的風險。

　　針對這種類型的項目，我們也可以采用下面将要介紹的“可運作原型系統法”，但由于開發方對需求不了解（證明以前缺乏類似項目的開發經驗和産品積累），如果開發一個可運作的原型系統，則幾乎需要從零開始編寫代碼，前期投入會很大。

　　四、可運作原型系統法

　　所謂“可運作原型系統法”，是指開發方根據合同中規定的基本需求，在以往類似項目應用系統的基礎上進行少量修改得出一可運作系統，通過“可運作原型系統”這一載體，達到徹底挖掘項目需求的一種需求擷取的方法。

　　這種方法比較适合于開發方清楚項目需求但使用者方不清楚項目需求的情況。這種類型的項目，開發方一般都有類似項目的建設經驗，是以可以在以往項目的基礎上，快速“建構”出一可運作系統，然後借助于這一“載體”來加快對需求的挖掘和雙方（特别是使用者方）對需求的了解。這種情況下，采用“所見即所得”的可運作原型系統法比較可取。

　　這種方法的一般操作步驟是：

　　步驟一、開發方根據其所了解到的需求（如通過合同或與使用者交流），在以往類似項目的基礎上，快速“建構”出一可運作系統；

　　步驟二、通過向使用者示範“可運作原型系統”，逐漸挖掘并讓使用者确認項目需求；

　　步驟三、開發方就不斷擷取的需求進行增量式整理，根據新的需求豐富可運作原型系統；

　　步驟四、雙方經過多次可運作原型系統的互動，開發方最終整理出《使用者需求說明書》，送出給使用者方确認簽字。

　　由于開發方清楚使用者的需求（證明以前有類似項目的開發經驗和産品積累），但使用者方自己不清楚，是以此時開發一個“可運作原型系統”，開發方的投入不會很大，但對于使用者了解和确認項目需求非常有利，是以針對這種類型的項目這是一種比較理想的需求擷取方式。

　　這種方法的另一個好處是：正式系統一般可以在該“可運作原型系統”的基礎上演化而成，為後續開發工作節省不少的工作量和成本。

　　值得注意的是，以上總結出的這四種需求擷取方法不是互斥的，我們可以根據項目的實際特點獨立應用或組合應用。

　　“忙碌，不代表有效率；方法，遠勝于苦幹”。但願我們從事軟體項目開發的朋友們，都能掌握好恰當的方法，以圖能獲得“事半功倍”的效果。