diff --git a/Dyczkowski/inteligentny-dom/wizja projektu IDOM.docx b/Dyczkowski/inteligentny-dom/wizja projektu IDOM.docx
new file mode 100644
index 0000000..c848b5d
Binary files /dev/null and b/Dyczkowski/inteligentny-dom/wizja projektu IDOM.docx differ
diff --git a/Dyczkowski/inteligentny-dom/wymagania projektowe IDOM.docx b/Dyczkowski/inteligentny-dom/wymagania projektowe IDOM.docx
new file mode 100644
index 0000000..043fc2b
Binary files /dev/null and b/Dyczkowski/inteligentny-dom/wymagania projektowe IDOM.docx differ
diff --git a/Dyczkowski/niezbednik-studenta/dokument_wizji_projektu.md b/Dyczkowski/niezbednik-studenta/dokument_wizji_projektu.md
new file mode 100644
index 0000000..f4de72b
--- /dev/null
+++ b/Dyczkowski/niezbednik-studenta/dokument_wizji_projektu.md
@@ -0,0 +1,128 @@
+# Dokument wizji projektu
+
+**Niezbędnik Studenta**
+
+**Autorzy: Anna Śniadek, Malwina Chudzińska, Adrian Pacholak, Phillip
+Ławniczak**
+
+**Data: 28.10.2020**
+
+## 1. Wprowadzenie
+
+Dokument dotyczy projektu realizowanego w ramach zespołowego projektu
+inżynierskiego. Niniejszy dokument służy przedstawieniu przeznaczenia
+tworzonego systemu, jego głównych cech i przyjętych założeń.
+
+## 2. Cel
+
+Celem projektu jest ułatwienie studentom Wydziału Matematyki i
+Informatyki organizacji studiów. Studenci poświęcają dużo czasu na
+znalezienie informacji i pomocy naukowych dotyczących danego przedmiotu,
+które umieszczone są na wielu różnych portalach. Chcemy ułatwić
+studentom ten proces zbierając wszystkie te materiały uporządkowane w
+jednym miejscu. Platforma ma stanowić wsparcie naukowe dla studentów
+porządkując pomoce naukowe dostępne w Internecie i gromadząc materiały
+udostępniane przez użytkowników oraz kreować wspólną przestrzeń dla
+studentów ułatwiając im integrację i jednocząc w problemach związanych
+ze studiami.
+
+## 3. Rynek
+
+Serwis „Niezbędnik Studenta" zbiera wszystkie pomoce naukowe,
+zgromadzone przez studentów oraz udostępniane przez prowadzących na
+różnych portalach, w jednym miejscu.
+
+Stanowi alternatywę dla grup tworzonych przez studentów w serwisie
+„Facebook", który zbiera wiele informacji o swoich użytkownikach
+zbędnych z punktu widzenia oferowanych funkcjonalności. Dodatkową
+przewagą Niezbędnika Studenta jest łatwość znajdywania interesujących
+nas grup oraz ich jednoznaczny podział na przedmioty, dzięki czemu posty
+oraz materiały trafiają wyłącznie do grupy zainteresowanych danym
+przedmiotem osób.
+
+Informacje i materiały niezbędne dla studentów WMI są umieszczane na
+wielu stronach. Nie ma natomiast miejsca w sieci zawierającego wskazówki
+odnośnie wyszukiwania tych informacji ani zbierającego odnośniki do
+stron, na których są one umieszczane.
+
+Dużym atutem platformy jest fakt, że jest ona tworzona przez studentów
+dla studentów, co oznacza, że rozwój aplikacji jest uzależniony od tej
+jednej społeczności i ma na niego bezpośredni wpływ.
+
+## 4. Opis produktu
+
+- Dostęp do serwisu dla studentów WMI po zalogowaniu w systemie
+ cas.amu.edu.pl
+
+- Lista prowadzących i odnośniki prowadzące do ich stron
+
+- Lista przedmiotów nauczanych na WMI
+
+- Możliwość dodania się do **grupy przedmiotowej** w celu dostępu do
+ **strony przedmiotu**
+
+ - możliwość udostępniania i korzystania z materiałów, notatek,
+ przykładowych zadań wraz z rozwiązaniami -- wszystkie materiały
+ dotyczące danego przedmiotu zostają zgromadzone w jednym miejscu
+
+ - forum dyskusyjne
+
+ - odnośniki do sylabusa i stron prowadzących
+
+ - lista prowadzących przedmiot
+
+- Użytkownicy mają możliwość inicjować wydarzenia w celu poszerzenia
+ grupy osób do wspólnej nauki lub znalezienia osób uczących się
+ samodzielnie na wydziale w celu integracji
+
+- Możliwość poszukiwania korepetytorów w osobnej zakładce
+
+- Możliwość tworzenia grup w celu znalezienia osób do zadań
+ grupowych/projektów
+
+- Tablica ogłoszeń dla wydziału, stanowiąca miejsce na eventy, kursy,
+ oferty pracy
+
+- Pliki dodawane przez studentów będą grupowane ze względu na przedmiot,
+będą filtrowane pod kątem nazwy, tagów, podział na wykład / ćwiczenia.
+Użytkownicy mogą zgłosić brak przedmiotu w bazie przedmiotów jako błąd
+wysyłany do administratorów. Administrator ma uprawnienia pozwalające
+na zarządzanie (dodawanie / usuwanie / edycję) danymi (przedmiotami,
+prowadzącymi).
+
+- Administrator może nadawać uprawnienia administratora innym
+użytkownikom.
+
+- Administrator ma uprawnienia pozwalające na usuwanie treści (postów,
+komentarzy, plików) oraz banowanie użytkowników (użytkownicy połączeni
+są z kontem w Usosie). Użytkownicy mogą zgłaszać treści, które uważają
+za nieodpowiednie. Komentarze do postów z kategorii zadania można
+oznaczać jako proponowane odpowiedzi.
+
+- Użytkownicy mogą oznaczać komentarze o takim charakterze jako
+poprawne/niepoprawne.
+
+## 5. Zakres i ograniczenia
+
+W pierwszej wersji systemu po zalogowaniu w systemie cas.amu.edu.pl
+dostępny będzie podstawowy interfejs startowy użytkownika, lista
+przedmiotów i ich strony. Użytkownicy będą mieli możliwość dołączenia do
+grup przedmiotowych, udostępniania oraz wglądu do materiałów, udziału w
+forum. Ograniczenia na rozmiar udostępnianych multimediów.
+
+- Aplikacja webowa
+
+- Responsywna aplikacja dostosowana do korzystania na urządzeniach
+ mobilnych
+
+- Technologie:
+
+ - Baza danych - MySQL
+
+ - Front-end - JavaScript, React
+
+ - Back-end - Java, Spring, Hibernate, JUnit
+
+- Ograniczenia rozmiar plików: 2 MB - jeden plik
+
+- Ograniczenia rozszerzeń - jpg/png, txt, pdf, docx, doc, odt
\ No newline at end of file
diff --git a/Dyczkowski/niezbednik-studenta/dokument_wymagan_projektowych.md b/Dyczkowski/niezbednik-studenta/dokument_wymagan_projektowych.md
new file mode 100644
index 0000000..0909265
--- /dev/null
+++ b/Dyczkowski/niezbednik-studenta/dokument_wymagan_projektowych.md
@@ -0,0 +1,334 @@
+# Dokument wymagań projektu
+
+**Nazwa projektu: Niezbędnik Studenta**
+**Autorzy: Adrian Pacholak, Ania Śniadek, Malwina Chudzińska, Phillip Ławniczak**
+**Data: 28.10.2020**
+
+
+
+## 0. Wersja dokumentu
+
+1.1 - 28.10.2020 - dostosowanie do nowego szablonu
+
+1.2 - 16.11.2020 - naniesienie poprawek wedłgu uwag promotora
+
+## 1. Elementy składowe projektu (produkty projektu)
+
+### Aplikacja webowa
+
+ - Zintegrowana z REST API - pobiera dane użytkowników, dane
+ zawarte w aplikacji
+
+ - Dostępna dla użytkowników posiadających konto w systemie USOS
+
+ - Zarządzana przez zespół administratorów składający się z
+ wybranych, zainteresowanych studentów
+
+ - Umożliwia zalogowanym użytkownikom
+
+ - korzystanie z forum
+
+ - dostęp do materiałów zamieszczanych przez użytkowników
+
+ - udostępnianie plików
+
+ - pozyskiwanie informacji dotyczących studiów
+
+ - Dokumentacja dotycząca oprogramowania aplikacji webowej
+
+ - Technologie:
+
+ - JavaScript
+
+ - React
+
+ - HTML5
+
+ - SASS
+
+ - CSS3
+
+ - webpack
+
+ - node.js
+
+ - Publikacja aplikacji:
+
+ - Dostęp do aplikacji na stronie internetowej
+
+ - Dostęp do repozytorium oraz dokumentacji aplikacji na serwisie
+ GitHub
+
+### Aplikacja serwerowa - REST API
+
+ - Udostępnia serwisy REST
+
+ - Służy do pobierania oraz zarządzania informacjami na temat
+ przedmiotów, prowadzących, wydarzeniach
+
+ - Służy do pobierania i dodawania materiałów naukowych
+
+ - Służy do zamieszczania postów i komentarzy na forum
+
+ - Używa relacyjnej bazy danych do przechowywania informacji o
+ użytkownikach, przedmiotach, prowadzących, ogłoszeniach,
+ wydarzeniach, postach oraz materiałów naukowych
+
+ - Zintegrowane z Systemem Usos w celu autoryzacji oraz pobierania
+ informacji o użytkownikach
+
+ - Dokumentacja dotycząca oprogramowania REST API
+
+ - Technologie: Java, Spring, Hibernate
+
+
+### Relacyjna baza danych:
+
+ - Baza stworzona na potrzeby przechowywania informacji o
+ użytkownikach, przedmiotach, prowadzących, wydarzeniach
+
+ - Technologie:
+
+ - Azure SQL
+
+### Repozytorium zawierające kod aplikacji
+
+ - GitHub
+
+### Elementy nieprogramistyczne
+
+- Tablica projektowa - Jira:
+
+ - Historia wymagań funkcjonalności (user stories)
+
+ - Historia zadań
+
+- Prototyp aplikacji webowej
+
+- Dokumentacja dotycząca oprogramowania REST API
+
+- Dokumentacja dotycząca oprogramowania aplikacji webowej
+
+- Dokumentacja architektury wykorzystanej w projekcie
+
+## 2. Granice projektu
+
+- Produkty nie zawarte:
+
+ - Aplikacja mobilna
+
+ - Aplikacja desktopowa
+
+- Funkcjonalności nie zawarte:
+
+ - Rejestracja użytkowników
+
+ - Dostęp dla użytkowników nie posiadających konta w systemie USOS
+
+ - Chat dla użytkowników aplikacji
+
+ - Możliwość edycji danych użytkownika
+
+## 3. Lista wymagań funkcjonalnych
+
+ - Aplikacja webowa:
+
+ - Autentykacja i autoryzacja użytkowników przez system
+
+ - Dostęp do informacji na temat przedmiotów i prowadzących
+
+ - Możliwość dołączania i opuszczania grup przedmiotowych
+
+ - Możliwość dodawania postów stanowiących ogłoszenia, oferty
+ pracy i oferty korepetycji na tablicy ogłoszeń
+
+ - Możliwość dodawania postów na forum dyskusyjnym, możliwość
+ komentowania postów i zamieszczania rozwiązań do zadań
+
+ - Możliwość udostępniania plików innym użytkownikom
+
+ - Możliwość inicjowania wydarzeń i dołączania do wydarzeń
+
+ - Możliwość dostosowania powiadomień przez użytkownika
+
+ - Możliwość dodawania przedmiotów, prowadzących, przydatnych linków przez użytkowników z uprawnieniami administratora
+
+ - Możliwość zarządzania ogłoszeniami, postami, komentarzami użytkowników przez administratorów
+
+ - Możliwość dawania użytkownikom uprawnień administratora przez administratorów
+
+ - Aplikacja serwerowa:
+
+ - Zintegrowana z Systemem USOS w celu autoryzacji oraz
+ pobierania informacji o użytkownikach
+
+ - Pobieranie oraz zarządzanie informacjami na temat
+ przedmiotów, prowadzących, wydarzeń, postów i komentarzy na
+ forum
+
+ - Pobieranie i dodawanie materiałów naukowych
+
+ - Połączona z relacyjną bazą danych zawierającą dane oraz
+ pliki
+
+## 4. Lista wymagań niefunkcjonalnych
+
+- Dokumentacja dotyczącą oprogramowania aplikacji webowej i REST API
+
+- Dostęp do repozytorium kodu
+
+- Aplikacja dostępna dla komputerów i urządzeń mobilnych
+
+- Użyte biblioteki na licencji open-source
+
+
+## 5. Mierzalne wskaźniki wdrożenia
+
+- Akceptacja funkcjonalna:
+
+ - Ukończenie zdefiniowanych funkcjonalności aplikacji webowej
+
+ - Dostęp do aplikacji dla wszystkich użytkowników systemu Usos
+
+ - Brak błędów utrudniających korzystanie z aplikacji
+
+- Akceptacja jakościowa:
+
+ - Zawieranie testów jednostkowe i sprawdzenie, czy spełniają swoje
+ zadanie
+
+ - Deploy wersji alpha aplikacji na serwer 30.11.2020, przeprowadzenie testów, sporządzenie raportu i naniesienie poprawek na jego podstawie
+
+ - Deploy wersji beta aplikacji 07.01.2021 na serwer, przeprowadzenie testów, sporządzenie raportu i naniesienie poprawek na jego podstawie
+
+ - Aplikacja posiada 40 aktywnych użytkowników
+
+## 6. Kryteria akceptacji projektu dla I semestru prac
+
+ - Dostarczenie prototypu projektu
+
+ - Aplikacja webowa zintegrowana z REST API oferująca
+ funkcjonalności:
+
+ - logowanie do serwisu
+
+ - podstawowy interfejs startowy użytkownika
+
+ - lista przedmiotów (grup przedmiotowych)
+
+ - możliwość dołączenia do grup przedmiotowych
+
+ - udział w forum
+
+ - Dokumentacja aplikacji webowej i serwerowej
+
+## 7. Kryteria akceptacji projektu dla II semestru prac
+
+ - Aplikacja webowa zintegrowana z REST API uzupełniona o
+ funkcjonalności:
+
+ - udostępnianie i pobieranie materiałów w postaci plików
+
+ - tworzenie i dołączanie do wydarzeń
+
+ - dodawanie ogłoszeń
+
+ - powiadomienia i customizacja powiadomień
+
+ - edycja zawartości strony przez admistratorów
+
+ - zarządzanie treścią i użytkownikami przez administratorów
+
+ - Anglojęzyczna wersja aplikacji
+
+ - Dokumentacja aplikacji webowej i serwerowej
+
+ - System pozytywnie przeszedł testy obciążeniowe, testy alpha i beta
+
+
+## 8. Organizacja pracy zespołu
+
+- Strona klienta:
+
+ - Studenci wydziału Matematyki i Informatyki na kierunku
+ Matematyka i Informatyka
+
+- Strona zespołu projektowego
+
+ - Malwina Chudzińska
+
+ - Product Owner
+
+ - Implementacja aplikacji webowej
+
+ - Tworzenie prototypu interfejsu aplikacji
+
+ - Anna Śniadek
+
+ - Implementacja aplikacji webowej
+
+ - Projekt szaty graficznej aplikacji
+
+ - Scrum Master
+
+ - Adrian Pacholak
+
+ - Implementacja serwisów REST dla aplikacji
+
+ - Projektowanie bazy danych
+
+ - Phillip Ławniczak
+
+ - Tworzenie prototypu interfejsu aplikacji
+
+ - Implementacja aplikacji webowej
+
+
+## 9. Ryzyka projektowe
+
+- Odejście członka implementującego aplikację webową lub stronę
+ serwerową - trudności w ukończeniu aplikacji
+
+- Określone ramy czasowe, semestry, na stworzenie produktu - ryzyko
+ nieukończenia w czasie
+
+- Nieporozumienia w zespole dotyczące rozwiązań implementacyjnych,
+ architektury, funkcjonalności lub używanych technologii
+
+- Konieczność poświęcenia czasu na dopełnienie wiedzy dotyczącej
+ stosowanych technologii
+
+- Brak odpowiedniego zaangażowania w projekcie ze strony zespołu lub
+ wybranych członków zespołu
+
+- Przechowywanie danych o użytkownikach
+
+- Brak zainteresowania aplikacją ze strony użytkowników
+
+- Brak chętnych do pełnienia roli administratora
+
+- Zarządzanie nieodpowiednimi treściami
+
+- Problemy techniczne po stronie systemu Usos
+
+## 10. Kamienie milowe
+
+- Logowanie przez cas.amu.edu.pl
+
+- Dostarczenie użytkownikowi funkcjonalności dołączania do grup
+ przedmiotowych
+
+- Dostarczenie użytkownikowi funkcjonalności dodawania kontentu do
+ portalu
+
+- Wdrożenie aplikacji serwerowej na serwerze
+
+- Aplikacja posiadająca dokumentację
+
+- Aplikacja dostępna na stronie internetowej
+
+- Aplikacja posiadająca użytkowników
+
+- Aplikacja uzupełniona danymi dotyczącymi przedmiotów, prowadzących,
+ materiałami naukowymi
+
\ No newline at end of file
diff --git a/Dyczkowski/techniki-dentystyczne/wymagania projektowe.docx b/Dyczkowski/techniki-dentystyczne/wymagania projektowe.docx
new file mode 100644
index 0000000..14f4c86
Binary files /dev/null and b/Dyczkowski/techniki-dentystyczne/wymagania projektowe.docx differ
diff --git a/Witkowski/aport-me/dokument_wymagan_projektowych.md b/Witkowski/aport-me/dokument_wymagan_projektowych.md
new file mode 100644
index 0000000..0e7e6e5
--- /dev/null
+++ b/Witkowski/aport-me/dokument_wymagan_projektowych.md
@@ -0,0 +1,215 @@
+# Dokument wymagań projektowych
+
+## Nazwa projektu: **AportMe**
+
+## Autorzy: _Dawid Wietrzych, Jacek Krakowski, Matusz Lesiecki, Wojciech Jarmosz_
+
+## Data: 13.11.2020r.
+
+## **0. Wersje dokumentu**
+
+| Wersja | Data | Zmiany |
+| :----: | :----------: | :---------------------------------------: |
+| 1.0 | 13.11.2020r. | Utworzenie dokumentu wymagań projektowych |
+
+## **1. Elementy składowe projektu (produkty projektu)**
+
+#### **Programistyczne:**
+
+- Aplikacja webowa oparta o framework Vue.js.
+- Aplikacja mobilna dla systemów Android 16+ i iOS 9+.
+- Instancja serwera bazodanowego oparta o silnik PostgreSQL.
+- Aplikacja serwerowa w języku Java oparta o framework Spring Boot.
+
+#### **Nieprogramistyczne:**
+
+- Zbieranie wymagań projektowych przy współpracy z przedstawicielem fundacji.
+- Stworzenie dokumentu wizji projektu.
+- Dokument wymagań projektowych.
+- Dokumentacja techniczna.
+- Diagram UML, obrazujący schemat bazy danych.
+- Ankieta użyteczności/wrażeń użytkownika projektu.
+
+## **2. Granice projektu**
+
+- **Dlaczego aplikacja nie zostanie udostępniona w Apple Store?**
+ Produkt na urządzenia marki Apple, wymagają posiadania sprzętu tego producenta. Zespół nie dysponuje obecnie wystarczającą ilością sprzętu umożliwiającą przetestowanie aplikacji w stopniu umożliwiającym jej bezpieczne i pewne wdrożenie. Projekt zakłada wydanie wersji oraz rozwój na platformę iOS w przypadku sukcesu aplikacji na platformę Android. Cały proces wiąże się z kosztami, których w obecnej chwili nie jesteśmy w stanie pokryć.
+
+- **Dlaczego funkcjonalność płatności nie została wdrożona?**
+ Obecnie większość systemów do płatności online wymaga przesłania pieniędzy na nasze konto, a my bezpośrednio przelewamy na konto fundacji. Obecnie posiadamy za mało wiedzy żeby móc działać w tym zakresie w pełni legalnie. Rozważamy założenie fundacji która pozwoli nam na legalne obsługiwanie tej funkcjonalności, bez ryzyka problem ze strony Urzędu Skarbowego.
+
+- **Dlaczego konta dla fundacji są tworzone na bazie po stronie naszego zespołu?**
+ Nasza aplikacja zakłada rejestrację fundacji za pośrednictwem naszego zespołu, ze względów bezpieczeństwa i ograniczenia do minimum podszywania się zwykłych użytkowników pod konta fundacji. Po naszej stronie leży sprawdzenie wiarygodności fundacji, która zechce u nas założyć konto i takowe konto przekazać z hasłem tymczasowym, które potem fundacja może zmienić w panelu użytkownika.
+
+- **Dlaczego nie zdecydowano się na integrację z zewnętrznymi systemami (np. systemami autoryzacji)?**
+ Nie zdecydowaliśmy się na wykorzystanie usługi Keycloak (rozważaliśmy taką opcję autoryzacji użytkowników) z powodu braku doświadczenia w jej wykorzystaniu. Braliśmy również pod uwagę zintegrowanie aplikacji z usługą Firebase, jednak wymagał on zbyt dużej (jak nie całkowitej) integracji naszego projektu z usługami Google’a czego nie chcieliśmy robić.
+
+- **Dlaczego niektóre funkcjonalności nie zostały (lub nie zostaną) wdrożone, chociaż nie wymagają istotnego nakładu prac?**
+ Staramy się na ten moment wypuścić produkt spełniający minimalne wymagania fundacji i użytkowników (model MVP). Umożliwi to wcześniejsze zebranie opinii na temat przyszłych funkcjonalności projektu i dalszego rozwoju. Pozwoli też na uniknięcie wprowadzania niepotrzebnych modułów. Projekt wymaga również większego nakładu prac (z racji używanych technologii i platform - mobilna oraz webowa).
+
+## **3. Lista wymagań funkcjonalnych**
+
+#### **Aplikacja mobilna**
+
+- Użytkownik loguje się do aplikacji mobilnej.
+- Użytkownik rejestruje się loguje do aplikacji mobilnej.
+- Użytkownik może przejść do aplikacji bez autoryzacji.
+- Użytkownik może wysłać email z linkiem do resetu hasła.
+- Użytkownik przegląda listę zwierząt dostępnych w systemie.
+- Użytkownik przegląda listę fundacji dostępnych w systemie.
+- Użytkownik może przejrzeć szczegółowy opis zwierzęcia.
+- Użytkownik może skontaktować się z fundacją za pośrednictwem telefonu lub maila (przekierowanie do dedykowanej aplikacji).
+- Zalogowany użytkownik może dodać zwierzęta do ulubionych.
+- Zalogowany użytkownik może dodać fundacje do ulubionych.
+- Zalogowany użytkownik może przeglądać polubione zwierzęta i fundacje.
+- Zalogowany użytkownik może się wylogować.
+- Zalogowany użytkownik może utworzyć ankietę adopcyjną.
+- Zalogowany użytkownik może przeglądać swoje ankiety adopcyjne.
+- Możliwość filtrowania, wyszukiwania określonych zwierząt według kryteriów określonych przez fundacje..
+- Możliwość wsparcia finansowego zwierząt/schronisk.
+- Możliwość wyrażenia chęci adopcji wybranego zwierzaka.
+- Możliwość zmiany hasła.
+- Dodawanie do polubionych fundacji i zwierząt.
+- Obliczanie odległości od schroniska na podstawie lokalizacji użytkownika.
+- Optymalizacja pobierania wpisów.
+- Autoryzacja.
+
+#### **Aplikacja webowa**
+
+- Pozwala zalogować się fundacji.
+- Pozwala zarządzać ogłoszeniami zwierząt fundacji.
+- Pozwala aktualizować dane fundacji.
+- Fundacja ma wgląd w ankiety adopcyjne.
+- Dodanie kreatora ankiet, które użytkownicy będą wypełniać w celu złożenia wniosku o adopcję danego zwierzęcia.
+- Dodanie możliwości przeglądania nadesłanych wniosków z poziomu aplikacji.
+- Dodanie małego workflow obiegu wniosków (zaakceptowany/odrzucony etc.).
+- Przystosowanie aplikacji webowej również dla urządzeń mobilnych (breakpointy).
+- Podpięcie api związanego z logowaniem zmianą hasła użytkowników.
+- Panel umożliwiający prezentację płatności, które zostały przekazane na rzecz zwierząt z określonej fundacji.
+- Zrealizowanie poprawek przekazanych przez komisję na pierwszej obronie projektu.
+
+#### **Serwer**
+
+- Wdrożenie modułu płatności umożliwiającego datkowanie zwierząt.
+- Tworzenie logiki biznesowej do ankiet adopcyjnych.
+- Pokrycie testami.
+- Autoryzacja.
+
+## **4. Lista wymagań niefunkcjonalnych**
+
+- Aplikacja webowa, powinna posiadać interfejs wielojęzyczny (język angielski oraz polski).
+- Maksymalny czas ładowania się aplikacji webowej powinien wynosić maksymalnie 10s.
+- Aplikacja webowa będzie wspierać wszystkie najpopularniejsze przeglądarki (tj. Google Chrome, Mozilla Firefox, Opera, Microsoft Edge, Safari) z wyłączeniem Internet Explorer z racji zapowiedzianego przez firmę Microsoft braku dalszego wsparcia oraz ewentualnych problemów z wczytywaniem paczek npm.
+
+## **5. Mierzalne wskaźniki wdrożeniowe**
+
+- Aplikacja mobilna zostanie wdrożona w sklepie Google Play.
+- System do zarządzania ogłoszeniami zwierząt dla fundacji zostanie wdrożony na domenie publicznej. Ogłoszenia zostaną dodane przez przynajmniej jedną współpracującą fundację.
+- Pod koniec pierwszego semestru wersja testowa zostanie przedstawiona współpracującej fundacji oraz zostaną zebrane informacje zwrotne o tym co należy poprawić.
+- Pod koniec drugiego semestru system zostanie przedstawiony potencjalnym użytkownikom względem zebrania informacji o konwersji aplikacji.
+- System backendowy zostanie wdrożony na dedykowany serwer.
+
+## **6. Kryteria akceptacji projektu dla I semestru prac**
+
+#### **Aplikacja mobilna:**
+
+- Główna lista zwierzaków do adopcji i podgląd profilu wraz ze szczegółami o danych zwierzęciu. - **wymagane**
+- Lista fundacji występująca w aplikacji i podgląd szczegółowych informacji. - **wymagane**
+- Ekrany logowania i rejestracji użytkowników. - **oczekiwane**
+- Zakładka “ulubione” z fundacjami i zwierzętami. - **planowane**
+- Ekran profilu użytkownika. - **oczekiwane**
+- Intro slider. - **oczekiwane**
+
+#### **Aplikacja webowa:**
+
+- Stworzenie interfejsu zarządzania profilami tj. główna lista dodanych profili, a także ich podgląd oraz edycja (CRUD). - **wymagane**
+- Stworzenie panelu edycji profilu fundacji oraz ustawień konta. - **wymagane**
+- Wdrożenie możliwości kadrowania oraz dodawania zdjęć do profili zwierząt. - **oczekiwane**
+- Stworzenie podstron: “Strony głównej”, “O nas”, “Kontakt”. - **oczekiwane**
+- Stworzenie interfejsu logowania użytkowników. - **oczekiwane**
+
+#### **Aplikacja backendowa:**
+
+- Stworzenie encji ORM fundacji, użytkownika, profili zwierząt oraz danych użytkownika. - **wymagane**
+- Stworzenie REST API dla profili, danych użytkownika, a także profili fundacji. - **wymagane**
+- Stworzenie podstawowego modelu autoryzacji użytkowników. - **wymagane**
+- Zgodność aplikacji z polityką RODO. - **wymagane**
+- Testy obciążeniowe aplikacji. - **oczekiwane**
+ - zdajemy sobie sprawę z ryzyka dużej liczebności użytkowników naszej aplikacji, co za tym idzie ze zwiększonego “ruchu” i obciążenia serwera. Dołożymy wszelkich starań aby aplikacja była jak najbardziej wydajna w stosunku do liczby korzystających z niej osób.
+
+## **7. Kryteria akceptacji projektu dla II semestru prac**
+
+#### **Aplikacja mobilna:**
+
+- Możliwość filtrowania, wyszukiwania określonych zwierząt według kryteriów określonych przez fundacje. - **wymagane**
+- Możliwość wsparcia finansowego zwierząt/schronisk. - **planowane**
+- Możliwość wyrażenia chęci adopcji wybranego zwierzaka. - **wymagane**
+- Dodawanie do polubionych fundacji i zwierząt. - **oczekiwane**
+- Możliwość zmiany hasła. - **wymagane**
+- Obliczanie odległości od schroniska na podstawie lokalizacji użytkownika. - **planowane**
+- Optymalizacja pobierania wpisów. - **wymagane**
+- Autoryzacja. - **wymagane**
+
+#### **Aplikacja webowa:**
+
+- Dodanie kreatora ankiet, które użytkownicy będą wypełniać w celu złożenia wniosku o adopcję danego zwierzęcia. - **wymagane**
+- Dodanie możliwości przeglądania nadesłanych wniosków z poziomu aplikacji. - **wymagane**
+- Dodanie małego workflow obiegu wniosków (zaakceptowany/odrzucony etc.). - **oczekiwane**
+- Przystosowanie aplikacji webowej również dla urządzeń mobilnych (breakpointy). - **oczekiwane**
+- Podpięcie api związanego z logowaniem zmianą hasła użytkowników. - **wymagane**
+- Panel umożliwiający prezentację płatności, które zostały przekazane na rzecz zwierząt z określonej fundacji. - **planowane**
+- Zrealizowanie poprawek przekazanych przez komisję na pierwszej obronie projektu. - **wymagane**
+
+#### **Aplikacja backendowa:**
+
+- Wdrożenie modułu płatności umożliwiającego datkowanie zwierząt. - **planowane**
+- Pokrycie testami. - **oczekiwane**
+- Tworzenie logiki biznesowej do ankiet adopcyjnych. - **wymagane**
+- Autoryzacja. - **wymagane**
+
+## **8. Organizacja pracy zespołu**
+
+- Komunikacją z klientem zajmował się Mateusz Lesiecki, polegała ona na wykonywaniu wideokonferencji z klientem oraz zespołem AportMe po ukończonym sprincie i prezentacji aktualnego stanu projektu. Klient oceniał funkcje projektu oraz ich UX. Głównym interesariuszem projektu jest TTB Poznań - fundacja zajmująca się pomocą Bulterierom. Fundacja ta jest również przyszłym klientem korzystającym z aplikacji w roli fundacji/schroniska.
+ Podział zespołu ze względu na technologię przedstawia się następująco:
+- _Dawid Wietrzych_ - Frontend
+- _Wojciech Jarmosz_ - Frontend, Backend
+- _Mateusz Lesiecki_ - Backend, Mobile
+- _Jacek Krakowski_ - Backend, Mobile
+
+- Z racji chęci ścisłej współpracy z fundacją pod kątem użyteczności funkcji w aplikacji, zdecydowaliśmy się na metodykę zwinną, opartą o kilkutygodniowe sprinty, po których następowała konsultacja z klientem.
+- Jakie narzędzia wspomagające prace projektowe wykorzystuje zespół? W jaki sposób zespół zarządza kodami źródłowymi? W jaki sposób zarządza przebiegiem projektu? Czy wykorzystuje się narzędzia CI/CD? Czy stosowane narzędzia są ze sobą zintegrowane? Jeśli tak, to w jaki sposób?
+ **Narzędzia:** Git, Github, Jira, Postman, Swagger, ESlint + Prettier, Husky
+ **Zarządzanie kodem:** Wzajemny Code Review członków zespołu
+ **Ci\CD:** Brak
+ **Czy zintegrowane:** Tak, w postaci zdalnego repozytorium, korzystanie z jego funkcji (PR,CR)
+- Cykl życia oprogramowania zaczyna się od dodania zadania do backlogu, programista przypisuje się do zadania, a następnie przystępuje do jego realizacji, każda nowa funkcjonalność jest tworzona na osobnym branchu na gicie. Co 3 dni odbywają się spotkania (na wzór daily) gdzie omawiamy problemy i ewentualne ich rozwiązania. Po skończeniu pracy nad funkcjonalnością, wystawiany jest pull request, a następnie przeprowadzanie Code Review. Po poprawkach w Code Review branch jest mergowany do głównego brancha - _develop_.
+
+## **9. Ryzyka projektowe**
+
+Z uwagi na złożoność niektórych funkcjonalności i ograniczenia technologiczne/sprzętowe, wdrożenie ich może okazać się niemożliwe lub znacznie utrudnione, do takich elementów należą:
+
+- Obsługa datkowania fundacji - rozwiązanie aspektów prawnych i bezpieczeństwa danych.
+- Obsługa lokalizacji użytkownika względem lokalizacji schroniska
+- Wdrożenie aplikacji mobilnej na system IOS.
+- Odpowiednie przetestowanie aplikacji pod kątem wydajności i bezpieczeństwa.
+- Integracja z systemami obsługi płatności - Dotpay, Przelewy24, lub innym.
+
+## **10. Kamienie milowe**
+
+#### **Listopad**
+
+- Stworzenie systemu do zarządzania ogłoszeniami przez fundacje.
+- Stworzenie kreatora ankiet adopcyjnych.
+- Stworzenie końcowego szkieletu REST API.
+
+#### **Grudzień**
+
+- Usprawnienie modułu Autoryzacji
+- Dodanie możliwości wypełnienia ankiety w aplikacji mobilnej.
+- Próba deploy'u aplikacji na serwer oraz wystawienie aplikacji mobilnej w Google Play
+
+#### **Styczeń**
+
+- Stworzenie wszystkich ekranów w aplikacji mobilnej
+- Testy i ewentualne poprawki REST API
+- Testy użytkowe aplikacji webowej i mobilnej
diff --git a/Witkowski/be-my-gym/README.md b/Witkowski/be-my-gym/README.md
new file mode 100644
index 0000000..385a3a5
--- /dev/null
+++ b/Witkowski/be-my-gym/README.md
@@ -0,0 +1,150 @@
+# **Project requirements document**
+
+**Project name: BeMyGym**
+
+**Authors: Hanna Hrytsko, Angelika Lach**
+
+**Date: 13.11.2020**
+
+**0. Document versions**
+
+| Version | Date (DD.MM.YYYY) | Comments |
+| --- | --- | --- |
+| 1.0 | 13.11.2020 | First version |
+
+**1. Project components (project products)**
+
+Programming elements:
+
+ - Website application (React application)
+ - Node server application
+ - Firebase database
+
+Non-programming elements:
+
+ - Project requirements document
+ - Development documentation
+ - License and ownership rights
+ - Project vision document
+ - Drafts of design made with Figma
+ - Report on usability tests performed
+
+**2. Project boundaries**
+
+ - We have decided to create a web application and not mobile app because it is more convenient: large screen, no need to download anything, no need to have a separate app for booking gyms only. The web application is possible to open in a mobile browser as well.
+
+ - We do not have a chat bot because it is not necessary, everyone can send a contact form. Chat bots are also rarely used from our experience.
+
+ - We haven't done a full text search because in firebase this option is not free. It also seems redundant as we want to implement searching and filtering gyms themselves.
+
+ - We have decided not to include any payment options. This is due to the fact that it would be very hard to unify the payment options across all gym owners (private, public e.g. a school). There is also a preference for a payment in person in situations like that.
+
+ - There will be a limit on how many photos can be uploaded per gym. Their size will also be limited. This is due to the database limitations.
+
+ - We have decided to focus on Poznań only. We may expand in the future, but for now it is way easier and safer or us to limit ourselves to one city.
+
+ - There will be no sharing on social media. These are very rarely used.
+
+**3. List of functional requirements**
+
+| **Item** | **Description** |
+| --- | --- |
+| Logging in/Signing up | There are separate pages for signing in and signing up. They are authenticated with firebase. There exists the ability to sign up traditionally – with an email and password – or with Facebook/Google account. |
+| Contact form | Available from the link in the footer, lets users contact the admins. |
+| Navbar | Contains buttons redirecting to the 'add gym' and login pages. After signing in there are 'log out' and user profile pages. Admins can access the admin page. Sticked to the top. |
+| User profile | Displays user data and managed gyms (if any). Displays user favourites gyms. |
+| Admin page | From there admins can update gyms' info downloaded from the Poznań API as well as manage reservations. |
+| Gym profile | Displays all the available gym information along with a map depicting gym's location, a calendar that shows the unavailable time slots and allows users to choose the date(s) and time for the booking, and a booking form. For admin and gyms owner there is an ability to change gym data. |
+| Gallery | Displays pictures uploaded by the gym's owner in form of a slider. |
+| All gyms listings | This page shows all the gyms in a shortened, paginated form. It is possible to search and/or filter gyms. Every listing has a button redirecting to the proper gym profile with full information (-> gym profile). For admin and gym owner there is an ability to delete a gym. |
+| Searching/filtering | It is possible to search a gym by name or filter gyms by e.g. number of changing rooms. |
+| Ratings | Every gym has a rating which is a weighted score from all the ones given to it by users who had booked it before. |
+| Adding new gym | This page contains a form which needs to be filled out in order to add a new gym to the database (after it is accepted by the admins). There is also a photo submit. Only available to registered users. |
+| Booking | Contains a form that requires user's data and a calendar where time and date need to be chosen. |
+| Reservation acceptance | Bookings have to be accepted or rejected by gym owners. |
+| FAQ page | Page with frequently asked questions – explanations about e.g. how to become a gym owner. |
+| Footer | Contains buttons redirecting to FAQ page and contact form. Sticked to the bottom. |
+
+User story: web application where it is possible to find a venue and reserve it for a period of time. Existing gyms are uploaded from Poznań API and the owners of the gyms can add new gyms and edit them.
+
+**4. List of non-functional requirements**
+
+| **Item** | **Description** |
+| --- | --- |
+| Availability | Users can book gyms on the website throughout the week at any time during the day. |
+| Localization | Site is in Polish. The only currency displayed is PLN. |
+| Portability | Supported browsers: Firefox 82.0.2, Chrome 86.0.4240.111 and later versions of the browsers. |
+
+**5. Measurable implementation indicators**
+
+ - The system will be available in the domain znajdzsale.pl, service will be connected with a firebase database.
+ - System gather data from Poznan API and present it to user.
+ - The system will be available to users by the 18.01.2021.
+ - After usability tests regarding to the user comments possible changes will be made.
+ - The last version of the system will be implemented on the WMI server.
+
+**6. Project acceptance criteria for the second semester of work**
+
+ - **Required:**
+ - It will be possible to edit gym's data: its name, address, number of audience seats if any, etc. Editing gym data will be available to admins and to gym owners (users that have registered and have the ownership of the gym).
+ - It will be possible to add, edit and delete reservations. Gym owners will be able to accept or reject a reservation – a reservation with pending acceptance will have this status reflected on the calendar. Accepted reservations will also be marked as 'accepted'. Rejected reservations will disappear. Guests and registered users alike will be able to make a reservation but also cancel it by sending a mailed notification to gym owner. Admins will have the ability to do all of the above.
+ - We plan to implement guest/user/admin views, each with different functions. Guests are only allowed to make or cancel a reservation. Registered users can have the ownership of the gym, thus be able to edit its information and accept/reject reservations. Admin have access to all functionalities.
+ - Searching by name will be expanded into filtering and searching. It will be possible to filter the searched gyms by e.g. the number of changing rooms.
+ - **Expected:**
+ - It will be possible to rate a gym after an accepted booking has happened. It will be a weighted score that reflects users' experience with the gym owner and gym's quality (does it comply with the listing? were there all the amenities mentioned? etc).
+ - Every gym will have its own gallery – a slider containing all the photos uploaded by the gym owner.
+ - **Planned:**
+ - It will be possible to 'favourite' a gym in case the user had a pleasant experience before and may book it again in the future – it will be possible to see all of user's favourites.
+ - Implement the rating system along with the score display.
+ - There will be a notification system implemented. If a gym is booked during the time that the user would have liked to book it, they will be notified if the slot/slots become free. The gym owner will be notified when somebody books their gym.
+ - FAQ page.
+
+**7. Organization of team work**
+
+**Scope of work for** :
+
+Angelika Lach: documentation, design, logging/registering, creating firebase database, pagination, support form, navbar, api, gym profile, adding gyms form, booking form, jira management (tasks, sprints); planned: guest/user/admin views, ratings, favourites, notifications, testing, deploying.
+
+Hanna Hrytsko: documentation, calendar, maps, searching avenues by name, user profile, reservation management page, admin page, gym profile, gym management; planned: gallery, filtering, faq, gym/booking management, testing, deploying.
+
+We plan to divide all of the mail points of the product (database, user/gym profile, authorization, authentication, gym gallery, map, calendar, ratings etc.) into smaller subtasks and then divide these subtasks among ourselves.
+
+ - Design is created by Angelika Lach.
+ - Communication is done via messenger.
+ - We use Scrum-alike methodology on Jira. It is very popular methodology, so we haven't had any doubts to use it. The decision was unanimous.
+ - There are sprints which last about a month and cover the tasks we want to complete in the nearest future. If something has not been achieved, it is moved to the next sprint.
+ - There are small tasks like a feature fix or placement changes and bigger tasks – epics – which are divided into even smaller components. Usually, one person takes care of all the tasks in the epic.
+ - The source code is on GitHub. Everyone has a local copy of project on their machine and after making changes commits are added to git and the changes pushed to GitHub.
+ - Changes are tested by the other person. After the tests were deemed successful, a task is considered complete and pushed from the dev branch to the master.
+ - Below are plots from GitHub and Jira:
+
+|  |  |
+| --- | --- |
+
+**8. Project risks**
+
+ - The implementation infrastructure Firebase has some paid features (like full text search, log in page build in user app), so we couldn't use it in the project.
+ - It may be necessary to transfer the project to the Faculty infrastructure, which will increase the workload.
+ - The lack of potential customers using our ready-made web application.
+ - Imperfections in the web application - developers don't have enough experience.
+ - Some data in Poznań API is stored not in a full form, for example some description fields contain "..." instead of a single period at the end of the sentence.
+
+**9. Milestones**
+
+**Second semester**
+
+| **Period** | **Description** |
+| --- | --- |
+| Late October – sprint I | planning |
+| November - sprint I | reservation management: implement the ability to edit/delete reservations|
+||gym management: implement the ability to edit gym's data|
+||guest/user/admin views: make three separate views with different available features/some of the features locked|
+||FAQ page: page with frequently asked questions |
+| Late November - December – sprint II | gallery: make a gallery for each of the gyms in form of a slider|
+||ratings: implement the rating system along with the score display|
+||favourite: implement adding gyms to favourites|
+||filtering: implement the ability to filter gyms by features e.g. the number of changing rooms|
+||notifications: implement the notification system which will alert users when a slot they wanted to book is free |
+| December | testing |
+| December - January | deploying application |
+| January | application is ready to use |
diff --git a/Witkowski/be-my-gym/github.png b/Witkowski/be-my-gym/github.png
new file mode 100644
index 0000000..ef3ec89
Binary files /dev/null and b/Witkowski/be-my-gym/github.png differ
diff --git a/Witkowski/be-my-gym/jira.png b/Witkowski/be-my-gym/jira.png
new file mode 100644
index 0000000..5f12ed5
Binary files /dev/null and b/Witkowski/be-my-gym/jira.png differ
diff --git a/Witkowski/by-my-gym/README.md b/Witkowski/by-my-gym/README.md
deleted file mode 100644
index db28249..0000000
--- a/Witkowski/by-my-gym/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Instrukcja
-
-W tym katalogu należy umieścić dokumenty wizji systemu oraz wymagań projektowych zgodnie z szablonami.
diff --git a/Witkowski/conference-page/dokument-wymagan-projektowych-2a.md b/Witkowski/conference-page/dokument-wymagan-projektowych-2a.md
new file mode 100644
index 0000000..93b8098
--- /dev/null
+++ b/Witkowski/conference-page/dokument-wymagan-projektowych-2a.md
@@ -0,0 +1,290 @@
+# Dokument wymagań projektowych
+
+## Dokument wizji dla projektu Conference Web
+
+### Autorzy: Konrad Pierzyński, Michał Starski, Maciej Więcek, Patrycja Łaźna
+
+### Data: 14.11.2020r
+
+-----
+
+#### **0. Wersje dokumentu**
+
+14.11.2020r - stworzenie dokumentu
+
+18.11.2020r - poprawki według zaleceń prowadzącego
+
+19.11.2020r - uzupełnienie dokumentu o elementy związane z wtyczką
+
+-----
+
+#### **1. Elementy składowe projektu**
+
+* aplikacja webowa w języku JavaScript oparta o framework React;
+
+* aplikacja serwerowa w języku Java oparta o framework Spring;
+
+* instancja serwera bazy danych oparta o silnik PostgreSQL;
+
+* wtyczka do edycji wyglądu strony działająca w przeglądarce;
+
+* prototyp wtyczki wykonany w Adobe XD;
+
+* dokumenty: "wizja projektu", "kryteria akceptacji", "dokumentacja techniczna", "dokument wymagań projektowych"
+
+-----
+
+#### **2. Granice projektu**
+
+Z uwagi na uproszczenia, które stosujemy, aby aplikacja była przystępna dla osób nietechnicznych, jak i skupienie na jednym typie generowanych stron, produkt nie będzie tak rozwinięty, jak obecne na rynku inne rozbudowane i komercyjne CMS’y.
+Do funkcjonalności, które nie znajdą się w aplikacji, należą między innymi:
+
+- tworzenie treści wykraczających poza schemat strony konferencyjnej,
+- obsługa płatności.
+
+Dodatkowo, ze względu na podział prac w grupie, stworzony jest oddzielny moduł do edycji wyglądu stron, działający jedynie w przeglądarkach opartych o silnik chromium.
+
+-----
+
+#### **3. Lista wymagań funkcjonalnych**
+
+Na panel administratora składają się następujące sekcje:
+
+1. Strona główna
+
+ a) z tego poziomu można przejść na pozostałe sekcje,
+
+ b) służy jako ekran powitalny panelu administratora,
+
+ c) wyświetla stworzone przez użytkownika podstrony,
+
+ d) pozwala na pobranie stron;
+
+2. Sekcja 'generowania strony'
+
+ a) pozwala użytkownikowi wygenerować pojedynczą podstronę o podanej nazwie,
+
+ b) umożliwia wybranie odpowiedniego szablonu,
+
+ c) pozwala wypełnić szablon komponentami;
+
+3. Sekcja 'szablony'
+
+ a) umożliwia stworzenie niestandardowego szablonu (układu komponentów na stronie), nadanie mu nazwy i zapisanie w systemie;
+
+4. Sekcja 'ustawienia'
+
+ a) pozwala na uzupełnienie danych o konferencji na podstawie których wypełniane będą komponenty;
+
+5. Sekcja 'uczestnicy'
+
+ a) zawiera listę uczestników z możliwym poglądem, edycją i usunięciem
+
+ b) pozwala na manualne utworzenie uczestników
+
+ c) pozwala na powiadomienie uczestnika o zaakceptowaniu płatności (bez jej obsługi)
+
+Oprócz tego, dążymy do tego, aby produkt końcowy umożliwiał wygenerowanie strony zawierającej:
+
+* lista uczestników
+* informacje o opłacie konferencyjnej
+* informacje na temat miejsca organizacji konferencji
+* zaproszeni mówcy
+* plan konferencji
+* dofinansowanie
+* lista uczestników
+* komitet ( programowy / naukowy )
+* kontakt
+* aktualności
+* dojazd
+* zakwaterowanie
+* poprzednie konferencje
+* zdjęcia
+* publikacja
+* konfigurowalna strona
+* konfigurowalne pole menu
+
+
+Na wtyczkę składają się dwa główne moduły:
+1. Menu, z którego można wybrać elementy do edycji oraz własności elementów:
+ - kolor,
+ - krój czcionki i jej wielkość,
+ - marginesy i przestrzeń wokół elementu,
+ - wymiary,
+ - obramowanie,
+ - położenie elementu,
+ - widoczność elementu;
+2. Podstrona wtyczki
+ - znajduje się tutaj edytor CSS, w którym dynamicznie jest generowany kod wynikowy oraz krótka instrukcja użytkowania wtyczki;
+ - pozwala na pobranie pliku CSS;
+
+-----
+
+#### **4. Lista wymagań niefunkcjonalnych**
+
+Aplikacja jest przystosowana do pracy i działania z najpopularniejszymi przeglądarkami - tj. Mozilla Firefox i tymi opartymi o silnik chromium. Wynika to z niemożności obsługi przez przestarzałe przeglądarki elementów HTML, CSS i JS powszechnie uważanych za standard.
+
+Zdecydowaliśmy się na wykonanie aplikacji webowej, ponieważ ważnym aspektem jest, aby produkt był dostępny w łatwy sposób na szerokiej gamie urządzeń.
+
+Ze względów prostoty budowy aplikacji i prywatności nie zdecydowaliśmy się na wdrożenie żadnych zewnętrznych sposobów autoryzacji.
+
+Interfejs użytkownika panelu administratora aplikacji został stworzony przy pomocy biblioteki gotowych elementów Bootstrap. Wynika to z ograniczonego czasu i chęci zbudowania szybkiego prototypu przez zespół.
+
+Wtyczka powinna działać niezawodnie również offline, łącznie z opcją zapisywania pliku wynikowego, jednak strona, na której zachodzą zmiany musi być w pełni załadowana. Dodatkowo, pozwala na edytowanie stron, w taki sposób, że zmiany będą działać również na urządzeniach mobilnych.
+
+Niektóre funkcjonalności nie zostaną wdrożone z uwagi na zmiany w podziale zadań w grupie w trakcie trwania projektu.
+
+
+
+-----
+
+#### **5. Mierzalne wskaźniki wdrożeniowe**
+
+Na koniec drugiego semestru klient otrzyma wersję beta systemu. W przypadku braku zastrzeżeń aplikacja zostanie udostępniona na potrzeby klienta i jego zakładu, a wtyczka udostępniona w Chrome Web Store.
+
+-----
+
+#### **6. Kryteria akceptacji projektu dla I semestru prac**
+
+* wymagane
+
+ * generator szablonów
+ * sekcja panelu administratora umożliwiająca użytkownikowi wygenerowanie szablonu (tj. siatki na komponenty)
+ * opcjonalna możliwość dodania własnych styli i skryptów
+ * generator pojedynczej strony
+ * umożliwia wybranie szablonu (jednego z domyślnych lub stworzonych przez użytkownika) i uzupełnienia go o komponenty
+ * pozwala na finalne wygenerowanie strony do plików.
+ * zabezpieczenie panelu administratora przed nieautoryzowanym dostępem
+ * edytor wyglądu stron z naciskiem na edycję wyglądu całych znaczników, a nie poszczególnych elementów
+
+* oczekiwane
+
+ * wygenerowanie responsywnego prototypu strony przy użyciu aplikacji
+
+* planowane
+
+ * ukierunkowanie przygotowanych komponentów ściśle pod stronę konferencyjną
+
+-----
+
+#### **7. Kryteria akceptacji projektu dla II semestru prac**
+
+* wymagane
+
+ * rozbudowanie panelu administratora o kolejne zakładki umożliwiające konfigurację danych na temat konferencji
+
+ * uzupełnienie bazy komponentów o te, które zostały opisane w wizji projektu
+
+ * dodanie możliwości tworzenia więcej niż jednej podstrony
+
+ * rozszerzenie działania wtyczki o edycję pojedynczych elementów i zapisanie stanu strony
+
+* oczekiwane
+
+ * dodanie zakładki do zarządzania uczestnikami konferencji
+
+ * dodanie możliwości podglądu podstrony na różnych rozdzielczościach ekranu
+
+ * przygotowanie wygenerowanej strony do publikacji
+
+ * rozbudowanie edytora CSS, np. o możliwość wskazywania literówek
+
+* planowane
+
+ * rozbudowanie procesu generowania strony o optymalizację plików wynikowych
+
+-----
+
+#### **8. Organizacja pracy zespołu**
+
+Nasz zespół został podzielone na trzy podgrupy:
+
+* część frontendowa
+
+ * Konrad Pierzyński
+
+ * sekcja generatora szablonów
+ * generator responsywnych szablonów
+ * funkcjonalność dodawania styli i skryptów
+ * szablony i komponenty
+ * UX/UI aplikacji
+
+ * Michał Starski
+
+ * konfiguracja środowiska frontendu
+ * sekcja tworzenia strony
+ * system ładowania komponentów i szablonów
+ * sekcja podglądu wygenerowanej strony
+ * autoryzacja użytkownika
+ * zarządzanie flow pracy GIT/JIRA
+
+* część backendowa
+
+ * Maciej Więcek
+ * baza danych i logika aplikacji
+ * generowanie stron
+ * zabezpieczenie API
+ * autoryzacja użytkownika
+ * deployment usługi
+
+* wtyczka
+ * Patrycja Łaźna
+ * wszystkie działania związane ze stworzeniem wtyczki
+ * UX/UI
+ * testowanie wtyczki
+ * deployment
+
+Komunikacją z klientem zajmuje się cały zespół z wykorzystaniem MS Teams.
+
+Zespół przyjął metodykę kanban. Rozważany był również scrum, ale z uwagi na zbyt dużą asynchroniczność prac spowodowaną czynnikami zewnętrznymi finalnie został odrzucony.
+
+Do zarządzania pracą i kodem, zespół korzysta z dwóch narzędzi:
+
+* JIRA - organizacja zadań
+* GIT - kontrola kodu
+* Trello - organizacja zadań (zadania dot. wtyczki, tylko w I semestrze)
+
+#### *Cykl życia zadania w projekcie*
+
+Zadanie powstaje podczas cotygodniowego spotkania, podczas którego członkowie zespołu omawiają kolejne kroki budowy aplikacji i ustalają ich priorytety. W momencie gdy zadanie jest gotowe do realizacji, trafia ono do puli zadań do zrobienia w Jirze.
+
+| Nazwa etapu zadania | Do zrobienia | W trakcie | Zrobione |
+| ------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------- |
+| Opis etapu | Po uzgodnieniu z zespołym nowo zaplanowane zadanie trafia w to miejsce. | Deklaracja członka zespołu, że pracuje nad zadaniem. Ewentualnie zadanie jest w trakcie sprawdzania. | Zadanie zostaje uznane za zakończone. |
+
+-----
+
+#### **9. Ryzyka projektowe**
+
+Ze względu na mały zespół i ograniczony czas, funkcjonalności mogą okazać się niedopracowane. Ponadto jednorodny wygląd komponentów może odpychać niektórych klientów.
+Podzielenie systemu na aplikację i wtyczkę może wydawać się nieintuicyjne.
+
+-----
+
+#### **10. Kamienie milowe**
+
+* koniec marca
+ * Przygotowanie infrastruktury projektu, rozmowa z klientem
+* początek kwietnia
+ * Stworzenie podstawowego panelu administratora z możliwością wyboru szablonu i umieszczenie w nim komponentów
+* środek kwietnia
+ * Komunikacja prototypu panelu adminstratora z serwerem
+* koniec kwietnia
+ * Stworzenie minimalnej wersji aplikacji
+* początek maja
+ * Dodanie autoryzacji administratorów, przerobienie interfejsu tworzenia i umieszczania komponentów
+* czerwiec
+ * Mechanizm generowania pojedynczej strony
+ * Dodanie modułów do edycji elementów we wtyczce i mechanizmu generowania kodu CSS
+* lipiec - sierpień
+ * Dodanie prostego edytora CSS
+ * Stworzenie działającego prototypu wtyczki
+* październik - listopad
+ * Konfiguracja danych odnoście konferencji i umożliwienie komponentom korzystanie z nich
+* listopad - grudzień
+ * Łączenie wielu podstron w jedną całość
+ * Rozbudowanie działania pickera o pojedyncze elementy
+* styczeń - luty
+ * Rozszerzenie możliwości edytora CSS
+ * Optymalizacja procesu budowania strony wynikowej
+ * Przygotowanie produkcyjnych komponentów
\ No newline at end of file
diff --git a/Witkowski/flat-mapp/Wymagania projektowe FlatMapp.docx b/Witkowski/flat-mapp/Wymagania projektowe FlatMapp.docx
new file mode 100644
index 0000000..2d0c8e3
Binary files /dev/null and b/Witkowski/flat-mapp/Wymagania projektowe FlatMapp.docx differ
diff --git a/Witkowski/grilled-brain/Wymagania_projektowe.docx b/Witkowski/grilled-brain/Wymagania_projektowe.docx
new file mode 100644
index 0000000..6e40f39
Binary files /dev/null and b/Witkowski/grilled-brain/Wymagania_projektowe.docx differ
diff --git a/Witkowski/lang-sheet/Project requirements.md b/Witkowski/lang-sheet/Project requirements.md
new file mode 100644
index 0000000..3b07bb3
--- /dev/null
+++ b/Witkowski/lang-sheet/Project requirements.md
@@ -0,0 +1,230 @@
+# Project requirements
+
+Project title: Langsheet
+
+Authors: Andrew Moskovets, Kiryl Averkiyeu, Bohdan Bakhlul
+
+Date: 15.11.2020
+
+
+## 0. Document versions
+1.0 - current
+
+
+## 1. Project components (project products)
+Programming components:
+- React-framework-based frontend component - semesters 1 & 2
+- Django-framework-based backend component - semesters 1 & 2
+- Database server instance based on MongoDB - semester 2
+
+Non-programming components:
+- Functional specification - semesters 1 & 2
+- Layouts designed with AdobeXD - semesters 1 & 2
+- Test reports - semester 2
+- Documentation considering the architecture of the application - semesters 1 & 2
+
+
+## 2. Project boundaries
+
+- Mobile application (iOS, Android) will not be created. It is unreasonable because of the small display working area
+- Worksheet constructor will not be available on mobile devices via the browser. It is unreasonable because of the small display working area
+
+## 3. Functional requirements list
+##### Teacher:
+- Teacher can upload images in order to use them as text sources.
+- Teacher can choose the number of points for every exercise.
+- Teacher can export the worksheet to PDF.
+- Teacher can edit his worksheet
+- Teacher can delete exercises.
+- Teacher can save the worksheet.
+- Teacher can preview separate exercises.
+- Teacher can preview the whole worksheet.
+- Teacher can create “Fill in the gaps” type exercises.
+- Teacher can create “Match paragraphs with titles” type exercises.
+- Teacher can create “Open question” type exercises.
+- Teacher can create “Closed question” type exercises.
+- Teacher can create “Test question” type exercises.
+- Teacher can create “Fill in missing sentences” type exercises.
+- Teacher can create “Match paragraphs with titles” type exercises.
+- Teacher can create “True/false” type exercises.
+- Teacher can create “Fill in with word by given base form” type exercise.
+- Teacher can create “Create titles for paragraphs” type exercise.
+- Teacher can send the link with the worksheet to the chosen student(s).
+- Teacher can generate a teacher’s sheet with a solution.
+- Teacher can choose a language for the exercises statements.
+- Teacher defines when the sheet is available and for who.
+##### Student:
+- Student can view worksheets.
+- Student can solve worksheets online.
+- Student can print worksheets.
+- Student can see his result.
+
+## 4. Nonfunctional requirements list
+- We want to be able to create worksheets in an easy way, with as many automated elements as possible. Elements are created by the app with minimal help from the user. Moreover, we would like to be able to use text from photos taken by the user. The application will focus on the Spanish language but should work also for other languages without problems. The application should be designed for people which are not proficient in using computer tools.
+- Product is targeted for use in Google Chrome (86.0 and newer), Safari (14.0 and newer), Mozilla Firefox (82.0 and newer).
+- Product is targeted for use in Spanish and English languages.
+- Worksheet creation and editing are available only on the desktop.
+- Optimal resolution for creating a worksheet is 1920x1080.
+- Optimal resolution for solving worksheet is 375x660 for mobile and 1920x1080 for desktop.
+
+## 5. Measurable implementation indicators
+The project will be deployed to domain langsheet.com after our client will provide testing and approve deployment action. At the end of December, the closed beta version of the product is going to be released. In January 1.0 version will be released.
+
+## 6. Project acceptance criteria for semester one
+##### Required:
+- Worksheet constructor
+- PDF generation
+- High level of automatization
+##### Expected:
+- At least 10 types of exercises, which can be used in the worksheet
+- Optical character recognition feature
+- Lack of errors and failures, which harm product usability
+- User-friendly design
+- Multilingualism
+##### Planned:
+- Dark mode of the website
+
+## 7. Project acceptance criteria for semester two
+##### Required:
+- Deploy to the server
+- Product tested and approved positively by the client
+- Possibility to solve tests online
+- Possibility to share test for solving via link
+##### Expected:
+- The product is tested and approved positively by the group of users
+- Teacher registration via our system
+- Teacher registration via external systems (Facebook, Google)
+##### Planned:
+- Explanatory dictionary support
+- Import article text from its link
+
+## 8. Teamwork organization
+##### Andrii Moskovets:
+- Creating UI/UX design
+- Creating mock-ups for the whole app
+- App testing and bug fixing
+- Creating previews for separate exercises
+- Creating documentation (project vision, acceptance criteria, presentation, technical documentation)
+- Future tasks
+##### Bohdan Bakhlul:
+- Creating an optical character recognition program
+- Creating previews for separate exercises
+- Manual testing
+- Creating mockups for specific components
+- Creating documentation (project vision, acceptance criteria, presentation, technical documentation)
+- Fixing bugs, UX-mistakes
+- Future tasks
+##### Kiryl Averkiyeu:
+- Creating specific components for the front-end part of the application, e.g
+ - Component for editing worksheet
+ - Component for editing exercises
+ - Component for worksheet preview
+ - etc.
+- Code reviewing
+- Creating documentation (project vision, acceptance criteria, presentation, technical documentation)
+- Bug fixing
+- Manual testing
+- Text tokenizing
+- Future tasks
+#### Roles:
+##### Andrii Moskovets
+- full-stack developer
+- UX/UI designer
+##### Bohdan Bakhlul
+- full-stack developer
+- Test Lead
+##### Kiryl Averkiyeu
+- full-stack developer
+- DevOps Engineer
+
+
+Communication with the client is organized via real-time Teams meeting after every sprint. Everyone from the team is communicating with the client.
+
+We use personalized Agile, meeting with clients after each sprint: refining requirements + prioritizing tasks for the next sprint. 1st semester - 2 weeks sprints, 2nd semester - 1 month sprints. The waterfall methodology was rejected because the client is able to meet with us often and give ideas and prioritize tasks to ensure quality of final product.
+
+Source code and backlog is managed with GitLab version control system. Diagram of the task life cycle:
+```
+Open -> To Do -> Doing -> Code Review -> Testing -> (Rejected) -> Merge Request -> Closed
+() - optional step
+```
+
+## 9. Project risks
+##### Resource-related:
+- The small size of the team (3 out of 4) leads to bigger responsibility and amount of work to be done for every member
+- Member leaving leads to huge difficulties in finishing the product
+- Time restrictions on product creation
+- Most of the used technologies are new to all team members and are learned during the whole development process
+
+##### Others:
+- Adding new requirements by the client may lead to difficulties in finishing the project on time or errors occurring in new functionalities
+- Team misunderstandings about implementation solutions, architecture, functionality, or technologies used
+- Lack of proper commitment to the project on the part of the team
+- Sudden lack of support or termination of used development technology or tools - the need to re-implement, or continuing implementation in unused / poorly designed tool, library
+- A tight deadline, team communication problems as a consequence of pandemic, university workload, and private issues may negatively affect the work on the application
+
+## 10. Milestones
+#### 1st semester: 2-week sprints.
+Due to a change of project topic, development started in mid-April (2nd sprint of the month)
+- April
+ - 2nd sprint
+ - Add blank backend
+ - Add blank frontend
+ - Create a view for the worksheet constructor
+ - Create Gap Fill Generator
+ - Create an endpoint for text tokenization
+ - Set up linters
+ - Create common .gitignore file
+ - Create an endpoint for constructing PDF file
+ - PDF document preview
+ - Bug fixing
+- May
+ - 1st sprint
+ - Create an “official” mockup of the whole web application
+ - Create a model for storing data
+ - Create Acceptance Criteria document
+ - Bug fixing
+ - 2nd sprint
+ - Test OCR libraries
+ - Test Gap Fill Generator for different encodings
+ - Create a view for adding text using the photo upload
+ - Create an endpoint for OCR
+ - Bug fixing
+- June
+ - 1st sprint
+ - Reconstructing front-end corresponding to worksheet constructor due to mock-up created before
+ - Modernization of PDF document generator
+ - Adding new features
+ - Bug fixing
+ - Testing
+ - 2nd sprint
+ - Bug fixing
+ - Testing
+ - Prepare Minimum Viable Product for presenting to the committee
+ - Prepare presentation for the committee
+#### 2nd semester: 1-month sprints.
+- October sprint
+ - Multiple question types feature
+ - Testing
+ - Bug fixing
+ - November sprint
+ - Create a layout for online solving
+ - Research online worksheet solving
+ - Testing
+ - Bug fixing
+- December sprint
+ - Implement solving worksheets online
+ - Implement sharing worksheets via link
+ - Testing
+ - Bug fixing
+ - Presenting product to the client
+- January sprint
+ - Deploying
+ - Implement dictionary support
+ - Implement article import support
+ - Testing application on a small group
+ - Bug fixing
+ - Presenting product to the client
+- February sprint
+ - Bug fixing
+ - Presenting product to the client
+ - Presenting product to the committee
diff --git a/Witkowski/pana-cea/PanaCea final Documentation.pdf b/Witkowski/pana-cea/PanaCea final Documentation.pdf
new file mode 100644
index 0000000..634c847
Binary files /dev/null and b/Witkowski/pana-cea/PanaCea final Documentation.pdf differ
diff --git a/Witkowski/pool-aid/Project requirementsS2.pdf b/Witkowski/pool-aid/Project requirementsS2.pdf
new file mode 100644
index 0000000..98f90cc
Binary files /dev/null and b/Witkowski/pool-aid/Project requirementsS2.pdf differ
diff --git a/Witkowski/transport-platform/project-requirements-city-advisor.pdf b/Witkowski/transport-platform/project-requirements-city-advisor.pdf
new file mode 100644
index 0000000..deb6643
Binary files /dev/null and b/Witkowski/transport-platform/project-requirements-city-advisor.pdf differ
diff --git a/Zywica/dev-match/DevMatch-Dokument_wizji_projektu-2.0.0.pdf b/Zywica/dev-match/DevMatch-Dokument_wizji_projektu-2.0.0.pdf
new file mode 100644
index 0000000..0887f10
Binary files /dev/null and b/Zywica/dev-match/DevMatch-Dokument_wizji_projektu-2.0.0.pdf differ
diff --git a/Zywica/dev-match/DevMatch-Dokument_wymagan_projektowych-2.0.0.pdf b/Zywica/dev-match/DevMatch-Dokument_wymagan_projektowych-2.0.0.pdf
new file mode 100644
index 0000000..3add9f8
Binary files /dev/null and b/Zywica/dev-match/DevMatch-Dokument_wymagan_projektowych-2.0.0.pdf differ
diff --git a/Zywica/ork/Wymagania projektowe.pdf b/Zywica/ork/Wymagania projektowe.pdf
new file mode 100644
index 0000000..cd43ccd
Binary files /dev/null and b/Zywica/ork/Wymagania projektowe.pdf differ
diff --git a/Zywica/rents/RENTALL - Project Requirements.docx b/Zywica/rents/RENTALL - Project Requirements.docx
new file mode 100644
index 0000000..89ff073
Binary files /dev/null and b/Zywica/rents/RENTALL - Project Requirements.docx differ