一、 了解你的團隊和其他風險承擔者
系統(tǒng)需求工程師不單純是一個技術工作者，也應該是個很好的交際者。老外的書籍我并沒有看到過多關于“需求獲取中人際交往”的論述，大多是輕描談寫，但是在中國卻要把這個放在首位。我親眼見過甲方和乙方因為純個人性格問題導致需求會開得很緊張的場面。我們能對這種現象避而不談嗎?我曾經說過，在中國獲取需求最好的地方是在飯桌上，這種觀點老外會覺得不可思議。因此，不管是在需求獲取、分析還是管理整個過程中，系統(tǒng)需求工程師不能忽視與人打交道的過程，應該分析每個人的優(yōu)點缺點，有的放矢，為了獲取最終的需求有時要講究策略和戰(zhàn)術。在這個看似簡單的問題亦或是管理心理學的問題上恐怕我們這些習慣于搞技術的人需要學習一輩子。能讓大部分人在整個系統(tǒng)需求獲取和管理中都能和平相處也是系統(tǒng)需求工程師一項責任。
二、 學習即待開發(fā)系統(tǒng)的全部業(yè)務，了解得越深越好
通常情況下，系統(tǒng)需求工程師可能對待開發(fā)系統(tǒng)根本一點都不了解，隔行如隔山，熟悉目標單位的具體業(yè)務是較大的考驗，這也要求系統(tǒng)需求工程師善于學習。不僅僅是學習具體業(yè)務，還要學習行業(yè)業(yè)務，因為客戶代表提出的需求不一定是整個行業(yè)中最科學的最合理的需求，如果系統(tǒng)需求工程師能控制需求導向往正確合理的方向發(fā)展，其好處是多方面的，既有助于是客戶得到最好的業(yè)務需求又有利于軟件復用。
三、 獲得所有需求的模型和關聯圖
通過需求收集獲得的大多是口頭上或是文字表述的需求，這種需求映射到系統(tǒng)開發(fā)上是有偏差的，口頭上表達很容易的一項需求讓計算機實現有時會變得非常復雜。因此建立各種模型尤為重要，這種模型可能是由專業(yè)的需求分析員來做。同樣一個設計項目，兩個人做出來的可能完全不一樣，因為需求分析員對需求的理解可能不一樣。系統(tǒng)需求工程師應該有責任把好關，細微的差別是允許的，但決不能偏離最初需求的含義。
四、 獲得接口原型和數據字典
往往在獲取需求是客戶代表說這需要一個接口，需要使用其他系統(tǒng)的某些數據。但如何實施，有沒有政策法規(guī)和技術的壁壘呢，所以系統(tǒng)需求工程師不能把問題想得過于簡單。接口兩頭的系統(tǒng)經常是黑盒與黑盒的關系，事先必須設計接口原型，有條件的情況下需要進行測試，這些工作應該在設計之前就做。數據字典是人類和計算機模型之間的橋梁和紐帶，也是所有風險承擔者理解這個系統(tǒng)的統(tǒng)一規(guī)約，系統(tǒng)需求工程師在深入學習這些表述的同時有義務讓所有參與者明白一些重點詞匯、字段的含義。
五、 時刻不忘需求的優(yōu)先級和可行性分析論證
主次不分是大忌，開發(fā)任何一個項目都有重點和非重點，把力量向重點傾斜會取得令人滿意的結果，如果不分主次地盲目開發(fā)，設計者費了九牛二虎之力做出來的東西最后發(fā)現根本不是主要的。如果在需求分析階段就非常注意把需求分成等級，哪些是整個系統(tǒng)的核心，哪些是次要的或者不影響整個業(yè)務流程的，這對隨后的開發(fā)有著重要的意義。
六、 發(fā)現錯誤和遺漏立刻改正
作為系統(tǒng)需求工程師不能過于樂觀，要知道需求分析員和其他風險承擔者不是每個人都認真仔細閱讀和分析你的所有文檔。事實上大多數情況下他們不會承擔“沒有宏觀把握需求”這個責任，因此系統(tǒng)需求工程師有責任也有必要從大局著手來發(fā)現宏觀架構和細枝末節(jié)的錯誤，可以召集出一個團隊對設計好的全部“藍圖”召開幾次糾錯會，最好此時就把程序設計者和客戶代表也請過來。大家一起發(fā)現錯誤和遺漏的同時，也在達成一個潛在的共識，同時還加深了所有參與者對該項目的認識理解程度。我就見過因為一個小小的錯誤導致整個系統(tǒng)流轉出現問題的實例，其實這些錯誤完全可以在設計之初解決。
七、 抓住亮點和