7 złych praktyk tworzenia przypadków użycia

Przypadki użycia łatwo jest stworzyć je źle. Kiedy robisz je źle? Przeczytaj ten wpis i twórz idealne przypadki użycia i stosuj dobre praktyki, aby zaoszczędzić swój czas.

Spis treści

Przypadki użycia - 7 złych praktyk

Cześć!

Tworzenie poprawnych i przydatnych przypadków użycia to niewątpliwie sztuka. Wiele osób wykorzystuje przypadki użycia podczas analizy. Potrzeba jednak dużo doświadczenia, wiedzy i cierpliwości, aby stworzyć je poprawnie i zgodnie z najlepszymi praktykami. 

Zanim przejdziemy dalej, ustalmy, czym są przypadki użycia, o których jest artykuł?

„Przypadek użycia reprezentuje określone, inicjowane przez aktora zachowanie lub zestaw zachowań systemu, którego celem jest z góry określony i przydatny dla aktora rezultat, może zawierać możliwe warianty jego podstawowego zachowania, w tym wyjątkowe zachowanie takie jak obsługa błędów, oznacza konkretne (w celu uzyskania konkretnego efektu) użycie Systemu; kluczowe pojęcia skojarzone z Przypadkami Użycia to Aktor i System (na podstawie UML v.2.5.1., www.omg.org).”

Nieco upraszczając definicję, można powiedzieć, że przypadek użycia przedstawia zachowanie lub zestaw zachowań systemu na bodźce podchodzące z jego otoczenia (użytkownika lub inne systemy). Stosujemy go więc 2 przypadkach:

  1. Aby zobrazować funkcjonalności systemu od strony użytkownika
  2. Aby zobrazować usługi integracyjne, które są widoczne na zewnątrz systemu

Stworzone zostało już wiele treści jak tworzyć przypadki użycia, w tym artykule wskażę czego unikać podczas ich tworzenia. Artykuł powstał na podstawie moich doświadczeń oraz znajomych z branży, ponieważ zauważyliśmy pewne bardzo złe praktyki, które wypaczają sens tworzenia przypadków użycia i utrudniają późniejsze utrzymywanie dokumentacji.

Przypadki użycia - 7 złych praktyk

Dlaczego?

Zanim przejdziemy do złych praktyk, zobaczmy, dlaczego takie praktyki powstają. Wyobraź sobie następującą historię:

„Pewnego dnia do firmy został zatrudniony Stanisław. Jest on analitykiem z niewielkim doświadczeniem i wciąż z brakami wiedzy, w pewnych ważnych obszarach. W poprzedniej pracy niestety nabył praktykę „Klient ma zawsze rację”.

Pewnego dnia podczas pracy z klientem dostał zadanie identyfikacji oraz stworzenia przypadków użycia. Zrobił to zgodnie ze znanymi zasadami i przesłał do klienta.

Klient odpowiedział, że w ramach tych przypadków chciałbym mieć opisane, z którego ekranu zaczyna się scenariusz, oraz aby w opisie kroków scenariusza było opisane, na którym ekranie jest aktualnie użytkownik i jakie pola ten ekran zawiera. Chciałbym również, aby w ramach tych opisów zawierały się wszelkie reguły biznesowe, walidacje na polach i ogólnie, aby taki przypadek zawierał wszystko.

Ku zasadzie „klient zawsze ma rację”, Stanisław poprawił przypadki. Efekt był niesamowity, duże obszernie opisane przypadki użycia z nawet 20 krokami. Największy z przypadków ma ponad 6 stron A4. Pojawiły się oczywiście diagramy i nawet przypadki, które nie posiadają scenariuszy, lecz są „ważną” częścią całości.

Stasiek przesłał wynik swoich prac do klienta, więc klient ucieszony zaakceptował i rozpoczęli realizację. Od początku zespół nie wiedział jak czytać te przypadki i przeszukiwanie dokumentu zajmowało ogromną część czasu podczas pracy. Developerzy denerwowali się, ponieważ te same rzeczy, występowały w wielu miejscach dokumentu i ciężko było mówić o spójności. Stanisław stale musiał konsultować ze zespół i z klientem.

Klient z racji tego, że Stanisław spełnił jego życzenie, uznał to za swój wkład w świat analizy i teraz wymaga tego we wszystkich kolejnych projektach…”

Historia Stanisława

Czy takie dokumentowanie jest dobre i czy ma sens, przy pełnym wachlarzu dostępnych technik i narzędzi analizy? Moim zdaniem nie.

Złe praktyki

Czas na to, po co tu przyszedłeś. W rozdziale tym przedstawiłem złe praktyki, których należy unikać podczas tworzenia przypadków użycia.

Diagram przypadków bez opisu przypadków

Pierwszy błąd to diagram przypadków użycia, bez jakiegokolwiek opisu zaprezentowanych przypadków. Zespół nie mając informacji o zawartości „chmurek” musi sam opracować zasady działania systemu (więc nie wykonałeś swojej pracy, tworząc przypadek użycia!). Diagram sam w sobie niesie małą wartość, ponieważ po jednym zdaniu w nazwie, nie dowiesz się, jak ma dokładnie działać system, a taką wartość muszą dawać przypadki użycia.

Błędne stosowanie relacji

W wypadku błędnego stosowania relacji zauważam dwa warianty.

  1. Nie znajomość zasad korzystania z relacji 
  2. Braki wynikające z innych błędów w tworzeniu (zawieranie interfejsu itd.)

Pierwszy dość szybko można wykryć, jeżeli znasz zasady tworzenia relacji, w drugim przypadku trzeba nieco doświadczenia, aby go zauważyć i odpowiednio poprawić. Kiedyś spotkałem się z sytuacją, gdy ktoś stworzył diagram, aby był diagram, bo tego wymagała umowa i nikt nie sprawdzał tej części dokumentacji. Szkoda, ponieważ z dobrze stworzonego diagramu z poprawnymi relacjami, można szybko i efektywnie określić co jest do zrobienia i w jakiej kolejności. Nawet jeżeli chcemy tylko i wyłącznie poznać system jako nowa osoba w zespole.

Powyżej, jest przykład źle zrobionego diagramu i podziału przypadków użycia. Unikaj takiego podejścia! Jest tu błędne zastosowanie relacji, zła identyfikacja i uwidacznia efekt opisu elementów interfejsu w ramach przypadku użycia. 

Przejdźmy teraz do błędów z powyższego diagramu. Pierwszy błąd to identyfikacja przypadku użycia na podstawie interfejsu, czyli „Wyświetliłem ekran główny”. Drugi błąd, to „Zalogowałem się”, co nie może być przypadkiem użycia. Trzeci błąd jest powiązany z  „Use Case 3”, przypadkiem niemający żadnej relacji do aktora, ani innego przypadku użycia. Czwarty błąd, który można podejrzewać to relacje extend, przy czym tutaj trzeba wejść w opis samych przypadków i ich zależności, ponieważ czasami z tzw. Big Picture coś wygląda błędnie, lecz jest bardzo dobrze zrobione.

Stosowanie relacje jest bardzo pomocne w zrozumieniu, dlatego ważne, aby zrobić to poprawnie i z głową.

Za duże lub za małe

Czasami spotykane przypadki użycia mają 15-30 kroków w scenariuszu głównym i do tego scenariusz alternatywne. Bez wizualizacji w postaci diagramu aktywności, odbiorca nie ma szans, zrozumieć jak coś działa i czasami, taki przypadek opisuje zbyt duży obszar systemu, więc powinien zostać podzielony. Dobrą praktyką jest zawieranie do 8-10 kroków w scenariuszu, ponieważ pozwala to na zrozumienie jego przebiegu i zależności w przeważnie pierwszym czytaniu.
Oczywiście pojawia się też sytuacja odwrotna, gdy pojawiają się przypadki ze scenariuszami, posiadającymi 1-2 kroki. Tworzenie takich elementów również nie ma sensu, ponieważ opisuje to przeważnie coś, co powinno zostać opisane poprzez np. wymaganie.

Przypadki użycia zawierają elementy intefejsu

Miejscem do opisu interfejsu musi być dedykowana część dokumentacji, gdzie opiszemy ekrany, listę pól, logikę pól i odwołania do funkcjonalności. Niestety, zbyt często miejscem tym stają się przypadki użycia. Przez to pojawiają się późniejsze problemy z utrzymywaniem aktualności przypadków użycia z nadmiarem w postaci opisu interfejsu (np. Użytkownik musi kliknąć przycisk „Kliknij tutaj”, zostanie wyświetlony ekran „klikacz tutejszy” … ). W moim odczuciu powodem, dlaczego tak przypadki są tworzone, jest obrazowość opisu, ponieważ łatwiej jest wyobrazić sobie przycisk niż wybór opcjiSpecyficzne słowa, których należy unikać to nazwy elementów np. przycisk, lista rozwijana, checkbox itd. Popełnienie tego błędu, bardzo szybko prowadzi do niespójności w dokumentacji i kosztownego utrzymywania aktualności dokumentów.

Łączenie wszystkich przypadków z jednym

„Czy wiesz o tym, że możesz zrobić to w alternatywnym scenariuszu i nie dodawać kolejnego przypadku?” – mniej więcej podobne słowa kiedyś usłyszałem. Następnie za namową tej osoby powstał wielki scenariusz z kilkoma scenariuszami alternatywnymi. Niestety to był duży błąd, ponieważ jak potem okazało się, była to inna funkcjonalność. Jest to pułapka, w którą można wpaść. Jeżeli pojawia się wiele scenariuszy alternatywnych, należy zrobić krok wstecz i sprawdzić, czy przypadek użycia nie zawiera w sobie wielu funkcjonalności i jeżeli to się potwierdzi, podzielić go zgodnie z wynikającymi funkcjonalności. Tworząc przypadek użycia ogranicz opis do tego co jest niezbędne, do przekazania. Nie trzeba opisać całego świata. Czasami wystarczy jedynie odnośnik do „ważnego” elementu. Pamiętaj! Przypadek użycia to nie scenariusz filmu!

Przypadek użycia zastępuję całą dokumentację

Przypadek użycia ma pewną formę, która świetnie odwzorowuje to co dzieje się w systemie. Jednak czasami, w ramach opisu jest to nadużywane. Wynikiem tego jest zawieranie w scenariuszu wcześniej wspomnianych elementów, które nie powinny się tam znaleźć jak np. reguły biznesowe czy opis interfejsu. Są to zawsze rzeczy nadmiarowe, które powinny mieć swoje oddzielne miejsce w dokumentacji i być odpowiednio opisane. 

Brak zastosowania struktury przypadku

Ostatni błąd, który często jest przyczyną wszystkich powyższych to BRAK ZASTOSOWANIA SZABLONU lub brak jego zrozumienia!

Jeżeli zaczynasz tworzyć przypadek użycia, zastosuj szablon. Następnie przeczytaj instrukcję oraz zobacz przykład, jak powinien zostać prawidłowo wypełniony dokument. Wiele jest standardów, świetnych artykułów, szkoleń, a temat „jak tworzyć przypadki użycia” przewija się co chwilę na blogach, więc nie będziesz miał problemu w stworzeniu czegoś własnego, jeżeli nie masz firmowego szablonu.

Aby Cię naprowadzić, określę w skrócie, tylko że przypadek użycia, powinien być opisany następującymi cechami:

  • Nazwą
  • Opisem wprowadzającym
  • Warunkami wstępnymi
  • Sposobem użycia (Scenariusze) – jak coś się dzieje i jak ma zachować się funkcjonalność podczas wyjątków.
  • Wymaganiami specjalnymi 
  • Warunkami końcowymi
  • Zależnościami i relacjami

Zawsze zaczynaj od szablonu i jego zrozumienia! Dopiero wtedy twórz piękne opisy.

7 Złych praktyk tworzenia przypadków użycia - BLOG - Podsumowanie

Podsumowanie

Mam nadzieję, że wpis ten dostarczył Ci nieco wiedzy, o tym, gdzie szukać dobrych praktyk oraz dowiedzieć się czego unikać podczas tworzenia przypadków. Jeżeli chcesz dowiedzieć się więcej, daj znać w komentarzu lub napisz do mnie.

Jeżeli już teraz chcesz dowiedzieć się więcej, przejdź do Bibliografii i zapoznaj się z dobrymi praktykami innych autorów!

Bibliografia

  1. Wolski M. (Data dostępu: 2020-11-11). wolski.pro. Artykuł „Diagram przypadków użycia”: https://wolski.pro/diagramy-uml/diagram-przypadkw-uzycia/
  2. OMG, (Data dostępu: 2020-11-11) Specyfikacja OMG Unified Modeling Language: https://www.omg.org/spec/UML/2.5/PDF/
  3. Żeliński J. (Data dostępu: 2020-11-11). it-consulting.pl. Definicja „Przypadek użycia”: https://it-consulting.pl/autoinstalator/wordpress/glossary/przypadek-uzycia/#.X6p1X2hKhaQ [Data dostępu 11.11.2020]
  4. seilevel (Data dostępu: 2020-11-11). seilevel.com Artykuł: „Best Practices with Use Cases”: https://seilevel.com/requirements/best-practices-with-use-cases [Data dostępu 11.11.2020]

Aby pobrać materiały

Dołącz do Newslettera

Co tam znajdziesz?

– Instrukcje Enterprise Architect

– Szablony dokumentacji

– Zadania z Enterprise Architect

– Przykładowe repozytoria