Zdanie, które brzmi jak gotowe wymaganie#
Rysowanie problemu pomaga zauważyć niewiadome, ponieważ wymaga nazwania rzeczy i połączenia ich konkretnymi zależnościami. W zdaniu „klient rezerwuje wizytę i otrzymuje potwierdzenie” łatwo pominąć moment zajęcia terminu, płatność czy anulowanie. Kiedy próbujemy pokazać przebieg, musimy zdecydować, gdzie te zdarzenia umieścić i co ma nastąpić po każdym z nich.
Nie chodzi o szczególną właściwość samych obrazów. Podobny efekt może dać dokładny opis scenariusza albo tabela reguł. Rysunek ułatwia jednak wskazanie konkretnej luki: jest stan początkowy i oczekiwany wynik, ale nie wiadomo, co je łączy w trudniejszej sytuacji.
Przyjrzyjmy się niewielkiemu systemowi rezerwacji wizyt. Wszystkie opisane poniżej zasady są założeniami przykładu. W prawdziwym projekcie wymagałyby ustalenia z osobami odpowiedzialnymi za usługę.
Co właściwie znaczy „zarezerwować”?#
Klient wybiera godzinę 16:00 i przechodzi do płatności. W tym samym momencie inna osoba otwiera kalendarz. Czy nadal widzi ten termin jako dostępny?
Słowo „rezerwacja” nie daje odpowiedzi. Dla jednej osoby oznacza już pewne miejsce w kalendarzu. Dla innej jest tylko rozpoczętą próbą zakupu. Jeszcze ktoś zakłada, że termin zostaje zajęty dopiero po wpłacie.
W naszym przykładzie zespół decyduje, że po skutecznym przydzieleniu terminu powstaje rezerwacja oczekująca na płatność. Przez określony czas termin jest niedostępny dla innych klientów. Rezerwacja może następnie zostać potwierdzona albo wygasnąć. Sama próba przydzielenia terminu może się nie udać, jeśli ktoś inny zdążył go wcześniej zająć.
Już samo nazwanie tych sytuacji ujawnia pierwsze zadanie: trzeba odróżnić wybranie godziny w interfejsie od skutecznego zajęcia terminu. Widok kalendarza mógł przecież zdezaktualizować się, zanim klient nacisnął przycisk.
Trzy stany i jedno brakujące rozstrzygnięcie#
Do dalszej rozmowy przyda się diagram maszyny stanów. Przedstawia on sytuacje, w których może znajdować się jeden obiekt, oraz zdarzenia powodujące zmianę. Tutaj tym obiektem jest rezerwacja, która już skutecznie zajęła termin.
Przyjmujemy roboczo, że klient ma dziesięć minut na opłacenie wizyty. To przykładowa decyzja produktu, a nie reguła UML ani ogólna rekomendacja. Model obejmuje czas od utworzenia rezerwacji do jej potwierdzenia lub wygaśnięcia.
Prostokąty oznaczają stany rezerwacji. Opis strzałki mówi, co wywołuje zmianę. Zapis w nawiasach kwadratowych jest warunkiem, który musi być spełniony, aby dane przejście mogło nastąpić. Przy wygaśnięciu po ukośniku dopisano efekt: zwolnienie terminu.
Stany „Potwierdzona” i „Wygasła” nie oznaczają usunięcia danych. Po prostu nie rozwijamy tutaj dalszych losów rezerwacji. Możliwość odwołania potwierdzonej wizyty należałaby do kolejnego fragmentu modelu.
Notatka obok stanu „Wygasła” jest zwykłą adnotacją o nierozstrzygniętej sprawie. Nie dodaje zachowania do systemu. Brak strzałki dla spóźnionej płatności nie stanowi w tym roboczym rysunku decyzji o jej zignorowaniu. Oznacza, że opis nie jest jeszcze kompletnym wymaganiem.
Przykład, który sprawdza nasz pomysł#
Przejdźmy przez sytuację krok po kroku. O 12:00 Anna zajmuje termin na 16:00. Rozpoczyna płatność, ale wiadomość z potwierdzeniem nie dociera od razu. O 12:10 rezerwacja wygasa, a termin wraca do kalendarza. O 12:11 rezerwuje go Bartek. O 12:12 system otrzymuje potwierdzenie wpłaty Anny.
Automatyczne przywrócenie rezerwacji Anny mogłoby oznaczać dwie wizyty o tej samej godzinie. Zignorowanie wiadomości pozostawiłoby wpłatę bez wyjaśnienia. Potrzebna jest więc jawna reguła obsługi takiej sytuacji. Możliwe kierunki obejmują zwrot wpłaty, zaproponowanie innej godziny albo przekazanie sprawy do wyjaśnienia. Wybór zależy od zasad usługi i możliwości rozliczeń.
Warto przy tym odróżnić moment wykonania płatności od momentu otrzymania wiadomości o niej. Anna mogła zapłacić przed 12:10, choć system dowiedział się o tym później. Warunek „przed wygaśnięciem” wymaga zatem doprecyzowania: według jakiego czasu i jakiego wiarygodnego źródła rozstrzygamy? Trzeba też ustalić przypadek dokładnie na granicy terminu.
Rysunek nie wybierze odpowiedzi. Sprawi za to, że trudno będzie przejść obok tego pytania bez zauważenia go.
Od pytania do ustalenia#
Po takiej rozmowie dobrze jest rozdzielić rzeczy już uzgodnione od propozycji. Krótki zapis może wyglądać następująco:
| Kwestia | Stan ustaleń w przykładzie | Następny krok |
|---|---|---|
| Czy oczekiwanie na płatność zajmuje termin? | Tak, uzgodniona reguła | Uwzględnić przy przydzielaniu terminów |
| Jak długo trwa oczekiwanie? | Dziesięć minut, wartość robocza | Potwierdzić z właścicielem usługi |
| Jak obsłużyć spóźnioną wpłatę? | Brak decyzji | Uzgodnić obsługę z osobą odpowiedzialną za rozliczenia |
| Który czas rozstrzyga o płatności? | Brak decyzji | Sprawdzić informacje od operatora i przyjąć regułę graniczną |
Takie zestawienie chroni przed potraktowaniem wszystkich elementów rysunku jako zatwierdzonych zasad. Pokazuje również, czego brakuje do zakończenia analizy. Jeśli ktoś nie ma prawa podjąć decyzji o rozliczeniach, nie powinien zastępować jej własnym domysłem tylko po to, by dorysować ostatnią strzałkę.
Co jeszcze warto sprawdzić#
Kiedy główny przebieg jest już zrozumiały, można przejść przez kilka trudniejszych przykładów. Dwie osoby próbują zająć ten sam termin. Operator przysyła potwierdzenie dwukrotnie. Klient wraca do płatności po wygaśnięciu rezerwacji. Wiadomość o wpłacie trafia do systemu w tej samej chwili co zdarzenie wygaśnięcia.
Nie trzeba umieszczać wszystkich tych sytuacji na jednym diagramie. Część łatwiej opisać osobnymi scenariuszami i oczekiwanymi wynikami. Zasada „jeden termin może mieć najwyżej jedną aktywną rezerwację” wymaga także odpowiedniego mechanizmu technicznego. Sam rysunek stanów nie zabezpiecza systemu przed równoczesnymi operacjami.
Pytania warto dobierać do ryzyka i celu rozmowy. Wstępne spotkanie o pomyśle na usługę nie wymaga rozpisania całego rozwiązania. Przed wdrożeniem obsługi płatności pozostawienie tych samych niewiadomych byłoby już poważną luką.
Rysunek, który wolno poprawiać#
Roboczy diagram powinien nadawać się do zmiany. Warto zacząć od kilku nazw i przejść, prześledzić zwykły przypadek, a potem spróbować znaleźć sytuację, której rysunek nie wyjaśnia. Gdy pojawi się sprzeczność, poprawiamy model lub wracamy do decyzji, na której go oparliśmy.
Widoczna luka bywa najcenniejszym wynikiem takiej pracy. Pozwala zamienić ogólne poczucie, że „trzeba to jeszcze przemyśleć”, w konkretne pytanie o spóźnioną płatność, dostępność terminu czy odpowiedzialność za decyzję. Z takim pytaniem można już pójść do właściwej osoby i doprowadzić ustalenia do końca.