Nasze podejście

Przypadki użycia

Wdrażanie oprogramowania jest wyzwaniem nie tylko ze względu na trudności techniczne. Aby oprogramowanie miało jakikolwiek sens, ważne, by było dostosowane do potrzeb użytkowników. Kluczowe okazuje się wówczas pytanie: „Co z naszym oprogramowaniem zrobią użytkownicy?”. Z pomocą w udzieleniu odpowiedzi przychodzą rozwiązania zorientowane na użytkownika i użytkowanie. Pozwolą nam one wdrożyć kluczowe funkcje, a także uchronić się przed dodaniem funkcjonalności, którymi użytkownicy ostatecznie nie będą zainteresowani.

Pamiętajmy, że wymagania użytkownika nie odnoszą się wyłącznie do aspektu funkcjonalnego – związane są także z wymaganiami biznesowymi. Osoba, która nie ma doświadczenia w cyfrowym biznesie, staje przed trudnym pytaniem, w jaki sposób poznać intencje użytkowników. Jedną z najpopularniejszych technik, która na to pozwala, są przypadki użycia. Dzięki nim zrozumiemy wymagania, które stawia użytkownik – i to w wielu typach projektów.

Przypadek użycia jako opis sekwencji interakcji

Przypadki użycia (use case) są opisami sekwencji interakcji, jakie zachodzą między systemem a aktorem, gdzie ważne jest, by aktor osiągnął wyznaczony cel, jak np. zmienił dane profilowe w sklepie internetowym.

Zobrazujmy to na prostym przykładzie. Wyobraźmy sobie, że wchodzimy na stronę księgarni internetowej, ale okazuje się, że nasze dane profilowe nie są już aktualne, bo zmieniliśmy adres zamieszkania. Przypadkiem użycia będzie więc zmiana danych profilowych.

Use case – przykład

Przypadek użycia będzie wyglądał następująco:

„Księgarnia – zaktualizuj profil klienta”.

Use case, czyli przypadek użycia, bywa często mylony z opowieściami (historyjkami/historiami) użytkownika. Różnica jest tymczasem prosta: opowieści użytkownika wykraczają poza wskazanie celu, do którego zmierza użytkownik. Opisują bowiem także motywacje, które stoją za celem.

Dla przykładu:

„Jako klient chcę zaktualizować mój profil, dzięki czemu przyszłe zakupy będą przychodzić pod mój nowy adres zamieszkania”.

Gdy mamy do czynienia z przypadkami użycia, analityk biznesowy podejmuje współpracę z użytkownikami. Jest wówczas w stanie przekonać się, jak wyobrażają sobie oni dialog z systemem, którego zadanie to realizacja konkretnego celu. Zebrane dane pozwalają nadać konkretną strukturę, która będzie zgodna z szablonem użycia. Przypadek użycia pozwoli stwierdzić, jakie wymagania funkcjonalne powinni wziąć pod uwagę programiści. Zadaniem testera będzie natomiast sprawdzenie, czy określony przypadek został prawidłowo wdrożony. Pamiętajmy jednak, że przypadek użycia nie powinien określać szczegółów dotyczących projektu, gdyż jego celem jest skupienie się na wyobrażeniach użytkownika. Dzięki przypadkom użycia pokażemy uczestnikom projektu strukturę i kontekst.

Z kolei user stories zespoły zwinne skupiają się na opracowaniu testów akceptacyjnych. Takie testy pozwalają dowiedzieć się, na ile udało się sprostać wymaganiom, które postawił przed nami użytkownik. Dużym plusem takich testów jest to, że odbywają się one już na wczesnym etapie prac.

Lecz gdy mowa o cechach wspólnych przypadków użycia i opowieści użytkownika, warto przede wszystkim zwrócić uwagę, że use cases i opowieści użytkowników skupiają się na tym, co chce osiągnąć użytkownik, a nie na tym, co według ich wyobrażenia powinien zrobić system. Jeśli chodzi o obie metody, naszym zadaniem jest opisanie zadań, które użytkownicy będą musieli wykonać w systemie (albo zidentyfikowanie interakcji na linii użytkownik-system).

W czym pomocne są przypadki użycia?

Przypadki użycia pozwolą nam na specyfikację wymagań funkcjonalnych, tj. opisanie tego, co ma zrobić system. Kolejnym elementem jest walidacja wymagań, która pozwoli sprawdzić, czy wymagania prowadzą do osiągnięcia postawionych przed projektem celów.

Dla lepszego zrozumienia projektu stosuje się zaś diagramy interakcji, które pozwalają zaplanować konkretne działanie systemu. Co więcej, wiedząc, jakie funkcje powinny zostać zaimplementowane, zyskujemy punkt odniesienia dla projektu interfejsu użytkownika. Każdy przypadek użycia okazuje się ponadto pomocny w wypadku testów akceptacyjnych. Zastosowanie przypadków użycia pozwoli nam także oszacować czas, który zabierze projekt, bo zyskamy wgląd w złożoność systemu.

Prace nad przypadkami użycia

Wyżej wspomnieliśmy o diagramach przypadków użycia. Warto przyjrzeć im się dokładniej, gdyż pozwalają one na prezentację funkcjonalności systemu wraz z jego otoczeniem. Diagram pozwala na graficzne zaprezentowanie własności systemu z uwzględnieniem tego, jakie funkcjonalności są widziane po stronie użytkownika. Pozwala to na przedstawienie usług, które są widoczne na zewnątrz systemu.

Diagram składa się z wymagań funkcjonalnych i otoczenia, w którym znajduje się system. Diagram to swego rodzaju agregat funkcji usług, które wykonuje system. Poza prezentacją specyfikacji pozwala także zidentyfikować funkcjonalności oraz weryfikować postępy w modelowaniu i implementacji. Dodajmy, że jego zaletą jest także to, że wspomaga komunikację między uczestnikami projektu.

Diagram pozwala na określenie wymagań stawianych systemowi, a więc to, co system ma robić z punktu widzenia jego otoczenia. Zapewnia również określenie granic systemu, tj. otoczenia i elementów, które wchodzą z nim w interakcję.

Podstawowe zastosowania diagramu to, po pierwsze, określanie i doprecyzowanie funkcji systemu — przypadki użycia wymuszają zwykle nowe wymagania. Po drugie, komunikacja z klientami — prostota nazw i intuicyjność powodują, że diagramy przypadków użycia są dobrym sposobem porozumiewania się projektantów z przyszłymi użytkownikami systemu. Dochodzi do tego jeszcze generowanie przypadków testowych — opis danego przypadku użycia może zasugerować sposoby testowania, a także konkretne dane testowe i lepsze zrozumienie różnych scenariuszy wykorzystania systemu. Dzięki diagramom zapewniamy sobie lepsze porozumiewanie się projektantów systemu oraz jego przyszłych użytkowników.

Kiedy sprawdzą się zarówno przypadki użycia, jak i opowieści użytkownika?

  1. W wypadku pozyskiwania wymagań dla aplikacji biznesowych.
  2. Podczas tworzenia witryn internetowych.
  3. W pracach nad samoobsługowymi kioskami.
  4. W pracach nad systemami, które pozwalają użytkownikom na kontrolowanie urządzeń.

Aktor w przypadkach użycia jest ważny

Gdy mowa o przypadku użycia, często przewijającym się pojęciem jest tzw. aktor. Chodzi o rolę, którą pełni użytkownik w stosunku do systemu, jak i przypadków użycia. Wiąże się to z tym, że każdy użytkownik realizuje pewien scenariusz użycia. Przypadek użycia to zbiór powiązanych ze sobą scenariuszy użycia, a scenariusz to określona realizacja przypadku użycia.

Aktora należy pojmować także jako zbiór ról odgrywanych przez użytkowników. Owe role odgrywane są przez użytkowników przypadku użycia podczas interakcji z tym przypadkiem. Kluczowe jest to, by aktor pełnił określoną funkcję wobec systemu i przypadku użycia, którego używa. Co ważne, aktor nie jest częścią systemu, tylko znajduje się niejako „na zewnątrz” i musi być w interakcji chociaż z jednym przypadkiem użycia.

Aktor i system w przypadkach użycia

  1. Aktor to pewna rola w stosunku do systemu.
  2. Aktor nie zawsze oznacza konkretną osobę fizyczną — jedna osoba może logować się do systemu jako użytkownik, a innym razem jako administrator.
  3. Aktor może reprezentować całą grupę fizyczną użytkowników systemu.
  4. Aktorzy nie zawsze są aktywni — przykład to aktor, który zatwierdza przelew bankowy.

Jak pisać przypadki użycia?

Należy uważać z pisaniem zbyt wielu przypadków użycia. Lepiej nie pisać odrębnego przypadku użycia dla każdego możliwego scenariusza. Minimalizm jest także ważny, gdy opisujemy przypadek użycia — w grę nie wchodzi kilkustronicowy opis. Przepływ nie powinien liczyć więcej niż 10 lub 15 kroków.

Prosty przykład: powinniśmy pisać „System umożliwia dokonanie wyboru” zamiast „System wyświetla listę rozwijaną”. Chodzi więc o to, że przypadki użycia powinny skupiać się na tym, co chcą osiągnąć użytkownicy, a nie na wyglądzie ekranów. Unikajmy także zamieszczania definicji danych w przypadkach użycia. Ostatnia wskazówka, o której warto pamiętać, dotyczy przypadków użycia, których nie rozumieją użytkownicy. Ważne jest pisanie przypadków użycia z perspektywy użytkownika, nie zaś z punktu widzenia systemu. Przypadki użycia powinny być tak proste jak to tylko możliwe, dlatego możemy poprosić użytkowników, by je ocenili.

Przypadek użycia — historia i podsumowanie

Przypadkiem użycia (use case) nazwiemy sekwencje operacji wykonywanych przez system. Ich inicjatorem jest aktor, który jest pewną abstrakcją — użytkownikiem, któremu w danym momencie zostaje przypisana konkretna rola. Use case z jednej strony modeluje oczekiwane zachowanie systemu wobec aktora, ale z drugiej nie precyzuje sposobu realizacji tego zachowania. Za przypadkiem użycia idzie cel, a sam przypadek użycia opisuje zazwyczaj dłuższy proces. Dodajmy, że nazwa przypadku użycia zazwyczaj zawiera rzeczownik, określając cel uaktywnienia przypadku, który jest poprzedzony czasownikiem opisującym rodzaj aktywności.

W wypadku prac nad przypadkiem użycia definiujemy jego dokumentację. Pomocne są rysunki lub makieta interfejsu użytkownika, która pozwala na łatwiejsze stworzenie opisu danego przypadku. Możemy też zaproponować wspomniany już diagram czynności (nazywany czasem diagramem aktywności), który w języku UML służy do modelowania czynności i zakresu odpowiedzialności elementów lub użytkowników systemu. UML (Unified Modeling Language – zunifikowany język modelowania) to pół-formalny język wykorzystywany do modelowania różnego rodzaju systemów. Jego autorami są Grady Boocha, Jamesa Rumbaugha i Ivara Jacobson, obecnie zaś rozwija go Object Management Group.

Warto w tym miejscu wspomnieć o początkach przypadków użycia, które przypadają na 1986 rok. To właśnie wtedy Ivar Jacobson, informatyk zaangażowany w tworzenie Unified Modeling Language (UML) oraz Rational Unified Process (RUP), opisał technikę do specyfikowania przypadków użycia. Choć pamiętajmy, że początkowo używał on określeń scenariusz użytkowania (usage scenarios) i przypadki użytkowania (usage case). Już w latach 90. przypadki użycia stały się powszechnie stosowanym sposobem opisu wymagań funkcjonalnych.

Widzimy więc, że przypadki użycia (podobnie zresztą jak opowieści użytkowników — user stories) są podstawą wdrażania oprogramowania, które odpowie na potrzeby użytkowników. Zastosowanie przypadków użycia pozwala nas uchronić przed stworzeniem software'u, które wcale nie spełni oczekiwań użytkowników — nie mając odpowiedniej wiedzy, bardzo łatwo przeoczyć zaimplementowanie najważniejszych funkcji, a także dodać zbędne funkcjonalności. Poza tym za sprawą przypadków użycia spełnimy wymagania biznesowe.

Aby nasze oprogramowanie odniosło sukces na rynku, musimy najpierw dokładnie poznać naszego użytkownika, odpowiedzieć na jego potrzeby, a następnie je zaspokoić. Praca nad przypadkami użycia jest jednym z elementów, które są niezbędne do osiągnięcia wymarzonego rezultatu. Innymi elementami, o których warto pamiętać, są wspomniane już user stories czy tworzenie person.

Pod pojęciem persony rozumiemy reprezentację użytkownika/klienta. Tworzenie persony polega na łączeniu ludzi zainteresowanych naszymi usługami. Konieczne jest wówczas wzięcie pod uwagę podobieństw demograficznych i mentalnych. Dzięki segmentacji ujawniają się także pewne nawyki i upodobania użytkowników/klientów. Możemy ponadto zrozumieć, jak inni widzą i oceniają nasz produkt (o ile ten pojawił się już na rynku). Idzie za tym możliwość stworzenia lejka sprzedażowego, czyli ścieżki, którą pokonuje klient od momentu poznania produktu do jego zakupu. Proces ten jest stosunkowo łatwy do przeprowadzenia, ponieważ nie brak w internecie wielu, często darmowych narzędzi, które pozwalają nam zrozumieć, jacy są nasi odbiorcy. Więcej o lejku sprzedażowym przeczytacie w naszym artykule.

Ustal z nami szczegóły
Wykorzystujemy pliki cookies. Szczegóły znajdziesz w Polityce Cookies. Akceptuję