Projektowanie Systemu Zarządzania Harmonogramem Dostaw

Warunki początkowe

• Dyspozytor jest zalogowany w systemie.
• Trwa dzień roboczy poprzedzający dzień, którego dotyczy harmonogram.
• Bieżący czas systemowy to godzina wcześniejsza niż 16:00.
• W systemie istnieją zlecenia o statusie „Nowe".

Scenariusz interakcji

1. Dyspozytor wybiera opcję zarządzania harmonogramem na kolejny dzień roboczy.
2. System wyświetla interfejs planowania z listą nieprzydzielonych zleceń i dostępnych kierowców.
3. Dyspozytor wykonuje operacje zarządcze: tworzy nową trasę i przypisuje kierowcę oraz pojazd; dodaje/usuwa zlecenia; zmienia kolejność; modyfikuje parametry trasy.
4. [«extend»] Dyspozytor może uruchomić PU: „Automatyczna optymalizacja tras".
5. Dyspozytor zatwierdza i „publikuje" harmonogram (najpóźniej o 16:00).
6. System wysyła sfinalizowane trasy do aplikacji mobilnych kierowców.

Sytuacje wyjątkowe

• 1a. Próba edycji po 16:00 – system wyświetla harmonogram w trybie tylko do odczytu.
• 1b. Pilna modyfikacja po 16:00 – dyspozytor uruchamia PU: „Reagowanie na opóźnienia lub awarie".
• 3a. Brak dostępnych zasobów – system informuje o braku kierowców lub pojazdów.
• 5a. Anulowanie zmian – system cofa niezapisane zmiany po potwierdzeniu.

Warunki końcowe

Harmonogram na następny dzień roboczy jest utworzony, zatwierdzony i wysłany do kierowców. Wszystkie zlecenia przypisane do tras.

Warunki początkowe

• Dyspozytor jest zalogowany w systemie.
• W systemie zarejestrowane jest zgłoszenie opóźnienia/awarii LUB system automatycznie wykrył problem.

Scenariusz interakcji

1. System wyświetla powiadomienie o problemie: typ, kierowca, pojazd, lokalizacja, szacowane opóźnienie, zagrożone dostawy.
2. Dyspozytor wybiera opcję szczegółowego podglądu.
3. System prezentuje rekomendowane opcje reakcji.
4. Dyspozytor wybiera jedną z opcji:

5. Dyspozytor dodaje komentarz opisujący podjęte działania.
6. Po rozwiązaniu dyspozytor zamyka zgłoszenie.
7. System oznacza zgłoszenie jako „Rozwiązane" z timestampem i archiwizuje.

Warunki końcowe

Harmonogram zaktualizowany, kierowcy i klienci powiadomieni, zgłoszenie zamknięte z dokumentacją.

Warunki początkowe

• Dyspozytor jest zalogowany w systemie.
• Harmonogram na bieżący dzień roboczy został zatwierdzony.

Scenariusz interakcji

1. Dyspozytor wybiera funkcję „Monitorowanie floty".
2. System wyświetla mapę i listę tras na bieżący dzień.
3. System cyklicznie (co 60 s) odświeża: [«include»] pobiera dane z systemu GPS, aktualizuje pozycje na mapie, odbiera statusy od kierowców, przelicza ETA.
4. Dyspozytor może wybrać konkretną trasę do podglądu szczegółów.
5. [«extend»] Wykrycie problemu → automatycznie uruchamia PU: „Reagowanie na opóźnienia lub awarie".

Sytuacje wyjątkowe

• 3a. Brak danych GPS – system wyświetla ostatnią pozycję z ikoną ostrzeżenia.
• 3b. Brak aktualizacji statusu od kierowcy >2h – system oznacza trasę i sugeruje kontakt.

Warunki końcowe

Dyspozytor posiada aktualną informację o statusie wszystkich dostaw.

Warunki początkowe

• Dyspozytor jest zalogowany.
• System w trybie tworzenia/zarządzania harmonogramem.

Scenariusz interakcji

1. Dyspozytor wybiera trasę do optymalizacji.
2. System pobiera współrzędne punktów dostawy.
3. System stosuje algorytm optymalizacyjny minimalizujący dystans/czas.
4. System prezentuje porównanie: dotychczasowa vs. zoptymalizowana trasa (dystans, czas, oszczędność paliwa).
5. Dyspozytor akceptuje lub odrzuca.
6. Jeśli akceptuje – system aktualizuje kolejność zleceń.

Sytuacje wyjątkowe

• 4a. Brak lepszej trasy – system informuje o braku możliwości optymalizacji.
• 5a. Trasa narusza ograniczenia czasowe – system wyświetla ostrzeżenie z informacją o dotkniętych klientach.

Warunki końcowe

Trasa zoptymalizowana lub pozostawiona bez zmian.

Warunki początkowe

• Kierowca zalogowany, ma przydzielone zlecenia.
• Pojazd jest zatrzymany (wymaganie bezpieczeństwa).

Scenariusz interakcji

1. Kierowca wybiera aktualizację statusu.
2. System wyświetla listę zleceń z aktualnym statusem.
3. Kierowca wybiera zlecenie i nowy status: „Rozpoczęta", „Dostarczona", „Nieudana dostawa".
4. Przy statusie „Nieudana dostawa" – przyczyna z listy (brak odbiorcy, odmowa, nieprawidłowy adres, inne).
5. Kierowca opcjonalnie dodaje komentarz i zatwierdza.
6. System zapisuje status z datą/godziną i wysyła powiadomienie do klienta.

Warunki końcowe

Status zaktualizowany, klient powiadomiony.

Warunki początkowe

• Kierowca zalogowany, ma przydzielone zlecenia na bieżący dzień.

Scenariusz interakcji

1. Kierowca wybiera podgląd zleceń.
2. System wyświetla listę w kolejności realizacji: numer, adres, preferowana godzina, kontakt do klienta, uwagi.
3. Kierowca może wybrać zlecenie do szczegółowego podglądu: pełny adres, dane kontaktowe, rodzaj towaru, instrukcje specjalne.
4. System wyświetla przycisk nawigacji uruchamiający aplikację map.

Sytuacje wyjątkowe

• 2a. Brak przydzielonych zleceń – system informuje kierowcę.
• 6a. Brak aplikacji nawigacyjnej – system wyświetla adres w formie tekstowej.

Warunki końcowe

Kierowca posiada pełną informację o swoich zleceniach.

Warunki początkowe

• Kierowca zalogowany, w trakcie realizacji trasy.

Scenariusz

1. Kierowca wybiera opcję zgłoszenia problemu.
2. System wyświetla formularz: typ problemu, szacowany czas opóźnienia (min), opis.
3. Kierowca zatwierdza – system zapisuje z datą, godziną, lokalizacją GPS.
4. System wysyła powiadomienia do dyspozytora i dotkniętych klientów.

Sytuacje wyjątkowe

• 4a. Anulowanie zgłoszenia – system powraca bez zapisywania.
• 5a. Brak połączenia sieciowego – system zapisuje lokalnie i wysyła po przywróceniu połączenia.

Warunki końcowe

Zgłoszenie zapisane, powiadomienia wysłane.

Warunki początkowe

• Zarejestrowane zgłoszenie opóźnienia/awarii przez kierowcę.
• Zdefiniowani odbiorcy powiadomień.

Scenariusz

1. System identyfikuje dotkniętych klientów i pobiera ich dane kontaktowe.
2. Generuje wiadomości i wysyła e-mail do klientów.
3. Opóźnienie >60 min → dodatkowo SMS do klientów.
4. Wysyła e-mail do dyspozytora.
5. Awaria krytyczna lub opóźnienie >120 min → SMS do dyspozytora.
6. Zapisuje informacje o wysłanych powiadomieniach.

Sytuacje wyjątkowe

• 4a. Błąd e-mail – system loguje i oznacza klienta do kontaktu telefonicznego.
• 5a. Błąd SMS – ponowienie po 2 min, max 3 próby.
• 2a. Brak danych kontaktowych – system tworzy zadanie dla obsługi klienta.
• 1a. Brak dostępu do systemu powiadomień – kolejkowanie, ponawianie co 5 min, alert do admina.

Warunki końcowe

Powiadomienia e-mail i SMS wysłane, informacje zapisane w systemie.

Warunki początkowe

• System GPS w pojazdach aktywny, połączenie sieciowe dostępne.
• Istnieją aktywne trasy „W realizacji".

Scenariusz

1. System co 60 s inicjuje zapytanie do GPS o lokalizacje aktywnych pojazdów.
2. GPS zwraca: identyfikator pojazdu, pozycję, czas pomiaru, prędkość.
3. System waliduje poprawność i kompletność danych.
4. Aktualizuje pozycje w bazie z timestampem.
5. Udostępnia dane do modułu monitorowania.

Sytuacje wyjątkowe

• 1a. Brak odpowiedzi GPS – zachowanie ostatnich pozycji, ponowienie w następnym cyklu, alert po 3 próbach.
• 3a. Nieprawidłowy format – odrzucenie wadliwych danych, alert po 5 błędach dla pojazdu.

Warunki końcowe

Zaktualizowane pozycje pojazdów, dane dostępne dla monitorowania.

Warunki początkowe

• Pracownik zalogowany, w systemie istnieją zlecenia.

Scenariusz

1. Pracownik wprowadza kryteria wyszukiwania: numer zlecenia, klient, data, status, telefon.
2. System wyświetla listę znalezionych dostaw.
3. Pracownik wybiera dostawę – system wyświetla pełne informacje i lokalizację na mapie (jeśli w trakcie).
4. Pracownik może przejść do obsługi reklamacji [«include»].

Sytuacje wyjątkowe

• 4a. Brak wyników – system proponuje rozszerzenie kryteriów.
• 2a. Brak kryteriów – system wymaga min. jednego pola.

Warunki końcowe

Pracownik posiada pełną informację o wyszukanej dostawie.

Warunki początkowe

• Pracownik zalogowany, klient zgłosił problem.

Scenariusz

1. Pracownik wybiera opcję obsługi reklamacji dla wyświetlanej dostawy.
2. System wyświetla formularz: typ problemu, opis, priorytet, proponowane rozwiązanie.
3. Pracownik wypełnia i zatwierdza.
4. System generuje unikalny numer reklamacji i zapisuje.
5. System wysyła e-mail potwierdzający do klienta z numerem sprawy.

Warunki końcowe

Reklamacja zapisana i przypisana do dostawy.

Warunki początkowe

• Klient kontaktuje się z firmą w celu zamówienia dostawy.

Scenariusz interakcji

1. Pracownik wybiera opcję nowego zlecenia.
2. System wyświetla formularz: klient, adres dostawy, data, godzina, rodzaj towaru, waga/wymiary, uwagi, priorytet.
3. Pracownik wyszukuje klienta po nazwie lub NIP.
4. Pracownik wypełnia pola, system prezentuje dostępne terminy.
5. Pracownik wybiera termin i zatwierdza.
6. System waliduje, generuje numer zlecenia, zapisuje.
7. Pracownik przekazuje klientowi numer zlecenia.

Sytuacje wyjątkowe

• 5a. Dodawanie nowego klienta – formularz danych: nazwa, NIP, adres, kontakt, weryfikacja, zapis.
• 9a. Nieprawidłowe dane – system wyświetla komunikaty błędów.
• 7a. Brak terminów – system proponuje alternatywne.

Warunki końcowe

Nowe zlecenie zapisane, wygenerowany numer, klient poinformowany.

Warunki początkowe

• Pracownik zalogowany, istnieją niewyeksportowane dostawy.

Scenariusz interakcji

1. Pracownik wybiera eksport danych.
2. System wyświetla formularz: zakres dat, status rozliczenia, klient, status dostawy.
3. Pracownik wprowadza kryteria i zatwierdza.
4. System wyświetla podgląd: liczba zleceń, łączna wartość, zakres dat.
5. Pracownik potwierdza eksport.
6. System generuje plik CSV (identyfikator, dane klienta, data, wartość, status rozliczenia, nr faktury/WZ).
7. System oznacza dostawy jako „Wyeksportowane" z datą.

Sytuacje wyjątkowe

• 5a. Brak danych – powrót do kryteriów.
• 6a. Niekompletne dane – ostrzeżenie, opcja eksportu bez tych rekordów.
• 8a. Błąd generowania – logowanie, opcja ponowienia.

Warunki końcowe

Plik CSV wygenerowany, dostawy oznaczone jako wyeksportowane.

Warunki początkowe

• Pracownik zalogowany, istnieją zrealizowane dostawy z danymi o kosztach.

Scenariusz interakcji

1. Pracownik wybiera generowanie raportów kosztów.
2. System wyświetla formularz: typ raportu (podsumowanie/ wg kierowców/ wg klientów/ wg tras), zakres dat, format (PDF/Excel/CSV).
3. System oblicza: łączne koszty, średni koszt na zlecenie, wskaźnik rentowności, porównanie z poprzednim okresem.
4. System generuje raport z wykresami i tabelami.
5. Pracownik przegląda i pobiera raport.

Sytuacje wyjątkowe

• 5a. Brak danych za okres – propozycja zmiany zakresu.
• 7a. Błąd generowania – logowanie, opcja ponowienia.

Warunki końcowe

Raport wygenerowany, dostępny do pobrania.

Warunki początkowe

• Użytkownik nie posiada konta, ma dostęp do portalu rejestracyjnego.

Scenariusz interakcji

1. Użytkownik wybiera rejestrację nowego konta.
2. System wyświetla formularz: nazwa firmy, NIP, adres, osoba kontaktowa, telefon, e-mail, hasło.
3. Użytkownik wypełnia formularz, akceptuje regulamin.
4. System weryfikuje dane (format NIP, e-mail, zgodność haseł).
5. System sprawdza unikalność NIP/e-mail.
6. System tworzy konto, generuje ID, wysyła e-mail z linkiem aktywacyjnym.

Sytuacje wyjątkowe

• 6a. Nieprawidłowe dane – komunikat przy błędnym polu.
• 7a. Klient już zarejestrowany – propozycja odzyskania hasła.
• 4a. Brak akceptacji regulaminu – wymuszenie akceptacji.

Warunki końcowe

Konto klienta utworzone (nieaktywne), e-mail z linkiem aktywacyjnym wysłany.

Standardowy przypadek użycia logowania – bez szczegółowego opisu.

Warunki początkowe

• Klient jest zalogowany do systemu.

Scenariusz interakcji

1. Klient wybiera złożenie nowego zamówienia.
2. System wyświetla formularz: adres (z zapisanych lub nowy), rodzaj towaru, waga/wymiary, preferowana data, uwagi.
3. Klient wypełnia dane zamówienia.
4. [«include»] System sprawdza dostępne terminy dostawy.
5. System prezentuje terminy z cenami.
6. Klient wybiera termin i godzinę.
7. System wyświetla podsumowanie: adres, termin, cena, szacowany czas.
8. Klient zatwierdza zamówienie.
9. System generuje numer, zapisuje, wysyła potwierdzenie e-mail.

Sytuacje wyjątkowe

• 5a. Brak terminów – propozycja alternatywnych.
• 9a. Nieprawidłowe dane – komunikaty błędów.
• 3a. Nowy adres – formularz, opcja zapisu na przyszłość.
• 11a. Błąd e-mail – zapis zamówienia, ostrzeżenie o problemie.

Warunki końcowe

Zamówienie zapisane, numer wygenerowany, potwierdzenie wysłane.

Warunki początkowe

• System ma dostęp do aktualnego harmonogramu, określony adres dostawy.

Scenariusz interakcji

1. System odbiera zapytanie o terminy z adresem i szacowanym czasem dostawy.
2. Pobiera harmonogramy na najbliższe 14 dni.
3. Analizuje obłożenie tras, oblicza dostępny czas i okna czasowe.
4. Identyfikuje dni z wystarczającą ilością wolnego czasu.
5. Oblicza cenę dla każdego terminu.
6. Zwraca listę terminów z podziałem na dni i godziny.

Sytuacje wyjątkowe

• 5a. Brak terminów w 14 dniach – podaje pierwszy przewidywany wolny termin.
• 3a. Niespójne dane – logowanie, kontynuacja z pominięciem błędnych rekordów.

Warunki końcowe

Lista dostępnych terminów z cenami zwrócona.

Warunki początkowe

• Klient zalogowany, ma aktywne/historyczne zamówienia.

Scenariusz

1. Klient wybiera przegląd swoich dostaw.
2. System wyświetla listę w zakładkach: aktywne, zaplanowane, zrealizowane.
3. Klient wybiera dostawę – system wyświetla szczegóły i lokalizację na mapie (jeśli w trakcie).
4. System automatycznie odświeża status co 2 min.
5. [«extend»] Klient może przejść do zgłoszenia reklamacji.

Sytuacje wyjątkowe

• 2a. Brak zamówień – propozycja złożenia nowego.
• 4a. Brak danych GPS – ostatnia znana lokalizacja.

Warunki końcowe

Klient posiada aktualną informację o statusie swoich dostaw.

Warunki początkowe

• Klient zalogowany, w systemie występują zmiany statusu.

Scenariusz

1. System wykrywa zdarzenie (zmiana statusu, opóźnienie, dostawa zrealizowana).
2. Generuje treść: typ, numer zamówienia, opis, nowy ETA.
3. Wysyła e-mail. Opóźnienie >30 min lub status „Dostarczona" → SMS.
4. Wyświetla powiadomienie w interfejsie (pop-up/baner).
5. Klient klika powiadomienie → szczegóły dostawy.
6. System oznacza jako „Przeczytane", archiwizuje w historii.

Sytuacje wyjątkowe

• 3a. Błąd e-mail – system kolejkuje, ponawia co 5 min, max 3 próby.
• 6a. Klient niezalogowany – powiadomienie czeka na kolejne logowanie.

Warunki końcowe

Klient poinformowany, powiadomienie zapisane w historii.

Warunki początkowe

• Klient zalogowany, system wyświetla szczegóły dostawy.

Scenariusz

1. Klient wybiera opcję zgłoszenia reklamacji.
2. System wyświetla formularz: typ problemu, opis, załączniki zdjęć, preferowany sposób kontaktu, oczekiwane rozwiązanie.
3. Klient wypełnia i zatwierdza.
4. System waliduje, wyświetla potwierdzenie z numerem zgłoszenia i czasem odpowiedzi (do 48h roboczych).

Sytuacje wyjątkowe

• 5a. Niepełne dane – komunikat o wymaganych polach.
• 3b. Problem krytyczny (brak dostawy, uszkodzenie) – automatyczne oznaczenie jako priorytetowe.

Warunki końcowe

Zgłoszenie zapisane, numer wygenerowany, powiadomienia wysłane do obsługi i klienta.