Sory za hard spam ostatnio ;)
Mam napisać USE CASE dotyczące systemu zarządzania w hotelu. Po pierwsze trochę się ta aplikacja tak hm... rozchodzi? Znaczy jej koncepcja. W sumie to nawet nie wiem co miało być na początku. Mi zgłoszono o to taki pomysł: rezerwacje i zarządzanie personelem. Czy aby to nie powinny być dwie oddzielne aplikacje, ewentualnie połączone w jeden system? Ale z dwoma bazami danych? Z drugiej strony musimy jakoś przechowywać dane osoby która coś tam robi, znaczy recepcjonisty. Dwie nie powiązane ze sobą aplikacje? Znaczy w pierwszej aplikacji odnośnie rezerwacji, konta pracowników z podstawową personalizacją: imię, nazwisko, id. W drugiej, informacje o pracownikach, adres, staż pracy, stanowisko, przełożony, dni pracy, uwagi etc.
Dalej padła idea aby dorobić apki mobilne aby klienci mogli sobie sami rezerwować etc / równolegle i recepcjonistami.
Rozumiem, że jak mam pisać te USE CASE?
Przykłady: skrócenie pobytu, przedłużenie pobytu(ps czy akurat te nie lepiej połączyć w jedno?(skrócenie/przedłużenie pobytu))płatność za pobyt etc. Tutaj widzę taki problem że mamy tak naprawdę dwie grupy userów (recepcjonista i klient) Obie te grupy mogą rezerwować, czy anulować rezerwacje, ale tylko recepcjonista może na przykład opłacić pobyt przez zaznaczenie samej opcji ponieważ możliwe że dostał te pieniądze gotówką. Jeden USE CASE : Anulowanie rezerwacji i dwóch aktorów? Użytkownik i recepcjonista? Jak dalej? Podczas scenariusza nazywać ich po prostu aktorem głównym?
Inna sprawa czy USE CASE dotyczące rezerwacji nie powinny być jakoś oddzielone od tych dotyczących zarządzania pracownikami?
Ps Dobrze uważam że USE CASE: Modyfikacja rezerwacji jest za ogólny i on rozrósł by się niebotycznie? Można zmienić date/czas trwania rodzaj, szczególnym przypadkiem jest zmiana że na przykład pobyt został opłacony. Ponadto ten USE CASE za dużo nie mówi. Nie lepiej bardziej konkretne? Że jak spojrzymy na liste USE CASE to już czujemy do czego one służą?