From 74e26a0ab030d5331c8d2d55276a67e74d0d46b3 Mon Sep 17 00:00:00 2001 From: Norbert Litkowski Date: Thu, 26 Nov 2020 20:17:15 +0100 Subject: [PATCH 1/9] + Create project requirements document. Update README.md --- Zywica/car-pool/README.md | 4 +- Zywica/car-pool/docs/project_requirements.md | 207 +++++++++++++++++++ 2 files changed, 209 insertions(+), 2 deletions(-) create mode 100644 Zywica/car-pool/docs/project_requirements.md diff --git a/Zywica/car-pool/README.md b/Zywica/car-pool/README.md index db28249..ca981b6 100644 --- a/Zywica/car-pool/README.md +++ b/Zywica/car-pool/README.md @@ -1,3 +1,3 @@ -# Instrukcja +# CARPOOL -W tym katalogu należy umieścić dokumenty wizji systemu oraz wymagań projektowych zgodnie z szablonami. +[Dokument wymagań projektu](docs/project_requirements.md) \ No newline at end of file diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md new file mode 100644 index 0000000..f96daa2 --- /dev/null +++ b/Zywica/car-pool/docs/project_requirements.md @@ -0,0 +1,207 @@ +# Dokument wymagań projektowych + +## Nazwa projektu: Carpool + +## Autorzy: Michał Dulski, Julian Kobryński, Norbert Litkowski, Maciej Sobkowiak + +### 1. Elementy składowe projektu + +#### 1.1 Elementy programistyczne: + +- Aplikacja mobilna dla systemów Android stworzona przy pomocy biblioteki React Native. +- Aplikacja mobilna dla systemów iOS stworzona przy pomocy biblioteki React Native. +- REST API w języku C# oparty na frameworku .NET 5. +- Identity Provider w języku C# i frameworku .NET 5. +- Aplikacja webowa w języku TypeScript oparta na frameworku React. +- Instancja bazy danych oparta o silnik MSSQL. + +#### 1.2 Elementy nieprogramistyczne: + +- Prototyp aplikacji webowej wykonany przy użyciu Adobe XD, +- Prototyp aplikacji mobilnej wykonany przy użyciu Adobe XD, +- Opis interfejsu API wykonany przy użyciu Swaggera, +- Event Storming wykonany przy użyciu tablicy Miro. + +### 2. Granice projektu + +- Aplikacja w Apple AppStore – ze względu na ograniczenia budżetowe projektu, nie zdecydowaliśmy się na umieszczenie aplikacji w AppStore. +- Chat wewnątrz aplikacji – chcemy, aby aplikacja była jak najbardziej wyspecjalizowana. Ze względu, że użytkownicy korzystający z przejazdów wewnątrz jednej grupy najczęściej znają się, mają też prawdopodobnie kontakt w innej aplikacji do komunikacji tekstowej. +- Przejazdy poza grupami – aplikacja skierowana jest do grup znajomych lub pracowników z jednej firmy. Zdecydowaliśmy, że przejazdy będą możliwe jedynie wewnątrz takich grup, gdyż do przejazdów między obcymi ludźmi istnieje wiele konkurencyjnych rozwiązań. + +### 3. Lista wymagań funcjonalnych + +1. Jako użytkownik mogę stworzyć konto w aplikacji, +2. Jako użytkownik mogę zalogować się do aplikacji używając loginu i hasła, +3. Jako użytkownik mogę wylogować się z aplikacji, +4. Jako użytkownik mogę usunąć swoje konto, +5. Jako użytkownik mogę edytować swoje dane w aplikacji, +6. Jako użytkownik mogę łatwo przełączać tryby aplikacji (tryb pasażera lub kierowcy), +7. Jako użytkownik mogę przeglądać otrzymane zaproszenia do grup, +8. Jako użytkownik mogę akceptować lub odrzucać zaproszenia do grup, +9. Jako użytkownik mogę przeglądać grupy, do których należę, +10. Jako użytkownik mogę wyświetlić szczegóły dowolnej grupy, do której należę, +11. Jako użytkownik mogę opuścić grupę, +12. Jako użytkownik mogę stworzyć nową grupę, +13. Jako administrator mogę zapraszać użytkowników do grupy, +14. Jako administrator mogę usuwać członków grupy, +15. Jako administrator mogę przeglądać zaplanowane przejazdy w grupie, +16. Jako administrator mogę przeglądać odbyte przejazdy w grupie, +17. Jako administrator mogę edytować dane grupy, +18. Jako administrator mogę usunąć grupę, +19. Jako administrator mogę wygenerować raport działalności grupy w wybranym przedziale czasowym, +20. Jako pasażer mogę przeglądać przejazdy w grupach, +21. Jako pasażer mogę wysyłać prośby o dołączenie do przejazdu, +22. Jako pasażer mogę przeglądać przejazdy, do których jestem zapisany, +23. Jako pasażer mogę przeglądać przejazdy, w których uczestniczyłem, +24. Jako pasażer mogę przeglądać szczegóły przejazdu, +25. Jako pasażer mogę zrezygnować z przejazdu, na który się zapisałem, +26. Jako kierowca mogę tworzyć przejazdy jednorazowe lub regularne, +27. Jako kierowca mogę wyświetlać prośby o dołączenie do przejazdu, +28. Jako kierowca mogę akceptować lub odrzucać prośby o dołączenie do przejazdu, +29. Jako kierowca mogę wyświetlać zaplanowane przejazdy, +30. Jako kierowca mogą wyświetlać odbyte przejazdy, +31. Jako kierowca mogę wyświetlić szczegóły przejazdu, +32. Jako kierowca mogę usuwać pasażerów z przejazdu, +33. Jako kierowca mogę anulować przejazdy, + +### 4. Lista wymagań funcjonalnych + +1. Internacjonalizacja – system musi posiadać lokalizowane zasoby tekstowe +2. Dostępność - aplikacja mobilna musi być dostępna dla systemów Android 4.4 (API 19+), ze względu na to, że wsparcie dla tej wersji wzwyż zapewnia obsługę większości użytkowników systemu Android +3. Dostęp do repozytorium kodu +4. Aplikacja webowa dostępna dla przeglądarek mobilnych oraz desktopowych +5. Autoryzacja tradycyjna w oparciu o JWT + +### 5. Mierzalne wskaźniki wdrożeniowe + +- Aplikacja webowa zostanie udostępniona na domenie carpool.com.pl i za jej pomocą w systemie zostanie utworzone co najmniej 5 grup obejmujących co najmniej 25 użytkowników. +- W obrębie każdej grupy zostanie wykonany co najmniej jeden przejazd. +- Aplikacja mobilna zostanie udostępniona na Google Play i będzie z niej korzystać co najmniej 20 osób. +- REST API zostanie poddane testom obciążeniowym, które zapewnią, że maksymalny czas odpowiedzi z serwera dla nie więcej niż 100 użytkowników jednoczenie nie przekroczy 2 sekund + +### 6. Kryteria akceptacji projektu dla I semestru prac + +#### 1. Wymagane + +- Prototyp aplikacji +- Możliwość tworzenia grup z poziomu aplikacji webowej +- Spójna stylistycznie z prototypem aplikacja webowa +- Możliwość tworzenia przejazdów w aplikacji mobilnej +- Możliwość zapisu na istniejące przejazdy w aplikacji mobilnej +- Spójna stylistycznie z prototypem aplikacja mobilna +- Serwer REST API obsługujący obie aplikacje +- Zintegrowanie REST API z bazą danych + +#### 2. Oczekiwane + +- Wyświetlanie lokalizacji grup i punktów odbioru na mapie +- Wdrożenie aplikacji webowej na Azure +- Wdrożenie serwera REST API na Azure + +#### 3. Planowane + +- Zapraszanie użytkowników do dołączenia do grupy w aplikacji webowej +- Wyświetlanie informacji o grupach w aplikacji mobilnej + +### 7. Kryteria akceptacji projektu dla II semestru prac + +#### 1. Wymagane + +- Możliwość tworzenia kont użytkowników z poziomu aplikacji mobilnej i webowej +- Identity provider zapewniający dostęp do zasobów REST API +- Zarządzanie grupami (edycja danych grupy, dodawanie/usuwanie użytkowników należących do grupy, wyświetlanie przejazdów odbywających się w danej grupie) +- Możliwość wyświetlania danych o odbytych przejazdach w aplikacjach mobilnej i webowej +- Możliwość tworzenia przejazdów i zarządzania nimi w aplikacjach mobilnej i webowej +- Udostępnienie aplikacji mobilnej w Google Play +- Pozytywne zakończenie testów obciążeniowych REST API + +#### 2. Oczekiwane + +- Generowanie raportów podsumowujących przejazdy w danej grupie +- Udostępnienie aplikacji webowej na domenie carpool.com.pl +- Udostępnienie aplikacji mobilnej w sklepie Google Play + +#### 3. Planowane + +- Możliwość logowania się przy użyciu konta Google +- Podział kosztów na uczestników przejazdu wewnątrz systemu +- Identity provider ma umożliwić uwierzytelnianie przy użyciu zewnętrznych dostawców tożsamości (Google, Facebook) + +### 8. Organizacja pracy zespołu + +#### Zespół projektowy + +- Maciej Sobkowiak - Product Owner, Web Developer + + - Zarządzanie zadaniami w projekcie + - Projektowanie prototypu aplikacji webowej + - Implementacja aplikacji webowej + +- Michał Dulski – Backend Developer + + - Projektowanie architektury serwera REST API + - Implementacja aplikacji serwera REST API + - Implementacja identity provider’a + - Zarządzanie zasobami platformy chmurowej + - Kontakt z klientem + +- Norbert Litkowski – Web Developer + + - Projektowanie architektury aplikacji webowej + - Implementacja aplikacji webowej + - Integracja aplikacji webowej z platformą chmurową + +- Julian Kobryński – Mobile Developer + - Projektowanie prototypu aplikacji mobilnej + - Implementacja aplikacji mobilnej + - Projektowanie architektury aplikacji mobilnej + +#### Kontakt z klientem + +Organizujemy regularne spotkania z klientem, na których przedstawiamy postępy, które poczyniliśmy od ostatniego spotkania i dyskutujemy o planach na dalszy rozwój aplikacji. Prezentujemy również nasze pomysły na zmiany lub usprawnienia w aplikacji oraz ewentualne problemy, które napotkaliśmy. + +#### Cykl życia zdania w projekcie + +Każde zadanie po powstaniu umieszczane jest w kolumnie “To Do”, a następnie jest przypisywane do osoby, która będzie odpowiedzialna za jego zrealizowanie. Kiedy programista rozpoczyna prace nad zadaniem przenosi je do kolumny “In Progress”. Wykonane zadanie trafia do kolumny “QA” (Quality Assurance) i tworzony jest Pull Request. Inny członek zespołu przygląda się zmianom wprowadzonym w związku z danym zadaniem i jeśli uważa, że zostało wykonane prawidłowo, akceptuje Pull Request i kod trafia na główną gałąź w repozytorium, a zadanie do kolumny “Done”. + +#### Metodyka pracy + +Metodyka pracy, według której realizujemy projekt od samego początku to klasyczny Scrum. W początkowej fazie projektu wypełniliśmy backlog i oszacowaliśmy wszystkie zadania. Organizujemy dwutygodniowe sprinty, do których przydzielamy kilka zadań z backlogu. Zdecydowaliśmy się na tę metodykę, ponieważ została ona nam zasugerowana oraz dokładnie wytłumaczona przez promotora projektu i uważamy, że jest najbardziej skuteczna. + +#### Narzędzia wspomagające + +- Aplikacja webowa – przy każdym commicie na główną gałąź w repozytorium uruchamiany aplikacja jest budowana w chmurze Azure. Jeśli build zakończy się sukcesem, uruchamia się release pipeline, który ten build umieszcza w odpowiednim folderze na serwerze +- Aplikacja serwerowa – przy każdym commicie na główną gałąź repozytorium uruchamiany jest workflow w GitHub Actions, który najpierw buduje aplikację, a następnie publikuje aplikację webową w chmurze Azure oraz dodaje logi całej operacji w chmurze. + +### 9. Ryzyka projektowe + +- Określone ramy czasowe na stworzenie projektu okazały się nie wystarczające do całkowitego stworzenia aplikacji. +- Brak osób zainteresowanych korzystaniem z aplikacji –wymagane samodzielne korzystanie i testowanie aplikacji przez członków zespołu. +- Projekt jest o podwyższonym stopniu ryzyka ze względu na sytuację pandemiczną na świecie w związku z rozprzestrzenianiem się wirusa COVID-19. W związku z powyższym, testy z udziałem prawdziwych użytkowników mogą nie być możliwe do wykonania. +- Nieporozumienia w zespole dotyczące rozwiązań implementacyjnych, architektury, funkcjonalności lub używanych technologii +- Odejście członka zespołu - w zależności osoby, problem w ukończeniu składowej projektu. +- Brak doświadczenia w wdrażaniu aplikacji serwerowej na platformy chmurowe. +- Brak zaangażowania w projekt ze strony członków zespołu (niedostarczanie funkcjonalności na czas, brak komunikacji) +- Nagły brak wsparcia jednej z wykorzystywanych technologii lub narzędzia –konieczność zmiany narzędzi/technologii i implementacja funkcjonalności od zera w oparciu o nowe rozwiązanie albo modyfikacja obecnie istniejących funkcjonalności, aby działały z nowo wybraną technologią/narzędziem. + +### 10. Kamienie milowe + +#### Faza 1 (I semestr), do czerwca 2020: + +- Przygotowanie prototypu aplikacji mobilnej +- Wypełnienie backlogu w systemie Jira +- Rozpoczęcie prac programistycznych nad aplikacją serwerową, webową i mobilną +- Utworzenie zasobów do hostowania bazy danych, aplikacji webowej i aplikacji serwerowej na platformie Azure +- Ukończenie MVP projektu +- Wdrożenie MVP aplikacji serwerowej na platformę Azure + +#### Faza 2 (II semestr), do stycznia 2021: + +- Ukończenie zaplanowanych funkcjonalności w aplikacji mobilnej, webowej i serwerowej +- Utworzenie zasobów do hostowania identity provider’a na platformie azure +- Konfiguracja narzędzi ciągłej integracji (CI) dla aplikacji serwerowej REST API +- Konfiguracja narzędzi ciągłej integracji (CI) dla identity provider’a +- Konfiguracja narzędzi ciągłej integracji (CI) dla aplikacji webowej +- Opublikowanie aplikacji mobilnej w Play Store +- Stworzenie testów dla aplikacji webowej i serwerowej +- Opublikowanie aplikacji webowej w domenie internetowej From 5ee96888daeacd6d3f193558f404df18f036eb45 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Julian=20Kobry=C5=84ski?= Date: Sun, 29 Nov 2020 17:45:44 +0100 Subject: [PATCH 2/9] Subtitle typo fixed --- Zywica/car-pool/docs/project_requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md index f96daa2..3f65035 100644 --- a/Zywica/car-pool/docs/project_requirements.md +++ b/Zywica/car-pool/docs/project_requirements.md @@ -64,7 +64,7 @@ 32. Jako kierowca mogę usuwać pasażerów z przejazdu, 33. Jako kierowca mogę anulować przejazdy, -### 4. Lista wymagań funcjonalnych +### 4. Lista wymagań niefuncjonalnych 1. Internacjonalizacja – system musi posiadać lokalizowane zasoby tekstowe 2. Dostępność - aplikacja mobilna musi być dostępna dla systemów Android 4.4 (API 19+), ze względu na to, że wsparcie dla tej wersji wzwyż zapewnia obsługę większości użytkowników systemu Android From 9d1d9f08de63be16eac85bd499a20aa71f615c38 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Julian=20Kobry=C5=84ski?= Date: Sun, 29 Nov 2020 17:58:09 +0100 Subject: [PATCH 3/9] Repo and jira links added --- Zywica/car-pool/docs/project_requirements.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md index 3f65035..575c2ed 100644 --- a/Zywica/car-pool/docs/project_requirements.md +++ b/Zywica/car-pool/docs/project_requirements.md @@ -173,6 +173,10 @@ Metodyka pracy, według której realizujemy projekt od samego początku to klasy - Aplikacja webowa – przy każdym commicie na główną gałąź w repozytorium uruchamiany aplikacja jest budowana w chmurze Azure. Jeśli build zakończy się sukcesem, uruchamia się release pipeline, który ten build umieszcza w odpowiednim folderze na serwerze - Aplikacja serwerowa – przy każdym commicie na główną gałąź repozytorium uruchamiany jest workflow w GitHub Actions, który najpierw buduje aplikację, a następnie publikuje aplikację webową w chmurze Azure oraz dodaje logi całej operacji w chmurze. +[Repozytorium kodu](https://github.com/carpool-team/carpool) + +[Jira](https://jira.wmi.amu.edu.pl/secure/RapidBoard.jspa?rapidView=281&projectKey=CARP&view=planning.nodetail) + ### 9. Ryzyka projektowe - Określone ramy czasowe na stworzenie projektu okazały się nie wystarczające do całkowitego stworzenia aplikacji. From 0e21edc744489c1d68ddc67cbdef652627621e2e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20Dulski?= Date: Sun, 29 Nov 2020 18:05:00 +0100 Subject: [PATCH 4/9] =?UTF-8?q?Uaktualnienie=20kryteri=C3=B3w=20akceptacji?= =?UTF-8?q?=20semestr=202?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Zywica/car-pool/docs/project_requirements.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md index 575c2ed..688b54a 100644 --- a/Zywica/car-pool/docs/project_requirements.md +++ b/Zywica/car-pool/docs/project_requirements.md @@ -112,14 +112,17 @@ - Zarządzanie grupami (edycja danych grupy, dodawanie/usuwanie użytkowników należących do grupy, wyświetlanie przejazdów odbywających się w danej grupie) - Możliwość wyświetlania danych o odbytych przejazdach w aplikacjach mobilnej i webowej - Możliwość tworzenia przejazdów i zarządzania nimi w aplikacjach mobilnej i webowej -- Udostępnienie aplikacji mobilnej w Google Play - Pozytywne zakończenie testów obciążeniowych REST API +- Wymagania funkcjonalne: 1, 2, 3, 4, 6, 8, 11, 12, 13, 14, 17, 20, 21, 26, 27, 28, 31, 32, 33 #### 2. Oczekiwane - Generowanie raportów podsumowujących przejazdy w danej grupie - Udostępnienie aplikacji webowej na domenie carpool.com.pl - Udostępnienie aplikacji mobilnej w sklepie Google Play +- Testy akceptacyjne aplikacji mobilnej +- Testy akceptacyjne aplikacji webowej +- Wymagania funkcjonalne: 5, 7, 9, 10, 15, 17, 18, 19, 22, 23, 24, 25, 29, 30, 33 #### 3. Planowane From d75b6e0c5c97e10ee7d4523dd7564f3fbef7bdf1 Mon Sep 17 00:00:00 2001 From: Norbert Litkowski Date: Sun, 29 Nov 2020 18:27:24 +0100 Subject: [PATCH 5/9] Update: non-functional requirements --- Zywica/car-pool/docs/project_requirements.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md index 688b54a..68027ee 100644 --- a/Zywica/car-pool/docs/project_requirements.md +++ b/Zywica/car-pool/docs/project_requirements.md @@ -68,8 +68,8 @@ 1. Internacjonalizacja – system musi posiadać lokalizowane zasoby tekstowe 2. Dostępność - aplikacja mobilna musi być dostępna dla systemów Android 4.4 (API 19+), ze względu na to, że wsparcie dla tej wersji wzwyż zapewnia obsługę większości użytkowników systemu Android -3. Dostęp do repozytorium kodu -4. Aplikacja webowa dostępna dla przeglądarek mobilnych oraz desktopowych +3. Dostęp do repozytorium kodu - repozytorium kodu systemu będzie publicznie dostępne +4. Aplikacja webowa dostępna dla przeglądarek mobilnych oraz desktopowych - MS Edge, Firefox, Chrome, Safari, Opera 5. Autoryzacja tradycyjna w oparciu o JWT ### 5. Mierzalne wskaźniki wdrożeniowe @@ -176,9 +176,9 @@ Metodyka pracy, według której realizujemy projekt od samego początku to klasy - Aplikacja webowa – przy każdym commicie na główną gałąź w repozytorium uruchamiany aplikacja jest budowana w chmurze Azure. Jeśli build zakończy się sukcesem, uruchamia się release pipeline, który ten build umieszcza w odpowiednim folderze na serwerze - Aplikacja serwerowa – przy każdym commicie na główną gałąź repozytorium uruchamiany jest workflow w GitHub Actions, który najpierw buduje aplikację, a następnie publikuje aplikację webową w chmurze Azure oraz dodaje logi całej operacji w chmurze. -[Repozytorium kodu](https://github.com/carpool-team/carpool) +- [Repozytorium kodu](https://github.com/carpool-team/carpool) - korzystamy z publicznego repozytorium na platformie GitHub -[Jira](https://jira.wmi.amu.edu.pl/secure/RapidBoard.jspa?rapidView=281&projectKey=CARP&view=planning.nodetail) +- [Jira](https://jira.wmi.amu.edu.pl/secure/RapidBoard.jspa?rapidView=281&projectKey=CARP&view=planning.nodetail) - służy nam do planowania pracy w oparciu o metodykę Agile ### 9. Ryzyka projektowe From 207ad2cd10b8281702538c503cd81595fb62e0bf Mon Sep 17 00:00:00 2001 From: Norbert Litkowski Date: Sun, 29 Nov 2020 18:42:05 +0100 Subject: [PATCH 6/9] Add external links --- Zywica/car-pool/README.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Zywica/car-pool/README.md b/Zywica/car-pool/README.md index ca981b6..e7e0791 100644 --- a/Zywica/car-pool/README.md +++ b/Zywica/car-pool/README.md @@ -1,3 +1,7 @@ # CARPOOL -[Dokument wymagań projektu](docs/project_requirements.md) \ No newline at end of file +## Dokumenty +- [Dokument wymagań projektu](docs/project_requirements.md) +--- +## Linki zewnętrzne +- [GitHub]("https://github.com/carpool-team/carpool") \ No newline at end of file From 6a7b5778034cec617bc487f553c9ca66ec34a79a Mon Sep 17 00:00:00 2001 From: Norbert Litkowski Date: Sun, 29 Nov 2020 18:45:30 +0100 Subject: [PATCH 7/9] Update: project boundaries --- Zywica/car-pool/docs/project_requirements.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md index 68027ee..8dce19c 100644 --- a/Zywica/car-pool/docs/project_requirements.md +++ b/Zywica/car-pool/docs/project_requirements.md @@ -24,9 +24,11 @@ ### 2. Granice projektu -- Aplikacja w Apple AppStore – ze względu na ograniczenia budżetowe projektu, nie zdecydowaliśmy się na umieszczenie aplikacji w AppStore. +- Aplikacja mobilna w Apple AppStore – ze względu na ograniczenia budżetowe projektu, nie zdecydowaliśmy się na umieszczenie aplikacji w AppStore. Aplikacja będzie dostępna na platformie Google Play - Chat wewnątrz aplikacji – chcemy, aby aplikacja była jak najbardziej wyspecjalizowana. Ze względu, że użytkownicy korzystający z przejazdów wewnątrz jednej grupy najczęściej znają się, mają też prawdopodobnie kontakt w innej aplikacji do komunikacji tekstowej. - Przejazdy poza grupami – aplikacja skierowana jest do grup znajomych lub pracowników z jednej firmy. Zdecydowaliśmy, że przejazdy będą możliwe jedynie wewnątrz takich grup, gdyż do przejazdów między obcymi ludźmi istnieje wiele konkurencyjnych rozwiązań. +- Aplikacja nie przewiduje rejestracji korporacyjnych lub grupowych. Każdy z użytkowników tworzy konto samodzielnie. Może natomiast zostać po rejestracji dodany do firmowej grupy. +- System oferuje wyliczenia kosztów przejazdu na uczestnika. Nie będą natomiast obsługiwane rozliczenia wewnątrz aplikacji. ### 3. Lista wymagań funcjonalnych From 9d9da8576b775c967031d4128f86150c53f33766 Mon Sep 17 00:00:00 2001 From: Norbert Litkowski Date: Sun, 29 Nov 2020 19:54:01 +0100 Subject: [PATCH 8/9] Update: project boundaries --- Zywica/car-pool/docs/project_requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md index 8dce19c..dc79f0f 100644 --- a/Zywica/car-pool/docs/project_requirements.md +++ b/Zywica/car-pool/docs/project_requirements.md @@ -28,7 +28,7 @@ - Chat wewnątrz aplikacji – chcemy, aby aplikacja była jak najbardziej wyspecjalizowana. Ze względu, że użytkownicy korzystający z przejazdów wewnątrz jednej grupy najczęściej znają się, mają też prawdopodobnie kontakt w innej aplikacji do komunikacji tekstowej. - Przejazdy poza grupami – aplikacja skierowana jest do grup znajomych lub pracowników z jednej firmy. Zdecydowaliśmy, że przejazdy będą możliwe jedynie wewnątrz takich grup, gdyż do przejazdów między obcymi ludźmi istnieje wiele konkurencyjnych rozwiązań. - Aplikacja nie przewiduje rejestracji korporacyjnych lub grupowych. Każdy z użytkowników tworzy konto samodzielnie. Może natomiast zostać po rejestracji dodany do firmowej grupy. -- System oferuje wyliczenia kosztów przejazdu na uczestnika. Nie będą natomiast obsługiwane rozliczenia wewnątrz aplikacji. +- System nie będzie obsługiwał rozliczeń między uczestnikami przejazdów. Będą one z założenia dokonywane między zainteresowanymi, ze względu na to, że i tak są oni znajomymi w realnym świecie. ### 3. Lista wymagań funcjonalnych From e2cec278177b2e20b95f6f2cad9d14b244083ce8 Mon Sep 17 00:00:00 2001 From: Norbert Litkowski Date: Sun, 29 Nov 2020 20:09:39 +0100 Subject: [PATCH 9/9] Update: project boundaries --- Zywica/car-pool/docs/project_requirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Zywica/car-pool/docs/project_requirements.md b/Zywica/car-pool/docs/project_requirements.md index dc79f0f..ce0086d 100644 --- a/Zywica/car-pool/docs/project_requirements.md +++ b/Zywica/car-pool/docs/project_requirements.md @@ -28,7 +28,7 @@ - Chat wewnątrz aplikacji – chcemy, aby aplikacja była jak najbardziej wyspecjalizowana. Ze względu, że użytkownicy korzystający z przejazdów wewnątrz jednej grupy najczęściej znają się, mają też prawdopodobnie kontakt w innej aplikacji do komunikacji tekstowej. - Przejazdy poza grupami – aplikacja skierowana jest do grup znajomych lub pracowników z jednej firmy. Zdecydowaliśmy, że przejazdy będą możliwe jedynie wewnątrz takich grup, gdyż do przejazdów między obcymi ludźmi istnieje wiele konkurencyjnych rozwiązań. - Aplikacja nie przewiduje rejestracji korporacyjnych lub grupowych. Każdy z użytkowników tworzy konto samodzielnie. Może natomiast zostać po rejestracji dodany do firmowej grupy. -- System nie będzie obsługiwał rozliczeń między uczestnikami przejazdów. Będą one z założenia dokonywane między zainteresowanymi, ze względu na to, że i tak są oni znajomymi w realnym świecie. +- System nie będzie obsługiwał rozliczeń między uczestnikami przejazdów. Będą one z założenia dokonywane między zainteresowanymi. ### 3. Lista wymagań funcjonalnych