Jedno z najważniejszych pytań, jakie powinniśmy sobie zadać przed wdrożeniem softwaru, brzmi: „Co z naszym oprogramowaniem zrobią użytkownicy?”.
By uzyskać na nie odpowiedź, z pomocą przychodzą rozwiązania zorientowane na użytkownika i użytkowanie.
Dzięki nim wdrożymy kluczowe funkcje i uchronimy się przed dodaniem takich, z których użytkownicy i tak by później nie skorzystali.
Wymagania użytkownika znajdują się między wymaganiami biznesowymi, czyli celem projektu, a wymaganiami funkcjonalnymi – tym wszystkim, co powinni wykorzystać programiści.
Schody zaczynają się już na poziomie wyboru metody, która pozwoli określić intencje użytkowników. Najlepiej, gdy zdecydujemy się na dwie najpopularniejsze techniki – przypadki użycia i opowieści / historie użytkownika. Obie strategie pozwalają zrozumieć wymagania odbiorcy w wielu typach projektów i robią to o wiele lepiej niż pozostałe rozwiązania.
Czym jest przypadek użycia i opowieść użytkownika?
Przejdźmy teraz do samych definicji. Przypadek użycia (z ang. use case) to opis sekwencji interakcji, które zachodzą między systemem a personą. Chodzi o to, by persona osiągnęła wyznaczony cel, np. zmieniła dane profilowe w sklepie internetowym.
Zobrazujmy to jeszcze dokładniej poprzez zastosowanie prostego zapisu przypadku użycia:
„Księgarnia internetowa – zaktualizuj profil klienta”.
Tymczasem opowieść użytkownika jest to „krótki i prosty opis funkcjonalności, opowiedziany z perspektywy osoby, zazwyczaj użytkownika albo klienta systemu, której funkcjonalność ta jest potrzebna” (Cohn, 2010). Przykładowy schemat opowieści użytkownika wygląda następująco:
„Jako <rodzaj użytkownika> chcę <jakiś cel>, dzięki czemu <jakiś powód>”.
Widzimy więc, że historia użytkownika, w przeciwieństwie do przypadku użytkownika, wskazuje jego typ, a także przesłanki, które stoją za tym, że chce skorzystać z danej opcji.
Mamy tym samym przed oczami szczegółowy opis. Przykładowo: „Jako klient chcę zaktualizować mój profil, dzięki czemu za przyszłe zakupy będę mógł płacić nową kartą kredytową”.
Pamiętajmy, że procesy przypadku i opowieści użytkownika zmierzają w innych kierunkach. Praca nad przypadkiem użycia oznacza, że analityk biznesowy podejmie współpracę z przedstawicielami użytkowników.
Przekona się więc, jak wyobrażają sobie oni dialog z systemem, którego zadaniem jest zrealizowanie konkretnego celu.
Dzięki zebranym informacjom nada strukturę, która będzie zgodna z szablonem użycia. Opierając się na przypadku użycia stwierdzi, jakie wymagania funkcjonalne powinni wziąć pod uwagę programiści. Tester sprawdzi z kolei, czy określony przypadek został prawidłowo wdrożony.
Jednakże przypadek użycia nie powinien określać szczegółów dotyczących projektu – jego zadaniem jest skupienie się na wyobrażeniach użytkownika. Przypadki użycia pokazują uczestnikom projektu strukturę i kontekst, których brak w zbiorze opowieści użytkowników.
W wypadku opowieści użytkownika zespoły zwinne skupiają się zwykle na opracowaniu testów akceptacyjnych. Za ich sprawą dowiadujemy się, na ile udało się nam sprostać wymaganiom, które postawił przed nami użytkownik.
Siła tej metody bierze się stąd, że skupia się ona na testach już na wczesnym etapie prac – owocuje to bardzo dobrymi efektami, i to niezależnie od przyjętej metodyki.
No dobrze, ale co w sytuacji, gdy opowieści użytkowników są zbyt duże, żeby zostały zaimplementowane podczas jednej iteracji? Konieczne jest wówczas ich podzielenie na mniejsze historie, które można wdrożyć w ramach pojedynczej iteracji.
Przypadki użycia i opowieści użytkownika – cechy wspólne
Skupmy się teraz na cechach wspólnych obu metod. Przede wszystkim, przypadki użycia i opowieści użytkowników koncentrują się na tym, co chcą osiągnąć użytkownicy – ale nie na tym, co według nich powinien zrobić system.
Naszym zadaniem – zarówno w wypadku przypadków użycia, jak i opowieści użytkownika – będzie opisanie zadań, które użytkownicy będą musieli wykonać w systemie albo zidentyfikowanie interakcji na linii użytkownik-system.
Analityk biznesowy dowie się, jakie funkcje są niezbędne. Dochodzą do tego jeszcze testy weryfikujące, które ocenią, czy dana opcja została poprawnie wdrożona.
Gdzie sprawdzą się obie metody, a gdzie nie?
Przypadki użycia i opowieści użytkownika sprawdzą się w:
- pozyskiwaniu wymagań dla aplikacji biznesowych;
- witrynach internetowych;
- samoobsługowych kioskach;
- systemach, które pozwalają użytkownikom na kontrolowanie urządzeń.
Sprawdź również nasze wpisy poświęcone temu, jak wybrać dobry software house cz.1 i cz.2
Fotografia tytułowa: Giphy.com
Chcesz wiedzieć, ile kosztuje aplikacja?
