Przykładem zależności wymagającej precyzyjnej walidacji są wnioski dotyczące zdarzeń godzinowych.

Pracownik korzysta z opieki nad dzieckiem od 9:00 do 11:00, a później odpracowuje wcześniejsze wyjście prywatne między 15:00 a 17:00.

Oba zdarzenia dotyczą tego samego dnia. Nie oznacza to jednak, że ze sobą kolidują.

Jeżeli system analizuje wyłącznie datę, drugi wniosek może zostać zablokowany. Jeżeli bierze pod uwagę rzeczywiste przedziały czasu, może prawidłowo rozpoznać, że oba zdarzenia mogą funkcjonować obok siebie.

Nie chodziło więc o dodanie wyjątku dla jednego formularza. Potrzebna była bardziej uniwersalna zasada: tam, gdzie proces jest godzinowy, sama zgodność dat nie wystarcza do stwierdzenia konfliktu.

Takie podejście można później zastosować również w kolejnych scenariuszach.

Rozróżnienie wspólnej daty i rzeczywistego nakładania się godzin było jednym z przykładów tego, jak precyzyjna reguła może zastąpić doraźne ograniczenia formularza. W innych procesach równie istotne okazywało się ustalenie, jaki czas faktycznie został przepracowany.

Wyjścia prywatne – ewidencja faktycznego przebiegu dnia

W przypadku wyjść prywatnych istotne jest nie tylko ustalenie przedziału nieobecności, lecz także prawidłowe odtworzenie pozostałego czasu pracy.

Pracownik rozpoczyna pracę o 8:00. O 12:00 wychodzi na dwie godziny, a następnie wraca i kontynuuje pracę.

Samo zarejestrowanie wyjścia nie wystarcza. System musi znać także rzeczywistą godzinę rozpoczęcia pracy. W przeciwnym razie może oprzeć się na harmonogramie i zbudować błędny obraz dnia.

A to wpływa już nie tylko na kalendarz. Może zmienić rozliczenie normy, nadgodzin i późniejszą ewidencję.

Dlatego przy analizie nie zatrzymujemy się na miejscu, w którym użytkownik wykonuje daną operację. Sprawdzamy również, gdzie te same dane będą wykorzystane później.

Zapis wyjścia prywatnego jest więc tylko jednym etapem. O poprawności rozwiązania decyduje również to, czy pozostałe dane pozwalają właściwie odtworzyć czas pracy przed wyjściem i po powrocie. Podobne zależności pojawiają się przy delegacjach obejmujących część dnia.

W pewnym momencie projekt zaczyna więc wyglądać inaczej. Nie chodzi już o to, aby każdemu zgłoszeniu przypisać osobną poprawkę. Punktem odniesienia staje się rzeczywisty przebieg dnia pracownika.

Każde kolejne wymaganie można wtedy sprawdzić według podobnego schematu:

Takie uporządkowanie pozwala oceniać nowe wymagania w odniesieniu do reguł całego rozwiązania, zamiast za każdym razem projektować kolejny wyjątek.

Aby wspólne reguły mogły zostać prawidłowo wdrożone, trzeba było przełożyć je na jednoznaczne wymagania. Ogólne oczekiwanie użytkownika nie zawsze wskazuje, jak system powinien zachować się przy połączeniu kilku zdarzeń — dlatego tak ważne stały się konkretne scenariusze.

Analiza wymagań w enova365 – od opisu wniosku do scenariusza pracownika

Przy tak powiązanych procesach znaczenie ma precyzja formułowania wymagań.

Zdanie „pracownik powinien móc złożyć kilka wniosków jednego dnia” pozostawia sporo miejsca na interpretację. Znacznie więcej mówi konkretny scenariusz:

pracownik rozpoczyna pracę o 8:00, od 10:00 do 12:00 korzysta z opieki, następnie wraca do pracy, a od 16:00 do 18:00 pracuje w nadgodzinach.

W takim układzie od razu można sprawdzić, jakie przedziały pojawią się w kalendarzu, czy zachowana jest norma i od którego momentu rzeczywiście może rozpocząć się czas nadliczbowy.

Tak samo jest z delegacją. Sama informacja o wyjeździe nie wystarcza. Znaczenie ma jego początek, zakończenie, praca przed wyjazdem i po powrocie oraz sposób rozliczenia poszczególnych etapów.

Precyzyjny opis scenariusza ogranicza ryzyko rozbieżnej interpretacji tego samego wymagania przez klienta, konsultanta i programistę.

Tak przygotowane scenariusze pełniły również praktyczną funkcję w testach: pozwalały sprawdzić, czy uzgodnione zasady działają nie tylko osobno, ale także w połączeniu z innymi zdarzeniami.