Nasz proces
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”.
Przypadki użycia vs User Story
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 w przypadku testów akceptacyjnych zespoły zwinne skupiają się na opracowaniu user stories. 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?
Programiści nie implementują wymagań biznesowych, czy wymagań użytkowników. To co kodują to wymagania funkcjonalne i pozafunkcjonalne programu.
Nie mniej niemozliwe jest stworzenie wymagań funkcjonalnych bez poznania potrzeb użytkowników i wymagań biznesu.
Przypadki użycia opisują interakcję użytkownika oprogramowania z punktu widzenia użytkownika, tj. od strony widocznych zachowań systemu. Zaś wymagania funkcjonalne wynikają z wymagań przypadków użycia i opisują określone elementy zachowań systemu.
Prawidłowo sformułowane przypadki użycia są niezbędne do opracowania specyfikacji wymagań oprogramowania, która w efekcie zawiera zarówno wymagania funkcjonalne, jak i pozafunkcjonalne.
Co więcej, przypadki użycia dają wytyczne do projektowania interfejsu użytkownika. Ponadto każdy przypadek użycia jest pomocny przy testach akceptacyjnych.
Spis przypadków użycia pozwola wstępnie oszacować czas wdrożenia oprogramowania, gdyż ich opis pozwala zrozumieć 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 user story?
Zarówno przypadki użycia, jak i opowieści użytkownika są ważną częścią procesu projektowania każdego oprogramowania. Są niezbędne w aplikacjach webowych, aplikacjach mobilnych, czy usługach oferowanych w modelu subskrypcyjnych.
Pomogą przy tworzeniu stron internetowych. Wszędzie tam, gdzie oprogramowanie ma komus posłużyć, niezbędne jest dowiedzenie się, co program ma robić, aby spełniał on potrzeby użytkownika.
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
- Aktor to pewna rola w stosunku do systemu.
- Aktor nie zawsze oznacza konkretną osobę fizyczną — jedna osoba może logować się do systemu jako użytkownik, a innym razem jako administrator.
- Aktor może reprezentować całą grupę fizyczną użytkowników systemu.
- 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.
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.
W procesie prac nad designem produktu i przypadkami użycia musimy poznać dokładnie naszego użytkownika. W tym pomaga tworzenie person.
Pod pojęciem persony rozumiemy reprezentację użytkownika (klienta).
Daje to możliwość tworzenia produktu cyfrowego nie tylko dla swojej firmy, ale w odpowiedzi na potrzebę rynku, a co za tym idzie - pozyskiwania trafficu przez internet i stworzenie lejka sprzedażowego. Więcej o lejku sprzedażowym przeczytacie w naszym artykule.