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