確定優先級：對觀點排出優先級也是非常重要的，它能夠幫助你識別出重大的風險，并為你在制定迭代計劃時提供指導。同樣，這項工作也應該由項目涉眾來確定。
調查主要業務邏輯：什么叫主要業務邏輯？包括了企業的主要業務流程、主要的業務規則、重大的算法。這些都是需要在一開始就十分明確的資料，需要在建模會議上了解清楚。當然，你不能對你的項目涉眾說，"這個，接下來，大家談一談主要的業務邏輯吧。"下面的涉眾一定摸不著頭腦。你還是應該引導涉眾，從涉眾的話語中捕捉你需要的信息。
注意會議時間：人不是機器，是會累的。所以控制好會議的長度很關鍵。一般，這種會議會有四五個小時，根據統計，兩個小時內的會議不會讓人產生疲勞感。所以應該把會議分成幾小段。另外，你還可以根據會議的進展來決定每小段會議參與的人數。因為，會議越往后，一些與會者就不太重要了。
避免細節：建模會議主要的目標是建立高階需求。如果把過多的時間花在討論雞毛蒜皮的小事，那就會浪費大家的時間。而在此時調查需求細節是沒有很大的意義的。因為你對很多的事情都還不了解，需要進一步的深入。這時候的細節對你并沒有太多的幫助。
回避技術：我在一次建模會議的時候，遇到一位負責技術的涉眾，他總是不停的詢問系統的技術架構，推銷他的設計理念。使得我不得不好幾次重申，"技術問題我們會單獨找時間談。"我想，那位技術人員應該是有比較好的理念，也很希望能夠表現一把，這點無可厚非。但是這個時候還不是討論技術的時候，需求尚未明確，討論技術實現不是本末倒置么？
做好記錄：俗話說，好記性不如爛筆頭。所以在會議上做好記錄是非常關鍵的。因為這種會議的代價相當高昂，你的項目涉眾不可能每天不干活，陪你開會的，就算他們肯，他們的老板也不肯。所以要充分利用好會議的成果，所以一個優秀的速記員絕對是必要的。另外，根據研究顯示，如果使用錄音機的話，會使得與會者心存芥蒂而不愿開口，所以，不要使用錄音機。
6. 測試
在需求的初始階段提到測試可能會覺得有些奇怪。凡是項目，總會有一個標準來考核是否成功。這里的測試指的是考核軟件項目是否成功的一個"執行性目標"。
這個目標將會是軟件開發最終要滿足的條件，軟件成功與否的判定標準。很多企業在信息化建設的時候沒有一個比較明確的目標。所以在被問道這方面的問題時，他的答案往往是我的目標是建成企業的ERP系統，建設企業的信息化平臺等空洞的話。這樣的軟件怎么開發？連結束的標準都沒有。是費用用完結束呢，還是決策者說停就停了呢。目標應該有一個可以量化的標準。例如，開發物流系統的目的是為了縮短產品周轉周期，降低庫存；開發供應鏈系統是為了加強和供應商的聯系，降低庫存。這些和具體業務有關的指標都是可以通過細化，用多種分指標來度量的，所以是可以做到的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
