Krzysztof kuhy Rudnicki
54337a662e
Five files were outside README / CLAUDE* / DOCS* / TODO*, and two were over the 250-line cap. Both gates now pass repo-wide. Renames: the two lowercase readme.md files, and three documents into DOCS-*. The AIS requirements doc split at its own boundary into functional (101) and non-functional (174). The WDWR report split into six numbered sections behind an index that keeps the original filename, 38-235 lines each; 753 lines of body plus the 18-line header account for all 771 original lines, so nothing was dropped. That WDWR file needed checking before splitting: it sits next to main.tex and main.pdf and looked like a conversion of them. It is not -- main.tex is project 25406 and the markdown is project 18402, a different document. So it is authored content and the split is real work, not churn on a build artifact. Filled the three empty READMEs and replaced ECOTE's, which was a stale copy of the root README still claiming the group projects were excluded -- they were merged in by subtree some time ago. EOPSY/lab1 turned out not to be the code-free directory the survey suggested: it has modify.sh and modify_examples.sh. The oddly-named empty files beside them are the exercise's OUTPUT, committed so the before/after state is visible, and its README now says so rather than leaving them looking like junk. CLAUDE.md follows the testsAndMisc structure. Writing it caught a nice one: the md-naming marker is a biconditional, so quoting the literal removal string in a non-TODO file fails the gate. The gate was right; the text is rephrased. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0172dj34FDpao6wsix8ZuCzE
6.9 KiB
https://github.com/Artur-Romaniuk/ais
https://www.overleaf.com/project/67e843e5c78b52b01a88211a
System e-Toll do zbierania danych na temat ruchu pojazdów po polskich drogach i naliczania należności za przejazdy.
Rezultatem projektu powinien być dokument PDF, zawierający następujące elementy:
- Wymagania funkcjonalne.
- pogrupowana lista wymagań
- zidentyfikować jeden kluczowy proces biznesowy i szczegółowo ten proces zdefiniować. Definicja procesu to po prostu:
- cel procesu
- stan początkowy
- stan końcowy
- kroki procesu, z uwzględnieniem sytuacji wyjątkowych.
- Wymagania niefunkcjonalne.
- geograficzna skala działania
- liczba obsługiwanych klientów
- liczba obsługiwanych zdarzeń biznesowych w określonym czasie (na godzinę/dziennie/miesięcznie etc.)
- wymagania wydajnościowe
- wymagania niezawodnościowe
- wymagania bezpieczeństwa
- ....
- Projekt systemu w postaci modelu C4 (https://c4model.com/)
- wystarczą 3 pierwsze poziomy : context, containers, components, nie wymagam poziomu code
- diagram dynamiczny(dynamic diagram) realizujący opisany w wymaganiach proces biznesowy
- diagram wdrożenia (deploymen diagram)
- Dyskusja zastosowanych wzorców i/lub taktyk architektonicznych - w celu wyboru odpowiednich rozwiązań należy się odwołać do wymagań funkcjonalnych i niefunkcjonalnych.
- Decyzje architektoniczne w postaci modelu MAD 2.0
Wymagania funkcjonalne
# Wymagania funkcjonalne dla Systemu e-Toll
## Kluczowy proces biznesowy: Naliczanie i pobieranie opłat za przejazd
### 1. Cel procesu
- Wykrywanie pojazdów na płatnych odcinkach dróg
- Naliczanie należności zgodnie z taryfami
- Pobieranie opłat od użytkowników
### 2. Stan początkowy
Pojazd niezarejestrowany w systemie jako znajdujący się na płatnym odcinku drogi, z kontem użytkownika posiadającym określony stan środków (prepaid) lub limitem kredytowym (postpaid).
### 3. Stan końcowy
Prawidłowo naliczona i pobrana opłata za przejazd, zaksięgowana w systemie finansowym, z wygenerowanym potwierdzeniem dla użytkownika oraz aktualizacją stanu konta.
### 4. Kroki procesu
1. Identyfikacja pojazdu wjeżdżającego na płatny odcinek (poprzez urządzenie OBU, aplikację mobilną lub kamery ANPR) [Dla redundancji, im więcej systemów tym większa szansa na identyfikację)
2. Zebranie danych o pojeździe (kategoria, klasa emisji spalin, masa)
3. Rozpoczęcie śledzenia przejazdu i rejestracja czasu wjazdu
4. Monitorowanie trasy przejazdu przez punkty kontrolne
5. Identyfikacja zjazdu z płatnego odcinka
6. Obliczenie należności na podstawie przebytej trasy i charakterystyki pojazdu
7. Weryfikacja dostępności środków na koncie użytkownika
8. Pobranie opłaty z konta użytkownika
9. Wygenerowanie potwierdzenia transakcji
10. Aktualizacja salda konta użytkownika
**Obsługa sytuacji wyjątkowych:**
- Jeśli identyfikacja pojazdu nie jest możliwa: uruchomienie procedury rejestracji incydentu z dokumentacją wizualną (zdjęcia niezidentyfikowanego pojazdu)
- W przypadku niewystarczających środków na koncie:
- Zablokowanie konta do momentu zapłacenia
- W przypadku braku zapłaty w określonym czasie, uruchomienie procedury windykacyjnej
- Przy awarii urządzenia OBU: automatyczne przełączenie na identyfikację przez system kamer ANPR
- W razie przerwy w komunikacji: lokalne buforowanie danych i synchronizacja po przywróceniu łączności
- Jeśli zidentyfikowano omijanie bramek:
- Poinformowanie użytkownika
- uruchomienie procedury kontrolnej
- naliczenie kary
## Wymagania funkcjonalne
1. **System rejestracji użytkowników** - System musi umożliwiać rejestrację nowych użytkowników z weryfikacją tożsamości, zbieraniem danych o pojazdach (w tym masa, klasa emisji, kategoria) oraz wyborem metody płatności (prepaid lub postpaid).
2. **Moduł geolokalizacji pojazdów** - System musi określać pozycję pojazdów z dokładnością do 10 metrów, wykorzystując dane GPS z urządzeń OBU lub aplikacji mobilnej, aktualizowane nie rzadziej niż co 30 sekund podczas przejazdu.
3. **System rozpoznawania tablic rejestracyjnych (ANPR)** - System musi identyfikować pojazdy poprzez kamery ANPR z dokładnością co najmniej 98% w różnych warunkach pogodowych i oświetleniowych, jako dopełnienie jeśli wszystkie systemy działają poprawnie lub alternatywa dla urządzeń OBU w razie awarii..
4. **Elastyczny system taryfowy** - System musi obsługiwać zróżnicowane taryfy opłat w zależności od: typu pojazdu, masy całkowitej, klasy emisji spalin, pory dnia, dnia tygodnia oraz stopnia zatłoczenia drogi.
5. **Moduł rozliczeń i płatności** - System musi obsługiwać różne metody płatności (karty płatnicze, przelewy, płatności mobilne, blik) z możliwością automatycznego doładowania konta prepaid oraz wystawiania faktur elektronicznych zgodnych z przepisami prawa.
6. **System powiadomień dla użytkowników** - System musi wysyłać automatyczne powiadomienia do użytkowników (aplikacja, mail + sms) o: niskim stanie konta, zbliżającym się terminie płatności, dokonanych transakcjach oraz zmianach w taryfach i regulaminie.
7. **Moduł raportowania i analityki** - System musi generować raporty dotyczące natężenia ruchu, generowanych przychodów, incydentów oraz efektywności egzekwowania opłat, z możliwością eksportu danych w formatach CSV i PDF.
8. **System wykrywania naruszeń** - System musi identyfikować próby obejścia opłat (np. manipulacja urządzeniem OBU, podawanie fałszywych danych o pojeździe) i automatycznie uruchamiać procedury weryfikacyjne.
9. **Portal samoobsługowy dla użytkowników** - System musi udostępniać portal internetowy oraz aplikację mobilną umożliwiającą użytkownikom zarządzanie kontem, przeglądanie historii przejazdów i opłat, generowanie raportów oraz aktualizację danych pojazdu.
10. System musi umożliwiać ręczną korektę naliczonej opłaty przez operatora w przypadku zgłoszenia błędu przez użytkownika. Zakładając, że system źle naliczył opłatę np. Użytkownik został obciążony za trasę, której nie przejechał lub przypisano niewłaściwą kategorię pojazdu. Użytkownik zgłasza błąd do obsługi systemu. W takim przypadku operator musi mieć możliwość ręcznej korekty naliczonej opłaty np. Anulowanie opłaty, zmniejszenie jej lub ponowne przeliczenie, jeżeli zgłoszenie użytkownika okaże się zasadne. Zasadność zgłoszenia musi być weryfikowalna poprzez fizyczne zdjęcia pojazdu
Wymagania niefunkcjonalne zostały wydzielone do osobnego pliku, aby zmieścić się w limicie 250 wierszy.