User Stories vs. Use Cases

Te dwie konstrukcje służą do opisywania konkretnych interakcji między systemem a użytkownikiem. Pozwalają lepiej zrozumieć developerom i klientom funkcjonalności danej aplikacji. Zapisywane są w języku zrozumiałym dla obu stron. Na etapie tworzenia takiej wstępnej dokumentacji można odkryć pewne niedociągnięcia w pomyśle na aplikacje czy też różne sprzeczności, których można się pozbyć.

Tablica z karteczkami

Postaram się pokrótce opisać na czym polegają obie metody i czym się od siebie różnią.

W krótki i mam nadzieję zrozumiały sposób.

User Stories

Jest to dość prosta forma opisania interakcji między użytkownikiem a system. Jak niektórzy twierdzą bywa “zwodniczo prosta”. Opiera się na prostym schemacie:

Jako <osoba> chcę <potrzeba>, żeby <cel do osiągnięcia, problem do rozwiązania>.

Mówiąc ‘osoba‘ bierzemy pod uwagę daną rolę w systemie (Administrator / Moderator / Użytkownik), skonkretyzowaną grupę użytkowników czy też Personę. Jest to podstawowy schemat User Story. Przykład: Jako moderator forum chcę mieć możliwość zablokowania danego użytkownika, żeby utrzymać porządek.

Istnieje także bardziej złożony schemat na podstawie którego buduje się User Story. Z języka angielskiego jest to zasada Pięciu W, czyli w przekładzie na polski będą to pytania: kto, co, kiedy, gdzie, dlaczego. W tej sytuacji ogólny schemat wygląda następująco:

Jako <kto><kiedy><gdzie>, chcę <co>, ponieważ <dlaczego>. Warunki satysfakcji.

Jest to bardziej złożona forma, natomiast bardziej precyzyjna od poprzedniej.

Use Cases

Konstrukcja podobna do User Story, ale opisująca interakcje użytkownika z systemem w bardziej szczegółowy sposób. Można powiedzieć, że jest to prawie kompletna funkcjonalność, ale zapisana w języku interpersonalnym. Często przedstawiane są w postaci rozbudowanych diagramów. Oczywiście wybranie tej formy dokumentacji dla swojego projektu niesie ze sobą też pewne niedogodności. Tworzenie tak szczegółowych grafów i opisów zajmuje sporo czasu.

Przykładowy Use Case może się składać z następujących elementów:

Aktorów – tak jak w przypadku User Stories aktorem nazywamy rolę w systemie, bądź konkretnie opisanego użytkownika systemu. W konkretnym Use Case opisujemy aktorów, którzy będą brali udział w danym scenariuszu interakcji z systemem.

Wyzwalacz – konkretna akcja, która zostaje wywołana przez jednego z aktorów bądź inny warunek jaki musi zaistnieć w systemie.

Przewidywania – warunki jakie prawdopodobnie zostały spełnione już przed wywołaniem akcji. Możemy spodziewać się przykładowo, że jeżeli użytkownik chcę zapłacić za produkty w koszyku, to dodał wcześniej je do koszyka.

Przewidywania po zakończeniu scenariusza – jaki powinien być rezultat danego scenariusza. Co tak na prawdę chcemy osiągnąć?

Normalny przebieg – krok po kroku opisujemy wszystko to, co powinno się wydarzyć w systemie w danym scenariuszu. Tutaj musimy pamiętać o każdym szczególe jaki chcemy zaimplementować do systemu.

Przebieg alternatywny – opisuje co się stanie jeżeli w kroku x przebiegu normalnego wydarzy się coś, co odbiega od normy. W tym kroku musimy opisać w jaki sposób system będzie reagował na rożnego rodzaju błędy, tak aby zachować ciągłość pracy.

Po co ta dokumentacja?

Tak jak wspominałem we wstępie pisanie takiej dokumentacji ułatwia pełne zrozumienie implementowanych funkcjonalności jak i sposobu działania całego systemu. User Story jest ogólną informacją o interakcjach między użytkownikiem a systemem, podczas gdy Use Case jest bardziej szczegółowym opisem przebiegu scenariusza w naszym systemie.

User Stories czy Use Cases?

Decyzję można podjąć zadając sobie następujące pytanie: “Czy w przypadku tego projektu User Stories pozostawiają jakieś dwuznaczności?”. Jeżeli nikt nie ma wątpliwości co do jednoznaczności User Stories można przy nich zostać. Natomiast kiedy budujemy bardziej zaawansowaną aplikację, gdzie sposobów zrozumienia i implementacji poszczególnych funkcjonalności jest mnóstwo, wtedy warto sięgnąć po Use Cases.

To tyle jeśli chodzi o krótkie wyjaśnienie różnic między tymi dwoma sposobami dokumentacji projektu.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *