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