确定优先级：对观点排出优先级也是非常重要的，它能够帮助你识别出重大的风险，并为你在制定迭代计划时提供指导。同样，这项工作也应该由项目涉众来确定。
调查主要业务逻辑：什么叫主要业务逻辑？包括了企业的主要业务流程、主要的业务规则、重大的算法。这些都是需要在一开始就十分明确的资料，需要在建模会议上了解清楚。当然，你不能对你的项目涉众说，"这个，接下来，大家谈一谈主要的业务逻辑吧。"下面的涉众一定摸不着头脑。你还是应该引导涉众，从涉众的话语中捕捉你需要的信息。
注意会议时间：人不是机器，是会累的。所以控制好会议的长度很关键。一般，这种会议会有四五个小时，根据统计，两个小时内的会议不会让人产生疲劳感。所以应该把会议分成几小段。另外，你还可以根据会议的进展来决定每小段会议参与的人数。因为，会议越往后，一些与会者就不太重要了。
避免细节：建模会议主要的目标是建立高阶需求。如果把过多的时间花在讨论鸡毛蒜皮的小事，那就会浪费大家的时间。而在此时调查需求细节是没有很大的意义的。因为你对很多的事情都还不了解，需要进一步的深入。这时候的细节对你并没有太多的帮助。
回避技术：我在一次建模会议的时候，遇到一位负责技术的涉众，他总是不停的询问系统的技术架构，推销他的设计理念。使得我不得不好几次重申，"技术问题我们会单独找时间谈。"我想，那位技术人员应该是有比较好的理念，也很希望能够表现一把，这点无可厚非。但是这个时候还不是讨论技术的时候，需求尚未明确，讨论技术实现不是本末倒置么？
做好记录：俗话说，好记性不如烂笔头。所以在会议上做好记录是非常关键的。因为这种会议的代价相当高昂，你的项目涉众不可能每天不干活，陪你开会的，就算他们肯，他们的老板也不肯。所以要充分利用好会议的成果，所以一个优秀的速记员绝对是必要的。另外，根据研究显示，如果使用录音机的话，会使得与会者心存芥蒂而不愿开口，所以，不要使用录音机。
6. 测试
在需求的初始阶段提到测试可能会觉得有些奇怪。凡是项目，总会有一个标准来考核是否成功。这里的测试指的是考核软件项目是否成功的一个"执行性目标"。
这个目标将会是软件开发最终要满足的条件，软件成功与否的判定标准。很多企业在信息化建设的时候没有一个比较明确的目标。所以在被问道这方面的问题时，他的答案往往是我的目标是建成企业的ERP系统，建设企业的信息化平台等空洞的话。这样的软件怎么开发？连结束的标准都没有。是费用用完结束呢，还是决策者说停就停了呢。目标应该有一个可以量化的标准。例如，开发物流系统的目的是为了缩短产品周转周期，降低库存；开发供应链系统是为了加强和供应商的联系，降低库存。这些和具体业务有关的指标都是可以通过细化，用多种分指标来度量的，所以是可以做到的。
文章来源于领测软件测试网 https://www.ltesting.net/
