To jest to co zrozumie Klient, najprostszy diagram do pokazania, zawiera zakres projektu, granice systemu (najważniejsza rzecz) i aktorów (część różowa tylko dla lepszego zrozumienia treści artykułu). Inny System, jeżeli inicjuje akcję czyli żąda usługi także jest aktorem, ale System realizujący na nasze zlecenie jakieś usługi nie jest aktorem, jest tylko wywoływany, sam z siebie nie inicjuje żadnej akcji. On realizuje jakąś potrzebną nam funkcję. Może się okazać, że Zewnętrzny system ma zarówno interfejs oferowany jak i wymagany, wtedy w projekcie, na diagramie przypadków użycia, warto operować nie nazwą zewnętrznego systemu (np. ERP który może mieć dziesiątki interfejsów oferowanych i wymaganych) a nazwą usługi (interfejs oferowany) lub zdarzenia (interfejs wymagany) będących przedmiotem takich akcji i zakresu projektu. Diagram przypadków użycia to pierwszy test zrozumienia tego co i po co ma powstać. Jest to bardzo prosty diagram i dlatego każde uproszczenie lub niezrozumienie, prowadzi nie raz do poważnych nieporozumień a bywa, że do krachu projektu. To bardzo ważny diagram. Powie nam do czego Systemy Projektowany będzie używany, to cel sponsora. Na tej podstawie można wybrać gotowe oprogramowanie i testując je ocenić przydatność (nie radze wybierać gotowego oprogramowania na bazie prezentacji!). Ale diagram ten nigdy nie powie jaką logikę należy zaimplementować, dlatego w przypadku tworzenia oprogramowania konieczny jest jego projekt: model dziedziny systemu, jako kolejny etap projektu na oprogramowanie dedykowane. Przypomnę także, że przypadki użycia w wersji minimalnej powinny mieć opis: cel jego użycia (co Aktor chce osiągnąć) stan początkowy (wejście, dane wejściowe, itp.) stan końcowy (wyjście, dane wyjściowe itp.) Tu zwracam uwagę, że powyższe to zarazem testy akceptacyjne otrzymanego oprogramowania.