大概的看了下用例图，觉得太简单
一般都是先介绍角色、用例、连接等等，然后就是泛化、包含
看了几个用例图，感觉根本体现不出来任何业务方面的东西
而用例文档中的主要事务、前提条件、结果、主要流程、例外流程等，用用例图好像都不能体现出来
因此，请问画了用例图以后还要写用例文档吗？
如果还要写的话，那用例图在这当中究竟起了哪些作用？
------解决方案--------------------------------------------------------
1、用例的核心是文字而不是图。
2、用例图可以不画，但用例必须写。
3、用例图只是帮你理解用例间的关系。
------解决方案--------------------------------------------------------
我觉得你画的东西应该说是用例模型，是用来表现整体业务的。针对单个用例还需要以一定规范的用语来进行描述性说明，说明其价值和使用方式。这样的用例部分才是完整。
------解决方案--------------------------------------------------------
众多的细节，比如说初始条件，异常处理等都不是图例能表达清楚的。
------解决方案--------------------------------------------------------
把说明写的幽默点，让别人看起来有意思，哈哈哈，
越多的人看你的文档，写这份文档的意义越大，就越有成就感，就能写出更好的文档
------解决方案--------------------------------------------------------
这个要看项目情况了。
一般说来，如果项目比较大，是需要有文字说明的。
------解决方案--------------------------------------------------------
用例的步骤描述才是用例的核心，用例图可以结合活动图说明流程。
------解决方案--------------------------------------------------------
用例文档是必须写的。
主要包括以下四个方面：
1、前置条件（必须）：必须的输入
2、后置条件（必须）：做完后生成什么
3、基本流程（必须）：（只能出现两个角色：即 “用户” 和 “系统”）
4、扩展流程 ：如果基本流程中出了问题该如何处理
------解决方案--------------------------------------------------------
RUP4+1视图里面用例图及用例描述是最重要的，毕竟之后的工作都是用例驱动的
------解决方案--------------------------------------------------------
用例图的作用：
1.识别用户角色，actor
2.识别系统边界，哪些是本次开发系统要做的，哪些是legacy系统做的等等
3.展示给用户看系统的主要功能，便于进一步细化（因为跟客户谈的时候是要先把大致的功能确定下来，才能就每个功能进一步谈下去的，不可能一次性搞定，要不断迭代）
写用例文档是个重头戏，工作量的大头
肯定要写的，而且要写的尽量详细，而且还要让用户认可才行