Przejdź do głównej zawartości

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

Komentarze

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego.
Przejdź do pytań
Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.  
Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych.
No to lecimy :) pytanie na dziś to 
Jak Pani przeprowadza analizę?
Pierwsze co mi się nasunęło na myśl: „To zależy” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy.
Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- Jak właściwie zabrać się za analizę i…

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy!
Takie podobno cieszą się największym zainteresowaniem 😊
Jakie Pani zna rodzaje diagramów UML ?
No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.

 Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.  
Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu niepotrzebne struktury i di…