我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。
于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。
这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。
好了，今天是第一篇。想得很远，真希望我能坚持下去，呵呵
用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。
这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。
最 具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人 用用例来划分子系统，功能模块和功能点。如果这样，用例根本没有存在的必要。有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够 深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程 的影子还没有从他们脑子里彻底抹去。
如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？ 我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入-->计算-->输出。这让你想到了什 么？DFD图？这可是典型的面向过程分析模式。因此我说把用例当做功能点的分析员实际在做面向过程的分析。
而用例则不是计算机术语，UML除了在 计算机行业中应用，它也经常被应用在其它行业中。用例是一种需求方法学，虽然软件危机和OO的发展促成了它的诞生并被完美的融合进了OO体系，形成了 UML，但它实际上并不是软件行业的专用品。如果非要从功能的角度解释，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场 景，这些“功能”体现不同的组合方式。实际上，把用例解释为某个参与者(actor)要做的一件事可能更为合适。这样的一件事有以下几个特征：
一、 这件事是相对独立的。这意味着它不需要与其它用例交互而独自完成参与者的目的。也就是说这件事从“功能”上说是完备的。读者可能会想到，用例之间不是也有 关联关系吗？比如扩展，比如实现，比如继承，它看上去并不是独立的嘛。关于这个问题，笔者会在后续的文章里详细说明。这里稍微解释一下，用例之间的关系是 分析过程的产物，而且这种关系一般的产生在概念层用例阶段和系统层用例阶段。对于业务用例，这个特征是很明显的。
二、这件事的执行结果对参与者来 说是可观测的和有意义的。例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该 作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。又比如说，登录系统是一个有效的用例，但输入密码却不 是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？
三、这件事必须 由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征二。例如从ATM 取钱是一个有效的用例，ATM吐钞却不是。因为ATM是不会无缘无故吐钞的，否则，我从此天天守在ATM旁，生活无忧矣。
四、这件事必然是以动宾 短语形式出现的。即，这件事必须有一个动作和动作的受体。例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在没有水的情况下 人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的，但是笔者所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的 并不在少数。
除去以上的特征，笔者觉得用例的含义还要更深些。首先，用例的背后是一种需求方法论。其核心是以参与者为中心（区别于以计算机 系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。 换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作 了。其次，用例简直就是为OO而生的，其思想完美的符合OO。用例分析方法试图找到问题领域内所有相对独立的参与者和事件，并把业务流程当成是这些参与者 和事件之间的交互结果（在UML用活动图或序列图来描述）。因此，用例方法被吸纳到OO之后，UML得以以完备的形式出现，用例成为了真正的OO核心。在 RUP里，这种核心作用被发挥到极致，产生了用例驱动（usecase driven）的软件过程方法，在RUP里，软件生产的所有过程和产物都是围绕着用例形成的。
可以说，用例分析是OO的第一步。如果用例分 析本身出了问题，对业务架构，软件架构的影响是很大的，将大大削弱OO的优势--复用、扩展。笔者认为软件复用可以分为三个层次，最低层次的复用是代码级 复用，这是由OO语言特性提供支持的，例如继承，聚合，多态；较高层次的复用是组件级复用，这是由设计模式提供支持的，例如Factory模式, Builder模式；最高层次的复用则是服务级复用，这在很大程度上是由应用服务器和通讯协议来提供支持的，例如最近炒得火热的SOA（面向服务的应用） 架构。用例分析的好坏也许对代码级和组件级的复用影响不太大，但对服务级的复用影响却是巨大的。笔者认为服务级复用是OO的最高境界，而结构良好的用例分 析则是达到这一境界的基础。
闲话：
今天你OO了吗？
如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程，先画出业 务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到 下一个环节的。那么很不幸，你还在做面向过程的事情。
如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？....那么恭喜你，你已经OO啦！
预告：
下一篇文章将讨论如何获取用例
*********************************************************
作者coffeewoo 欢迎您访问文章原始出处 : http://blog.csdn.net/coffeewoo 以及 http://coffeewoo.itpub.net ，阅读中有任何问题可以在BLOG上留言或发邮件到 coffeewoo@gmail.com，我将尽力为您解答。具有代表性的问题我会以 Q &A的形式收录到对应的文章之后。希望本系列文章对您有帮助。欢迎转载，敬请注明，谢谢 ^_^
好文章，为什么不坚持写下去了呢！！！
我在学习UML，觉得很难把握一个度，而且很多时候没有办法，也没有什么可以评判自己所划分的用例如何，有你们这样的高手，又不惜赐教的，很好！！！
写吧？？？
最好以后可以写一些案例，这样就更完美了，
我以后会经常来看的，也会介绍在学习建模的朋友来看的，
有点八婆，哈，
最后一句：继续吧！！！
写到第四篇开始疑惑了。一是好象没人喜欢这类文章。二是再展开下去有点开枝散叶的意思，一时不知从何入手了。加上工作，就耽误下来了。
以后会继续更新的。谢谢你喜欢。
今日，拜读您的佳作，深感自己学的肤浅。
作为一个即将加入IT领域的我，您的文章让我见识了您独到的思想，和广博的知识结构与实践经验。对正在学习和实践的年轻人，其很有借鉴价值。希望您能多写写这么好的文章！坚持！我会把您的思想传给更多的人！
我是一个面向过程的设计者，想向OO设计转，你的文章对我很有帮助
不错！学习UML有一段时间了，但是不系统！
通过您的文章系统学习一下！！！
以前也在网上也阅读过讲用例分析的文章，但好像对于具体的项目没有实践的指导作用
你写的不同，
楼主能给不能根据一个具体而微的小项目,阐述一下oo分析的全过程,嘿嘿...这样更能贴近实际的感受oo分析....8过要有劳楼主了,呵呵
楼主辛苦了，还是希望你能好好写下去。
小弟我正在学习建模，不知道你有什么好的建议？
也可以给我们大家讲一下。
正在学习建模技术;没什么好说的,只有四个字,"感谢楼主!"
楼主能不能以一个具体实际的小应用为例阐述一下面向对象分析的全过程。毕竟OO是一种方法学，纯从理论上理解对于大多数的初学者来说还是有些困难的。
你 的文章思路清晰，讲解细致入理，读时偶有同感不甚欢喜，深深佩服你的OO思想之深邃，偶的梦想是成为一名伟大的系统分析师，站在软件过程的金字塔顶，按胸 中的丘壑勾勒软件蓝图。以后会多多向你学习，你是我的榜样！我的qq 15387970，非常希望你能加我为好友！谢谢！
学无止境，我无非多做了几年而已。QQ我是不用的，如果要联系的话我的MSN就是文章中公布的邮箱。有什么问题可以到以武会友去留言。谢谢光临。
顶,读后有感触
顶,读后有感触
看完＇今天你ＯＯ了吗＇，才知道．我是个完完全全的面过过程开发者．．．
非常感谢楼主．继续拜读其他文章...
不用灰心，其实OO和过程的转换只在一念之间，同一件事情你是从完整流程逻辑角度去看的？还是从人的角度去看的？流程还是要搞清楚的，无非是把流程看作是人做事以后交互的结果，而不是系统的本源，就这么一点差别：）
虽然学过面向对象分析与设计，但似乎一直理解不透。读了这篇文章感觉受益匪浅。大虾，加油哦。
赞美之言就省略了，非常仔细的看了《什么是用例》一文。条分缕析，字字珠玑，看的直呼过瘾。
不过，在看“二、这件事的执行结果对参与者来说是可观测的和有意义的。例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它 是系统的一个必需组 成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。…”这段的时候，我一直 疑惑着，系统备份删除前的数据，这个极其重要的功能需求，不在需求阶段列出来，何时列出来呢？我还没看到后续的文章，也许后续解决了，但是这个问题我不搞 清楚，我会一直认为通过获取用例的方式，并不能将系统的所有功能都得到。很多用户不参与的事情，系统会悄悄的做了。用例不列出来，系统功能不就不完全了 吗？
“系统备份删除前的数据”这样的语句其实很模糊。
有两种情况：
1.语意：逻辑删除
2.语意：客户提出的需求
假设是1的语意，那很简单，在业务用例阶段完全不需要出现“系统做什么”，只有在系统用例和之后的分析模型阶段再出现
假设是2的语意，那你就要考虑这样的语句本身对你的需求有什么样的影响？也即“备份删除前的数据”究竟是为了做什么？这也要分两种情况：
1.客户假设说我是想为了保存以前的历史数据以备不时之需
2.客户假设说我是可能想在某个报表中可以看到版本比较的信息
好，如果是1的需求，那很简单，你只是记录下这句客户的话，然后作为一个“非功能性需求”列在你最终生成的《需求规格说明书上》
如果是2的需求，那你就有必要在“备份删除前的数据”和“查看版本报表”这两个动作所处的某两个（或一个）业务用例中加上这样的“用例描述”：客户删除数据->生成历史数据->。。。->客户查看历史数据
搂主这么辛苦，看你的东西不回，有点对不住你，更何况真是受益非浅！！以后我会常来的。谢谢了！
万分感谢搂主，我是一个刚刚开始转型的程序员，您的这篇文章对我的作用实在是太重要了。
谢谢了
好东西 我刚刚要学OO 谢谢楼主了
不回复真的不是我的个性
楼主能不能结合这个图书例子用你的风格讲解一下系统分析员和架构师的区别。看了一些文章，总不得要领。感激涕零！
用例分析系列中所有的工作，都是系统分析员做的，架构师不做这些工作。但这些工作的成果是架构师工作最主要的输入之一。
夸张一点说，系统分析员可以完全不懂计算机知识。他是领域专家，是行业顾问，或者有着对陌生问题领域敏锐的视角和极强的总结，归纳能力。能够把客户分散的，杂乱的，矛盾的需求整理成为完备的，自洽的，有弹性的结构，并且能够与客户共同探讨。
架构师是计算机专家，软件的行家里手。需要深入了解各种各样的软件结构，应用模式，中间件，服务器，甚至硬件知识...具备这么全面的知识目的是为接下来 的开发工作定下基调。根据需求规模，应用环境要求，客户特殊要求，应用程序特性等，再根据公司的基本情况，来选择或决定技术路线，中间件，开发工具等。为 开发定下基调，大的架构。小公司，中，小型项目我个人意见是根本用不到架构师这个角色的，顶多一个高级设计师把握整体框架就行了。架构师还要高于高级设计 师，只有当一个项目或产品大到需要很多个开发组，产品由很多个可独立的组件组成的时候，架构师才有意义。
一锤定音！
报以雷鸣般的掌声！
我 是一个刚来公司实习的实习生，有个项目需求已经做完，而恰恰中了楼主点出的要害，按功能点划分系统。要开始建模了，自己胡乱看了两天，有点不得要领，以前 也没什么经验，第一次使用Rose,今天偶然搜到楼主的主页，感觉很好，呵呵，收藏了慢慢看，只是觉得时间很紧迫，需求又跟我的建模思想不太一致，不知怎 么下手
谢谢楼主,您所讲的太好了,学习!会常来的!
好文章，一定要顶。
恳请继续！
感谢楼主的话就不用小弟重复了,只是有一件事想请教楼主,我是一个刚刚转行到IT业不到一年时间的,现在做程序员,但我已经决定软件开发作为我的职业生涯,请问楼主能给我一点建议吗???谢谢:
IT 是个挺累人的工作，活到老学到老这句话在这个行业里再适合不过。就我个人经验来说我觉得基本功是很重要的。这些基本功包括第一个就是程序功底，不必在意掌 握多少种语言，而是深入研究某一种。如果你也是用java的就很幸福了，java的开源软件，开源框架非常之多，尽管下载下来研究源码，把学习所得应用到 实际工作中去，进步会非常之快的。
IT也有很多工种的，程序员，系统分析员，设计师，架构师，项目管理，硬件工程师。各类行业所采用的技术也有很大不同。不过如果你基本功过硬，转什么工种什么技术都会很容易。
重要的一点是在打基本功的同时考虑自己适合，喜欢什么方面的工作，再多加些努力在那个方向上。
祝你在IT大展鸿图
真 心感谢楼主的建议,我会努力做到更好的,因为我以前没有什么基础知识,听说C#语言入门比较容易,所以就选择了它,据网上以及一些书中介绍,C#是 Java的翻版,所以我想先学学C#,然后有机会再向Java转,听一些前辈说写程序要成功,就必须要做到多看多写多想;我希望楼主的文章能一直继续,陪 伴我不断的成长.
一直在oo和面向过程之间徘徊,今天的会议,也一直难以在功能点和用例的关系上困惑,看完你的文章,才觉得uml还得深入学习啊.
受益颇深，谢搂主
IT业进来不是一天两天了但觉得想做，有想法去做却是最近的事。看到你的文章忍不住回贴，其实我是个很懒的人，对不起从前各位大虾了。 楼主文章如醍醐灌顶，看了几本有关的书一直不太得要领，希望楼主继续传道解惑，有劳了！
谢谢分享
支持
新手请教：之前在网上看到“用例分析需要从用户的角度去分析，也可以把系统本身看成一个用户，那“系统备份删除前的数据”是不是也可以在用例列出呢？
或者把系统本身看成用户是错误的？
把 什么作为一个用例，前提是你事先划定了一个边界。站在边界外的是actor，边界内的是用例。边界是很重要的。它决定了你的视角和能够得出的结果。例如， 对于站在笼子外的你来看，笼子里的猴子是用例，而如果笼子里的猴子来看，用例就是你了。这是视角不同。边界同时可以决定粒度。比如，你站在汽车外时，你看 到的东西是车体大小，颜色。你在汽车里时，你看到的是仪表盘，方向盘。当把仪表盘拆开，你看到的是电路，显示版...
用例获得也是同样道理，哪些是actor，哪些是用例，粒度如何，取决于你对于边界的认定
谢谢！偶就喜欢这种通俗易懂的解释～可在书上怎么也看不到～看书上分析的例子总感觉自己已经明白，是那么回事了。但自己分析建模一个系统时，又总感觉好多东西都不确定上不了手。
好文章
好 文章,不回对不起楼主了，不过我现在很忙,看了一篇.明天中午再看第二篇,uml以前也学过,不过自我感觉没学好,现在用jsp等技术做一个小项目,考勤 系统.在确定用例时,很迷惑,不知道哪种才算用例,本来自以为自己理解了,原来还是习惯于面向过程的思想.在re:qcsoft [回复中提到,小公司，中，小型项目我个人意见是根本用不到架构师这个角色的，顶多一个高级设计师把握整体框架就行了,那么象考勤系统这种小的项目也需要 分析用例,希望楼主指点下,如果要分析用例,那么考勤登记里的登记上班时间和登记下班时间算两个用例吗,还是考勤登记就是一个用例,根据楼主说明的用例的 第一个特征:这件事是相对独立的,我想应该是分为两个用例吧.
用例分为业务用例和系统用例。业务用例描述业务需求，系统用例描述系统需求。业务用例最重要的一点是能否完整表述actor主角的期望。所以你先要弄清楚谁在驱动考勤登记，他的目的是什么。
我觉得只登记上班和只登记下班应该都是目的的一部分，所以应该登记考勤是业务用例。至于上班和下班是否在系统用例阶段要分开，取决于你打算在系统层面将它分成两个逻辑功能还是一个。
这么好的文章怎么才发现哦，相见恨晚！
楼主，请教一个问题：
我现在在做一个项目，把所有的涉及到的业务都细分成添加、删除、浏览等等类似的一个个小的用例，这应该都是业务用例了，那请问我的系统用例是哪些呢？应该怎么写？或者说有必要写吗？（你可以拿一个电子商务的系统作例子指导一下，多谢了！）
你 列举出的那些用例实际上都是系统用例了，你还怎么再细分呢？业务用例是指的业务目标，例如说维护人员档案，这是一个完整的业务目标，也是一个业务用例。至 于维护办法，有手工的，有自动的，有的只能加不能删，有的只能修改，有的只能看....这些，是实现业务目标的方法。在这些方法中，打算纳入软件开发范围 的，才叫做系统用例。
楼主，多谢你的指教
那我是不是可以这样理解呢，如果把业务用例进行功能上的细分的话，分成若干个小的用例，那么这些小的用例是不是就是系统用例？
就象维护人员档案，如果细分成添加档案，修改档案，删除档案，查看档案等等。。。
如果你的答案是肯定的话，那我是不是可以继续这样理解：一般情况下，业务用例实际上是在一个比较高的层面上来看业务逻辑，更接近于用户的直接需求，而系统用例则是业务逻辑的详细的划分，更接近与程序的设计了？
多谢你的赐教！！！！！
不大对喔。系统用例和业务用例的区别并非是细分。
请注意理解：业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。也就是对于actor来说，他所负责的业务需要由一系列的业 务目标组成。比如一个档案管理员，他的业务目标就是维护档案。比如论坛管理员，他的业务目标有维护用户，维护帖子等..这些业务目标构成actor职责的 全部。业务用例体现了需求。
而需求的实现有多种方式。如何实现它，是由系统用例来体现的，它们并不是一个简单的细分关系，虽然看上去象。就说维护档案吧，这样一个业务目标，会有多种 不同的用例场景去完成它，这些场景包括如何增加档案，如何修改档案，如何删除档案....对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪 些部分是要纳入系统建设范围的。比如维护档案业务用例中，假设由于某个原因，修改档案很困难，只能通过先删除，再全部重建的方式来实现，那么系统用例就增 加档案，删除档案，而没有修改档案。
业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。业务用例不是接近，而是完全的直接需求，系统用例也不是业务逻辑的详细划分，而是系统对需求的实现方式，但不是与程序设计无关，它只是说，要建设的系统功能性需求由这些系统用例构成。
所以业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。
大哥，多谢赐教，你这么一解释清楚多了，我现在在用例，写了好多，可是老觉得不清晰，我已经加了你的MSN，希望有机会即时请教！！
PS：很想跳槽做你的手下哦！
我想知道这些在大学时要学习吗，我们有软件工程课但是可是这些好象太深奥了，在大学时有必要学这些吗？
实际工作中大部分软件公司至少在名义上要用UML，并且事实上UML是面向对象方法的最佳实践。不论是.net技术还是j2ee技术，不论是什么项目，面向对象都是必须的知识。你觉得在大学有必要学吗？
谢谢楼主回复,感觉清晰多了
刚刚开始oo学习。
谢 谢楼主，这个blog确实好，解答了我好多的疑问。真的谢谢了。楼主的系统分析员之路第一篇讨论的是什么是用例，第三篇讨论了涉众。这里一直有一个疑问怎 么从涉众中找出系统的actor？ 就拿网上图书借阅系统来说，图书馆的一些领导希望查询系统获得他们想知道的信息，这里要不要把作为一个actor，如果是actor的话，有没有必要有 “综合查询”用例
谢 谢楼主，这个blog确实好，解答了我好多的疑问。真的谢谢了。楼主的系统分析员之路第一篇讨论的是什么是用例，第三篇讨论了涉众。这里一直有一个疑问怎 么从涉众中找出系统的actor？ 就拿网上图书借阅系统来说，图书馆的一些领导希望查询系统获得他们想知道的信息，这里要不要把作为一个actor，如果是actor的话，有没有必要有 “综合查询”用例
如果某涉众直接使用计算机系统，则该涉众就是一个备选actor。如果多个涉众使用计算机系统的目的是一样的，则只需要一个actor。
领导希望查询系统获得他们想知道的信息，如果这个信息只有领导需要，它的确是actor，如果有很多涉众都在使用，应当考虑是不是有另一个actor代理 这些涉众来使用。至于“综合查询”用例，我觉得是不准确的，至少在需求阶段，需要明确知道查询什么。而是不是“综合”起来，取决于设计而不是需求。
例如领导直接查询系统获得上架图书的统计情况，领导也直接查询系统获得借出图书的统计情况。我想说的是：领导希望查询的信息可能和几个用例都有交叉。 这个时候该怎么处理这种情况呢？
http://coffeewoo.itpub.net/post/9169/227772
这篇文章中讨论到一些关于查询的问题。拷贝到这里。
有一点是值得讨论的，就是查询用例。这是一个比较特殊的东西，因为查询的目标可以很明确，也可以很模糊。比如，我就只是查查看而已，看完了什么也不 做；也可能是因为我要租房，所以查询；还可以因为是我要查完后修改我已经发布的信息...类似这样的不同目标还有很多，显然我们不可能每一个目标都去定义 一个查询XXX业务用例。同时，一个查询可能是跨越多个业务用例的，比如把求租、寻租和用户信息集中在一个查询结果里面。在这一点上我也不能断定你专门目 标的用例：找房屋信息业务用例，和你朋友通用目标的用例：查询信息业务用例哪一个是正确的，事实上都是正确的，也都有道理，取决于客户需求中针对查询的要 求，到底是专门目的，还是模糊目的。
另外补充一点，如果是模糊的，通常查询XX作为某一个用例的扩展或者包含。例如，要删除用户，必须先查询，查询是删除的一个包含。或者，要删除用户，可以直接从列表中删除，也可以设定条件查询，查询是删除的一个扩展
拜读中～
读了您的文章，感觉思路很清晰，很实用，非常感谢。
您提到文中使用的例子是直接进入到系统用例级别，我是初学者，其实很希望能有一个包含“业务用例模型--概念模型--系统用例模型”完整的简单例子，以帮助理解并试验，您可以推荐一下或者您手头有合适的例子吗？
呵呵，不情之求，有点贪心 希望你能理解、见谅。
太好了，期待你的新书
路过，看过，收益过！！ 不顶不行！！！
不仅仅对楼主的知识佩服，更对楼主的精神和人品赞扬。
楼主给我们做了榜样，向楼主学习！！
附带：现在很多人都恃才自傲，不可否认他们的知识令人折服，但他们的人品却大打折扣。
看了好几遍了，确实受益匪浅啊，还有问题不明白，关于增删改查这样的用例，比如一个管理系统，基本都有这些操作，如果把它们看作系统用例，那么有这样一个结果，到处都有这样的用例，这样存在是否有意义，如果没有意义的话，是否可以用一个‘维护XX’这样的一个用例来代替？
我说系统用例，附带的意思是这些系统用例是可复用的。到处都有这些操作，那么它们应该被视为是可复用的部分。
例如，Hibernate提供了增删改查的API，你要做的事情是产生HQL。Hibernate提供了增删改查的API就是可复用的部分，但它是系统的，与客户业务无关。
这是用Hibernate做例子来讲，如果你的项目中不用任何的第三方框架，完全是自己的，要避免到处都有这样的用例，那么你们就要在自己的项目框架里实现这些与业务无关的的系统用例，那么与业务相关的用例就可以用“维护XX”来代替了，因为“维护”的功能已经实现了。
如果不是这样做的，如果要维护文档和代码的一致性，那到处是增删改查不可避免的。省略掉当然也可以，只不过需要大家达成共识：所有带“维护”的用例都包括“增删改查”
谢 谢，什么时候出版你的书，好想看看，增加自己的分析能力！还有一问题想请教一下，比如说图书馆登记图书这样一个事件，如果把它看作一个用例，问题就是：新 图书登记上架之前是要对图书分类，那么这个图书分类应该看作单独用例，还是登记图书中的包含用例，这个过程本来就没有清晰的界限？
表 面上看没有清晰的界限，实际上有。你这个问题是个用例粒度的问题，到底多大合适？这个问题其实是有明确界限的，就看你选择的边界在哪里。比如，你选择的边 界是整个图书馆管理，那么登记图书就是图书馆管理中的一个业务环节，而图书分类是看不到的。如果选择的边界是登记图书管理，那么分类图书、装订图书、编辑 概要等等就是适合的用例。
所以说这个过程是有明确界限的，依赖于你所选择的边界。
好，很好！！
非常感谢作者！
非常好！
表 面上看没有清晰的界限，实际上有。你这个问题是个用例粒度的问题，到底多大合适？这个问题其实是有明确界限的，就看你选择的边界在哪里。比如，你选择的边 界是整个图书馆管理，那么登记图书就是图书馆管理中的一个业务环节，而图书分类是看不到的。如果选择的边界是登记图书管理，那么分类图书、装订图书、编辑 概要等等就是适合的用例。
所以说这个过程是有明确界限的，依赖于你所选择的边界。
对边界还是不大明白。请问一下边界的选择是否有一定的原则或规则？是不是由项目组成员自己来确定这个边界？
边 界即是你面对的问题领域。边界的决定没有严格的规则，但有经验可循。面对一个复杂的问题时，为了能够把问题弄清楚，人们会把整个问题分解成一些小的问题领 域，这就形成了边界。在项目最初，边界可能是很宽泛，很粗的，随着项目的进展，信息越来越多，越来越细致，边界也会随着清晰，细致。
在分析过程中，边界绝不是一成不变的，在项目的不同阶段，面对不同的问题，总有很多种可能的边界选择。没有标准判断对错，只不过边界选择的结果要利于分析问题。当然，不好的边界选择会导致分析困难。如果根本不用边界的概念，那问题就是一锅粥了。
读过你的文章，受益匪浅！
系统用例是不是在分析模型中去处理啊，在业务用例中只是描述维护档案，而在分析模型中仔细的去分析要做什么操作
理解有误。UML是用例驱动，因此是系统用例决定了分析模型分析做什么操作，而不是因为分析模型所以系统用例。
所谓系统用例，其定义是actor与系统的交互，所以决定了分析模型的主体就是操作。
那么对于档案管理中间的一个场景来说 比如说档案的增删改
业务用例应该是档案的维护
系统用例是 档案的增加 档案的删除 档案的修改
那么分析模型中 不也是 档案的增加 档案的删除 档案的修改 起不是和系统用例做的事情一样吗?
分析模型本来就是系统用例分析的一部分，做的事情就是应当与系统用例一样的。所不同的只是表达形式，分析模型是用分析类来表达的
十分感谢您的耐心回答，还有一个问题在结构化分析中有数据模型的分析，那么用面向对象的分析数据模型不需要进行建模吗？我在您后面的那个例子里面没有发现对数据进行建模啊
另外说一下您的用例分析文章4好像页面有问题，全是乱码，rss阅读器一进就卡死了
多谢作者。这学期选了一门软件程序设计方法学，听得似懂非懂。看了作者的文章之后，感觉清楚了很多。更重要的是，让我有一种跃跃欲试的感觉。后天考试，肯定会对我有所帮助，更重要的是，对自己的工作更有帮助。感觉作者比我们老师讲得清楚，哈，可以来我们学校开讲座：）
很晚了，明天继续看。。。
系统建模时经常遇到的工作流类型应用的建模方法
在企业应用建模中，我们经常遇到的一种情况：某种业务，它由一系列顺序相关的业务活动组成，这些业务活动一般由不同的人甚至不同的部门负责，也就是说为了实现一个业务目标需要不同的职责的人或部门协作。
我们考虑一个315服务系统处理顾客投诉的应用，在业务模型中，它只是一个业务用例，我们就把它叫“顾客投诉”。
“顾客投诉”可以这样一种场景来描述：
张大头最近买了一部手机，刚用了没多久发觉是一部水货，张大头很是气愤，找到商家要求退货，不料售货员态度蛮横，不理睬他，张大头没办法，只得向315热线投诉。
315的受理人员接受了他的投诉，并记录了投诉人的信息以及投诉案件的一般情况，如手机型号、商家、购买时间等，然后要求张大头在家等消息。315协会的 管理人员很快接到了新的投诉案件信息，并将它分配给处理人员李曲去处理。然后，李曲开始处理这件事情，李曲找到李大头，把它的手机首先拿去鉴定，仅确认确 实是水货，然后李曲和张大头拿着检验报告到商家，要求他们退货，几番交涉，商家退货了事。然后李曲将这个的处理结果写了报告交给管理人员。管理人员向张大 头进行了回访，确认了此事，并签署了审批意见，然后结束了这件案子。
好了，现在要求开发这个应用，需求人员认为有以下几个业务活动：
（前台）电话受理
（主管）分派任务
（调查人员）处理案件并编写案件处理报告
（主管）电话回访用户，签署审批意见，结束案件
需求人员同样认为采用用例来描述需求既能够比较清晰又符合项目开发的要求，按照以前的习惯，我们获得了以下用例模型：
按照用例的定义，它应该是合理的，但用例之间没有关系，总让人觉得没有更好地反映出业务之间的密切的关系，实际上我们不难发现，这些业务都是围绕着一个投 诉案件来进行的，如果能够很好的描述它们的关系对于业务的理解和用户的最后价值是有帮助的，毕竟谁会使用一个只有电话受理，却不处理的业务应用呢。当然这 种关系在业务模型是中可以看出来的，因为都包括在“顾客投诉”业务用例中，但问题是并不是所有系统都建立业务模型，而且怎样在系统用例中反映它们的关系 呢，同时用例的事件流描述也会出现像“受理后将案件传给主管”等“将...传递给...”的描述，因为它们确实关系密切。
当然有人提出这种方式：将用例之间加上带箭头的连接线来表示：
但遗憾的是这并不是一种正确语义的表示方法，有些UML的CASE工具（像TogetherJ）甚至根本不让绘制这样的图形。更为重要的是如果主管需要根据“填写处理报告”用例的结果来决定是“结案”，还是需要“案件转移”到其它部门，又应该在什么地方描述呢。
当然也可以考虑单独绘制一张活动图来描述。但是这些仅仅都是关注在表示方法上的改进，更为重要的是如何从功能（业务）的关系上如何更好地反映它本来具有的自然依赖关系。
请问coffewoo兄这种情况下如何进行用例建模。
另外，该系统实现时（姑且不考虑数据与逻辑分离原则），可否实现为一个《顾客投诉类》，其中该类中有四个方法：（前台）电话受理 ；（主管）分派任务 ；（调查人员处理案件）编写案件处理报告； （主管电话回访用户）签署审批意见，结束案件。这里姑且将《案件处理报告》实现为《顾客投诉类》的多个属性。
谢谢！！
这些思考是你自己的吗？真的非常棒！能够思考这些问题，可以说你对用例方法的理解已经非深刻了！觉得你这个问题很有意思，我会把它作为一篇博文发出来的
在回答你的问题之前我先扯点别的东西，与这个问题的答案相关。昨天晚上我跟一个同事闲聊SOA，天马行空的扯了很多将来可能的商务模式和应用模型。 尽管聊天的内容玩笑和吹牛皮的成份居多，不过观点总结起来就是一个：on demand business，也就是所谓的商务随需应变。在我们的牛皮里，将来的应用系统处于一种“不确定”状态，例如，假设你想交手机费，你会请求一个交费服务， 但是你不知道这个交费服务最后将你的费用交到了哪家银行，还是哪家运营商，还是某个中介机构，你只知道你的交费成功了。甚至，交费服务的开发者自己也不知 道会交到哪里，它按照一定的规则（例如目速度最快的、最稳定的、手续费最低的...等等）搜索可以接受交费请求的其他服务提供商提供的服务，并调用它们。 这个过程是动态而不是事先定义的。社会上的各个服务机构都提供了各式各样的服务，而个人或中服务中介则可以自己定义自己的综合服务以获得赢利。例如，你可 以定义一个集交手机费、交水电费、交有线电视费、纳税....等等服务于一身的一榄子交费服务。换句话说，业务流程由使用者决定而不是服务提供商！于是， 应用系统模型变为服务机构提供服务，而使用者在使用时自行定制业务流程。
之所以扯上面的故事是因为在你的思考中，你的疑虑在于你认为如果功能之间的业务关系不能够清晰的表示出来，那么业务模型不能成立，随之编写程序也变 为不可能。正如你所说：但是这些仅仅都是关注在表示方法上的改进，更为重要的是如何从功能（业务）的关系上如何更好地反映它本来具有的自然依赖关系。
不过我并不这样看。功能（业务）之间的关系真的是“自然依赖关系”么？不，功能（业务）之间的关系是因需而存的。用你所举的例子来说，如“主管需要 根据“填写处理报告”用例的结果来决定是“结案”，还是需要“案件转移”到其它部门”之类的业务关系并不是自然依赖的，而是由315案件处理条例之类的规 则来决定的，更本质的说，是这样的规则也是因为处理顾客投诉的需求而产生的。回到我之前的故事，商务随需应变，怎么理解？需是本质，商务是形式，商务随需 而变。一旦顾客投诉需求有变，你所说的“关系密切的、自然依赖的”业务就完全有可能不再关系密切，不再相互依赖。如果这样，你还认为必须要把用例之间因为 当前业务而产生的关系当做“天然、本质”的内容来定义吗？
将用例定义为“独立”的，不定义它们之间的关系的道理就在这里。用例之间本来没有所谓的自然形成的客观关系，它们之所以发生关系，是因为业务场景的 需要，换言之，是因为需求的需要。需求变了，业务场景就变了，但业务场景变了却不意味着用例会变。举个最简单的例子，现在很多大中城市已经合并了110， 119，112等应急电话，原来打110只能报匪警，打119只能报火警。但现在打110既可以报匪警也可以报火警。我们发现，需求变了，业务场景变了， 但是用例却没变，我们不会看到民警挥舞着警棍冲入火场，也不会看到消防警拖着消防栓狂追小偷。由是得出结论：110不等于匪警，它只是匪警出警用例的一个 业务场景而已，因为这个业务场景，110应急程序和匪警产生了关系，但这个关系不是天然的。或许有一天我们每个人手机上都有一个紧急事件按钮，一按就可以 与所谓城市应急处理中心联系，而110，119，112等等服务程序则可能光荣下岗，而民警、消防警、急救中心还是一个都不能少。
不知你得到答案了吗？这种情况下进行用例建模跟你现在习惯的做法一般无二，用例仍然是独立的；它们之间的“关系”仍然体现在各种场景中；不要试图在用例之间用什么线来表示用例之间有业务关系；不要将现在的业务关系认为是用例之间的天然关系。
如果真的实现了我与同事海吹的那个将来，你所能做的是提供适合的用例，将其实现为服务；而业务场景，则是由顾客自己来决定，通过服务搜索引擎从海量 用例（服务）中挑出自己中意的，拖拖拽拽，定义出一些个性化的诸如“购房一条龙服务”、“生活费用一条龙服务”、“挑选女朋友一条龙服务”之类的业务流程 供自己使用，那才是真正的商务随需应变，on demand business!
呵呵，憧憬ing...
我使用用例我想是捕捉系统的行为，然后根据use case 为系统行为建模，感谢LZ的原创，以后会常的。。。 ^_^
拜读了这里的文章，受益良多，多谢多谢。
小弟这里有个问题想要请教。
现在正在做的一个项目，要求：对于已注册了的用户，当其
信箱（外部Mail Server，本系统不提供mail收发机能）收到新邮件时，本系统能够将新邮件的内容自动打印并保存到系统内供用户在需要的时候阅览，操作。即系统能够自动的不依赖于用户操作的从mail server获取新邮件。收信过程对用户是不可见的。
对于上面这个自动收信的机能，能否用在用例模型中描述呢。感觉似乎这个自动收信的事情是由系统自己做的，并没有外部的Actor。如果无法在用例模型中描 述这个机能，是不是应该在机能外要求说明书中描述呢。总感觉客户有“我有新邮件的时候你要自动给我打印出来，我只要在需要的时候拿打印出的纸”的需求却无 法在用例模型中表现出来，困惑中。。。
请赐教。谢谢。
你 的案例当然是有一个外部actor的，很显然它不是人类，但是所谓的“自动”其实并不自动，对计算机来说，必然有一个东西来触发这一操作。它可能是一个计 时器，每隔一段时间触发一次检查和接收新邮件的程序；也可能是另一个系统进程，持续监听新邮件的到达；无论如何，肯定是有触发者的，这个触发者就是 actor
茅塞顿开，小弟拜服。多谢coffeewoo老大。
是不是可以这样理解,业务用例是在客户视角让系统做什么？系统用例是在系统实现视角实现业务用例的一个个功能点的划分？
高人，怎么在网上总看不到您呢，已经有半年时间没有在MSN里看到您了，不知，您是否是因为忙的原因呢？
高 人，您是做中间件研发的，我没有接触过中间件，不知道中间件是否就是一个组件开发呢？还是中间件就是UML所描述的组件视图中的组件呢？中间件和一般的面 向接口编程中的面向接口而封装的职责单一的DLL是否有区别呢？能否给些解答呢，期待您的回复！另：您是走在IT行业的前沿而且您的经验也非常的丰富，而 且思考问题的方式也有独到之处！能否描述些现IT行业的前沿技术，给我们这些普通的IT人一些指导路线方针呢？再次感谢您啊！
为何不是因为业务的需求，为了实现公司商业目标，必然公司需要招聘人员，来履行其公司分配的职责。从这个角度，就不是从参与者的角度来决定不同的业务流程了，如何解释呢？
理解不对，业务用例是客户现有业务，有没有计算机客户的业务都真实的存在，手工也是业务。系统用例是说，引入计算机后，客户的哪些业务要在计算机里以怎样的模式实现
你所说的组件是运行在中间件上的。所谓中间件，就是将软件中针对某一问题领域的一系列公共解决方案集合起来，放在客户程序和问题领域之间，使得客户程序不需要直接面对问题，只需要通过中间件提供的编程模型就可以快速解决问题。
你说的DLL只是库，只是工具而已。中间件不但是大量工具的集合，也是编程模型，运行平台。本身就是一个程序。
中间件很多，.net,webshpere,weblogic是应用程序中间件，MQ是消息中间件，领域不同，还有安全中间件，交易中间件，事务中间件。。。
不理解你的问题
那请教您，中间件和软件框架的区别是什么呢？多谢啊！
呵呵，我犯了一个错误，以为所有的用例都是以系统为边界的。再次请问coffee大哥，请问业务用例如何确定边界呢？
确定业务用例边界的方法和系统如出一辙，但你的提法又有点问题。不是因为有了业务用例所以有了边界，而是相反。先有边界才有业务用例。你可以仔细体会一下本博中关于参与者的那篇文章，用例和参与者是先决定了边界，才能够确定的。
边界是一个逐步明确的过程，你总应当先假设一个，然后边界外的一切都是参与者，边界里的一切都是用例。
其实我觉得面向对象分析里最难掌握的是边界。在新书里有专门讲边界的章节。过些日子可能会发表上来，呵呵
呵呵，期待新书啊。
coffeewoo兄，我是曾经问过你统建模时经常遇到的工作流类型应用的建模方法问题的oneway——01，谢谢你的回答。
知道你对PMP，项目管理很有经验，想问你一些有关质量管理的问题，在分析设计BBS提出此问题似乎有些不合适，但不知有什么办法找到你，抱歉了！
对质量保证与质量控制的问题一直未完全搞清楚，想请教！
质量保证是在质量体系里有计划、系统的活动，提供能够满足质量需求的信任，质量控制是致力于满足质量需求。质量保证内容很多，主要包括产品质量保证与过程 质量保证。过程质量保证就是依据一定义的过程标准检查项目活动是否符合过程要求，产品质量保证应该是检查工作产品是否符合预想规定的模版要求等，质量控制 也是依据一定的质量标准检查、测试产品是否满足质量要求，但两个活动的执行者可能不一样，质量保证侧重第三方独立检查、审计（audit），质量控制为小 组内部的复审（review），不知这样理解对否。现在请问：
1、 质量控制与工作产品质量保证差别在什么地方，是否质量控制要保证工作产品内容的正确性，而工作产品质量保证只是工作产品形式上是否符合模版？
2、 比如对需求规格说明书进行评审，这个过程是质量控制，当然有质量保证人员参加。要检查文档内容的完整性、正确性、一致性等，这由技术专家负责，而质量保证人员负责保证评审过程的是否符合过程标准？
3、 有过程质量保证，那就是检查过程执行的符合性，也应该有过程质量控制。过程质量控制是什么？？就是过程的识别，程序化么？？对过程执行时控制影响过程结果质量的过程因素（人、料、工具等）是过程质量控制么？？
4、 项目质量管理一定很清楚，包括质量策划、质量保证、质量控制。质量策划应该策划出质量目标、质量标准和实现它们的质量体系（过程、资源），通过质量保证、 质量控制两个活动来实现。而质量保证又是在质量策划所策划质量体系里面有计划、有系统的活动，他的工具与方法包括质量策划、质量控制的工具与方法，是否可 以这样理解，质量保证通过定期执行，要多次执行类似质量策划的活动，以提高以后工作中的质量标准和目标；要多次执行类似质量控制的活动，从第三方角度知道 工作产品达到质量要求的情况？如果是，似乎质量保证包括质量策划、质量控制一些类似活动，质量保证的外延似乎更广，相当质量管理了？？。
5、 怎样理解一个公司的ISO9001质量管理体系与具体项目质量策划的质量体系的关系？？具体项目质量策划的质量体系可以剪裁、引用公司的ISO9001质量管理体系？？
6、 质量保证是对质量控制的质量控制，可以这么说么？？
7、 比喻对《需求规格说明书》评审（找缺陷），你觉得是质量控制还是质量保证？？
非常感谢！！！
呵呵，你这些问题非常专业了。我不是专门做质量保证的，在项目管理里虽然质量保证也是其中的一部分，不过我本人在这个领域的经验不算多，ISO体系和CMM体系虽然有过了解，但不深入，不敢回答如此专业的问题。
不过可以就我在项目实践过程中的一些经验大致说一说，我所说的是实践经验，而非专业知识。
就质量管理而言，我认为分为管理和执行两个部分。管理部分包括质量体系的采用，ISO还是CMM，软件过程的决定，质量计划（缺陷率、性能等），质量管理 组织的设立，质量标准的确定等等。也就是说，质量保证是做管理的。拿需求评审来说，确定评审流程、评审标准是质量保证要做的事情。
我认为的质量控制是实际的行为，比方说需求评审中，参与评审的各方根据质量保证所确定的流程和标准来评审需求，发现问题，提出问题，决定整改计划，执行整改等这些行为是质量控制的行为。
再比如代码的缺陷率要求，测试过程决定是质量保证要做的工作，而测试和修复缺陷的实施则是质量控制。
只能说那么多了，不知是否能回答你的问题，呵呵，我对这方面研究不是那么深入的。抱歉。
受教
你好，coffewoo朋友，还是有关用户需求的问题的请教。记得我以前一次问过此问题，你的回答是你文章中的业务需求相当于用户需求（我认为你的观点也应与RUP一致），但看了以下的一些观点以后，觉得仍难理解。以下是三种观点内容：
1、软件需求包括三个不同的层次：业务需求、用户需求和功能需求也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
2、业务建模其实分为两个部分来看。一个部分是对as－is建模。另一部分是对to－be建模。as－is，是对企业或者机构等业务建模范围的业务现状建 模，以找出其业务过程中实际存在的问题。也就是to－be建模。是对企业将来的建模。当我们对企业的业务运营问题给出一个比较好的解决方案后，企业会是一 个什么样的运行状况呢？企业不知道，我们也不知道，最好的办法，就是对to－be进行建模。对于业务建模，常见的两个问题是该做的时候没有作和不必要的时 候却做了。面对复杂业务，缺失业务建模过程使得软件工程人员根本不可能真正的理解业务，更加无法真正的理解用户需求，而是仅仅依赖用户的口述等获得大量似 是而非的理解，最终导致大量的变更，甚至更严重的问题。
3、RUP中只有一个需求模型，那就是系统用例模型。所谓业务用例模型是在项目的初始阶段，对于其项目可行性风险分析，企业流程重组，所作的企业运行流程模型。我们可以通过这个模型了解其运作过程，但是这个模型一般不是由我们来做，是由业务和领域顾问来做。
因此，我认为业务需求建模（也是业务建模，结果包括业务用例，其中有自动和手动的过程，以业务的术语说明）记录业务系统涉众从面向业务系统角度对目 前或重组后业务工作方式的理解，此时，系统的自动化边界未确定；根据“用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。”的说法，用户需求应该是最终系统使用用户对业务过程（在业务建模中描述）及对计算机实现 业务过程的处理需求的用户理解（就是以用户容易理解的语言说明），此时，系统的自动化边界应确定，这就要求增加一个用户需求建模层次；而系统需求建模（结 果包括系统用例）指定新软件系统应能完成什么工作。
这样，需求建模应该是以下几个层次，
1、业务需求建模----企业运行流程（as-is，to-be）模型（业务模型）的一部分，一般不是由我们来做，是由业务和领域顾问来做。可揭示需要改 进的地方，反映了组织机构或客户对系统、产品高层次的目标要求，业务需求建模当然也是一个分析的过程，其结论可在项目视图与范围文档中予以说明。
2、用户需求建模----我理解需增加的一层，在理解业务需求的基础上，实现其业务需求而提出的基于实际情况的具体目标，当然仍可使用用例的方式建模，便于与用户沟通，但应该是面向信息系统的。
3、系统需求建模----系统用例模型，建模系统功能需求，实现用户需求。
请问：
1、不知我理解是否正确？
2、是否实际工作中一般将我上述的业务需求建模和用户需求建模合在一起完成，如果是这样的话，这一工作的结果一方面要面向业务系统，另一方面要面向信息系统，似乎也不好操作。
3、好多书籍和资料都认为在需求阶段做两件事，业务需求建模和系统需求建模。业务需求建模建模目前业务运作方式并得到业务需求用例，系统建模得到系统用例来实现业务需求用例。
我认为这又似乎和你观点一致又不一致，一致表现在：都是两个子阶段，后一子阶段一致；不一致就是前一子阶段不是建模你所说的用户需求（你的观点认为你的业 务建模的确是在描述用户需求），因为这里前一子阶段建模的业务需求是面向业务系统的，而你所说的用户需求应是需求的三个层次所描述的用户需求，它似乎是面 向信息系统的提出的。
是否你说的用户需求也是面向业务描述的，与需求的三个层次所描述的用户需求一致，而我认为的需求的三个层次所描述的用户需求是面向信息系统的不对？
另外你的观点认为，业务建模是从用户需求开始的，似乎不必建模系统目前的业务过程，但好多书籍和资料都认为业务需求建模要建模系统目前的业务过程。假如既要建模目前业务运作方式和流程，又要建模我所说的用户需求，是否应按我在上面所说的三个层次来做？？
4、用户需求是面向信息系统的，用用户容易理解的语言描述，当然包括业务术语和必要的信息技术术语,业务建模的业务需求面向业务术语描述的说法对么？
请赐教！！谢谢！
5、用户需求是用户向业务系统提出的业务需求，向信息系统提出的系统需求，还是向信息系统提出的业务需求？？
请赐教！！谢谢！
我 还是一个学生，不过我即将会走上IT行业的，可是我还有很多的知识不够牢固，这样是不是找不到工作呢？你在IT这一行这么久，能不能向我们说说你的求职心 得，或者是给我指点指点呢？现在我也在学UML建模，可是往往听不懂，老师的题目都不会做，我很着急。希望前辈多多指教，小师妹在这谢礼了？下回我有不懂 的题目，能不能放到这上问你，你大概几天可以回复呢？
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
