Wypłata pieniędzy z bankomatu przy użyciu karty płatniczej (przykład na poziomie biznesowego przypadku użycia)
Aktor główny: klient banku XYZ.
Opis: Klient banku chce dokonać wypłaty środków przy zastosowaniu osobistej karty płatniczej wydanej przez bank. Scenariusz obejmuje wypłatę środków bez możliwości użycia innych funkcji bankomatu.
Poziom: Cel użytkownika.
Uczestnicy i interesy:
Klient – wypłata pieniądzy w szybki sposób w dowolnym momencie.
Bank XYZ – ograniczenie kosztów związanych z obsługą klientów w filii banku.
Warunek początkowy: Użytkownik posiada rachunek bankowy, środki na koncie oraz kartę płatniczą.
Minimalna gwarancja: Klient otrzymuje informację o trybie serwisowym bankomatu.
Gwarancja powodzenia: Klient wypłaca wybraną przez siebie kwotę z bankomatu, a jego konto zostaje obciążone tą samą kwotę. Następuje rejestracja transakcji.
Główny scenariusz powodzenia:
1. Klient wsuwa kartę płatniczą do czytnika.
2. Bankomat odczytuje identyfikator banku oraz numer konta i kontaktując się z głównym komputerem, stwierdza ich poprawność.
3. Klient wpisuje PIN.
4. Bankomat stwierdza jego poprawność.
5. Klient wybiera przycisk „wypłata” i podaje kwotę będącą wielokrotnością 50 zł.
6. Bankomat informuje główny system bankowy o koncie klienta i pobranej przez niego kwocie, a następnie otrzymuje akceptację i nowe saldo.
7. Bankomat wydaje gotówkę, kartę i potwierdzenie z nowym saldem.
8. Bank odnotowuje transakcję w dzienniku.
Rozszerzenia:
2a. Klient posiada kartę, której bankomat nie obsługuje.
2a1. Bankomat podaję informację o zidentyfikowanym problemie, a następnie odrzuca transakcję.
2b. Karta klienta jest uszkodzona.
2b1. Bankomat podaje informacje o zidentyfikowanym problemie, a następnie odrzuca transakcję.
3a. Bankomat stwierdza niepoprawność numeru PIN.
3a1. Klient ponownie wpisuje numer PIN.
3a2. Klient rezygnuje z przypadku użycia.
5a. Klient nie posiada wybranej kwoty na koncie.
5a1. Klient zmienia kwotę wypłaty.
5a2. Klient rezygnuje z przypadku użycia.
5b. Wybrana kwota przewyższa dzienny limit wypłaty z konta.
5b1. Klient zmienia kwotę wypłaty.
5b2. Klient rezygnuje z przypadku użycia.
5c. Bankomat nie ma środków, aby wypłacić żądaną kwotę.
5c1. Klient zmienia kwotę wypłaty.
5c2. Klient rezygnuje z przypadku użycia.
Przykładowo, jeżeli scenariusz główny byłby:
Użytkownik loguje się do systemu.
Użytkownik otwiera formularz dodawania nowej firmy.
System prezentuje pusty formularz.
Użytkownik wprowadza NIP oraz nazwę firmy.
Użytkownik wybiera opcję zapisu danych w bazie.
System potwierdza zgodność danych i zapisuje nowy rekord.
To scenariusz alternatywny wyglądałby następująco:
4.a.
Użytkownik wybiera opcje importu dodatkowych danych na podstawie
numeru NIP
4.a.1 System pobiera ogólnodostępne dane firmy,
takie jak adres, czy dane kontaktowe
4.a.2 System wyświetla
informację o statusie operacji (zakończona sukcesem czy nie).
4.a.3
Użytkownik kontynuuje scenariusz zgodnie z opisem z kroku 5.
6.a.
System wykrywa niepoprawny format numeru NIP.
6.a.1 System
wyświetla komunikat wskazujący na konkretną przyczynę
błedu.
6.a.2 Użytkownik potwierdza komunikat (zamyka)
6.a.3
Użytkownik koryguje dane i kontynuuje scenariusz zgodnie z opisem z
kroku 5.
Przypadki użycia to usługi systemu (aplikacji) świadczone aktorowi (użytkownikowi systemu).
Przypadek Użycia to usługa Systemu jaką świadczy on jego Aktorowi. Aktorem Systemu nazywamy osobę korzystającą z oprogramowania w celu realizacji określonych zadań. Aktor systemu to odpowiednik Roli w modelu procesu biznesowego. Przypadek użycia oprogramowania to sytuacja, gdy oprogramowanie wspiera Aktora w realizacji konkretnej czynności w procesie biznesowym. Na diagramach Przypadków użycia, wykonanych w notacji UML, aktorem może być także inny zewnętrzny system, inicjujący interakcję z oprogramowaniem projektowanym.
Przypadki użycia Systemu traktują System jako tak zwaną „czarną skrzynkę”, opisują to co system ma robić, nie opisują tego jak system ma te usługi realizować. Opis realizacji to etap projektowania systemu.
Przypadki użycia, usługi aplikacji są wywodzone (śladowane) wprost z modelu procesów biznesowych jako wymagane usługi aplikacyjne. Każdy przypadek użycia systemu powinien odpowiadać konkretnej aktywności z modelu procesów biznesowych. Możliwa jest sytuacja, gdy jeden przypadek użycia (usługa systemu) wspiera kilka różnych czynności np. usługa zarządzania rejestrem kontrahentów pozwala na wykonanie czynności dodania, usunięcia czy modyfikacji danych kontrahenta, jednak niewłaściwa jest sytuacja, w której jedna czynność wymagałaby od użytkownika użycia kilku różnych usług systemu, gdyż zakłada się, że czynności w procesach na wymaganym do analizy poziomie szczegółowości, to czynności „atomowe” podobnie jak usługi oprogramowania.
W projektach dedykowanych, jednoznaczność opisu danego przypadku użycia nie może budzić wątpliwości, dlatego, poza diagramem przypadków użycia, powinien powstać scenariusz wykonania każdego z nich (dialog aktor – system).
“Użytkownik wyszukuje fakturę zgodnie z opisem w ‘UC-Wyszukaj fakturę’”
http://arturgula.aretech.pl/2016/06/05/10-wskazowek-jak-skutecznie-pisac-przypadki-uzycia/
https://www.michalwolski.pl/2015/05/dokumentacja-wymagan-w-oparciu-o-przypadki-uzycia/
https://it-consulting.pl/autoinstalator/wordpress/wp-content/uploads/2018/05/word-image-9.png
http://www.math.uni.lodz.pl/~robpleb/uml_cwiczenia/cwiczenia1.pdf
https://msdn.microsoft.com/pl-pl/library/dd409432.aspx
http://edu.pjwstk.edu.pl/wyklady/pri/scb/index18.html
https://it-consulting.pl/autoinstalator/wordpress/2017/06/04/ile-przypadkow-uzycia/
