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 |