User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊

Proszę napisać wymganie w formie user stories. 
Proszę zapisać wymaganie w formie przypadku użycia.
Czym są sytuacje wyjątkowe w opisie przypadków użycia ?

No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories, a czym Use Case.

User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2]

User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy)[3].

Ważne jest to, aby User Stories przedstawiały perspektywę Użytkownika i nie zawierała sugestii implementacyjnych czy pomysłu z rozwiązaniem. Nad poprawnością i sensem US czuwa reguła INVEST ( opiszę ją w kolejnym poście, ponieważ stanowi jedno z pytań z listy 99)

Wracając to pytania, szablon takiej historyjki może wyglądać następująco:

Jako <rola> chcę <czynność>, aby <cel>, np.: „Jako (rola) Sponsor chcę, (czynność) aby system informował o aktywności użytkownika na jego kontach na Facebooku po to (cel) , aby jego znajomi również stali się użytkownikami systemu”. 

I jeśli wydaje się Wam, że to może za mało, za krótko, to nie! nie myślcie tak, historyjka (ehh, jak to źle brzmi) jest właśnie po to, żeby zwięźle, prosto i krótko przedstawić wymaganie naszego interesariusza. 

Przypadki Użycia (Use Cases/UC) – a właściwie diagramy przypadków użycia pozwalają na:

• Przedstawienie funkcjonalności systemu wraz z jego otoczeniem,
• Zaprezentowanie w sposób graficzny a zarazem bardzo przejrzysty własności systemu z punktu widzenia użytkownika.

Przykład:  Zamodelowanie Domu Makerskiego [1]

Taki diagram pokazuje co Użytkownik może wykonać z poziomu Interfejsu Użytkownika, przedstawione są funkcjonalności i powiązania między nimi. Aktorzy prezentują konkretnych użytkowników z podziałem na role (Użytkownik/Pracownik DM).

Niestety sam diagram nie wystarczy 😉 Przypadki Użycia mają małą wadę, nie pokazują kolejnych kroków, jakie są wykonywane w ramach danej aktywności (ale nie takie jest ich zadanie). Dlatego, aby wymaganie w postaci UC było kompletne musi zostać opatrzone tabelą, z odpowiednim opisem:

Zbieranie wymagań w postaci przypadku użycia dla systemów informatycznych nie będzie miało zastosowania dla rozwiązań nieposiadających interfejsu użytkownika, lub dla wymagań niefunkcjonalnych/jakościowych.

Ostatnie pytanie dotyczyło przedstawienia sytuacji wyjątkowych, czym są w opisie przypadków użycia? 

Jak sama nazwa wskazuje są to wszystkie sytuacje, scenariusze, które pokazują odstępstwa od przebiegu głównego. W naszym przykładzie jest to przerwa związana z niedziałaniem systemu zewnętrznego do przetwarzania zleceń, ale mogą to być inne sytuacje wyjątkowe, wszystko zależy od kontekstu i wymagania, które opisujecie 😊

Źródła:

[1] UML 2.1 Ćwiczenia, Praca zbiorowa pod redakcją Stanisława Wryczy

[2] Oprogramowanie szyte na miarę, Michał Bartyzel

[3] Kurs Specjalistów Analizy- blog analiza IT

[4] https://designmodo.com/user-stories-ux/ - rysunek