Witam, mam do zrobienia projekt systemu zarządzania klubem piłkarskim. Ponieważ jestem w tym zielony, nie jestem pewny, czy dobrze to robię, więc proszę o jakieś porady, poprawki. A oto moje wypociny, pewnie trochę za bardzo to zagmatwałem, ale...

Dodaję jeszcze opis tego projektu(możliwość edycji):
System zakłada zarządzanie zawodnikami i transferami. Dla zawodników planowane są płace, premie oraz reżim treningowy. Poza tym w razie kontuzji planowane są zabiegi i rehabilitacja. Na mecze wyjazdowe rezerwowany jest autokar oraz w razie potrzeby nocleg. System zarządza też sprzedażą biletów na mecze domowe, imiennych karnetów wiernego kibica oraz wynajmem stadionu na imprezy promocyjne. W ramach zarządzania finansami klubu sprzedawana też jest powierzchnia reklamowa na koszulkach piłkarzy oraz wokół stadionu i na biletach. Miejsca na stadionie są numerowane. System odpowiada też za zarządzanie klubowym magazynem, aby nie zabrakło napojów energetycznych, piłek, koszulek i innego niezbędnego zaplecza.

Mam sporo uwag - wymienię wybrane grupy
- nazewnictwo przypadków użycia - proponuje nazwę UC w formie dokonanej
np.
zamiast 'badanie' -> wprowadź wyniki badania;
zamiast 'zakup biletu' -> kup bilet;

- wydaje mi się że zdecydowanie za dużo asocjacji (w stosunku do wymagań w formie opisowej)
np.
prezes - transfer (OK) - rozumiem jako prezes wykonaj/odnotuj transfer zawodnika
zawodnik - transfer (?) - czy na pewno - rozumiem jako -> zawodnik odnotowuje transfer siebie lub innego zawodnika

inny przykład
zawodnik - płace <-ext - extneds - rozumiem jako -> zawodnik ma możliwość zdefiniowania wynagrodzenia oraz premii (sobie lub innemu zawodnikowi)

- za dużo extend - zakup biletu <-ext- rodzaj biletu - czy czasem wybór 'rodzaj biletu' nie jest integralną częścią transakcji zakupu biletu - a co za tym idzie czy należy go wyróżniać jako osoby useCase

- za dużo include - 'sprawdź wolne miejsce' --inc-> 'zapłata' -> co rozumiem jako częścią sprawdzania wolnego miejsca jest zapłata - co raczej powinno być na odwrót tzn. w ramach transakcji dokonania 'płatności' weryfikowane jest czy zakupione 'miejsce' jest nadal dostępne.

- nieosiągalne przypadki użycia 'mecz na wyjeździe' (kto go inicjuje - system ?)

- z zastosowanych elementów wynika że jest to diagram przypadków systemowych podczas gdy z kontekstu bardziej wskazuje na biznesowe przypadki użycia które nie koniecznie wszystkie zostaną obsłużone w twoim systemie (no chyba że się mylę i twój system będzie naprawdę rozbudowany).
przykładowo - czy aby na pewno lekarz będzie odnotowywał w systemie fakt wykonanego zabiegu (łącznie z danymi medycznymi) czy może jednak osoba z klubu będzie odnotowywała jedynie 'kontuzję' bez podawania szczegółów jedynie określając niedostępność zawodnika.

Witam,
proponuję zastanowić się nad możliwością zmniejszenia liczby przypadków użycia na diagramie. (Założenie dotyczące nieprzekraczania 9 przypadków użycia na diagramie, jest niezmiernie wartościowe).

Pozdrawiam,
Artur

Dzięki za pomoc, trochę mi rozjaśniłeś o co chodzi, spróbuję to trochę skrócić i uporządkować. Co do opisu, jest to własny opis, bo do projektu dostaliśmy tylko temat, szablon projektu, resztę mieliśmy sobie sami założyć. A co do systemowych czy biznesowych przypadków użycia, to nie za bardzo rozumiem różnicę, a mam takie podpunkty do wykonania:
2. MODEL WYMAGAŃ
2.1 Biznesowe przypadki użycia
2.1.1 Diagramy przypadków użycia
2.1.2 Opisy przypadków użycia
2.2 Aktorzy
2.2.1 Pracownicy
2.2.2 Aktorzy biznesowi
2.2.3 Pozostałe systemy
2.2.4 Mapa ról
2.3 Wymagania systemowe
2.3.1 Systemowe diagramy przypadków użycia
2.3.2 Opisy systemowych przypadków użycia
A oprócz tego mam zrobić 5 diagramów czynności do wybranych przypadków użycia, co mniej więcej rozumiem, ale nie rozumiem podpunktu:
1.1.3 Model procesu biznesowego (diagram czynności – activity diagram))
Czym te diagramy się różnią? Z góry dzięki za wszelką pomoc.