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