Wymagania niefunkcjonalne - PatrykLesiak/Gathering GitHub Wiki

Wymagania względem projektu

Terminarz zakończenia poszczególnych etapów pracy (zgodny z umieszczonym we wprowadzeniu)

Reguły biznesowe

1. Obowiązujące prawo dotyczące ochrony danych osobowych:

1.1. Konieczność stosowania ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych jest przerzucona na odbiorcę produktu - organizatora (tj. hotel, biuro podróży itd.)

2. Dla biur podróży:

2.1.Obecnie uczestnicy wyjazdów (w tym zagranicznych) organizowanych przez biura podróży zmuszeni są zabrać ze sobą dodatkową ilość gotówki w lokalnej walucie, którą pierwszego lub drugiego dnia opłacają wycieczki fakultatywne poprzez przekazanie gotówki rezydentom oraz wpisanie się na listę.

Nasz system zapewnia brak konieczności posiadania przy sobie gotówki w trakcie wycieczek oraz zapewnia automatyzację procesu zapisu. Nie jest wymagana obecność rezydenta.

3. Dla hoteli:

3.1. Zapisu na uroczystości, zabawy z animatorami, bale, spotkania dokonuje się w recepcji za pośrednictwem recepcjonisty/recepcjonistki.

Dzięki dostarczonemu systemowi nastąpi automatyzacja procesu zapisu na wydarzenia poprzez możliwość skorzystania z własnego, bądź udostępnionego przez hotel urządzania mobilnego. Nie jest wymagana obecność pracowników hotelu.

4. Dla kół naukowych:

4.1. Obecnie istnieje konieczność wypełniania dokładnych danych osobowych uczestników wycieczek przez organizatora w celu otrzymania dofinansowania z uczelni.

System tworzy listę automatycznie na podstawie danych osób, które zapisały się na wydarzenie. Jest to ułatwienie pracy organizatora.

5. Dla organizatorów imprez masowych i kulturalnych:

5.1. Obecnie przy organizacju dużych eventów w przestrzeni zamkniętej (zgromadzenia powyżej 500 osób) należy powiadomić policję, której zadaniem jest ewentualna pomoc w zabezpieczeniu imprezy.

5.2. Zgromadzenia publiczne - definiowane jako jako zgrupowanie co najmniej 15 osób, zwołane w celu wspólnych obrad lub w celu wspólnego wyrażenia stanowiska - zgodnie z przepisami polskiej Konstytucji muszą być zgłoszone na maksimum 30 dni do minimum 3 dni przez rozpoczęciem zgromadzenia do władz gminnych.

Zadaniem systemu będzie powiadomienie organizatora o przekroczeniu bądź rychłej możliwości przekroczenia dopuszczalnej ilości osób w przestrzeniach zamkniętych lub publicznych, które mogłyby wymagać dodatkowych działań ze strony organizatora. W przyszłości planowana jest automatyzacja procesu powiadamiania - poprzez przygotowanie i wypełnienie odpowiednich dokumentów za organizatora z możliwością wydruku.

6. Otrzymanie biletu

6.1. Uczestnik dopiero po opłaceniu biletu może go dostać (w formie elektronicznej - na skrzynkę e-mail)

Ograniczenia implementacji

  • nie są brane pod uwagę rozwiązania płatne dla projektów komercyjnych

Dostępność, wydajność, niezawodność

Aplikacja webowa będzie dostępna przez dowolną przeglądarkę internetową, co zwiększa dostępność rozwiązania do maksimum. System będzie w stanie obsłużyć wielu użytkowników jednocześnie, przy jednoczesnym ograniczeniu do maksymalnej prędkości łącza. Dokładna ilość operacji przeprowadzanych w jednym momencie nie została jeszcze określona.

Użyteczność

  • nasz produkt będzie skracał czas przygotowania wydarzenia przez organizatora poprzez szereg funkcjonalności oraz ułatwiał zwykłym użytkownikom możliwość znalezienia interesującego ich wydarzenia oraz wzięcie w nim udziału, co będzie przekładało się na satysfakcję
  • ograniczenie błędów implementacyjnych do minimum poprzez model testowania kodu,
  • dzięki dużej intuicyjności interfejsu system będzie bardzo prosty w obsłudze,
  • zapewni cykliczny powrót do korzystania z naszego produktu (np. co wakacje),
  • efektywność pod względem wyglądu i możliwości - system stworzony według najnowszych trendów w stylizacji aplikacji webowych.

Dokumentacja

  • instrukcja obsługi systemu dla osób chcących się zapisać na wydarzenia oraz organizatorów,
  • dokumentacja analityczna systemu (produkt analizy biznesowej, zawiera procesy biznesowe, wymagania funkcjonalne i niefunkcjonalne),
  • dokumentacja architektury systemu,
  • samodokumentujący się kod (zgodnie ze Słownikiem pojęć).

Utrzymanie systemu

W przypadku produktu spersonalizowanego wsparcie dla klientów będzie udzielane przez okres dziesięciu lat od daty wdrożenia. Natomiast w przypadku zwykłej wersji aplikacji wsparcie to będzie udzielane przez cały okres istnienia jej na rynku.

Problemy i ryzyka

Lp. Problem / Ryzyko Działanie
1. Istnieje mała szansa na powstanie podobnego systemu przed ukończeniem prac nad naszym systemem, Sprawdzanie rynku podobnych rozwiązań przez cały okres tworzenia projektu.
2. Zdecydowanie większe prawdopodobieństwo istnieje na powstanie kolejnych konkurencyjnych produktów po uruchomieniu naszego, Ewentualna konkurencyjność cenowa z późniejszymi rozwiązaniami.
3. Konieczność przetrzymywania w bazie danych osobowych stwarza duże prawdopodobieństwo ataku hakerów chcących wykraść dane użytkowników, Przerzucenie odpowiedzialności za przetrzymywanie bazy danych na podmioty korzystające z rozwiązania Gathering.
4. Konieczność używania zewnętrznych systemów płatniczych stwarza ryzyko braku dopasowania danych wymaganych dla systemów płatniczych, Dopasowanie danych do zewnętrznych systemów płatniczych już po wyborze systemu, który w największym stopniu będzie odpowiadał potrzebom klienta, przy jednoczesnym utrzymaniu kryterium cenowego.
5. Może się okazać, że w tym samym czasie z systemu będzie korzystać bardzo,duża liczba użytkowników i akcje, które będą chcieli wykonać przeciążą,system. Przed wypuszczeniem gotowego produktu na rynek przeprowadzenie intensywnych testów wydajnościowych systemu