Podstawowy projekt systemu kancelarii adwokackiej

Witam

Obecnie tworzę wstępny zarys dla niewielkiego systemu, który mógłby rozwiązywać najbardziej podstawowe zadania z którymi mają na co dzień
do czynienia prawnicy/adwokaci/radcy prawni. System który ułatwiałby im życie. Tworzę to powiedzmy ramach treningu.
Na razie rozpisane mam wymagania oraz przypadki użycia aczkolwiek nie jestem pewien czy na podstawie takich wymagań trafnie określiłem scenariusze. Scenariusz w formie tekstowej są nadal w formie realizacji.

Gdyby osoba bardziej wprawiona mogła by to przejrzeć i nakreślić mi błędy lub skomentować to co jest właściwe. Ew wskazówki. W porównaniu do wcześniejszych prób sądzę bardziej się przyłożyłem.

Moze adwokat nie zauważy przy pierwszej demonstracji, ale baza pism bez skatalogowania w sprawy jest śmiertelne dla tego rodzaju użytkownika

Schemat to jest czego ? Pobożnych życzeń ? Dlaczego z dziesiatek / setek obszarów, jakimi może się zajmować kancelaria adwokacka, akurat sprawa windykacyjna zasługuje na odmienne traktowanie ?

Gdyby to była kwesta studiów, to problem miedzy jakością uczelmi i tobą.
Ale pachnie mi że to za kasę. Jeśli tak - żałosne.

@delform_17:

Widze od dawna pchasz tu jakieś schematy, i od dawna jesteś krytykowany.
Szaleństwem jest robić wciąż to samo i oczekiwać różnych rezultatów – Albert Einstein.

To nie jest w ramach studiów tylko własnej praktyki. To jest tylko zarys systemu. Działalność windykacyjna to jest osobny nieco bardziej skomplikowany proces. Umieszczam, a nie pcham tu tego typu rzeczy w ,,nadziei", że ktoś będzie w stanie pokazać mi gdzie robię błędy i jak można to poprawić. Marginesem pobożna życzenia mają ludzie bez celu typu wychować dzieci wziąć kredyt na mieszkanie i jakoś tam żyć.

PS. Nie pracuje dla pieniędzy tylko dla satysfakcji. Pieniądze to tylko dodatek. Co do Einsteina można to ma już mniej sensu to szaleństwo, ale jeszcze nieco wierzę w ludzi

Przy początkowej fazie projektu zbierane są wymagania.
Po zebraniu wymagań ogólnych, są zbierane wymagania szczegółowe i to one są czasami wkładane w przypadki użycia.
Tworzenie przypadku użycia przebiega różnie, często są to tabelki podobne do:

Diagram to tylko dodatek, nie musi być i bardzo często go nie ma.
Format tabelki zależy od firmy, czasem tych kolumn jest mniej, czasem więcej, czasami są inne.

@malencki:

Dopuściłbym śmiało, zwł w sytacjach początkujacych, małych zespołach (z obu stron), przy słabych kwalifikacjach abstrakcyjnych po stronie zleceniodawcy itd ...
... wiec dopuściłbym inne plaszczyzny ujęcia, BYLE KONSEKWENTNIE, jak scenariusze to scenariusze, jak analzia danych (dokumentów, wydruków) to danych.

Obrazkowo: jeśli to jest długopisem na kartce, to nawet jeśli kartka w ujęciu a) jest ledwo wypełniona, zaczynam kartkę b) ponieważ jest w innym spojrzeniu

@AnyKtokolwiek:

c.d.

Tzw "kartka" z propozycjami implementacyjnymi (system uprawnień, elementy architektoniczne o których klient powinien wiedzieć do generują istotne skutki) to nie tylko inna kartka, ale w innym skoroszycie.

@malencki:

Cenne jest ze podniosłeś, a kol powinien przyjąć: co analiza to analiza, co projekt to projekt, to sa inne rzeczy

Panowie tyle komentarzy a tylko jedna osoba ogólnie mnie poprawiła nikt sie nie odniósł do diagramów z choć jedną poprawką. Czytam książkę i staram się stosować w praktyce posiłkując sie też podobnymi przykładami aczkolwiek z racji tego, że nie jestem pewien czy merytorycznie jest dobrze dlatego tutaj wstawiłem.

@delform_17: patrząc po diagramach które umieściłeś to 1 oraz 3 nie mają (jak dla mnie), żadnego sensu.
Nad drugim można pomyśleć ponieważ co nieco wiadomo z tego co zamieściłeś.

Widzę to tak, że aplikant wprowadza opis sprawy, następnie sprawdzany jest duplikat (cokolwiek to oznacza w tym przypadku), następnie opcjonalnie (extended) w zależności od wyników sprawdzenia, opis sprawy ląduje w bazie danych.
Dodatkowo aplikant ma odpowiedzialność za dołączenie dokumentacji oraz ustalenie priorytetu. Chociaż nie jest jasno powiedziane czy te działania są wymagane czy opcjonalne. Narysowałem to tak, chociaż prawie na 99% jest to błędne. Niestety nie znam przypadku użycia tylko domysły więc całość polega bardziej na wróżbiarstwie.
include powinno się używać do pewnej encji systemu, która w przypadku użycia jest wykorzystywana wielokrotnie (ma wiele ścieżek wejścia).

Diagramy use case mają bardzo dyskusyjną przydatność do czegokolwiek (albo kompletnie nie rozumiem ich sensu). Analizę problemów, jakie opisujesz (workflow) należy rozpocząć od udokumentowania procesu biznesowego. Jak się zaczyna, jak przechodzi kolejne etapy, kto bierze w nim udział, w jakiej roli, jakie artefakty są jego wejściem i wynikiem.

Odnosząc się do tego co widzę, to nie istnieje taki use case jak "zapis do bazy". To szczegół implementacyjny taki sam jak np, "inicjalizacja zmiennych".