了解目标组织（将要在其中部署系统的组织）的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。 （来自RUPCN）
以上大家可以理解，我们有没有更深的理解呢？我先从业务主角和业务角色说起业务建模，在业务建模中主要有业务主角（BUSINESS ACTOR）和业务角色（BUSINESS WORKER），对此我们有什么了解呢。我先做出定义：业务主角是服务对象，如对商店进行业务建模， 业务主角是顾客。业务角色是服务人员或系统，如对商店进行业务建模，业务角色是售货员。业务主角是为谁提供服务，产生了用例。业务角色是提供服务，完成了用例。可以仔细看看RUPCN。这两个东西它们在ROSE中图形的表示也不一样。
但大家有没有想过，业务建模更深的意义，我们在传统的软件工程来说并没有类似业务建模这个概念，而RATIONAL公司又要将此放入，在软件工程中，它又到底起了什么作用呢？
一般说来，我们做一个软件项目基本上都是从需求调研后就到需求建模和需求分析了，没怎么去想业务建模。而大家有没有想过，我们对需求的处理比较表象，如界面、功能和数据，对业务处理过程缺少规范的说明，而这正是开发必须的。你有没有觉得你以前很多开发没有准确反应需求，是否有一个原因，不是需求不清，而是对需求的实现过程不清，即没有了解好业务，从RUP的角度来说，也就是缺少了业务建模这一关键环节。我曾经思索过业务建模最主要解决什么问题，我的看法就是业务建模就是创建业务处理模型，是进行需求分析的依据。而需求分析的结果，将要确定一个开发规范，正确的实现业务处理过程应当是它的一个重要内容，而我们在需求调研时，往往忽视了这一点。
那么，在需求调研中，需求建模与业务建模谁先谁后呢？个人认为，业务是本来就存在的，不管有没有这个软件或项目，它都存在，它都在按一定的模式运作，因此业务建模与需求调研、需求建模是无关的，立项之前业务模型就可以存在. 或是立项以前，业务建模就可以完成的。 然而，实际并非如此，用户只知道如何处理业务，却很少有一个完整的业务模型，当立项时，就需求承建方邦助客户创建它。因为承建方不了解客户的业务过程是不能建模的， 又必须了解客户的业务。
对于软件开发过程，从软件工程的角度来说大多数人都清楚从需求调研，到需求建模，需求分析，系统分析，系统结构设计，系统代码设计，系统测试，系统维护这一过程，我参与过的项目，让我感到，有些项目失败或是非常难做，不在于以上这些环节没做好，而在于少了业务的环节。
很多人也许会说，业务不就是需求吗，没错，但更多的时候我们关注的是界面、功能、和数据，却很少注意功能之间的联系即业务过程。
有没有想过，我们将软件所有的功能做成菜单，让用户自己选择他们要做什么，而没有一个业务过程的概念，用户要自己知道用了某个功能后下一个该用哪个。这样的系统其实不是应用系统，只是一个数据处理机或者说是一个比较复杂的计算机器。它把业务过程分解为一些独立/分散的功能，而没有把这些功能组织起来。因此，有必要将业务从需求中分离而进行强调。我想，这也就是RATIONAL 公司引入业务建模这个重要的概念吧，
无论是从我的经验、观点和教训来说，还是看了RUP的观点来年，我个人认为新的软件开发过程是：业务调研，业务建模(业务分析)，(业务模型分析)需求调研（这时，已经有一部分需求可从来务模型中获得）, 需求建模，需求分析……因为建模的过程也是分析的过程，所以业务建模和业务分析可能交叉在一起。如果遇到一个客户，规范到已经有了现成的业务模型，那么直接就拿来就可以了。如果业务建模与需求调研是同一班人，那么需求调研中的业务模型分析工作就比较容易了。
业务建模当中又要注意什么呢？我个人的看法是：千万别把业务建模和需示分析混在一起啦。如网上订单系统，一个人下了订单，当然此订单是通过系统自动完成，并没有后台人员的支持，此时，业务主角当然是下订单的人，那业务角色呢 是否是没有，还是下订单的人？ 对于系统来说，业务主角当然是下订单的人，而业务角色呢？不太可能是系统自已吧？ 而我的看法是业务角色就是系统自已，那不是很矛盾吗？其实，关键一点是业务建模你不能有需求分析的概念，在这里，系统并不是软件系统，而是完成业务主角的订单，即一个用例的东西，根据业务建模的概念，完成了订单这个用例只能是订单系统，那么业务角色也就是订单系统。因为它是下订单这一业务中。
无论业务角色还是业务主角，都是对角色的抽象，不能具体到某个人的。而一个具体的事务，可能会兼任两个不同的角色，但此时，大部分发生了身份或岗位的转移。
zingers 2003-10-31
关于业务建模，Craig larman在他的名著中倒是有所提到，作者在把它归纳在用例分析中了，比如他始终强调关键业务角色的利益所得和相对趋势。我在一个省级检测机构作项目时，就自觉得把系统对人的影响和角色对系统的期待，以及它们之间的反复作用放在一个很重要的层面上来考虑，尽管这种做法还无法按步就班地操作，就是先研究现有业务流程，把确定性和不确定性的因素考虑周到，再设想系统实现和人的反应性之间的关系。然后再在设计时注意软件的可变动性。这样的一个好处是项目相对比较顺利，和各方面打交道比较顺畅，真正让软件有使用价值，而不是变成一堆代码的尸体。
clamp 2004-12-30
呵呵，这个帖子好象响应的人不多啊。
我勉强也可以算是做业务需求的吧。
目前我把它分成以下几块内容（主要针对企业定制应用）
1、客户方基本信息。
包括客户信息、组织结构、用户、用户关系等
2、客户方业务流程和业务信息
3、客户方管理和生产模式
4、客户方的变化和发展方向
以上这几部分其实更接近于咨询所要了解的内容。
5、哪些部分需要使用系统？系统的边界和范围是什么？系统的涉众是什么？
6、系统对应哪些业务流程和业务信息，引入系统以后新的业务流程和业务信息是什么？？
7、引入系统以后新的管理和生产模式是什么？？
以上这三个问题我认为是一个项目最核心的问题
大到横跨整个企业的ERP，小到针对一个人的信息管理，都要考虑这三个问题。
8、对引入系统以后新的业务流程和业务信息进行概念建模
9、对引入系统以后新的管理和生产模式以客户方内部规范的形式固定下来
这一步也很重要
10、获取具体对象和用例
11、获取对象关系和用例关系
注意：以上的步骤不是先后执行的，根据实际的情况会有调整。
事实上在实际操作的时候往往是从第10步和第11步开始，但是只有这两步是不够的……
tianxinet 2004-12-30
几年前看过高展的“全程建模”，颇有收益，应用于项目中的业务建模，能够解决一些问题，通过实践，也深感业务建模很重要（当时在做企业管理软件）。采用“全程建模”提供的方法和工具（实际上是IDEF）进行业务建模，非专业人士稍加解释也看得懂。
后来看UML、RUP，实践中觉得其中的一些方法、工具又是一种不错的业务建模方式，经过一两次“培训”（就是拿着写好的文档讲给他们听而已），非专业人士也看得懂。
再后来看XP，结合实践觉得“经过裁减的RUP等‘重型方法’+XP的某些原则”，也是很不错的，不过XP就没什么业务建模的概念了。
我是个“投机派”，呵呵，实践中觉得有用就拿来用！
lingice 2005-01-04
对这篇文章很有感触！
最近的一个项目就遇到了“业务”问题，我们这个项目“发起者”和“最终用户”是分开的，而且完全不在一个部门（领域），我们开发小组成员对于这个“领域”也是完全陌生的，项目催的比较急，领导们整天说“赶紧把总体方案”拿出来，可是我们这个Team对这个领域太陌生了，而用户方很忙（他们确实很忙，而不是有意阻碍），关于业务这方面交流有限，更谈不上“对业务流程建模”了，我们想跟着用户，在他们的日常工作中探索业务，可是由于种种不可抗拒的因素，如密级很高，而无法实施！
针对于这种项目如何实施“业务建模”？！而且用户对于自己业务流程的把握也不是很到位，举一个极端的例子，如：作战时物资的调配与供给，没在这种环境下就很难把握住“正确的流程”，更何况战场错综复杂，何种是正确、何种是错误很难说得清楚！
不知道我举的这个例子恰当不恰当？！总之，业务建模是非常好的，但在一些情况下是很难实现、很难把握的！
不知道有没有朋友遇到过和我类似的情况！
o6z的评论:
典型的瀑布思维方式。
业务建模及其产生的业务模型非常可能是在你还没有接触客户而只是接触了领域的时候就产生了的，这一点非常的好理解。而对于从业务模型上推倒出的实现领域模型，也非常的可能在需求分析之前就已经产生的。而且这些模型越是早的产生，就说明这个组织对于领域和业务的积累深厚。到真正面向实施的时候，由于已经存在一个系统化的业务和开发框架，实施起来就会轻松的多。
这篇文章我很早就想作一个点评，但是当时我没有时间。现在好了，我来作一个我自己的阐述。
引用
了解目标组织（将要在其中部署系统的组织）的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。 （来自RUPCN）
这段话有问题。这个目标是没有必要达成共识的。而是要理解不同的涉众各自不同的目标，而这些目标很多时候是相互矛盾的（比如卖方和买方的矛盾，管理者和被管理者的矛盾，业务方和竞争对手的矛盾）。实际我我们操作的时候需要的是找到最应该满足的那部分涉众的目标，并且在一定程度上去满足这些目标的非对抗目标。但是实际上这个问题还需要特别的考虑。如果你是在项目前对于领域进来了解的时候进行这个业务建模（我更愿意叫做领域建模），这个时候得到的模型应该非常明确的反映出这个对抗的关系，以便于在具体针对项目的时候进行有目的的权衡。
而由于作者在最初的基本出发点上就存在这样的未深刻理解，所以在后面的论述中存在非常多的微妙的错误，而且造成的影响很多是本质上的问题。
引用
以上大家可以理解，我们有没有更深的理解呢？我先从业务主角和业务角色说起业务建模，在业务建模中主要有业务主角（BUSINESS ACTOR）和业务角色（BUSINESS WORKER），对此我们有什么了解呢。我先做出定义：业务主角是服务对象，如对商店进行业务建模， 业务主角是顾客。业务角色是服务人员或系统，如对商店进行业务建模，业务角色是售货员。业务主角是为谁提供服务，产生了用例。业务角色是提供服务，完成了用例。可以仔细看看RUPCN。这两个东西它们在ROSE中图形的表示也不一样。
为这里作者实际上阐述的有些不清楚，很多情况下业务主角并不是顾客，比如你要建立的模型是为财务管理服务的。
实际上这里隐含一个作者的想法，这一点大概也是RUP的一个问题。那就是过早的划分出了一个模型所要针对的需求对象。而在我这里，业务建模如果是在项目的前的领域分析的时候，特别是在建立分析模型的时候，关键的是在描绘场景，而非过程，或者是业务领域中有些什么对象（概念模型），而不是有些什么过程（业务流程）。这是由于业务流程会随着业务的实施具体环境的不同有所不同，过早的具体化会造成后期对于真实用户业务过程理解的污染。但是我们也清楚实际上这个业务过程是非常重要的一个业务领域中的概念，如果不在早期就有所准备，那么后期的工作也会非常困难。解决这个问题的方式就是尽早的建立业务规则库，这个问题我会在今后作专门的阐述。
引用
但大家有没有想过，业务建模更深的意义，我们在传统的软件工程来说并没有类似业务建模这个概念，而RATIONAL公司又要将此放入，在软件工程中，它又到底起了什么作用呢？
一般说来，我们做一个软件项目基本上都是从需求调研后就到需求建模和需求分析了，没怎么去想业务建模。而大家有没有想过，我们对需求的处理比较表象，如界面、功能和数据，对业务处理过程缺少规范的说明，而这正是开发必须的。你有没有觉得你以前很多开发没有准确反应需求，是否有一个原因，不是需求不清，而是对需求的实现过程不清，即没有了解好业务，从RUP的角度来说，也就是缺少了业务建模这一关键环节。我曾经思索过业务建模最主要解决什么问题，我的看法就是业务建模就是创建业务处理模型，是进行需求分析的依据。而需求分析的结果，将要确定一个开发规范，正确的实现业务处理过程应当是它的一个重要内容，而我们在需求调研时，往往忽视了这一点。
那么，在需求调研中，需求建模与业务建模谁先谁后呢？个人认为，业务是本来就存在的，不管有没有这个软件或项目，它都存在，它都在按一定的模式运作，因此业务建模与需求调研、需求建模是无关的，立项之前业务模型就可以存在. 或是立项以前，业务建模就可以完成的。 然而，实际并非如此，用户只知道如何处理业务，却很少有一个完整的业务模型，当立项时，就需求承建方邦助客户创建它。因为承建方不了解客户的业务过程是不能建模的， 又必须了解客户的业务。
明显的作者这两段话之间是有矛盾的——前面一段是隐含者说业务建模是需求建模的一个部分，后面则又在说业务建模可以在项目前就产生。是什么原因造成作者的这个矛盾呢？
根本原因还是在于作者没有跳出瀑布思想的束缚，依然将对于业务和领域的工程化分析强行的加入需求工程中来。我们知道需求是客户的真实需要，而没有客户也自然不会有需求，当然没有项目自然就不存在客户。当然有些产品的开发虽然没有确定的真实客户，可是还是存在着假想的目标客户。而我这里所说的，恰恰是在业务建模的有些时候，特别是项目前的最初阶段，你不应该确定 你需要满足的个别人群，而是要阐述在业务场景中所有涉及到的群体。
同时这里作者的一个观点我是同意的，就是有些时候需求不清楚，是由于如何实现需求不被我们理解。但是问题在于具体的业务实现是不可能被你提前完全的解释的。你只能在现实的环境中去针对性的达成业务过程。而实际上解决这个问题工具就是我前面提到的分析模型和业务规则库。你要作的是依照客户的实际情况，对于分析模型进行裁减，再比对规则库进行建立现实化的需求模型。
比如我们要设计一个会计程序，我们会发现其分析模型是再中外都基本一致的。但是由于国内外的政策和法律等方面的原因，规则会不同。那么这个时候你要作的是同时维护两个基于业务过程的模型，还是维护一个分析模型和一套包括中外不同国家的会计领域的规则库呢？而同时我们还知道，由于法律和社会习惯的原因，规则是会发生变化的，那么是不是你的那个基于业务流程的模型也需要不断的随之全面性的变化呢？而不是向你实现分析模型和规则库的分离。同时我们还要考虑到规则的变化很少会发生全面的变化，那么维护一个规则库实际上就只是在环境变化时，去修改个别的规则。
同时作者最后还犯了一个根本性的错误，认为对于业务不了解就不能建模。他看来完全的忽略了建模的一个目的就是去了解业务，或者说了解业务就是从建模开始的。
引用
对于软件开发过程，从软件工程的角度来说大多数人都清楚从需求调研，到需求建模，需求分析，系统分析，系统结构设计，系统代码设计，系统测试，系统维护这一过程，我参与过的项目，让我感到，有些项目失败或是非常难做，不在于以上这些环节没做好，而在于少了业务的环节。
看来作者还是不能跳出瀑布的思维方式，依然认为在直线的思维中转圈。
引用
很多人也许会说，业务不就是需求吗，没错，但更多的时候我们关注的是界面、功能、和数据，却很少注意功能之间的联系即业务过程。
这里作者证实了他吧业务也划分为需求的领域的观点。而这一点是我这个点评所最需要批判的。
引用
有没有想过，我们将软件所有的功能做成菜单，让用户自己选择他们要做什么，而没有一个业务过程的概念，用户要自己知道用了某个功能后下一个该用哪个。这样的系统其实不是应用系统，只是一个数据处理机或者说是一个比较复杂的计算机器。它把业务过程分解为一些独立/分散的功能，而没有把这些功能组织起来。因此，有必要将业务从需求中分离而进行强调。我想，这也就是RATIONAL 公司引入业务建模这个重要的概念吧，
而这里作者又说要把业务从需求中分离出来，显然他还没有真正的考虑明白他到底应该作什么。同时他还忽略了，很多功能是跨越多个业务过程的，或者为多个业务过程所涉及的。同时对于功能的组织也非入作者暗示的那样只是需要业务的指导，还要考虑到其他非常多的因素，比如硬件环境，软件环境，人力资源环境等等。同时很多时候既便开发者没有业务的概念，也不是 不能设计出合乎业务的功能，同时也不是就不能对用户下一个需要应该的功能作出指示。而往往是用户的功能被他们的需求完全的锁定，而不能考虑到会发生的变化，以及可能的其他选择。这一点也是其从根本上还是不能看到他的所谓的业务模型没有解决他要解决问题的能力。
引用
无论是从我的经验、观点和教训来说，还是看了RUP的观点来年，我个人认为新的软件开发过程是：业务调研，业务建模(业务分析)，(业务模型分析)需求调研（这时，已经有一部分需求可从来务模型中获得）, 需求建模，需求分析……因为建模的过程也是分析的过程，所以业务建模和业务分析可能交叉在一起。如果遇到一个客户，规范到已经有了现成的业务模型，那么直接就拿来就可以了。如果业务建模与需求调研是同一班人，那么需求调研中的业务模型分析工作就比较容易了。
作者在这里还是在犯把业务分析过程和需求分析过程混淆的毛病。
同时一个问题他不知道是理解错误，还是他没有提及。实际上需求建模就是需求分析的过程，分析的目标就是建立一个模型，而这么模型的主要目标不是为了需求分析的更清楚，而是为了使下一个开发阶段的工作能更好的理解需求，并且按照这个模型建立程序。无论从瀑布的观点和迭代的角度，这一点都一样。而只有分析模型和规则库才是为了使你能更好的分析需求。
引用
业务建模当中又要注意什么呢？我个人的看法是：千万别把业务建模和需示分析混在一起啦。如网上订单系统，一个人下了订单，当然此订单是通过系统自动完成，并没有后台人员的支持，此时，业务主角当然是下订单的人，那业务角色呢 是否是没有，还是下订单的人？ 对于系统来说，业务主角当然是下订单的人，而业务角色呢？不太可能是系统自已吧？ 而我的看法是业务角色就是系统自已，那不是很矛盾吗？其实，关键一点是业务建模你不能有需求分析的概念，在这里，系统并不是软件系统，而是完成业务主角的订单，即一个用例的东西，根据业务建模的概念，完成了订单这个用例只能是订单系统，那么业务角色也就是订单系统。因为它是下订单这一业务中。
作者不断的提醒大家不能把业务建模和需求分析混在一起，可是他自己就完全的不能区分开两者的关系，这一点非常值得我们思考。而在这里他又为业务主角和业务角色的纠缠不清，其实根本问题在于他过早的引入了业务用例的。实际上如我在前面强调的业务分析，或者领域分析所使用的技术是明显对象的分析，和基于规则的分析，得到的工件是分析模型（类型图）和规则库。这一点是那些顽固的坚持在RUP的圈子里面，而不是运用RUP的思想去分析问题的人的通病。
同时作者在这里还涉及到了系统在业务过程中的地位，他在这里也有所偏差，我会在以后介绍业务用例中系统的地位。
引用
无论业务角色还是业务主角，都是对角色的抽象，不能具体到某个人的。而一个具体的事务，可能会兼任两个不同的角色，但此时，大部分发生了身份或岗位的转移。
这里显然作者还是在说用例，而恰恰是他还不能理解用例的一些基本的概念。任何的角色必须具体到个别而具体的人，这是常识性的错误。
为什么作者在我的分析中犯了众多的基本错误呢？我认为这大概就是目前很多人习惯性的受到瀑布思维方式的影响。而还有一个原因，就是这些人往往是自学成才，而又不能去理解新方法的意图。他们过于追求形式的相似，而不是思想的统一。
领域分析应该是独立于需求工程的单独部分，应该使用面向对象的方式和基于规则的方法，提交的领域分析模型和规则库。这两个工件是独立于项目的，并且不断的被维护和积累的。是公司在一个行业中的核心资产。
事实确实如此，但是前一个项目是不是可以为下一个项目进行必要的积累？对一个行业的开发项目，是否可以成为为另外相关领域的研究过程？
如果单纯的从一个项目去研究对于目前广大的软件企业并没有太多的意义，因为我们的公司往往都是在进行短期的、成本和周期被严格限定的项目。但是越是这样我们就越是有必要去研究领域中的问题。
而用户使用我们的产品往往是为了解决一些他们现在已经不能解决的业务问题，这些问题解决的方法他们自己并不知道。作为一个非行业内的人士需要为行业中可以称为专家级别的人提出行业的解决方案的事情经常性的出现在我们的周围。我们如果不能找到解决的途径，我们就必然会被淘汰。
传统的需求工程所研究的问题和论述的方法，往往只是局限在单独项目的一个周期。这不能不说是一个非常严重的问题。这一点就类似LISP中的出现的你可以表达一个方程，但是这并不代表你解决了求方程解的方法。
我还认为对于领域的研究可以增加我们对个别项目客户需求理解的能力，从而更好的理解他们的真正目标。同时这样作还可以大幅度的提高我们建立一个行业内通用平台的能力，从而在工期和成本以及质量上更好的完成项目。
所以剩下关键的问题就是如何去从原来的经验中去提纯出关于领域的知识，并且把这些知识变成我们解决问题的能力。这就是我最近在作的研究。
工程学研究的一个方向就是如何产生知识，传递知识，和应用知识。同时作为个人的成长来说，寻找必要的方法和适当的方式，也是非常必要的。
同时作为一个组织，如果不能把其成员的经验进行沉淀，不能把前面的工作作为后面工作的基础，这也是一种资源的最大浪费。
所以我们有必要去学习如何进行这些知识的积累，去学习如何把经验变成知识。
FireBody:
说点个人拙见， 虽然业务模型和 领域模型有可能在需求分析之前大体可以确定下来，但是我觉得可以这样理解这句话， 虽然大体的模型可以确定下来，但是在得到具体的需求 和 用例场景后，仍然需要对业务模型进行一个 整体的分析，得出一个更具体的更适合的 领域模型， 我想这个过程应该是在第一次迭代中对所有抽取出来的主要用例进行整体分析而得出的一个结果。
从这个理解上来说 ，我认为 业务建摸和 领域模型应该在需求分析之后 ，有什么过错？
Jimmy:
领域模型是超出某个单独的系统设计的,业务领域适用的一套规则模型. 所以对于单个系统开发来说应该是早期需求/研究阶段进行建立, 目的是帮助界定系统边界/基本框架,确定基本业务规则.需求分析阶段之后是否还需要进行这样的工作?应该是不用的,因为这时系统边界已经确立了,开发工作应该围绕的是需求模型而非业务模型进行.
当然不排除系统开发完毕对于领域模型的理解有了进一步深入的看法,对其进行整理,以便今后相关项目开发之利.
但是根据单独系统需求的不同, 去修改领域模型, 这实在是犯了一个概念性错误.
yaboocn 2006-02-24
我觉得不要太强调把整个过程的分得过于清晰，而应该根据具体情况来定，如果团队开发一个熟悉的领域，当然可以先进行业务建模，然后进行需求调研，但是如果涉足一个新的领域的话，我认为需求调研中就应该包含业务调研，需求调研不应该只是被动的接受客户提出的要求，还应该主动去了解行业的知识，客户的业务运转模式，和业务规则，通过调研人员主动去认识业务，并且这里存在一个管理思路的问题，一个软件并不只是迎合用户目前的业务，而是通过软件来提高用户的生产效率达到一个更好的效果，虽然现在国内软件做的并不是那么好，但这总是个方向。有点跑题，但是我觉得如果有能力在需求调研前业务建模当然是好，要是不行，我觉得在系统分析时做比较合适，软件基本过程总是从外至内的反复迭代来进行分析设计的，这里的外不是指界面而是从外部交互到内部交互，就像rose中会有business use case 和use case一样
xyzou 2006-02-28
业务建模，需要专业人士的介入，比如说领域专家，他们可以不是做软件的，但是他们对于这个领域非常的了解，以致于他们能给出一个适合于该领域的模型，同时又能顾虑到特殊的用户需求。
一般在进行业务（领域）建模时是需要有一名领域专家，再加上调研人员，还有客户，这样做出来的需求分析设计才会更完善。
当然，小的项目或者行业背景不深的项目，可能不需要领域专家的参与。但是，在行业背景很深的情况下，如果调研人员什么都不懂，那么跟客户交流起来也是很费劲的，毕竟大多数客户他们也并不真正的能把他的工作抽象起来，这个都需要领域专家的帮助。
yaboocn 2006-03-01
领域专家确实很重要，行业软件很需要这一类人，其实他是代表的一个总客户，因为客户虽然是实际业务的运营者，但是，客户一般不可能使一个人，这些客户大部分只知道整个业务的某个片断，这就给需求调研带来很大困难，其实现在很多的需求调研大部分都是敷衍，没有完成真正的价值，这就把压力放到实施阶段了，很多软件都是在实施阶段进行很大的修改，这主要是没有在前期进行很好的业务建模。
我一般都把客户的需求分成三个层次：
一是业务模型 二是数据接口和数据需求 三是界面表现
业务模型，是整个软件的核心，只有做好了他才能使整个软件正向前进，保证后续工作的进行
以上大家可以理解，我们有没有更深的理解呢？我先从业务主角和业务角色说起业务建模，在业务建模中主要有业务主角（BUSINESS ACTOR）和业务角色（BUSINESS WORKER），对此我们有什么了解呢。我先做出定义：业务主角是服务对象，如对商店进行业务建模， 业务主角是顾客。业务角色是服务人员或系统，如对商店进行业务建模，业务角色是售货员。业务主角是为谁提供服务，产生了用例。业务角色是提供服务，完成了用例。可以仔细看看RUPCN。这两个东西它们在ROSE中图形的表示也不一样。
但大家有没有想过，业务建模更深的意义，我们在传统的软件工程来说并没有类似业务建模这个概念，而RATIONAL公司又要将此放入，在软件工程中，它又到底起了什么作用呢？
一般说来，我们做一个软件项目基本上都是从需求调研后就到需求建模和需求分析了，没怎么去想业务建模。而大家有没有想过，我们对需求的处理比较表象，如界面、功能和数据，对业务处理过程缺少规范的说明，而这正是开发必须的。你有没有觉得你以前很多开发没有准确反应需求，是否有一个原因，不是需求不清，而是对需求的实现过程不清，即没有了解好业务，从RUP的角度来说，也就是缺少了业务建模这一关键环节。我曾经思索过业务建模最主要解决什么问题，我的看法就是业务建模就是创建业务处理模型，是进行需求分析的依据。而需求分析的结果，将要确定一个开发规范，正确的实现业务处理过程应当是它的一个重要内容，而我们在需求调研时，往往忽视了这一点。
那么，在需求调研中，需求建模与业务建模谁先谁后呢？个人认为，业务是本来就存在的，不管有没有这个软件或项目，它都存在，它都在按一定的模式运作，因此业务建模与需求调研、需求建模是无关的，立项之前业务模型就可以存在. 或是立项以前，业务建模就可以完成的。 然而，实际并非如此，用户只知道如何处理业务，却很少有一个完整的业务模型，当立项时，就需求承建方邦助客户创建它。因为承建方不了解客户的业务过程是不能建模的， 又必须了解客户的业务。
对于软件开发过程，从软件工程的角度来说大多数人都清楚从需求调研，到需求建模，需求分析，系统分析，系统结构设计，系统代码设计，系统测试，系统维护这一过程，我参与过的项目，让我感到，有些项目失败或是非常难做，不在于以上这些环节没做好，而在于少了业务的环节。
很多人也许会说，业务不就是需求吗，没错，但更多的时候我们关注的是界面、功能、和数据，却很少注意功能之间的联系即业务过程。
有没有想过，我们将软件所有的功能做成菜单，让用户自己选择他们要做什么，而没有一个业务过程的概念，用户要自己知道用了某个功能后下一个该用哪个。这样的系统其实不是应用系统，只是一个数据处理机或者说是一个比较复杂的计算机器。它把业务过程分解为一些独立/分散的功能，而没有把这些功能组织起来。因此，有必要将业务从需求中分离而进行强调。我想，这也就是RATIONAL 公司引入业务建模这个重要的概念吧，
无论是从我的经验、观点和教训来说，还是看了RUP的观点来年，我个人认为新的软件开发过程是：业务调研，业务建模(业务分析)，(业务模型分析)需求调研（这时，已经有一部分需求可从来务模型中获得）, 需求建模，需求分析……因为建模的过程也是分析的过程，所以业务建模和业务分析可能交叉在一起。如果遇到一个客户，规范到已经有了现成的业务模型，那么直接就拿来就可以了。如果业务建模与需求调研是同一班人，那么需求调研中的业务模型分析工作就比较容易了。
业务建模当中又要注意什么呢？我个人的看法是：千万别把业务建模和需示分析混在一起啦。如网上订单系统，一个人下了订单，当然此订单是通过系统自动完成，并没有后台人员的支持，此时，业务主角当然是下订单的人，那业务角色呢 是否是没有，还是下订单的人？ 对于系统来说，业务主角当然是下订单的人，而业务角色呢？不太可能是系统自已吧？ 而我的看法是业务角色就是系统自已，那不是很矛盾吗？其实，关键一点是业务建模你不能有需求分析的概念，在这里，系统并不是软件系统，而是完成业务主角的订单，即一个用例的东西，根据业务建模的概念，完成了订单这个用例只能是订单系统，那么业务角色也就是订单系统。因为它是下订单这一业务中。
无论业务角色还是业务主角，都是对角色的抽象，不能具体到某个人的。而一个具体的事务，可能会兼任两个不同的角色，但此时，大部分发生了身份或岗位的转移。
zingers 2003-10-31
关于业务建模，Craig larman在他的名著中倒是有所提到，作者在把它归纳在用例分析中了，比如他始终强调关键业务角色的利益所得和相对趋势。我在一个省级检测机构作项目时，就自觉得把系统对人的影响和角色对系统的期待，以及它们之间的反复作用放在一个很重要的层面上来考虑，尽管这种做法还无法按步就班地操作，就是先研究现有业务流程，把确定性和不确定性的因素考虑周到，再设想系统实现和人的反应性之间的关系。然后再在设计时注意软件的可变动性。这样的一个好处是项目相对比较顺利，和各方面打交道比较顺畅，真正让软件有使用价值，而不是变成一堆代码的尸体。
clamp 2004-12-30
呵呵，这个帖子好象响应的人不多啊。
我勉强也可以算是做业务需求的吧。
目前我把它分成以下几块内容（主要针对企业定制应用）
1、客户方基本信息。
包括客户信息、组织结构、用户、用户关系等
2、客户方业务流程和业务信息
3、客户方管理和生产模式
4、客户方的变化和发展方向
以上这几部分其实更接近于咨询所要了解的内容。
5、哪些部分需要使用系统？系统的边界和范围是什么？系统的涉众是什么？
6、系统对应哪些业务流程和业务信息，引入系统以后新的业务流程和业务信息是什么？？
7、引入系统以后新的管理和生产模式是什么？？
以上这三个问题我认为是一个项目最核心的问题
大到横跨整个企业的ERP，小到针对一个人的信息管理，都要考虑这三个问题。
8、对引入系统以后新的业务流程和业务信息进行概念建模
9、对引入系统以后新的管理和生产模式以客户方内部规范的形式固定下来
这一步也很重要
10、获取具体对象和用例
11、获取对象关系和用例关系
注意：以上的步骤不是先后执行的，根据实际的情况会有调整。
事实上在实际操作的时候往往是从第10步和第11步开始，但是只有这两步是不够的……
tianxinet 2004-12-30
几年前看过高展的“全程建模”，颇有收益，应用于项目中的业务建模，能够解决一些问题，通过实践，也深感业务建模很重要（当时在做企业管理软件）。采用“全程建模”提供的方法和工具（实际上是IDEF）进行业务建模，非专业人士稍加解释也看得懂。
后来看UML、RUP，实践中觉得其中的一些方法、工具又是一种不错的业务建模方式，经过一两次“培训”（就是拿着写好的文档讲给他们听而已），非专业人士也看得懂。
再后来看XP，结合实践觉得“经过裁减的RUP等‘重型方法’+XP的某些原则”，也是很不错的，不过XP就没什么业务建模的概念了。
我是个“投机派”，呵呵，实践中觉得有用就拿来用！
lingice 2005-01-04
对这篇文章很有感触！
最近的一个项目就遇到了“业务”问题，我们这个项目“发起者”和“最终用户”是分开的，而且完全不在一个部门（领域），我们开发小组成员对于这个“领域”也是完全陌生的，项目催的比较急，领导们整天说“赶紧把总体方案”拿出来，可是我们这个Team对这个领域太陌生了，而用户方很忙（他们确实很忙，而不是有意阻碍），关于业务这方面交流有限，更谈不上“对业务流程建模”了，我们想跟着用户，在他们的日常工作中探索业务，可是由于种种不可抗拒的因素，如密级很高，而无法实施！
针对于这种项目如何实施“业务建模”？！而且用户对于自己业务流程的把握也不是很到位，举一个极端的例子，如：作战时物资的调配与供给，没在这种环境下就很难把握住“正确的流程”，更何况战场错综复杂，何种是正确、何种是错误很难说得清楚！
不知道我举的这个例子恰当不恰当？！总之，业务建模是非常好的，但在一些情况下是很难实现、很难把握的！
不知道有没有朋友遇到过和我类似的情况！
o6z的评论:
典型的瀑布思维方式。
业务建模及其产生的业务模型非常可能是在你还没有接触客户而只是接触了领域的时候就产生了的，这一点非常的好理解。而对于从业务模型上推倒出的实现领域模型，也非常的可能在需求分析之前就已经产生的。而且这些模型越是早的产生，就说明这个组织对于领域和业务的积累深厚。到真正面向实施的时候，由于已经存在一个系统化的业务和开发框架，实施起来就会轻松的多。
这篇文章我很早就想作一个点评，但是当时我没有时间。现在好了，我来作一个我自己的阐述。
引用
了解目标组织（将要在其中部署系统的组织）的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。 （来自RUPCN）
这段话有问题。这个目标是没有必要达成共识的。而是要理解不同的涉众各自不同的目标，而这些目标很多时候是相互矛盾的（比如卖方和买方的矛盾，管理者和被管理者的矛盾，业务方和竞争对手的矛盾）。实际我我们操作的时候需要的是找到最应该满足的那部分涉众的目标，并且在一定程度上去满足这些目标的非对抗目标。但是实际上这个问题还需要特别的考虑。如果你是在项目前对于领域进来了解的时候进行这个业务建模（我更愿意叫做领域建模），这个时候得到的模型应该非常明确的反映出这个对抗的关系，以便于在具体针对项目的时候进行有目的的权衡。
而由于作者在最初的基本出发点上就存在这样的未深刻理解，所以在后面的论述中存在非常多的微妙的错误，而且造成的影响很多是本质上的问题。
引用
以上大家可以理解，我们有没有更深的理解呢？我先从业务主角和业务角色说起业务建模，在业务建模中主要有业务主角（BUSINESS ACTOR）和业务角色（BUSINESS WORKER），对此我们有什么了解呢。我先做出定义：业务主角是服务对象，如对商店进行业务建模， 业务主角是顾客。业务角色是服务人员或系统，如对商店进行业务建模，业务角色是售货员。业务主角是为谁提供服务，产生了用例。业务角色是提供服务，完成了用例。可以仔细看看RUPCN。这两个东西它们在ROSE中图形的表示也不一样。
为这里作者实际上阐述的有些不清楚，很多情况下业务主角并不是顾客，比如你要建立的模型是为财务管理服务的。
实际上这里隐含一个作者的想法，这一点大概也是RUP的一个问题。那就是过早的划分出了一个模型所要针对的需求对象。而在我这里，业务建模如果是在项目的前的领域分析的时候，特别是在建立分析模型的时候，关键的是在描绘场景，而非过程，或者是业务领域中有些什么对象（概念模型），而不是有些什么过程（业务流程）。这是由于业务流程会随着业务的实施具体环境的不同有所不同，过早的具体化会造成后期对于真实用户业务过程理解的污染。但是我们也清楚实际上这个业务过程是非常重要的一个业务领域中的概念，如果不在早期就有所准备，那么后期的工作也会非常困难。解决这个问题的方式就是尽早的建立业务规则库，这个问题我会在今后作专门的阐述。
引用
但大家有没有想过，业务建模更深的意义，我们在传统的软件工程来说并没有类似业务建模这个概念，而RATIONAL公司又要将此放入，在软件工程中，它又到底起了什么作用呢？
一般说来，我们做一个软件项目基本上都是从需求调研后就到需求建模和需求分析了，没怎么去想业务建模。而大家有没有想过，我们对需求的处理比较表象，如界面、功能和数据，对业务处理过程缺少规范的说明，而这正是开发必须的。你有没有觉得你以前很多开发没有准确反应需求，是否有一个原因，不是需求不清，而是对需求的实现过程不清，即没有了解好业务，从RUP的角度来说，也就是缺少了业务建模这一关键环节。我曾经思索过业务建模最主要解决什么问题，我的看法就是业务建模就是创建业务处理模型，是进行需求分析的依据。而需求分析的结果，将要确定一个开发规范，正确的实现业务处理过程应当是它的一个重要内容，而我们在需求调研时，往往忽视了这一点。
那么，在需求调研中，需求建模与业务建模谁先谁后呢？个人认为，业务是本来就存在的，不管有没有这个软件或项目，它都存在，它都在按一定的模式运作，因此业务建模与需求调研、需求建模是无关的，立项之前业务模型就可以存在. 或是立项以前，业务建模就可以完成的。 然而，实际并非如此，用户只知道如何处理业务，却很少有一个完整的业务模型，当立项时，就需求承建方邦助客户创建它。因为承建方不了解客户的业务过程是不能建模的， 又必须了解客户的业务。
明显的作者这两段话之间是有矛盾的——前面一段是隐含者说业务建模是需求建模的一个部分，后面则又在说业务建模可以在项目前就产生。是什么原因造成作者的这个矛盾呢？
根本原因还是在于作者没有跳出瀑布思想的束缚，依然将对于业务和领域的工程化分析强行的加入需求工程中来。我们知道需求是客户的真实需要，而没有客户也自然不会有需求，当然没有项目自然就不存在客户。当然有些产品的开发虽然没有确定的真实客户，可是还是存在着假想的目标客户。而我这里所说的，恰恰是在业务建模的有些时候，特别是项目前的最初阶段，你不应该确定 你需要满足的个别人群，而是要阐述在业务场景中所有涉及到的群体。
同时这里作者的一个观点我是同意的，就是有些时候需求不清楚，是由于如何实现需求不被我们理解。但是问题在于具体的业务实现是不可能被你提前完全的解释的。你只能在现实的环境中去针对性的达成业务过程。而实际上解决这个问题工具就是我前面提到的分析模型和业务规则库。你要作的是依照客户的实际情况，对于分析模型进行裁减，再比对规则库进行建立现实化的需求模型。
比如我们要设计一个会计程序，我们会发现其分析模型是再中外都基本一致的。但是由于国内外的政策和法律等方面的原因，规则会不同。那么这个时候你要作的是同时维护两个基于业务过程的模型，还是维护一个分析模型和一套包括中外不同国家的会计领域的规则库呢？而同时我们还知道，由于法律和社会习惯的原因，规则是会发生变化的，那么是不是你的那个基于业务流程的模型也需要不断的随之全面性的变化呢？而不是向你实现分析模型和规则库的分离。同时我们还要考虑到规则的变化很少会发生全面的变化，那么维护一个规则库实际上就只是在环境变化时，去修改个别的规则。
同时作者最后还犯了一个根本性的错误，认为对于业务不了解就不能建模。他看来完全的忽略了建模的一个目的就是去了解业务，或者说了解业务就是从建模开始的。
引用
对于软件开发过程，从软件工程的角度来说大多数人都清楚从需求调研，到需求建模，需求分析，系统分析，系统结构设计，系统代码设计，系统测试，系统维护这一过程，我参与过的项目，让我感到，有些项目失败或是非常难做，不在于以上这些环节没做好，而在于少了业务的环节。
看来作者还是不能跳出瀑布的思维方式，依然认为在直线的思维中转圈。
引用
很多人也许会说，业务不就是需求吗，没错，但更多的时候我们关注的是界面、功能、和数据，却很少注意功能之间的联系即业务过程。
这里作者证实了他吧业务也划分为需求的领域的观点。而这一点是我这个点评所最需要批判的。
引用
有没有想过，我们将软件所有的功能做成菜单，让用户自己选择他们要做什么，而没有一个业务过程的概念，用户要自己知道用了某个功能后下一个该用哪个。这样的系统其实不是应用系统，只是一个数据处理机或者说是一个比较复杂的计算机器。它把业务过程分解为一些独立/分散的功能，而没有把这些功能组织起来。因此，有必要将业务从需求中分离而进行强调。我想，这也就是RATIONAL 公司引入业务建模这个重要的概念吧，
而这里作者又说要把业务从需求中分离出来，显然他还没有真正的考虑明白他到底应该作什么。同时他还忽略了，很多功能是跨越多个业务过程的，或者为多个业务过程所涉及的。同时对于功能的组织也非入作者暗示的那样只是需要业务的指导，还要考虑到其他非常多的因素，比如硬件环境，软件环境，人力资源环境等等。同时很多时候既便开发者没有业务的概念，也不是 不能设计出合乎业务的功能，同时也不是就不能对用户下一个需要应该的功能作出指示。而往往是用户的功能被他们的需求完全的锁定，而不能考虑到会发生的变化，以及可能的其他选择。这一点也是其从根本上还是不能看到他的所谓的业务模型没有解决他要解决问题的能力。
引用
无论是从我的经验、观点和教训来说，还是看了RUP的观点来年，我个人认为新的软件开发过程是：业务调研，业务建模(业务分析)，(业务模型分析)需求调研（这时，已经有一部分需求可从来务模型中获得）, 需求建模，需求分析……因为建模的过程也是分析的过程，所以业务建模和业务分析可能交叉在一起。如果遇到一个客户，规范到已经有了现成的业务模型，那么直接就拿来就可以了。如果业务建模与需求调研是同一班人，那么需求调研中的业务模型分析工作就比较容易了。
作者在这里还是在犯把业务分析过程和需求分析过程混淆的毛病。
同时一个问题他不知道是理解错误，还是他没有提及。实际上需求建模就是需求分析的过程，分析的目标就是建立一个模型，而这么模型的主要目标不是为了需求分析的更清楚，而是为了使下一个开发阶段的工作能更好的理解需求，并且按照这个模型建立程序。无论从瀑布的观点和迭代的角度，这一点都一样。而只有分析模型和规则库才是为了使你能更好的分析需求。
引用
业务建模当中又要注意什么呢？我个人的看法是：千万别把业务建模和需示分析混在一起啦。如网上订单系统，一个人下了订单，当然此订单是通过系统自动完成，并没有后台人员的支持，此时，业务主角当然是下订单的人，那业务角色呢 是否是没有，还是下订单的人？ 对于系统来说，业务主角当然是下订单的人，而业务角色呢？不太可能是系统自已吧？ 而我的看法是业务角色就是系统自已，那不是很矛盾吗？其实，关键一点是业务建模你不能有需求分析的概念，在这里，系统并不是软件系统，而是完成业务主角的订单，即一个用例的东西，根据业务建模的概念，完成了订单这个用例只能是订单系统，那么业务角色也就是订单系统。因为它是下订单这一业务中。
作者不断的提醒大家不能把业务建模和需求分析混在一起，可是他自己就完全的不能区分开两者的关系，这一点非常值得我们思考。而在这里他又为业务主角和业务角色的纠缠不清，其实根本问题在于他过早的引入了业务用例的。实际上如我在前面强调的业务分析，或者领域分析所使用的技术是明显对象的分析，和基于规则的分析，得到的工件是分析模型（类型图）和规则库。这一点是那些顽固的坚持在RUP的圈子里面，而不是运用RUP的思想去分析问题的人的通病。
同时作者在这里还涉及到了系统在业务过程中的地位，他在这里也有所偏差，我会在以后介绍业务用例中系统的地位。
引用
无论业务角色还是业务主角，都是对角色的抽象，不能具体到某个人的。而一个具体的事务，可能会兼任两个不同的角色，但此时，大部分发生了身份或岗位的转移。
这里显然作者还是在说用例，而恰恰是他还不能理解用例的一些基本的概念。任何的角色必须具体到个别而具体的人，这是常识性的错误。
为什么作者在我的分析中犯了众多的基本错误呢？我认为这大概就是目前很多人习惯性的受到瀑布思维方式的影响。而还有一个原因，就是这些人往往是自学成才，而又不能去理解新方法的意图。他们过于追求形式的相似，而不是思想的统一。
领域分析应该是独立于需求工程的单独部分，应该使用面向对象的方式和基于规则的方法，提交的领域分析模型和规则库。这两个工件是独立于项目的，并且不断的被维护和积累的。是公司在一个行业中的核心资产。
事实确实如此，但是前一个项目是不是可以为下一个项目进行必要的积累？对一个行业的开发项目，是否可以成为为另外相关领域的研究过程？
如果单纯的从一个项目去研究对于目前广大的软件企业并没有太多的意义，因为我们的公司往往都是在进行短期的、成本和周期被严格限定的项目。但是越是这样我们就越是有必要去研究领域中的问题。
而用户使用我们的产品往往是为了解决一些他们现在已经不能解决的业务问题，这些问题解决的方法他们自己并不知道。作为一个非行业内的人士需要为行业中可以称为专家级别的人提出行业的解决方案的事情经常性的出现在我们的周围。我们如果不能找到解决的途径，我们就必然会被淘汰。
传统的需求工程所研究的问题和论述的方法，往往只是局限在单独项目的一个周期。这不能不说是一个非常严重的问题。这一点就类似LISP中的出现的你可以表达一个方程，但是这并不代表你解决了求方程解的方法。
我还认为对于领域的研究可以增加我们对个别项目客户需求理解的能力，从而更好的理解他们的真正目标。同时这样作还可以大幅度的提高我们建立一个行业内通用平台的能力，从而在工期和成本以及质量上更好的完成项目。
所以剩下关键的问题就是如何去从原来的经验中去提纯出关于领域的知识，并且把这些知识变成我们解决问题的能力。这就是我最近在作的研究。
工程学研究的一个方向就是如何产生知识，传递知识，和应用知识。同时作为个人的成长来说，寻找必要的方法和适当的方式，也是非常必要的。
同时作为一个组织，如果不能把其成员的经验进行沉淀，不能把前面的工作作为后面工作的基础，这也是一种资源的最大浪费。
所以我们有必要去学习如何进行这些知识的积累，去学习如何把经验变成知识。
FireBody:
说点个人拙见， 虽然业务模型和 领域模型有可能在需求分析之前大体可以确定下来，但是我觉得可以这样理解这句话， 虽然大体的模型可以确定下来，但是在得到具体的需求 和 用例场景后，仍然需要对业务模型进行一个 整体的分析，得出一个更具体的更适合的 领域模型， 我想这个过程应该是在第一次迭代中对所有抽取出来的主要用例进行整体分析而得出的一个结果。
从这个理解上来说 ，我认为 业务建摸和 领域模型应该在需求分析之后 ，有什么过错？
Jimmy:
领域模型是超出某个单独的系统设计的,业务领域适用的一套规则模型. 所以对于单个系统开发来说应该是早期需求/研究阶段进行建立, 目的是帮助界定系统边界/基本框架,确定基本业务规则.需求分析阶段之后是否还需要进行这样的工作?应该是不用的,因为这时系统边界已经确立了,开发工作应该围绕的是需求模型而非业务模型进行.
当然不排除系统开发完毕对于领域模型的理解有了进一步深入的看法,对其进行整理,以便今后相关项目开发之利.
但是根据单独系统需求的不同, 去修改领域模型, 这实在是犯了一个概念性错误.
yaboocn 2006-02-24
我觉得不要太强调把整个过程的分得过于清晰，而应该根据具体情况来定，如果团队开发一个熟悉的领域，当然可以先进行业务建模，然后进行需求调研，但是如果涉足一个新的领域的话，我认为需求调研中就应该包含业务调研，需求调研不应该只是被动的接受客户提出的要求，还应该主动去了解行业的知识，客户的业务运转模式，和业务规则，通过调研人员主动去认识业务，并且这里存在一个管理思路的问题，一个软件并不只是迎合用户目前的业务，而是通过软件来提高用户的生产效率达到一个更好的效果，虽然现在国内软件做的并不是那么好，但这总是个方向。有点跑题，但是我觉得如果有能力在需求调研前业务建模当然是好，要是不行，我觉得在系统分析时做比较合适，软件基本过程总是从外至内的反复迭代来进行分析设计的，这里的外不是指界面而是从外部交互到内部交互，就像rose中会有business use case 和use case一样
xyzou 2006-02-28
业务建模，需要专业人士的介入，比如说领域专家，他们可以不是做软件的，但是他们对于这个领域非常的了解，以致于他们能给出一个适合于该领域的模型，同时又能顾虑到特殊的用户需求。
一般在进行业务（领域）建模时是需要有一名领域专家，再加上调研人员，还有客户，这样做出来的需求分析设计才会更完善。
当然，小的项目或者行业背景不深的项目，可能不需要领域专家的参与。但是，在行业背景很深的情况下，如果调研人员什么都不懂，那么跟客户交流起来也是很费劲的，毕竟大多数客户他们也并不真正的能把他的工作抽象起来，这个都需要领域专家的帮助。
yaboocn 2006-03-01
领域专家确实很重要，行业软件很需要这一类人，其实他是代表的一个总客户，因为客户虽然是实际业务的运营者，但是，客户一般不可能使一个人，这些客户大部分只知道整个业务的某个片断，这就给需求调研带来很大困难，其实现在很多的需求调研大部分都是敷衍，没有完成真正的价值，这就把压力放到实施阶段了，很多软件都是在实施阶段进行很大的修改，这主要是没有在前期进行很好的业务建模。
我一般都把客户的需求分成三个层次：
一是业务模型 二是数据接口和数据需求 三是界面表现
业务模型，是整个软件的核心，只有做好了他才能使整个软件正向前进，保证后续工作的进行
扫一扫
1995
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
