PLATFORMA E-USŁUG EDUKACYJNYCH WSPiA

4.3.6.1. Serwerowy system operacyjny – licencje pokrywające wszystkie rdzenie w procesorach fizycznych w ramach proponowanych 4 serwerów kasetowych blade. 147

4.3.6.2. Licencje dostępowe CAL do systemów operacyjnych dla 350 pracowników 150

4.3.6.3. Licencje dostępowe dla studentów do systemów operacyjnych – 2 szt. 150

5. Wdrożenie 150

5.1. Analiza przedwdrożeniowa 150

5.2. Instalacja i konfiguracja środowiska sprzętowego 151

5.3. Opracowanie e-usług 152

5.4. Wdrożenie platformy e-usług 152

5.5. Szkolenia 153

6. Dokumentacja 154

Prezentacja Błąd! Nie zdefiniowano zakładki.

1. Słownik Pojęć

• Platforma e-usług / Platforma multiportalowa – zbiór wielu portali internetowych osadzonych we wspólnym środowisku serwerowym oraz bazodanowym, posiadających wspólne mechanizmy

umożliwiające zarządzanie, rozbudowę i modyfikację praz dodawanie nowych portali internetowych.

Platforma w swojej funkcjonalności zapewnia możliwość realizacji wymienionych w dokumencie e-usług.

• Portal – pojedynczy serwis internetowy stanowiący część platformy multiportalowej

• Xxxxxxx – witryna internetowa

• Moduł – element portalu zawierający określone funkcjonalności.

• Blok – element portalu służący do prezentacji treści.

• Mapy Google – zewnętrzny komponent portalu wykorzystywany do prezentacji danych na mapach geograficznych

• Front – powszechnie widoczna cześć portalu stanowiąca zbiór opublikowanych witryn internetowych

• Panel – panel administracyjny dostępny po zalogowaniu tylko dla uprawnionych użytkowników. (panel globalny i panel lokalny)

• Globalny panel administracyjny – panel administracyjny umożliwiający zarządzanie wszystkimi portalami uruchomionymi w obrębie platformy multiportalowej

• Lokalny panel administracyjny – panel administracyjny umożliwiający zarządzanie pojedynczym portalem w obrębie platformy portalowej

• RG – Rozdzielnia Główna zasilania

• SZR – System Zasilania Rezerwowego

• ePUAP - Elektroniczna Platforma Usług Administracji Publicznej, Ogólnopolska platforma teleinformatyczna służąca do komunikacji obywateli z jednostkami administracji publicznej

• POL-on - jest to zintegrowany system informacji o nauce i szkolnictwie wyższym, który wspiera

pracę Ministerstwa Nauki i Szkolnictwa Wyższego, a także Głównego Urzędu Statystycznego oraz Centralnej Komisji do spraw Stopni i Tytułów. Jego istotnym zadaniem jest stworzenie globalnej bazy danych o jednostkach naukowych, wyższych uczelniach i nauce polskiej. Gromadzone dzięki niemu informacje

wspierają procesy decyzyjne Ministerstwa Nauki i Szkolnictwa Wyższego odnośnie do polskich uczelni oraz jednostek naukowych. POL-on ułatwia podejmowanie decyzji o ukierunkowaniu wydatków na kształcenie i pomoc materialną dla uczelni wyższych

• KReM - to system informatyczny umożliwiający zbieranie wyników egzaminów maturalnych z całej Polski oraz udostępnianie ich upoważnionym do tego uczelniom, jest prowadzony przez Centralną Komisję Egzaminacyjną

• FAQ (ang. Frequently Asked Questions) – zbiory często zadawanych pytań i odpowiedzi na nie

• SSO (ang. single sign-on) - pojedyncze logowanie– możliwość jednorazowego zalogowania się do usługi sieciowej i uzyskania dostępu do wszystkich autoryzowanych zasobów zgodnych z tą usługą.

• SAML (ang. Security Assertion Markup Language) - nazwa protokołu, zatwierdzonego przez OASIS (Organization for the Advancement of Structured Information Standards) i wykorzystywanego do pośredniczenia w uwierzytelnianiu i automatycznego przekazywania między systemami i aplikacjami

informacji o uprawnieniach użytkowników.

• Slider - Jest to element strony internetowej, w obrębie którego następuje zmiana treści (np. obrazka). Slajdy zmieniają się po upływie określonego czasu (kilku sekund).

• WYSIWYG (ang. what you see is what you get i) – akronim stosowany w informatyce dla określenia metod, które pozwalają uzyskać wynik w publikacji identyczny lub bardzo zbliżony do obrazu na ekranie

• SEO - Optymalizacja dla wyszukiwarek internetowych (ang. search engine optimization, zwana

także pozycjonowaniem) – procesy zmierzające do osiągnięcia przez xxxx xxxxxx internetowy jak najwyższej pozycji w wynikach organicznych wyszukiwarek internetowych dla wybranych słów i fraz kluczowych.

• REST - Representational State Transfer (REST, ang. zmiana stanu poprzez reprezentacje) –

styl architektury oprogramowania wywiedziony z doświadczeń przy pisaniu specyfikacji protokołu HTTP dla systemów rozproszonych. REST wykorzystuje x.xx. jednorodny interfejs, bezstanową komunikację, zasoby, reprezentacje, hipermedia.

2. Założenia Projektu

2.1. Założenia ogólne

Podniesienie efektywności i dostępności oraz wprowadzenie 12 nowych e-usług przez wyższą szkołę prawa i administracji rzeszowską szkołę wyższą z siedzibą w Rzeszowie w okresie 01.01.2017-30.06.2018, co będzie miało bezpośredni wpływ na wyższą jakość i ułatwi dostęp do usług publicznych świadczonych drogą elektroniczną.

W ramach niniejszego projektu przewidziano wdrożenie e-usług dedykowanych studentom, środowisku akademickiemu (A2C) oraz zapewniających skuteczną współpracę z gospodarką i instytucjami publicznymi.

1. e-rekrutacja – poziom 4

2. e-student – poziom 4

3. e-tablica ogłoszeń – poziom 2

4. e-kontakt – poziom 3

5. e-wykłady – poziom 3

6. e-lista obecności – poziom 4

7. e-klinika Prawa – poziom 3

8. e-klinika Przedsiębiorczości – poziom 3

9. e-klinika Administracji – poziom 3

10. e-klinika Bezpieczeństwa – poziom 3

11. Interaktywny system badań – poziom 3

12. e-repozytorium – poziom 2

Cel główny zostanie osiągnięty poprzez cele szczegółowe, do których zaliczamy:

1. wdrożenie 12 e-usług dedykowanych studentom i całemu środowisku akademickiemu;

2. dostarczenie 3 e-usług na 4 poziomie dojrzałości;

3. dostarczenie 7 e-usług na 3 poziomie dojrzałości;

4. zapewnienie odpowiednich warunków nauczania poprzez rozbudowę i modernizację zaplecza WSPiA w oparciu o technologie komunikacyjne i informatyczne;

5. zapewnienie odpowiednich warunków współpracy z przedsiębiorcami oraz instytucjami publicznymi;

6. zwiększenie efektywności nauczania WSPiA poprzez wprowadzenie nowej jakości dostępu do zasobów wiedzy;

7. unowocześnienie platformy dystrybucji informacji pomiędzy pracownikami naukowymi, wykładowcami, studentami oraz pracownikami administracyjnymi Uczelni;

8. unowocześnienie platformy dystrybucji informacji pomiędzy WSPiA a przedsiębiorcami i instytucjami publicznymi;

9. rozwój intelektualny studentów WSPiA;

10. rozwój intelektualny pracowników WSPiA.

2.2. Realizowane procesy

Przedmiotem projektu jest zintegrowane środowisko informatyczne realizujące procesy biznesowe skupione według kluczowych obszarów:

Nazwa obszaru	Opis obszaru
1. Rekrutacja	Rejestracja kandydatów na studia.
	Usługi przeznaczone zarówno dla studentów, jak i całego personelu

2. Wsparcie procesu dydaktycznego

Uczelni, pozwalające na poprawę organizacji zajęć dydaktycznych oraz

automatyzację przepływu informacji.

3. Obsługa poradni prawnych działających w strukturach Uczelni

Usługa przeznaczona dla studentów ma na celu wsparcie kształcenia praktycznego studentów. Kontakt z rzeczywistymi przypadkami i możliwość pracy nad nimi daje możliwość wykorzystania nabytej

wiedzy teoretycznej w praktyce.

4. Badania naukowe

Usługi pozwalające na przygotowanie, przeprowadzenie oraz analizę wyników badań naukowych z wykorzystaniem systemów

informatycznych.

5. Archiwizacja i udostępnianie dokumentów oraz materiałów dydaktycznych

Usługi oraz narzędzia informatyczne pozwalające na skuteczne i bezpieczne przechowywanie informacji. Repozytorium stanowić będzie również bazę wiedzy udostępnianą dla poszczególnych interesariuszy.

Główne obszary funkcjonalne zostały podzielone na podprocesy, które będą realizowane w ramach wdrożenia i integracji już istniejących oraz nowych systemów informatycznych

Lp.	Nazwa procesu	Opis procesu
1.	E-rekrutacja	Rejestracja kandydatów na studia wyższe. Proces przeznaczony będzie dla kandydatów na studia oraz pracowników Uczelni obsługujących proces rekrutacji
2.	E-student	Elektroniczny obieg dokumentów. Przeznaczony dla studentów oraz pracowników Uczelni
3.	E-tablica ogłoszeń	Elektroniczna informacja dla wszystkich interesariuszy
4.	E-kontakt	Elektroniczne kalendarze, harmonogramy spotkań, konsultacji, wydarzeń.
5.	E-wykłady	Rejestracja, publikacja i archiwizacja wykładów prowadzonych przez pracowników dydaktycznych
6.	E-lista obecności	Rejestracja uczestników wykładów oraz innych zajęć dydaktycznych
7.	E-klinika prawa	Obsługa poradni kliniki prawa.
8.	E-klinika administracji	Obsługa poradni kliniki administracji.
9.	E-Klinika przedsiębiorczości	Obsługa poradni kliniki przedsiębiorczości.
10.	E-klinika bezpieczeństwa	Obsługa poradni kliniki bezpieczeństwa.
11.	Interaktywny system badań	Przygotowanie, publikacja, przeprowadzenie ankiet wykorzystywanych do badań naukowych.
12.	E-repozytorium	Archiwizacja, bezpieczeństwo oraz udostępnianie uprawnionym użytkownikom zasobów rejestrowanych w ramach wdrażanych e- usług

Wszystkie w/w podprocesy będą posiadać obszar wspólny, wyodrębniony jako grupa procesów technicznych, przeznaczonych do zapewnienia bezpieczeństwa oraz zachowania integralności danych w objętych projektem systemach informatycznych.

Lp.	Nazwa procesu	Opis procesu
1.	Administracja systemów informatycznych	Zarządzanie i monitorowanie infrastruktury IT
2.	Zarządzanie tożsamością	Zarządzanie tożsamością użytkowników końcowych systemu
3.	Uwierzytelnianie	Weryfikacja i potwierdzenie zadeklarowanej tożsamości podmiotu biorącego udział w procesach
4.	Autoryzacja	Udostępnienie zasobów po procesie pomyślnego uwierzytelnienia
5.	Synchronizacja i udostępnianie danych	Integracja systemów informatycznych realizujących procesy e-usług w

2.3. Główni użytkownicy Platformy E-Usług Edukacyjnych

• Pracownicy Administracji Uczelni

• Pracownicy Dydaktyczni Uczelni

• Studenci

• Obywatele

2.4. Zakres projektu

Przedmiotem postępowania jest dostarczenie elementów składowych które umożliwią realizację e-usług zdefiniowanych w rozdziale 2.1. spełniających realizujących poniższe funkcjonalności.

Opis do tabel:

W - funkcjonalność wymagana na dzień złożenia oferty

O - funkcjonalność opcjonalna nie wymagana na dzień złożenia oferty, ale wymagana w momencie zakończenia wdrożenia.

2.4.1. E-usługa E-Rekrutacja

Cel realizacji e-usługi: Obsługa procesu rekrutacji w dwóch aspektach: z punktu widzenia kandydata na studia oraz od strony pracowników Uczelni obsługujących proces rekrutacji. Usługa przeznaczona będzie dla wszystkich zainteresowanych podjęciem studiów w Uczelni (kandydatów na studia) oraz pracowników Uczelni obsługujących proces rekrutacji oraz zajmujących się analityką danych związanych z naborami kandydatów na studia.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-rekrutacja zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	E-rekrutacja
ER - 001	System musi działać w przeglądarce internetowej – wszyscy użytkownicy (zarówno kandydaci jak i członkowie komisji rekrutacyjnej uczelni) muszą mieć możliwość wykorzystania funkcjonalności systemu z poziomu przeglądarki internetowej (nie dopuszcza się użycia połączenia terminalowego).	W
ER – 002	System jest w pełni responsywny – formularze rekrutacyjne dostosowują się do urządzenia używanego przez kandydata, który może zarejestrować się z wykorzystaniem komputera, smartfona, tabletu itp.	O
ER – 003	System daje możliwość uruchomienia dwóch lub więcej niezależnych serwisów rekrutacyjnych, ale działających w oparciu o jedną, wspólną bazę danych.	O
ER – 004	System posiada możliwość pracy na bazach danych MS SQL, Oracle.	O
ER – 005	System posiada możliwość wysyłania do kandydatów powiadomień indywidualnych, grupowych i spersonalizowanych poprzez: e-mail, sms i umieszczenie ogłoszenia dla kandydata w systemie rekrutacyjnym.	O
ER – 006	System posiada możliwość automatycznego wysyłania powiadomień do kandydata na podstawie wcześniej zdefiniowanych przez komisję rekrutacyjną warunków dla danego powiadomienia.	O
ER – 007	Dla kandydatów cudzoziemców system podczas procesu rekrutacji daje możliwość zapisywania się na przedmioty wprowadzone w planie studiów systemu dziekanatowego	O
ER – 008	System umożliwia walidację wprowadzonego przez kandydata adresu e-mail i potwierdzenie tego adresu poprzez wysłanie linku aktywacyjnego.	O
ER – 009	System daje możliwość zalogowania się na konto kandydata przez członka komisji rekrutacyjnej.	O
ER – 010	Dane przyjętych kandydatów są przenoszone z systemu rekrutacyjnego do	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	systemu dziekanatowego automatycznie. System działa wg zasady jeden PESEL – jeden numer albumu: w przypadku rozpoczęcia na uczelni kolejnego toku studiów numer albumu pozostaje ten sam – wymagane jest zachowanie sposobu numeracji albumu jak w dziekanacie zgodnie z paragrafem 3 ustęp 2 Rozporządzenia Ministra Nauki i Szkolnictwa Wyższego z dnia 16 września 2016 roku w sprawie dokumentacji przebiegu studiów.
ER – 011	System rekrutacyjny operuje na odrębnej bazie danych, zgodnie z przepisami dot. ochrony danych osobowych.	W
ER – 012	System zapewnia pełną obsługę postępowania rekrutacyjnego (od rejestracji kandydata do przekazania danych osób przyjętych na studia do właściwej bazy dziekanatowej) dla każdego rodzaju rekrutacji (w tym rekrutacji cudzoziemców).	W
ER – 013	Struktura uczelni (wydziały, kierunki) odwzorowana w systemie dziekanatowym musi zostać zaimplementowana w systemie rekrutacyjnym. Dodanie nowego kierunku w systemie dziekanatowym musi skutkować pojawieniem się nowej potencjalnej ścieżki w systemie rekrutacyjnym, na którą będzie mógł zapisać się kandydat.	W
ER – 014	System umożliwia generowanie numerów subkont dla kandydatów na podstawie dostarczonego szablonu (schematu).	O
ER – 015	System umożliwia zaczytywanie plików z wpłatami kandydatów z banku po stronie systemu Rekrutacji (pliki zaczytywane w module Web), podczas zaczytywania następuje automatyczne przez system oznaczenie dokonania płatności.	W
ER – 016	System musi posiadać integrację z co najmniej jednym systemem płatności online – kandydat zaraz po zarejestrowaniu może dokonać opłaty rekrutacyjnej w odpowiednim serwisie.	W
ER – 017	System posiada moduł raportów (zestawienia) np. kwota naliczeń, kwota wpłat, lista kandydatów z wpłatami, bez wpłat. Moduł ten musi posiadać możliwość przygotowania dowolnych zestawień z danych zgromadzonych w bazie danych.	W
ER – 018	System ma możliwość przygotowania zdefiniowanych pól, które dla danego numeru PESEL zaciągane są z bazy systemu dziekanatowego.	O
ER – 019	System rekrutacyjny pozwala z poziomu przeglądarki internetowej na generowanie wydruków seryjnych, korespondencji seryjnej na podstawie wybranych pól w formatach .pdf, .doc, .html.	W
ER – 020	System posiada możliwość informowania kandydata po zalogowaniu na konto o stanie salda (zaksięgowanych wpłatach).	W
ER – 021	Podczas i po rejestracji w systemie kandydat ma możliwość: a) wypełniania formularza online (wszelkie wprowadzane dane są weryfikowane, dane dotyczące wyników matury są importowane i weryfikowane z bazą KReM); b) wyboru kilku kierunków studiów, na które chce się ubiegać o przyjęcie; c) wprowadzenia zdjęcia (o formacie ściśle zdefiniowanym przez administratora); d) wyboru przez kandydata (na etapie rejestracji) kierunku głównego i kierunków/specjalności alternatywnych, możliwość wybrania przez	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	kandydata ścieżki kształcenia; e) przeglądania FAQ z wszelkimi istotnymi dla procesu rekrutacyjnego informacjami; f) wprowadzenia danych dotyczących każdego rodzaju matury w tym międzynarodowej, które system automatycznie uwzględni w algorytmie wyliczającym liczbę punktów; g) wydruku dokumentów niezbędnych w procesie rekrutacji; h) sprawdzenia aktualnego statusu swojego podania o przyjęcie.
ER – 022	System rekrutacyjny: a) gromadzi dane o przebiegu postępowania rekrutacyjnego (dane osobowe, egzaminy, wprowadzone oceny, itd.); b) zapisuje informacje dotyczące aktywności użytkowników; c) pozwala na zmianę algorytmów wyliczania punktów uzyskanych przez kandydata w postępowaniu rekrutacyjnym; d) umożliwia wyszukiwanie kandydatów wg wszystkich wprowadzonych danych; e) umożliwia generowanie niezbędnych wydruków w tym wydruków rankingów wg zdefiniowanych kryteriów; f) prowadzi rejestr decyzji i dokumentów drukowanych dla kandydata, związanych z postępowaniem rekrutacyjnym; g) umożliwia tworzenie dowolnych raportów z danych zapamiętanych w systemie; h) umożliwia przygotowanie sprawozdania EN-1 w systemie Pol-on; i) umożliwia przygotowanie innych sprawozdań w ramach zmieniających się przepisów prawa; k) zapewnia elastyczne dopasowanie procesu rekrutacji; l) działa na zasadzie słowników; m) umożliwia tworzenie raportów i statystyk z procesu rekrutacji, bądź jej etapów.	W
ER – 023	System umożliwia wprowadzanie wyników egzaminów wstępnych lub rozmów kwalifikacyjnych.	W
ER – 024	System umożliwia generowanie kont do opłat.	W
ER – 025	System umożliwia obsługę kandydatów, którzy nie przechodzą standardowego procesu kwalifikacji na studia np. studenci przenoszący się z innych uczelni, studenci rozpoczynający drugi kierunek, niektóre grupy cudzoziemców, itd. - możliwość definiowania innych niż ogólnie obowiązujące zasady przyjęć.	W
ER – 026	System umożliwia definiowanie listy wymaganych dokumentów od kandydatów w zależności od zadeklarowanego przez kandydata rodzaju studiów, dokumentów przedwyjazdowych i rozliczeniowych (dla studiów zagranicznych), możliwość wyświetlania i raportowania na bieżąco listy dokumentów złożonych i niezłożonych przez kandydata/studenta.	W
ER – 027	System umożliwia samodzielne definiowanie nowych formularzy rekrutacyjnych zgodnie ze zmieniającą się ofertą edukacyjną, bez konieczności ingerencji programistów dostawcy systemu.	W
ER – 028	System umożliwia rejestrację kandydatów z automatycznym wykorzystaniem danych wprowadzonych w formularzu internetowym.	W

Nr wymagania

Opis wymagania

Funkcjonalność W/O

Możliwość ewidencji danych personalnych, w tym: imiona (w przypadku posiadania drugiego imienia - konieczność uzupełnienia) i nazwiska, PESEL, adresy: zameldowania i do korespondencji, telefony, e-maile, dane

o wykształceniu, informacje o ukończonej szkole średniej lub wyższej, ocen maturalnych, wybór wydziałów, wybór kierunków studiów, dane o niepełnosprawności, źródło utrzymania, oświadczenie o podjęciu drugiego

kierunku, informacja - cudzoziemiec, itd.

ER – 029

System umożliwia rejestrację cudzoziemców i nadawanie im numeru identyfikacyjnego (brak PESEL) - dane do formularza to: narodowość, kraj pochodzenia, adres za granicą, adres w Polsce, numer paszportu, numer wizy i kraj wydania, miejsce (kraj) ukończenia szkoły średniej, informacja o niepełnosprawności, podstawa przyjęcia (decyzja rektora, decyzja Ministra,

Karta Polaka, Unia Europejska, karta stałego pobytu).

ER – 030

System wspomaga ewidencjonowanie decyzji o przyjęciu lub nieprzyjęciu, odwołań, podpisania umowy o świadczenie usługi edukacyjnej (ewidencja

pism przy każdym kandydacie).

ER – 031

System umożliwia przeszukiwanie listy kandydatów wg zadanych kryteriów: nabór, kierunek, rodzaj, tryb studiów, semestr naboru, rok, dyplom, data wpisu, płeć, nowa i stara matura, laureaci i finaliści olimpiad, niepełnosprawni (stopień i rodzaj), liczby uzyskanych punktów z każdego etapu rekrutacji, średniej ocen, wyników kwalifikacji, z numerami albumu,

miejsca studiowania, tury zajęć oraz innych zdefiniowanych.

ER – 032

System musi umożliwiać bezpieczne zalogowanie się poprzez przeglądarkę z wykorzystaniem SSO platformy ePUAP (SAML) oraz alternatywnie tożsamości w systemach dzienników szkolnych. Na etapie ewentualnej demonstracji przy aktywnej sesji ePUAP wymagane jest wywołanie przygotowanej platformy demonstracyjnej w przeglądarce i automatyczne

otrzymanie w niej tożsamości użytkownika ePUAP

ER – 033

System musi umożliwiać automatyczne pozyskanie z systemów

informatycznych uczelni informacji o oferowanych kierunkach studiów. System rekrutacji musi umożliwiać utworzenie informacji o dostępnych kierunkach studiów na podstawie danych istniejących w systemie dziekanatowym. W przypadku dodania kolejnego kierunku studiów w systemie dziekanatowym kierunek ten musi pojawić się w systemie

rekrutacyjnym od razu, bez konieczności wykonywania jakichkolwiek prac dodatkowych.

ER – 034

System powinien umożliwiać pozyskanie historycznych danych o poziomie progów rekrutacyjnych. Wymagane jest pobranie z systemu uczelni danych o historycznych progach rekrutacyjnych (minimalnym wyniku matury dla

poszczególnych kierunków studiów).

ER – 035

System powinien umożliwiać możliwość wypełnienia i złożenia deklaracji

maturalnej przez użytkownika.

ER – 036

System musi umożliwiać przejmowanie z domeny publicznej informacji o historycznych wynikach egzaminów dla co najmniej 100 szkół woj.

podkarpackiego, celem wykonania prognozy wyniku egzaminu maturalnego użytkownika. System musi pozwalać na prognozowanie wyniku

maturalnego, podczas której możliwa będzie zmiana pozycji w wybranym

przedmiocie.

Nr wymagania

Opis wymagania

Funkcjonalność W/O

ER – 037

System musi umożliwiać prognozowanie wyniku maturalnego w oparciu o

dane historyczne i pozycję kandydata w szkole. Wymagane jest przedstawienie algorytmu prognozowania.

ER – 038

Formularz rekrutacyjny powinien mieć możliwość przejęcia danych ze

szkolnych systemów informatycznych. Wymagane jest wskazanie, które z pól formularzy rekrutacyjnych będą wypełnione danymi z systemów szkolnych.

Podczas ewentualnej prezentacji wymagane jest zaprezentowanie przenoszenia informacji z systemu szkolnego do formularza rekrutacyjnego.

ER – 039

System powinien umożliwiać przejmowanie z domeny publicznej informacji o historycznych wynikach egzaminów w szkołach, celem prezentacji w

systemie danych o historycznych wynikach egzaminów w szkołach.

ER – 040

System powinien posiadać możliwość wskazania interesujących użytkownika kierunków studiów, a następnie przekazywania mu bieżącej informacji o szansie dostania się na wybrane kierunki. Podczas ewentualnej prezentacji wymagana jest możliwość modyfikacji wprowadzonych danych, takich jak

wynik egzaminu maturalnego i sprawdzanych kierunków studiów.

ER – 041

System musi umożliwiać przeprowadzenie wielowymiarowych analiz pozwalających na identyfikację trendów i korelacji związanych z rekrutacją w analizowanych danych z uwzględnieniem kategorii informacji takich jak:

płeć, rok rozpoczęcia studiów, pochodzenie, wiek, forma, poziom i kierunek studiów. Wizualizacja wyników analiz musi być dostępna w formie raportów i interaktywnych prezentacji z wykorzystaniem systemów typu Business

Intelligence

2.4.2. E-usługa E-Student

Cel realizacji e-usługi: usługa umożliwi studentom składanie podań w formie elektronicznej. Uwierzytelniony student Uczelni będzie miał możliwość składania podania zgodnie z obowiązującymi wzorami dokumentów na Uczelni. Wypełnione formularze elektroniczne wraz z załączonymi dokumentami, trafią do właściwych jednostek organizacyjnych Uczelni w celu ich rozpatrzenia. Na każdym etapie złożonego podania, student ma możliwość podglądu statusu swojego dokumentu. Po rozpatrzeniu podania pozytywnie lub negatywnie, student otrzymuję informację drogą mailową z informacją nt. swojego podania. Uruchomienie usługi umożliwi złożenie podania z dowolnego miejsca. Do złożenia podania będzie potrzebne aktywne konto w systemie - konto studenta jak również konto dowolnego pracownika, który będzie upoważniony do składania podań w imieniu studenta. Usługa obejmie następujące procesy składania wniosków: wniosek o dokonanie sprostowania/ zmiany danych osobowych; wniosek o indywidualną organizację toku studiów; wniosek o przeprowadzenie egzaminu komisyjnego; wniosek o udzielenie urlopu; wniosek o wydanie odpisu dyplomu ukończenia studiów w tł. na język obcy; wniosek o wyrażenie zgody na powtarzanie modułu/ów zajęć; wniosek o wyrażenie zgody na przeniesienie do innej Uczelni; wniosek o wyrażenie zgody na zmianę kierunku/formy studiów; wniosek o wznowienie studiów; wniosek o zwolnienie z opłaty za studia lub inne usługi edukacyjne; wniosek w sprawie rezygnacji ze studiów; wniosek o zwolnienie z opłaty za studia lub inne usługi edukacyjne; odwołanie od decyzji o skreśleniu z listy studentów oraz wniosek ogólny; wniosek o wydanie dyplomu, wniosek o wydanie kopii dyplomu oraz wniosek o wydanie zaświadczenia o ukończeniu studiów. Usługa umożliwi przeprowadzenie procesu rejestracji oraz weryfikacji prac dyplomowych studentów z zachowaniem ścieżki akceptacji. Weryfikacja prac dyplomowych będzie oparta na dwóch etapach – oceny merytorycznej, przeprowadzanej przez pracownika dydaktycznego oraz możliwość integracji z systemem antyplagiatowym.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-student zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
XX-0	X-xxxxxxx
XX-0	System musi umożliwiać studentom składanie podań w formie elektronicznej poprzez stronę www z dowolnego miejsca.	W
ES-3	System musi umożliwiać definiowanie formularzy dynamicznych które będą realizowały odpowiednie wnioski składane przez studentów	W
ES-4	Lista wniosków realizowanych które musie realizować system: 1. wniosek o dokonanie sprostowania/ zmiany danych osobowych, 2. wniosek o indywidualną organizację toku studiów, 3. wniosek o przeprowadzenie egzaminu komisyjnego, 4. wniosek o udzielenie urlopu, 5. wniosek o wydanie odpisu dyplomu ukończenia studiów w tł. na język obcy, 6. wniosek o wyrażenie zgody na powtarzanie modułu/ów zajęć, 7. wniosek o wyrażenie zgody na przeniesienie do innej Uczelni, 8. wniosek o wyrażenie zgody na zmianę kierunku/formy studiów, 9. wniosek o wznowienie studiów, 10. wniosek o zwolnienie z opłaty za studia lub inne usługi edukacyjne, 11. wniosek w sprawie rezygnacji ze studiów, 12. wniosek o zwolnienie z opłaty za studia lub inne usługi edukacyjne, 13. odwołanie od decyzji o skreśleniu z listy studentów oraz wniosek ogólny, 14. wniosek o wydanie dyplomu, 15. wniosek o wydanie kopii dyplomu, 16. wniosek o wydanie zaświadczenia o ukończeniu studiów.	W
ES-5	System musi umożliwiać przeprowadzenie procesu rejestracji oraz weryfikacji prac dyplomowych studentów z zachowaniem ścieżki akceptacji.	W
ES-6	Weryfikacja prac dyplomowych musi być oparta na ocenie merytorycznej – przeprowadzanej przez pracownika dydaktycznego. Musi także istnieć możliwość oceny przez zewnętrzny system antyplagiatowy, który będzie zintegrowany z systemem E-student	W
ES-7	Student musi mieć możliwość sprawdzenia z dowolnego miejsca i o dowolnej godzinie statusu złożonego przez siebie wniosku.	W
ES-8	Student musi mieć możliwość sprawdzenia z dowolnego miejsca i o dowolnej godzinie statusu złożonego przez pracownika wniosku w jego imieniu.	W
ES-9	System musi automatycznie wysyłać powiadomienia e-mail do studenta przy każdej zmianie statusu wniosku.	W
ES-10	System musi rejestrować do wniosku między innymi dane: 1. adres e-mail, 2. nazwisko, 3. nazwisko xxxxxx, 4. imię, 5. płeć, 6. dane uzupełniające (Kierunek Studiów, Specjalizacja, Tryb studiów, Rodzaj studiów, Nr albumu, Semestr, Rok studiów, Katedra, Dziekanat – do sterowania obiegiem jaka jednostka dostaje podania), 7. adres, 8. adres do korespondencji, 9. dane identyfikacyjne pracownika (Xxxx, nazwisko, identyfikator pracownika naukowego lub administracji),	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	10. identyfikator dokumentu (Dane identyfikacyjne dokumentów, których sprawa dotyczy), 11. treść (treść dokumentów których sprawa dotyczy), 12. Dane słownikowe (Wykładowcy, katedry, przedmioty i inne).
ES-11	Dane osobowe studenta muszą być pobierane z systemu dziekanatowego posiadanego przez Uczelnię na podstawie loginu pobieranego z usługi katalogowej Active Directory i automatycznie dołączane do składanego wniosku.	W
ES-12	System musi umożliwić studentom składanie podań w formie elektronicznej.	W
ES-13	Każdy Student Uczelni będzie miał możliwość składania podania zgodnie z obowiązującymi wzorami dokumentów na Uczelni.	W
ES-14	Wypełnione formularze elektroniczne, wraz z załączonymi dokumentami w formie elektronicznej, muszą trafić do właściwych jednostek organizacyjnych Uczelni w celu rozpatrzenia.	W
ES-15	Podanie musi trafić do pracownika administracyjnego właściwego dla danego podania, który może dodać swoje adnotacje lub uzupełnić o stosowne załączniki i dokonać akceptacji podania lub wezwać studenta do dokonania korekt lub uzupełnień.	W
ES-16	System musi umożliwić przekazanie podania od pracownika administracyjnego do decydenta podejmującego decyzję.	W
ES-17	Na każdym etapie złożonego podania, Student musi mieć możliwość podglądu statusu swojego dokumentu.	W
ES-18	Po rozpatrzeniu podania pozytywnie lub negatywnie, Student musi otrzymać maila z informacją nt. swojego podania.	W
ES-19	System musi umożliwić składanie podań zarówno przez Studenta jak i przez dowolnego pracownika Uczelni, który będzie do tego upoważniony.	W
ES-20	System musi umożliwiać złożenie podania z dowolnego miejsca - wystarczy aktywne konto w systemie.	W
ES-21	System musi umożliwiać stworzenie repozytorium cyfrowych podań.	W
ES-22	System musi być zintegrowany z systemem dziekanatowym używanym na Uczelni w zakresie: -pobieranie danych studenta do wniosków i odwołań.	W

2.4.3. E-usługa E-tablica ogłoszeń

Usługa e-tablica ogłoszeń powinna pozwolić na informowanie użytkowników o bieżących i przyszłych wydarzeniach związanych z Uczelnią. Usługa e-tablica ogłoszeń dostępna poprzez Platformę powinna umożliwić:

1. umieszczenie ogłoszeń o ważnych z punktu widzenia funkcjonowania Uczelni sprawach x.xx. zarządzenia rektora; informacje o ofercie Uczelni, informacje o wydarzeniach z działalności Uczelni,

2. prezentacja komunikatów dla studentów w budynkach Uczelni na monitorach wyposażonych w minikomputer do prezentacji treści.

Cele usługi e-tablica ogłoszeń:

1. dostęp do ważnych informacji przez studentów, doktorantów oraz kandydatów na studia oraz innych zainteresowanych ofertą lub działalnością Uczelni;

2. umożliwienie dostępu do danych i informacji - komunikatów, informacjami o odbywanych zajęciach, zmianach dotyczących przesunięcia terminu lub miejsca wykładu lub ćwiczeń

3. angażowanie się studentów w życie Uczelni poprzez przekazywanie im przygotowanych informacji na rozmieszczonych monitorach

4. informowanie o ofercie Uczelni dla wszystkich obywateli (szkolenia, wykłady otwarte, prelekcje, konferencje, kierunki kształcenia, świadczenie usług doradczych dla obywateli)

Za realizację oraz zapewnienie jakości świadczonych e-usług odpowiedzialne będą Dział Informatyki, Dział Kształcenia, Dział Promocji oraz poszczególne jednostki organizacyjne Uczelni.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-tablica ogłoszeń zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
ET-1	E-tablica ogłoszeń
ET-2	System musi pozwalać na realizację E-tablicy ogłoszeń, będącej elektroniczną informacją dla wszystkich interesariuszy.	W
ET-3	System musi prezentować informacje skierowane do studentów, doktorantów, kandydatów na studia oraz innych zainteresowanych ofertą lub działalnością Uczelni.	W
ET-4	System musi informować użytkowników o bieżących i przyszłych wydarzeniach na Uczelni.	W
ET-5	System musi pozwalać na zamieszczenie ogłoszeń o ważnych z punktu widzenia funkcjonowania Uczelni sprawach x.xx. zarządzenia rektora, informacje o ofercie Uczelni, informacje o wydarzeniach z działalności.	W
ET-6	System musi prezentować komunikaty dla studentów w budynkach Uczelni na monitorach.	W
ET-7	System musi pozwalać na prezentację informacjami o odbywających się zajęciach, zmianach dotyczących przesunięcia terminu lub miejsca wykładu lub ćwiczeń.	W
ET-8	E-tablica ogłoszeń musi informować o ofercie Uczelni dla wszystkich obywateli (szkolenia, wykłady otwarte, prelekcje, konferencje, kierunki kształcenia, świadczenie usług doradczych dla obywateli).	W
ET-9	System musi umożliwiać odbiór informacji na ekranach telewizorów, komputerach, tabletach lub smartfonach.	W
ET-10	Prezentacja treści na E-tablicach ogłoszeń musi odbywać się poprzez dowolną przeglądarkę internetową.	W
ET-11	Wygląd i prezentacja wyświetlanych treści musi być wykonana w technologii HTML (HyperText Markup Language) i CSS (Cascading Style Sheets).	W
ET-12	System musi prezentować informację w sposób dynamiczny, tzn. nie dopuszczalne jest przeładowywanie strony.	W
ET-13	System musi posiadać mechanizmy cache, bez konieczność każdorazowego odpytywania bazy danych.	W
ET-14	Grafika wyświetlanych treści musi być wykonana w technologii RWD (Responsive Web Design).	W
ET-15	Wygląd i układ komunikatów E-tablicy ogłoszeń musi dostosowywać się automatycznie do rozmiaru okna urządzenia, na którym jest wyświetlany.	W
ET-16	System komunikatów musi funkcjonować w obrębie pojedynczej domeny www, pod którą skonfigurowana jest E-tablica ogłoszeń.	W
ET-17	System komunikatów musi pozwalać na prezentację uniwersalnych komunikatów, dostępnych z dowolnej lokalizacji.	W
ET-18	System komunikatów musi pozwalać na personalizowanie treści pod konkretne urządzenie.	W
ET-19	System musi pozwalać na definiowanie nieograniczonej liczby urządzeń, na których mają być wyświetlane komunikaty.	W
ET-20	System musi weryfikować czy ekran, na którym wyświetlane są informacje, posiada spersonalizowane treści czy wyświetla ogólne informacje.	W
ET-21	System musi pozwalać na konfigurację i zarządzanie treściami wyświetlanymi na tablicach	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	ogłoszeń z poziomu dowolnej przeglądarki internetowej.
ET-22	System musi pozwalać na dodawanie treści takich jak: 1. filmy, 2. zdjęcia, 3. komunikaty tekstowe.	W
ET-23	System musi pozwalać na prezentację zdefiniowanych treści w postaci typów takich jak: 1. bloków tekstowych, 2. bloków ze zdjęciami, 3. slider , 4. pasek informacyjny, 5. rozkład zajęć.	W
ET-24	Slider musi pozwalać na prezentację wielu rotujących się plansz, na które składają się zdjęcia, tytuł ora krótki opis	W
ET-25	Pasek informacyjny musi pozwalać na prezentację wielu rotujących się w poziomie komunikatów, w postaci przewijanego tekstu.	W
ET-26	Rozkład zajęć musi pozwalać na prezentację wielu rotujących się w pionie komunikatów, prezentujących rozkład zajęć Sali, przy której znajduje się ekran.	W
ET-27	System musi pozwalać na definiowanie i zarządzanie układem elementów (bloków) na ekranie.	W
ET-28	Definicja pojedynczego bloku to: 1. nazwa bloku, 2. typ bloku.	W
ET-29	Dostępne w systemie bloki, muszą odpowiadać zdefiniowanym typom treści.	W
ET-30	System musi pozwalać na konfigurację układu ogólnego E-tablicy ogłoszeń oraz dla każdego ze zdefiniowanych urządzeń oddzielnie.	W
ET-31	Zarządzanie układem ekranu musi odbywać się za pomocą mechanizmów drag&drop (przeciągnij i upuść).	W
ET-32	System musi pozwalać na zdefiniowanie wielu niezależnych bloków informacyjnych w ramach konkretnego układu ekranu.	W
ET-33	System musi pozwalać na ustawienie pojedynczego bloku w konkretnym miejscu ekranu i nadanie mu pożądanego kształtu za pomocą rozciągania go kursorem.	W
ET-34	System musi prezentować na monitorze ustawienie ekranu, ściśle odpowiadające przeprowadzonej konfiguracji.	W
ET-35	System musi pozwalać na definiowanie wielu niezależnych informacji.	W
ET-36	Na pojedynczą informację muszą składać się przynajmniej: 1. nazwa informacji, 2. typ informacji (tekst, zdjęcie, slider, pasek) 3. kontrolka do wprowadzenia informacji w zależności od jej typu, 4. wybór ekranu, na którym dana informacja ma się wyświetlić.	W
ET-37	System musi pozwalać na przypisanie pojedynczej informacji do wielu ekranów, w tym do głównego.	W
ET-38	System musi pozwalać na zarządzanie publikacją pojedynczej informacji za pomocą jej statusu.	W
ET-39	System musi pozwalać na zarządzanie publikacją pojedynczej informacji za pomocą dat jej publikacji.	W

2.4.4. E-usługa E-kontakt

Cel: Realizacja funkcjonalności powinna skupiać się na Interaktywnych kalendarzach e-kontakt umożliwiających umawianie się na spotkania z wykładowcą. Student musi mieć podgląd kalendarza wykładowcy, powinien mieć możliwość wysłania zapytania dotyczącego możliwości spotkania w danym terminie, natomiast wykładowca powinien mieć możliwość potwierdzenia takiego terminu spotkania. Kalendarz musi również automatycznie wyświetlać terminy zajęte tym samym automatyzując proces rezerwacji terminów. Student logując się na swoją stronę WWW powinien mieć możliwość sprawdzenia kalendarza z dostępnością poszczególnych osób, do których uczęszcza na zajęcia/wykłady. Poprzez wybranie odpowiedniej daty, godziny, proponowanej długości czasu spotkania powinien mieć możliwość, z poziomu przeglądarki WWW, umówić się na konsultacje z nauczycielem. Na konsultacje z dedykowanymi osobami z Uczelni powinny mieć możliwość umówienia się za pośrednictwem portalu WWW także osoby nie będące studentami.

Usługę będzie świadczył Dział „Nowy wymiar studiowania” przy wsparciu Działu Informatyki, także sami pracownicy dydaktyczni powinni mieć możliwość określać swoje kalendarze spotkań.

System musi przewidzieć integrację z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych, posiadających profil zaufany w przedmiotowym systemie.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-kontakt zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EK-1	E-kontakt
EK-2	System musi umożliwiać zapisywanie się na spotkania z wykładowcą.	W
EK-3	System musi przechowywać i wyświetlać kalendarz dostępnych terminów spotkań.	W
EK-4	System musi wyświetlać terminy już zarezerwowane.	W
EK-5	System musi umożliwiać zaakceptowanie lub odrzucenie przez wykładowcę terminu.	W
EK-6	Osoba chcąca zapisać się na spotkanie będzie mogła wybrać datę i godzinę proponowanego spotkania (w ramach dostępnych terminów) oraz proponowaną długość czasu spotkania (wg ustalonej na etapie wdrożenia siatki godzin).	W
EK-7	Terminy spotkań i sale oraz dane o wykładowcach muszą być pobierane z systemu dziekanatowego Zamawiającego i zapisywane w systemie. Aktualizacja danych musi odbywać się przynajmniej raz dziennie za pomocą mechanizmów CRON (mechanizmy do harmonogramowania zadań).	W
EK-8	Osoba zapisująca się na spotkanie musi mieć możliwość załączenia pliku (przynajmniej: .pdf, .doc, .docx, .xls, .xlsx, .otd, .ppt) do zgłoszenia.	W
EK-9	System musi informować osobę zapisującą się na spotkanie o odrzuceniu bądź akceptacji spotkania drogą mailową. W przypadku odrzucenia spotkanie, wykładowca ma mieć możliwość dodania komentarza, który zostanie wysłany w mailu do studenta.	W
EK-10	System w wysyłanym mailu do wykładowcy z prośba o potwierdzenie bądź odrzucenie terminu musi mieć możliwość akceptacji terminu z poziomu maila, bez konieczności logowania się do systemu.	W
EK-11	System musi przechowywać informacje o zapisach na spotkania w koncie użytkownika. Informacje te muszą być możliwe do sprawdzenia w każdym z serwisów systemu multiportalowego w którym jest włączone logowanie	W
EK-12	W przypadku usunięcia terminów spotkań w systemie dziekanatowym Zamawiającego, na które już były potwierdzone spotkania, system musi automatycznie poinformować studentów o takiej zmianie.	W
EK-13	System na liście dostępnych wykładowców wyświetli wszystkich którzy mają włączone uprawnienia do zarzadzania swoimi spotkaniami.	W
EK-14	Wykładowca otrzymując informacje o prośbie zapisania się na spotkanie od studenta,	W

Nr wymagania

Opis wymagania

Funkcjonalność W/O

musi otrzymać informacje o danej osobie: imię, nazwisko, identyfikator, e-mail, nr

telefonu, plik (jeśli został dołączony).

2.4.5. E-usługa E-wykłady

Cel: e-usługa powinna zapewnić przeprowadzanie wideokonferencji i rejestracji wykładów, które w ramach platformy mogą być udostępnianie studentom oraz innym zainteresowanym podmiotom (instytucje, osoby fizyczne). Do realizacji e-usługi zaplanowano specjalną salę wyposażoną w sprzęt AV.

Usługa powinna umożliwić:

1. udostępnianie wykładów „na żywo” na odpowiednich portalach WWW

2. nagrywanie wykładów i zapisywanie ich do pliku, następnie udostępnianie przez strony WWW odpowiednim grupom studentów, lub wszystkim osobom zainteresowanym wykładem

3. umożliwienie transmisji wykładu prowadzonego w zdalnej lokalizacji dla grupy słuchaczy/studentów zgromadzonych w przystosowanej do tego sali/auli

4. przeprowadzenie interaktywnej konferencji/spotkania pomiędzy dwoma lokalizacjami wyposażonymi w systemy wideokonferencyjne

Główne obszary e-usługi:

a) System powinien udostępniać transmisję wykładów na żywo

Projektor z obiektywem musi umożliwić wyświetlenie obrazu na ekranie projekcyjnym dla studentów znajdujących się w auli. Obraz zarówno dla projektora jak i dla urządzenia transmitującego obraz na żywo do Internetu powinien być realizowany przez terminal z kamerą HD. By przekazać obraz HD do projektora należy przewidzieć odpowiedni odbiornik i nadajnik HDMI. Kolumny głośnikowe podłączone do wzmacniacza powinny umożliwić nagłośnienie sali wykładowej. Sygnał zarówno do głośników jak i do urządzeń transmitujących wykład powinien być zapewniony poprzez zastosowanie bezprzewodowych mikrofonów do ręki, mikrofony krawatowe i nagłowne, mikrofon stołowy. By mikrofony bezprzewodowe mogły pracować należy zastosować splitter antenowy z anteną dipolową. By sygnał z kilku mikrofonów nie wywoływał efektu szumu należy wpiąć mikrofony do procesora antysprzężeniowego. By sterować urządzeniami znajdującymi się w auli potrzebny jest moduł przekaźników, swich z PoE, acces point Wi-Fi, który umożliwi komunikację tabletu z jednostką centralną.

Dzięki zastosowaniu serwera nagrywania i strumieniowania, terminala z kamerą HD (camera dual display 1080p) wraz z odpowiednio podłączonymi mikrofonami musi być możliwość transmisji wykładów przez Internet na żywo. Kamera wraz z mikrofonami przechwytuje obraz i dźwięk z wykładu i poprzez jednostkę centralą system sterowania z matrycą AV przekaże sygnał do serwera nagrywania i strumieniowania. To urządzenie musi być podłączone do Internetu dzięki czemu po wejściu na odpowiednią stronę będzie możliwość oglądania i słuchania na żywo wykładu prowadzonego w auli Uczelni.

b) udostępnianie nagranych wykładów,

Serwer nagrywania i strumieniowania zapewni także kompresję dźwięku oraz obrazu oraz zapisanie takiego wykładu jako pliku audio-video, który następnie po odpowiednim opisaniu zostanie opublikowane na strony WWW Uczelni jako materiał dydaktyczny.

Główne funkcjonalności usługi muszą być realizowane w obszarach:

a) Projekcja treści multimedialnych

b) Zarządzanie sygnałem AV

c) System dystrybucji dźwięku i nagłośnienia

d) Sterowanie i zarządzanie ustawieniami systemu

e) Integracja z systemami inteligentnego budynku

f) Komunikacja i transmisja sygnału AV

1. Projekcja

Do prezentacji treści przewidziany jest projektor o wysokiej jasności 8000 lumenów, posiadający natywną rozdzielczość obrazu 1920 x 1200 (WUXGA). Duża jasność projektora jest wymagana ze względu na wykorzystanie sali do prowadzenia wideokonferencji – należy zapewnić wysoką jakość obrazu przy oświetlonym pomieszczeniu. Źródłem światła w proponowanym projektorze jest półprzewodnikowy laser, który zastępuje tradycyjne lampy wyładowcze. Żywotność lasera wynosi 20000 godzin, a więc nie ma potrzeby wymiany lamp w trakcie całego cyklu eksploatacji urządzenia. Projektor zostanie wyposażony w obiektyw pozwalający uzyskać obraz o szerokości 400cm z odległości 8,5m. Ekran projekcyjny powinien odpowiadać proporcjami rozdzielczości wyświetlanego obrazu (16:10), dlatego planowany jest rozwijany elektrycznie model o wymiarach 400cm x 250cm. Ekran jest przeznaczony do montażu ściennego. Materiał projekcyjny biały matowy z czarną ramką.

2. Zarządzanie sygnałami AV

Źródłami obrazu w systemie mogą być dwa komputery z wyjściami wideo w formatach HDMI lub VGA i wizualizer. Należy przewidzieć dwa przyłącza audio-video wbudowane w stół. Przyłącza powinny być zabezpieczone klapką, która zabezpiecza gniazda przez przypadkowym uszkodzeniem i zanieczyszczeniem. W każdym przyłączu powinny znajdować się gniazda HDMI, VGA, jack 3,5mm, RJ45 i zasilanie 230V. Podłączone sygnały będą bezstratnie konwertowane do postaci pozwalającej na przesłanie ekranowaną skrętką kategorii 6 na odległość do 100m. Wszystkie sygnały powinny trafić do matrycy AV, w której zostaną poddane obróbce. Sygnały wideo mogą zostać w razie potrzeby przeskalowane w celu dopasowania rozdzielczości źródła obrazu do rozdzielczości projektora. Sygnały audio mogą zostać poddane korekcji barwy dźwięku i dynamiki, a następnie wysłane do wzmacniacza. Obraz do projektora powinien być wysyłany przez ekranowaną przewód sygnałowy (skrętka) o kategorii 6 i konwertowany do postaci HDMI.

3. Nagłośnienie

Głównym przeznaczeniem systemu nagłośnienia w tej instalacji powinno być przekazywanie mowy z bardzo dobrą zrozumiałością. W tym celu należy dobrać głośniki o liniowym układzie przetworników. Taka konstrukcja pozwala na równomierne pokrycie dźwiękiem całej po wierzchni pomieszczenia i zminimalizowanie niepożądanych odbić dźwięku. Charakterystyki głośników powinny być dobrane tak, aby zapewnić wysoką zrozumiałość mowy przy poziomie głośności komfortowym dla słuchaczy podczas kilkugodzinnego wykładu.

Do nagłośnienia mowy dostępne powinny być mikrofony bezprzewodowe: do ręki, nagłowny i przypinany krawatowy.

4. Sterowanie systemem AV

System audiowizualny składa się zazwyczaj z wielu urządzeń, których obsługa wymaga znajomości ich specyfikacji technicznych. Aby umożliwić samodzielną obsługę systemu osobom, które nie są biegłe w technologiach AV, należy przewidzieć system sterowania z graficznym interfejsem użytkownika. Widoczna część systemu powinna być dostępna przez panel dotykowy (tablet) z dedykowaną aplikacją, której funkcje będą indywidualnie programowane pod daną konfigurację sprzętu w instalacji. Wszystkie funkcje potrzebne do efektywnego wykorzystania sprzętu audiowizualnego powinny być dostępne w postaci intuicyjnych grafik. Podstawowe funkcje, takie jak włączanie i wyłączanie systemu, zmiana źródeł obrazu, regulacja głośności, zaciemnianie pomieszczenia i wykonywanie połączeń wideokonferencyjnych, powinny być dostępne na głównym ekranie, natomiast bardziej zaawansowane, takie jak diagnostyka stanu instalacji czy kontrola pojedynczych urządzeń, mogą zostać ukryte przed zwykłym użytkownikiem. Należy przewidzieć dwa panele. Jeden zainstalowany w naściennej stacji dokującej zabezpieczonej kodem PIN, drugi dostępny dla technika w reżyserce. Dodatkową funkcjonalnością powinien być wirtualny panel, który obsługuje się za pomocą dowolnego komputera PC, co powinno być pomocne w przypadku potrzeby wsparcia użytkownika z odległej lokalizacji. Niewidoczna dla użytkownika część systemu sterowania, to jednostka główna systemu wbudowana w matrycę AV. Urządzenia takie jak projektor, ekran, wizualizer, oświetlenie, wideokonferencja, sterowane powinny być przez porty RS-232, sieć LAN lub odpowiednie moduły.

5. Integracja

System audiowizualny powinien umożliwić integrację z oświetleniem i roletami, bądź żaluzjami zaciemniającymi pomieszczenie. Kontrola nad tymi funkcjonalnościami może być zapewniona z poziomu panelu kontrolnego, ale można również pozostawić równolegle działające tradycyjne włączniki ścienne.

6. Komunikacja

System powinien umożliwić łączenie się z innymi lokalizacjami (połączenie wideokonferencyjne) poprzez standardowe protokoły SIP i H.323, umożliwiając przeprowadzanie zdalnych wykładów lub dołączanie czynnych uczestników podczas trwania zajęć. Oprócz widoku zdalnej osoby system powinien umożliwić równoczesne wyświetlenie prezentacji, filmu lub innego rodzaju treści (obsługa jednocześnie dwóch strumieni wideo). Jakość połączenia powinna być realizowana na poziomie 720p60 dla każdego z wyświetlanych obrazów.

Dodatkowo system powinien umożliwić rejestrację prowadzonych zajęć oraz zdalny dostęp do zajęć dla uczestników biernych (uczestnicy, którzy mogą oglądać wykład, ale nie mogą zabrać głosu i nie są widoczni na ekranie w Sali; będą mogli natomiast komunikować się poprzez czat). Nagrane materiały, jak i materiały już posiadane przez Zamawiającego mogą zostać wykorzystane do budowania platformy VoD (Video on Demand – wideo na żądanie), do której dostęp będą posiadać studenci z odpowiednimi uprawnieniami.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-wykłady zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EW-1	E-wykłady
EW-2	System do nagrywania i dystrybuowania nagrań (na żywo i na żądanie)	W
EW-3	System musi być oferowany jako maszyna wirtualna (dostępna na platformą VMWare i Hyper-V)	W
EW-4	System musi być elastycznie licencjonowany, czyli umożliwia na początku zakup tylko niezbędnych licencji oraz późniejsze dokupienie licencji przy rozbudowie systemu	W
EW-5	Przy wykorzystaniu terminali tego samego producenta uruchomienie nagrywania z pozycji jednego przycisku; możliwość nagrywania wideokonferencji również przy użyciu wideoterminali innych producentów bazujących na protokole SIP wraz z kodekiem H.264	W
EW-6	System musi umożliwiać nagrywanie 1 sesji w jakości 720p30 (widok kamery, audio , prezentacja) oraz umożliwiać transmisję na żywo do 250 użytkowników.	W
EW-7	Możliwość rozbudowy do 20 jednoczesnych nagrań HD 720p i 2000 użytkowników odbierających transmisję na żywo (rozbudowa licencyjna)	W
EW-8	System musi pozwalać na dołączanie dodatkowych dokumentów do utworzonych nagrań np. prezentacja lub formularz pytań	W
EW-9	W celu łatwego odtwarzania nagrań oraz szybkiego lokalizowania potrzebnych fragmentów materiału, system musi umożliwiać na podział materiału na rozdziały	W
EW-10	Do nagrania musi być możliwość podłączenia plików z tłumaczeniem (min. 4 różne języki)	W
EW-11	System musi umożliwiać stworzenie niezależnych kanałów tematycznych, do których dostęp będą miały tylko uprawnione osoby.	W
EW-12	System musi umożliwiać udostępnienie każdego nagrania osobom, które nie posiadają konta dostępowego (bez konieczności tworzenia takiego konta)	W
EW-13	Podczas transmisji na żywo musi być aktywna funkcja czat	W
EW-14	System musi umożliwić dostęp do nagrań oraz transmisji na żywo z urządzeń mobilnych (tablet, smartfon)	W
EW-15	System musi umożliwiać, osobom zalogowanym, na dodawanie komentarzy do	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	nagrań

2.4.6. E-usługa E-lista obecności

Cel: E-Lista obecności (eLO) musi pozwolić na pełną obsługę i archiwizację danych dotyczących list obecności studentów na zajęciach dydaktycznych realizowanych na Uczelni. Moduł musi ułatwiać, wspomagać i przyspieszać pracę pracowników Uczelni, poprzez automatyzację procesu rejestrację obecności studentów, ograniczenie dokumentacji do wersji elektronicznych oraz centralizację danych dotyczących obecności studentów na zajęciach dydaktycznych.

Za pośrednictwem systemu świadczone musza być wysokopoziomowe usługi na rzecz studentów, pracowników dydaktycznych, pracowników komórek organizacyjnych każdego szczebla Uczelni .

e-Lista obecności, musi umożliwiać x.xx:

obsługę zdarzeń związanych z rejestracją obecności studentów Uczelni

przeglądanie zarejestrowanych list obecności dla wszystkich kierunków / grup ćwiczeniowych

tworzenie raportów i statystyk związanych z frekwencją studentów na różnych poziomach szczegółowości: dla studenta, dla grupy ćwiczeniowej, dla grupy wykładowej, kierunku, wydziału,

Użytkownikami Platformy będą studenci, pracownicy dydaktyczni, pracownicy komórek organizacyjnych zgodnie ze zdefiniowanymi uprawnieniami.

Dzięki integracji pomiędzy systemem E-lista obecności, a system dziekanatowym obecności studenta na zajęciach będą uwzględniane przez system wystawiania ocen z danego przedmiotu.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-lista obecności zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
ELO-1	e-Lista obecności
ELO-2	System musi posiadać narzędzia integracyjne z systemem dziekanatowym Uczelni	W
ELO-3	System musi przechowywać listę: pracowników, zajęć, grup ćwiczeniowych z systemu dziekanatowego Uczelni	W
ELO-4	System musi posiadać narzędzia integracyjne z systemem personalizacyjnym kart procesorowych Uczelni	W
ELO-5	System musi prezentować dane e-Listy obecności w postaci ograniczonej, to znaczy że dostęp do tych danych musi być ograniczony, np. poprzez logowanie.	W
ELO-6	System musi umożliwiać zdefiniowanie ról użytkowników do modułu e-Listy obecności uniemożliwiając określonym rolom (np. studentom) rejestrację Listy obecności	W
ELO-7	System musi umożliwiać pracownikom dydaktycznym rejestrację List obecności prowadzonych zajęć.	W
ELO-8	Podczas rejestracji Listy obecności pracownik dydaktyczny powinien określić: przedmiot oraz grupę dla której rejestrowana jest lista obecności.	W
ELO-9	System powinien zaprezentować pracownikowi dydaktycznemu domyślną listę studentów (imię, nazwisko, zdjęcie, nr albumu) przypisaną do grupy	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	ćwiczeniowej/wykładowej/laboratoryjnej
ELO-10	Rejestracja obecności na zajęciach musi odbywać się za pomocą Elektronicznej legitymacji studenckiej poprzez przyłożenie jej do czytnika kart procesorowych.	W
ELO-11	System powinien umożliwiać rejestrację obecności studentów na zajęciach przez zaznaczenie obecnych studentów na domyślnej liście studentów przypisanej do grupy ćwiczeniowej.	W
ELO-12	System powinien komunikować się z czytnikiem Kart procesorowych podpiętych do komputera pracownika.	W
ELO-13	Czytnik Kart procesorowych powinien komunikować się z modułem E-Listy obecności za pomocą oprogramowania zainstalowanego na komputerze pracownika dydaktycznego.	W
ELO-14	Oprogramowanie służące do komunikacji czytnika kart procesorowych z Modułem e-Listy obecności powinno być udostępnione w środowisku Uczelni z możliwością pobrania na komputer pracownika dydaktycznego a następnie intuicyjnego zainstalowania.	W
ELO-15	System powinien umożliwić rejestrację obecności studentów kierunku spoza grupy dla której rejestrowana jest lista obecności przez prowadzącego (np. odrabianie zajęć)	W
ELO-16	System musi umożliwiać podgląd zarejestrowanych list obecności dla pracowników dydaktycznych i pracowników jednostek administracyjnych	W
ELO-17	Zbiorcza lista zarejestrowanych List obecności musi umożliwiać filtrowanie danych co najmniej po wartościach: grupa / kierunek / przedmiot	W
ELO-18	System musi umożliwiać pracownikom dydaktycznym dostęp do Listy studentów uczestniczących w zajęciach pracownika dydaktycznego	W
ELO-19	System musi umożliwiać studentom wgląd w listę przedmiotów w których biorą udział oraz statystyki dotyczące obecności na zajęciach	W
ELO-20	System musi przekazywać do systemu dziekanatowego Uczelni dane dotyczące obecności studentów na zajęciach.	W
ELO-21	System musi umożliwiać pracownikom dydaktycznym, pracownikom jednostek organizacyjnych Uczelni generowanie zbiorczych raportów dot. frekwencji studentów dla: 1. kierunków studiów 2. toku studiów 3. zajęć dydaktycznych 4. grup ćwiczeniowych 5. poszczególnych studentów 6. zgodnie ze zdefiniowanym poziomem uprawnień	W
ELO-22	System musi umożliwiać studentom Uczelni generowanie raportów dot. frekwencji na wszystkich zajęciach dydaktycznych, w których uczestniczył	W
ELO-23	System powinien umożliwiać anulowanie lub poprawę listy obecności prowadzącemu zajęcia lub wyznaczonemu pracownikowi Uczelni w przypadku stwierdzenia niezgodności.	W
ELO-24	System musi umożliwić wykorzystanie Elektronicznej Karty Pracowniczej o parametrach technicznych jak stosowana obecnie u Zamawiającego Elektroniczna Legitymacja Studencka	W
ELO-25	System musi obsługiwać czytniki dualne kart procesorowych.	W
	Oprogramowanie do personalizacji Elektronicznej Karty Pracowniczej
ELO-26	System musi umożliwić wykonanie personalizacji graficznej i elektrycznej Elektronicznej Karty Pracowniczej według poniższych wymagań	W
ELO-27	System musi umożliwiać pobranie pracowników z systemu dziekanatowego lub kadrowego Zamawiającego	W
ELO-28	System musi umożliwiać wydanie Elektronicznej Karty Pracownika Zamawiającego	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
ELO-29	System musi posiadać możliwość wymiany danych z systemami: dziekanatowym kadrowymi zgodnie z Rozporządzeniem Rady Ministrów z dnia 11.10.2005 roku w sprawie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej	W
ELO-30	System musi umożliwić przechowywanie danych osobowych oraz zdjęć pracowników w bazie danych systemu	W
ELO-31	System misi zapewniać możliwość odczytywania i zapisywania w bazie danych systemu numerów fabrycznych (CSN) wydawanych kart odrębnie dla części stykowej i bezstykowej	W
ELO-32	System musi umożliwiać wydanie duplikatu Elektronicznej Karty Pracownika	O
ELO-33	System musi umożliwiać numerowanie kolejnych duplikatów	O
ELO-34	System musi umożliwiać generowanie raportów z wydań kart	O
ELO-35	System powinien umożliwić określenie terminu ważności karty	O
ELO-36	System powinien umożliwić anulowanie ważności karty	W
ELO-37	System misi zapewniać możliwość drukowania obydwu stron kart w jednym cyklu personalizacji w tym wydruku na kartach kodu kreskowego	O
ELO-38	System misi umożliwiać Inicjalizację karty i tworzenie struktury danych na kartach	W
ELO-39	System musi umożliwiać personalizację elektroniczna i graficzna kart w jednym przebiegu	W
ELO-40	System musi umożliwiać definiowanie przynajmniej 24 grup użytkowników	O
ELO-41	System musi umożliwiać definiowanie przynajmniej 24 szablonów wydruku kart	O
ELO-42	System musi umożliwiać drukowanie potwierdzenia opłaty za wydanie karty	O
ELO-43	System musi umożliwiać definiowanie różnych taryf opłat za wydanie karty i duplikatu	O
ELO-44	System musi zapewniać dostęp (zapis/odczyt) do danych w bazie głównej systemu personalizacji kart	W
ELO-45	System powinien posiadać możliwość generowania kluczy wzorcowych (mother keys), zapisywanych tylko i wyłącznie na karcie procesorowej	W
ELO-46	Mechanizm generowania kluczy wzorcowych powinien umożliwiać wygenerowanie dla części stykowej 3 różnych kluczy	O
ELO-47	Mechanizm generowania kluczy wzorcowych powinien umożliwiać wygenerowanie dla części bezstykowej standardu Mifare, 16 różnych kluczy. Obecnie wykorzystywane karty na Uczelni mają układ bezstykowy typu Mifare.	O
ELO-48	Mechanizm generowania kluczy powinien wykorzystywać chwilowe wartości bufora klawiatury oraz pozycji myszki	O
ELO-49	System powinien posiadać funkcjonalność • rejestracji kart z kluczami w systemie, • wykonywania kopii kart z kluczami, • zmiany numerów PIN kart zawierających klucze • odblokowywania numerów PIN kart z kluczami	W
ELO-50	Mechanizm zabezpieczania Elektronicznych Kart Pracowników zarówno w części stykowej jak i bezstykowej powinien wykorzystywać mechanizm dywersyfikacji kluczy w oparciu o wygenerowane klucze wzorcowe	W
ELO-51	System powinien posiadać funkcjonalności obróbki fotografii takie jak • Możliwość współpracy z aparatami cyfrowymi oraz skanerami • Możliwość definiowania katalogu wejściowego zdjęć (przed obróbką) • Możliwość definiowania katalogu wyjściowego zdjęć (po obróbce) • Automatyczne uruchamianie aplikacji do obróbki fotografii po zapisaniu zdjęć w	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	katalogu wejściowym • Obsługiwane formaty plików graficznych: mapa bitowa (.bmp), plik JPG (.jpg, .jpe, .jpeg • Możliwość edycji następujących parametrów zdjęć: jasność, kontrast, nasycenie barw, rozmiar, skala, obrót, przesuwanie zdjęcia w pionie i poziomie • Możliwość wykadrowania zdjęcia poprzez zaznaczenie obszaru kadrowania • Możliwość podglądu i akceptacji wstępnie skadrowanego zdjęcia • Możliwość cofnięcia i powtórzenia operacji kadrowania • Automatyczne uruchamianie interfejsu umożliwiającego połączenie zdjęcia z danymi osobowymi po zaakceptowaniu kadru • Automatyczne kierowanie obrobionych zdjęć do zdefiniowanego katalogu wyjściowego
ELO-52	System powinien umożliwiać łączenie zdjęć z danymi pracowników w zakresie • Możliwość zapisania w bazie danych nowego zdjęcia • Możliwość podmiany zdjęcia wcześniej zapisanego w bazie danych	W
ELO-53	System powinien umożliwiać wyszukiwanie danych osobowych według filtru przynajmniej po następujących polach: Imię, Nazwisko, PESEL , Nr kadrowy	W
ELO-54	System musi umożliwiać ręczne wprowadzenie danych osobowych pracownika	W
ELO-55	System musi umożliwiać przeglądanie listy wyszukanych osób wraz z możliwością edycji danych	W
ELO-56	System powinien umożliwiać definiowanie trybu pracy programu zgodnie z poniższymi elementami • personalizacja graficzna, • inicjalizacja elektryczna części stykowej • inicjalizacja elektryczna części bezstykowej, • tworzenie logów zapisów dokonywanych na karty	W
ELO-57	System powinien posiadać możliwość sterowania następującymi elementami pracy drukarki do momentu zadruku karty.: • ładowanie karty do programatora, • wysuwanie karty, • zerowanie drukarki, • wydruk kontrolny, • test palety kolorów	O
ELO-58	System powinien posiadać możliwość konfiguracji programu, dostępne opcje konfiguracyjne: wybór rodzaju drukarki, wybór szablonu wydruku oraz możliwość testowego wydruku szablonu	O
ELO-59	System powinien umożliwiać wydruk pojedynczej karty bądź całej grupy kart	W
ELO-60	System powinien umożliwiać podgląda statystyk bazy danych, co najmniej na podstawie danych • liczba osób w bazie, • liczba osób, którym wydano kartę, • liczba osób, którym nie wydano karty, • liczba wydanych duplikatów, • liczba kart błędnie spersonalizowanych, • liczba zdjęć w bazie danych	O
ELO-61	System powinien umożliwiać podgląd statusu karty użytkownika, • karta wydana,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	• karta ma zdjęcie, • karta jest repliką, • karta jest zawieszona, • karta jest duplikatem, • karta jest unieważniona, • wydano replikę/duplikat karty, • karta została zwrócona
ELO-62	System powinien posiadać możliwość definiowania różnych kolejek wydruku i przypisywania im zadań według definiowanych przez użytkowników filtrów	O
ELO-63	System powinien posiadać możliwość integracji z Active Directory	W
ELO-64	System powinien posiadać możliwość zakładania kont w Active Directory	W
ELO-65	System powinien posiadać możliwość synchronizacji danych w Active Directory na podstawie wprowadzonych danych w systemie personalizacyjnym np. nr wydanej karty, status karty	W
ELO-66	System powinien posiadać możliwość aktualizacji danych na podstawie informacji z posiadanego przez Uczelnię z Active Directory	W

2.4.7. E-usługa E-klinika prawa

Usługa skierowana do studentów ma na celu wsparcie kształcenia praktycznego. Kontakt z rzeczywistymi przypadkami i możliwość pracy nad nimi da studentom możliwość wykorzystania nabytej wiedzy teoretycznej w praktyce. Do udzielania porad prawnych w ramach e-usługi uprawnieni przewiduje się przydzielenie studentów IV i V roku, a wyjątkowo III roku, studiujący na kierunku „prawo” w Uczelni z bardzo dobrymi wynikami w nauce.

Porady prawne będą prowadzone w ramach platformy, która obejmować będzie następujące moduły:

1. rejestracja zainteresowanych udzieleniem porady;

2. konto klienta kliniki, w ramach którego będzie można zgłosić wniosek o udzielnie porady prawnej i ustalić zakres konsultacji;

3. panel administracyjny (edycja danych klientów, ewidencja doradców biznesowych, kalendarz dyżurów doradców biznesowych, przydzielanie spraw, kalendarz spraw, ewidencja spraw itp.).

Działalność konsultingowa Kliniki Prawa dodatkowo powinna być uzupełniona o:

1. wyszukiwarkę orzecznictwa sądowego dotyczącego spraw z zakresu ubezpieczeń społecznych – na podstawie kryterium przedmiotowego

2. wyszukiwarkę pism procesowych w sprawach karnych, cywilnych, rodzinnych, prawa pracy i ubezpieczeń społecznych – na podstawie kryterium przedmiotowego

3. wyszukiwarkę orzecznictwa dotyczącego pozycji prawnej skazanego i instrumentów prawnych służących ochronie jego praw – na podstawie kryterium przedmiotowego

4. wzory pism procesowych w sprawach wskazanych powyżej, umożliwiającą wprowadzenie danych faktycznych i uzasadnienia prawnego do gotowego wzorca pisma procesowego

5. wybrane orzecznictwo sądowe i administracyjne dotyczące pozycji prawnej oraz obowiązków ucznia – na podstawie kryterium przedmiotowego

Cel: Działalność Kliniki Prawa będzie służyć zwiększeniu świadomości prawnej osób zainteresowanych uzyskaniem porady prawnej, ułatwiać ich funkcjonowanie w społeczeństwie zorganizowanym na podstawie norm prawnych, a także umożliwi lepszą ochronę ich interesów prawnych.

Moduł przewiduje integrację z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych, posiadających profil zaufany w przedmiotowym systemie.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-lista klinika prawa zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-1	E-klinika prawa
EKP-2	Usługa E-klinika prawa skierowana do studentów, musi wspierać kształcenie praktyczne. Narzędzie musi wspomagać wykorzystanie nabytej wiedzy teoretycznej w praktyce.	W
EKP-3	System musi ułatwiać oraz przyśpieszać proces udzielania porad prawnych przez studentów.	W
EKP-4	System w ramach e-usługi musi udostępniać mechanizmy pozwalające na nadawanie uprawnień studentom do modułu E-klinika prawa.	W
EKP-5	Moduł musi umożliwiać: 1. Rejestrację osób zainteresowanych udzielaniem porad; 2. Rejestrację konta klienta, osoby zainteresowanej otrzymaniem porady prawnej; 3. Zgłoszenie wniosku o udzielenie porady prawnej; 4. Określenie zakresu konsultacji - wybór obszaru ze zdefiniowanej listy; 5. Przegląd zgłoszonych wniosków; 6. Podgląd statusu zgłoszonych wniosków;	W
EKP-6	Moduł musi umożliwiać studentom zgłoszenie chęci współpracy w ramach działalności prowadzonej przez E-klinikę prawa.	W
EKP-7	Zgłoszenia współpracy muszą być realizowane poprzez formularz internetowy.	W
EKP-8	Moduł w ramach swoich funkcjonalności przewidywać musi możliwość integracji z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych.	W
EKP-9	Moduł musi umożliwiać określenie danych informacyjnych charakteryzujących zakres działania E-kliniki prawa w tym: 1. Regulamin 2. Informacje prawne 3. Materiały pomocnicze 4. Załączniki	W
EKP-10	Moduł musi pozwalać na określenie operatorów usługi, poprzez nadanie uprawnień, w tym: 1. Osoby potwierdzające rejestrację terminów spotkań; 2. Opiekuna sekcji; 3. Osoby rozpatrujące sprawy;	W
EKP-11	Moduł musi pozwalać na wprowadzenie danych personalnych klienta w celu przeprowadzenia rejestracji terminu spotkania.	W
EKP-12	Moduł musi pozwalać na przesłanie powiadomienia drogą mailową zawierającego potwierdzenie spotkania.	W
EKP-13	Moduł musi umożliwiać określenie danych informacyjnych charakteryzujących sprawę w tym: 1. Rodzaj sprawy; 2. Załączone dokumenty dotyczące sprawy; 3. Opis oraz opinie sprawy;	W
EKP-14	Moduł musi pozwalać na kategoryzowanie spraw.	W
EKP-15	W module musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii/rodzaju sprawy.	W
EKP-16	Moduł musi pozwalać na definiowanie danych opisowych spraw w celach informacyjnych dla osób zainteresowanych.	W
EKP-17	Moduł musi pozwalać na dodawanie plików i załączników przy definiowaniu spraw.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-18	Moduł musi pozwalać na określenie osoby rozpatrującej zgłoszoną sprawę.	W
EKP-19	Moduł musi umożliwiać określenie status sprawy.	W
EKP-20	Pojedyncza sprawa musi zostać opisana przynajmniej przez następujące dane: 1. Tytuł sprawy 2. Data złożenia wniosku sprawy 3. Rodzaj sprawy 4. Opis sprawy 5. Lista załączników dotyczących sprawy 6. Status 7. Osoba rozpatrująca	W
EKP-21	Moduł musi udostępniać mechanizm potwierdzenia lub odrzucenia terminu konsultacji sprawy przez opiekuna sekcji.	W
EKP-22	Moduł musi posiadać mechanizm informujący osobę zapisującą się na spotkanie o odrzuceniu bądź akceptacji terminu konsultacji drogą mailową.	W
EKP-23	Moduł w wysyłanym powiadomieniu droga mailową, z prośba o potwierdzenie bądź odrzucenie terminu konsultacji, musi posiadać możliwość akceptacji terminu z poziomu wiadomości email, bez konieczności logowania się do systemu.	W
EKP-24	Moduł musi posiadać mechanizmy prezentacji wszystkich zdefiniowanych w systemie spraw osobom rozpatrującym.	W
EKP-25	Moduł musi prezentować wszystkie złożone wnioski w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania wpisów.	W
EKP-26	Moduł musi pozwalać na podgląd szczegółów złożonego wniosku, poprzez wejście w dany wniosek z poziomu listy.	W
EKP-27	Funkcjonalność składania wniosku dostępna będzie tylko dla zarejestrowanych w systemie użytkowników.	W
EKP-28	Wszyscy zalogowanie na froncie systemu użytkownicy muszą mieć dostęp do funkcjonalności „Mojego konta”.	W
EKP-29	System w ramach funkcjonalności „Moje konto” musi pozwalać na prezentację złożonych przez użytkownika spraw w postaci stronicowanej listy.	W
EKP-30	System musi pozwalać użytkownikom na podgląd szczegółów sprawy, dołączonych plików oraz statusu.	W
EKP-31	System musi pozwalać na konfiguracje harmonogramu otwarcia kliniki.	W
EKP-32	Harmonogram otwarcia E-kliniki prawa może być konfigurowany tylko przez uprawnionych użytkowników wewnętrznych systemu.	W
EKP-33	System musi pozwalać na zdefiniowanie przedziałów godzin, w których możliwe będą konsultacje z osobami rozpatrującymi.	W
EKP-34	Formularz konfiguracji przedziałów czasowych musi być zawierać przynajmniej dane: 1. Dzień – Data konsultacji; 2. Przedział godzinowy; 3. Miejsce konsultacji;	W
EKP-35	System musi pozwalać na zdefiniowanie konsultacji cyklicznych w wybranych dniach i przedziałach godzinowych.	W
EKP-36	Widok harmonogramu musi pozwalać na wyświetlanie: 1. w formie listy, 2. w formie kalendarza.	W
EKP-37	Widok harmonogramu w formie kalendarza to widok kalendarza miesięcznego z możliwością przeskoczenia do następnych miesięcy lub powrotu do poprzednich.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-38	Kalendarz musi prezentować dni tygodnia w postaci kafelków, musi zaznaczać aktualny dzień, musi zawierać opisy dni tygodnia.	W
EKP-39	W przypadku wystąpienia konsultacji w danym dniu, kafelek kalendarza musi zostać wyraźnie oznaczony, a informacje o konsultacjach w tym dniu muszą być dostępne w formie skróconej po najechaniu myszką na ten dzień (tooltip – dymek z informacją).	W
EKP-40	System musi pozwalać na podgląd szczegółów konsultacji, poprzez wejście w dany wpis z poziomu listy lub kalendarza.	W
EKP-41	W ramach dostępu do szczegółów konsultacji, system musi pozwolić na użytkownikom na zapis na wybrane konsultacje.	W
EKP-42	Zapis na dane konsultacje musi nastąpić poprzez wypełnienie formularza.	W
EKP-43	W systemie musi dostępna być wyszukiwarka spraw prowadzonych w e-klinice prawa.	W
EKP-44	Usługa E-klinika prawa musi udostępniać mechanizm wyszukiwarki spraw.	W
EKP-45	Usługa E-klinika prawa musi umożliwiać wyszukiwanie informacji dla zadanej frazy.	W
EKP-46	Usługa E-klinika prawa musi umożliwiać przeszukiwanie zawartość plików udostępnionych w treściach spraw.	W
EKP-47	Usługa E-klinika prawa musi pozwolić na przeszukiwanie dokumentów w formatach doc, docx, pdf, rtf, txt, odt, xls, xlsx, ppt, odp.	W
EKP-48	Wyszukiwanie spraw w usłudze E-klinika prawa musi posiadać opcje zaawansowane pozwalające na przeszukanie bazy danych przynajmniej według poniżysz kryteriów: Rodzaj/kategoria sprawy Osoba konsultująca	W
EKP-49	Konfiguracja wyszukiwarki musi pozwolić na ustawienie minimalnej liczby znaków, dla których system uruchomi proces wyszukiwania.	W
EKP-50	Usługa E-klinika prawa umożliwiać musi mechanizm powalający na tworzenie bazy wiedzy.	W
EKP-51	System musi prezentować wszystkie wpisy bazy wiedzy w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania wpisów.	W
EKP-52	System musi pozwalać na podgląd szczegółów wpisu bazy wiedzy, poprzez wejście w dany wpis z poziomu listy.	W
EKP-53	Pojedynczy wpis dostępny w bazie wiedzy musi zostać opisany przynajmniej przez następujące dane: 1. Tytuł 2. Rodzaj/kategoria 3. Opis 4. Lista załączników dotyczących 5. Status publikacji	W
EKP-54	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii/rodzaju sprawy definiowanych w bazie wiedzy.	W
EKP-55	W ramach bazy danych usługi E-klinika prawa, udostępniane będą treści z obszarów: 1. Orzecznictwa sądowego dotyczącego spraw z zakresu ubezpieczeń społecznych; 2. Pism procesowych w sprawach karnych, cywilnych, rodzinnych, prawa pracy i ubezpieczeń społecznych; 3. Orzecznictwa dotyczącego pozycji prawnej skazanego i instrumentów prawnych służących ochronie jego praw; 4. Orzecznictwa sądowego i administracyjnego dotyczącego pozycji prawnej oraz obowiązków ucznia;	W

2.4.8. E-usługa E-klinika administracji

Usługa skierowana do studentów, mająca na celu wsparcie kształcenia praktycznego. Kontakt z rzeczywistymi przypadkami i możliwość pracy nad nimi daje możliwość wykorzystania nabytej wiedzy teoretycznej w praktyce. E- usługa zapewni stworzenie baz danych, tj. zbiorów orzeczeń sądowych podlegających kategoryzacji i wybranych przez Uczelnie do publikacji i udostepnienia w ramach portalu. Będą to następujące zbiory:

1. Zbiór orzeczeń sądów administracyjnych zgromadzonych według przyjętej systematyki i metody selekcji ukierunkowanych na sprawy z zakresu pomocy społecznej i wyselekcjonowanych pod kątem tych kategorii spraw określanych abstrakcyjnie, które rodzą wątpliwości w procesie stosowania prawa przez organy administracji publicznej,

2. Zbiór tez poglądów literatury, zgromadzonych według przyjętej systematyki i metody selekcji ukierunkowanych na sprawy z zakresu pomocy społecznej i wyselekcjonowanych pod kątem tych kategorii spraw określanych abstrakcyjnie, które rodzą wątpliwości w procesie stosowania prawa przez organy administracji publicznej,

3. Zbiór orzeczeń Trybunału Konstytucyjnego, zgromadzonych według przyjętej systematyki i metody selekcji ukierunkowanych na sprawy z zakresu pomocy społecznej. Stworzenie w/w baz danych i ich udostępnianie środkami elektronicznymi w sposób zapewniających stały dostęp zwiększy dostępność do orzecznictwa, wpłynie na poprawę świadomości i kultury prawnej społeczeństwa, będzie stanowiło realną pomoc dla beneficjentów pomocy społecznej, którzy mają trudności z dostępem do powszechnych baz danych oraz właściwego wyselekcjonowania orzeczeń w konkretnych sprawach administracyjnych z pomocy społecznej. Usługa zapewni również udostępnienie baz danych ośrodkom pomocy społecznej, z którymi współpracuje wnioskodawca.

Ad. 1. Repozytorium zawierające zbiór orzeczeń sądów administracyjnych będzie zbiorem przygotowywanym przez studentów działających w ramach prowadzonej przez Uczelnię Kliniki Administracji. Zbiór ten tworzony będzie w oparciu o założenie wyselekcjonowania z Centralnej Bazy Orzeczeń Sądów Administracyjnych (xxxxxxxxxx.xxx.xxx.xx) rozstrzygnięć sądów zarówno I, jak II instancji orzeczniczej w sprawach z zakresu szeroko rozumianej pomocy społecznej. Będzie zatem zawierał orzecznictwo w sprawach wywołujących wątpliwości w praktyce stosowania prawa, w szczególności w obszarze pomocy społecznej sensu stricte, świadczeń rodzinnych, pomocy osobom uprawnionym do alimentów, wspierania rodziny i systemu pieczy zastępczej. Celem pozyskania danych na temat problemów prawnych rodzących największe wątpliwości w działaniu organów administrujących pomocą społeczną, studenci będą korzystać z pomocy Ośrodków Pomocy Społecznej, z którymi Klinika Administracji Uczelni ma podpisane umowy o współpracy. W ten sposób tworzoną wyselekcjonowaną bazę orzeczeń sądów administracyjnych w wybranych sprawach cechuje duży stopień użyteczności praktycznej. Ujednolicona merytorycznie baza, zawierająca najistotniejsze orzeczenia z określonej dziedziny prawa administracyjnego będzie służyła bez ograniczeń społeczeństwu, w szczególności osobom będącym beneficjentami pomocy społecznej. Udostępnienie bazy za pomocą środków komunikacji elektronicznej zapewni do niej stały dostęp, co niewątpliwie urealnia szanse osób korzystających z pomocy społecznej lub zamierzających z niej korzystać na dostęp do orzecznictwa już wyselekcjonowanego, a zatem celującego w zainteresowania osób korzystających. Ogólnie dostępna Centralna Baza Orzeczeń Sądów Administracyjnych, zawierająca zbiór wszystkich orzeczeń sądów, jakie codziennie zapadają w Wojewódzkich Sądach Administracyjnych oraz w Naczelnym Sądzie Administracyjnym, zmniejsza szanse dla przeciętnego człowieka na znalezienie i właściwe wyselekcjonowanie orzeczeń w konkretnych sprawach administracyjnych z zakresu pomocy społecznej.

Ad. 2. Repozytorium zawierające zbiór tez poglądów literatury, zgromadzone będzie według przyjętej systematyki i metody selekcji ukierunkowanych na sprawy z zakresu pomocy społecznej i wyselekcjonowanych pod kątem tych kategorii spraw określanych abstrakcyjnie, które rodzą wątpliwości w procesie stosowania prawa przez organy administracji publicznej. Repozytorium będzie prowadzone przez studentów działających w ramach Kliniki Administracji WSPiA Rzeszowskiej Szkoły Wyższej . Studenci działający pod kierunkiem naukowym nauczycieli akademickich będą dokonywali stałego przeglądu literatury naukowej w spawach z zakresu pomocy społecznej, próbując w ten sposób wyszukiwać stanowisk na temat wątpliwości prawnych jakie stwarza stosowanie prawa w obszarze pomocy społecznej, w szczególności w obszarze zagadnień kontrowersyjnych, jak również powstających na gruncie nowych regulacji prawnych. Zadaniem studenta będzie właściwe wyselekcjonowanie poglądów literatury oraz sformułowanie tez z odesłaniem do źródła. Stworzenie w/w bazy danych i jej udostępnianie środkami elektronicznymi, będzie stanowić istotne uproszczenie dla przeciętnego człowieka w zakresie dostępu do aktualnych tez z literatury przedmiotu, w warunkach w których dotąd dostęp do poglądów nauki w dziedzinie prawa musiał się wiązać z

koniecznością samodzielnego poszukiwania ich w źródłach bibliograficznych znajdujących się, np. w czytelniach akademickich funkcjonujących przy jednostkach organizacyjnych Uczelni. Upowszechnienie tej wiedzy wpłynie na poprawę świadomości i kultury prawnej społeczeństwa, będzie stanowiło realną pomoc dla beneficjentów pomocy społecznej, którzy mają trudności z prawidłowych zrozumieniem przepisów prawnych w interesujących ich sprawach z zakresu pomocy społecznej, a w konsekwencji niejednokrotnie zrozumieniem celu i skutków prowadzonych postępowań administracyjnych. Usługa zapewni również udostępnienie baz danych ośrodkom pomocy społecznej, z którymi współpracuje wnioskodawca. Bieżący dostęp do poglądów literatury będzie służył podniesieniu poziomu wiedzy pracowników, zwiększy ich kompetencje, przez co usprawni proces decyzyjnego stosowania prawa i wpłynie na jakość orzecznictwa.

Ad. 3. Repozytorium zawierające zbiór orzeczeń Trybunału Konstytucyjnego (TK) będzie prowadzone według przyjętej systematyki i metody selekcji ukierunkowanej na sprawy z zakresu pomocy społecznej.

Baza orzeczeń Trybunału Konstytucyjnego będzie zawierała wyroki Trybunału Konstytucyjnego w sprawach z zakresu szeroko rozumianej pomocy społecznej. Baza będzie prowadzona przez studentów działających w ramach Kliniki Administracji WSPiA Rzeszowskiej Szkoły Wyższej. Ich zadaniem będzie bieżące śledzenie spraw prowadzonych przez Trybunał Konstytucyjny w sprawach z zakresu pomocy społecznej oraz umieszczanie w zbiorze zapadających w tych sprawach orzeczeń. Bieżący monitoring spraw będzie prowadzony w oparciu o informacje na stronach internetowych Trybunału Konstytucyjnego.

Źródłem pozyskania orzeczeń będą dostępne przez Internet Dzienniki Ustaw, w których są publikowane orzeczenia oraz elektronicznym zbiorze orzeczeń - Orzecznictwo Trybunału Konstytucyjnego Zbiór Urzędowy (Bazy Orzeczeń Trybunału Konstytucyjnego - xxx.xxxxxxxx.xxx.xx/xxxxxxxxxx/).

Ujednolicona merytorycznie baza, zawierająca najistotniejsze orzeczenia TK z określonej dziedziny prawa administracyjnego będzie służyła bez ograniczeń społeczeństwu, w szczególności osobom będącym beneficjentami pomocy społecznej. Udostępnienie bazy za pomocą środków komunikacji elektronicznej zapewni do niej stały dostęp, co niewątpliwie urealnia szanse osób korzystających z pomocy społecznej lub zamierzających z niej korzystać na dostęp do orzecznictwa już wyselekcjonowanego. Usługa zapewni również udostępnienie baz danych ośrodkom pomocy społecznej, z którymi współpracuje wnioskodawca. Bieżący dostęp do Orzeczeń TK będzie służył podniesieniu poziomu wiedzy pracowników, zwiększy ich kompetencje, przez co usprawni proces decyzyjnego stosowania prawa i wpłynie na jakość orzecznictwa.

System musi przewidzieć integrację z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych, posiadających profil zaufany w przedmiotowym systemie.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-lista klinika administracji zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKA-1	E-klinika administracji
EKA-2	Usługa E-klinika administracji skierowana do studentów, musi wspierać kształcenie praktyczne. Narzędzie musi wspomagać wykorzystanie nabytej wiedzy teoretycznej w praktyce.	W
EKA-3	System musi udostępniać mechanizmy pozwalające na tworzenie bazy zbiorów orzeczeń sądowych.	W
EKA-4	System musi pozwalać na kategoryzowanie zbiorów orzeczeń sądowych.	W
EKA-5	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii bazy zbiorów.	W
EKA-6	System w ramach e-usługi klinika administracji musi pozwalać na publikację wybranych przez Uczelnie zbiorów orzeczeń sądowych.	W
EKA-7	System w ramach e-usługi klinika administracji musi pozwalać na udostępnienie w ramach portalu wybranych zbiorów orzeczeń sądowych.	W
EKA-8	System musi pozwalać na publikowanie treści dostępnych dla zalogowanych użytkowników oraz treści ogólnodostępnych.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKA-9	System w ramach e-usługi musi udostępniać mechanizmy pozwalające na nadawanie uprawnień studentom do modułu E-klinika administracji.	W
EKA-10	Moduł musi umożliwiać: 1. Rejestrację osób zainteresowanych udzielaniem porad; 2. Rejestrację konta klienta, osoby zainteresowanej otrzymaniem porady prawnej; 3. Zgłoszenie wniosku o udzielenie porady prawnej; 4. Określenie zakresu konsultacji - wybór obszaru ze zdefiniowanej listy; 5. Przegląd zgłoszonych wniosków; 6. Podgląd statusu zgłoszonych wniosków;	W
EKA-11	System musi umożliwiać studentom zgłoszenie chęci współpracy w ramach działalności prowadzonej przez E-klinikę administracji.	W
EKA-12	Zgłoszenia współpracy muszą być realizowane poprzez formularz internetowy.	W
EKA-13	System w ramach swoich funkcjonalności przewidywać musi możliwość integracji z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych.	W
EKA-14	System musi umożliwiać określenie danych informacyjnych charakteryzujących zakres działania E-kliniki administracji w tym: 1. Regulamin 2. Informacje prawne 3. Materiały pomocnicze 4. Załączniki	W
EKA-15	System musi pozwalać na określenie operatorów usługi, poprzez nadanie uprawnień, w tym: 1. Osoby potwierdzające rejestrację terminów spotkań; 2. Opiekuna sekcji; 3. Osoby rozpatrujące sprawy;	W
EKA-16	System musi pozwalać na wprowadzenie danych personalnych klienta w celu przeprowadzenia rejestracji terminu spotkania.	W
EKA-17	System musi pozwalać na przesłanie powiadomienia drogą mailową zawierającego potwierdzenie spotkania.	W
EKA-18	System musi umożliwiać określenie danych informacyjnych charakteryzujących sprawę w tym: 1. Rodzaj sprawy; 2. Załączone dokumenty dotyczące sprawy; 3. Opis oraz opinie sprawy;	W
EKA-19	System musi pozwalać na kategoryzowanie spraw.	W
EKA-20	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii/rodzaju sprawy.	W
EKA-21	System musi pozwalać na definiowanie danych opisowych spraw w celach informacyjnych dla osób zainteresowanych.	W
EKA-22	System musi pozwalać na dodawanie plików i załączników przy definiowaniu spraw.	W
EKA-23	System musi pozwalać na określenie osoby rozpatrującej zgłoszoną sprawę.	W
EKA-24	System musi umożliwiać określenie status sprawy.	W
EKA-25	Pojedyncza sprawa musi zostać opisana przynajmniej przez następujące dane: 1. Tytuł sprawy 2. Data złożenia wniosku sprawy 3. Rodzaj sprawy 4. Opis sprawy 5. Lista załączników dotyczących sprawy 6. Status	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	7. Osoba rozpatrująca
EKA-26	System musi udostępniać mechanizm potwierdzenia lub odrzucenia terminu konsultacji sprawy przez opiekuna sekcji.	W
EKA-27	System musi posiadać mechanizm informujący osobę zapisującą się na spotkanie o odrzuceniu bądź akceptacji terminu konsultacji drogą mailową.	W
EKA-28	System w wysyłanym powiadomieniu droga mailową, z prośba o potwierdzenie bądź odrzucenie terminu konsultacji, musi posiadać możliwość akceptacji terminu z poziomu wiadomości email, bez konieczności logowania się do systemu.	W
EKA-29	System musi posiadać mechanizmy prezentacji wszystkich zdefiniowanych w systemie spraw osobom rozpatrującym.	W
EKA-30	System musi prezentować wszystkie złożone wnioski w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania wpisów.	W
EKA-31	System musi pozwalać na podgląd szczegółów złożonego wniosku, poprzez wejście w dany wniosek z poziomu listy.	W
EKA-32	Funkcjonalność składania wniosku dostępna będzie tylko dla zarejestrowanych w systemie użytkowników.	W
EKA-33	Wszyscy zalogowanie na froncie systemu użytkownicy muszą mieć dostęp do funkcjonalności „Mojego konta”.	W
EKA-34	System w ramach funkcjonalności „Moje konto” musi pozwalać na prezentację złożonych przez użytkownika spraw w postaci stronicowanej listy.	W
EKA-35	System musi pozwalać użytkownikom na podgląd szczegółów sprawy, dołączonych plików oraz statusu.	W
EKA-36	System musi pozwalać na konfiguracje harmonogramu otwarcia kliniki.	W
EKA-37	Harmonogram otwarcia E-kliniki administracji może być konfigurowany tylko przez uprawnionych użytkowników wewnętrznych systemu.	W
EKA-38	System musi pozwalać na zdefiniowanie przedziałów godzin, w których możliwe będą konsultacje z osobami rozpatrującymi.	W
EKA-39	Formularz konfiguracji przedziałów czasowych musi być zawierać przynajmniej dane: 1. Dzień – Data konsultacji; 2. Przedział godzinowy; 3. Miejsce konsultacji;	W
EKA-40	System musi pozwalać na zdefiniowanie konsultacji cyklicznych w wybranych dniach i przedziałach godzinowych.	W
EKA-41	Widok harmonogramu musi pozwalać na wyświetlanie: 1. w formie listy, 2. w formie kalendarza.	W
EKA-42	Widok harmonogramu w formie kalendarza to widok kalendarza miesięcznego z możliwością przeskoczenia do następnych miesięcy lub powrotu do poprzednich.	W
EKA-43	Kalendarz musi prezentować dni tygodnia w postaci kafelków, musi zaznaczać aktualny dzień, musi zawierać opisy dni tygodnia.	W
EKA-44	W przypadku wystąpienia konsultacji w danym dniu, kafelek kalendarza musi zostać wyraźnie oznaczony, a informacje o konsultacjach w tym dniu muszą być dostępne w formie skróconej po najechaniu myszką na ten dzień (tooltip).	W
EKA-45	System musi pozwalać na podgląd szczegółów konsultacji, poprzez wejście w dany wpis z poziomu listy lub kalendarza.	W
EKA-46	W ramach dostępu do szczegółów konsultacji, system musi pozwolić na użytkownikom na zapis na wybrane konsultacje.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKA-47	Zapis na dane konsultacje musi nastąpić poprzez wypełnienie formularza internetowego.	W
EKA-48	Usługa E-klinika administracji musi udostępniać mechanizm wyszukiwarki spraw.	W
EKA-49	Usługa E-klinika administracji musi umożliwiać wyszukiwanie informacji dla zadanej frazy.	W
EKA-50	Usługa E-klinika administracji musi umożliwiać przeszukiwanie zawartość plików udostępnionych w treściach spraw.	W
EKA-51	Usługa E-klinika administracji musi pozwolić na przeszukiwanie dokumentów w formatach doc, docx, pdf, rtf, txt, odt, xls, xlsx, ppt, odp.	W
EKA-52	Wyszukiwanie spraw w usłudze E-klinika administracji musi posiadać opcje zaawansowane pozwalające na przeszukanie bazy danych przynajmniej według poniżysz kryteriów: 1. Rodzaj/kategoria sprawy 2. Osoba konsultująca	W
EKA-53	Konfiguracja wyszukiwarki musi pozwolić na ustawienie minimalnej liczby znaków, dla których system uruchomi proces wyszukiwania.	W
EKA-54	Usługa E-klinika administracji umożliwiać musi mechanizm powalający na tworzenie bazy wiedzy.	W
EKA-55	System musi prezentować wszystkie wpisy bazy wiedzy w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania wpisów.	W
EKA-56	System musi pozwalać na podgląd szczegółów wpisu bazy wiedzy, poprzez wejście w dany wpis z poziomu listy.	W
EKA-57	Pojedynczy wpis dostępny w bazie wiedzy musi zostać opisany przynajmniej przez następujące dane: 1. Tytuł 2. Rodzaj/kategoria 3. Opis 4. Lista załączników dotyczących 5. Status publikacji	W
EKA-58	W ramach bazy danych usługi E-klinika administracji, udostępniane będą treści z obszarów: 1. Orzeczeń sądów administracyjnych sądowego dotyczącego spraw z zakresu pomocy społecznej; 2. Orzeczeń Trybunału Konstytucyjnego dotyczących spraw z zakresu pomocy społecznej; 3. Tez poglądów literatury spraw z zakresu pomocy społecznej;	W

2.4.9. E-usługa E-klinika przedsiębiorczości

Usługa skierowana do studentów mająca na celu wsparcie kształcenia praktycznego. Kontakt z rzeczywistymi przypadkami i możliwość pracy nad nimi daje możliwość wykorzystania nabytej wiedzy teoretycznej w praktyce. Podstawowym celem działania platformy jest optymalizacja procesu obsługi klientów Kliniki. W związku z tym system powinien obejmować następujące moduły:

1. Rejestracja klientów kliniki,

2. Konto klienta kliniki, w ramach którego będzie można zgłosić sprawę i umówić się na spotkanie (klient będzie miał możliwość określenia zakresu konsultacji określając rodzaj działalności gospodarczej i elementy biznesplanu, które chce omówić; formularz będzie umożliwiał dołączanie dokumentów)

3. Panel administracyjny (edycja danych klientów, ewidencja doradców biznesowych, kalendarz dyżurów doradców biznesowych, przydzielanie spraw, kalendarz spraw, ewidencja spraw itp.).

Dodatkowo System będzie obejmował kilka e-usług nawiązujących do zdiagnozowanych (typowych) problemów osób rozpoczynających działalność gospodarzą:

1. Aplikację szkoleniową,

2. Wyszukiwarkę klauzul niedozwolonych związanych z e-biznesem,

3. Wyszukiwarkę ofert wynajmu lokali użytkowych na terenie Rzeszowa,

4. Generator umowy spółki cywilnej,

5. Narzędzia do tworzenia/weryfikacji biznesplanu,

6. Aplikację do ankiet testujących produkty/usługi startupów.

Ad. 1. Aplikacja szkoleniowa

Certyfikowane kursy na tematy prawno-biznesowe dla zarejestrowanych użytkowników obejmujące moduły szkoleniowe oraz egzaminacyjne (testowe) oraz umożliwiające wygenerowanie e-certyfikatu.

Proces odbywa się poprzez:

1. Zarejestrowanie się jako użytkownik (założenie konta),

2. Przejście cyklu e-kursów,

3. Zdanie e-testu/egzaminu,

4. Wygenerowanie e-certyfikatu.

Ad. 2. Wyszukiwarka klauzul niedozwolonych związanych z e-biznesem

Wyszukiwarka stworzona w oparciu o Rejestr Klauzul Niedozwolonych udostępniony na stronie UOKiK – Urząd Ochrony Konkurencji i Konsumetów (xxxxx://xxxxx.xxx.xx/). W ramach tej usługi zostanie stworzona baza klauzul związanych z e-biznesem. Do każdej klauzuli zostaną przypisane odpowiednie słowa kluczowe (o większym stopniu szczegółowości niż w oryginalnym rejestrze).

Ad. 3. Wyszukiwarka ofert wynajmu lokali użytkowych na terenie Rzeszowa

Wyszukiwarka będzie działała w oparciu o tworzoną (bazę ofert nieruchomości, które są rozproszone w różnych serwisach ogłoszeniowych (ogólnopolskich i lokalnych) oraz biur nieruchomości. Będzie uwzględniała narzędzia sprawdzające unikalność i aktualność ofert.

Ad. 4. Generator umów spółki cywilnej

Formularz będzie umożliwiał wpisywanie wybranych danych stron umowy oraz uwzględniał różne propozycje klauzul poszczególnych elementów umowy spółki, co pozwoli dostosować je do indywidualnych wymagań. Umowa będzie mogła być wygenerowana w języku angielskim.

Ad. 5. Narzędzia do tworzenia/weryfikacji biznesplanu

Aplikacje ułatwiające przedstawienie (on-line) założeń biznesowych projektów tj. business model canvas (szablon modelu biznesowego), analiza SWOT (popularna heurystyczna technika służąca do porządkowania i analizy informacji. Nazwa jest akronimem od angielskich słów określających cztery elementy składowe analizy (Strengths – mocne strony, Weaknesses – słabe strony, Opportunities - szanse i Threats - zagrożenia)).

Ad. 6. Aplikacja do ankiet testujących produkty/usługi startupów

Aplikacja będzie obejmowała narzędzia do tworzenia ankiety (opis usługi/projektu, tworzenie pytań otwartych i zamkniętych), publikacji, wypełniania oraz sprawdzania jej wyników.

System przewiduje integrację z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych, posiadających profil zaufany w przedmiotowym systemie.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-lista klinika przedsiębiorczości zawiera poniższa tabela.

Nr wymagania

Opis wymagania

Funkcjonalność W/O

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-1	E-klinika przedsiębiorczości
EKP-2	Usługa E-klinika przedsiębiorczości skierowana do studentów, musi wspierać kształcenie praktyczne. Narzędzie musi wspomagać wykorzystanie nabytej wiedzy teoretycznej w praktyce.	W
EKP-3	System musi udostępniać mechanizmy pozwalające na prowadzenie działalności informacyjnej w obszarze tematyki szeroko rozumianego bezpieczeństwa.	W
EKP-4	System musi posiadać funkcjonalność pozwalającą na prezentację treści opisowych.	W
EKP-5	System w ramach e-usługi klinika bezpieczeństwa musi pozwalać na publikację wybranych przez Uczelnie treści statycznych.	W
EKP-6	System musi pozwalać na kategoryzowanie treści statycznych.	W
EKP-7	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii treści statycznych.	W
EKP-8	System musi pozwalać na publikowanie treści dostępnych dla zalogowanych użytkowników oraz treści ogólnodostępnych.	W
EKP-9	System musi prezentować wszystkie treści statyczne w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania wpisów.	W
EKP-10	System musi pozwalać na podgląd szczegółów treści statycznych, poprzez wejście w dany wpis z poziomu listy.	W
EKP-11	System w ramach e-usługi musi udostępniać mechanizmy pozwalające na nadawanie uprawnień studentom do modułu E-klinika przedsiębiorczości.	W
EKP-12	Moduł musi umożliwiać: 1. Rejestrację osób zainteresowanych udzielaniem porad; 2. Rejestrację konta klienta, osoby zainteresowanej otrzymaniem porady prawnej; 3. Zgłoszenie wniosku o udzielenie porady prawnej; 4. Określenie zakresu konsultacji - wybór obszaru ze zdefiniowanej listy; 5. Przegląd zgłoszonych wniosków; 6. Podgląd statusu zgłoszonych wniosków;	W
EKP-13	System musi umożliwiać studentom zgłoszenie chęci współpracy w ramach działalności prowadzonej przez E-klinikę przedsiębiorczości.	W
EKP-14	Zgłoszenia współpracy muszą być realizowane poprzez formularz internetowy.	W
EKP-15	System w ramach swoich funkcjonalności przewidywać musi możliwość integracji z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych.	W
EKP-16	System musi umożliwiać określenie danych informacyjnych charakteryzujących zakres działania E-kliniki przedsiębiorczości w tym: 1. Regulamin 2. Informacje prawne 3. Materiały pomocnicze 4. Załączniki	W
EKP-17	System musi pozwalać na określenie operatorów usługi, poprzez nadanie uprawnień, w tym: 1. Osoby potwierdzające rejestrację terminów spotkań; 2. Opiekuna sekcji; 3. Osoby rozpatrujące sprawy;	W
EKP-18	System musi pozwalać na wprowadzenie danych personalnych klienta w celu przeprowadzenia rejestracji terminu spotkania.	W
EKP-19	System musi pozwalać na przesłanie powiadomienia drogą mailową zawierającego potwierdzenie spotkania.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-20	System musi umożliwiać określenie danych informacyjnych charakteryzujących sprawę w tym: 1. Rodzaj sprawy; 2. Załączone dokumenty dotyczące sprawy; 3. Opis oraz opinie sprawy;	W
EKP-21	System musi pozwalać na kategoryzowanie spraw.	W
EKP-22	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii/rodzaju sprawy.	W
EKP-23	System musi pozwalać na definiowanie danych opisowych spraw w celach informacyjnych dla osób zainteresowanych.	W
EKP-24	System musi pozwalać na dodawanie plików i załączników przy definiowaniu spraw.	W
EKP-25	System musi pozwalać na określenie osoby rozpatrującej zgłoszoną sprawę.	W
EKP-26	System musi umożliwiać określenie status sprawy.	W
EKP-27	Pojedyncza sprawa musi zostać opisana przynajmniej przez następujące dane: 1. Tytuł sprawy 2. Data złożenia wniosku sprawy 3. Rodzaj sprawy 4. Opis sprawy 5. Lista załączników dotyczących sprawy 6. Status 7. Osoba rozpatrująca	W
EKP-28	System musi udostępniać mechanizm potwierdzenia lub odrzucenia terminu konsultacji sprawy przez opiekuna sekcji.	W
EKP-29	System musi posiadać mechanizm informujący osobę zapisującą się na spotkanie o odrzuceniu bądź akceptacji terminu konsultacji drogą mailową.	W
EKP-30	System w wysyłanym powiadomieniu droga mailową, z prośba o potwierdzenie bądź odrzucenie terminu konsultacji, musi posiadać możliwość akceptacji terminu z poziomu wiadomości email, bez konieczności logowania się do systemu.	W
EKP-31	System musi posiadać mechanizmy prezentacji wszystkich zdefiniowanych w systemie spraw osobom rozpatrującym.	W
EKP-32	System musi prezentować wszystkie złożone wnioski w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania wpisów.	W
EKP-33	System musi pozwalać na podgląd szczegółów złożonego wniosku, poprzez wejście w dany wniosek z poziomu listy.	W
EKP-34	Funkcjonalność składania wniosku dostępna będzie tylko dla zarejestrowanych w systemie użytkowników.	W
EKP-35	Wszyscy zalogowanie na froncie systemu użytkownicy muszą mieć dostęp do funkcjonalności „Mojego konta”.	W
EKP-36	System w ramach funkcjonalności „Moje konto” musi pozwalać na prezentację złożonych przez użytkownika spraw w postaci stronicowanej listy.	W
EKP-37	System musi pozwalać użytkownikom na podgląd szczegółów sprawy, dołączonych plików oraz statusu.	W
EKP-38	System musi pozwalać na konfiguracje harmonogramu otwarcia kliniki.	W
EKP-39	Harmonogram otwarcia E-kliniki przedsiębiorczości może być konfigurowany tylko przez uprawnionych użytkowników wewnętrznych systemu.	W
EKP-40	System musi pozwalać na zdefiniowanie przedziałów godzin w których możliwe będą konsultacje z osobami rozpatrującymi.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-41	Formularz konfiguracji przedziałów czasowych musi być zawierać przynajmniej dane: 1. Dzień – Data konsultacji; 2. Przedział godzinowy; 3. Miejsce konsultacji;	W
EKP-42	System musi pozwalać na zdefiniowanie konsultacji cyklicznych w wybranych dniach i przedziałach godzinowych.	W
EKP-43	Widok harmonogramu musi pozwalać na wyświetlanie: 1. w formie listy, 2. w formie kalendarza.	W
EKP-44	Widok harmonogramu w formie kalendarza to widok kalendarza miesięcznego z możliwością przeskoczenia do następnych miesięcy lub powrotu do poprzednich.	W
EKP-45	Kalendarz musi prezentować dni tygodnia w postaci kafelków, musi zaznaczać aktualny dzień, musi zawierać opisy dni tygodnia.	W
EKP-46	W przypadku wystąpienia konsultacji w danym dniu, kafelek kalendarza musi zostać wyraźnie oznaczony, a informacje o konsultacjach w tym dniu muszą być dostępne w formie skróconej po najechaniu myszką na ten dzień (tooltip).	W
EKP-47	System musi pozwalać na podgląd szczegółów konsultacji, poprzez wejście w dany wpis z poziomu listy lub kalendarza.	W
EKP-48	W ramach dostępu do szczegółów konsultacji, system musi pozwolić na użytkownikom na zapis na wybrane konsultacje.	W
EKP-49	Zapis na dane konsultacje musi nastąpić poprzez wypełnienie formularza internetowego.	W
EKP-50	Aplikacja szkoleniowa
EKP-51	Aplikacja musi posiadać mechanizmy do tworzenia testów, publikacji, wypełniania oraz sprawdzania wyników.	W
EKP-52	System musi pozwalać na konfigurację tworzonych testów.	W
EKP-53	System musi pozwalać na tworzenie różnych typów pytań, w szczególności pytań otwartych i zamkniętych.	W
EKP-54	Moduł szkoleniowy musi składać się z definicji testu oraz definicji pytań dostępnych w konkretnym teście.	W
EKP-55	Prezentacja testów musi polegać na wyświetleniu jej danych opisowych – nazwa, pole wstęp. Wyświetlenie samych pytań musi nastąpić po aktywacji testu przez samego użytkownika przyciskiem rozpocznij test.	W
EKP-56	Na pojedynczą ankietę muszą składać się przynajmniej pola: 1. nazwa, 2. tytuł, 3. data publikacji od, data publikacji do, 4. opis, 5. wstęp (edytor WYSIWYG), 6. publikacja wyników, 7. liczba wypełnień 8. status publikacji.	W
EKP-57	Moduł musi pozwalać na określenie ilości wypełnionych testów. Po osiągnięciu tej ilości, test jest niedostępny.	W
EKP-58	Moduł musi pozwalać na publikacje wyników. W przypadku pytań zamkniętych system musi generować graficzne statystyki.	W
EKP-59	Moduł musi posiadać funkcjonalność tworzenia nowych rekordów na podstawie rekordów już istniejących.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-60	W przypadku testów wypełnionych przynajmniej raz nie mogą być zmieniane pytania tego rekordu.	W
EKP-61	System musi pozwolić na podgląd wypełnień danego testu z poziomu panelu administracyjnego.	W
EKP-62	System musi pozwolić na eksport wypełnień danego testu do pliku.	W
EKP-63	System musi pozwalać na sortowanie pytań w obrębie konkretnego testu.	W
EKP-64	System musi pozwolić na dodawanie przynajmniej poniższych typów pytań do testów: 1. pytanie jednokrotnego wyboru, 2. pytanie wielokrotnego wyboru, 3. pytanie typu select (wybór z listy rozwijalnej), 4. opis, 5. podział strony, 6. załącznik.	W
EKP-65	System musi pozwalać na definiowanie dodatkowych parametrów dla powyższych pól, takich jak: 1. nazwa pola, 2. długość pola – dla pól tekstowych, 3. dodatkowy opis nad i pod polem, 4. wymagalność pola na formularzu, 5. widoczność pola na formularzu na froncie.	W
EKP-66	Moduł musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy formularzy testów, 2. dodawanie formularzy testów, 3. edycja formularzy testów, 4. usuwanie formularzy testów, 5. publikacja, zatwierdzanie formularzy testów, 6. wersjonowanie formularzy testów, 7. dostęp do pytań, 8. dodawanie pytań, 9. edycja pytań, 10. usuwanie pytań.	W
EKP-67	System musi pozwalać na określenie dostępności testów dla użytkowników.	W
EKP-68	System musi pozwalać na dodanie testu dla użytkowników zalogowanych oraz dla użytkowników niezalogowanych.	W
EKP-69	System musi pozwalać na określenie, które odpowiedzi w konkretnym pytaniu są poprawne.	W
EKP-70	System musi pozwalać na określenie ilości punktów otrzymywanych za poprawną odpowiedź.	W
EKP-71	System musi pozwalać na określenie ilości punktów potrzebnych do pozytywnego zakończenia testu.	W
EKP-72	System musi pozwalać wygenerować e-certyfikat po pozytywnym zakończeniu testu.	W
EKP-73	System musi pozwalać na konfigurację e-certyfikatu.	W
EKP-74	System musi pozwalać na skonfigurowanie e-certyfikatu przynajmniej w zakresie: 1. nagłówek, 2. możliwość dodanie logo, 3. możliwość dodanie tekstu;	W
EKP-75	System w ramach funkcjonalności „Moje konto” musi pozwalać na prezentację	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	wypełnionych przez użytkownika testów w postaci stronicowanej listy.
EKP-76	System musi pozwalać użytkownikom na podgląd szczegółów wypełnionych testów, dołączonych plików oraz statusu.	W
EKP-77	System musi pozwalać użytkownikom na podgląd wyników testów.	W
EKP-78	System musi pozwalać na wygenerowanie e-certyfikatu po pozytywnie zakończonym teście.	W
EKP-79	System musi pozwalać na pobranie e-certyfikatu po kliknięciu w odpowiedni link.	W
EKP-80	System musi pozwalać na tworzenie jednostek lekcyjnych i wypełnianie ich za pomocą materiałów edukacyjnych (dokumenty, filmy, dźwięki, itp.)	W
EKP-81	System musi pozwalać na określenie dostępności materiałów szkoleniowych użytkownikom.	W
EKP-82	Moduł musi pozwalać na przeglądanie zdefiniowanych rekordów w postaci listy wpisów, wyszukiwanie, filtrowanie, podgląd szczegółów wpisu.	W
EKP-83	System musi pozwalać na podgląd szczegółów rekordu, poprzez wejście w dany rekord z poziomu listy.	W
EKP-84	Pojedynczy wpis szkoleniowy musi zostać opisany przynajmniej przez następujące dane: 1. Tytuł 2. Data publikacji 3. opis (WYSIWYG), 4. data publikacji, 5. status publikacji, 6. zdjęcia, 7. pliki do pobrania.	W
EKP-85	Wyszukiwarka klauzul niedozwolonych związanych z e-biznesem
EKP-86	System musi posiadać moduł – Wyszukiwarka klauzul niedozwolonych związanych e- biznesem.	W
EKP-87	Moduł musi pozwalać na tworzenie baz informacji.	W
EKP-88	Moduł umożliwi użytkownikom e-kliniki na przeglądnie zgromadzonych informacji.	W
EKP-89	System musi pozwalać na konfiguracje modułu oraz na definiowanie pól wchodzących w skład pojedynczego wpisu.	W
EKP-90	Moduł musi pozwalać na przeglądanie zdefiniowanych rekordów w postaci listy wpisów, wyszukiwanie, filtrowanie, podgląd szczegółów wpisu.	W
EKP-91	System musi pozwalać na podgląd szczegółów rekordu, poprzez wejście w dany rekord z poziomu listy.	W
EKP-92	Moduł musi pozwalać administratorowi na wskazanie poszczególnych pól, które będą stanowić podstawę dla działania mechanizmów przeszukiwania bazy rekordów przez pozostałych użytkowników.	W
EKP-93	Na definicję pojedynczego słownika muszą składać się przynajmniej pola: nazwa, status publikacji.	W
EKP-94	W ramach zdefiniowanego słownika system musi pozwalać administratorowi na definicję jego elementów.	W
EKP-95	W ramach zdefiniowanego słownika system musi pozwalać na dodanie elementów takich jak: 1. pole jednokrotnego wyboru, 2. pole wielokrotnego wyboru, 3. pole typu select (wybór z listy rozwijalnej), 4. pole z otwartą odpowiedzią w polu typu input,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	5. pole z otwartą odpowiedzią w polu typu textarea, 6. załącznik, 7. pole data, 8. pole czas, 9. pole data i czas, 10. pole e-mail, 11. pole pesel, 12. pole select – wielopoziomowe,
EKP-96	System musi pozwalać na definiowanie dodatkowych parametrów dla powyższych pól, takich jak: 1. nazwa pola, 2. długość pola – dla pól tekstowych, 3. dodatkowy opis nad i pod polem, 4. wymagalność pola na formularzu, 5. widoczność pola na formularzu na froncie, 6. widoczność pola w wyszukiwarce, 7. możliwość sortowania po polu w widoku listy na froncie.	W
EKP-97	Struktura słownika nie może być edytowana / zmieniana jeżeli został on wypełniony przynajmniej jednym wpisem.	W
EKP-98	Konfiguracja wyszukiwarki dla danego słownika musi pozwalać na włączenie / wyłączenie możliwości wyszukiwania na froncie.	W
EKP-99	System musi pozwalać na konfiguracje pól dostępnych w wyszukiwarce za pomocą mechanizmów drag & drop, ustalania ich kolejności. Formularz może ale nie musi wykorzystywać wszystkich pól.	W
EKP-100	Wyszukiwarka ofert wynajmu lokali użytkowych na terenie Rzeszowa
EKP-101	System musi pozwalać na tworzenie bazy ofert nieruchomości.	W
EKP-102	System musi posiadać moduł umożliwiający wyszukiwanie ofert wynajmu lokali użytkowych na terenie Rzeszowa.	W
EKP-103	System musi pozwalać na zarządzanie rekordami zdefiniowanymi w bazie ofert nieruchomości.	W
EKP-104	System musi prezentować wszystkie oferty z bazy nieruchomości w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania rekordów.	W
EKP-105	System musi pozwalać przynajmniej na następujące akcje: 1. dodanie nowej oferty, 2. edycja istniejącej oferty, 3. podgląd istniejących ofert, 4. usunięcie oferty;	W
EKP-106	System musi pozwalać na eksport ofert z bazy nieruchomości do pliku.	W
EKP-107	System musi pozwalać na podgląd szczegółów oferty, poprzez wejście w dany rekord z poziomu listy.	W
EKP-108	Na definicję pojedynczej oferty muszą składać się przynajmniej następujące pola: 1. nazwa, 2. opis (WYSIWYG), 3. cechy charakteryzujące ofertę, 4. osoba kontaktowa, 5. kategoria/rodzaj oferty, 6. data publikacji,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	7. status publikacji, 8. zdjęcia, 9. pliki do pobrania.
EKP-109	System musi pozwalać na kategoryzowanie ofert nieruchomości.	W
EKP-110	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii/rodzaju ofert nieruchomości.	W
EKP-111	System musi posiadać mechanizm pozwalający na zarządzanie cechami wyróżniającymi oferty.	W
EKP-112	System musi umożliwiać definiowanie cech, a następnie przypisanie ich do ofert.	W
EKP-113	System musi zapobiegać powtarzaniu wartości cech wspólnych dla kilku ofert.	W
EKP-114	System musi pozwalać na zdefiniowanie listy wartości dla pojedynczej cechy.	W
EKP-115	System musi prezentować wszystkie zdefiniowane cechy w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania rekordów.	W
EKP-116	System musi pozwalać na podgląd szczegółów cech, poprzez wejście w dany rekord z poziomu listy.	W
EKP-117	System musi pozwalać przynajmniej na następujące akcje: 1. dodanie nowej cechy, 2. edycja istniejącej cechy, 3. usunięcie cechy;	W
EKP-118	Na definicję pojedynczej cechy muszą składać się przynajmniej następujące pola: 1. nazwa, 2. symbol 3. opis, 4. typ cechy;	W
EKP-119	W ramach zdefiniowanej cechy system musi pozwalać na wybranie przynajmniej następującego typu cechy: 1. pole jednokrotnego wyboru, 2. pole wielokrotnego wyboru, 3. pole typu select, 4. pole typu input, 5. pole typu textarea;	W
EKP-120	System musi udostępniać mechanizm wyszukiwarki ofert nieruchomości.	W
EKP-121	Wyszukiwanie ofert w usłudze E-klinika przedsiębiorczości musi posiadać opcje zaawansowane pozwalające na przeszukanie bazy danych przynajmniej według poniżysz kryteriów: 1. Rodzaj/kategoria oferty, 2. Nazwa, 3. Opis, 4. Cechy ofert zdefiniowane w systemie;	W
EKP-122	System musi pozwalać na oznaczenie cech, które dostępne będą w wyszukiwarce.	W
EKP-123	System musi prezentować wyniki wyszukiwania w postaci stronicowanej listy, z możliwością filtrowania rekordów.	W
EKP-124	System musi pozwalać na podgląd szczegółów ofert, poprzez wejście w dany rekord z poziomu listy wyszukiwania.	W
EKP-125	System musi pozwalać na złożenie zapytania dotyczącego wybranej oferty.	W
EKP-126	Zapytania o oferty muszą być realizowane poprzez formularz internetowy.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-127	System musi pozwalać na przesłanie zapytania drogą mailową do osoby zarządzającej modułem ofert nieruchomości.	W
EKP-128	System musi pozwalać na przesłanie zapytania drogą mailową do osoby kontaktowej wskazanej w ofercie nieruchomości.	W
EKP-129	System musi prezentować zapytania o oferty w postaci stronicowanej listy z możliwością filtrowania rekordów.	W
EKP-130	System musi pozwalać na podgląd szczegółów zapytań o oferty, poprzez wejście w dany rekord z poziomu listy.	W
EKP-131	System musi pozwalać na dodanie oferty nieruchomości z frontu serwisu.	W
EKP-132	Dodawanie ofert z frontu systemu powinno być realizowane poprzez formularz internetowy lub system musi udostępnić odpowiednie mechanizmy pozwalające na dodanie oferty do bazy nieruchomości.	W
EKP-133	System musi pozwalać na weryfikacje ofert dodanych z poziomu frontu serwisu.	W
EKP-134	System musi pozwalać na zmianę statusu ofert nieruchomości.	W
EKP-135	Generator umów spółki cywilnej
EKP-136	System musi posiadać możliwość definiowania szablonów dokumentów (wzorców) w postaci plików w formacie DOCX. Definiowanie szablonów może być oparte o pakiet MS OFFICE używany przez Zamawiającego.	W
EKP-137	System musi umożliwić generowanie dokumentu w formacie .DOCX na podstawie danych zawartych w elektronicznym formularzu w oparciu o dynamiczne szablony (wzorce)	W
EKP-138	Szablon dokumentu powinien być standardowym plikiem .DOCX, w którym będzie można definiować stały tekst, wstawiać obrazy oraz pobierane z systemu zmienne (typu pola tekstowe, liczbowe, listy oraz zmienne kontekstowe np. aktualnie zalogowany użytkownik czy bieżąca data), które podczas generowania dokumentu zostaną zastąpione wartościami pobranymi z elektronicznego formularza.	W
EKP-139	Powinna być zachowana możliwość formatować szablonu (wzorca) m. in. poprzez wybór rodzaju czcionki, wielkości czcionki, koloru czcionki, wskazanie tekstu pogrubianego, tekstu pochyłego, edycje tabulacji, edycje wcięć.	W
EKP-140	W szablonie powinna być możliwość wstawienia kodu kreskowego lub kodu 2D, który pozwoli na automatyczną identyfikację wypełnionego formularza, na podstawie którego wygenerowano dokument DOCX.	W
EKP-141	Wygenerowany, na podstawie szablonu, dokument .DOCX powinien być automatycznie zapisany jako załącznik do wypełnionego formularza, w którym go wygenerowano.	W
EKP-142	Użytkownik powinien mieć możliwość edycji i zapisu zmiany w wygenerowanym dokumencie bez pobierania pliku na lokalny komputer. Do tego celu może zostać użyty pakiet MS OFFICE	W
EKP-143	System powinien umożliwić aktualizację zdefiniowanych w/w zmiennych dla wygenerowanego już dokumentu .DOCX	W
EKP-144	System powinien umożliwić konwersję wygenerowanego pliku z formatu .DOCX na plik formatu PDF wraz ze stworzeniem warstwy tekstowej	W
EKP-145	W systemie muszą być udostępnione przynajmniej dwa domyślne szablony umów. Pozostałe szablony umów cywilnych zostaną wprowadzone przez przeszkolonego użytkownika o odpowiednich uprawnieniach.	W
EKP-146	System musi umożliwić wyświetlenie listy, przygotowanych wcześniej szablonów dokumentów (wzorców), dostępnej dla zalogowanych użytkowników	W
EKP-147	System musi umożliwiać zalogowanym studentom generowanie dokumentów w formacie .DOCX na podstawie przygotowanych wcześniej szablonów dokumentów (wzorców)	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKP-148	Zalogowany student powinien mieć dostęp do listy wszystkich, wygenerowanych przez siebie, dokumentów DOCX.	W
EKP-149	Narzędzia do tworzenia/weryfikacji biznesplanu
EKP-150	Aplikacja musi posiadać mechanizmy do tworzenia kliku typów formularzy.	W
EKP-151	System musi prezentować wszystkie zdefiniowane formularze w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania rekordów.	W
EKP-152	System musi pozwalać na podgląd szczegółów formularzy, poprzez wejście w dany rekord z poziomu listy.	W
EKP-153	System musi pozwalać przynajmniej na następujące akcje: 1. dodanie nowego formularza, 2. edycja istniejącego formularza (tylko w przypadku jeśli nie istnieją wypełnienia danego formularza), 3. usunięcie formularza (tylko w przypadku jeśli nie istnieją wypełnienia danego formularza),;	W
EKP-154	Na definicję pojedynczego formularza muszą składać się przynajmniej następujące pola: 1. nazwa, 2. symbol, 3. status, 4. opis, 5. pola formularza;	W
EKP-155	System musi pozwolić na włączenie pól formularza z listy dostępnych: 1. pola tekstowe, 2. pola wielokrotnego wyboru checkbox, 3. pola jednokrotnego wyboru select, 4. pola typu załącznik, 5. Pole nagłówek.	W
EKP-156	Moduł formularza musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy wpisów, 2. podgląd szczegółów wpisów, 3. eksport wpisów do pliku, 4. konfiguracja modułu.	W
EKP-157	System musi pozwolić na export wpisów w bazie danych do pliku.	W
EKP-158	System musi generować powiadomienie drogą mailową do administratora systemu o wypełnieniu formularza.	W
EKP-159	System musi pozwalać na komentowanie wypełnień formularza.	W
EKP-160	System musi generować powiadomienia drogą mailową o dodaniu nowego komentarza.	W
EKP-161	System musi wysyłać powiadomienia do osoby wypełniającej formularz oraz do administratora modułu.	W
EKP-162	System w ramach funkcjonalności „Moje konto” musi pozwalać na prezentację złożonych przez użytkownika formularzy w postaci stronicowanej listy.	W
EKP-163	System musi pozwalać użytkownikom na podgląd szczegółów formularza, dołączonych plików oraz statusu.	W
EKP-164	System musi pozwalać użytkownikom na podgląd komentarzy do formularza.	W
EKP-165	System musi pozwalać użytkownikom na dodawanie komentarzy do formularza.	W
EKP-166	System musi pozwalać na tworzenie nowej wersji wypełnienia formularza na podstawie już	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	istniejącego wpisu.
EKP-167	Aplikacja do ankiet testujących produkty/usługi sartupów
EKP-168	Aplikacja musi posiadać mechanizmy do tworzenia ankiet, publikacji, wypełniania oraz sprawdzania wyników.	W
EKP-169	System musi pozwalać na konfigurację tworzonych ankiet.	W
EKP-170	System musi pozwalać na tworzenie różnych typów pytań, w szczególności pytań otwartych i zamkniętych.	W
EKP-171	Moduł ankiet musi składać się z definicji ankiet oraz definicji pytań dostępnych w konkretnej ankiecie.	W
EKP-172	Prezentacja ankiety musi polegać na wyświetleniu jej danych opisowych – nazwa, pole wstęp. Wyświetlenie samych pytań musi nastąpić po aktywacji ankiety przez samego użytkownika przyciskiem rozpocznij ankietę.	W
EKP-173	Na pojedynczą ankietę muszą składać się przynajmniej pola: 1. nazwa ankiety, 2. tytuł ankiety, 3. data publikacji od, data publikacji do, 4. opis, 5. wstęp (edytor WYSIWYG), 6. ankieta anonimowa, 7. publikacja wyników ankiety, 8. liczba wypełnień ankiety 9. status publikacji.	W
EKP-174	Ankiety musza pozwalać na wypełnienie ankiet jako anonimowych, wówczas nawet przy zalogowanym użytkowniku system nie pobiera o nim informacji.	W
EKP-175	Ankiety muszą pozwalać na określenie ilość jej wypełnień. Po osiągnięciu tej ilości, ankieta jest niedostępna.	W
EKP-176	Ankiety musza pozwalać na publikacje jej wyników. W przypadku pytań zamkniętych system musi generować graficzne statystyki.	W
EKP-177	Ankiety muszą posiadać funkcjonalność tworzenia ankiety na podstawie ankiety już istniejącej.	W
EKP-178	W przypadku ankiety wypełnionej przynajmniej raz nie mogą być zmieniane pytania tej ankiety.	W
EKP-179	System musi pozwolić na podgląd wypełnień danej ankiety z poziomu panelu administracyjnego.	W
EKP-180	System musi pozwolić na eksport wypełnień danej ankiety do pliku.	W
EKP-181	System musi pozwalać na sortowanie pytań w obrębie konkretnej ankiety.	W
EKP-182	System musi pozwolić na dodawanie przynajmniej poniższych typów pytań do ankiety: 1. pytanie jednokrotnego wyboru, 2. pytanie wielokrotnego wyboru, 3. pytanie typu select, 4. pytanie z otwartą odpowiedzią w polu typu input, 5. pytanie z otwartą odpowiedzią w polu typu textarea, 6. pytanie matrycowe, 7. opis, 8. podział strony, 9. załącznik.	W
EKP-183	System musi pozwalać na definiowanie dodatkowych parametrów dla powyższych pól,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	takich jak: 1. nazwa pola, 2. długość pola – dla pól tekstowych, 3. dodatkowy opis nad i pod polem, 4. wymagalność pola na formularzu, 5. widoczność pola na formularzu na froncie.
EKP-184	Moduł ankiet musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy ankiet, 2. dodawanie ankiety, 3. edycja ankiety, 4. usuwanie ankiety, 5. publikacja, zatwierdzanie ankiety, 6. wersjonowanie ankiety, 7. dostęp do pytań, 8. dodawanie pytań, 9. edycja pytań, 10. usuwanie pytań.	W
EKP-185	System musi pozwalać na osadzanie ankiety za pomocą [shortcodes – identyfikator obiektu] w edytorze WYSIWYG.	W
EKP-186	Ankiety osadzanie za pomocą [shortcodes] w edytorze WYSIWYG muszą pokazać się od razu, bez konieczności kliknięcia w przycisk start ankiety.	W
EKP-187	Moduł ankiet musi posiadać blok prezentujący ankietę, który może być użyty w układzie strony.	W

2.4.10. E-usługa E-klinika bezpieczeństwa

Usługa skierowana do studentów mająca na celu wsparcie kształcenia praktycznego. Kontakt z rzeczywistymi przypadkami i możliwość pracy nad nimi da możliwość wykorzystania nabytej wiedzy teoretycznej w praktyce. Do udzielania porad w ramach e-usługi uprawnieni będą studenci II i III roku studiów pierwszego stopnia oraz I i II roku studiów drugiego stopnia, studiujący na kierunku „bezpieczeństwo wewnętrzne” w WSPiA Rzeszowskiej Szkole Wyższej z bardzo dobrymi wynikami w nauce oraz wykazujący się aktywnością w działalności naukowej w obszarze badań nad bezpieczeństwem.

Cel: E-klinika bezpieczeństwa Wewnętrznego prowadzić będzie działalność informacyjną w obszarze tematyki szeroko rozumianego bezpieczeństwa, skierowaną zarówno do przedstawicieli instytucji administracji publicznej (urzędów i służb właściwych w obszarze zadań bezpieczeństwa i porządku publicznego oraz placówek oświatowych), sektora prywatnego, organizacji społecznych, jak i bezpośrednio do obywateli. Konsultacje będą prowadzone w ramach platformy, która będzie obejmowała następujące moduły:

1. rejestracja klientów kliniki,

2. konto klienta kliniki, w ramach którego będzie można zgłosić sprawę i umówić się na konsultację,

3. panel administracyjny (edycja danych klientów, ewidencja doradców biznesowych, kalendarz dyżurów doradców biznesowych, przydzielanie spraw, kalendarz spraw, ewidencja spraw itp.)

Działalność informacyjna prowadzona będzie dla:

1. instytucji publicznych właściwych w obszarze zadań bezpieczeństwa i porządku publicznego oraz do prywatnych podmiotów gospodarczych realizujących zadania wymagające dodatkowych procedur związanych z ochroną bezpieczeństwa, dotyczy w szczególności x.xx.:

• zasad organizacji i zabezpieczania imprez masowych,

• zasad organizacji zgromadzeń i zbiórek publicznych,

• zasad uzyskiwania zezwoleń i koncesji na określoną działalność gospodarczą,

• ochrony informacji niejawnych (w tym zasad uzyskiwania świadectwa bezpieczeństwa przemysłowego przez przedsiębiorców),

• zasad opracowywania planów ochrony obiektów,

• zasad opracowywania planów ochrony przeciwpożarowej,

• zasad przygotowywania dokumentacji dotyczącej realizacji zadań zarządzania kryzysowego dla administracji publicznej szczebla lokalnego na wypadek zagrożeń o charakterze niemilitarnym,

• zasad ochrony infrastruktury krytycznej,

• zasad bezpieczeństwa przewozu towarów niebezpiecznych oraz zasad organizacji bezpieczeństwa transportu drogowego,

• analiz zagrożeń przestępczością gospodarczą w określonych sektorach gospodarki, w tym analiz metod popełniania tych przestępstw w celu zwiększenia świadomości przedsiębiorców,

• zasad ochrony obiektów i obszarów.

2. Dla instytucji publicznych (placówek oświatowych) oraz organizacji pozarządowych właściwych w obszarze edukacji i kształcenia postaw pro obywatelskich, polegałaby x.xx. na:

• informacji w zakresie tworzenia programów profilaktycznych dla dzieci i młodzieży oraz konsultowaniu treści programów,

• informacji w tematyce programów i scenariuszy lekcji w ramach przedmiotu Edukacja dla Bezpieczeństwa realizowanego na podstawowym i ponadpodstawowym poziomie nauczania, Bezpieczeństwa realizowanego na podstawowym i ponadpodstawowym poziomie nauczania,

• informacji na temat opracowywania innowacyjnych scenariuszy lekcji, w tym zajęć warsztatowych o charakterze praktycznym, dotyczących tematyki bezpieczeństwa wewnętrznego i zagrożeń przestępczością.

3. Na rzecz obywateli i polegałaby x.xx. na:

• informacji w zakresie specyfiki naboru do służb i instytucji ochrony bezpieczeństwa i porządku publicznego,

• informacji w obszarze warunków dokonywania wpisu na listę detektywów,

• informacji w zakresie warunków uzyskiwania licencji pracowników ochrony osób i mienia,

• informacji na temat warunków uzyskiwania uprawnień do powoływania służby informacyjnej i porządkowej na imprezach masowych,

• działalności informacyjnej nt. uprawnień i obowiązków funkcjonariuszy służb ochrony bezpieczeństwa i porządku publicznego.

W ramach usługi E-klinika bezpieczeństwa powstanie Podkarpacka Mapa Zagrożeń Kryminalnych.

Realizacja tej innowacyjnej e-usługi będzie polegała na zapewnieniu interaktywnego, aktualizowanego w trybie półrocznym, portalu internetowego, umożliwiającego monitorowanie zagrożeń bezpieczeństwa wewnętrznego na terenie wszystkich 25 powiatów i 160 gmin województwa podkarpackiego (mapy zagrożeń).

Zebrane w taki sposób informacje zarówno na temat obiektywnych danych statystycznych (np. liczba kradzieży, rozbojów, włamań itd.), jak i subiektywnych odczuć obywateli będą podlegały systematycznej, dogłębnej analizie porównawczej celem prognozowania trendów zagrożeń oraz tworzenia mapy zagrożeń w województwie podkarpackim.

Portal będzie zasilany danymi statystycznymi, pozyskiwanymi od formacji mundurowych (Policja, Straż Graniczna, Państwowa Straż Pożarna, Służba Ochrony Kolei, Inspektorat Transportu Drogowego, Straż Miejska).

Zagrożenia będą analizowane cyklicznie, natomiast raz w roku będzie sporządzany kompleksowy raport, który zostanie zamieszczony na portalu w celu dotarcia z tą informacją do społeczeństwa. W piątym roku realizacji projektu dodatkowo sporządzony zostanie raport ewaluacyjny, który wskaże na ewentualną zasadność utrzymania w kolejnych latach zaprojektowanego narzędzia.

Narzędzie, jakie zostanie utworzone w ramach portalu będzie służyło szerokiemu gronu odbiorców: przede wszystkim studentom, obywatelom, przedsiębiorcom planującym rozwój działalności na terenie województwa, władzom samorządowym (zwłaszcza w ramach prac Powiatowych Komisji Bezpieczeństwa i Porządku Publicznego) i rządowym (wojewódzkim) służbom mundurowym odpowiedzialnym za zapewnienie bezpieczeństwa regionalnego. Projekt umożliwi planowanie adekwatnych do pojawiających się zagrożeń działań zapobiegających i ograniczających te zjawiska oraz wspomoże efektywne zarządzanie bezpieczeństwem w regionie.

Projekt wdrożenia Podkarpackiej Mapy Zagrożeń Kryminalnych wpisuje się w założenia Celu 7. Rządowej Strategii Sprawne Państwo.

System przewiduje integrację z usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych, posiadających profil zaufany w przedmiotowym systemie.

Szczegółowe wymagania funkcjonalne dotyczące usługi e-lista klinika bezpieczeństwa zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
EKB-1	E-klinika bezpieczeństwa
EKB-2	Usługa E-klinika bezpieczeństwa skierowana do studentów, musi wspierać kształcenie praktyczne. Narzędzie musi wspomagać wykorzystanie nabytej wiedzy teoretycznej w praktyce.	W
EKB-3	System musi udostępniać mechanizmy pozwalające na prowadzenie działalności informacyjnej w obszarze tematyki szeroko rozumianego bezpieczeństwa.	W
EKB-4	System musi posiadać funkcjonalność pozwalającą na prezentację treści opisowych.	W
EKB-5	System w ramach e-usługi klinika bezpieczeństwa musi pozwalać na publikację wybranych przez Uczelnie treści statycznych.	W
EKB-6	System musi pozwalać na kategoryzowanie treści statycznych.	W
EKB-7	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii treści statycznych.	W
EKB-8	System musi pozwalać na publikowanie treści dostępnych dla zalogowanych użytkowników oraz treści ogólnodostępnych.	W
EKB-9	System musi prezentować wszystkie treści statyczne w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania wpisów.	W
EKB-10	System musi pozwalać na podgląd szczegółów treści statycznych, poprzez wejście w dany wpis z poziomu listy.	W
EKB-11	System w ramach e-usługi musi udostępniać mechanizmy pozwalające na nadawanie uprawnień studentom do modułu E-klinika bezpieczeństwa.	W
EKB-12	Moduł musi umożliwiać: 1. Rejestrację osób zainteresowanych udzielaniem porad; 2. Rejestrację konta klienta, osoby zainteresowanej otrzymaniem porady prawnej; 3. Zgłoszenie wniosku o udzielenie porady prawnej; 4. Określenie zakresu konsultacji - wybór obszaru ze zdefiniowanej listy; 5. Przegląd zgłoszonych wniosków; 6. Podgląd statusu zgłoszonych wniosków;	W
EKB-13	System musi umożliwiać studentom zgłoszenie chęci współpracy w ramach działalności prowadzonej przez E-klinikę bezpieczeństwa.	W
EKB-14	Zgłoszenia współpracy muszą być realizowane poprzez formularz internetowy.	W
EKB-15	System w ramach swoich funkcjonalności przewidywać musi możliwość integracji z	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	usługą ePUAP w obszarze uwierzytelniania użytkowników zewnętrznych.
EKB-16	System musi umożliwiać określenie danych informacyjnych charakteryzujących zakres działania E-kliniki bezpieczeństwa w tym: 1. Regulamin 2. Informacje prawne 3. Materiały pomocnicze 4. Załączniki	W
EKB-17	System musi pozwalać na określenie operatorów usługi, poprzez nadanie uprawnień, w tym: 1. Osoby potwierdzające rejestrację terminów spotkań; 2. Opiekuna sekcji; 3. Osoby rozpatrujące sprawy;	W
EKB-18	System musi pozwalać na wprowadzenie danych personalnych klienta w celu przeprowadzenia rejestracji terminu spotkania.	W
EKB-19	System musi pozwalać na przesłanie powiadomienia drogą mailową zawierającego potwierdzenie spotkania.	W
EKB-20	System musi umożliwiać określenie danych informacyjnych charakteryzujących sprawę w tym: 1. Rodzaj sprawy; 2. Załączone dokumenty dotyczące sprawy; 3. Opis oraz opinie sprawy;	W
EKB-21	System musi pozwalać na kategoryzowanie spraw.	W
EKB-22	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości kategorii/rodzaju sprawy.	W
EKB-23	System musi pozwalać na definiowanie danych opisowych spraw w celach informacyjnych dla osób zainteresowanych.	W
EKB-24	System musi pozwalać na dodawanie plików i załączników przy definiowaniu spraw.	W
EKB-25	System musi pozwalać na określenie osoby rozpatrującej zgłoszoną sprawę.	W
EKB-26	System musi umożliwiać określenie status sprawy.	W
EKB-27	Pojedyncza sprawa musi zostać opisana przynajmniej przez następujące dane: 1. Tytuł sprawy 2. Data złożenia wniosku sprawy 3. Rodzaj sprawy 4. Opis sprawy 5. Lista załączników dotyczących sprawy 6. Status 7. Osoba rozpatrująca	W
EKB-28	System musi udostępniać mechanizm potwierdzenia lub odrzucenia terminu konsultacji sprawy przez opiekuna sekcji.	W
EKB-29	System musi posiadać mechanizm informujący osobę zapisującą się na spotkanie o odrzuceniu bądź akceptacji terminu konsultacji drogą mailową.	W
EKB-30	System w wysyłanym powiadomieniu droga mailową, z prośba o potwierdzenie bądź odrzucenie terminu konsultacji, musi posiadać możliwość akceptacji terminu z poziomu wiadomości email, bez konieczności logowania się do systemu.	W
EKB-31	System musi posiadać mechanizmy prezentacji wszystkich zdefiniowanych w systemie spraw osobom rozpatrującym.	W
EKB-32	System musi prezentować wszystkie złożone wnioski w postaci stronicowanej listy, z	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	możliwością filtrowania i wyszukiwania wpisów.
EKB-33	System musi pozwalać na podgląd szczegółów złożonego wniosku, poprzez wejście w dany wniosek z poziomu listy.	W
EKB-34	Funkcjonalność składania wniosku dostępna będzie tylko dla zarejestrowanych w systemie użytkowników.	W
EKB-35	Wszyscy zalogowanie na froncie systemu użytkownicy muszą mieć dostęp do funkcjonalności „Mojego konta”.	W
EKB-36	System w ramach funkcjonalności „Moje konto” musi pozwalać na prezentację złożonych przez użytkownika spraw w postaci stronicowanej listy.	W
EKB-37	System musi pozwalać użytkownikom na podgląd szczegółów sprawy, dołączonych plików oraz statusu.	W
EKB-38	System musi pozwalać na konfiguracje harmonogramu otwarcia kliniki.	W
EKB-39	Harmonogram otwarcia E-kliniki bezpieczeństwa może być konfigurowany tylko przez uprawnionych użytkowników wewnętrznych systemu.	W
EKB-40	System musi pozwalać na zdefiniowanie przedziałów godzin w których możliwe będą konsultacje z osobami rozpatrującymi.	W
EKB-41	Formularz konfiguracji przedziałów czasowych musi być zawierać przynajmniej dane: 1. Dzień – Data konsultacji; 2. Przedział godzinowy; 3. Miejsce konsultacji;	W
EKB-42	System musi pozwalać na zdefiniowanie konsultacji cyklicznych w wybranych dniach i przedziałach godzinowych.	W
EKB-43	Widok harmonogramu musi pozwalać na wyświetlanie: 1. w formie listy, 2. w formie kalendarza.	W
EKB-44	Widok harmonogramu w formie kalendarza to widok kalendarza miesięcznego z możliwością przeskoczenia do następnych miesięcy lub powrotu do poprzednich.	W
EKB-45	Kalendarz musi prezentować dni tygodnia w postaci kafelków, musi zaznaczać aktualny dzień, musi zawierać opisy dni tygodnia.	W
EKB-46	W przypadku wystąpienia konsultacji w danym dniu, kafelek kalendarza musi zostać wyraźnie oznaczony, a informacje o konsultacjach w tym dniu muszą być dostępne w formie skróconej po najechaniu myszką na ten dzień (tooltip).	W
EKB-47	System musi pozwalać na podgląd szczegółów konsultacji, poprzez wejście w dany wpis z poziomu listy lub kalendarza.	W
EKB-48	W ramach dostępu do szczegółów konsultacji, system musi pozwolić na użytkownikom na zapis na wybrane konsultacje.	W
EKB-49	Zapis na dane konsultacje musi nastąpić poprzez wypełnienie formularza internetowego.	W
EKB-50	System musi umożliwiać wprowadzenie danych statystycznych do systemu.	W
EKB-51	1. Na pojedynczy rekord danych statystycznych muszą składać się przynajmniej następujące pola: 2. Powiat; 3. Gmina; 4. Kategoria/rodzaj zdarzenia; 5. Data wystąpienia zagrożenia;	W
EKB-52	System musi pozwalać na wprowadzenie danych w okresach czasowych.	W
EKB-53	System musi umożliwiać wprowadzanie przynajmniej następujących danych	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	słownikowych: 1. Powiat; 2. Gmina; 3. Kategoria/rodzaj zdarzeń;
EKB-54	W systemie musi znajdować się mechanizm pozwalający na zdefiniowanie dowolnej ilości wartości słownikowych przynajmniej dla następujących danych: 1. Powiat; 2. Gmina; 3. Kategoria/rodzaj zdarzeń;	W
EKB-55	System musi umożliwiać konfigurowanie parametrów interaktywnej mapy zagrożeń kryminalnych.	W
EKB-56	System musi prezentować wszystkie zdefiniowane rekordy z danymi statystycznymi w postaci stronicowanej listy, z możliwością filtrowania i wyszukiwania rekordów.	W
EKB-57	System musi pozwalać na eksport danych statystycznych do pliku.	W
EKB-58	System musi pozwalać na podgląd szczegółów rekordu, poprzez wejście w dany rekord z poziomu listy.	W
EKB-59	System musi pozwalać na wygenerowanie interaktywnej mapy bezpieczeństwa na podstawie zgromadzonych danych statystycznych.	W
EKB-60	System musi pozwalać na filtrowanie danych przedstawionych na mapie interaktywnej według zadanych kryteriów.	W
EKB-61	System musi umożliwiać filtrowanie punktów prezentowanych na mapie przynajmniej według: 1. Powiat; 2. Gmina; 3. Kategoria/rodzaj zdarzeń; 4. Okres czasowy (dzień, miesiąc, rok);	W
EKB-62	System musi pozwalać na możliwość prezentacji wielu punktów na mapie zagrożeń wraz z informacją o nich.	W
EKB-63	W ramach wyświetlania punktów na mapie system musi pozwalać na prezentację opisu punktu, po kliknięciu w niego.	W

2.4.11. Interaktywny System Badań

Cel: przeprowadzanie badań na potrzeby Uczelni, instytucji publicznych, instytucji otoczenia biznesu oraz innych podmiotów.

E-usługa powinna zostać oparta o aplikację portalową do ankietowania. Poniżej przedstawiono szeroki zakres tematyczny przeprowadzanych badań. Dane z przeprowadzonych badań będą udostępniane na podstawie przyjętych założeń projektowych.

Narzędzia do przygotowania oraz publikacji elektronicznych ankiet pozwolą na skuteczne profilowanie problematyki oraz obszaru objętego badaniami. Usługa powinna obejmować tworzenie dynamicznych formularzy do przeprowadzania ankiet wśród użytkowników portalu oraz zbieraniem danych z przeprowadzanych ankiet. Ankiety muszą mieć możliwość dołączania do treści publikowanych w różnych strukturach portalu WWW.

System do przeprowadzenia badań za pośrednictwem ankiet powinien umożliwić:

1. Tworzenie ankiet otwartych, dostępnych dla anonimowych, nieuwierzytelnionych użytkowników

2. Tworzenie ankiet zamkniętych, dostępnych tylko dla zalogowanych, uwierzytelnionych użytkowników Moduł ankiet musi umożliwić x.xx. zarządzanie ankietami w zakresie:

1. Przeglądania wszystkich dodanych ankiet;

2. Edycji ankiet, jeżeli ankieta nie została opublikowana;

3. Przeglądania pytań przydzielonych do ankiet;

4. Dodawania, edytowania pytań, jeżeli ankieta nie została opublikowana;

5. Przeglądania odpowiedzi na poszczególne pytania w ankietach;

6. Eksport wyników ankiet w formie pliku csv;

7. Przeglądania ankiet według statusu;

8. Sortowania ankiet po nazwie, dacie dodania, autorze;

9. Sortowania pytań w ankietach;

10. Pojedynczego i masowego przenoszenia ankiet do kosza;

Szczegółowe wymagania funkcjonalne dotyczące Interaktywny System Badań zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
ISB-1	Interaktywny System Badań
ISB-2	Interaktywny System Badań musi posiadać moduł ankiet służących do zbierania opinii wśród użytkowników systemu.	W
ISB-3	Interaktywny System Badań musi pozwalać na dodawanie definicji ankiet oraz definicji pytań dostępnych w konkretnej ankiecie.	W
ISB-4	System musi pozwalać na dodawanie ankiet jedynie osobom zalogowanym i z odpowiednimi uprawnieniami.	W
ISB-5	Prezentacja ankiety musi polegać na wyświetleniu jej danych opisowych – nazwa, pole wstęp. Wyświetlenie samych pytań musi nastąpić po aktywacji ankiety przez samego użytkownika przyciskiem rozpocznij ankietę.	W
ISB-6	Na pojedynczą ankietę muszą składać się przynajmniej pola: 1. nazwa ankiety, 2. tytuł ankiety, 3. data publikacji od, data publikacji do, 4. opis, 5. wstęp (edytor WYSIWYG), 6. ankieta anonimowa, 7. publikacja wyników ankiety, 8. liczba wypełnień ankiety 9. status publikacji.	W
ISB-7	W systemie badań, ankieta musi posiadać obsługę procesu zatwierdzania treści ankiety i jej publikacji w systemie.	W
ISB-8	W systemie badań, moduł ankiet musi posiadać funkcjonalność kosza polegająca na usunięciu i możliwości przywrócenia ankiety z kosza.	W
ISB-9	W systemie badań, ankieta musi podlegać procesowi wersjonowania wpisów.	W
ISB-10	Interaktywny System Badań musi pozwalać na wypełnienie ankiet jako anonimowych, wówczas nawet przy zalogowanym użytkowniku system nie pobiera o nim informacji, jak również musi być możliwość oznaczenie ankiety dostępnej tylko dla zalogowanych użytkowników, wówczas zapisywane są dane o osobie wypełniającej ankietę.	W
ISB-11	Interaktywny System Badań musi pozwalać na określenie ilości ankiet do wypełnienia. Po osiągnięciu tej ilości, ankieta jest niedostępna do wypełnienia.	W
ISB-12	Interaktywny System Badań musi pozwalać na publikacje wyników ankiet. W przypadku pytań zamkniętych system musi generować graficzne statystyki.	W
ISB-13	Interaktywny System Badań musi posiadać funkcjonalność tworzenia ankiety na	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	podstawie ankiety już istniejącej.
ISB-14	System musi posiadać zabezpieczenie spójności danych polegający na tym, że w przypadku ankiety wypełnionej przynajmniej raz nie mogą być zmieniane pytania tej ankiety.	W
ISB-15	System musi pozwolić na podgląd wypełnień danej ankiety z poziomu panelu administracyjnego.	W
ISB-16	System musi pozwolić na eksport wypełnień danej ankiety do ustrukturyzowanego pliku tekstowego. Co umożliwi dostarczenie danych do innych systemów (niezintegrowanych) w celu analizy danych	W
ISB-17	System musi pozwalać na sortowanie pytań w obrębie konkretnej ankiety, o ile ankieta nie została jeszcze wypełniona.	W
ISB-18	Interaktywny System Badań musi pozwolić na dodawanie przynajmniej poniższych typów pytań do ankiety: 1. pytanie jednokrotnego wyboru, 2. pytanie wielokrotnego wyboru, 3. pytanie typu select, 4. pytanie z otwartą odpowiedzią w polu typu input, 5. pytanie z otwartą odpowiedzią w polu typu textarea, 6. pytanie matrycowe, 7. opis, 8. podział strony, 9. załącznik.	W
ISB-19	System musi pozwalać na definiowanie dodatkowych parametrów dla powyższych pól, takich jak: 1. nazwa pola, 2. długość pola – dla pól tekstowych, 3. dodatkowy opis nad i pod polem, 4. wymagalność pola na formularzu, 5. widoczność pola na formularzu na froncie.	W
ISB-20	Dla modułu ankiet, system musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy ankiet, 2. dodawanie ankiety, 3. edycja ankiety, 4. przenoszenie ankiety do kosza, 5. przywracanie ankiety z kosza, 6. usuwanie ankiety, 7. publikacja, zatwierdzanie ankiety, 8. wersjonowanie ankiety, 9. dostęp do pytań, 10. dodawanie pytań, 11. edycja pytań, 12. usuwanie pytań. 13. Zarządzanie tylko własnymi ankietami	W
ISB-21	System musi pozwalać na nadawanie powyższych uprawnień osobno lub w różnych wariantach.	W
ISB-22	System musi pozwalać na osadzanie ankiety za pomocą [shortcodes] w edytorze WYSIWYG. Użycie ankiety poprzez [shortcodes] musi być co najmniej w modułach:	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	aktualności, opisowym, formularzu kontaktowym, liście plików, liście stron.
ISB-23	Ankiety osadzanie za pomocą [shortcodes] w edytorze WYSIWYG muszą pokazać się od razu, bez konieczności kliknięcia w przycisk start ankiety.	W
ISB-24	Interaktywny System Badań musi posiadać blok prezentujący ankietę, który może być użyty w strukturze stron Portalu	W

2.4.12. Usługa E-Repozytorium

Cel: Udostępnianie materiałów dydaktycznych w formie cyfrowej np.: materiałów z wykładów, prezentacji, nagrań wykładów, wyników badań itp. dla wszystkich użytkowników Platformy lub wybranej grupy docelowej użytkowników (np. dla studentów z konkretnego rocznika czy konkretnej grupy ćwiczeniowej).

Prowadzący, jeśli nie ma dokumentów w postaci cyfrowej, digitalizuje je (w procesie digitalizacji dokument powinien zostać opisany metadanymi koniecznymi do poprawnego wyszukiwania dokumentu), następnie musi mieć możliwość określenia grupy docelowej, dla której dany materiał ma być dostępny w Platformie. Po określeniu tych informacji dany materiał w formie elektronicznej powinien być dostępny na podstronie prowadzącego utworzonej w ramach głównego portalu WWW uczelni (Platformie). W zależności od nadanych uprawnień dokument może być przeglądany/pobrany przez każdego użytkownika, który wejdzie na tą stronę, lub tylko przez użytkowników, którym zostały nadane odpowiednie uprawnienia. Oprogramowanie musi być zintegrowane z usługą Active Directory istniejącą na Uczelni. Dzięki współpracy aplikacji e-repozytorium z usługą katalogową będzie możliwe dystrybuowanie treści/materiałów do wybranych grup użytkowników lub do wszystkich osób nawet tych, które nie mają konta w systemie katalogowym Uczelni.

Usługę będzie świadczył Pion Dydaktyczny przy wsparciu Działu Informatyki WSPiA Rzeszowskiej Szkoły Wyższej. Szczegółowe wymagania funkcjonalne dotyczące E-repozytorium zawiera poniższa tabela.

Nr wymagania	Opis wymagania	Funkcjonalność W/O
ER-1	E-repozytorium
ER-2	System musi pełnić funkcję repozytorium dokumentów z wszystkich portali uruchomionych w ramach Platformy	W
ER-3	System musi posiadać wyszukiwarkę szukającą po wszystkich dokumentach opisanych metadanymi.	W
ER-4	System musi wyświetlać linki do dokumentów wraz z opisem i przypisanymi do dokumentu tagami.	W
ER-5	System musi uwzględniać uprawnienia które zostały nadane deponowanym dokumentom w poszczególnych portalach.	W
ER-6	System musi wyświetlać dokumenty w formie listy.	W
ER-7	System musi posiadać stronicowanie listy dokumentów.	W
ER-8	System musi wyświetlać informacje z którego portalu pochodzi dokument i do jakiego modułu został dodany.	W
ER-9	System musi być zintegrowany z usługa katalogową Active Directory istniejącą na Uczelni.	W

3. Ogólne wymagania funkcjonalne i techniczne.

Funkcjonalności ogólne dla platformy webowej przeznaczonej do realizacji e-usług:

E-tablica ogłoszeń; E-kontakt; E-klinika prawa; E-klinika administracji; E-Klinika przedsiębiorczości; E-klinika bezpieczeństwa; Interaktywny system badań; E-repozytorium

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-1	Uwierzytelnianie
WF-2	Platforma e-usług musi umożliwiać uwierzytelnienie użytkowników zewnętrznych (Obywateli) z wykorzystaniem poświadczeń Profilu Zaufanego obsługiwanych przez platformę ePUAP	W
WF-3	Platforma e-usług musi poprawnie realizować funkcje jednokrotnego logowania (SSO- single sign-on) z wykorzystaniem funkcjonalności oferowanej w ramach platformy ePUAP .	W
WF-4	Platforma e-usług musi poprawnie obsłużyć mechanizm generowania i utrzymania Identyfikatora Sesji TGSID w ramach SSO realizowanego z wykorzystaniem platformy ePUAP.	W
WF-5	Platforma e-usług musi umożliwiać uwierzytelnienie użytkowników wewnętrznych (Pracownicy administracji, pracownicy dydaktyczni, administratorzy) z wykorzystaniem indywidualnych poświadczeń konta użytkownika usługi katalogowej Active Directory.	W
WF-6	Dodatkowo platforma e-usług musi zapewniać możliwość uwierzytelnienia wszystkich użytkowników z wykorzystaniem lokalnego konta systemu portalowego, zapewniając w ten sposób alternatywną formę autoryzacji.	W
WF-7	Dla użytkowników zewnętrznych (Obywateli) konto lokalne powinno być zakładane w procesie samodzielnej rejestracji i musi ono być jednoznacznie powiązane w systemie portalowym z kontem użytkownika Profilu Zaufanego obsługiwanego w ramach platformy ePUAP .	W
WF-8	Dla użytkowników wewnętrznych (Pracownicy administracji, pracownicy dydaktyczni, administratorzy) konto lokalne musi być zakładane przez administratora systemu portalowego z poziomu panelu administracyjnego i musi ono być jednoznacznie powiązane z kontem usługi Katalogowej Active Directory.	W
WF-9	Multi portalowość
WF-10	Platforma multiportalowa musi umożliwiać tworzenie wielu niezależnych od siebie serwisów i stron www.	O
WF-11	Uruchomione portale mogą różnić się funkcjonalnościami, ale w obrębie dostępnych (opisanych w niniejszym dokumencie).	O
WF-12	Uruchomione portale mogą różnić się grafiką, ale w obrębie dostępnych szablonów (opisanych w niniejszym dokumencie).	O
WF-13	Architektura środowiska multiportalowego musi bazować na wspólnym serwerze plików i WWW.	O
WF-14	Całe środowisko multiportalowe musi pracować w oparciu o wspólną bazę danych.	O
WF-15	Środowisko multiportalowe musi bazować na systemie zarządzania treścią CMS (ang. Content Management System).	O
WF-16	Konfiguracja platformy multiportalowej musi umożliwiać wskazanie domeny, pod którą będzie funkcjonował portal główny oraz wyszczególnienie subdomen w których będą funkcjonowały pozostałe portale internetowe.	O

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-17	Platforma multiportalowa musi umożliwiać działanie stron na domenach alternatywnych (oprócz portalu głównego). Domena alternatywna musi być nadrzędna dla subdomeny.	O
WF-18	Platforma multiportalowa musi posiadać oddzielny mechanizmy administracyjne w postaci: • globalnego panelu administracyjnego umożliwiającego zarządzanie wszystkimi portalami uruchomionymi w obrębie platformy multiportalowej, • lokalnego panelu administracyjnego umożliwiającego zarządzanie pojedynczym portalem w obrębie platformy portalowej.	O
WF-19	Panel globalny – zarządzanie portalami
WF-20	System musi posiadać oddzielny panel globalny do zarządzania wszystkimi portalami uruchomionymi w jego obrębie.	W
WF-21	Panel globalny musi pozwalać na tworzenie wielu niezależnych portali, różniących się treściami i funkcjonalnościami.	W
WF-22	Użytkownicy panelu globalnego muszą być oddzielenie od reszty systemu. Nie mogą mieć dostępu do „zwykłych” paneli administracyjnych.	W
WF-23	Użytkownicy z dostępem do panelu globalnego muszą mieć pełne uprawnienia w jego obszarze.	W
WF-24	Dostęp do panelu globalnego musi odbywać się poprzez połączenie szyfrowane (SSL).	W
WF-25	System musi pozwalać na dodawanie, edycję, konfigurację parametrów oraz usuwanie serwisów.	W
WF-26	System musi umożliwiać dodawanie portali w strukturze drzewiastej.	W
WF-27	System musi umożliwiać tworzenie nowych portali poprzez wypełnienie formularza lub jako kopię serwisu już istniejącego.	W
WF-28	System musi pozwalać na definiowanie takich parametrów portalu jak: 1. nazwa portalu, 2. symbol portalu, 3. położenie portalu w strukturze drzewa portali, 4. typ portalu, 5. szablon portalu, 6. domena portalu, 7. języki portalu, 8. portal aktywny, 9. portal dostępny, 10. moduły portalu.	W
WF-29	Symbol tworzonych portali musi być unikalny, ze względu na wykorzystanie go w linku, jako subdomeny domeny głównej.	W
WF-30	System portalowy musi umożliwiać włączanie/wyłączanie modułów (spośród wszystkich dostępnych w systemie) dla danego portalu przez administratora panelu globalnego, w zależności od potrzeb.	W
WF-31	System musi posiadać możliwość określenia typu projektu (lista rozwijana) przy uruchamianiu nowej witryny. Typy muszą odpowiadać stworzonym projektom graficznym i włączać funkcjonalności dedykowane (moduły) temu typowi portalu, bez konieczności manualnego zaznaczania ich.	W
WF-32	System portalowy musi pozwalać natworzenie nowych szablonów graficznych, na podstawie szablonów już istniejących.	W
WF-33	Panel administracyjny – zarządzanie treścią witryny

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-34	Każdy z portali uruchomionych w ramach multi portalu musi posiadać swój własny, niezależny panel administracyjny, umożliwiający zarządzanie jego danymi.	W
WF-35	Dostęp do panelu administracyjnego musi odbywać się poprzez połączenie szyfrowane (SSL).	W
WF-36	Każdy z portali uruchomionych w ramach multi portalu musi posiadać indywidualnie definiowaną strukturę, treści, ustawienia konfiguracyjne, administratorów itp.,	W
WF-37	System portalowy musi umożliwiać dodawanie administratorów o uprawnieniach pozwalających na zarządzanie kilkoma portalami wchodzącymi w skład systemu.	W
WF-38	Administrator posiadający uprawnienia do więcej niż jednego systemu musi posiadać możliwość przelogowania się między panelami tych portali, bez konieczności ręcznego wpisywania adresu panelu danej strony w przeglądarce.	W
WF-39	Funkcjonalności dostępne w panelu administracyjnym muszą zależeć od uprawnień jakie posiada zalogowany użytkownik.	W
WF-40	Zalogowany użytkownik musi widzieć jedynie te funkcjonalności, do których ma dostęp.	W
WF-41	Wersje językowe
WF-42	System musi umożliwić tworzenie wielu różnych wersji językowych stron WWW.	W
WF-43	Wersje językowe tej samej strony muszą być od siebie niezależne, tzn. mogą mieć różne struktury i treści.	W
WF-44	W momencie produkcyjnego uruchomienia systemu, Wykonawca musi zapewnić wsparcie dla wersji polskiej oraz angielskiej uruchamianych stron internetowych. Oznacza to, że wszystkie elementy nie będące edytowalnymi z poziomu panelu administracyjnego muszą być przetłumaczone (np. labele na button’ach).	W
WF-45	System musi posiadać możliwość dodawania nowych wersji językowych i wprowadzania ich tłumaczeń z poziomu panelu administracyjnego (np. etykiety na )	W
WF-46	System musi pozwalać na powiązywanie ze sobą tych samych treści w różnych wersjach językowych.	W
WF-47	W przypadku zmiany języka na podstronie, która posiada odpowiednik w wybranej wersji językowej, system musi przekierować użytkownika od razu na wybraną podstronę. W przypadku, gdy takiego powiązania nie ma, system musi przekierować użytkownika na stronę główną.	W
WF-48	Szablony graficzne
WF-49	System musi wspierać obsługę szablonów graficznych.	W
WF-50	Warstwa prezentacji danych musi być oddzielona od warstwy logiki.	W
WF-51	System musi posiadać oddzielne katalogi do przechowywania plików odpowiedzialnych za wygląd strony (np. html, css, js, img, obrazki).	W
WF-52	System musi posiadać oddzielne katalogi do przechowywania plików odpowiedzialnych za wygląd strony dla każdego szablonu osobno.	W
WF-53	System musi posiadać katalog wspólny dla wszystkich szablonów graficznych, do przechowywania np. wspólnych bibliotek js (java script).	W
WF-54	System musi pozwalać na nadpisywanie styli z katalogu głównego, stylami w katalogu konkretnego szablonu graficznego.	W
WF-55	System w momencie uruchomienia produkcyjnego musi posiadać szablony graficzne dla: 1. Platformy e-usług edukacyjnych	W
WF-56	System musi pozwalać na szybkie dodanie nowego szablonu graficznego przez administratora systemu.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-57	System musi pozwalać na dodanie nowego szablonu poprzez kopię już istniejącego i nadanie mu nazwy.	W
WF-58	Struktura portalu
WF-59	System musi posiadać możliwość definiowania menu, które tworzą strukturę portalu i informacji na stronie www.	W
WF-60	System musi pozwalać na tworzenie wielu niezależnych od siebie menu.	W
WF-61	System musi pozwalać na publikację menu w określonych na etapie analizy przedwdrożeniowej regionach strony (układ strony głównej oraz podstron).	W
WF-62	System musi pozwalać na tworzenie menu w postaci drzewa (struktura hierarchiczna) oraz na dowolne przepinanie dodanych już pozycji między dostępnymi menu.	W
WF-63	Dodane pozycje drzewa muszą reprezentować podstrony portalu.	W
WF-64	System musi prezentować zdefiniowane struktury w postaci drzewiastej oraz w postaci listy, z możliwością filtrowania i wyszukiwania.	W
WF-65	System musi pozwalać na definiowanie takich parametrów pozycji w menu jak: 1. nazwa strony, 2. symbol strony, 3. przypisanie strony do konkretnego menu i jej położenie w strukturze tego menu, 4. typ strony, 5. pokaż / ukryj w menu, 6. strona opublikowany, 7. strona dostępna dla zalogowanych, 8. opis strony (WYSIWYG), 9. zdjęcie strony, 10. układ strony.	W
WF-66	Symbol pozycji musi być unikalny w obrębie całej struktury informacji w portalu ze względu na jego późniejsze wykorzystanie w odnośnikach na stronie.	W
WF-67	Struktura portalu musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-68	Struktura portalu musi posiadać funkcjonalność kosza.	W
WF-69	Struktura portalu musi podlegać procesowi wersjonowania wpisów.	W
WF-70	System musi pozwolić administratorowi na podgląd danej strony, bez konieczności jej publikacji.	W
WF-71	Pozycje w menu muszą mieć możliwość przypisania jednej z poniższych funkcji (typ strony): 1. link do strony głównej, 2. link zewnętrzny (możliwość podania odnośnika do zewnętrznego portalu), 3. link wewnętrzny (alias do pozycji już istniejącej w ramach wszystkich dostępnych menu) 4. moduł (wybór funkcjonalności z listy dostępnych w systemie, moduły opisane są w dalszej części dokumentu).	W
WF-72	Opis strony oraz zdjęcie strony to elementy, które system musi wykorzystywać do graficznej prezentacji menu, do prezentacji listy podstron oraz do wyświetlania treści na podstronie w przypadku braku treści w podpiętym do pozycji module.	W
WF-73	System musi pozwalać na dodawanie wielu pozycji struktury z przypisanym tym samym modułem. Oznacza to, że w systemie będzie funkcjonowało np. kilka podstron z niezależnymi aktualnościami, dostępnymi pod różnymi odnośnikami.	W
WF-74	W przypadku modułu aktualności oraz kalendarium, system musi pozwalać na	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	oznaczenie tych modułów jako domyślne w obrębie konkretnego portalu.
WF-75	Tylko jedna strona o typie moduł aktualności może być oznaczona jako domyślna w portalu.	W
WF-76	Tylko jedna strona o typie moduł kalendarium może być oznaczona jako domyślna w portalu.	W
WF-77	W przypadku modułów opisowych (np. akapity, aktualności) system musi pozwalać administratorowi na wyświetlanie elementów społecznościowych na tej podstronie.	W
WF-78	Kosz systemowy
WF-79	System musi posiadać funkcjonalności kosza systemowego.	W
WF-80	Usuwane z systemu elementy nie mogą być fizycznie usunięte z serwera. Muszą zostać przeniesione do kosza.	W
WF-81	Każda z funkcjonalności lub modułów musi posiadać swój własny kosz. Kosz ten musi funkcjonować w obrębie modułu przypiętego do konkretnej strony.	W
WF-82	Elementy w koszu mogą zostać przywrócone lub faktycznie usunięte z kosza.	W
WF-83	Elementy przeniesione do kosza, nie mogą być widoczne na froncie strony.	W
WF-84	Elementy przywrócone z kosza muszą posiadać status nieopublikowany, bez względu na to jaki miały status przed przeniesieniem do kosza.	W
WF-85	System w ramach panelu administracyjnego musi posiadać funkcjonalność wyświetlania wszystkich elementów w koszu w danym systemie, tak by administrator nie musiał przechodzić przez wszystkie strony portalu.	W
WF-86	W ramach funkcjonowania uprawnień w portalu, system musi pozwalać na zdefiniowanie użytkownika o uprawnieniach przenoszenia do kosza, przywracania z kosza i usuwania z kosza w ramach funkcjonowania modułu konkretnej podstrony. System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-87	Publikacja treści
WF-88	System musi posiadać funkcjonalności zatwierdzania i publikacji treści opisowych.	W
WF-89	Aby wpis / treść była widoczna na froncie strony musi mieć zaznaczone dwie flagi: zatwierdzony opublikowany	W
WF-90	Widoczność flagi zatwierdź oraz opublikuj musi zależeć od uprawnień redaktora wprowadzającego treści.	W
WF-91	System musi pozwalać na podgląd wprowadzonych treści opisowych bez konieczności ich zatwierdzenia i publikacji.	W
WF-92	System musi kontrolować statusy powyższych flag i pozwalać na publikację wyłącznie tych wpisów, które zostały uprzednio zatwierdzone. Nie można opublikować wpisu bez wcześniejszego zatwierdzenia.	W
WF-93	System w ramach panelu administracyjnego musi posiadać funkcjonalność wyświetlania wszystkich elementów, które oczekują na zatwierdzenie lub publikację w danym systemie w jednym miejscu.	W
WF-94	W ramach funkcjonowania uprawnień w portalu, system musi pozwalać na zdefiniowanie użytkownika o uprawnieniach do zatwierdzania oraz do publikowania treści w ramach funkcjonowania modułu konkretnej podstrony. System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-95	Multimedia
WF-96	System musi posiadać repozytorium plików.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-97	Wszystkie pliki udostępniane na witrynach systemu muszą wcześniej znaleźć się w repozytorium.	W
WF-98	Repozytorium plików musi pozwalać na katalogowanie plików (tworzenie grup i podgrup) w celu zachowania porządku w danych wysyłanych na serwer.	W
WF-99	Tworzenie i zarządzanie katalogami nie może mieć ograniczeń co do ich ilości i zagłębień.	W
WF-100	System musi pozwalać na masowe dodawanie multimediów z dysku lokalnego komputera do repozytorium plików.	W
WF-101	System musi przechowywać repozytorium w osobnym katalogu na serwerze, w celu prostego tworzenia kopi bezpieczeństwa wrzucanych na serwer plików.	W
WF-102	System w swojej konfiguracji musi posiadać możliwość zdefiniowania typów plików możliwych do wrzucenia do repozytorium.	W
WF-103	System musi pozwalać na zmianę nazw plików i katalogów.	W
WF-104	System musi pozwalać na nadawanie plikom dodatkowych opisów oraz słów kluczowych.	W
WF-105	W przypadku obrazów administratorzy muszą widzieć miniatury plików w postaci podgląd danego obrazu. W przypadku innych plików system musi pokazywać ikony z symbolami rozszerzeń tych plików.	W
WF-106	Wszystkie dodawanie do repozytorium pliku muszą standardowo przyjmować status opublikowane.	W
WF-107	Widok repozytorium plików musi pozwalać na przełączanie się między kafelkami a szczegółami. W lewej części repozytorium musi znaleźć się hierarchiczna struktura katalogów, pomagająca w poruszaniu się po repozytorium.	W
WF-108	Tylko pliki opublikowane mogą być używane w treściach portalu.	W
WF-109	W ramach repozytorium musi istnieć funkcjonalność kosza.	W
WF-110	Pliki, które zostały od publikowane nie mogą być używane w treściach portalu, czyli nie mogą być wykorzystywane przez redaktorów. Oznacza to, że nie można ich dodać w nowych treściach. Natomiast te, które są wyświetlane aktualnie w treściach portalu a zostały od publikowane musza zniknąć z frontu strony www.	W
WF-111	System w ramach repozytorium plików musi pozwalać na wyszukiwanie plików po: 1. nazwie, 2. opisie, 3. słowach kluczowych, 4. statusie publikacji.	W
WF-112	Repozytorium plików musi być podzielone na: katalog publiczny portalu, katalogi prywatne użytkowników.	W
WF-113	System musi pozwalać na przyznawanie użytkownikom uprawnień do repozytorium z podziałem na: 1. dostęp wyłącznie do katalogu publicznego portalu, 2. dostęp do katalogu publicznego portalu oraz katalogu prywatnego użytkownika, 3. dostęp wyłącznie do katalogu prywatnego użytkownika.	W
WF-114	System musi posiadać możliwość definiowania szczegółowych uprawnień do każdego katalogu i pliku w repozytorium, w tym na zmianę publikacji, dodawanie plików do katalogów, usuwanie do kosza, przywracanie z kosza.	W
WF-115	System musi pozwalać na kadrowanie zdjęć umieszczanych w treściach stron.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-116	Układ podstron
WF-117	System musi pozwalać administratorowi na zarządzanie układem stron.	W
WF-118	System musi pozwalać na zarządzanie układem strony głównej oraz układem podstron.	W
WF-119	Układ strony głównej oraz podstron muszą zostać wypracowane na etapie analizy przedwdrożeniowej oraz podczas prac nad projektami graficznymi systemu.	W
WF-120	Strony (w tym główna) muszą zostać podzielone na regiony, w których będą prezentowane bloki z treściami.	W
WF-121	Przypisywanie bloków do regionów musi odbywać się za pomocą mechanizmów drag & drop. (przeciągnij i upuść)	W
WF-122	System musi pozwalać na definiowanie szablonów układów podstron i przypisywanie ich do stron (struktura portalu).	W
WF-123	System musi pozwalać na definiowanie szablonów układów strony głównej.	W
WF-124	System musi pozwalać na czasowe definiowanie układu strony głównej.	W
WF-125	Przy definiowaniu szablonu podstrony system musi pozwalać na przypisanie do niego schematu SEO.	W
WF-126	Wersje graficzne
WF-127	System musi wspierać funkcjonalności wersji graficznych portali.	W
WF-128	Wersje graficzne mają służyć do zmiany elementów graficznych portali wchodzących w skład multi portalu ze względu na ważne wydarzenia i uroczystości.	W
WF-129	System musi uwzględniać następujące wersje graficzne portali: 1. wersja zwykła (wyświetlana codziennie), 2. wersja żałobna, 3. wersja bożonarodzeniowa, 4. wersja wielkanocna, 5. wersja patriotyczna.	W
WF-130	Każda z wersji graficznych musi zakładać zmiany kilku elementów graficznych (ustalonych na etapie tworzenia grafiki) w celu zaakcentowania danego wydarzenia.	W
WF-131	W przypadku wersji żałobnej portali system musi wyświetlać wszystkie grafiki (wraz ze zdjęciami i miniaturkami zdjęć) w odcieniach szarości.	W
WF-132	System musi pozwalać na włączenie konkretnej wersji graficznej w zdefiniowanych okresie czasu.	W
WF-133	Użytkownicy
WF-134	System musi pozwalać na gromadzenie i przechowywanie danych o jego użytkownikach.	W
WF-135	System musi zapewnić poprawne zbieranie i przetwarzanie danych osobowych użytkowników. W obu tych obszarach musi zapewnić zgodność z wymogami prawnymi oraz dobrymi praktykami.	W
WF-136	System musi tworzyć rejestr wszystkich prób uwierzytelnienia użytkowników, zakończonych zarówno powodzeniem jak i niepowodzeniem.	W
WF-137	Rejestr uwierzytelniania musi przechowywać maksymalnie wiele informacji, pozwalających na identyfikację uwierzytelniania. Muszą to być x.xx.: 1. pełna data i czas, 2. nazwa konta, które zostało poddane autoryzacji, 3. adres IP, z którego nawiązano połączenie, 4. dane sesyjne i serwerowe, 5. rezultat autoryzacji (powodzenie/niepowodzenie).	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-138	System musi zapewnić interfejs do przeglądania i przeszukiwania rejestru uwierzytelniania.	W
WF-139	System musi zostać zintegrowany z funkcjonującą w organizacji usługą katalogową (AD). Integracja ta musi pozwolić na autoryzację użytkowników (pracownicy) administracyjnych w portalach danymi domenowymi.	W
WF-140	System musi przechowywać dane użytkowników AD w swojej bazie, co jest konieczne ze względu na możliwość przyznawania rozbudowanych uprawnień do treści w portalu.	W
WF-141	Dane użytkownikach z AD muszą być zintegrowane z systemem za pomocą zadań cyklicznych (CRON’a).	W
WF-142	System musi pozwalać na zakładanie dodatkowych kont użytkowników w obrębie samego systemu portalowego. Konta te mogą być zakładane przez administratora z poziomu panelu CMS lub poprzez samodzielną rejestrację użytkowników na stronie.	W
WF-143	System musi pozwalać na konfigurację modułu rejestracji. Zakładane konta muszą być aktywowane przez administratora w panelu lub poprzez link weryfikacyjny, wysłany na podany przez użytkownika w procesie rejestracji email.	W
WF-144	System musi pozwalać jego administratorom na włączenie modułu rejestracji, w tym: 1. konfiguracji dowolnych pól formularza rejestracyjnego, 2. określenie ich wymagalności, 3. określenie nazw, 4. konfigurację zgód systemowych, 5. włączenie powiadomień mailowych i określenie ich treści, 6. konfigurację sposobu aktywacji użytkowników (od razu po rejestracji, aktywacja linkiem w mailu, aktywacja przez administratora).	W
WF-145	Identyfikator użytkownika (login) musi być unikalny w skali całego systemu multi portalowego, bez podziału na pod portale.	W
WF-146	Role i uprawnienia
WF-147	System musi umożliwiać tworzenie stref z ograniczonym dostępem.	W
WF-148	Funkcjonalności stref z ograniczonym dostępem do systemu muszą dotyczyć zarówno panelu administracyjnego jak i treści publikowanych na froncie multi portalu.	W
WF-149	Ograniczenia w dostępie do poszczególnych stref muszą zostać rozwiązane za pomocą ról oraz grup uprawnień, gdzie: 1. rola – zbiór uprawnień w obrębie panelu administracyjnego, 2. grupa – struktura drzewiasta, do której należą użytkownicy.	W
WF-150	Dostęp do panelu administracyjnego konkretnego portalu, może mieć wyłącznie użytkownik, któremu przyznano prawo dostępu do logowania się do tego portalu. Taki użytkownik może być super administratorem tego portalu – posiada dostęp do wszystkich jego funkcjonalności lub ma dostęp wyłącznie do części opcji panelu, na podstawie uprawnień nadanych mu przez innego administratora.	W
WF-151	System musi posiadać możliwość nadawania użytkownikom uprawnień indywidualnych oraz poprzez przypisanie do roli.	W
WF-152	Uprawnienia przyznawane użytkownikom w systemie muszą się sumować.	W
WF-153	Udostępnianie na froncie systemu treści wyłącznie dla zalogowanych użytkowników musi odbywać się poprzez wskazanie konkretnych użytkowników lub wybór grupy użytkowników.	W
WF-154	System musi pozwalać na ręczne tworzenie grup użytkowników w poszczególnych panelach administracyjnych uruchomionych portali.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-155	System musi pozwolić na korzystanie z grup użytkowników zdefiniowanych w AD Zamawiającego. Dane te muszą być zintegrowane platforma e-usług za pomocą zadań cyklicznych (CRON’a).	W
WF-156	System musi posiadać możliwość definiowania uprawnień dla wszystkich modułów funkcjonujących w danym systemie (np. redaktor posiadający możliwość przeglądania wpisów we wszystkich uruchomionych modułach aktualności w danym portalu).	W
WF-157	System musi posiadać możliwość definiowania uprawnień do poszczególnych modułów w ramach witryny do której ten moduł jest przypisany (np. redaktor posiadający możliwość przeglądania wpisów wyłącznie z modułu aktualności na podstronie „Najnowsze wydarzenia” w danym portalu).	W
WF-158	System musi pozwalać na nadawanie uprawnień do wszystkich funkcjonalności i akcji w ramach tych funkcjonalności w portalu.	W
WF-159	Użytkownik posiadający możliwość nadawania uprawnień w systemie, nie może nadać uprawnień wyższych niż sam posiada.	W
WF-160	W ramach tworzenia stref z ograniczonym dostępem, system musi kontrolować dostęp do konkretnych podstron oraz do treści w tych podstronach. Niedopuszczalna jest sytuacja by treść była niedostępna, natomiast plik do pobrania w tej treści lub link do zdjęcia w tej treści pozwalał na zobaczenie go przez użytkowników bez prawa dostępu do tej sekcji (np. poprzez skopiowanie i przekazanie linku).	W
WF-161	API
WF-162	System musi posiadać API, które pozwoli na zdalną administrację systemem portalowym.	W
WF-163	API musi zostać wykonane w oparciu o rozwiązanie REST.	W
WF-164	Wszystkie metody dostępne w API zostaną sprecyzowane na etapie analizy przedwdrożeniowej, a ich ilość nie przekroczy 30.	W
WF-165	W chwili obecnej wymaga się by system posiadał metody pozwalające na: 1. pobranie informacji o uruchomionych portalach, 2. pobranie informacji o konkretnym portalu, 3. dodanie nowego portalu, 4. aktywacja / dezaktywacja portalu, 5. pobranie listy aktualności, 6. pobranie szczegółów konkretnej aktualności 7. dodanie aktualności, 8. edycja aktualności, 9. aktywacja / dezaktywacja aktualności, 10. usunięcie aktualności, 11. pobranie listy akapitów, 12. pobranie szczegółów konkretnego akapitu 13. dodanie akapitu, 14. edycja akapitu, 15. aktywacja / dezaktywacja akapitu, 16. usunięcie akapitu.	W
WF-166	Pełna dokumentacja API wraz z przykładami wywołania poszczególnych metod musi znaleźć się w dokumentacji powdrożeniowej systemu.	W
WF-167	Statystyki
WF-168	W ramach wdrożenia, Wykonawca musi dostarczyć system do monitorowania statystyk odwiedzin oraz analizy ruchu na stronach nowego portalu Zamawiającego.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-169	Statystyki muszą być rozbite per portal, z możliwość włączenia / wyłączenia ich na konkretnym portalu. Dostęp do interfejsu zbieranych danych muszą posiadać wyłącznie osoby wskazane przez głównego administratora portalu.	W
WF-170	System do zbierania statystyk musi zapewnić przynajmniej: godzinowe, dzienne, miesięczne i roczne statystyki odwiedzin portalu internetowego, liczbę użytkowników (w tym nowych i powracających), liczbę wizyt i odsłon witryny, a także czas trwania wizyty, statystyki odsłon poszczególnych podstron portalu, informacje, z jakich systemów operacyjnych, przeglądarek, rozdzielczości, korzystali użytkownicy, generowanie statystyk w formie graficznej.	W
WF-171	System do zbierania statystyk musi zostać zainstalowany lokalnie, na zasobach Zamawiającego.	W
WF-172	Wersjonowanie
WF-173	System musi posiadać funkcjonalności wersjonowania treści opisowych.	W
WF-174	Wersjonowanie musi być dostępne w każdej funkcjonalności systemu zarządzania służącej do publikacji treści użytkownikom (np. aktualności, wydarzenia, strony opisowe).	W
WF-175	Każda edycja treści, zmiana daty publikacji, statusu musi tworzyć nową wersję wpisu. Wersja poprzednia musi zostać od publikowana.	W
WF-176	System musi posiadać podgląd poprzednich wersji danego wpisu oraz możliwość oznaczenia tych wersji jako aktualnych (opublikowanych). W ten sposób jedna z poprzednich wersji (starych wersji) może stać się najnowszą wersją wpisu.	W
WF-177	W ramach funkcjonowania uprawnień w portalu, system musi pozwalać na zdefiniowanie użytkownika o uprawnieniach do przeglądania i oznaczania jako aktywne poprzednich wersji wpisów w ramach funkcjonowania modułu konkretnej podstrony. System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-178	Rejestr zmian
WF-179	System musi posiadać funkcjonalności rejestru zmian.	W
WF-180	System musi rejestrować wszystkie akcje i działania użytkowników portalu od strony panelu administracyjnego.	W
WF-181	System musi rejestrować takie akcje jak dodanie, edycja, usunięcie, przeniesienie do kosza, itd. wpisów w systemie	W
WF-182	Rejestr zmian musi przechowywać maksymalnie wiele informacji, pozwalających na identyfikację zmienianych danych. Muszą to być x.xx.: 1. pełna data i czas, 2. nazwa użytkownika dokonującego zmiany, 3. nazwa funkcjonalności, w obrębie której nastąpiła zmiana, 4. identyfikacja akcji w tej funkcjonalności np. dodanie wpisu, 5. różnice w wpisach, było – jest, 6. adres IP, z którego nawiązano połączenie, 7. dane sesyjne i serwerowe.	W
WF-183	Rejestr zmian musi zapewniać mechanizmy identyfikacji zmian wprowadzonych w wpisach. System musi pokazywać różnice w edytowanych treściach i wskazywać zmienione wartości w formularzach.	W
WF-184	System musi zapewnić intuicyjny interfejs do przeglądania i przeszukiwania rejestru	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	zmian.
WF-185	W ramach funkcjonowania uprawnień w portalu, system musi pozwalać na zdefiniowanie użytkownika o uprawnieniach z dostępem do rejestru zmian.	W
WF-186	SEO
WF-187	System portalowy musi być napisany z uwzględnieniem optymalizacji dla wyszukiwarek internetowych (SEO).	W
WF-188	System portalowy musi stosować przyjazne adresy, np. domena/strona/informacja.	W
WF-189	Funkcjonalności SEO muszą umożliwiać swobodny sposób definiowania metatagów strony, tj. tytułu strony, słów kluczowych strony oraz opisu strony, na poszczególnych podstronach (niezależnie od konfiguracji strony głównej), z których każda będzie oznaczona unikalnym adresem URL.	W
WF-190	Metatagi strony muszą być generowane automatycznie na podstawie treści danej podstrony lub poprzez definicję schematów metatagów.	W
WF-191	Zmienne wykorzystywane przez schemat metatagów muszą zostać oparte o elementy takie jak: 1. nazwa podstrony, 2. nazwa podstrony nadrzędnej, 3. lead, 4. data publikacji, 5. nazwa portalu, 6. element modułu.	W
WF-192	System musi umożliwiać przypisywanie schematów metatagów do szablonów stron (te z kolei muszą być przypisywane do elementów struktury menu).	W
WF-193	System musi wyświetlać metatagi według kolejności: 1. metatagi ze schematu metatagów przypisanych do szablonu podstron danej pozycji w menu, 2. metatagi z konfiguracji danej pozycji w menu 3. metatagi z treści strony 4. metatagi z konfiguracji ogólnej systemu	W
WF-194	Edytor treści
WF-195	System musi posiadać edytor treści WYSIWYG (ang. What You See Is What You Get).	W
WF-196	Edytor treści systemu musi pozwalać na łatwe i intuicyjne wprowadzanie treści przez redaktorów, bez konieczności znajomości zagadnień technicznych, np. atrybutów html’a.	W
WF-197	Edytor treści systemu musi posiadać możliwość trybu pracy w wersji html.	W
WF-198	Edytor treści systemu nie może mieć ograniczeń co do wprowadzanych atrybutów lub znaczników kodu html.	W
WF-199	Edytor WYSIWYG dostępny w portalu musi zawierać co najmniej następujące funkcjonalności: 1. pogrubianie tekstu, 2. kursywa tekstu, 3. podkreślanie tekstu, 4. justowanie tekstu, 5. przekreślenie tekstu, 6. cytowanie, 7. podlinkowywanie / odlinkowanie tekstu, 8. wypunktowania / numerowanie tekstu,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	9. umieszczanie plików do pobrania z repozytorium plików, 10. umieszczanie zdjęć z repozytorium plików, 11. umieszczanie filmów z repozytorium plików, 12. umieszczanie filmów ze źródeł zewnętrznych, 13. umieszczanie plików audio z repozytorium plików, 14. umieszczanie plików audio ze źródeł zewnętrznych, 15. przeklejanie tekstu z Worda z prawidłową konwersją w locie do formatowania docelowego edytora, 16. czyszczenie formatowania tekstu, 17. wstawianie zdefiniowanych stylów, 18. wstawanie zdefiniowanych nagłówków i paragrafów, 19. wstawanie znaków specjalnych, 20. wstawianie i edycja tabel (w tym wierszy i kolumn), 21. możliwość cofania i przywracania wykonanych akcji.
WF-200	Edytor treści system musi pozwalać na wstawianie linków zewnętrznych (wpisywanych ręcznie) oraz linków wewnętrznych, do istniejących stron w strukturze portalu (wybór menu i pozycji w menu).	W
WF-201	System musi posiadać poniższe funkcjonalności w przypadku wstawiania zdjęć: 1. możliwość wprowadzenia tekstu alternatywnego, 2. możliwość wprowadzenia etykiety, 3. określenie odnośnika po kliknięciu (opcje: brak, lightbox, możliwość wprowadzenia adresu URL), 4. określenie wyświetlanego rozmiaru, 5. możliwość dodania klasy CSS lub styli.	W
WF-202	System musi posiadać poniższe funkcjonalności w przypadku wstawiania tabel: 1. wstawianie tabeli, 2. ustalanie właściwości tabeli - szerokość, wysokość, odstęp między komórkami, margines w komórkach, obramowanie, etykieta, wyrównanie, wybór klasy CSS, obramowanie, kolor tła, 3. usuwanie tabeli, 4. właściwości komórki - szerokość, wysokość, styl CSS, obramowanie, kolor tła, 5. scalanie komórek tabeli, 6. podział komórek tabeli, 7. wstawianie wiersza poniżej /powyżej, 8. wstawianie kolumny przed / po, 9. usuwanie wiersza, 10. usuwanie kolumny, 11. wycięcie wiersza, 12. skopiowanie wiersza, 13. wklejanie wiersza przed / po, 14. właściwości wiersza – rodzaj (head, body, footer), wyrównanie, wysokość, styl CSS, obramowanie, kolor tła.	W
WF-203	Edytor treści system musi pozwalać na wstawianie treści wewnątrz edytora pochodzących z innych, dodanych już w systemie modułów.	W
WF-204	Umieszczanie w edytorze treści danych z innych modułów, musi obywać się poprzez tzw. [shortcodes]. Oznacza to, że z poziomu edytora system musi wstawić specjalny kod, który dopiero na froncie strony zostanie zamieniony na właściwą treść.	W
WF-205	Wstawianie [shortcodes] w treść edytora musi odbywać się automatycznie.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	Administrator musi najpierw określić modułu, z którego chce wstawić treść, a następnie z listy dostępnych stron o tym typie modułu, wybrać właściwy.
WF-206	System musi pozwalać na wstawianie treści z funkcjonalności: 1. galeria zdjęć, 2. galeria wideo, 3. lista plików, 4. lista stron, 5. bannery, 6. ankiety / formularze, 7. mapa interaktywna.	W
WF-207	Strona błędu 404
WF-208	System musi posiadać możliwość zarządzania stroną błędu 404.	W
WF-209	System musi pozwalać na zarządzanie treścią strony 404.	W
WF-210	System musi pozwalać na zarządzanie układem strony 404, analogicznie jak w przypadku układu podstron.	W
WF-211	Konfiguracja platformy multi portalowej
WF-212	System musi posiadać funkcjonalność konfiguracji systemu.	W
WF-213	Konfiguracja systemu musi być oddzielna dla każdego z systemów, w jego panelu administracyjnym.	W
WF-214	Konfiguracja systemu musi pozwalać na ustawienie parametrów serwisu, takich jak: nazwa strony, opis strony, logo strony.	W
WF-215	Konfiguracja strony musi pozwalać na włączenie lub wyłączenie wersji językowych strony na podstawie wersji uruchomionych w panelu globalnym systemu.	W
WF-216	Konfiguracja strony musi pozwalać na włączenie lub wyłączenie całej strony. W przypadku jej wyłączenia front serwisu jest wyłączony natomiast administrator może pracować w panelu administracyjnym strony.	W
WF-217	Konfiguracja musi pozwalać na zarządzanie treścią wyświetlaną na froncie systemu przy jego wyłączeniu (edytor WYSIWYG).	W
WF-218	Konfiguracja musi pozwalać na ustawienie parametrów powiadomień mailowych, parametrów poczty SMTP niezbędnych do wysyłki powiadomień z dostępnych w serwisie funkcjonalności.	W
WF-219	Konfiguracja musi pozwalać na zarządzanie informacjami dostępnymi w stopce strony. Są to między innymi dane opisowe, adres korespondencyjny, numery telefonów do sekretariatów itp. Elementy dostępne w stopce muszą zostać określone na etapie analizy przedwdrożeniowej.	W
WF-220	W przypadku braku konfiguracji stopki w panelu administracyjnym strony, system na froncie musi dziedziczyć te parametry z portalu głównego systemu multi portalowego.	W
WF-221	Konfiguracja musi pozwalać na zarządzanie informacjami o polityce cookie’s w serwisie.	W
WF-222	W przypadku braku konfiguracji polityki cookie’s w panelu administracyjnym strony, system na froncie musi dziedziczyć te parametry z portalu głównego systemu multi portalowego.	W
WF-223	Cache systemu
WF-224	System musi posiadać mechanizmy cache’owania portali, co pozwoli zwiększyć wydajność działania całego systemu, szybkość ładowania się poszczególnych stron oraz obciążenie serwera bazodanowego.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-225	System musi pozwolić na pracę danej witryny w trybie z włączonym oraz z wyłączonych cache’m.	W
WF-226	Mechanizmy cache’u muszą być włączane / wyłączane z poziomu panelu globalnego oraz paneli administracyjnych poszczególnych witryn.	W
WF-227	System musi posiadać mechanizmy czyszczenia cache danej witryny na żądanie, z poziomu jej panelu administracyjnego.	W
WF-228	System musi posiadać mechanizmy automatycznego czyszczenia cache dla konkretnych jego funkcjonalności w momencie dodania/edycji treści. Oznacza to, iż po zmianie treści konkretnej podstrony będzie ona natychmiast widoczna, bez konieczności ręcznego czyszczenia cache lub odczekania „pewnego” okresu czasu.	W
WF-229	Zadania cykliczne
WF-230	System musi pozwalać na wymianę danych pomiędzy nim a zewnętrznymi systemami, poprzez zadania cykliczne.	W
WF-231	Zadania cykliczne muszą być uruchamiane co zadany okres czasu lub o określonej godzinie (porze), przy czym elementy te muszą być konfigurowalne.	W
WF-232	Bloki systemu
WF-233	System musi pozwalać na definiowanie bloków.	W
WF-234	System musi pozwalać na tworzenie poniższych typów bloków: niezależnych (blok opisowy z edytorem WYSIWYG, możliwość wstawienia kodu html), powiązanych z funkcjonalnościami systemu (np. skrót aktualności, blok bannerów).	W
WF-235	System musi pozwalać na rozmieszczanie bloków w regionach dostępnych przy definicji układu strony głównej oraz podstron (drag & drop).	W
WF-236	System musi pozwalać na rozmieszczanie tego samego bloku w różnych regionach, różnych układów stron.	W
WF-237	Bloki systemu muszą posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-238	Bloki systemu muszą posiadać funkcjonalność kosza.	W
WF-239	Bloki systemu muszą podlegać procesowi wersjonowania wpisów.	W
WF-240	System musi pozwalać na definiowanie bloków.	W
WF-241	Elementy społecznościowe
WF-242	System musi pozwalać użytkownikom na współdzielenie treści serwisu w mediach społecznościowych.	W
WF-243	System musi pozwalać użytkownikom na „polubienia” wybranej treści.	W
WF-244	W określonych miejscach serwisów, system musi prezentować serwisy społecznościowe, w których Zamawiający ma swój profil.	W
WF-245	Lista serwisów społecznościowych do umieszczenia na portalu musi zostać określona na etapie analizy przedwdrożeniowej. Administrator systemu musi mieć możliwość zarządzania listą dostępnych serwisów społecznościowych.	W
WF-246	Wymagania funkcjonalne poszczególnych modułów
WF-247	Aktualności
WF-248	System musi posiadać moduł aktualności, służący do prezentacji treści takich jak news’y, wydarzenia oraz informacje.	W
WF-249	System musi pozwalać na kategoryzację aktualności.	W
WF-250	System musi pozwalać na zawężanie listy aktualności poprzez wybór interesującej użytkownika kategorii.	W
WF-251	Podstawowy widok modułu to stronicowana lista aktualności ze zdjęciem, tytułem, datą publikacji, kategorią i tekstem wiodącym aktualności.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-252	System musi pozwalać na podgląd szczegółów aktualności, poprzez wejście w daną aktualność z poziomu listy.	W
WF-253	Na pojedynczą aktualność muszą składać się przynajmniej pola: 1. tytuł aktualności, 2. symbol aktualności (używany w odnośniku), 3. kategorie wpisu, 4. lead aktualności (skrót aktualności), 5. treść aktualności (WYSIWYG), 6. data publikacji od, data publikacji do, 7. status publikacji, 8. zdjęcia, 9. pliki do pobrania, 10. pozycjonowanie, 11. dodaj aktualność do kalendarium.	W
WF-254	System musi pozwalać na przypisanie aktualności do kilku kategorii.	W
WF-255	System musi pozwalać na automatyczne przenoszenie opublikowanych aktualności do dostępnego dla internautów archiwum. Przenoszenie musi być dokonywane po zadanej dacie.	W
WF-256	System musi pozwalać na załączanie do aktualności plików i zdjęć. Musi się ono odbywać poprzez edytor WYSIWYG oraz poprzez osobne zakładki w aktualności. Dodane zdjęcia muszą stworzyć galerię zdjęć pod wpisem (pierwsze zdjęcie widoczne jest na liście wpisów), natomiast dodane pliku musza się znaleźć pod treścią aktualności jako pliki do pobrania.	W
WF-257	Galeria zdjęć powinna pozwalać na powiększanie zdjęć poprzez kliknięcie w miniaturę. Powiększone zdjęcia muszą być prezentowana na warstwie zaciemniającej treść strony pod dużym zdjęciem.	W
WF-258	System musi pozwalać na tworzenie informacji o dostępie czasowym. Publikacja aktualności od zadanej daty, wycofanie aktualności z portalu od zadanej daty.	W
WF-259	Moduł aktualności musi posiadać funkcjonalność podglądu nie opublikowanych wpisów.	W
WF-260	Moduł aktualności musi posiadać funkcjonalność indywidualnych ustawień SEO dla pojedynczego wpisu.	W
WF-261	Moduł aktualności musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-262	Moduł aktualności musi posiadać funkcjonalność kosza.	W
WF-263	Moduł aktualności musi podlegać procesowi wersjonowania wpisów.	W
WF-264	Moduł aktualności musi podlegać procesowi powiązywania wersji językowych wpisów.	W
WF-265	Moduł aktualności musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy aktualności, 2. dodawanie aktualności, 3. edycja aktualności, 4. przenoszenie aktualności do kosza, 5. przywracanie aktualności z kosza, 6. usuwanie aktualności, 7. publikacja, zatwierdzanie aktualności, 8. wersjonowanie aktualności,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	9. dostęp do kategorii, 10. dodawanie kategorii, 11. edycja kategorii, 12. usuwanie kategorii.
WF-266	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-267	Moduł musi posiadać blok, prezentujący skrót konkretnej podstrony z aktualnościami, który może być użyty w układzie strony.	W
WF-268	Blok modułu musi posiadać elementy konfiguracyjne takie jak: 1. ilość aktualności w bloku, 2. nazwa bloku, 3. pokaż / ukryj zdjęcie.	W
WF-269	Moduł musi umożliwiać użytkownikom subskrypcję kanału RSS aktualności.	W
WF-270	Moduł musi pozwalać na dodanie aktualności do kalendarium. Oznacza to, że po zaznaczeniu opcji „dodaj aktualność do kalendarium”, dana aktualność pokaże się zarówno w tym module aktualności oraz w module kalendarium oznaczonym jako kalendarium domyślne w systemie.	W
WF-271	Zaznaczeniu opcji „dodaj aktualność do kalendarium”, musi skutkować koniecznością wypełnienia dodatkowych pól: 1. data rozpoczęcie wydarzenia, 2. godzina rozpoczęcia wydarzenia, 3. data zakończenia wydarzenia, 4. godzina zakończenia wydarzenia, 5. miejsce wydarzenia, 6. mapa z naniesionym punktem miejsca wydarzenia.	W
WF-272	Kalendarium
WF-273	System musi posiadać moduł kalendarium, służący do prezentacji treści takich jak informacje o planowanych wydarzeniach.	W
WF-274	Kalendarium musi być redagowane przez uprawnionych użytkowników wewnętrznych i będzie widoczne dla wszystkich użytkowników portalu.	W
WF-275	System musi pozwalać na dodanie modułu kalendarium w dwóch wariantach: kalendarium zintegrowane z aktualnościami, kalendarium niezależne.	W
WF-276	Kalendarium niezależne to moduł kalendarium z wpisami pochodzącymi dokładnie z tego konkretnego kalendarium.	W
WF-277	Kalendarium zintegrowane z aktualnościami, to kalendarium oznaczone w danym portalu jako domyślne.	W
WF-278	Moduł kalendarium musi pozwalać na wyświetlanie kalendarium: 1. w formie listy, 2. w formie kalendarza.	W
WF-279	Widok kalendarium w formie listy wydarzeń to lista wydarzeń ze zdjęciem, tytułem, datą publikacji i lead’em wydarzeń.	W
WF-280	Widok kalendarium w formie kalendarza to widok kalendarza miesięcznego z możliwością przeskoczenia do następnych miesięcy lub powrotu do poprzednich.	W
WF-281	Kalendarz musi prezentować dni tygodnia w postaci kafelków, musi zaznaczać aktualny dzień, musi zawierać opisy dni tygodnia.	W
WF-282	W przypadku wystąpienia wydarzeń w danym dniu, kafelek kalendarza musi zostać	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	wyraźnie oznaczony, a informacje o wydarzeniach w tym dniu muszą być dostępne w formie skróconej po najechaniu myszką na ten dzień (tooltip).
WF-283	System musi pozwalać na podgląd szczegółów wydarzeń, poprzez wejście w dane wydarzenie z poziomu listy lub kalendarza.	W
WF-284	W ramach dostępu do szczegółów wpisu, system musi pozwolić na użytkownikom na zapis na dane wydarzenie.	W
WF-285	Zapis na dane wydarzenie musi nastąpić poprzez wypełnienie prostego formularza.	W
WF-286	System musi wysyłać powiadomienia do administratora wydarzenia o nowym zgłoszeniu.	W
WF-287	System musi pozwalać administratorowi na podgląd dodanych zapisów oraz na ich potwierdzanie.	W
WF-288	Potwierdzenie zapisu musi generować powiadomienie mailowe do osoby, która zapisała się na dane wydarzenie.	W
WF-289	Na pojedyncze wydarzenie w kalendarium muszą składać się przynajmniej pola: 1. tytuł wydarzenia, 2. symbol wydarzenia (używany w odnośniku), 3. lead wydarzenia (skrót wydarzenia), 4. treść wydarzenia (WYSIWYG), 5. data publikacji od, data publikacji do, 6. status publikacji, 7. zdjęcia, 8. pliki do pobrania, 9. pozycjonowanie, 10. data rozpoczęcie wydarzenia, 11. godzina rozpoczęcia wydarzenia, 12. data zakończenia wydarzenia, 13. godzina zakończenia wydarzenia, 14. miejsce wydarzenia, 15. mapa z naniesionym punktem miejsca wydarzenia, 16. administrator wydarzenia,	W
WF-290	System musi pozwalać na automatyczne przenoszenie opublikowanych wydarzeń do dostępnego dla internautów archiwum. Przenoszenie musi być dokonywane po zadanej dacie.	W
WF-291	System musi pozwalać na załączanie do wydarzeń plików i zdjęć. Musi się ono odbywać poprzez edytor WYSIWYG oraz poprzez osobne zakładki w wydarzeniu. Dodane zdjęcia muszą stworzyć galerię zdjęć pod wpisem (pierwsze zdjęcie widoczne jest na liście wpisów), natomiast dodane pliku musza się znaleźć pod treścią wydarzenia jako pliki do pobrania.	W
WF-292	Galeria zdjęć powinna pozwalać na powiększanie zdjęć poprzez kliknięcie w miniaturę. Powiększone zdjęcia muszą być prezentowana na warstwie zaciemniającej treść strony pod dużym zdjęciem.	W
WF-293	System musi pozwalać na tworzenie informacji o dostępie czasowym. Publikacja wydarzeń od zadanej daty, wycofanie wydarzeń z portalu od zadanej daty.	W
WF-294	Moduł kalendarium musi posiadać funkcjonalność podglądu nie opublikowanych wpisów.	W
WF-295	Moduł kalendarium musi posiadać funkcjonalność indywidualnych ustawień SEO dla pojedynczego wpisu.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-296	Moduł kalendarium musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-297	Moduł kalendarium musi posiadać funkcjonalność kosza.	W
WF-298	Moduł kalendarium musi podlegać procesowi wersjonowania wpisów.	W
WF-299	Moduł kalendarium musi podlegać procesowi powiązywania wersji językowych wpisów.	W
WF-300	Moduł kalendarium musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy wydarzeń, 2. dodawanie wydarzenia, 3. edycja wydarzenia, 4. przenoszenie wydarzenia do kosza, 5. przywracanie wydarzenia z kosza, 6. usuwanie wydarzenia, 7. publikacja, zatwierdzanie wydarzenia, 8. wersjonowanie wydarzenia.	W
WF-301	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-302	Moduł musi posiadać blok, prezentujący skrót konkretnej podstrony z wydarzeniami, który może być użyty w układzie strony.	W
WF-303	Blok modułu musi posiadać elementy konfiguracyjne takie jak: 1. ilość wydarzeń w bloku, 2. nazwa bloku.	W
WF-304	Moduł musi umożliwiać użytkownikom subskrypcję kanału RSS wydarzeń.	W
WF-305	Akapity
WF-306	System musi posiadać moduł akapity, służący do prezentacji treści opisowych.	W
WF-307	System musi pozwalać na podział treść całej podstrony na akapity, które następnie redaktor może sortować oraz decydować o ich publikacji.	W
WF-308	Na pojedynczy akapit muszą składać się przynajmniej pola: 1. tytuł akapitu, 2. treść akapitu (WYSIWYG), 3. data publikacji, 4. status publikacji, 5. zdjęcia, 6. pliki do pobrania.	W
WF-309	System musi pozwalać na załączanie do akapitów plików i zdjęć. Musi się ono odbywać poprzez edytor WYSIWYG oraz poprzez osobne zakładki w aktualnościach. Dodane zdjęcia muszą stworzyć galerię zdjęć pod wpisem, natomiast dodane pliku musza się znaleźć pod treścią akapitu jako pliki do pobrania.	W
WF-310	Galeria zdjęć powinna pozwalać na powiększanie zdjęć poprzez kliknięcie w miniaturę. Powiększone zdjęcia muszą być prezentowana na warstwie zaciemniającej treść strony pod dużym zdjęciem.	W
WF-311	Moduł akapitów musi posiadać funkcjonalność podglądu nie opublikowanych wpisów.	W
WF-312	Moduł akapitów musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-313	Moduł akapitów musi posiadać funkcjonalność kosza.	W
WF-314	Moduł akapitów musi podlegać procesowi wersjonowania wpisów.	W
WF-315	Moduł akapitów musi posiadać przynajmniej poniższe akcje, do których można	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	nadawać uprawnienia: 1. dostęp do listy akapitów, 2. dodawanie akapitów, 3. edycja akapitów, 4. przenoszenie akapitów do kosza, 5. przywracanie akapitów z kosza, 6. usuwanie akapitów, 7. publikacja, zatwierdzanie akapitów, 8. wersjonowanie akapitów, 9. sortowanie akapitów.
WF-316	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-317	System musi posiadać blok opisowy, który może być użyty w układzie strony.	W
WF-318	Blok opisowy musi posiadać elementy konfiguracyjne takie jak: nazwa bloku, treść bloku (WYSIWYG).	W
WF-319	Lista stron
WF-320	System musi posiadać moduł listy stron, służący do prezentacji w formie skrótu stron podpiętych pod tą pozycję w strukturze portalu.	W
WF-321	Moduł listy stron musi wyświetlać wszystkie podstrony ze zdefiniowanego w panelu administracyjnym menu, znajdującego się w obszarze wybranej aktualnie strony.	W
WF-322	Pojedyncze pozycje muszą być odnośnikami do tych podstron.	W
WF-323	Moduł musi prezentować listę podstron wraz z danymi opisowymi pochodzącymi ze struktury portalu: 1. nazwa strony, 2. zdjęcie strony	W
WF-324	System musi pozwalać na wyświetlanie nad listą, tekstu pochodzącego z aktualnego elementu struktury portalu.	W
WF-325	System musi pozwalać na osadzanie listy stron za pomocą [shortcodes] w edytorze WYSIWYG.	W
WF-326	Lista plików
WF-327	System musi posiadać moduł listy plików, służący do prezentacji materiałów i dokumentów do pobrania.	W
WF-328	Podstawowy widok modułu to rejestr listy plików. System musi pozwalać na definiowanie rejestru, który jest spisem dostępnych list plików. W ramach modułu można dodać wiele list plików	W
WF-329	Na pojedynczą listę plików składa się: 1. tytuł, 2. opis, 3. publikacja, 4. Powyższe dane, w formie rejestru muszą być prezentowane w podstawowym widoku modułu. 5. dokumenty. 6. Dokumenty dostępne są po wejściu w szczegóły konkretnej listy plików.	W
WF-330	Nazwa listy plików na rejestrze musi być odnośnikiem do udostępnianych w ramach tej listy plików.	W
WF-331	Na pojedynczy dokument w ramach listy plików muszą składać się przynajmniej pola:	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	1. tytuł dokumentu, 2. etykieta dokumenty, 3. opis dokumentu 4. plik, 5. publikacja, 6. pozycja pliku na liście, 7. słowa kluczowe.
WF-332	Każdy dokument do pobrania musi prezentować przynajmniej poniższe informacje użytkownikom: 1. nazwa pliku, 2. wielkość pliku, 3. format pliku.	W
WF-333	W przypadku kiedy rejestr zawiera wyłącznie jedną listę plików z dokumentami, system musi prezentować od razu dokumenty tej pojedynczej listy.	W
WF-334	Definiowane przy dokumentach słowa kluczowe, muszą być wykorzystane w module wyszukiwarki.	W
WF-335	Moduł listy plików musi posiadać obsługę procesu zatwierdzania i publikacji samej listy oraz pojedynczych dokumentów w ramach tej listy.	W
WF-336	Moduł listy plików musi posiadać funkcjonalność kosza zarówno dla list plików jak i samych dokumentów wewnątrz list.	W
WF-337	Moduł listy plików musi podlegać procesowi wersjonowania wpisów zarówno dla list plików jak i samych dokumentów wewnątrz list.	W
WF-338	Moduł listy plików musi posiadać możliwość sortowania list plików w obrębie rejestru oraz samych dokumentów w konkretnej liście plików.	W
WF-339	Wszystkie udostępniane w ramach listy plików dokumenty musza pochodzić z repozytorium plików w systemie.	W
WF-340	Moduł listy plików musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do rejestru list plików, 2. dodawanie listy plików, 3. edycja listy plików, 4. przenoszenie listy plików do kosza, 5. przywracanie listy plików z kosza, 6. usuwanie listy plików, 7. publikacja, zatwierdzanie listy plików, 8. wersjonowanie listy plików, 9. dostęp do dokumentów, 10. dodawanie dokumentów, 11. edycja dokumentów, 12. przenoszenie dokumentów do kosza, 13. przywracanie dokumentów z kosza, 14. usuwanie dokumentów, 15. publikacja, zatwierdzanie dokumentów, 16. wersjonowanie dokumentów.	W
WF-341	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-342	Niezależnie od istnienia modułu listy plików system musi pozwalać administratorom na udostępnianie plików w formie linków znajdujących się w tekście (edytor	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	WYSIWYG).
WF-343	Linki
WF-344	System musi posiadać moduł linków, służący do prezentacji użytkownikom listy odnośników.	W
WF-345	System musi pozwalać na dodawanie w ramach podstrony linków, które redaktor może sortować oraz decydować o ich publikacji.	W
WF-346	System musi pozwolić na dodanie miniatury do linku.	W
WF-347	System w obrębie strony musi prezentować dodane odnośniki w postaci kafelków z miniaturami zdjęć.	W
WF-348	Na pojedynczy link muszą składać się przynajmniej pola: 1. nazwa odnośnika, 2. adres URL, 3. tekst wyświetlany po najechaniu, 4. otwórz w nowym oknie, 5. status publikacji, 6. zdjęcie.	W
WF-349	Moduł linków musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-350	Moduł linków musi posiadać funkcjonalność kosza.	W
WF-351	Moduł linków musi podlegać procesowi wersjonowania wpisów.	W
WF-352	Moduł linków musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy linków, 2. dodawanie linków, 3. edycja linków, 4. przenoszenie linków do kosza, 5. przywracanie linków z kosza, 6. usuwanie linków, 7. publikacja, zatwierdzanie linków, 8. wersjonowanie linków, 9. sortowanie linków.	W
WF-353	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-354	Moduł musi posiadać blok, prezentujący skrót konkretnej podstrony z linkami, który może być użyty w układzie strony.	W
WF-355	Blok linków musi posiadać elementy konfiguracyjne takie jak: nazwa bloku, dodatkowy opis nad odnośnikami (WYSIWYG).	W
WF-356	System musi pozwalać na osadzanie linków za pomocą [shortcodes] w edytorze WYSIWYG.	W
WF-357	Galeria zdjęć
WF-358	System musi posiadać moduł galerii zdjęć służący do prezentacji fotografii.	W
WF-359	Moduł galerii zdjęć musi pozwalać na grupowanie zdjęć w obrębie tematycznych galerii (wiele galerii w obrębie jednego modułu).	W
WF-360	Podstawowy widok modułu to lista dostępnych galerii, w postaci kafelków z miniaturami zdjęć oraz nazwą galerii.	W
WF-361	System musi pozwalać na dostęp do wszystkich zdjęć danej galerii, poprzez wejście w	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	daną galerię z odnośnika na kafelku.
WF-362	Na pojedynczą galerię muszą składać się przynajmniej pola: 1. nazwa galerii, 2. symbol galerii (używany w odnośniku), 3. opis galerii (WYSIWYG), 4. data publikacji od, data publikacji do, 5. status publikacji, 6. zdjęcia, 7. pozycjonowanie.	W
WF-363	W ramach konkretnej galerii zdjęć system musi prezentować miniatury wszystkich jej fotografii.	W
WF-364	Bezpośrednio pod miniaturami system musi prezentować listę pozostałych galerii dostępnych w tym module.	W
WF-365	Galeria powinna pozwalać na powiększanie zdjęć poprzez kliknięcie w miniaturę. Powiększone zdjęcia muszą być prezentowana na warstwie zaciemniającej treść strony pod dużym zdjęciem.	W
WF-366	System musi pozwalać na poruszanie się pomiędzy powiększonymi zdjęciami galerii za pomocą przycisków następny, poprzedni wyświetlanych pod powiększonym zdjęciem.	W
WF-367	System musi pozwalać na załączanie do galerii zdjęć. Musi się ono odbywać poprzez osobną zakładkę formularza. Dodane zdjęcia muszą stworzyć galerię (pierwsze zdjęcie widoczne jest na kafelku).	W
WF-368	System musi pozwalać na tworzenie informacji o dostępie czasowym. Publikacja galerii od zadanej daty, wycofanie galerii z portalu od zadanej daty.	W
WF-369	Moduł galerii zdjęć musi posiadać funkcjonalność podglądu nie opublikowanych wpisów.	W
WF-370	Moduł galerii zdjęć musi posiadać funkcjonalność indywidualnych ustawień SEO dla pojedynczego wpisu.	W
WF-371	Moduł galerii zdjęć musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-372	Moduł galerii zdjęć musi posiadać funkcjonalność kosza.	W
WF-373	Moduł galerii zdjęć musi podlegać procesowi wersjonowania wpisów.	W
WF-374	Moduł galerii zdjęć musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy galerii, 2. dodawanie galerii, 3. edycja galerii, 4. przenoszenie galerii do kosza, 5. przywracanie galerii z kosza, 6. usuwanie galerii, 7. publikacja, zatwierdzanie galerii, 8. wersjonowanie galerii.	W
WF-375	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-376	W przypadku kiedy galeria zdjęć zawiera wyłącznie jedną galerię z fotografiami, system musi prezentować od razu zdjęcia tej pojedynczej galerii.	W
WF-377	System musi pozwalać na osadzanie galerii zdjęć za pomocą [shortcodes] w edytorze WYSIWYG.	W
WF-378	Galeria video

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-379	System musi posiadać moduł galerii video służący do prezentacji materiałów video.	W
WF-380	Moduł galerii video musi pozwalać na osadzanie materiałów video ze źródeł zewnętrznych oraz z plików video znajdujących się w repozytorium plików.	W
WF-381	System musi posiadać konfigurację, określającą dostępne w systemie pliki video.	W
WF-382	Podstawowy widok modułu to filmy prezentowane w obrębie danego modułu w postaci kafelków z miniaturami, nazwą oraz opisem filmu.	W
WF-383	Na pojedynczy film w module galerii video muszą składać się przynajmniej pola: 1. nazwa filmu, 2. opis filmu, 3. typ filmu, 4. plik, 5. status publikacji.	W
WF-384	System musi pozwolić na wybór typu zamieszczanego filmu: link – należy podać odnośnik do źródła (np. video, YouTube), plik video – należy wybrać plik z repozytorium plików.	W
WF-385	Moduł galerii video musi posiadać funkcjonalność podglądu nie opublikowanych wpisów.	W
WF-386	Moduł galerii video musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-387	Moduł galerii video musi posiadać funkcjonalność kosza.	W
WF-388	Moduł galerii video musi podlegać procesowi wersjonowania wpisów.	W
WF-389	Moduł galerii video musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy plików video, 2. dodawanie video, 3. edycja video, 4. przenoszenie video do kosza, 5. przywracanie video z kosza, 6. usuwanie video, 7. publikacja, zatwierdzanie video, 8. wersjonowanie video.	W
WF-390	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-391	System musi pozwalać na osadzanie galerii zdjęć za pomocą [shortcodes] w edytorze WYSIWYG.	W
WF-392	Niezależnie od istnienia modułu galerii video system musi pozwalać administratorom na udostępnianie plików video w formie możliwych do odtworzenia filmów w tekście (edytor WYSIWYG).	W
WF-393	Formularz kontaktowy
WF-394	System musi posiadać moduł formularza kontaktowego. Moduł ten może być użyty wielokrotnie w obrębie każdego z portali i dowolnie skonfigurowany.	W
WF-395	Moduł musi pozwalać przynajmniej na: 1. zbieranie wiadomości od użytkowników, 2. wysyłkę powiadomień, 3. prezentacje treści opisowych, 4. wyświetlanie punktu na mapie Google.	W
WF-396	System musi pozwolić każdemu użytkownikowi systemu na wysyłkę powiadomienia / zapytania za pomocą dostępnego na froncie formularza.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-397	Wypełniony formularz musi zostać zapisany w bazie danych, co pozwoli na jego sprawną obsługę.	W
WF-398	System musi prezentować zapisane w bazie danych formularze, z możliwości podglądu szczegółów i usunięcia wpisu.	W
WF-399	System musi pozwolić na export wpisów w bazie danych do pliku.	W
WF-400	System musi pozwolić na konfigurację wielu administratorów danego formularza kontaktowego.	W
WF-401	System musi generować powiadomienie do administratora systemu o wypełnieniu formularza.	W
WF-402	System musi pozwolić na konfiguracje potwierdzeń mailowych do użytkowników, którzy wypełnili formularz o jego prawidłowym dostarczeniu.	W
WF-403	System musi pozwolić na konfigurację komunikatów widocznych po wypełnieniu formularza kontaktowego.	W
WF-404	System musi pozwolić na zamieszczenie dodatkowych treści nad i pod formularzem kontaktowym (edytor WYSIWYG).	W
WF-405	System musi pozwolić na pokazanie na mapie Google punktu z lokalizacją jednostki / wydziału, którego dotyczy formularz.	W
WF-406	System musi umożliwić konfigurację dostępnych pól formularza kontaktowego, za pomocą mechanizmów drag & drop.	W
WF-407	Startowa konfiguracja pól dostępnych na formularzu to: 1. adres email, 2. treść, 3. pole captcha. 4. Pól tych nie można wyłączyć.	W
WF-408	System musi pozwolić na włączenie dodatkowych pól z listy dostępnych: 1. pola tekstowe, 2. pola wielokrotnego wyboru checkbox, 3. pola jednokrotnego wyboru select, 4. pola typu załącznik.	W
WF-409	Wszystkie dostępne w konfiguracji pola muszą być włączane w formularzu za pomocą mechanizmów drag & drop. Każde z pól ma możliwość określenia dowolnej nazwy oraz włączenia / wyłączenia wymagalności pola.	W
WF-410	Moduł formularza kontaktowego musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy wpisów, 2. usuwanie wpisów, 3. podgląd szczegółów wpisów, 4. eksport wpisów do pliku, 5. konfiguracja modułu.	W
WF-411	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-412	Newsletter
WF-413	System musi posiadać moduł newsletteru do generowania powiadomień mailowych do zainteresowanych użytkowników portalu.	W
WF-414	System musi pozwalać na wysyłkę powiadomień do zarejestrowanych subskrybentów oraz użytkowników portalu.	W
WF-415	System musi pozwalać na wysyłkę powiadomień do konkretnej kategorii	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	subskrybentów.
WF-416	System musi pozwalać na wysyłkę powiadomień do konkretnej grupy użytkowników (np. grupy użytkowników z AD).	W
WF-417	System musi pozwalać na konfigurację formularza zapisu na newsletter.	W
WF-418	System musi pozwalać na konfigurację formularza poprzez wybór dostępnych pól z listy pól predefiniowanych.	W
WF-419	Konfiguracja dostępnych pól formularza musi odbywać się za pomocą mechanizmów drag & drop.	W
WF-420	System musi pozwalać na zmianę standardowych nazw pól oraz określenie ich wymagalności.	W
WF-421	Minimalna konfiguracja formularza pozwalająca na zapis do newsletteru to pole email.	W
WF-422	System musi pozwalać na definiowania kategorii subskrypcji i udostępnianie ich na froncie portalu w celu zapisu się do nich użytkowników.	W
WF-423	Użytkownicy muszą mieć możliwość zapisania się do wielu grup jednocześnie.	W
WF-424	Użytkownicy portalu w każdej chwili musza mieć możliwość wypisania się z dowolnej kategorii newsletteru lub z całego newsletteru.	W
WF-425	System musi pozwalać administratorom na definiowanie prywatnych kategorii subskrypcji.	W
WF-426	Prywatne kategorie subskrypcji muszą być dostępne wyłącznie administratorom systemu i służyć do wewnętrznego podziału subskrybentów.	W
WF-427	Administratorzy systemu muszą mieć możliwość importu subskrybentów do systemu z zewnętrznych źródeł (np. plik tekstowy).	W
WF-428	Warunkiem koniecznym do importu danych musi być kolumna email w pliku, bez tej kolumny import jest niemożliwy.	W
WF-429	Import subskrybentów do systemu musi pozwalać na przypisywanie kolumn w pliku ich odpowiednikom w bazie danych.	W
WF-430	System musi pozwalać na eksport subskrybentów z bazy do pliku tekstowego.	W
WF-431	System musi pozwolić na definiowanie wielu nadawców subskrypcji.	W
WF-432	Nadawca subskrypcji to skonfigurowane konto pocztowe SMTP, za pomocą który zrealizowana zostanie konkretna wysyłka powiadomień.	W
WF-433	System musi pozwalać na definiowanie szablonów, które następnie będą mogły być wykorzystywane przy budowaniu wiadomości do wysyłki.	W
WF-434	Na pojedynczy szablon musza składać się przynajmniej pola: 1. nazwa szablonu, 2. treść szablonu (edytor WYSIWYG), 3. [shortcodes] w postaci predefiniowanych zmiennych szablonu.	W
WF-435	Lista dostępnych w szablonie wiadomości [shortcodes] to przynajmniej: 1. data wysłania, 2. pole email, 3. pole imię, 4. pole nazwisko, 5. link rezygnacji z newsletteru, 6. link edycji danych subskrybenta, 7. nagłówki aktualności 8. nagłówki stron.	W
WF-436	[shortcodes] w szablonach wiadomości musza być zamieniane na właściwe dane w	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	momencie wysyłki powiadomień.
WF-437	[shorcodes] mogę być umieszczone w dowolnym miejscu treści edytora WYSIWYG.	W
WF-438	Nagłówki aktualności w [shortcodes] to skrócona lista aktualności z konkretnego modułu z odnośnikami do szczegółów tych widomości.	W
WF-439	Nagłówki stron w [shortcodes] to linki do konkretnych stron.	W
WF-440	System musi pozwalać na definiowanie wiadomości, które mogą być tworzone manualnie lub wykorzystywać gotowy, wcześniej zdefiniowany szablon.	W
WF-441	Na pojedynczą wiadomość muszą składać się przynajmniej pola: 1. nazwa wiadomości, 2. typ wiadomości, 3. załącz nagłówki, 4. status publikacji.	W
WF-442	Typ wiadomości to wybór wiadomości ze zdefiniowanego szablonu lub ręczne tworzenie wiadomości. W przypadku ręcznego tworzenia wiadomości procedura musi być identyczna jak przy definiowaniu szablonów.	W
WF-443	Opcja załącz nagłówki musi pozwalać na definicję tych nagłówków: wybór modułu aktualności, wybór stron.	W
WF-444	Definiowanie wiadomości musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-445	Definiowanie wiadomości musi posiadać funkcjonalność kosza.	W
WF-446	Definiowanie wiadomości musi podlegać procesowi wersjonowania wpisów.	W
WF-447	System musi pozwalać na definiowanie wysyłek powiadomień.	W
WF-448	Wysyłka powiadomień musi odbywać się poprzez zadania cykliczne.	W
WF-449	Wysyłka wiadomości musi być podzielona na paczki. Niedopuszczalna jest wysyłka np. 20 tys. powiadomień naraz, w pętli.	W
WF-450	Na pojedynczą wysyłkę wiadomości musza składać się przynajmniej: 1. nazwa wysyłki, 2. wybór wiadomości do wysłania, 3. odbiorcy wiadomości, 4. typ wysyłki, 5. nadawca wysyłki.	W
WF-451	Podczas generowania wysyłki system musi posiadać opcje podglądu wiadomości.	W
WF-452	Wiadomości muszą posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-453	Wiadomości muszą posiadać funkcjonalność kosza.	W
WF-454	Wiadomości muszą podlegać procesowi wersjonowania wpisów.	W
WF-455	System musi pozwalać na określenie odbiorców wiadomości przynajmniej dla: 1. administratorów systemu, 2. grupy użytkowników z AD, 3. subskrybentów, 4. subskrybentów z konkretnej kategorii (możliwość wyboru wielu kategorii).	W
WF-456	System musi na bieżąco informować o stanie wysyłki (zaplanowana, w realizacji, zrealizowana).	W
WF-457	System musi generować statystyki wysłanych wiadomości: 1. ilość odbiorców w wysyłce, 2. ilość wysłanych wiadomości, 3. ilość odebranych wiadomości,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	4. ilość kliknięć w linki zamieszczone w wiadomości.
WF-458	Newsletter musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do nadawców wiadomości, 2. dodaj nadawcę, 3. edytuj nadawcę, 4. usuń nadawcę, 5. dostęp do kategorii subskrypcji, 6. dodaj kategorię subskrypcji, 7. edytuj kategorię subskrypcji, 8. usuń kategorię subskrypcji, 9. dostęp do szablonów wiadomości, 10. dodaj szablon, 11. edytuj szablon, 12. usuń szablon, 13. dostęp do listy wysyłek, 14. dodaj wysyłkę, 15. podgląd wysyłki, 16. usuń wysyłkę, 17. dostęp do listy wiadomości, 18. dodawanie wiadomości, 19. edycja wiadomości, 20. przenoszenie wiadomości do kosza, 21. przywracanie wiadomości z kosza, 22. usuwanie wiadomości, 23. publikacja, zatwierdzanie wiadomości, 24. wersjonowanie wiadomości.	W
WF-459	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-460	Newsletter musi posiadać blok zapisu na subskrypcję, który może być użyty w układzie strony.	W
WF-461	Mapa serwisu
WF-462	System musi posiadać moduł mapy portalu.	W
WF-463	Mapa portalu musi pozwalać na zapoznanie się ze wszystkimi podstronami jakie znajdują się w poszczególnych portalach multi portalu.	W
WF-464	Mapa portalu musi prezentować wszystkie podstrony witryny wraz z zachowaniem hierarchicznej struktury informacji w portalu.	W
WF-465	Mapa portalu powinna być dostępna dla wszystkich wersji językowych portalu.	W
WF-466	Mapa portalu musi mieć formę listy hierarchicznych linków, a użytkownik po kliknięciu w wybrany link powinien zostać przeniesiony na odpowiednią podstronę.	W
WF-467	Mapa portalu musi tworzyć się automatycznie na podstawie zdefiniowanych bloków menu i struktury stron ustalonej przez administratora w tych menu.	W
WF-468	Mapa portalu musi zachowywać hierarchię struktury stron, np. poprzez wcięcia lub wyróżnienie stron nadrzędnych.	W
WF-469	Konfiguracja modułu musi pozwalać na określenie bloków menu, z których ma być prezentowana struktura portalu.	W
WF-470	Konfiguracja modułu musi pozwalać na zamieszczenie dodatkowego opisu (edytor	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	WYSIWYG) nad hierarchią stron.
WF-471	Mapa interaktywna
WF-472	System musi posiadać moduł mapy interaktywnej, który ułatwi użytkownikom znalezienie budynków oraz innych obiektów znajdujących się na terenie Zamawiającego.	W
WF-473	Moduł mapy interaktywnej musi posiadać możliwość prezentacji wielu punktów na mapie wraz z informacją o nich.	W
WF-474	Moduł mapy interaktywnej musi posiadać możliwość naniesienia trasy przejścia z punktu A do punktu B.	W
WF-475	System musi pozwalać na definiowanie wielu map wraz z wieloma punktami w obrębie portalu.	W
WF-476	System musi pozwolić na stworzenie mapy, a następnie przypisanie do niej punktów.	W
WF-477	Stworzenie mapy musi polegać przynajmniej na podaniu: 1. nazwy mapy, 2. środka mapy, poprzez wycentrowanie jej widoku oraz ustawienie przybliżenia, 3. status publikacji, 4. trasy na mapie.	W
WF-478	Dodanie trasy na mapie musi polegać na podaniu punktu początkowego A oraz punktu końcowego B. System musi sam wyznaczyć trasę między punktami.	W
WF-479	System musi pozwolić na ręczną zmianę wygenerowanej trasy, poprzez jej przesuwanie na mapie.	W
WF-480	Mapy muszą posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-481	Mapy muszą posiadać funkcjonalność kosza.	W
WF-482	Mapy muszą podlegać procesowi wersjonowania wpisów.	W
WF-483	System musi pozwalać na definiowanie punktów w ramach dodanej uprzednio mapie.	W
WF-484	Na pojedynczy punkt muszą składać się przynajmniej pola: 1. nazwa punktu, 2. symbol punktu (używany w odnośniku), 3. pokaż / ukryj szczegóły, 4. opis punktu, 5. treść punktu (WYSIWYG), 6. określenie położenia punktu na mapie, 7. kolor punktu, 8. status publikacji, 9. zdjęcia, 10. pliki do pobrania.	W
WF-485	System musi pozwalać na załączanie do punktu plików i zdjęć. Musi się ono odbywać poprzez edytor WYSIWYG oraz poprzez osobne zakładki przy punkcie. Dodane zdjęcia muszą stworzyć galerię zdjęć pod opisem w szczegółach punktu (pierwsze zdjęcie widoczne jest na liście wpisów), natomiast dodane pliku musza się znaleźć pod opisem w szczegółach punktu jako pliki do pobrania.	W
WF-486	W ramach wyświetlania punktów na mapie system musi pozwalać na prezentację opisu punktu, po kliknięciu w niego.	W
WF-487	System musi pozwalać na konfigurację punktów w taki sposób, by po kliknięciu w punkt można było zobaczyć jego szczegóły pod osobnym odnośnikiem (treść, położenie, zdjęcie, pliki).	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-488	Punkty muszą posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-489	Punkty muszą posiadać funkcjonalność kosza.	W
WF-490	Punkty muszą podlegać procesowi wersjonowania wpisów.	W
WF-491	Moduł mapy interaktywnej musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy map, 2. dodawanie map, 3. edycja map, 4. przenoszenie map do kosza, 5. przywracanie map z kosza, 6. usuwanie map, 7. publikacja, zatwierdzanie map, 8. wersjonowanie map, 9. dostęp do punktów w danej mapie, 10. dodawanie punktów, 11. edycja punktów, 12. przenoszenie punktów do kosza, 13. przywracanie punktów z kosza, 14. usuwanie punktów, 15. publikacja, zatwierdzanie punktów, 16. wersjonowanie punktów.	W
WF-492	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-493	System musi pozwalać na osadzanie map za pomocą [shortcodes] w edytorze WYSIWYG.	W
WF-494	Wyszukiwarka treści
WF-495	System musi posiadać moduł wyszukiwania treści.	W
WF-496	Wyszukiwarka musi pozwalać użytkownikom na przeszukanie treści całego portalu dla zadanej frazy.	W
WF-497	Wyszukiwarka musi przeszukiwać treści wszystkich podstron oraz modułów.	W
WF-498	Wyszukiwarka musi przeszukiwać zawartość plików udostępnionych w treściach podstron portalu.	W
WF-499	Wyszukiwarka musi pozwolić na przeszukiwanie dokumentów w formatach doc, docx, pdf, rtf, txt, odt, xls, xlsx, ppt, odp.	W
WF-500	Wyniki wyszukiwania musza zostać przedstawione w postaci listy wyników z odnośnikami do podstron lub plików według trafności wyników wyszukiwania.	W
WF-501	Prezentacja wyników wyszukiwania musi być podzielona na dwie sekcje: treści portalu, dokumenty.	W
WF-502	Domyślnie, w pierwszej kolejności wyszukiwarka powinna zwrócić wyniki dla treści portalu.	W
WF-503	Wyszukiwarka musi posiadać opcje zaawansowane, pozwalające na przeszukanie bazy danych pod kontem czasu publikacji wpisów: 1. w ciągu ostatnich 24 godzin, 2. w ciągu ostatniego tygodnia, 3. w ciągu ostatniego miesiąca.	W
WF-504	System musi rejestrować wyszukiwane przez użytkowników frazy i zapisywać ilość ich	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	wystąpień.
WF-505	System musi rejestrować datę i godzinę poszukiwanej frazy oraz IP użytkownika, który dokonał wyszukiwania.	W
WF-506	Rejestr wpisywanych fraz musi być dostępny w postaci stronicowanej listy wpisów, z możliwością filtrowania i wyszukiwania.	W
WF-507	Konfiguracja wyszukiwarki musi pozwolić na ustawienie minimalnej liczby znaków, dla których system uruchomi proces wyszukiwania.	W
WF-508	Moduł wyszukiwarki musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy wyszukiwanych fraz, 2. dostęp do konfiguracji modułu.	W
WF-509	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-510	Wyszukiwarka treści musi posiadać blok wyszukiwania, który może być użyty w układzie strony.	W
WF-511	Struktura organizacji
WF-512	System musi posiadać moduł struktury organizacji.	W
WF-513	Moduł musi prezentować strukturę organizacji oraz wszystkich jednostek funkcjonujących w ramach organizacji Zamawiającego.	W
WF-514	Moduł musi pozwalać na prezentacje struktury w trzech wariantach: 1. schemat organizacyjny (struktura hierarchiczna), 2. wyszukiwarka (po frazie), 3. wyszukiwarka A-Z.	W
WF-515	Schemat organizacyjny struktury organizacji musi prezentować hierarchiczną strukturę jednostek (z zachowaniem podległości) w postaci drzewa z rozwijanymi węzłami.	W
WF-516	Wyszukiwarka struktury organizacji to widok z możliwością wpisania szukanego wyrażenia. Po wciśnięciu szukaj, system musi wyświetlić wyniki w postaci listy znalezionych jednostek. Po wejściu w ten tryb, system nie zwraca nic, dopiero po wpisaniu frazy pokazują się wyniki, o ile zostały znalezione dopasowania.	W
WF-517	Wyszukiwarka A-Z struktury organizacji to wyszukiwarka jednostek poprzez wybór pierwszej litery nazwy jednostki i znalezienie danej jednostki na zawężonej liście jednostek. Po wejściu na ten tryb system musi pokazać nawigację w postaci pierwszych liter alfabetu (standardowo zaznaczamy literę „A”) oraz wyniki zwrócone dla wybranej litery.	W
WF-518	System musi pozwalać na zapoznanie się ze szczegółowymi informacjami na temat każdej z jednostek organizacyjnych funkcjonujących w ramach struktury Zamawiającego.	W
WF-519	Każda z jednostek organizacyjnych znajdujących się w strukturze organizacji może (ale nie musi) posiadać podstronę ze szczegółowymi informacjami.	W
WF-520	Na pojedynczą jednostkę muszą składać się przynajmniej pola: 1. nazwa jednostki, 2. symbol jednostki, 3. opis skrócony jednostki, 4. mapa z lokalizacją jednostki, 5. rodzaj jednostki (administracja, wydziały), 6. jednostka nadrzędna (miejsce w strukturze),	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	7. kod jednostki, 8. dane teleadresowe (WYSIWYG), 9. opis jednostki (WYSIWYG), 10. status publikacji, 11. zdjęcia, 12. pliki do pobrania, 13. słowa kluczowe.
WF-521	System musi pozwalać administratorom na zarządzanie strukturą portalu w dwóch trybach: 1. poprzez widok hierarchiczny, 2. stronicowana lista jednostek, z możliwością sortowania i filtrowania.	W
WF-522	System musi zostać zintegrowany z systemem kadrowym Zleceniodawcy. Struktura organizacyjna musi być importowana i aktualizowana w zadaniach cyklicznych z systemem dziedzinowym. Unikalnym identyfikatorem jednostki musi być jej kod, który pozwoli na taką integrację.	W
WF-523	System musi importować z systemu dziedzinowego podstawowe dane użytkowników wewnętrznych (identyfikator, imię, nazwisko, xxxx kontaktowe – e-mail, telefon)	W
WF-524	Platforma e-usług musi umożliwiać w swojej funkcjonalności definiowanie dodatkowych danych dla użytkowników wewnętrznych.	W
WF-525	Zarządzanie strukturą organizacji musi być dostępne z poziomu panelu administracyjnego portalu głównego i stąd dziedziczone na resztę portali.	W
WF-526	System musi pozwalać na załączanie do jednostki plików. Musi się ono odbywać poprzez edytor WYSIWYG oraz poprzez osobną zakładkę w konkretnej jednostce. Dodane pliku musza się znaleźć pod opisem jednostki w jej szczegółach jako pliki do pobrania.	W
WF-527	Moduł musi pozwalać na sortowanie jednostek w tej samej gałęzi.	W
WF-528	Definiowane przy jednostkach słowa kluczowe, muszą być wykorzystane w module wyszukiwarki.	W
WF-529	Moduł zarządzania strukturą musi posiadać funkcjonalność podglądu nie opublikowanych wpisów.	W
WF-530	Moduł zarządzania strukturą musi posiadać funkcjonalność indywidualnych ustawień SEO dla pojedynczego wpisu.	W
WF-531	Moduł zarządzania strukturą musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-532	Moduł zarządzania strukturą musi posiadać funkcjonalność kosza.	W
WF-533	Moduł zarządzania strukturą musi podlegać procesowi wersjonowania wpisów.	W
WF-534	Moduł zarządzania strukturą musi podlegać procesowi powiązywania wersji językowych wpisów.	W
WF-535	Moduł struktury organizacyjnej musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do struktury portalu, 2. dodawanie jednostki, 3. edycja jednostki, 4. przenoszenie jednostki do kosza, 5. przywracanie jednostki z kosza, 6. usuwanie jednostki, 7. publikacja, zatwierdzanie jednostki,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	8. wersjonowanie jednostki.
WF-536	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-537	System w ramach panelu administracyjnego musi pozwolić na podgląd użytkowników systemu przypisanych do danej jednostki organizacyjnej.	W
WF-538	Slider
WF-539	System musi posiadać moduł slider.	W
WF-540	Slider musi pozwolić na wyróżnienie treści w postaci opisu i zdjęcia w formie rotujących się slajdów.	W
WF-541	Pojedyncze slajdy muszą być zmieniane według zdefiniowanego w konfiguracji systemu czasu. Dodatkowo użytkownik będzie mógł samodzielnie przełączyć widok pomiędzy kolejnymi slajdami.	W
WF-542	System musi pozwalać na definicje wielu slajdów i grupowanie ich wewnątrz bloków.	W
WF-543	Bloki mogą być użyty w układzie strony i prezentowane użytkownikom na froncie strony.	W
WF-544	Zgrupowane wewnątrz bloków slajdy musza wyświetlać się w postaci rotowanych treści.	W
WF-545	Pojedynczy slajd może należeć wyłącznie do jednego bloku.	W
WF-546	Na pojedynczy slider muszą składać się przynajmniej pola: 1. nawa slider’a, 2. wyświetlany tytuł slaider’a, 3. kolor czcionki tytułu, 4. etykieta, 5. opis, 6. kolor czcionki opisu, 7. status publikacji, 8. zdjęcie, 9. odnośnik, 10. przypisanie do bloku.	W
WF-547	Moduł slider musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-548	Moduł slider musi posiadać funkcjonalność kosza.	W
WF-549	Moduł slider musi podlegać procesowi wersjonowania wpisów.	W
WF-550	Zamieszczane w slider’ze zdjęcia xxxxx pochodzić z repozytorium plików.	W
WF-551	Moduł slider musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy slajdów, 2. dodawanie slaider’a, 3. edycja slaider’a, 4. przenoszenie slaider’a do kosza, 5. przywracanie slaider’a z kosza, 6. usuwanie slaider’a, 7. publikacja, zatwierdzanie slaider’a, 8. wersjonowanie slaider’a.	W
WF-552	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-553	Banery

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-554	System musi posiadać moduł banerowy.	W
WF-555	Moduł banerów ma służyć graficznej oraz tekstowej prezentacji treści użytkownikom.	W
WF-556	Banery wyświetlane na portalu muszą mieć formę statyczną (np. pliki jpg, jpeg, png, treść) lub dynamiczną (pliki gif, swf).	W
WF-557	Banery mogą wyświetlać się w określonych stałych miejscach na stronie wkomponowanych w layout lub w formie pop-up.	W
WF-558	System musi pozwalać na definicje wielu banerów i grupowanie ich wewnątrz bloków.	W
WF-559	Bloki mogą być użyty w układzie strony i prezentowane użytkownikom na froncie strony.	W
WF-560	Pojedynczy baner może należeć wyłącznie do jednego bloku.	W
WF-561	Na pojedynczy baner muszą składać się przynajmniej pola: 1. tytuł banera, 2. pokaż tytuł banera, 3. typ banera, 4. wysokość, 5. szerokość, 6. data publikacji od, data publikacji do, 7. status publikacji, 8. przypisanie do bloku.	W
WF-562	Moduł bannerów musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-563	Moduł bannerów musi posiadać funkcjonalność kosza.	W
WF-564	Moduł bannerów musi podlegać procesowi wersjonowania wpisów.	W
WF-565	Moduł musi pozwalać na definiowanie poniższych typów banerów: 1. graficzny, 2. flashowy, 3. tekstowy (textarea), 4. tekstowy (edytor WYSIWYG).	W
WF-566	Zamieszczane w banerze zdjęcia musza pochodzić z repozytorium plików.	W
WF-567	Moduł banerów musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy banerów, 2. dodawanie banera, 3. edycja banera, 4. przenoszenie banera do kosza, 5. przywracanie banera z kosza, 6. usuwanie banera, 7. publikacja, zatwierdzanie banera, 8. wersjonowanie banera.	W
WF-568	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-569	Blok banerów musi posiadać elementy konfiguracyjne takie jak typ wyświetlania.	W
WF-570	System powinien udostępniać poniższe typy wyświetlania banerów: 1. losowo, 2. popup – jednorazowo, 3. popup – przy każdym wejściu na stronę.	W
WF-571	System bannerów w ramach bloków powinien udostępniać statystyki banerów.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-572	System powinien pokazywać statystyki sumaryczne dla całego bloku oraz dla banerów przypisanych do tego bloku.	W
WF-573	System powinien prezentować ilości odsłon (wyświetleń) banerów i ilość kliknięć w odnośniki w banerach.	W
WF-574	System musi pozwalać na osadzanie banerów (bloku banerów) za pomocą [shortcodes] w edytorze WYSIWYG.	W
WF-575	Słowniki
WF-576	System musi posiadać moduł słowników.	W
WF-577	Moduł słowników musi pozwalać na tworzenie baz informacji.	W
WF-578	Moduł słowników umożliwi użytkownikom portalu na przeglądnie informacji zgromadzonych w formie słownika.	W
WF-579	System musi pozwalać na tworzenie konfiguracji słownika oraz na definiowanie pól wchodzących w skład pojedynczego wpisu.	W
WF-580	Dzięki systemowi ról i uprawnień system musi posiadać możliwość udostępniania słowników wszystkim bądź zalogowanym użytkownikom.	W
WF-581	Moduł musi pozwalać na przeglądanie pozycji słownika w postaci listy wpisów, wyszukiwanie, filtrowanie, podgląd szczegółów wpisu.	W
WF-582	Moduł musi pozwalać na definiowanie pozycji słownika przez administratorów panelu oraz użytkowników frontu.	W
WF-583	Moduł musi pozwalać administratorowi na wskazanie poszczególnych pól, które będą stanowić podstawę dla działania mechanizmów przeszukiwania wskazanego słownika przez pozostałych użytkowników.	W
WF-584	Konfiguracja moduł musi pozwolić na dodanie danych do bazy za pomocą dedykowanego formularza przez użytkowników frontu. (Dane wysłane przez formularz muszą być wcześniej zaakceptowane przez administratora.	W
WF-585	Konfiguracja modułu musi pozwalać administratorowi na akceptację wpisów do słownika przesłanych przez użytkowników frontu, przed ich publikacją.	W
WF-586	System musi pozwalać na przypisywanie konkretnego słownika do wskazanej w strukturze portalu witryny internetowej w celu udostępniania danych pochodzących z słownika dla zalogowanych użytkowników.	W
WF-587	Na definicję pojedynczego słownika muszą składać się przynajmniej pola: nazwa, status publikacji.	W
WF-588	System musi pozwalać na stworzenie słownika na podstawie innego już istniejącego słownika. W ten sposób nowy słownik będzie posiadał definicje pól pochodzących z wskazanego słownika źródłowego.	W
WF-589	Słownik musi posiadać obsługę procesu zatwierdzania i publikacji.	W
WF-590	Słownik musi posiadać funkcjonalność kosza.	W
WF-591	Słownik musi podlegać procesowi wersjonowania wpisów.	W
WF-592	W ramach zdefiniowanego słownika system musi pozwalać administratorowi na definicję jego elementów.	W
WF-593	W ramach zdefiniowanego słownika system musi pozwalać na dodanie elementów takich jak: 1. pole jednokrotnego wyboru, 2. pole wielokrotnego wyboru, 3. pole typu select, 4. pole z otwartą odpowiedzią w polu typu input,	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	5. pole z otwartą odpowiedzią w polu typu textarea, 6. załącznik, 7. pole data, 8. pole czas, 9. pole data i czas, 10. pole e-mail, 11. pole pesel, 12. pole select – wielopoziomowe, 13. id obiektu.
WF-594	System musi pozwalać na definiowanie dodatkowych parametrów dla powyższych pól, takich jak: 1. nazwa pola, 2. długość pola – dla pól tekstowych, 3. dodatkowy opis nad i pod polem, 4. wymagalność pola na formularzu, 5. widoczność pola na formularzu na froncie, 6. widoczność pola w wyszukiwarce, 7. możliwość sortowania po polu w widoku listy na froncie.	W
WF-595	Struktura słownika nie może być edytowana / zmieniana jeżeli został on wypełniony przynajmniej jednym wpisem.	W
WF-596	Po użyciu słownika w strukturze serwisu musi on udostępniać możliwość konfiguracji dodatkowych pól.	W
WF-597	System nie może pozwolić na podpięcie słownika do struktury portalu bez wcześniejszego wykonania jego konfiguracji.	W
WF-598	Konfiguracja musi pozwalać na: 1. ustawienie słownika obsługiwanego na danej stronie, 2. konfiguracja listy wpisów w panelu, 3. konfiguracja listy wpisów na froncie, 4. konfiguracja formularza, 5. konfiguracja wyszukiwarki.	W
WF-599	Ustawienie słownika obsługiwanego na danej witrynie będzie realizowane przez wybór słownika z listy zdefiniowanych i skonfigurowanych wcześniej słowników.	W
WF-600	Konfiguracja listy wpisów w panelu musi pozwalać za pomocą mechanizmów drag & drop na określenie widoczności i kolejności kolumn na liście w panelu. Lista może ale nie musi wykorzystywać wszystkich elementów słownika.	W
WF-601	Konfiguracja listy wpisów na froncie musi pozwalać za pomocą mechanizmów drag & drop na określenie widoczności i kolejności kolumn na liście wpisów słownika dostępnego dla użytkowników na froncie. Lista może ale nie musi wykorzystywać wszystkich elementów słownika.	W
WF-602	Słownik wpisów na froncie musi pozwalać na wyświetlanie danych w postaci listy oraz jako widok kolumnowy. System musi pozwolić na zarządzanie tekstem na przycisku „dodaj do słownika” oraz na określenie ilości wpisów na liście. Spis wpisów musi być stronicowany.	W
WF-603	System musi zapewniać możliwość podpięcia słownika do formularza który to będzie stanowił formę prezentacji wskazanego słownika dla innych użytkowników	W
WF-604	Konfiguracja powyższego formularza musi pozwalać na włączenie / wyłączenie możliwości wypełnienia słownika danymi na froncie.	W
WF-605	System musi pozwalać na konfiguracje pól formularza za pomocą mechanizmów drag	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
	& drop, ustalania ich kolejności. Formularz może ale nie musi wykorzystywać wszystkich pól.
WF-606	Konfiguracja wyszukiwarki dla danego słownika musi pozwalać na włączenie / wyłączenie możliwości wyszukiwania na froncie.	W
WF-607	System musi pozwalać na konfiguracje pól dostępnych w wyszukiwarce za pomocą mechanizmów drag & drop, ustalania ich kolejności. Formularz może ale nie musi wykorzystywać wszystkich pól.	W
WF-608	Moduł słowników musi posiadać przynajmniej poniższe akcje, do których można nadawać uprawnienia: 1. dostęp do listy słowników, 2. dodawanie słownika, 3. edycja słownika, 4. przenoszenie słownika do kosza, 5. przywracanie słownika z kosza, 6. usuwanie słownika, 7. publikacja, zatwierdzanie słownika, 8. wersjonowanie słownika, 9. dostęp do elementów słownika, 10. dodawanie elementów, 11. edycja elementów, 12. usuwanie elementów, 13. konfiguracja słownika, 14. dostęp do listy wpisów w słowniku, 15. dodawanie wpisów do słownika, 16. edycja wpisów w słowniku, 17. przenoszenie wpisów słownika do kosza, 18. przywracanie wpisów słownika z kosza, 19. usuwanie wpisów słownika, 20. publikacja, zatwierdzanie wpisów słownika, 21. wersjonowanie wpisów słownika.	W
WF-609	System musi pozwalać na nadawanie tych uprawnień osobno lub w różnych wariantach.	W
WF-610	Aktualności globalne
WF-611	System musi posiadać funkcjonalność aktualności globalnych.	W
WF-612	Ponieważ poszczególne portale są oddzielnymi zbiorami danych, system musi pozwolić na dodanie aktualności, które muszą być widoczne we wszystkich portalach (np. ważne komunikaty).	W
WF-613	Aktualności globalne muszą być dostępne wyłącznie w panelu globalnym dla jego administratorów.	W
WF-614	Funkcjonalność aktualności globalnych musi pozwolić na dodanie wpisu do wszystkich uruchomionych w ramach multiportalu portali.	W
WF-615	Formularz dodawania aktualności musi być tożsamy ze zwykłym modułem aktualności.	W
WF-616	Definiując aktualność globalną administrator musi mieć możliwość wskazania na jakich portalach ma być ona opublikowana.	W
WF-617	Aktualność globalna widoczna jest w poszczególnych portalach (tylko tych wskazanych) w module aktualności, który został oznaczony jako domyślny.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-618	Ta sama sytuacja musi dotyczyć aktualności globalnej oznaczonej jako kalendarium. Taki wpis widoczny jest w portalu w module kalendarium oznaczonym jako domyślne.	W
WF-619	Wpisy aktualności i kalendarium globalnych w poszczególnych portalach muszą być widoczne w panelach administracyjnych tych portali na liście ale tylko dla celów informacyjnych. Takich wpisów nie można edytować, ani usunąć. Może to zrobić wyłącznie administrator globalny w panelu globalnym.	W
WF-620	Aktualności globalne muszą posiadać obsługę procesu zatwierdzania i publikacji ale tylko w panelu globalnym.	W
WF-621	Aktualności globalne muszą posiadać funkcjonalność kosza ale tylko w panelu globalnym.	W
WF-622	Aktualności globalne muszą podlegać procesowi wersjonowania wpisów ale tylko w panelu globalnym.	W
WF-623	Wyszukiwarka pracowników
WF-624	System musi posiadać moduł wyszukiwarki pracowników.	W
WF-625	Moduł wyszukiwarki użytkowników musi pozwolić na wyszukanie pracowników Zamawiającego.	W
WF-626	Moduł wyszukiwarki musi pozwolić na wyszukanie pracownika według kryteriów: 1. imię, 2. nazwisko, 3. jednostka organizacyjna, do której należy pracownik.	W
WF-627	Moduł musi prezentować listę pracowników uszeregowaną według trafności kryteriów.	W
WF-628	Dane pracowników muszą pochodzić z systemów dziedzinowych Zamawiającego i być cyklicznie importowane do multi portalu.	W
WF-629	Dokładny zakres importowanych danych musi zostać ustalony na etapie analizy przedwdrożeniowej.	W
WF-630	Moduł wyszukiwarki pracowników musi pozwolić na przejście z wyników wyszukiwania na podgląd szczegółów wybranego pracownika.	W
WF-631	Podgląd szczegółów danego pracownika musi być dostępny pod warunkiem, że dla danego pracownika została włączona opcja podglądu szczegółów i ma on uzupełnione informacje „O mnie” w swoim koncie.	W
WF-632	System musi pozwalać na włączenie pracownikom dostępu do swoich danych przez administratora. Administrator systemu musi posiadać opcję włączenia / wyłączenia tej opcji.	W
WF-633	System musi pozwalać administratorowi na edycję i rozbudowę powyższych danych dotyczących pracowników wyłącznie na poziomie platformy e-Usług bez zmian w systemie dziedzinowym z którego pochodzą.	W
WF-634	Zarządzanie dodatkowymi danymi pracownika musi być możliwe z poziomu frontu (dla pracownika) i panelu (dla administratora).	W
WF-635	Pracownicy z włączoną opcją dodatkowych danych po zalogowaniu się na froncie portalu mają dostęp do funkcjonalności „O mnie” w module „Moje konto.”	W
WF-636	Funkcjonalność „O mnie” musi pozwolić na wprowadzenie przez pracownika dodatkowych danych o swojej osobie - pełnione w Uczelni obowiązki, wyszczególnienie spraw którymi się zajmuje w obszarze swojej komórki organizacyjnej.	W
WF-637	Dane „O mnie” muszą podlegać wersjonowaniu, a ich wersje muszą być dostępne w panelu administracyjnym. Każda edycja tych danych musi tworzyć nową wersję wpisu.	W

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WF-638	Moduł wyszukiwarki i danych „O mnie” pracowników musi posiadać obsługę procesu zatwierdzania i publikacji (panel).	W
WF-639	Moduł wyszukiwarki i danych „O mnie” pracowników musi posiadać funkcjonalność kosza (panel).	W
WF-640	Moduł wyszukiwarki i danych „O mnie” pracowników podlegać procesowi wersjonowania wpisów (front i panel).	W

Wymagania ogólne dla systemu do realizacji usługi e-student – back-end

WF-641	Wymagania ogólne dla systemu do realizacji usługi e-student
WF-642	System obsługi elektronicznego obiegu dokumentów
WF-643	System powinien być zabezpieczony przed utratą danych spowodowaną awarią zasilania lub zakłóceniami w sieci zasilającej, dopuszcza się aby w razie awarii były tracone jedynie bieżące nie zapisane transakcje.	W
WF-644	System powinien być zabezpieczony przed dostępem nieuprawnionych osób lub programów.	W
WF-645	Dane występujące w systemie muszą podlegać procesom automatycznego tworzenia kopii zapasowej i kopii archiwalnych: całościowej, różnicowej, przyrostowej. Dokumentacja systemu musi zawierać procedurę odtwarzania z kopii archiwalnej/zapasowej.	O
WF-646	System musi mieć możliwość wykorzystania Active Directory do uwierzytelniania użytkowników.	W
WF-647	Wymagana jest obsługa wielu domen Active Directory.	O
WF-648	Wymagana jest możliwość pracy w środowisku terminalowym w oparciu o Microsoft Windows Terminal Server 2008 R2 lub nowszym.	O
WF-649	System powinien być oparty o platformę MS Xxxxxxxxxx w wersji min. wersja 2013 Foundation.	W
WF-650	System powinien być stworzony w technologii .NET w wersji min. 3.5	O
WF-651	Natywnym językiem zapytań silnika bazy danych powinien być język SQL (lub język zgodny z jego składnią).	O
WF-652	Silnik baz danych powinien zapewniać: 1. relacyjność, 2. integralność danych, 3. transakcyjność, 4. skalowalność.	O
WF-653	W systemie musi zostać zastosowany silnik bazodanowy z rodziny rozwiązań MS SQL.	O
WF-654	System bazodanowy musi zapewniać dostęp do danych wyłącznie po poprawnym uwierzytelnieniu. Dotyczy to zarówno dostępu przy pomocy programu, jak i wszystkich innych metod dostępu.	W
WF-655	System musi umożliwiać definiowanie grup użytkowników oraz nadawanie uprawnień na poziomie grup użytkowników oraz na poziomie pojedynczych użytkowników.	W
WF-656	System musi być zabezpieczony przed utratą danych oraz musi zachowywać spójność danych w bazie, w przypadku utraty komunikacji w sieci komputerowej.	W
WF-657	Nawigacja w systemie powinna być możliwa co najmniej za pomocą myszki i klawiatury.	W
WF-658	Moduł administrowania systemem musi pozwalać na zmianę jego parametrów wykonywaną przez administratora systemu bez interwencji Wykonawcy.	W

WF-659	W system musi być wbudowany system pomocy. Udostępnienie pomocy podręcznej (tzw. Help) w języku polskim, zawierającej zrozumiały i czytelny opis funkcjonowania aplikacji z elementami opisu merytorycznego zagadnienia. Pomoc podręczna powinna być kontekstowa, dostępna przy każdej formatce/ekranie. Merytorycznie musi być zgodna z wersją oprogramowania.	O
WF-660	System powinien mieć wbudowany mechanizm do rozszerzania funkcjonalności bez konieczności modyfikacji kodu źródłowego aplikacji i struktury bazy danych.	W
WF-661	System powinien mieć mechanizm do załączania własnych dodatkowych raportów, bez konieczności modyfikacji aplikacji.	W
WF-662	System powinien mieć wbudowany mechanizm do modyfikacji raportów (w tym wyglądu dokumentów).	O
WF-663	Interfejs użytkownika powinien być tak skonstruowany, aby nawigacja w czynnościach rutynowych, była możliwa za pomocą klawiatury bez użycia myszy.	O
WF-664	System musi uwzględniać znaki narodowe co najmniej wszystkich krajów europejskich najlepiej z pomocą kodowania Unicode.	O
WF-665	System musi posiadać możliwość automatycznego wysyłania wiadomości e-mail gdy zostanie spełniony zdefiniowany w systemie warunek.	W
WF-666	Modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych.	W
WF-667	System musi pozwolić na uruchamianie formularzy z kilku obszarów funkcjonalnych, bez konieczności przerywania pracy i uruchamiania kolejnych kopii programu.	W
WF-668	System musi pozwolić na eksport danych do popularnych formatów (co najmniej pdf, docx, xlsx).	W
WF-669	Dostarczony System musi mieć możliwość rozbudowy o nowe funkcje, poszerzania zakresu gromadzonych danych (np. dodanie pola lub tabeli), zmiany parametrów systemu itp.	W
WF-670	System musi zapewnić tryb projektowania formularza bez ingerencji programistycznej – modyfikacje dla użytkownika lub grupy użytkowników. Tryb powinien umożliwić przynajmniej: 1. dodawanie i usuwanie nowych pól na formularzach, 2. zmianę lokalizacji i rozmiaru pól, 3. zmianę rozmiaru i koloru czcionki, 4. blokowanie dokonywania zmian w polach, 5. zmianę wymagalności pól, 6. budowanie dynamicznych list z podpowiadanymi wartościami dla pól, 7. dodawanie przycisków uruchamiających dowolną wtyczkę (formularz, wydruk, akcję) wraz z możliwością przekazania kontekstu pracy, 8. dodawanie przycisków uruchamiających stronę HTML z dowolnymi merytorycznymi informacjami wraz z możliwością przekazania kontekstu pracy, 9. możliwość umieszczania kontekstowych linków do dowolnych wtyczek (formularza, wydruku, akcji), 10. budowę wyskakujących podpowiedzi (dymki) z dowolnymi merytorycznymi informacjami (dla pól i komórek w tabeli) wraz możliwością przekazania kontekstu pracy.	W
WF-671	Funkcjonalność
WF-672	Użytkownicy systemu muszą być autoryzowani za pomocą mechanizmów autoryzacyjnych korzystających z usług katalogowych. Uprawnienia użytkownika w zakresie obiegów dokumentów (szerzej: procesów) powinny być nadawane na poziomie: 1. Dokumentu, sprawy, zadania: w momencie przypisania do użytkownika zadania (oraz zadania DW) użytkownik otrzymuje uprawnienie związane z	W

	danym elementem workflow (dokumentem, sprawą). Uprawnienie takie zezwala na edycję elementu w zakresie edycji określonym dla danego kroku. Po zakończeniu zadania i przesłania dokumentu dalej (przekazania do kolejnej osoby lub kroku) dokument pozostaje dostępny dla osoby w trybie ‘tylko do odczytu’. 2. Globalnym: dla każdego procesu oraz kombinacji typu dokumentu z obiegiem możliwe jest określenie uprawnień: administracyjnych, modyfikacji bez usuwania, odczytu, odczytu bez załączników, rozpoczynania nowego obiegu.
WF-673	System musi umożliwić audyt historii operacji każdego dokumentu (sprawy, elementu workflow) x.xx. w zakresie: 1. edycji formularza, 2. wyboru ścieżek przejścia (decyzji), 3. wywołania akcji (w tym notyfikacji i akcji integracyjnych), 4. przydzielonych zadań, 5. załączników, 6. pozwalając określić autora oraz daty realizacji wpisów (zmian).	W
WF-674	System powinien posiadać wizualizacje historii zmian formularzy elektronicznych z dokładnością do pola (atrybutu) tego formularza. Dane powinny być prezentowane w tabeli tak, aby użytkownik łatwo mógł porównać zmiany w poszczególnych częściach formularza na poszczególnych krokach procesu/obiegu. Dodatkowo system dostarczyć informacji o wszystkich użytkownikach dokonujących tych zmian.	O
WF-675	System powinien zapewnić narzędzia do migracji danych pomiędzy środowiskami deweloperskim, testowym i produkcyjnym.	O
WF-676	System powinien posiadać mechanizm OCR pozwalający na automatyczną rejestrację dokumentów w systemie. Mechanizm nie może być oparty o szablony OCR bazujące na rozmieszczeniu wyszukiwanych elementów we wskazanych w szablonie obszarach dokumentów, innymi słowy wykorzystane szablony muszą być uniwersalne dla danego typu dokumentu (np. dla faktury system musi w oparciu o dostarczony szablon rozpoznawać faktury wystawiane na różnych formularzach).	O
WF-677	System powinien dawać możliwość tworzenia dokumentów PDF zawierających oryginalnie zeskanowany dokument (bitmapa), oraz zapisywać w nim tekst (tekst pod bitmapą, będący wynikiem działania mechanizmu OCR) – uzyskanie dokumentu z możliwością wyszukiwania	O
WF-678	Interfejs weryfikacji jakości rozpoznania dokumentów za pomocą mechanizmu OCR musi być dostępny w ramach podstawowego interfejsu wykorzystywanego w obiegu dokumentów niedopuszczalne jest np. wykorzystanie zewnętrznych aplikacji wymagających opuszczenia interfejsu, na którym realizowane są czynności związane z rejestracją dokumentów i ich procesowaniem przez pracownika)	O
WF-679	OCR musi umożliwiać rozpoznawanie tekstu wg dowolnie określanych przez użytkownika systemu harmonogramów (np. w tle, ad hoc) (określenie dni i godzin uruchamiania i zakończenia przetwarzania OCR dla wybranego zakresu dokumentów) dla całości lub wskazanych przetwarzanych przez system dokumentów	O
WF-680	System musi umożliwiać sprawne wyszukiwanie pełno-tekstowe wśród dokumentów wcześniej przetworzonych przez OCR	O
WF-681	System musi umożliwiać konfigurację serwera OCR na niezależnej maszynie od serwera aplikacyjnego i bazodanowego systemu.	O
WF-682	System musi umożliwić pobieranie dokumentów bezpośrednio z urządzeń skanujących Skanowane dokumenty muszą trafić automatycznie do wybranej biblioteki dokumentów.	O
WF-683	System musi umożliwiać import dokumentów z lokalnego systemu plików jako załączników do spraw/zadań/dokumentów	W
WF-684	System musi umożliwiać uruchomienie skanowania dokumentu z wykorzystaniem	O

	sterownika TWAIN skanera podłączonego do stacji roboczej użytkownika. System pozwala zapisać domyślne ustawienia w zakresie rozdzielczości skanowania, trybu (kolor, odcienie szarości, czarno-biały), itp.
WF-685	System musi umożliwiać pobieranie obrazów znajdujących się w schowku systemowym bez potrzeby ich uprzedniego zapisania na dysku w postaci pliku.	O
WF-686	System musi umożliwiać ograniczenie praw dostępu do określonych rodzajów dokumentów, zadań, spraw na podstawie nadanych użytkownikowi/grupie uprawnień	W
WF-687	System musi mieć zaimplementowany mechanizm ochrony przed całkowitym usunięciem dokumentów przez osoby inne niż Administrator Procesu.	W
WF-688	System powinien posiadać obsługę zastępstw i możliwe jest oparcie zastępstwa o dane z systemu kadrowo płacowego	W
WF-689	Zamawiający wymaga aby była możliwość konfiguracji procesów niezależnie od struktury organizacyjnej.	O
WF-690	Zamawiający wymaga aby była dostępna obsługa podglądu zadań pracowników podległych (wg. aktualnej na moment podglądu struktury organizacyjnej firmy wykorzystywanej w procesie)	O
WF-691	Praca grupowa
WF-692	System musi zapewnić możliwość współdzielonego dostępu do dokumentów zapewniając ich spójność.	O
WF-693	System musi umożliwiać wersjonowanie dokumentów z opisem historii zmian. Wersjonowanie dotyczy formularzy opisujących dokument jak i załączników. Powinna być możliwość wywołania podglądu zmian między wersjami załącznika wewnątrz edytora tekstu.	W
WF-694	System musi umożliwiać zablokowanie użycia nieaktualnej wersji dokumentu.	W
WF-695	System musi umożliwiać podgląd dowolnej wersji historycznej dokumentu.	O
WF-696	System musi posiadać mechanizm umożliwiający przesłanie dokumentu/sprawy/zadania do akceptacji, weryfikacji i opiniowania przez innych użytkowników Systemu	W
WF-697	System musi być wyposażony w funkcje akceptacji, które umożliwiać będą co najmniej: Akceptację dokumentu przesłanego do jednego użytkownika – dokument/sprawa/zadanie jest zaakceptowane tylko przez ww. użytkownika. Przesłanie dokumentu do wielu i akceptację przez jednego z nich – dokument/sprawa/zadanie jest zaakceptowane, gdy tę operację wykona jeden z grupy użytkowników (np.: jeden z trzech). Przesłanie i akceptację przez wielu użytkowników – dokument/sprawa/zadanie jest zaakceptowane, gdy tę operację wykona większość użytkowników (np.: dwóch z trzech). Przesłanie i akceptację przez wszystkich – dokument/sprawa/zadanie jest zaakceptowane, gdy tę operację wykonają wszyscy użytkownicy (np.: trzech z trzech).	W
WF-698	System musi umożliwiać łatwą modyfikację obiegu akceptacji dokumentów z użyciem interfejsu graficznego (projektowanie procesów workflow z użyciem schematu blokowego).	W
WF-699	Modyfikacja definicji obiegu dokumentu (np. dodanie kolejnego kroku akceptacji) nie może powodować konieczności ponownego uruchomienia obiegu dokumentów – element będący w kroku poprzedzającym kroki dodane powinien być procesowany zgodnie z nową definicją procesu.	O
WF-700	System powinien umożliwić dodawanie uwag/komentarzy do dokumentu na każdym etapie jego obiegu. System powinien posiadać możliwość przechowywania historii wprowadzanych uwag/komentarzy	O
WF-701	Proces przepływu pracy musi zapisywać ścieżkę akceptacji i mierzyć czasy podejmowania decyzji i umożliwiać późniejsze raportowanie.	O

WF-702	Mechanizmy przepływu pracy muszą być wyposażone w system raportowania: 1. ilości dokumentów w poszczególnych fazach; 2. ilości zaakceptowanych dokumentów z podziałem na typy dokumentów i osoby; 3. ilości odrzuconych dokumentów z podziałem na typy dokumentów i osoby; 4. czasy odpowiedzi na dokument dla poszczególnych użytkowników	W
WF-703	System musi być wyposażony w silnik reguł biznesowych pozwalający na tworzenie szerokiego wachlarza warunków wykorzystanych później do np. wykonania akcji, wpisywania wartości domyślnych, wyboru ścieżki procesu, przypisania osoby do zadania w procesie.	W
WF-704	Silnik reguł biznesowych powinien posiadać graficzny edytor reguł, pozwalający na tworzenie reguł za pomocą mechanizmu „przeciągnij i upuść”.	O
WF-705	Raz stworzone reguły biznesowe mogą być wielokrotnie wykorzystywane w wielu miejscach Systemu.	O
WF-706	System powinien wskazywać miejsca wykorzystania reguł biznesowych.	O
WF-707	Tworzenie/edycja dokumentów
WF-708	System musi współpracować z eksploatowanym przez Zamawiającego pakietem MS Office (wersja minimum 2007) na poziomie przygotowania i edycji dokumentów. System powinien umożliwiać otwarcie dokumentu w MS Office z poziomu Systemu.	W
WF-709	System musi umożliwiać generowanie dokumentów na podstawie szablonów pism używanych obecnie przez Zamawiającego.	W
WF-710	System musi umożliwiać tworzenie, przeglądanie, edycję, usuwanie i drukowanie utworzonych dokumentów przez uprawnione do tego osoby.	W
WF-711	System musi mieć wbudowane mechanizmy współpracy z edytorem tekstu z dokładnością do śledzenia zmian w dokumencie w taki sposób aby zmiany w pliku były rejestrowane przez system w bazie danych.	O
WF-712	System musi zapewniać możliwość automatycznego nadawania sygnatury wniosku.	W
WF-713	System musi z poziomu administratora systemu umożliwiać definiowanie reguł nadawania sygnatury zgodnie z obowiązującymi na Uczelni zasadami.	W
WF-714	Zarządzanie procesami
WF-715	System musi umożliwiać definiowanie, zarządzanie i wykonywanie procesów automatycznie przetwarzających zadania (workflow).	W
WF-716	System w ramach zarządzania procesami musi umożliwiać wykorzystanie informacji o strukturze organizacyjnej, jednostkach organizacyjnych, pracownikach, ich rolach w systemie do wyznaczania osób odpowiedzialnych za realizację poszczególnych etapów procesu.	W
WF-717	System musi umożliwiać automatyczne uruchamianie procesów realizacji zadań na podstawie wpływu pism od nadawców (dany rodzaj dokumentu inicjuje konkretną procedurę, np. przez profile dokumentów na skanerze).	W
WF-718	System musi umożliwiać ręczne wywoływanie procesów (ad hoc), poprzez przydział zadań pracownikom przez osoby do tego uprawnione (np. przez właścicieli procesów).	W
WF-719	System musi umożliwić tworzenie i edycję procesów bez konieczności korzystania z pomocy dostawcy z poziomu uprawnionego użytkownika systemu. Tworzenie procesów powinno odbywać się za pomocą graficznego, intuicyjnego interfejsu, który będzie umożliwiał modyfikowanie logiki zamodelowanych procesów.	W
WF-720	Modyfikacja obiektów (x.xx. kroku, ścieżki, nazwy atrybutu) występujących w procesie musi być propagowana na wszystkie elementy na których występuje obiekt celem minimalizacji pracy operatora systemu. Przykładem zastosowania może być przyjęcie nowego pracownika (obiektu), który przejmuje wszystkie uprawnienia i dokumenty/sprawy/zadania innego pracownika.	O
WF-721	System musi udostępniać bazę procedur/procesów odpowiednim użytkownikom, zgodnie ze zdefiniowanymi uprawnieniami.	W
WF-722	Zarządzanie zadaniami

WF-723	System musi mieć możliwość definiowania zadań przez uprawnione osoby oraz przekazywanie ich do wykonania podległym pracownikom.	W
WF-724	System musi umożliwiać osobie tworzącej oraz dekretującej zadanie określanie stopnia ważności, czasu realizacji oraz uwag dotyczących sposobu realizacji zadania.	W
WF-725	System musi umożliwiać wykonującemu zadanie określanie postępu realizacji zadania oraz dodanie uwag dotyczących toku wykonywania zadania.	W
WF-726	System musi umożliwiać przypisywanie jednej osobie, kilku osobom bądź grupie osób określonych zadań do wykonywania.	W
WF-727	Użytkownik musi mieć możliwość dodania do zadania dokumentów oraz innych plików z wewnętrznego systemu plików.	W
WF-728	W przypadku zadań generowanych przez predefiniowane procesy system musi informować użytkownika o kolejnych czynnościach, jakie musi wykonać, aby prawidłowo zakończyć realizację zadania.	O
WF-729	System musi automatycznie powiadamiać osoby wyznaczone do realizacji danego zadania o konieczności podjęcia odpowiednich czynności.	W
WF-730	System musi umożliwiać przekierowanie zadania do innego wykonawcy (np. w związku z absencją osoby dotychczas realizującej dany etap zadania).	W
WF-731	System musi sygnalizować o przekroczeniu terminu realizacji zadań.	O
WF-732	System musi zapewniać automatyczne generowanie przypomnień i ponagleń dla zadań, w których minął lub zbliża się termin realizacji, kierowanych do zaangażowanych w proces użytkowników oraz osób, które przydzieliły zadanie.	W
WF-733	System musi informować bądź prezentować osoby odpowiedzialne za wykonanie danego zadania oraz przydzielającego to zadanie o zakończeniu realizacji danego zadania.	W
WF-734	System musi umożliwiać śledzenie procesów, sprawdzenie, na jakim etapie znajduje się realizacja danego zadania.	W
WF-735	System musi umożliwiać sprawdzenie listy zadań do wykonania, przydzielonych określonemu pracownikowi (informacja dotycząca ilości wykonywanych zadań itp.).	W
WF-736	System musi posiadać możliwość przeglądania przez przełożonego zadań swoich podwładnych.	O
WF-737	Podpis elektroniczny
WF-738	System musi umożliwiać wykorzystanie podpisu elektronicznego do podpisywania dokumentów (co najmniej pliki PDF i DOCX).	W

4. Wymagania Techniczne

4.1. Architektura rozwiązania

Wymagania ogólne dla architektury Platformy e-usług przeznaczonej do realizacji:

E-tablica ogłoszeń; E-kontakt; E-klinika prawa; E-klinika administracji; E-Klinika

przedsiębiorczości; E-klinika bezpieczeństwa; Interaktywny system badań; E-repozytorium

Nr wymagania

Opis wymagania

Funkcjonalność W/O

WT-1

Planowane środowisko Systemu pracować powinno na zasobach zwirtualizowanych.

WT-2

System portalowy musi być zbudowany w oparciu o architekturę trójwarstwową

(warstwa prezentacji, warstwa logiki, warstwa bazy danych).

Nr wymagania	Opis wymagania	Funkcjonalność W/O
WT-3	System portalowy musi być zbudowany w oparciu o serwer aplikacyjny oraz o serwer bazy danych, przy czym oba te serwery muszą być uruchomione na oddzielnych maszynach.	W
WT-4	System musi wspierać i działać na systemie operacyjnym Linux Debian.	O
WT-5	System musi działać w oparciu o serwer http Apache lub NGINX.	O
WT-6	System musi wspierać i działać przynajmniej na poniższych bazach danych: 1. MariaDB, 2. MS SQL Server	O
WT-7	W przypadku zastosowaniu komponentów Open Source, system musi działać w oparciu o ich najnowsze wersje dostępne na rynku w dniu produkcyjnego uruchomienia multi portalu.	W
WT-8	Wszystkie funkcjonalności systemu i zarządzanie nim muszą być możliwe z poziomu przeglądarki internetowej, bez konieczności instalacji dodatkowego oprogramowania.	W
WT-9	System musi być wersjonowany. Wszystkie prace wdrożeniowe oraz modyfikacje plików źródłowych muszą być wersjonowanie i przetrzymywane na repozytorium (Git lub SVN), do których Zamawiający będzie miał dostęp.	W
WT-10	System musi obsługiwać wystąpienia wyjątków. Niedopuszczalne jest wyświetlanie błędów systemu na froncie strony.	W
WT-11	System musi zapewniać przyjazne URL’e.	W
WT-12	Wszystkie aplikacje w ramach panelu administracyjnego systemu muszą posiada ten sam wygląd oraz logikę działania.	W
WT-13	System musi funkcjonować w oparciu o budowę modułową. Musi pozwalać na jego rozbudowę, bez naruszenia stabilności modułów już istniejących.	W
WT-14	Instalacja nowych modułów musi odbywać się bez konieczności wyłączenie / przestoju w funkcjonowaniu multi portalu.	W
WT-15	System powinien być wykonany w technologii PHP >= 5.6.	O
WT-16	System powinien wykorzystywać Redis’a do przetrzymywania i cache’owania danych.	O
WT-17	System powinien wykorzystywać narzędzie Solr do wsparcia mechanizmów wyszukiwania.	O
WT-18	Standardy
WT-19	W3C
WT-20	System portalowy musi zostać przygotowany w oparciu o otwarte standardy W3C, zgodnie z najnowszymi trendami i możliwościami jakie daje język HTML 5 oraz zastosowanie CSS 3.	W
WT-21	Poprawność kodu HTML serwisu musi zostać zweryfikowana za pomocą walidatorów W3C, co przyszły Wykonawca potwierdzi stosownym raportem.	W
WT-22	WCAG 2.0
WT-23	Serwis internetowy ma być dostępny dla osób z niepełnosprawnością. W związku z tym musi być zgodny ze wszystkimi wytycznymi WCAG 2.0 zawartymi w załączniku nr 4 do Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 16 maja 2012 poz. 526).	W
WT-24	W szczególności przyszły Wykonawca musi uwzględnić poniższe elementy wytycznych WCAG 2.0:	W

Document Metadata

Table of Contents

PLATFORMA E-USŁUG EDUKACYJNYCH WSPiA

Document Metadata