chciałbym podzielić się kilkoma swoimi przemyśleniami na temat pisania use case'ów - przypadków użycia. Używam przypadków użycia już od około czterech lat i mimo pewnych sukcesów zawsze trudno było mi pisać kolejne kroki use case. Szczególnie dziwne jest to, że im dłużej pracuję jako analityk biznesowy tym trudniejsze staje się dla mnie pisanie use case'ów. Otóż niedawno odkryłem dlaczego i chciałbym się z Wami podzielić tym odkryciem. Problem jaki mam z przypadkami użycia wynika z ich istoty i treści jakie są w nich przekazywane.
Use case'y są powszechnie cenionym sposobem na modelowanie funkcjonalności oprogramowania polegającym na opisaniu prozą tego jakie interakcje zachodzą między użytkownikiem (aktorem) a systemem komputerowym i jak dzięki temu użytkownik osiąga swoje cele. Cel jaki ma użytkownik wchodząc w interakcje z komputerem jest tu najważniejszy: każdy krok czy to wykonywany przez użytkownika czy też przez system komputerowy powinien przybliżać nas do celu np.
Use case: Założyć blog
Cel: Stworzyć kanał komunikacyjny dla dzielenia się wiedzą na temat użyteczności, modelowania i analizy biznesowej.
Rola: Autor
Główny scenariusz:
- Autor nadaje nazwę bloga.
- System umożliwia wybór szablonu bloga.
- Autor zmienia wygląd wybranego szablonu.
- System umożliwia publikowanie treści na blogu.
- Autor dodaje wpis.
- Autor publikuje wpis.
- System umożliwia edycję oraz usuwanie opublikowanych wpisów.
Wiemy zatem, że warto doprowadzać use case'y do perfekcji. Niestety jest to bardzo trudne z powodu pewnego paradoksu jaki ma tu miejsce. Mianowicie zapisując każdy krok należy unikać wszelkich decyzji na temat końcowej implementacji oprogramowania. Nic na temat formatek, przycisków, klawiatury, myszki, nazw funkcji czy nazw procedur wykonywanych w programie. Żadnego pseudokodu, który utrudniałby zrozumienie sensu czy kontekstu. Przecież use case mają rozumieć użytkownicy a nie jedynie wtajemniczeni programiści. Odcinamy się zatem od implementacji zostawiając ją na później. Ale to już na pewno wiedzieliście skoro nadal czytacie ten artykuł. Więc gdzie jest paradoks...?
Otóż paradoks polega na tym, że w każdym kroku trzeba zdecydować czy wykonuje go użytkownik czy też system. Decydując kto ma wykonać kolejny krok – czy to aktor czy system decydujemy o finalnej implementacji i wchodzimy w subtelny obszar designu. Decydujemy o tym co będzie musiało zostać zaimplementowane w systemie oraz jakie informacje będą przekazywane przez użytkownika do systemu.
Tutaj tkwi mój problem w tworzeniu use case'ów. W use case'ach decydujemy o tym jakie są zamiary czy też intencje użytkownika i jaka jest odpowiedzialność po stronie systemu. Na tym etapie musimy dokładnie rozumieć cel, do którego dąży użytkownik. Musimy wiedzieć jakie informacje będzie posiadał użytkownik i czego będzie oczekiwał od systemu. Pisząc każdy krok trzeba postawić sobie pytanie czy wykonuje go użytkownik czy też system? Jak dużo pracy w realizacji danego zadania ma mieć użytkownik a jak dużo system? Co spychamy na użytkownika? Jak wiele elastyczności i kontroli ma być po stronie użytkownika?
Czy system może pobrać skądś potrzebne dane czy będzie wymagał tego od użytkownika? Czy lepiej napisać, że system coś ma umożliwić, czy też że aktor coś wykonać? Co napisać w scenariuszu głównym a co w scenariuszach alternatywnych? Czy w przypadku użycia chronione są interesy wszystkich interesariuszy?
Widać, że pojawia się wiele pytań odnoszących się do implementacji czyli tego czego w przypadkach użycia należy unikać. Nie chodzi o samo słownictwo lecz o to co wchodzi w implementacje a co nie. Nie byłoby w tym nic złego gdyby nie to, że musimy odpowiedzieć sobie na zbyt wiele pytań na raz. Napisanie use case'a nawet dla doświadczonej osoby z dobrze opanowanym warsztatem jest trudne i wymaga wiele wysiłku. Zadanie napisania use case'a jest bardzo skomplikowane. Niby parę linijek tekstu ale... Więc co zrobić by te parę linijek było prościej napisać....?
Najlepiej byłoby podzielić ten długi przeskok od oczekiwań użytkowników do sposobu ich implementacji na jakieś pod zadania, etapy, mniej złożone modelowanie. Otóż odpowiedzią na problemy z use case'ami są tzw. task'i (ładniej byłoby napisać zadania). Pisząc task'i również opisujemy kolejne etapy – kroki dążenia do celu jednak nie decydujemy o tym co robi użytkownik a co system. Koncentrujemy się na tym jaki jest cel danego zadania i co jest najrozsądniej zrobić by ten cel osiągnąć np.
Przykład 2.
Task: Założyć blog
Cel: Stworzyć kanał komunikacyjny dla dzielenia się wiedzą na temat użyteczności, modelowania i analizy biznesowej.
Główny scenariusz:
- Nadać nazwę bloga.
- Wybrać szablon
- Edytować szablon.
- Rozpocząć publikowanie treści na blogu
- Dodawać wpisy
- Publikować wpisy.
- Edytować i usuwać istniejące wpisy.
"Task & Support. Task Descriptions as Functional Requirements – Soren Lauesen"
Przekazałem Wam tym wpisem najważniejszą moim zdaniem myśl na temat use case'ów. Piszcie proszę co Was interesuje i z jakimi Wy borykacie się problemami. Czy chcielibyście zobaczyć więcej przykładów use case'ów? Obiecuję unikać tworzenia kolejnego opisu działania bankomatu... ;P
Łukasz