同时这里作者的一个观点我是同意的，就是有些时候需求不清楚，是由于如何实现需求不被我们理解。但是问题在于具体的业务实现是不可能被你提前完全的解释的。你只能在现实的环境中去针对性的达成业务过程。而实际上解决这个问题工具就是我前面提到的分析模型和业务规则库。你要作的是依照客户的实际情况，对于分析模型进行裁减，再比对规则库进行建立现实化的需求模型。
比如我们要设计一个会计程序，我们会发现其分析模型是再中外都基本一致的。但是由于国内外的政策和法律等方面的原因，规则会不同。那么这个时候你要作的是同时维护两个基于业务过程的模型，还是维护一个分析模型和一套包括中外不同国家的会计领域的规则库呢？而同时我们还知道，由于法律和社会习惯的原因，规则是会发生变化的，那么是不是你的那个基于业务流程的模型也需要不断的随之全面性的变化呢？而不是向你实现分析模型和规则库的分离。同时我们还要考虑到规则的变化很少会发生全面的变化，那么维护一个规则库实际上就只是在环境变化时，去修改个别的规则。
同时作者最后还犯了一个根本性的错误，认为对于业务不了解就不能建模。他看来完全的忽略了建模的一个目的就是去了解业务，或者说了解业务就是从建模开始的。
引用
对于软件开发过程，从软件工程的角度来说大多数人都清楚从需求调研，到需求建模，需求分析，系统分析，系统结构设计，系统代码设计，系统测试，系统维护这一过程，我参与过的项目，让我感到，有些项目失败或是非常难做，不在于以上这些环节没做好，而在于少了业务的环节。
看来作者还是不能跳出瀑布的思维方式，依然认为在直线的思维中转圈。
引用
很多人也许会说，业务不就是需求吗，没错，但更多的时候我们关注的是界面、功能、和数据，却很少注意功能之间的联系即业务过程。
这里作者证实了他吧业务也划分为需求的领域的观点。而这一点是我这个点评所最需要批判的。
引用
有没有想过，我们将软件所有的功能做成菜单，让用户自己选择他们要做什么，而没有一个业务过程的概念，用户要自己知道用了某个功能后下一个该用哪个。这样的系统其实不是应用系统，只是一个数据处理机或者说是一个比较复杂的计算机器。它把业务过程分解为一些独立/分散的功能，而没有把这些功能组织起来。因此，有必要将业务从需求中分离而进行强调。我想，这也就是RATIONAL 公司引入业务建模这个重要的概念吧，
而这里作者又说要把业务从需求中分离出来，显然他还没有真正的考虑明白他到底应该作什么。同时他还忽略了，很多功能是跨越多个业务过程的，或者为多个业务过程所涉及的。同时对于功能的组织也非入作者暗示的那样只是需要业务的指导，还要考虑到其他非常多的因素，比如硬件环境，软件环境，人力资源环境等等。同时很多时候既便开发者没有业务的概念，也不是 不能设计出合乎业务的功能，同时也不是就不能对用户下一个需要应该的功能作出指示。而往往是用户的功能被他们的需求完全的锁定，而不能考虑到会发生的变化，以及可能的其他选择。这一点也是其从根本上还是不能看到他的所谓的业务模型没有解决他要解决问题的能力。
引用
无论是从我的经验、观点和教训来说，还是看了RUP的观点来年，我个人认为新的软件开发过程是：业务调研，业务建模(业务分析)，(业务模型分析)需求调研（这时，已经有一部分需求可从来务模型中获得）, 需求建模，需求分析……因为建模的过程也是分析的过程，所以业务建模和业务分析可能交叉在一起。如果遇到一个客户，规范到已经有了现成的业务模型，那么直接就拿来就可以了。如果业务建模与需求调研是同一班人，那么需求调研中的业务模型分析工作就比较容易了。
作者在这里还是在犯把业务分析过程和需求分析过程混淆的毛病。
同时一个问题他不知道是理解错误，还是他没有提及。实际上需求建模就是需求分析的过程，分析的目标就是建立一个模型，而这么模型的主要目标不是为了需求分析的更清楚，而是为了使下一个开发阶段的工作能更好的理解需求，并且按照这个模型建立程序。无论从瀑布的观点和迭代的角度，这一点都一样。而只有分析模型和规则库才是为了使你能更好的分析需求。
引用
业务建模当中又要注意什么呢？我个人的看法是：千万别把业务建模和需示分析混在一起啦。如网上订单系统，一个人下了订单，当然此订单是通过系统自动完成，并没有后台人员的支持，此时，业务主角当然是下订单的人，那业务角色呢 是否是没有，还是下订单的人？ 对于系统来说，业务主角当然是下订单的人，而业务角色呢？不太可能是系统自已吧？ 而我的看法是业务角色就是系统自已，那不是很矛盾吗？其实，关键一点是业务建模你不能有需求分析的概念，在这里，系统并不是软件系统，而是完成业务主角的订单，即一个用例的东西，根据业务建模的概念，完成了订单这个用例只能是订单系统，那么业务角色也就是订单系统。因为它是下订单这一业务中。
文章来源于领测软件测试网 https://www.ltesting.net/
