場景:(呼叫中心的種類）（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。 –