Wymagania funkcjonalne 1. Wymagania ogólne

Wymagania funkcjonalne 1. Wymagania ogólne 1. System musi by przystosowany do obowizujcego w urzdzie bezdziennikowego systemu kancelaryjnego opartego o wykaz akt. 2. System powinien umoliwi prowadzenie w Urzdzie dowolnej sprawy w formie elektronicznej od momentu jej zarejestrowania na odpowiednim stanowisku pracy do momentu jej zakoczenia. 3. Obieg dokumentów przychodzcych odbywa si winien w całoci w formie dokumentów cyfrowych: od chwili zeskanowania dokumentu w odpowiedniej komórce organizacyjnej (np. kancelarii) a do przekazania kopii elektronicznej dokumentu na wskazane stanowisko pracy. 4. System powinien wspiera równie obieg dokumentów papierowych m.in. poprzez moliwo nanoszenia biecej informacji o miejscu przechowywania danego dokumentu i dodawania odwzorowania cyfrowego dowolnego dokumentu papierowego. 5. W przypadku przesyłek papierowych, dla których nie wykonuje si odwzorowania cyfrowego system musi posiada moliwo rejestracji w sposób przyjty w urzdzie. Opis takiej przesyłki w postaci metadanych i informacji o miejscu przechowywania nonika musi by przechowywany w systemie. 6. Obieg dokumentów wychodzcych odbywa si winien w sposób analogiczny, od chwili utworzenia dokumentu przy pomocy aplikacji biurowej / zeskanowania dokumentu w odpowiedniej komórce organizacyjnej do momentu ostatecznej dekretacji i podpisania dokumentu przez osob uprawnion podpisem cyfrowym, lub tradycyjnym po wydrukowaniu go na wskazanych stanowiskach pracy. 7. System musi umoliwi biece monitorowanie realizacji spraw w sposób terminowy i zgodny ze zdefiniowan procedur pracy. 8. System musi zapewni pełn kontrol nad obiegiem informacji (korespondencji, faksów, poczty elektronicznej, polece słubowych, plików tekstowych, zarzdze wewntrznych) w oparciu o instrukcj kancelaryjn, jednolity rzeczowy wykaz akt i instrukcj archiwaln. 9. System musi umoliwi przenoszenie danych zawartych w swoich bazach dla potrzeb Biuletynu Informacji Publicznej prowadzonego stosownie do wymaga Ustawy z dn. 6.09.2001 r. o dostpie do informacji publicznej (Dz.U. z 2001 r. Nr 112 poz. 1198 z pón. zm.), oraz umoliwi prowadzenie spraw w sposób zapewniajcy spełnienie wymaga Ustawy z dn. 18.09.2001 r o podpisie elektronicznym. (Dz.U. z 2001 r Nr 130 poz. 1450 z pón. zm.) oraz Ustawy o ochronie danych osobowych z dn. 29.08.1997 r. (Dz.U. z 2002 r. Nr 101 poz.926 z pón. zm.). 10. System musi umoliwi przenoszenie do swoich baz, danych z Elektronicznej Skrzynki Podawczej zgodnie z rozporzdzeniem Prezesa Rady Ministrów z dn. 29.09.2005 r., w sprawie warunków organizacyjno-technicznych dorczania dokumentów elektronicznych podmiotom publicznym (Dz.U. 2005 Nr 200, poz. 1651). 11. System musi uwzgldni ograniczenia i zasoby Urzdu (np. etaty, budet). Jego pełna funkcjonalno nie moe by uzaleniona od zwikszenia nakładów (np. zatrudnienia dodatkowych pracowników). System, po jego wdroeniu, nie moe powodowa wydłuenia czasu pracy uytkowników w stosunku do czasu przeznaczanego na konkretne czynnoci obecnie (rejestracja pisma w kancelarii, stworzenie pisma, obieg druków wewntrznych, itp.). Czas reakcji (odpowiedzi) systemu na działania uytkownika nie moe przekracza 5 sekund. 12. Poziom skomplikowania systemu powinien by niski, a jego obsługa intuicyjna. Strona 1/18

13. System zapewni musi: a. pełnienie dla wybranych adresów poczty elektronicznej funkcjonalno klienta poczty, umoliwia równie import do systemu wybranych maili z rónych klientów poczty elektronicznej, b. moliwo dodawania zastpstw na kilku poziomach: przez pracownika (wówczas nadawanie zastpstw powinno by raportowane kierownictwu), przez kierownika, przez administratora merytorycznego i administratora głównego, c. informowanie kto i jak czynno wykonał i w czyim zastpstwie jeli takie zastpstwo nadano, d. mechanizm przejcia spraw w przypadku odejcia z pracy lub zmiany zakresu czynnoci pracownika, e. wersjonowanie zmian w strukturze organizacyjnej zmiany odnosz si tylko do nowych dokumentów, spraw itp., f. przechodzenie po polach w ramach widoku, szablonu lub rejestru za pomoc klawisza TAB (konfigurowalna kolejno przechodzenia), g. moliwo wykonywania operacji seryjnych np. rejestracji (takie funkcje jak: dodaj nastpne z takimi danymi, zapisz dane, powiel dane), h. mechanizm podgldu pisma do akceptacji, które musi zawiera wszystkie dane, adne dane nie mog by ukrywane, i. podgld zeskanowanego pisma włczany/wyłczany cały czas podgld ma zawiera elementy nawigacji po zestawie zeskanowanych pism (w ramach jednej sprawy) zeskanowane i pierwotnie elektroniczne razem, j. moliwo wszczcia sprawy bez pisma przychodzcego, na podstawie pisma pierwotnie elektronicznego, notatki słubowej itp., k. mechanizm notatek prywatnych i publicznych do sprawy, do pisma, l. konieczno potwierdzenia otrzymania odwzorowania pisma lub/i papierowego oryginału poprzez wybór odpowiedniej opcji w systemie, m. mechanizm blokowanie moliwoci otwarcia pisma wówczas przegldanie tylko metryczki pisma/sprawy sprawy poufne lub zastrzeone, n. mechanizm blokowania moliwoci wydruku dla okrelonych kategorii dokumentów i/lub osób, o. histori pokazujca kto dokument pobrał na dysk, kto go drukował, kto przegldał, kto wykonał dany raport równie z opcj rezygnacji z monitorowania czci czynnoci, p. personalizacj ustawie interfejsu dla pojedynczego uytkownika, q. budow formularzy, rejestrów z poziomu graficznego interfejsu wraz z warunkami walidacji pól (WYSWIG), r. tworzenie rejestrów i spisów z poziomu graficznego interfejsu z moliwoci korzystania z pól istniejcych w systemie, s. dostosowanie interfejsu poprzez midzy innymi: mapowanie pól mechanizm mapowania okrelony z góry jak i edytowalny, blokowanie pól, usuwanie pól, dodawanie pól i ich etykiet, Strona 2/18

t. wyszukiwanie z mechanizmem filtrowania wyników, jeli dane s prezentowane w tabeli to sortowanie po kolumnach lub/i za pomoc okien dialogowych, u. moliwo dodawania inicjałów referenta do znaku sprawy (po kropce po roku sprawy), v. tworzenia podteczek w sposób przyjty w urzdzie, w. mechanizm sprawdzania danych w słownikach pod wzgldem np. dublujcych si danych wane w przypadku dodawania danych klientów, adresatów itp., x. mechanizm pilnujcy zmian w słownikach zmiana wartoci słownikowej musi wpływa tylko (z zasady) na nowe dokumenty, y. posiada róne rodzaje słowników: otwarte, zamknite, uczce si, definiowane przez administratora technicznego, z. mechanizmy usuwania dokumentów nieewidencjonowanych. 2. Wymagania w zakresie obiegu spraw i dokumentów 1. System musi udostpnia mechanizmy dla obiegu spraw i dokumentów, w tym moliwo tworzenia i modyfikacji cieki przetwarzania: a. w ramach systemu musi zosta przekazane narzdzie umoliwiajce Zamawiajcemu samodzielne definiowanie nowych oraz modyfikacj zdefiniowanych w ramach wdroenia procesów, b. narzdzie powinno udostpnia dla realizacji swoich zada interfejs graficzny, o intuicyjnej obsłudze przez uytkowników. c. narzdzie powinno umoliwia dokonanie sprawdzenia formalnej poprawnoci definicji procesu, d. narzdzie wykorzystane do realizacji obiegu powinno udostpnia nastpujce moliwoci kształtowania cieki przetwarzania: i. moliwo tworzenia przepływów sekwencyjnych, ii. moliwo tworzenia przepływów równoległych, iii. moliwo tworzenia przepływów alternatywnych, iv. moliwo tworzenia podprocesów i wielokrotnego ich wykorzystania, v. moliwo tworzenia grup decyzyjnych z głosowaniem decyzji. 2. System musi udostpnia mechanizmy dla obiegu spraw i dokumentów, w tym moliwo monitorowania sprawy: a. automatyczne łczenie dokumentów (w tym wszelkich pism, notatek) w sprawy np. na podstawie znaku sprawy, b. moliwo dodawania dowolnych załczników: prezentacji, filmów, zdj, stron WWW, nagra, maili itp., c. moliwo automatycznego dołczania UPO, (Urzdowego Powiadczenia Odbioru generowanego przez epuap) d. moliwo sprawdzenia aktualnego stanu sprawy, e. automatyczne informowanie odpowiedzialnych osób o zakoczeniu okrelonego etapu obsługi sprawy, f. moliwo ledzenia wstecznego sposobu załatwiania sprawy (daty, dane, dokumenty), Strona 3/18

g. moliwo kontroli czasu załatwiania sprawy, w tym: i. przypominanie o niebezpieczestwie upływu terminu załatwienia sprawy, ii. alarmowanie przełoonych o upływaniu terminu załatwienia sprawy (eskalacja), iii. moliwo definiowania alternatywnej cieki przetwarzania sprawy w razie niebezpieczestwa jej przeterminowania. h. oprócz limitów czasowych dla spraw okrelanych automatycznie lub nadawanych podczas rejestracji/dekretacji musi istnie moliwo rozrónienia limitów w dniach roboczych i dniach kalendarzowych w zalenoci od ustawie lub potrzeb (zgodnie z przepisami dla danych typów spraw), i. oprócz informacji o miejscu przechowywania papierowej wersji pisma (skład chronologiczny), które nie zostało wskanowane do systemu (ze wzgldu na format, wielko) system musi pozwala na rejestracj informacji o nonikach informatycznych, które s przechowywane w składzie informatycznych noników (instytucja moe mie wicej ni jeden skład), j. moliwoci o jakich mowa w powyszych punktach powinny by dostpne dla: i. całej sprawy, ii. pojedynczego zadania w sprawie, iii. zdefiniowanej grupy zada. 3. System musi mie moliwo przekazywania alarmów za pomoc: a. powiadomie przekazywanych w ramach realizowanego systemu, (np. informacje na pulpicie operatora), b. powiadomie przekazywanych za pomoc e-mail. 4. System musi udostpnia moliwo współpracy z repozytorium dokumentów w tym: a. moliwo automatycznego uruchamiania procesu obsługi dokumentu po dołczeniu nowego dokumentu do repozytorium, b. moliwo automatycznego uruchamiania procesu obsługi dokumentu po dołczeniu nowej wersji dokumentu do repozytorium, c. moliwo automatycznego uruchamiania procesu obsługi dokumentu po usuniciu dokumentu z repozytorium. 5. Rodzaj uruchamianych procesów o których mowa w powyszych punktach System powinien uzalenia od: a. rodzaju (klasy) dokumentu, b. wartoci zmiennych opisujcych dokument (atrybutów dokumentu), c. rodzaju zdarzenia w repozytorium (dodanie, modyfikacja wersji, usunicie). 6. System musi udostpnia moliwo prowadzenia analiz, w tym: a. posiada wbudowane raporty umoliwiajce podstawow analiz statystyczn prowadzonych spraw, b. umoliwia rozbudow systemu raportowania. 7. System musi zapewnia selektywny dostp do danych procesu oraz zwizanych z procesem Strona 4/18

dokumentów. 8. System musi umoliwia przypisanie do wykonywania poszczególnych kroków osób i grup uytkowników. 9. System musi umoliwia osobom uprawnionym dynamiczn zmian przypisania: a. System musi zapewni moliwo pełnienia wicej ni jednej roli dla uytkownika bez koniecznoci przelogowywania si np. pracownik sekretariatu i archiwista zakładowy (ta sama osoba) 10. Uytkownik powinien posiada prawa dostpu do dokumentów ograniczone do uprawnie zdefiniowanych dla repozytorium dokumentów. 11. W poszczególnych krokach powinien istnie dostp jedynie do danych i dokumentów jakie dla tego kroku okrelono przy definiowaniu procesu. 12. Inne wymagania dla systemu obiegu spraw i dokumentów: a. moliwo definiowania dynamicznych struktur danych, b. zdefiniowane schematy przetwarzania dla danego procesu powinny by: i. wersjonowane, ii. przechowywane w repozytorium, iii. separowane od przechowywania danych procesu. 13. System musi zapewni oznaczanie pism take za pomoc kodów kreskowych. 3. Wymagania w zakresie procesów 1. System zapewni obsług procesów podstawowych (grupa I), stosowanych w kadym urzdzie (tj. wymagajcych niewielkiego dostosowania procesów standardowych przez Wykonawc) procesów: a. korespondencja wchodzca b. korespondencja wychodzca c. obieg dokumentów finansowo-ksigowych d. upowanienia e. zamówienia publiczne ( w tym zamówienia poniej 14 tys. Euro) f. wnioski o dostp do informacji publicznej g. skargi i wnioski h. absencje i urlopy pracownicze i. delegacje krajowe i zagraniczne j. przemieszczanie majtku k. obsługa wniosków o podjcie kontroli l. zatrudnienie/zwolnienie pracownika m. organizacja narad, szkole i konferencji 2. System zapewni obsług procesów dedykowanych (grupa II) wynikajcych ze specyfiki Urzdu: a. GIW: Strona 5/18

b. WITD c. APKr i. działalno ustawowa (kontrolna); ii. działalno zwizana z funkcjonowaniem instytucji (niekontrolna). 1.. wskazane w pkt 1 oraz: i. działalno ustawowa (kontrolna); ii. działalno zwizana z funkcjonowaniem instytucji (niekontrolna). i. działalno ustawowa kontrolna, edukacyjna, wydawnicza, usługowa; ii. działalno zwizana z funkcjonowaniem instytucji. iii. W obydwu działaniach podstaw do odpowiedniej jakoci realizacji zada jest praca z informacj czyli jej gromadzenie, przetwarzanie, wyszukiwanie itp. (take informacji przechowywanej w postaci dokumentu papierowego). 3. Zamawiajcy oczekuje, e w czasie analizy przedwdroeniowej zidentyfikowane zostan wszystkie procesy, ale szczegółowo zostan opracowane i zautomatyzowane procesy z grupy I oraz wybrane elementy procesów z grupy II. Za jako i kompletno przeprowadzonych analiz odpowiada Wykonawca.. 4. Zamawiajcy oczekuje, ze procesy z grupy II powinny by moliwe do realizacji w Systemie, ale bez ich automatyzacji. Automatyzacja procesów grupy II odbdzie si w czasie okresu gwarancyjnego z uwzgldnieniem dowiadcze wynikajcych z obsługi procesów grupy I. 5. Analiza procesów musi by sporzdzona w postaci opisu słownego, ilustrowanego rysunkami/wykresami/obrazami ekranów oprogramowania. Dokument ma by sporzdzony w takiej formie, aby umoliwi jego zrozumienie przez osoby nie znajce adnej formalnej metody (notacji) modelowania procesów. 4. Wymagania w zakresie obsługi pracowników zdalnych 1. System musi zapewni bezpieczny dostp do Systemu dla pracowników znajdujcych si w innych lokalizacjach Urzdu oraz jednostek terenowych Urzdu. 2. System musi zapewni bezpieczne mechanizmy pracy zdalnej dla uprawnionych pracowników Urzdu z wykorzystaniem: a. urzdze mobilnych i sieci publicznej, b. urzdze stacjonarnych znajdujcych si w innych lokalizacjach Urzdu z wykorzystaniem sieci publicznej. 3. System musi umoliwia pracownikom zdalnym prac w trybie offline nad sprawami przez nich prowadzonymi, moliwo zapisu dokumentów oraz automatycznej synchronizacji po uzyskaniu dostpu przez uytkownika w trybie online. Praca offline pracowników zdalnych oznacza prac nad sprawami bez aktywnego połczenia z działajcym systemem, w tym take lokalne zapisywanie efektów tej pracy oraz automatyczne synchronizowanie zmian w momencie nawizania połczenia z systemem w trybie online. 5. Wymagania w zakresie obsługi interesantów (klientów zewntrznych) Urzdu 1. System musi posiada moliwo: a. kontroli przez klienta stanu realizacji sprawy na kadym etapie jej biegu (ledzenie toku sprawy) oraz szybkiego kontaktu z pracownikami Urzdu (w celu np. przekazania Strona 6/18

dodatkowych informacji niezbdnych do właciwego prowadzenia sprawy), b. monitorowania stanu sprawy po numerze z elektronicznego potwierdzenia złoenia wniosku, c. monitorowania danej sprawy wraz z nazwiskiem referenta / nr identyfikacyjnym referenta np. przez pracowników punktu informacyjnego, sekretariatu i innych pracowników Urzdu. d. rozbudowy o dodatkowe moduły oraz wprowadzania zmian. 2. Informacje o stanie realizacji spraw powinny by udostpniane np. w Biuletynie Informacji Publicznej. 6. Wymagania w zakresie systemu portalowego 1. Portal musi si składa z czci publicznej (widocznej w Internecie) oraz czci intranetowej (widocznej jedynie w danym Urzdzie i jego jednostkach terenowych) połczony w jedn logiczn cało. 2. System portalowy umoliwi musi: a. organizacj pracy grupowej, b. wspóln prac nad dokumentami z zachowaniem mechanizmów ich wersjonowania, c. publikacj dokumentów, d. podpisywanie dokumentów. 3. System portalowy zapewni musi: a. narzdzia umoliwiajce prost i intuicyjn publikacj treci w formacie HTML w trybie WYSIWYG, bez koniecznoci znajomoci jzyka HTML i innej wiedzy technicznej przez autorów treci, b. wersjonowanie treci stron portalu, działajce automatycznie przy wprowadzaniu kolejnych modyfikacji przez edytorów treci, c. zastosowanie procesów zatwierdzania zawartoci przed publikacj, tzn. moliwo zdefiniowania przynajmniej dwóch poziomów uprawnie edytorów (edytor i zatwierdzajcy), przy czym treci publikowane przez edytorów musz uzyska pozytywn akceptacj zatwierdzajcego przed udostpnieniem jej wszystkim uytkownikom portalu, d. moliwo budowania hierarchicznej struktury stron portalu z prostym przenoszeniem stron i sekcji w ramach struktury nawigacji, e. automatyczne tworzenie nawigacji na stronach portalu, odwzorowujce obecn hierarchi, f. automatyczne generowanie mapy stron portalu (breadcrump), g. moliwo zarzdzania poszczególnymi obszarami portalu osobom nietechnicznym, pełnicym rol edytorów bd administratorów merytorycznych, tak, by nie było konieczne angaowanie zespołu IT w proces zarzdzania treci portalu, h. definiowanie uprawnie uytkowników niezalenie do poszczególnych sekcji i stron portalu, zarówno uprawnie do odczytu zawartoci, jak i edycji oraz publikacji (róni edytorzy zawartoci portalu w zalenoci od jego czci). Definiowanie uprawnie powinno by dostpne dla administratorów merytorycznych poszczególnych obszarów Strona 7/18

portalu w sposób niezaleny od pracowników działu IT, i. automatyczne dołczanie do publikowanych stron informacji o autorze (edytorze) i dacie publikacji, j. moliwo personalizacji i filtrowania treci w portalu w zalenoci od roli lub innych atrybutów pracownika (np. stanowiska, komórki organizacyjnej), k. moliwo wykorzystania portalu, jako standardowego interfejsu uytkownika dla wszystkich posiadanych aplikacji składajcych si na System, l. mechanizmy wymiany danych z innymi systemami, w tym z centralnymi systemami administracji publicznej, 4. W zakresie mechanizmów wyszukiwania istnie musi: a. pełnotekstowe indeksowanie zawartoci intranetu w zakresie rónych typów treci publikowanych w portalu, tj. stron portalu, dokumentów tekstowych (w szczególnoci dokumentów XML), b. centralny mechanizm wyszukiwania treci dostpny dla uytkowników portalu, c. opcja wyszukiwania zaawansowanego, np. wyszukiwanie wg typów treci, autorów, dat publikacji, d. moliwo budowania wielu wyszukiwarek w rónych czciach portalu, słucych do przeszukiwania okrelonych obszarów portalu wg zadanych kryteriów, np. wg typów dokumentów, e. moliwo definiowania słownika słów wykluczonych (czsto uywanych), f. moliwo tworzenia linków sponsorowanych, prezentowanych wysoko w wynikach wyszukiwania w zalenoci od słów wpisanych w zapytaniu, g. podwietlanie w wynikach wyszukiwania odnalezionych słów kluczowych zadanych w zapytaniu, h. przedstawianie w wynikach duplikatów plików, i. statystyki wyszukiwanych fraz. 5. System portalowy musi by zintegrowany z widoczn na zewntrz internetow stron podmiotow (BIP) oraz stron WWW Urzdu. 6. Szata graficzna serwisu BIP musi spełnia standardy W3C, zachowujc formatowanie przyjte do publikacji serwisów BIP wg projektu ogólnopolskiej strony internetowej BIP www.bip.gov.pl. 7. Szablon stron bdzie zgodny z punktami kontrolnymi o priorytecie 1 i 2, okrelonymi w ramach Wytycznych dotyczcych Dostpnoci Treci Internetowych 1.0 (WCAG 1.0) Inicjatywy Dostpnoci do Sieci (WAI) opracowanej przez World Wide Web Consortium (W3C), 8. Zachowane bdzie wsparcie dla urzdze mobilnych (MDA, PDA, Tablet PC itp.), które mog obsługiwa strony WWW. 9. Obsługa informacji w BIP musi by zgodna z obowizujcymi w tym zakresie wymogami ustawowymi. 10. Dostp do intranetowego systemu portalowego dla uprawnionych pracowników Urzdu musi by moliwy lokalnie w Urzdzie oraz z dowolnego miejsca poprzez Internet. 11. System intranetowy nie moe by dostpny dla nieuprawnionych uytkowników. Strona 8/18

7. Wymagania w zakresie serwisu WWW i BIP 1. Wymagania ogólne: a. Wykonawca zapewni odpowiedni interfejs po stronie aplikacji i dostosuje rodowisko aplikacji do infrastruktury zapewnionej przez Urzd. b. rodowisko pracy: i. GIW: ii. WITD: iii. APKr: 1. System operacyjny serwera: Linux 2. Serwer WWW: Apache2 3. Oprogramowanie aplikacyjne: PHP5 4. Oprogramowanie bazodanowe: MySQL wersja 5. 1. System operacyjny serwera: MS Windows Server 2008 2. Serwer WWW: IIS 7.0 3. Oprogramowanie bazodanowe: MS SQL Server 2005 lub 2008 x64 1. System operacyjny serwera: Linux. 2. Serwer WWW: Apache2 3. Oprogramowanie aplikacyjne: PHP5 4. Oprogramowanie bazodanowe: MySQL wersja 5. c. Serwis ma mie budow modułow z moliwoci łatwej rozbudowy funkcjonalnej jak i ilociowej. d. Serwis ma zapewni: i. optymalizacj kodu pod ktem prdkoci wywietlania si strony (objtoci kodu), ii. optymalizacj kodu pod ktem wyszukiwania przez wyszukiwarki internetowe (metatagi, hierarchia nagłówków), iii. optymalizacj treci pod ktem przystpnoci dla uytkownika: uwypuklenie elementów istotnych, rozrónienie elementów odrbnych logicznie, iv. zgodno kodu z rekomendacj W3C HTML 4.01 oraz jego weryfikacj przy pomocy narzdzi udostpnionych przez W3C pod adresami http://validator.w3.org/ i http://jigsaw.w3.org/css-validator. e. Strona BIP musi spełnia wymagania rozporzdzenia regulujcego wymogi techniczne wobec stron Biuletynu informacji Publicznej. 2. Wygld serwisu: a. GIW: i. Punktem wyjcia dla projektu jest istniejca obecnie strona GIW (www.wetgiw.gov.pl). Przewiduje si jednak potrzeb przebudowy strony, aby zwikszy jej funkcjonalno i czytelno. Strona 9/18

b. WITD: c. APKr: ii. Wymagane jest opracowanie szaty graficznej strony, wersji angielskiej wybranych czci strony. Projekt ma uwzgldnia moliwo powikszenia zakresu witryny w przyszłoci, m.in. o dalsze wersje jzykowe. i. Serwis ma by zaprojektowany od podstaw i ma by zintegrowany ze stron BIP WITD. ii. Wymagane jest opracowanie strony w jzyku polskim oraz w wersjach jzykowych: angielskiej i niemieckiej. Projekt ma równie uwzgldnia moliwo powikszenia w przyszłoci zakresu serwisu m.in. o kolejne wersje jzykowe. i. Punktem wyjcia dla projektu jest istniejca obecnie strona APKr (www.archiwum.krakow.pl), z utrzymaniem podobnej tonacji kolorystycznej i ozdobnych elementów graficznych, nawizujcych do materiałów archiwalnych przechowywanych przez Urzd. Przewiduje si jednak potrzeb przebudowy mapy strony, aby zwikszy jej funkcjonalno i czytelno. ii. Wymagane jest opracowanie szaty graficznej strony dla osób niedowidzcych, wersji angielskiej. Projekt ma uwzgldnia moliwo powikszenia zakresu witryny w przyszłoci, m.in. o dalsze wersje jzykowe. iii. Zaprojektowanie architektury informacji wraz z klarown struktur serwisu zgodnie z ponisz list działów: Lp Menu główne Podmenu Podmenu II Informacje 1 inf. ogólne organizacja prawo komunikaty wydarzenia/kronika programy/projekty dzieje 2 Zasób archiwalny inf. ogólne bazy danych 3 Udostpnianie materiałów zasady czytelnie 4 archiwalnych Nadzór nad archiwami zakładowymi 5 Akta osobowe i płacowe Wystawy on-line 6 7 Odziały zamiejscowe i ekspozytury formularze inf. ogólne formularze Baza Nadzór ewentualny podział tematyczny wg wystaw Bochnia Nowy Targ Strona 10/18 inf. ogólne dzieje zasób nadzór archiwalny inf. ogólne dzieje

8 Wydawnictwa Edukacja, e-learning 9 Nowy Scz Tarnów Nowy Targ Spytkowice Kursy i szkolenia Edukacja zasób nadzór archiwalny inf. ogólne dzieje zasób nadzór archiwalny inf. ogólne dzieje zasób nadzór archiwalny inf. ogólne inf. ogólne lekcje historii, pokazy edukacja w sieci (e-learning) 10 Cennik 11 Jak załatwi spraw 12 Zamówienia publiczne 13 Kontakt 14 Ciekawe miejsca w sieci 15 Mapa strony 3. Projekt graficzny musi łczy w cało róne elementy strony (aktualnoci, artykuły, galerie, materiały multimedialne, sekcj download, stałe informacje itp.), ma by charakterystyczny i łatwo rozpoznawalny. 4. Nazwa serwisu WWW Urzdu ma by zaprojektowana w formie logotypu, który bdzie rozpowszechniany równie poza serwisem. 5. Serwis ma posiada uyteczn i intuicyjn typografi. 6. Serwis ma posiada do 5 formularzy zintegrowanych ze stron słucych wysłaniu okrelonych informacji przez internautów do Urzdu. 7. Najwaniejsze funkcje dostpne dla uytkownika maj by udostpnione za pomoc unikatowej i oryginalnej ikonografii. 8. Wykonawca, przedstawi projekt graficzny strony głównej serwisu w wersji polskiej, projekt ten po akceptacji, bd wniesionych przez Urzd uwagach zostanie zmodyfikowany i wdroony. Urzd udostpni pliki graficzne ze swojego zasobu do przygotowania graficznego projektu strony. 9. Funkcjonalno strony serwisu WWW: a. Szablon stron bdzie zgodny z punktami kontrolnymi o priorytecie 1 i 2, okrelonymi w ramach Wytycznych dotyczcych Dostpnoci Treci Internetowych 1.0 (WCAG 1.0) Inicjatywy Dostpnoci do Sieci (WAI) opracowanej przez World Wide Web Consortium (W3C). Strona ma si charakteryzowa zminimalizowanym czasem załadowania. b. Serwis ma zapewni obsług przegldarek zgodnie z zapisami Załcznika Nr 2 Wymagania niefunkcjonalne. c. Serwis ma działa niezawodnie w stosowanych powszechnie systemach operacyjnych (oraz starszych wersjach). Strona 11/18

d. Serwis ma by zoptymalizowany do rozdzielczoci 1024x728, brak skalowania w przypadku gdy uytkownik uywa wikszej rozdzielczoci. e. Sewris ma zapewni kodowanie polskich znaków wg standardu UTF-8. f. Z poziomu czytelnika publikowanych w formie artykułu treci ma by moliwo: i. zmiany wielkoci tekstu (pomniejszenie/powikszenie czcionki), ii. wydruku, iii. wygenerowania pliku pdf z moliwoci zapisania na dysku komputera, iv. cignicia pliku do pobrania, jeeli jest załczony do artykułu, v. wysłania treci e-mailem w formie funkcji Wylij znajomym wysyłanie do znajomego bezporednio ze stron WWW, rekomendacji z informacj o istnieniu danej podstrony. g. Serwis ma zapewni zastosowanie przyjaznych linków, które maj ułatwi uytkownikom odnalezienie si w serwisie, jak równie posługiwanie si linkami, np. www.nazwa.gov.pl/praca/oferta/ h. Administrator ma mie moliwo przeszukiwania zawartoci systemu według rónych kryteriów: nazwy pliku, tytułu, daty, godziny, ID artykułu i. Serwis ma zapewni istnienie wyszukiwarki umoliwiajcej Uytkownikowi przeszukiwanie serwisu zarówno proste, jak i zaawansowane z uwzgldnieniem operatorów logicznych OR i AND, wyszukiwania dokładnego wyraenia ujtego w cudzysłów, nieuwzgldniania wielkoci liter w szukanym wyraeniu. j. Serwis ma zapewni moliwo wysyłania newsletter a/biuletynu zarówno w formacie HTML jak i PDF do wydruku. k. Serwis ma zapewni mechanizm umoliwiajcy wywietlenie zaprojektowanej przez Wykonawc informacji o czasowej niedostpnoci serwisu z powodów technicznych oraz uwzgldnienie moliwoci zdefiniowania własnej informacji. l. Serwis ma zapewni automatyczne tworzenie mapy serwisu. m. Serwis ma zapewni mechanizm automatycznej archiwizacji dokumentów z okrelonym czasem publikacji i moliwoci korzystania z archiwum. Administrator ma mie moliwo decyzji (oraz jej zmiany) dotyczcej przedłuenia czasu publikacji, automatycznej archiwizacji lub usunicia artykułów. n. Serwis ma zapewni odtwarzanie elementów multimedialnych z poziomu strony odtwarzacz audio i video (wykorzystywany okazjonalnie, domylne pliki wideo bd przechowywane na kanale Youtube albo na innym serwerze) oraz aplikacja do przegldania obrazów cyfrowych i prezentacji. o. Serwis ma zapewni moliwo wykorzystania na stronie interaktywnego mechanizmu geolokalizacji (np. Google maps, www.zumi.pl) umoliwiajcego lokalizacj dowolnych obiektów oraz zajmowanych przez Urzd. 10. Narzdzia administracyjne systemu CMS: a. Panel Administracyjny i dokumentacja maj by w jzyku polskim. b. System ma realizowa swoje zadania przy uyciu przyjaznego i łatwego w obsłudze interfejsu. Strona 12/18

c. System CMS ma by przystosowany do obsługiwania nieograniczonej iloci nazwanych uytkowników, czyli odrbnych kont w systemie. d. Narzdzia administracyjne maj by dostosowane do specyfiki i potrzeb serwisu oraz wymaga Urzdu, a najczciej powtarzane czynnoci administracyjne powinny by zautomatyzowane. Maj te umoliwia dalsz rozbudow serwisu po zakoczeniu prac nad wdroeniem bdcym przedmiotem umowy midzy stronami. e. Nawigacja z poziomu administratora ma bazowa na widoku strony, a nie wyłcznie na strukturze drzewiastej. f. Publikacja materiału (artykułu, galerii jak i nowej zawartoci w menu) na stronie bdzie moliwa w maksymalnie 12 klikni od zalogowania. g. Czas od publikacji zmian do ich uwidocznienia na stronie nie moe przekroczy 2 minut. h. Moliwo podgldu zdj oraz wygldu edytowanych stron przed ich opublikowaniem. i. Moliwo zmiany koncepcji graficznej strony poprzez wprowadzanie do systemu szablonów graficznych, przy czym CMS nie powinien narzuca adnych ogranicze kompozycyjnych. j. Moliwo tworzenia szablonów stron w zakresie strukturalnym, tj. rozmieszczenie poszczególnych elementów na stronie oraz w zakresie graficznym, tj. odpowiednie uporzdkowanie obiektów graficznych na stronie (obsługa tworzenia szablonu moe zakłada pewien poziom wiedzy informatycznej Administratora Systemu), k. Tworzenie i zarzdzanie repozytorium plików dostp do plików umieszczanych na stronie WWW, tj. moliwo dodawania nowych, usuwania zbdnych plików, ukrywania, a take podmiany plików, które powinny by gromadzone w sposób pozwalajcy na swobodne ich przegldanie, katalogowanie i sortowanie, l. Wstawianie czystego kodu HTML: i. wstawianie i edycja tekstu, ii. wstawianie i edycja tabel, iii. dodawanie plików i obiektów z prezentacjami przygotowanymi z wykorzystaniem technologii Flash (z moliwoci definiowania ich wywietlania), iv. dodawanie oraz prezentacja zdj i plików multimedialnych. m. Moduł edycyjny ma umoliwia, co najmniej: i. dodawanie, zmian lub usuwanie elementów treci strony, ii. pogrubienie, pochylenie i podkrelenie tekstu, iii. zmian wielkoci, koloru i kroju czcionki, iv. zmian wielkoci interlinii, v. wyrodkowanie, wyjustowanie, wyrównanie do prawej lub lewej strony, vi. wklejenie bez formatowania, vii. stworzenie listy numerowanej i punktowanej, viii. cofnicie ostatniej operacji, ix. wstawienie, edycj i usunicie hiperłcza, Strona 13/18

x. wstawienie w tekst grafiki, moliwo ustawienia jej wzgldem tekstu, xi. wstawienie linii poziomej i ustalenie jej właciwoci (gruboci, koloru, stylu), xii. wstawienie tekstu w formie indeksu górnego lub dolnego, xiii. wyszukanie w tekcie, xiv. edycj w ródle dokumentu, xv. wstawianie elementów zewntrznych (np. aplikacji do przegldania obrazów cyfrowych i prezentacji, odtwarzacz audio video, Youtube). n. Przyznawanie uprawnie dostpu na zrónicowanych poziomach: i. Administratora systemu CMS osob odpowiedzialn za zarzdzanie całym systemem, w tym tworzenie, edytowanie, usuwanie, publikowanie treci, grafik, załczników, działów, podstron, dodawanie i usuwanie uytkowników i nadawanie im praw dostpu, ii. Redaktora osob odpowiedzialn za tworzenie, edytowanie, usuwanie, publikowanie treci, grafik, załczników, iii. Edytora osob odpowiedzialn za tworzenie, edytowanie, usuwanie, grafik, załczników bez prawa ich publikacji, iv. Czytelnika osob majc dostp po autoryzacji do przegldania wszystkich artykułów (łcznie z sekcjami ukrytymi) bez moliwoci ich edycji i publikacji v. Gocia - osob majc dostp bez autoryzacji do przegldania wszystkich artykułów bez moliwoci ich edycji i publikacji (bez sekcji ukrytych) o. Dostp do Panelu Administracyjnego z poziomu przegldarki internetowej (w tym obsługa rónych przegldarek internetowych). p. Moliwo bezpiecznej autoryzacji osób uprawnionych, logujcych si do niego przy pomocy przegldarki internetowej. q. Moliwo równoczesnej obsługi przez minimum trzy osoby. r. Blokowanie moliwoci edycji fragmentu danej strony w czasie, kiedy inna osob ju j edytuje. s. Obsługa wersjonowania kady tekst na poziomie administracyjnym powinien zawiera informacje o osobie, czasie i zmianach wprowadzonych w tekcie. Z poziomu czytelnika serwisu ma by widoczna tylko informacja o ostatniej aktualizacji. t. Opcja samodzielnego tworzenia działów i struktury serwisu oraz zmiany kolejnoci wywietlania działów w menu. Ma te istnie moliwo ukrycia działu tak, eby istniał w strukturze, ale nie był widoczny na stronie. u. Opcja ustawienia kolejnoci wywietlania tekstów na stronie. v. System ma automatycznie zmienia rozmiar zdj do miniatury przy minimalnej (niewidocznej dla uytkownika) stracie jakoci. w. System ma mie moliwo kadrowania edytowanego zdjcia po wgraniu dowolnego zdjcia system umoliwia wybranie kadru, a nastpnie zmienia rozmiar do formatu zdefiniowanego w layoucie strony x. Moliwo tworzenia statystyk: jako narzdzie statystyczne system moe wykorzystywa bezpłatne usługi np. Google Analytics. Tworzenie statystyk zarówno dla całej strony Strona 14/18

WWW, jak i poszczególnych jej działów i podstron powinno zawiera informacje o aktywnoci zewntrznej i wewntrznej, w szczególnoci: i. Aktywno zewntrzna: 1. ilo wej na stronie, 2. ilo indywidualnych uytkowników, 3. rodzaj uywanej przegldarki, 4. lokalizacja uytkowników na podstawie adresu IP, 5. inne. ii. Aktywno wewntrzna dane dotyczce aktywnoci administratorów i redaktorów oraz innych osób z zespołu redaktorskiego (kada strona powinna mie swoj histori edycji). y. Naley przewidzie moliwo wygenerowania zestawienia statystycznego dla wybranego okresu: dzie, tydzie, miesic, rok. z. Automatyczne udostpnianie strony WWW w wersji angielskiej jeli internauta wchodzi na stron spoza terenu Polski na podstawie numerów IP. aa. Publikowanie treci o zadanej wczeniej dacie i godzinie. bb. Po dodaniu pliku audiowizualnego do artykułu bdzie si on wywietlał na stronie w postaci playera lub jako plik do pobrania. cc. Moliwo dodania jako plik do pobrania dokumentów w formatach: DOC, XLS, RTF, TXT, PDF, PPS, MP3, WMV, AVI, MPEG, GIF, JPG oraz pochodnych. dd. Inne dodatkowe elementy w ramach aplikacji, jeli Wykonawca uzna, e ich wprowadzenie jest konieczne do sprawnego uytkowania systemu zarzdzania treci lub e ich wprowadzenie wzbogaci ofert serwisu. ee. Moliwo samodzielnej wymiany banerów przez redaktora na poziomie CMS. ff. CMS ma korzysta z modułu o funkcjonalnoci URL Rewriter. gg. Niezawodny, automatyczny system archiwizowania strony WWW wraz z opublikowanymi informacjami i udostpnionymi za jej porednictwem plikami oraz tworzenia kopii na nonikach zewntrznych. hh. Niezawodny, automatyczny system archiwizowania serwisu WWW wraz z opublikowanymi informacjami i udostpnionymi za jej porednictwem plikami oraz tworzenia kopii na nonikach zewntrznych. 11. Bezpieczestwo: a. Bezpieczestwo funkcjonowania systemu zapewnione zostanie przez logowanie, ochron danych, hierarchizacj dostpu, hierarchi uprawnie, szyfrowanie, ochron danych osobowych w przypadku stworzenia elektronicznych biuletynów informacyjnych (newsletter a). System zapewni niezbdne zabezpieczenia przed nieuprawnionymi zmianami na stronach, przekierowaniami, atakami oraz zapewni zabezpieczenie danym znajdujcym si na serwerze przed moliwoci wykradzenia. Zapewni moliwo bezpiecznej autoryzacji osób uprawnionych, logujcych si do niego przy pomocy przegldarki internetowej. b. Wymagania szczegółowe: Strona 15/18

12. Prawa autorskie: i. Dostp poprzez szyfrowane połczenie SSL. ii. Zapewnienie obsługi certyfikatów dostpnych dla przegldarek, w tym X.509 V3. iii. Zapewniona moliwo wyboru poziomu bezpieczestwa haseł wykorzystywanych przez uytkowników za pomoc: 1. wymuszanie minimalnej długoci hasła, 2. wymuszanie uywania silnych haseł (hasła odporne na typowe ataki np. atak słownikowy), 3. wymuszanie czasu ycia hasła, 4. automatycznego blokowania konta po ustalonej iloci nieudanych prób logowania (email z informacj o zdarzeniu do administratora oraz uytkownika którego dotyczy), 5. zabezpieczenie CAPCHA przy logowaniu. iv. System bdzie posiadał rejestr wszystkich prób uwierzytelnienia, w którym bd gromadzone i przechowywane ponisze informacje: 1. pełna data z godzin, 2. nazwa konta, które zostało poddane uwierzytelnieniu, 3. adres IP, z którego wykonywane było uwierzytelnienie, 4. nazwa domenowa adresu, z którego wykonywane było uwierzytelnienie, 5. rezultat uwierzytelnienia (powodzenie/niepowodzenie). 6. System bdzie posiadał rejestr modyfikacji (z opcj segregowania według daty i godziny, uytkowników, rodzaju operacji itd.) dowolnej strony serwisu WWW od momentu wprowadzenia jej do systemu, w którym bd gromadzone i przechowywane, co najmniej ponisze informacje: 7. pełna data z godzin modyfikacji, 8. wszystkie operacje przeprowadzone na elementach strony, 9. nazwa uytkownika, który dokonał zmian, 10. krótki opis operacji (np. publikowanie, modyfikacja, cofanie publikacji, itp.). v. System bdzie zabezpieczony w sposób, który zwiksza jego odporno na róne rodzaje ataków, ze szczególnym uwzgldnieniem ataków SQL Injections, Crosssite scripting (XSS) i Cross Site Request Forgery (CSRF). a. Prawa autorskie do serwisu, dokumentacji oraz licencje CMS i cało zastosowanego oprogramowania (równie zainstalowanego na serwerze na potrzeby rozwizania) zostanie przekazana na Urzd. Szczegóły zostan uwzgldnione w umowie midzy stronami. b. Wykonawca wyrazi zgod i zobowie si wzgldem zamawiajcego do ograniczenia korzystania z przyznanych mu, na mocy art. 16 ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych, autorskich praw osobistych do autorstwa dzieła, w szczególnoci poprzez nieujawnienie swojego autorstwa na wykonanym i udostpnionym Strona 16/18

osobom trzecim utworze. 8. Wymagania w zakresie obiegu umów i dokumentów ksigowych 1. System zapewni musi: a. przyjcie i rejestracj dokumentu ksigowego, b. wstpn weryfikacj przez właciw komórk, c. zatwierdzenie merytoryczne: i. opis faktury (właciwy pracownik), ii. zatwierdzenie (wewntrzn właciwy pracownik / osoba koordynujca proces wydatków w jednostce wewntrznej), iii. weryfikacj pod wzgldem finansowo-ksigowym, iv. zatwierdzenie (Dyrektor Urzdu), v. opłat obsług i rejestracj informacji o płatnoci. 9. Wymagania w zakresie obsługi archiwum zakładowego 1. System musi posiada moduł zapewniajcy funkcjonowanie archiwum zakładowego (obsługa: przekazywania dokumentacji przez komórki organizacyjne do archiwum zakładowego, wypoyczania dokumentów, brakowania, wycofywania dokumentacji itd.), w tym: a. moliwo prowadzenia wszystkich form ewidencji wymaganych przez obowizujce przepisy (np. wykaz spisów zdawczo-odbiorczych, rejestr udostpniania, procedura brakowania, przekazywania materiałów archiwalnych do archiwum pastwowego), b. automatyczne tworzenie spisów zdawczo-odbiorczych z prowadzonych przez poszczególnych referentów spisów spraw, c. moliwo przekazywania dokumentacji poszczególnych stanowisk w działach, d. moliwo nadzorowania przez archiwist zakładowego spisów zdawczo-odbiorczych na etapie ich tworzenia wraz z moliwoci dodawania uwag, e. moliwo przekazania paczki archiwalnej do ADE (wraz z prezentacj moliwoci systemu na przykładowej paczce archiwum wygenerowanej przez System), f. moliwo zamawiania materiałów do wypoyczenia, wypoyczania on-line, rejestracja wypoycze, wgldu do akt, g. moliwo edytowania istniejcych spisów zdawczo-odbiorczych, spisów dokumentacji przeznaczonej do zniszczenia, spisów materiałów archiwalnych przekazywanych do archiwum pastwowego i innej ewidencji, h. moliwo tworzenia i dodawania spisów zdawczo-odbiorczych dokumentacji, która nie została wprowadzona do systemu. 10. Wymagania w zakresie współpracy z Elektroniczn Skrzynk Podawcz Urzdu oraz epuap 1. System musi zapewni składanie pism i wniosków w formie elektronicznej (za porednictwem aktywnych formularzy), opatrzonych podpisem elektronicznym kwalifikowanym lub niekwalifikowanym z wykorzystaniem: a. GIW: platformy epuap, b. WITD: platformy epuap, c. APKr: platformy epuap oraz portalu Wrota Małopolski. Strona 17/18

2. System musi zawiera repozytorium elektronicznych formularzy, zgodnych w formie i kształcie z formularzami udostpnianymi i przyjmowanymi przez Urzd w wersji papierowej, umoliwiajce wybór właciwego formularza w celu złoenia dokumentu do Urzdu w wersji elektronicznej. Zamawiajcy akceptuje moliwo wykorzystania epuap w zakresie repozytorium 3. System musi przeprowadza walidacj danych podawanych przez interesanta podczas wypełniania elektronicznych formularzy w celu zagwarantowania poprawnoci oraz kompletnoci wprowadzonych danych. 4. Na podstawie poprawnie wypełnionego elektronicznego formularza, system musi generowa dokument w formacie PDF, umoliwia drukowanie i zapisanie go na dysku lokalnym. 5. Przewiduje si kilka podstawowych scenariuszy, w których bd wykorzystywane interfejsy do systemu epuap: a. przesłanie formularza elektronicznego z systemu epuap do Urzdu, b. przesłanie formularza elektronicznego z Urzdu do epuap, c. wykorzystanie usług infrastrukturalnych epuap w tym np. do obsługi formularza/dokumentu, d. autoryzacja uytkownika, e. rejestracja/modyfikacja usługi, f. utworzenie/modyfikacja profilu Urzdu, g. dostp do danych rejestrów centralnych. Strona 18/18