可以看出，业务建模在ERP工程中被着重强调，而且ERP中的BPR已经成为一门独立的学科。不仅如此，即便是在普通的信息系统中，业务建模也是非常重要的，所不同的，仅仅是它们的规模而已。这一点上，可能大家会不理解，如果你只是为企业的业务自动化建立应用，直接照搬企业模式不就行了吗。这里有两点原因，一是企业原有的业务模式在以人为主的环境中可能运行的很好，可是把这套模式原本不动的搬到计算机上就未必会适合了。人的能力和计算机的能力有很大的出入，所以流程必须经过调整以适应计算机；第二个原因是上面已经提到过的避免产生部门级的，部分功能区域的应用系统。
在RUP中，业务建模被作为下游流程的输入重点强调：业务模型是需求工作流程的一种重要输入，用来了解对系统的需求。业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。（RUP）
3. 需求和业务建模
业务建模是需求工程中最初始的阶段，也是整个项目的初始阶段。需要指出的是，业务建模时间的跨度在不同的项目中有很大的差别的。在有些项目中，例如大型ERP系统，可能需要几个月的时间。而对于普通的项目，业务建模的时间可能仅仅需要几天的时间。
需求是技术无关（technology independent）的。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。技术的实现细节是在后面的分析、设计阶段才需要考虑的事情。而在业务建模阶段，不但要保证需求的技术无关性，还要保证你的需求不要深入细节。因为在业务建模阶段，最重要的事情就是要了解业务的全貌，深入细节会浪费时间和精力。要知道，讨论一个企业里的业务细节，就算给你一个月的时间也没必能够结束。
在实际中，这两点都是很难做到的。例如企业原先有一个系统，这就不得不由你讨论和新旧系统的兼容问题。这时候就要注意，如果你是讨论就有系统的架构的话，那还是属于技术无关的范畴，如果你一旦进而讨论各具体模块/组件的细节，那就非但不是技术无关，而且也深入细节了。在不深入细节的问题上，往往你很难禁止项目涉众（Stakeholder）①不去讨论一些相关的业务细节。这个时候你可以将这些细节记录下来，然后再回到业务建模上。
①A stakeholder is defined as anyone who is materially affected by the outcome of the project.
涉众是所有会受到项目结果重大影响的人。
4. 业务建模时期的主要任务
项目涉众的共同愿景：要想项目成功，可离不开项目涉众的支持。在项目一开始，不论是项目涉众还是开发人员，对项目的任务、范围都是模糊不清的。但随着项目的深入，原来模糊的景象会慢慢清晰、立体起来。但是为了不浪费时间，我们有必要在项目射入之前，现在项目涉众中竖立一个共同的愿景。
共同愿景的竖立可没有想象中的那么简单，因为每位涉众都关心自己的利益，都有自己的评判标准。你可以把大家的意见都列在白板上，然后逐项集中讨论，做出修正，直到大家的意见一致的时候为止。在共同远景的竖立过程中，其实有两件事情也已经同时做了，项目范围（scope）和高阶（high-level）需求。
文章来源于领测软件测试网 https://www.ltesting.net/
