Książka opisuje jedną metodę pisania części opisu problemu, a mianowicie metodę przypadków użycia.
Co to jest? Jest to opis scenariusza interakcji użytkownika z systemem (lub z firmą). System pełni w tym przypadku rolę czarnej skrzynki (a to pozwala podzielić złożone zadanie projektowe na zaprojektowanie interakcji i zapewnienie tej interakcji). Jednocześnie wprowadzane są standardy notacji, co zapewnia łatwość czytania, także osobom niebędącym uczestnikami, a także pozwala na pewną kontrolę pod kątem kompletności i zgodności z celami zainteresowanego.
Użyj przykładu przypadku
Jak wygląda scenariusz na przykładzie autoryzacji w serwisie poprzez e-mail:
(System) Zaloguj się do serwisu, aby uzyskać dostęp do swojego konta osobistego. ~~ (poziom morza)
Kontekst: Do serwisu loguje się nieupoważniony klient, dzięki czemu witryna go rozpoznaje i wyświetla mu dane osobowe: historię przeglądania, historię zakupów, aktualną liczbę punktów bonusowych itp., wykorzystując jako login adres e-mail.
Poziom: cel użytkownika
Główny bohater: klient (odwiedzający nasz sklep internetowy)
Zakres: Interakcja Klienta ze stroną sklepu internetowego
Interesariusze i interesy:
- marketerowi zależy na zidentyfikowaniu maksymalnej liczby osób odwiedzających witrynę, aby zwiększyć zasięg prywatnych mailingów,
- specjalista ds. bezpieczeństwa chce mieć pewność, że nie dojdzie do przypadków nieuprawnionego dostępu do danych osobowych osoby odwiedzającej, w tym prób odgadnięcia hasła do jednego konta lub poszukiwania konta ze słabym hasłem,
- atakujący chce uzyskać dostęp do bonusów ofiary,
- konkurencja chce wystawiać negatywne recenzje na temat produktów,
- Botnet chce przejąć bazę klientów sklepu i przeprowadzić atak tak, aby witryna przestała działać.
Warunki wstępne: odwiedzający nie musi być upoważniony.
Minimalne gwarancje: odwiedzający będzie wiedział, czy próba autoryzacji zakończyła się sukcesem, czy niepowodzeniem.
Gwarancje sukcesu: gość jest upoważniony.
Główny scenariusz:
- Klient inicjuje autoryzację.
- System potwierdza brak autoryzacji klienta i nie przekracza liczby nieudanych prób autoryzacji z danej sesji (wyszukiwanie słabego hasła dla wielu kont) zgodnie z „Zasadą Bezpieczeństwa nr 23”.
- System zwiększa licznik prób autoryzacji.
- System wyświetla klientowi formularz autoryzacji.
- Klient podaje swój adres e-mail i hasło.
- System potwierdza obecność w systemie klienta posiadającego taki adres e-mail oraz zgodność hasła i nieprzekroczenie liczby prób logowania na to konto zgodnie z „Zasadą Bezpieczeństwa nr 24”.
- System autoryzuje klienta, dodaje historię przeglądania i koszyk tej sesji do ostatniej sesji tego konta klienta.
- System wyświetla komunikat o powodzeniu autoryzacji i przechodzi do kroku skryptu, w którym klient został przerwany w celu autoryzacji. W takim przypadku dane na stronie zostaną przeładowane z uwzględnieniem danych konta osobistego.
Rozszerzenia:
2.a. Klient jest już autoryzowany:
2.a.1. System powiadamia klienta o fakcie wykonanej wcześniej autoryzacji i proponuje przerwanie skryptu lub przejście do kroku 4, a w przypadku pomyślnego zakończenia kroku 6, wówczas wykonywany jest krok 7 z wyjaśnieniem:
2.a.7. System deaktoryzuje klienta na starym koncie, autoryzuje klienta na nowym koncie, natomiast historia przeglądania i koszyk tej sesji interakcji pozostają na starym koncie i nie są przenoszone na nowe. Następnie przejdź do kroku 8.
2.b Liczba prób autoryzacji przekroczyła próg zgodnie z „Zasadą Bezpieczeństwa nr 23”:
2.b.1 Przejdź do kroku 4, na formularzu autoryzacji dodatkowo wyświetla się captcha
2.b.6 System potwierdza poprawność wpisu captcha
2.b.6.1 Captcha wpisana niepoprawnie:
2.b.6.1.1. system zwiększa również licznik nieudanych prób autoryzacji dla tego konta
2.b.6.1.2. system wyświetli komunikat o błędzie i powróci do kroku 2
6.a. Nie znaleziono konta z tym adresem e-mail:
6.a.1 System wyświetla komunikat o awarii i oferuje możliwość przejścia do kroku 2 lub przejścia do scenariusza „Rejestracja użytkownika” i zapisania wprowadzonego adresu e-mail,
6.b. Hasło do konta z tym adresem e-mail nie zgadza się z wprowadzonym:
6.b.1 System zwiększa licznik nieudanych prób logowania do tego konta.
6.b.2 System wyświetla komunikat o niepowodzeniu i oferuje możliwość przejścia do scenariusza „Odzyskiwanie hasła” lub przejścia do kroku 2.
6.c: Licznik prób logowania dla tego konta przekroczył próg określony w „Zasadzie bezpieczeństwa nr 24”.
6.c.1 System wyświetla komunikat o zablokowaniu logowania do konta na X minut i przechodzi do kroku 2.
Co jest świetne
Sprawdza kompletność i zgodność z celami, czyli możesz przekazać wymagania innemu analitykowi do weryfikacji, popełniając mniej błędów na etapie formułowania problemu.
Praca z systemem czarnej skrzynki pozwala oddzielić rozwój i koordynację z klientem tego, co zostanie zautomatyzowane, od metod wdrożenia.
Jest częścią ścieżki analityka, jedną z głównych części użyteczności. Scenariusz użytkownika określa główne ścieżki jego ruchu, co znacznie ogranicza swobodę wyboru projektanta i klienta oraz pomaga zwiększyć szybkość rozwoju projektu.
Bardzo podoba mi się miejsce w opisie, w którym wskazane są wyjątki od poszczególnych etapów interakcji. Kompletny system informatyczny musi umożliwiać obsługę wyjątków, niektóre ręcznie, inne automatycznie (jak w powyższym przykładzie).
Doświadczenie pokazuje, że nieprzemyślana obsługa wyjątków może łatwo zmienić system w strasznie niewygodny. Pamiętam historię, jak w czasach sowieckich, żeby otrzymać decyzję, trzeba było uzyskać kilka zgód z różnych służb i jak to boli, gdy ostatnia służba mówi – ale we wniosku jest napisane złe imię i nazwisko lub jakiś inny błąd w interpunkcję, przerób wszystko i skoordynuj wszystko na nowo.
Często spotykam się z sytuacjami, w których logika działania systemu, która nie została przemyślana pod kątem wyjątków, wymagała znacznych przeróbek systemu. Z tego powodu lwia część pracy analityka poświęcona jest obsłudze wyjątków.
Notacja tekstowa, w przeciwieństwie do diagramów, umożliwia identyfikację i uwzględnienie większej liczby wyjątków.
Dodatek do metody z praktyki
W odróżnieniu od historii użytkownika, przypadek użycia nie jest niezależnie uszeregowaną pod względem priorytetów częścią instrukcji.
W powyższym scenariuszu rozważ wyjątek „6.a. Nie znaleziono żadnego konta z tym adresem e-mail.” i kolejny krok „6.a.1 System wyświetla komunikat o awarii i przechodzi do kroku 2.” Jakie negatywne rzeczy pozostały za kulisami? Dla Klienta jakikolwiek zwrot jest równoznaczny z tym, że cała praca, jaką włożył w wprowadzanie danych, ląduje na śmietniku. (Po prostu nie jest to widoczne w skrypcie!) Co można zrobić? Przebuduj skrypt, aby tak się nie stało. Czy jest to możliwe? Możesz - jako przykład - spojrzeć na skrypt autoryzacyjny Google.
Optymalizacja scenariuszy
Książka mówi o formalizacji, ale niewiele mówi o metodach optymalizacji takich scenariuszy.
Możliwe jest jednak wzmocnienie tej metody poprzez optymalizację scenariuszy, a metoda formalizacji przypadków użycia pozwala na to. W szczególności należy pomyśleć o każdym wystąpieniu wyjątku, określić przyczynę i przebudować skrypt w taki sposób, aby pozbyć się wyjątku lub zminimalizować podróż klienta.
Składając zamówienie ze sklepu internetowego należy podać miasto dostawy. Może się okazać, że sklep nie może dostarczyć towaru do wybranego przez klienta miasta, ponieważ tam nie dostarcza, ze względu na ograniczenia gabarytowe lub z powodu braku towaru w odpowiednim magazynie.
Jeśli po prostu opiszemy scenariusz interakcji na etapie rejestracji, możemy napisać „poinformuj klienta, że dostawa jest niemożliwa i zaoferuj zmianę miasta lub zawartości koszyka” (na tym poprzestaje wielu początkujących analityków). Ale jeśli takich przypadków jest wiele, scenariusz można zoptymalizować.
Pierwszą rzeczą, którą musisz zrobić, to pozwolić Ci wybrać tylko miasto, w którym możemy dostarczyć. Kiedy to zrobić? Przed wyborem produktu na stronie internetowej (autodetekcja miasta poprzez IP z wyjaśnieniem).
Po drugie, musimy dać wybór tylko temu towarowi, który jesteśmy w stanie dostarczyć klientowi. Kiedy to zrobić? W momencie wyboru - na karcie produktu i karcie produktu.
Te dwie zmiany znacznie przyczyniają się do wyeliminowania tego wyjątku.
Wymagania dotyczące pomiarów i metryk
Rozważając zadanie minimalizacji obsługi wyjątków, możesz ustawić zadanie raportowania (przypadek użycia nie jest opisany). Ile było wyjątków, w jakich przypadkach wystąpiły oraz ile przychodzących scenariuszy przeszło pomyślnie.
Ale niestety. Doświadczenie pokazało, że wymogi raportowania dla scenariuszy w tej formie nie wystarczą; należy wziąć pod uwagę wymagania raportowania dla procesów, które są opisywane głównie nie w formie przypadku użycia.
Dostęp do użyteczności
W naszej praktyce formularz opisu przypadków użycia rozszerzyliśmy o opis konkretnych atrybutów podmiotów oraz dane umożliwiające klientowi podjęcie decyzji, co zwiększa późniejszą użyteczność.
Do projektowania użyteczności dodaliśmy sekcję wejściową - wyświetlanie danych.
W scenariuszu z autoryzacją jest to fakt, że klient jest autoryzowany w systemie. Jeżeli klient posiada preautoryzację, wyświetli się ostrzeżenie o przełączeniu historii nawigacji i koszyka na nowe konto po pomyślnej autoryzacji.
Generalnie jest to wyświetlenie niezbędnych informacji dla klienta, aby mógł podjąć decyzję o swoich dalszych działaniach zgodnie ze scenariuszem (można zapytać, czy te dane wystarczą klientowi, czego jeszcze potrzebuje, jakie informacje mu potrzebne) klient musi podjąć decyzję).
Warto także podzielić wprowadzane informacje na pola wejściowe, jeśli są one przetwarzane osobno i przy tworzeniu różnych wyjątków.
W przykładzie z autoryzacją klienta, jeśli rozdzielisz wprowadzone informacje na login i hasło, to warto zmienić skrypt autoryzacyjny, aby wyróżnić etapy wprowadzania osobnego loginu i osobnego hasła (i dzieje się to w Yandex, Google, ale czego nie robi się w większości sklepów internetowych).
Osiągnięcie wymaganych przekształceń danych
Ze skryptu można także wyodrębnić wymagania dotyczące algorytmów konwersji danych.
Przykłady:
- Aby podjąć decyzję o zakupie produktu w sklepie internetowym, klient musi znać na karcie produktu możliwość, koszt, czas dostawy tego produktu do swojego miasta (które wyliczane są przez algorytm na podstawie dostępności produktu w magazyny i parametry łańcucha dostaw).
- Podczas wpisywania frazy w wyszukiwarkę, klientowi wyświetlają się sugestie wyszukiwania według algorytmu (które są generowane przez algorytm...).
Razem
Generalnie po przeczytaniu książki niestety nie jest jasne jak przejść całą drogę od analityka przez problemy biznesowe do sformalizowanej specyfikacji technicznej dla programisty. Książka opisuje tylko część procesu, przy czym kroki wejściowe są niejasne, a kolejne kroki niejasne. Sam przypadek użycia najczęściej nie jest kompletnym stwierdzeniem dla programisty.
Niemniej jednak jest to bardzo dobry sposób na sformalizowanie i przetworzenie scenariuszy interakcji pomiędzy przedmiotem a podmiotem, gdy interakcja powoduje zmianę czegoś w podmiocie. Jest to jedna z niewielu metod pisania, która pozwala na weryfikowalne wymagania z jawnymi punktami wyszukiwania wyjątków.
Książka jest obowiązkową lekturą dla analityków, którzy chcą rozpocząć pisanie testowalnych sztuk.
Źródło: www.habr.com