Inżynieria wymagań i projektowanie "co aplikacja ma robić" na wysokim poziomie

Zastanawiam się, czy powstało coś fajniejszego od use case diagram. Żeby nie poruszać się w próżni, jak byście podeszli do zaprojektowania systemu, który ma wspomóc taki case:

• Firma wykupiła swoim pracownikom basen.
• Basen ma ograniczoną "pojemność" 20 miejsc.
• Chętnych jest więcej (tak, wiem, zmień pracę)
• Zrobiona jest lista, lista rezerwowa
• Czasami ktoś się zapisze, a później nie przyjdzie
• Gdyby powiadomił o tym chętnych dostatecznie szybko, to ktoś pewnie by wskoczył na jego miejsce

Celem wprowadzenia systemu, jest minimalizacja "pustych przebiegów". Jak ktoś nie lubi pływać, to można wstawić w to miejsce kolejkę u lekarza, miejsca parkingowe...

• Od czego byście zaczęli wymyślanie co taki system ma robić?
• Jakich technik byście użyli do modelowania na wysokim poziomie funkcjonalności
• Ew. jakich narzędzi, chociaż to pewnie sprawa wtrórna.

Ja w ogóle nie używałbym żadnych narzędzi do tego celu, według mnie to dostarczyłoby tylko niepotrzebnego bałaganu i overheadu.

Przeprowadziłbym po prostu zwykłą iterację wytwarzania oprogramowania, przygotowanie MVP, pokazanie klientowi, zbieranie feedbacku, powtórz.

@Riddle: Jasne, ale MVP, żeby powstało, też musi mieć jakąś funkcjonalność. Pytanie jak się zabrać za definiowanie tej funkcjonalności. Można np. zacząć od zdefiniowania aktorów, potem dopisania sobie podstawowych akcji jakie ci aktorzy mają mieć możliwość wykonać w aplikacji - tak bym podszedł UML'owo. Nie wiem, czy teraz nie pojawiły się jakieś nowsze "techniki".

piotrpo napisał(a):

@Riddle: Jasne, ale MVP, żeby powstało, też musi mieć jakąś funkcjonalność. Pytanie jak się zabrać za definiowanie tej funkcjonalności.

Spytaj tego kto Ci zlecił napisanie tej aplikacji jaka jest absolutnie podstawowa funkcja tej aplikacji.

piotrpo napisał(a):

Można np. zacząć od zdefiniowania aktorów, potem dopisania sobie podstawowych akcji jakie ci aktorzy mają mieć możliwość wykonać w aplikacji - tak bym podszedł UML'owo. Nie wiem, czy teraz nie pojawiły się jakieś nowsze "techniki".

Nie chodzi o to czy nowsza czy nie nowsza, tylko o to czy to ma jakiś sens. I takie podejście moim zdaniem nie ma sensu.

Ja bym użył metodyki ułańskiej - weźta i zróbta.

@S4t: To jest jakiś "plan", ale, jak chce się biec, to warto najpierw wybrać stronę :D

No to demokratycznie, każdy krzyczy w którą stronę biegniemy, ten kto najgłośniej krzyczy wygrywa.

Nie wiem czy powstało coś bardziej formalnego niż UML i BPMN. C4 czy Event Storming pomijam bo to nie ten case (rozkładanie złożonych funkcjonalności na czynniki pierwsze).

Rozwiązanie tego problemu sprowadza się do dwóch rzeczy: opisu procesu, aktorów, warunków wstępnych, brzegowych, wyjątków i różnych ścieżek alternatywnych być może popartych jakimś diagramem ilustrującym proces.

Więc ja tu widzę dwa wyjścia: formalnie i nieformalne. W nieformalnym stosujesz taką notację, kształty i kolory jakie ci przyjdą do głowy. Z korporacyjnego doświadczenia wiem, że im więcej kolorów i ładnych kształtów w formie ikonek (najlepiej zrobionych w PPT), a nie smutnych prostokątów i beczek, tym większy szacun i prestiż w strukturach korpo enterprajs architektów i CTO. Nawet jeśli taki rysunek nie ma większego sensu i nic nie pokazuje poza fantazją i umiejętnościami graficznymi autora.

W formalnym podejściu ja bym skorzystał z tabel przypadków użycia takich jak tu https://sites.google.com/site/louismccallapcp/home/development/use-cases/use-case-tables. Z diagramu przypadków użycia bym nie korzystał bo to mało wnosi, w tabelach można umieścić dużo więcej informacji. Można też skorzystać z Agile i wykorzystać do tego składnię Gherkin czyli Given, When, Then. Poziom szczegółowości tabel czy informacji zapisywanych za pomocą języka Gherkin to już kwestia indywidualna.

A jeśli chodzi o formalną ilustrację procesu to tu albo BPMN albo jak chcesz/preferujesz zostać przy UML-u to masz coś takiego jak diagram aktywności (Activity Diagram).