场景:(呼叫中心的种类）（1）客户请求技术人员。 （2）请求进入队列以供技术人员查看。 （2b）客户收到关于提交数据的确认电子邮件（3）技术人员处理请求（3b）每个人都收到电子邮件（4）请求已完成（5）技术人员提交已完成请求的数据（6）已结束请求。创建一个用例图...我是否过于复杂
所以左边的两个演员。不是所有的东西都要正确连接？因此，客户获取电子邮件和提交数据绘制。 对于技术演员，他们处理交互并提交数据和获取电子邮件。
我念叨UML这里：http://www.soberit.hut.fi/T-76.115/01-02/palautukset/groups/Fireball/t2/docs/UseCaseMethod.html
想知道是否应该对代表数据库图的右侧的演员？我错过了什么？你怎么知道你用一个用例图完成了？
系统中不包含参与者，他们是系统的外部参与者。通常，数据库在系统中，它不是演员。
例如，对于您的情况，如果技术人员必须知道如何去客户，则辅助演员可以是谷歌地图，因为他必须看到旅行的地图。在这种情况下，在使用情况下，谷歌地图达到了地图。
我知道确保UCs完成的唯一方法是查看它们和/或获取客户需求清单并使用UCs追踪客户需求。
希望得到这个帮助。
更多： @Kilian关于功能的评论是一个真正的好评。通常，当我们开始时，我们认为用例是“实现某个功能的工作流程”，或者作为所有用户界面菜单的集合，但事实并非如此。
所以@Waren，我可以建议：
先试着用一个标题和一个paragph deifning系统的主要任务定义系统。系统不仅是您要编写的代码，而且还将为其部署的所有代码（机器，虚拟机，db，bay，swicht，过程，DDL，配置文件等）
然后定义需求，系统必须满足的高级需求（iso项应参见enter link description here）
然后定义actors/stackeholder和继承层次结构来确定所需的角色和权限。不要忘记所有的操作需求（监控，备份/恢复，DRS程序，报告，部署等）
然后定义您的用例思维功能或单个增加值并检查整个一致性。关于UC的一个好处是描述“错误/例外”情况。
然后一个有趣的观点可能是定义系统的模式：安装，生产现场测试，生产，更新/补丁，维护，系统停止和删除。就像那样，你一定会覆盖整个系统生命周期。
本文有一些非常错误的地方。用例描述了一个单独的增值。这将在某些情况下完成。本文的作者只是从函数开始。这是**明显错误**。您应该更好地阅读Bittner/Spence。 –