2013年參與某能源集團的資訊化平台建設，更多的負責了前期的調研工作和設計工作，當然也還在繼續編碼。在和客戶的溝通交流過程中積累了一些需求調研方面的經驗，恰逢年終總結之計給自己整理總結，也希望能夠給後來者提供一些幫助。
一、認清需求工程
需求工程，需求的調研過程是一個系統性的工程，既然是系統性的工程就要遵循一定的規律和工程學方法。
需求工程幾乎涉及到所有的項目幹系人，會涉及到跨公司、跨部門的協作，而且由于人對事物的認知是不斷趨向于正确的(複雜多變)，是以需求工程是一項極其複雜的工作。認清需求工作的困難性，擺正确自己的态度是成功的第一步。需求工程切記客戶說什麼記錄什麼，然後拿着記錄的文檔回去就組織後續工作，這會使後期的工作萬劫不複。
從上而下大方向調研：對于整個資訊化系統而言，系統級别的範圍的界定，是從上而下的，這種調研對象應該是集團資訊化一把手。這個範圍的界定應該在簽訂項目合同的時候就已經達成共識了。接下來子子產品的功能，就需要和相關部門幹系人進行确認了。是以在調研的初始階段，應該是從上而下的。
從下而上小細節确認：從上而下這一過程完成後，對整個系統的思路和整體方向就了把握。當然這還遠遠不足以形成文檔，我們還需要跟操作層進行細節調研。操作層對于某一細節領域會更具有權威，他們會提供一些具體的資料，盡量保持這些資料(單據、報表等)是有内容的。
二、需求工程的周期
需求工程是複雜的，是以我們需要了解需求工程的周期，把握其規律。
入下圖所示，我們常說的需求調研是分為很多個過程的。我在剛剛開始做需求方面工作的時候，客戶在描述需求的時候，我總是不自覺的把需求轉化為“界面原型”和“具體的業務事件”，後來被同僚批評了。他告訴我，需求調研和需求分析是兩個過程，調研的時候先多去了解客戶提出的問題，搜集資料等，先不着急去做分析。因為在不了解整體情況的時候，你的分析可能是有偏差的。是以，調研的時候就應該已調研為主，拿到較為全面的第一手資料之後，在開始進行分析。
分析的過程中，可能為産生業務流程圖和業務模型，甚至簡易的操作界面也會出來。注意，我們的分析一定是有成果的，而不是和客戶簡單的達成口頭共識。分析出來之後，就需要組織客戶進行确認了，這個會是一個反複的過程。随着項目幹系人的認知提高，PDCA戴明循環螺旋上升。對于分析輸出成果沒有問題了，就要和客戶簽字确認了。
和客戶簽字确認完之後，公司内部對需求進行評審，評審完畢之後，開始進去其他項目階段。也開始了需求變更的管理。
三、需求工程過程的把控
開始開發之後，需求也是會發生變更的，是以我們需要需求過程多的管理。公司今年新來的以前做外包的同僚，認為變更是管理不到位，對這種變更他是深惡痛絕的。當然人人都是深惡痛絕，但是需求變更隻能減少，不能消除。需求變更後，要及時的調整計劃和需求規格說明書等等。
四、需求工程與開發的銜接
需求通過内部評審後，進入開發階段。開發過程中碰到需求變更不要立馬就去改動，要權衡着去調整。
五、需求工程與測試及驗收的銜接
需求規格說明書出來後，可以開始編寫測試計劃和用例。由于需求說明書是甲方和乙方幹系人的共識，是以在項目驗收或驗收的時候也要适當以此作為依據。
以上是今年工作中的大緻總結，後期會慢慢完善，并且寫的更加詳細一些。