A diagram przypadków użycia to podstawowy narzędzie modelowania w inżynierii wymagań używany do wizualizacji interakcji między aktorami (użytkownikami lub systemami zewnętrznymi) i systemem (lub jego funkcjonalnościami). Pomaga stakeholderom zrozumieć, co system musi robić z perspektywy funkcjonalnej i pełni funkcję mostu komunikacyjnego między zespołami technicznymi a użytkownikami biznesowymi.
Mimo swojej prostoty, diagram przypadków użycia jest często stosowany niepoprawnie z powodu złej identyfikacji aktorów, niejasnych przypadków użycia lub niepoprawnych relacji. Niniejszy przewodnik ma na celu wyjaśnienie kluczowych koncepcji, zaproponować metodologię krok po kroku, oraz wyróżnić typowe pułapki do uniknięcia.
| Koncepcja | Wyjaśnienie |
|---|---|
| Aktor | Użytkownik, organizacja lub system zewnętrzny, który interakcjonuje z systemem. Wykonuje rolę „użytkownika” w kontekście systemu. Przykłady: uczeń, nauczyciel, administrator, brama płatności. |
| Przypadek użycia | Opis konkretnego celu lub funkcji, którą system wykonuje dla aktora. Określa co co system robi, a nie jak. Przykłady: „Zarejestruj się na kurs”, „Zgłoś oceny”, „Wygeneruj raport”. |
| Granica systemu | Granica oddzielająca system od zewnętrznych aktorów i systemów. Wszystko znajdujące się wewnątrz granicy jest częścią systemu. |
| Związek | Linia łącząca aktora z przypadkiem użycia, wskazująca, że aktor może wykonać ten przypadek użycia. |
| Generalizacja | Relacja, w której jeden aktor dziedziczy zachowanie od innego (np. „Student” jest rodzajem „Użytkownika”). |
| Zależność | Relacja wskazująca, że jeden przypadek użycia zależy od innego (e |
| .g., „Wygeneruj raport” zależy od „Pobrania danych studenta”). | |
| Zawiera | Przypadek użycia, który jestwymaganydla wykonania innego (np. „Zgłoś oceny” zawiera „Weryfikację numeru studenta”). |
| Rozszerza | Przypadek użycia, którywarunkowododaje funkcjonalność (np. „Wyślij powiadomienie” rozszerza „Zgłoś oceny”, gdy oceny są poniżej progu). |
⚠️ Uwaga ważna: Przypadki użycia nie dotycząfunkcji— dotyczącelów funkcyjnychspełniających potrzeby użytkownika.
Zadaj sobie te podstawowe pytania, aby zidentyfikować wszystkich istotnych aktorów:
| Pytanie | Dlaczego to ma znaczenie |
|---|---|
| Kto korzysta z głównych przypadków użycia? | Określa podstawowych użytkowników (np. studenci, profesorowie). |
| Kto potrzebuje wsparcia w codziennej pracy? | Wyznacza role wsparcia (np. personel HR, wsparcie IT). |
| Kto odpowiada za administrację systemu? | Określa role administratora (np. menedżer systemu, administrator bazy danych). |
| Z jakimi zewnętrznymi urządzeniami/systemami oprogramowania system się komunikuje? | Określa systemy zewnętrzne (np. e-mail, brama płatności, ERP). |
| Kto interesuje się wynikami systemu? | Określa stakeholderów (np. rodzice, członkowie zarządu). |
📌 Wskazówka: Zaczynaj od najważniejszych użytkowników i rozszerzaj na zewnątrz. Użyj scenariuszy z rzeczywistego świata lub rozmów, aby zweryfikować identyfikację aktorów.
💡 Przykład: W systemie zarządzania studentami uczelni, aktorami mogą być:
Student
Pracownik naukowy
Konsultant akademicki
Urzędnik administracyjny
Brama płatności
System ERP
Po identyfikacji aktorów zadaj następujące pytania dotyczące każdego z nich:
| Pytanie | Cel |
|---|---|
| Jakie są główne zadania, które aktor musi wykonać? | Określa cele funkcjonalne (np. zarejestrować się, zapisywać się, przeglądać oceny). |
| Czy aktor chce wykonać zapytanie lub zmodyfikować dane w systemie? | Wskazuje operacje odczytu/zapisu (np. przeglądanie rekordów, edycja profilu). |
| Czy aktor chce poinformować system o zmianach w innych systemach? | Wskazuje na wyzwalacze oparte na zdarzeniach (np. powiadomienie systemu, gdy dodano kurs). |
| Czy aktor powinien zostać poinformowany o nieoczekiwanych zdarzeniach? | Wskazuje przypadki użycia powiadomień (np. „Ostrzeżenie: Wykryto przeciążenie kursu”). |
📌 Użyj prosta, skierowana na cele język. Unikaj terminów technicznych.
✅ Dobry przypadek użycia: „Zapisz się na kurs”
❌ Zły przypadek użycia: „Prześlij formularz rejestracyjny z walidacją” → staje się zbyt techniczny.
Przypadki użycia mogą być modelowane na różnych poziomach:
| Poziom | Opis |
|---|---|
| Przypadki użycia najwyższego poziomu | Szerokie cele funkcjonalne odzwierciedlające cele biznesowe (np. „Zarządzaj rekordami studentów”). |
| Udoskonalone przypadki użycia | Szczegółowe działania wyprowadzone z celów najwyższego poziomu. |
🔁 Iteracyjna metoda rozwoju:
Zacznij od celów biznesowych najwyższego poziomu.
Rozbij je na podcele.
Udoskonal każdy przypadek użycia, aż stanie się on konkretny i możliwy do wykonania.
📌 Przykład rozkładu:
Poziom najwyższego: „Wsparcie administracji studentów”
Udoskonalenie:
Student może się zarejestrować
Student może się zapisać na kursy
System przechowuje oceny
System wysyła potwierdzenie zapisu
To zapewnia, że system spełniaceli biznesoweprzy jednoczesnym pozostaniupraktycznym i testowalnym.
Teraz umieść aktorów i przypadki użycia na diagramie i połącz je odpowiednio.
[Aktor] --> [Przypadek użycia]
↑
[Include] [Extend]
↓
[Zależność]
Umieść aktorów poza granicą systemu (zazwyczaj po lewej, prawej lub górnej stronie).
Umieść przypadki użycia wewnątrz granicy systemu (w centrum lub poniżej).
Użyjlinii ciągłychdo połączeń.
Użyjlinii przerywanychdo zależności.
Użyjstrzałek dołączenia (→)dodołączeniazależności.
Użyjstrzałek rozszerzenia (→)dorozszerzać relacje.
Unikaj nakładania się przypadków użycia; utrzymaj diagram czytelny i przejrzysty.
📌 Przykład wizualny (oparty na tekście):
+------------------+
| Student | --> Zapisz się na kurs
+------------------+
|
v
+------------------+
| System | --> Przechowuj zapisy na kursy
| (Granica) |
+------------------+
^
|
+------------------+
| Brama płatności| --> Przetwarzaj opłatę za kurs
+------------------+
🚨 Powszechny błąd: rysowanie aktorów wewnątrz granicy systemu — oznacza to, że są częścią systemu, co nie jest prawdą.

Ten diagram został wygenerowany przez czatbot AI Visual Paradigm:

| Pułapka | Dlaczego to jest źle | Jak to naprawić |
|---|---|---|
| 🚫 Zbytnie skomplikowanie aktorów | Tworzenie zbyt wielu aktorów (np. „John Doe”, „Sarah Smith”) zamiast grupowania ról | Grupuj podobne role (np. „Student”, „Pracownik naukowy”) |
| 🚫 Używanie nieprecyzyjnych przypadków użycia | Frazy takie jak „zarządzaj danymi”, „zrób coś” | Zastąp je konkretnymi, celowo skierowanymi frazami (np. „Zgłoś zapis na kurs”) |
| 🚫 Brakujące zależności | Nie pokazywanie, jak jeden przypadek użycia zależy od innego | Dodaj dołącz lub rozszerzać relacje tam, gdzie są potrzebne |
| 🚫 Niepoprawne użycie „rozszerzać” | Używanie rozszerzyć dla normalnych przepływów pracy |
Użyj uwzględnij dla kroków wymaganych; użyj rozszerzyć tylko dla opcjonalnych, warunkowych |
| 🚫 Ignorowanie systemów zewnętrznych | Nie uwzględniając bram do płatności, e-maili itp. | Zidentyfikuj wszystkie systemy zewnętrzne i pokaż ich interakcje |
| 🚫 Używanie tylko jednego aktora | Zakładając, że tylko jeden użytkownik korzysta z systemu | Zidentyfikuj wszystkich interesariuszy i ich potrzeby |
| 🚫 Używanie żargonu technicznego | np. „Zaktualizuj bazę danych”, „wywołaj API” | Przytrzymaj się zachowań funkcyjnych — „Złożenie wniosku” jest lepsze |
| Ćwiczenie | Wyjaśnienie |
|---|---|
| ✅ Zaczynaj od celów biznesowych | Modeluj od góry — dopasuj do celów strategicznych. |
| ✅ Zajmij interesariuszy na wczesnym etapie | Przeprowadź rozmowy z użytkownikami końcowymi lub eksperckimi, aby zweryfikować przypadki użycia. |
| ✅ Zachowaj niezależność przypadków użycia | Każdy przypadek użycia powinien reprezentować jedno, jasne cel. |
| ✅ Używaj scenariuszy z rzeczywistego świata | Bazuj przypadki użycia na rzeczywistych aktywnościach użytkowników (np. student rejestrujący się na zajęcia). |
| ✅ Weryfikuj z zespołem | Przejrzyj diagram z programistami, testerami i analitykami biznesowymi. |
| ✅ Aktualizuj iteracyjnie | W miarę zmian wymagań, doskonal diagram w mniejszych cyklach. |
| ✅ Dokumentuj przypadki użycia szczegółowo | Zawieraj w osobnym dokumencie warunki wstępne, warunki końcowe oraz kryteria sukcesu/porażki. |
[30] Inżynieria wymagań – Podstawowy tekst dotyczący modelowania przypadków użycia.
[27] Identyfikowanie przypadków użycia w wymaganiach oprogramowania – Praktyczne metody wyprowadzania przypadków użycia z aktorów.
[16, 40] – Kompletna literatura dotycząca inżynierii wymagań i projektowania systemów.
Standardy IEEE/ISO: ISO/IEC 29148 – wytyczne dotyczące specyfikacji przypadków użycia.
Zalecane książki:
Wymagania oprogramowania: zrobienie tego dobrze od razu przez Ian Sproula
Zjednoczony proces rozwoju oprogramowania (RUP) – wprowadza modelowanie przypadków użycia w UML
Użytkownik
Bibliotekarz
Administrator
System katalogu internetowego
Brama płatności
Użytkownik:
Wypożycz książkę
Zwróć książkę
Szukaj książek
Zobacz status członkostwa
Bibliotekarz:
Wypożycz książki
Zwróć książki
Zaktualizuj rekordy książek
Wygeneruj listę przeterminowanych
Administrator:
Dodaj nowe książki
Zarządzaj kontami użytkowników
Wygeneruj raport roczny
System katalogu online:
Szukaj książek
Powiadom użytkownika o nowych pozycjach
Brama płatności:
Przetwarzaj kary
Przetwarzaj opłaty za przedłużenie
Użytkownik → Wypożycz → Zawiera → Zwróć
Bibliotekarz → Wypożycz → Przedłuż → Wyślij przypomnienie (jeśli przeterminowane)
Administrator → Dodaj książkę → Zawiera → Zaktualizuj katalog
Ten diagram jasno pokazuje, kto co robi, co może robić i jak systemy się ze sobą oddziałują.
✅ Czy zidentyfikowałem wszystkich istotnych aktorów?
✅ Czy przypadki użycia są opisowe i skierowane na cele?
✅ Czy wszyscy aktorzy są połączeni z co najmniej jednym przypadkiem użycia?
✅ Czy zależności (zawiera/przedłuża) zostały poprawnie zamodelowane?
✅ Czy brakuje jakichkolwiek aktorów lub przypadków użycia?
✅ Czy diagram jest łatwy do odczytania i zrozumienia?
✅ Czy przeszedłem go przez stakeholderów?
Tworzenie diagram przypadków użycia to więcej niż tylko rysowanie linii i prostokątów — to proces strategiczny który wymaga głębokiego zrozumienia potrzeb użytkowników, jasności w języku, i uwagi na szczegóły.
Choć diagram wydaje się prosty, nieprawidłowe wykorzystanie aktorów i przypadków użycia prowadzi do słabego projektowania systemu, pominiętych wymagań i frustracji użytkowników. Postępując zgodnie z krokami w tym przewodniku — identyfikując aktorów poprzez pytania z życia codziennego, wyprowadzając przypadki użycia z potrzeb aktorów i unikając typowych pułapek — możesz tworzyć dokładne, działające i zgodne z oczekiwaniami stakeholderów diagramy przypadków użycia.
✅ Pamiętaj: Dobry diagram przypadków użycia opowiada historię — historię o tym, jak użytkownicy współdziałają z systemem, aby osiągnąć swoje cele.