wymagania - stat.gov.pl file · Web viewsprawa numer: 59/SISP/PN/2011. WYMAGANIA FUNKCJONALNE I...

Załącznik nr 4 do SIWZsprawa numer: 59/SISP/PN/2011

WYMAGANIA FUNKCJONALNE I NIEFUNKCJONALNE

1 WYMAGANIA FUNKCJONALNE...............................................................................................4

1.1 WYMAGANIA OGÓLNE...............................................................................................41.2 ZARZĄDZANIE UPRAWNIENIAMI................................................................................71.3 ARCHITEKTURA SYSTEMU..........................................................................................91.4 INTERFEJS UŻYTKOWNIKA.......................................................................................11

1.4.1 Funkcjonalność interfejsu.................................................................................111.4.2 Potwierdzenia informacyjne..............................................................................151.4.3 Elastyczność i kontrola użytkownika.................................................................161.4.4 Zapobieganie i kontrola błędów........................................................................181.4.5 Klarowność wizualna........................................................................................181.4.6 Przejrzystość sytemu.........................................................................................191.4.7 Prowadzenie i wsparcie użytkownika................................................................20

1.5 ADMINISTROWANIE..................................................................................................201.6 ZARZĄDZANIE PROCESAMI PRACY...........................................................................22

1.6.1 Wymagania ogólne............................................................................................221.6.2 Zarządzanie procesami.....................................................................................241.6.3 Portal procesów................................................................................................251.6.4 Wymagania szczegółowe...................................................................................26

1.6.4.1 Mapowanie/Modelowanie procesów.............................................................26

1.6.4.2 Publikacja......................................................................................................32

1.6.4.3 Analiza procesów..........................................................................................33

1.6.4.4 Zarządzanie procesami..................................................................................33

1.6.4.5 Inne wymagania............................................................................................351.7 DOSTOSOWYWANIE SYSTEMU..................................................................................35

1.7.1 Projektowanie szablonów dokumentów i spraw................................................351.7.2 Projektowanie rejestrów...................................................................................381.7.3 Projektowanie szablonów stron........................................................................401.7.4 Projektowanie formularzy elektronicznych.......................................................41

1.8 PRZECHOWYWANIE I ANALIZA DANYCH..................................................................451.8.1 Kontrola i wersjonowanie.................................................................................451.8.2 Tworzenie raportów..........................................................................................481.8.3 Wyszukiwanie....................................................................................................511.8.4 Indywidualny kalendarz pracownika................................................................53

Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego oraz ze środków budżetu państwa.

7. Oś Priorytetowa: Społeczeństwo informacyjne – budowa elektronicznej administracji

str. 1

1.9 PORTAL KORPORACYJNY.........................................................................................561.9.1 Wygląd i logika działania..................................................................................561.9.2 Publikowanie i zarządzanie treścią...................................................................581.9.3 Repozytorium dokumentów portalu Korporacyjnego.......................................611.9.4 Praca grupowa..................................................................................................651.9.5 Praca offline......................................................................................................681.9.6 Książka adresowa pracowników.......................................................................68

1.10 PRACA Z PISMAMI, ZADANIAMI I SPRAWAMI...........................................................691.10.1Ogólne...............................................................................................................691.10.2Skanowanie pism...............................................................................................701.10.3Rejestracja dokumentów wpływających............................................................721.10.4Tworzenie pism..................................................................................................741.10.5Edytor pism.......................................................................................................761.10.6Rejestrowanie dokumentów w komórkach merytorycznych. Teczki spraw.

Rejestry..............................................................................................................761.10.7Prezentowanie pism i spraw..............................................................................781.10.8Wyszukiwanie pism i spraw...............................................................................811.10.9Drukowanie dokumentów..................................................................................831.10.10 Wysyłka pism...............................................................................................841.10.11 Procesy przepływów pracy..........................................................................851.10.12 Podpis elektroniczny....................................................................................89

1.11 MODUŁ ELEKTRONICZNEJ SKRZYNKI PODAWCZEJ (ESP)..........................................901.12 ELEKTRONICZNE ARCHIWUM...................................................................................911.13 DODATKOWE KOMPONENTY....................................................................................97

1.13.1Moduł struktury organizacyjnej........................................................................971.13.2Moduł rezerwacji zasobów..............................................................................101

1.14 WYMAGANIA SZCZEGÓŁOWE DLA PROCESÓW.......................................................1031.14.1Pytanie do GUS...............................................................................................1031.14.2Udostępnianie danych statystycznych.............................................................1041.14.3Wymagania ogólne dla procesów związanych z dyscypliną pracy.................1071.14.4Proces delegacji..............................................................................................1081.14.5Obsługa wniosku urlopowego.........................................................................1091.14.6Zgłaszanie uwag do Projektu Badań Statystycznych Statystyki Publicznej....1111.14.7Raporty z przebiegu badań..............................................................................1131.14.8Opracowywanie wzorów formularzy statystycznych.......................................114

1.15 INTEGRACJA...........................................................................................................1171.15.1ePUAP.............................................................................................................1171.15.2Exchange.........................................................................................................1171.15.3Broker Komunikacyjny....................................................................................118



str. 2

1.15.3.1 Interfejsy..................................................................................................118

1.15.3.2 Usługi (WebServices)..............................................................................118

1.15.3.3 Tabele interfejsowe w bazie danych.......................................................119

1.15.3.4 Pliki XML...............................................................................................1201.15.4System SOFTUS..............................................................................................1211.15.5Unified Communication..................................................................................1211.15.6System Edukacyjny..........................................................................................1211.15.7Portal informacyjny GUS................................................................................122

1.16 PODPIS ELEKTRONICZNY........................................................................................1221.16.1Weryfikacja podpisu elektronicznego..............................................................1221.16.2Podpisywanie..................................................................................................1241.16.3Budowa wewnętrznego serwera znakowania czasem.....................................1271.16.4Sprzętowy Moduł Kryptograficzny (Hardware Security Module)...................128

2 WYMAGANIA NIEFUNKCJONALNE...................................................................................130

2.1 WYMAGANIA OGÓLNE...........................................................................................1302.2 UŻYWALNOŚĆ/ERGONOMIA...................................................................................1322.3 BEZPIECZEŃSTWO..................................................................................................1332.4 SKALOWALNOŚĆ I WYDAJNOŚĆ.............................................................................1362.5 INTEROPERACYJNOŚĆ.............................................................................................1362.6 NIEZAWODNOŚĆ.....................................................................................................1372.7 ŁATWOŚĆ PIELĘGNACJI..........................................................................................1382.8 Standardy...............................................................................................................138



str. 3

1 WYMAGANIA FUNKCJONALNE

1.1 WYMAGANIA OGÓLNE

F01.01.001. Rozbudowywany System Informacyjny Intranet (zwany dalej

System) musi spełniać wymogi prawne określone w Załączniku nr

11 – Lista aktów prawnych.

F01.01.002. Wszystkie elementy systemu (z wyjątkiem oprogramowania

dodatkowego oraz komunikatów np. dla administratorów czy

deweloperów) muszą posiadać interfejs w języku polskim. W języku

polskim muszą być wyświetlane wszystkie komunikaty,

powiadomienia i alerty przekazywane użytkownikom przez system,

w tym także wysyłane przy użyciu poczty e-mail. Wszystkie te

elementy muszą być zgodne z regułami poprawności językowej.

F01.01.003. System musi tworzyć automatyczną logiczną nawigację.

F01.01.004. Oferowane rozwiązanie musi umożliwiać tworzenie kopii

zapasowych, a ich wykonywanie nie może wpływać negatywnie na

sprawne funkcjonowanie systemu.

F02.01.001. System w momencie odbioru końcowego będzie w pełni

skonfigurowany, a więc przygotowany do realizacji wszystkich

wymaganych funkcjonalności.

F02.01.002. System będzie kompleksowy, czyli realizujący w momencie odbioru

końcowego wszystkie funkcje i czynności wymagane przez

Zamawiającego.

F02.01.003. System będzie kompatybilny wewnętrznie - poszczególne elementy

systemu muszą poprawnie współpracować w ramach systemu.

F02.01.004. Dostarczony sprzęt i oprogramowanie wyspecyfikowane

asortymentowo i ilościowo musi być kompletne, posiadać wszelkie

wymagane instrukcje, gwarancje i licencje.

F02.01.005. System będzie cechował się wysoką wydajnością i dostępnością Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju

Regionalnego oraz ze środków budżetu państwa. 7. Oś Priorytetowa: Społeczeństwo informacyjne – budowa elektronicznej administracji

str. 4

usług, przy czym pod pojęciem wydajności rozumiemy zapewnienie

nieprzerwanej pracy urządzeń i systemów na potrzeby środowiska

produkcyjnego. Ma zapobiec utracie danych w wyniku:

a) błędów oprogramowania,

b) defektów produkcyjnych,

c) awarii sprzętowych,

d) błędów człowieka,

e) innych nieprzewidzianych wydarzeń.

F02.01.006. System dotyczył będzie tylko i wyłącznie obiegu pism jawnych,

nieoznaczonych żadną z klauzul w obszarze dokumentów

niejawnych.

F02.01.007. System po stronie użytkownika musi wykorzystywać standard

aplikacyjny przyjęty u Zamawiającego, tzn. system Windows XP,

Vista, 7 zainstalowany na stacjach roboczych wraz z pakietem

biurowym MS Office 2003/2007.2010 oraz z wchodzącymi w jego

skład aplikacjami: MS Word, MS Excel, MS Outlook, MS

PowerPoint.

F02.01.008. System zapewni możliwość rozbudowy o kolejne serwery usług,

przy zachowaniu odpowiedniej jakości i wydajnej synchronizacji

danych pomiędzy poszczególnymi serwerami.

F02.01.009. Autoryzacja użytkowników musi być zintegrowana z usługą

katalogową MS Active Directory, na której opiera się środowisko

informatyczne Zamawiającego – użytkownik raz zalogowany

z poziomu systemu operacyjnego stacji roboczej ma być

automatycznie rozpoznawany we wszystkich modułach

oferowanego rozwiązania bez potrzeby oddzielnego monitowania

go o ponowne uwierzytelnienie się.

F02.01.010. Interfejs użytkownika musi posiadać standardowe cechy aplikacji

webowej. Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 5

F02.01.011. System musi cechować prostota i intuicyjność obsługi, pozwalające

na pracę w systemie osobom nie posiadającym umiejętności

technicznych, musi też wykorzystywać mechanizmy znane

użytkownikom pakietu biurowego MS Office – jako standardu

aplikacji biurowych Zamawiającego.

F02.01.012. System będzie nowoczesny i zgodny ze stosowanymi na dzień

zawarcia umowy uznanymi na rynku standardami technicznymi

w zakresie dostarczanego sprzętu, oprogramowania a także

przyjętych rozwiązań oraz gwarantujący Zamawiającemu możliwość

jego dalszej rozbudowy i unowocześnienia. Oznacza to

w szczególności, iż musi być zbudowany za pomocą narzędzi

umożliwiających Zamawiającemu samodzielny rozwój aplikacji.

F02.01.013. System będzie posiadał możliwość rozwoju przez Zamawiającego,

w oparciu o dostarczone w ramach jego budowy narzędzia oraz

wygodną implementację procesów przewidzianych do wdrożenia

w terminie późniejszym.

F02.01.014. System zapewni spójność słowników używanych przez system.

F02.01.015. Dostawca musi utworzyć ontologię Systemu Elektronicznego

Obiegu Dokumentów.

a) dane pracowników,

b) opis struktury organizacyjnej urzędu,

c) powiązania pomiędzy typami spraw oraz jednostkami

organizacyjnymi i pracownikami,

d) dane kontaktowe osób i instytucji współpracujących w tym ich

adresy Elektronicznych Skrzynek Podawczych,

e) rejestry, do których prowadzenia Urząd jest zobowiązany

zgodnie z obowiązującym prawem.

F02.01.017. W Systemie SII zdefiniowane muszą zostać w warstwie obiektów

biznesowych klasy takie jak przełożony, pracownik, sprawa,

dokument, jednostka organizacyjna wraz z atrybutami je



str. 6

opisującym.

F02.01.018. Wykonawca zapewni wszelkie niezbędne komponenty sprzętowo-

programowe do obsługi serwera faksów, adekwatne do rozwiązania

zaproponowanego przez wykonawcę do realizacji budowy systemu

SII. Serwer faksów musi być zintegrowany z systemem SII

w zakresie możliwości wysłania i odbierania dokumentów ze

stanowisk pracy. W chwili obecnej w głównej siedzibie

Zamawiającego zarówno linie cyfrowe w ilości ok. 1200 sztuk, jak i

linie analogowe ok. 50 sztyk oparte są o urządzenie Siemens

HiPath 4000 wersja 5.0. Sieć telekomunikacyjna jest oddzielona od

sieci LAN.

1.2 ZARZĄDZANIE UPRAWNIENIAMI

F01.02.001. Dla Systemu muszą być dostarczone mechanizmy kontroli dostępu

administratorów umożliwiające dostęp do systemu wyłącznie po

jednoznacznym zidentyfikowaniu przeprowadzonym w ramach

procesu uwierzytelnienia.

F01.02.002. System powinien zapewniać odpowiednie mechanizmy

uwierzytelniania użytkowników nie anonimowych.

F01.02.003. System powinien zapewniać odpowiednie zabezpieczenia przed

nieautoryzowanym dostępem na poziomie wszystkich

komponentów serwera (system operacyjny, motory baz danych,

serwery aplikacyjne, serwery WWW i inne, jeśli zostaną

zastosowane).

F01.02.004. System powinien przechowywać i przesyłać występujące hasła

użytkowników wyłącznie w postaci zabezpieczonej.

F01.02.005. System powinien zapewniać mechanizmy kontroli uprawnień oparte

na rolach, umożliwiające kontrolę poziomu dostępu każdego

użytkownika zarówno w zakresie dostępu do danych

przetwarzanych, jak i korzystania z jego funkcjonalności. System

uprawnień musi umożliwić ograniczenie dostępu wyłącznie do Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 7

takich danych oraz takiego zakresu funkcji, jaki jest niezbędny

użytkownikowi.

F01.02.006. System powinien posiadać mechanizmy umożliwiające

rozliczalność działań użytkowników systemowych i nie

anonimowych.

F01.02.007. System powinien umożliwiać podział użytkowników na grupy

z możliwością przynależenia do kilku grup równocześnie.

F01.02.008. System powinien umożliwiać zarządzanie użytkownikami oraz

grupami w zakresie ustalania uprawnień.

F01.02.009. System powinien umożliwiać blokowanie dostępu określonym

grupom użytkowników do zdefiniowanych zasobów systemu.

F01.02.010. Wykonawca w celu zarządzania uprawnieniami dostępu do systemu

wykorzysta funkcjonujący u Zamawiającego system zarządzania

tożsamością użytkowników i rolami bazujący na rozwiązaniu

QuestOne firmy Quest Software, składające się z Quest Active

Roles Server, Quest ActiveRoles Quick Connect forBase Systems

oraz Quest ActiveRoles Self Service Manager.

F01.02.011. Aby system mógł być zintegrowany z systemem IDM musi spełniać

następujące wymagania:

a) system musi być zintegrowany z katalogiem korporacyjnym

Active Directory i wykorzystywać mechanizm uwierzytelnia

Windows,

b) role użytkowników integrowanego systemu muszą być

zbudowane na zasadzie wykorzystania grup użytkowników

z Active Directory. Przypisanie użytkownika do grupy w AD

będzie skutkowało automatycznym dodaniem użytkownika do

określonej roli w systemie.

F01.02.012. Dla aplikacji wykorzystujących Sharepoint musi być zapewniona

możliwość natywnego podłączenia (otwarte porty komunikacyjne)

MS Sharepoint z serwerem IDM (modułem propagacji uprawnień).



str. 8

F01.02.013. Dla aplikacji wykorzystujących Sharepoint musi zostać zdefiniowane

konto administracyjne, które ma możliwość podpięcia się do

SharePoint i zarządzania członkostwem grup lokalnych SharePoint.

F01.02.014. System musi oferować usługę, która umożliwi zarządzanie w prosty

sposób uprawnieniami do obiektów w szczególności:

a) backupowanie uprawnień,

b) przywracanie uprawnień na obiektach,

c) raportowanie zmian w uprawnieniach,

d) klonowanie uprawnień,

e) tworzenie uprawnień,

f) podmiana uprawnień,

g) wyłączanie dziedziczenia uprawnień,

h) wyszukiwanie uprawnień.

F01.02.015. System musi umożliwiać tworzenie raportów z uprawnień

użytkownika/ grup w tym do poszczególnych obiektów.

F01.02.016. System musi umożliwiać wyszukiwanie i modyfikowanie uprawnień

użytkowników i grup wraz z możliwością zarządzania członkostwem

grup i poszczególnymi uprawnieniami.

1.3 ARCHITEKTURA SYSTEMU

F01.03.001. Rozbudowywany o nowe elementy System musi stanowić zbiór

wielu niezależnych modułów, które - w zależności od nadanych

uprawnień - mogą być zarządzane niezależnie od siebie.

F01.03.002. System musi umożliwić utworzenie i niezależną konfigurację

obszarów roboczych poszczególnych komórek organizacyjnych pod

względem:

a) dostępnych typów dokumentów i ich metadanych,



str. 9

b) dostępnych przepływów pracy i ich skojarzeń z typami

dokumentów,

c) użytkowników posiadających odpowiednie poziomy uprawnień

do wykonywania operacji i dostępu do danych w ramach

obszaru.

F01.03.003. System musi pozwalać na organizację informacji w biblioteki

dokumentów i listy (mogące przechowywać co najmniej: terminy

kalendarza, zadania, kontakty), umożliwiając ich udostępnianie

i wymianę w systemie i poprzez MS Outlook 2007/2010.

F01.03.004. System musi umożliwić tworzenie zestawów dokumentów

o wspólnym zbiorze atrybutów, organizować je w foldery,

udostępniać widoki typu drzewo oraz umożliwiać przydzielanie

metadanych do dokumentów i folderów.

F01.03.005. System musi być wyposażony w katalog witryn wchodzących w jego

skład.

F01.03.006. System musi udostępniać mechanizmy:

a) współpracy między działami/zespołami,

b) zarządzania zawartością,

c) implementowania procesów pracy, w tym przepływu

dokumentów i spraw,

d) dostępu do informacji niezbędnych do realizacji założonych

celów i procesów.

F01.03.007. Architektura systemu musi umożliwiać osadzenie nowej

funkcjonalności, w szczególności nowych typów pism i nowych

procesów, bez rozbudowy portalu o dodatkowe witryny nie

wynikające ze struktury organizacyjnej przedsiębiorstwa.



str. 10

F01.03.008. System musi zapewnić przechowywanie całej zawartości portalu

(strony, dokumenty, konfiguracja) we wspólnym dla całego serwisu

systemie bazodanowym.

F01.03.009. System będzie posiadał możliwość rozbudowy poprzez

udostępnienie otwartego API.

F01.03.010. System musi umożliwiać modyfikację przez administratora systemu

(bez udziału dostawcy oprogramowania); modyfikacje powinny

obejmować zmianę wyglądu szablonów, tworzenie nowych klas

dokumentów i spraw, modyfikowanie i budowanie procesów pracy,

struktury organizacyjnej firmy i innych modułów.

F01.03.011. System musi się charakteryzować elastyczną konfiguracją

zapewniającą przystosowanie systemu do zmian zachodzących

w strukturze organizacyjnej Zamawiającego.

1.4 INTERFEJS UŻYTKOWNIKA 1.4.1 FUNKCJONALNOŚĆ INTERFEJSU

F01.04.001. Portal musi zapewnić przejrzystą nawigację pozwalającą

przemieszczać się pomiędzy obszarami funkcjonalnymi, w tym

pomiędzy witrynami obszarów komórek organizacyjnych, i

umożliwiać każdemu użytkownikowi przejście „na skróty” do witryny

jego komórki organizacyjnej.

F01.04.002. Użytkownik musi mieć łatwy dostęp do wszystkich informacji (np.

plików) potrzebnych do wykonania zadania.

F01.04.003. Sposób prezentacji informacji musi być adekwatny do potrzeb

zadania.

F01.04.004. System musi umożliwiać użytkownikowi wykonanie wszystkich

czynności, potrzebnych do wykonania zadania.

F01.04.005. Potwierdzenia z systemu muszą odnosić się do treści aktualnie

wykonywanego zadania.

F01.04.006. System musi obsługiwać polskie znaki diakrytyczne. Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 11

F01.04.007. System nawigacji opierać powinien się na wcześniej zdefiniowanych

szablonach zawierających strukturę nawigacji.

F01.04.008. System musi wyświetlać daty w formacie zdefiniowanym przez

uprawionego do tego administratora.

F01.04.009. System zapewni możliwość dostosowania wyświetlanych

elementów do indywidualnych (definiowanych) preferencji

użytkowników.

F01.04.010. System musi umożliwiać nawigowanie pomiędzy elementami

interfejsu zarówno przy użyciu myszki, jak i klawiatury.

F01.04.011. System musi umożliwiać wprowadzanie danych przez wklejenie ze

schowka systemowego Windows.

F01.04.012. System musi umożliwiać kopiowanie danych do innych aplikacji

przy użyciu schowka systemowego Windows.

F01.04.013. W ramach interfejsu użytkownika układ wizualny portalu będzie

można zmieniać na poziomach:

a) globalnym (statystyki publicznej),

b) jednostki statystyki publicznej (np. GUS, US, CIS),

c) komórki organizacyjnej (np. departamentu GUS),

d) grupy roboczej,

e) indywidualnego użytkownika.

F01.04.014. Na poziomie globalnym Administratorzy muszą mieć możliwość

zdefiniowania podstawowego układu Portalu wraz z określeniem:

a) układu i zawartości bloków w zakresie wspólnym,

obowiązkowym dla wszystkich użytkowników Portalu i

niemożliwym do zmiany przez administratorów lokalnych,

kierowników grup roboczych ani indywidualnych użytkowników,

b) domyślnego, szablonowego układu i zawartości bloków dla

całości statystyki publicznej, który może podlegać modyfikacji

przez administratorów lokalnych, kierowników grup roboczych Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 12

i użytkowników z zachowaniem obowiązkowej konfiguracji

lokalnej.

F01.04.015. Na poziomie jednostki statystyki publicznej administratorzy lokalni

muszą mieć możliwość zdefiniowania układu lokalnego Portalu wraz

z określeniem:

a) układu i zawartości bloków w zakresie wspólnym,

obowiązkowym dla wszystkich użytkowników Portalu w ramach

jednostki i niemożliwym do zmiany przez indywidualnych

użytkowników,

b) domyślnego, szablonowego układu i zawartości bloków dla

użytkowników Portalu w ramach jednostki, który może podlegać

modyfikacji przez użytkowników z zachowaniem obowiązkowej

konfiguracji.

F01.04.016. W witrynie osobistej użytkownika powinny znajdować się sprawy,

dokumenty i zadania, którymi ma zająć się aktualnie zalogowana

osoba, z możliwością przefiltrowania tej listy według dowolnych

kryteriów (wartości metadanych).

F01.04.017. W witrynie osobistej użytkownika będzie mozliwość prowadzenia

przez użytkowników swojej strony domowej (profilu użytkownika)

pozwalającej na umieszczanie zawartości z róznych obszarów,

aktualizowanie informacje o użytkowniku, łączenie się z innymi

uzytkownikami w grupy.

F01.04.018. System umożliwi integrację w witrynie osobistej użytkownika

przydzielonych zadań albo poprzez umieszczenie zadań na tej

samej liście co zadań z systemu SII albo poprzez obudowanie

portalu samoobsługowego innego systemu w witrynie użytkownika.

F01.04.019. W ramach projektu wykonawca zintegruje z witryną osobistą

użytkownika portal samoobsługowy systemu zarządzania

tożsamością, użytkownikami i rolami w zakresie prezentowania

przydzielonych zadań a także inne portale wskazane na etapie

projektu technicznego np. Service Desk.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 13

F01.04.020. System musi umożliwiać zdefiniowanie zawartości okien

na podstawie rodzaju obiektów (wiadomości, inne obiekty, sprawy).

F01.04.021. Użytkownik musi mieć możliwość otwierania wielu spraw,

dokumentów, wiadomości jednocześnie w oddzielnych

oknach/zakładkach przeglądarki bez konieczności ponownego

logowania się do systemu. Musi istnieć możliwość zdefiniowania

z poziomu administracyjnego systemu maksymalnej ich ilości lub

braku limitu.

F01.04.022. System musi zapewnić możliwość ustawienia dla wszystkich

przycisków i nagłówków kolumn interfejsu etykiet (tzw hint’ów),

wyświetlanych w momencie naprowadzenia na nie wskaźnika

myszy, zawierających informację o ich przeznaczeniu lub

zawartości.

F01.04.023. Skróty, akronimy (skróty od pierwszych liter nazwy), kody i inne

dane alfanumeryczne muszą być używane w taki sam sposób

w całym systemie, ponadto:

a) muszą być łatwe do odczytania i zrozumienia,

b) muszą przestrzegać znanych konwencji.

F01.04.024. Ikony, symbole i inne informacje graficzne muszą być używane

w całym systemie w taki sam sposób, ponadto:

a) muszą być łatwe do zrozumienia i odczytania,

b) muszą przestrzegać znanych konwencji.

F01.04.025. Ten sam typ informacji (np. instrukcje, menu, komunikaty, tytuły,

nagłówki) musi pojawiać się zawsze:

a) w tym samym miejscu na ekranie,

b) w tej samej oprawie graficznej (ramka itp.).

F01.04.026. Sposób (metoda) wprowadzania danego typu informacji musi być

taki sam w całym systemie.

F01.04.027. Sposób wyboru różnych opcji (np. z menu) powinien być taki sam

w całym systemie.



str. 14

F01.04.028. Gdy używana jest klawiatura, w całym systemie te same klawisze

muszą być używane stale do tych samych funkcji.

F01.04.029. Musi występować taka sama kolejność i ten sam sposób

wykonywania podobnych powiązanych ze sobą operacji (np.

uaktualnienie i kasowanie danych, rozpoczynanie i kończenie

transakcji).

F01.04.030. Sposób, w jaki system reaguje na określone działania użytkownika,

powinien być zawsze taki sam.

F01.04.031. System stosować będzie ogólnie przyjęty format danych (np.kodu

pocztowego), a ich format wyświetlania musi być zgodny

z formatem, w jakim dane są wprowadzane do systemu.

F01.04.032. Informacje muszą być prezentowane i pobierane przez system

w takich jednostkach, jakie w zadaniu stosuje użytkownik (np.

centymetry, złotówki).

F01.04.033. Kolejność i format wydrukowanych informacji muszą być zgodne ze

sposobem ich wyświetlania na ekranie.

F01.04.034. Właściciel witryny może określić sposób umieszczenia witryny

w katalogu (np. witrynę w katalogu zobaczą jedynie ci użytkownicy,

których uprawnienia pozwalają na dostęp do niej).

F01.04.035. System musi mieć możliwość przypisania motywu kolorystycznego /

graficznego do witryny.

1.4.2 POTWIERDZENIA INFORMACYJNE

F01.04.036. Instrukcje i komunikaty wyświetlane przez system muszą być :

a) zwięzłe i zachęcające do działania,

b) związane z wykonywanymi czynnościami,

c) dostarczać wszystkich wymaganych informacji,

d) treściwe i dokładne.



str. 15

F01.04.037. Instrukcje i podpowiedzi muszą wyraźnie sugerować, co należy

robić.

F01.04.038. Musi być jasno określone, jakie funkcje systemu i czynności są dla

użytkownika dostępne w każdej fazie pracy.

F01.04.039. Musi być jasno określone, co użytkownik powinien zrobić, aby

uruchomić poszczególne informacje (np. jakie opcje wybrać, które

klawisze przycisnąć).

F01.04.040. Musi być jasno określone, jakie system daje możliwości

wykorzystania skrótów klawiaturowych, komend i klawiszy

funkcyjnych.

F01.04.041. Odpowiedź systemu musi być zawsze odpowiednia

do wprowadzonych przez użytkownika danych lub wykonanych

czynności.

F01.04.042. System musi jasno informować o zakończeniu zadanych mu

operacji (pomyślnym i niepomyślnym).

F01.04.043. System musi natychmiast informować o wszelkich przeszkodach

w pracy, jednocześnie podając, jakie dane lub polecenia

użytkownika są aktualnie wykonywane.

F01.04.044. Komunikaty o błędach muszą określać:

a) gdzie pojawiły się błędy,

b) jakiego rodzaju są to błędy,

c) dlaczego się pojawiły.

F01.04.045. Komunikaty o błędach muszą zawierać czytelną informację, jakie

działania powinien podjąć użytkownik w celu wyeliminowania błędu

bądź też gdzie może znaleźć informacje dotyczące danego tematu

lub z kim powinien się skontaktować w celu rozwiązania problemu.

1.4.3 ELASTYCZNOŚĆ I KONTROLA UŻYTKOWNIKA F01.04.046. System musi dawać możliwość łatwego odwrócenia efektu

wykonanej czynności i cofnięcia się do poprzedniego etapu pracy



str. 16

lub poprzedniego ekranu (np. w przypadku mylnie wykonanej

czynności).

F01.04.047. Efekt cofnięcia wykonanej pracy musi dać się ponownie odwrócić

(powrót do stanu pierwotnego).

F01.04.048. System musi umożliwiać pracę przy użyciu skrótów

klawiaturowych, klawiszy funkcyjnych itp. wszędzie, gdzie jest to

potrzebne.

F01.04.049. Użytkownik musi mieć pełną kontrolę nad kolejnością pozyskiwania

informacji z systemu lub wykonywania ciągu czynności.

F01.04.050. Użytkownik powinien móc przeglądać sekwencje czynności

(ekranów) w obu kierunkach.

F01.04.051. System musi zapewnić możliwość łatwego powrotu do głównego

menu z dowolnej części systemu.

F01.04.052. Użytkownik musi łatwo przechodzić między dowolnymi częściami

systemu zależnie od potrzeb.

F01.04.053. System powinien podawać domyślne wartości często używanych

danych.

F01.04.054. Użytkownik, tam gdzie to wskazane, powinien móc wybrać

pomiędzy ręcznym wprowadzaniem danych a wykorzystaniem

wartości domyślnych.

F01.04.055. Użytkownik musi mieć możliwość poprawiania wartości domyślnych

podawanych przez system.

F01.04.056. W całym systemie pola, służące do wprowadzania danych, muszą

być, o ile jest to możliwe, wyposażone w maski wprowadzania.

F01.04.057. W całym systemie pola, służące do wprowadzania danych, muszą

być, o ile to możliwe, wyposażone w rozwijane listy słownikowe.

F01.04.058. Użytkownik musi mieć możliwość swobodnego ustalania, jak

nazywać i organizować informacje do późniejszego wykorzystania

(np. pliki, katalogi).



str. 17

1.4.4 ZAPOBIEGANIE I KONTROLA BŁĘDÓW

F01.04.059. System powinien samoczynnie weryfikować dane wprowadzone

przez użytkownika zanim zostaną one przetworzone.

F01.04.060. System musi jednoznacznie i natychmiast informować użytkownika

o wykryciu błędu.

F01.04.061. System musi informować użytkownika, kiedy rozmiar

wprowadzonych danych przekracza ilość dostępnego miejsca (np.

ilość znaków).

F01.04.062. Użytkownik musi być w stanie sprawdzić całość wprowadzonych

danych zanim zostaną one zapisane lub przetworzone.

F01.04.063. Użytkownik musi mieć możliwość łatwego poprawiania błędów.

F01.04.064. System musi prosić użytkownika o potwierdzenie wszystkich

działań, które nie są odwracalne lub mogą powodować poważne

skutki.

F01.04.065. System musi być zabezpieczony przed efektami ubocznymi zmian

dokonanych w innych jego częściach.

F01.04.066. System musi uniemożliwiać użytkownikom wykonanie działań, do

których nie mają oni uprawnień.

1.4.5 KLAROWNOŚĆ WIZUALNA F01.04.067. Każdy ekran (lub okno) musi być łatwo rozpoznawalny dzięki

swojemu nagłówkowi, tytułowi lub opisowi.

F01.04.068. Ważne informacje muszą być wyróżnione na ekranie (np. pozycja

kursora, instrukcje, komunikaty o błędach).

F01.04.069. Kolory w całym systemie muszą być używane w ten sam sposób

(np. komunikaty o błędach zawsze podświetlane w tym samym

kolorze).

F01.04.070. Informacje muszą być zorganizowane logicznie na ekranie (np.

menu zorganizowane według prawdopodobnej kolejności wyboru

czynności lub lista alfabetyczna).



str. 18

F01.04.071. Różne typy informacji muszą być na ekranie wyraźnie od siebie

oddzielone (np. instrukcje, opcje, wyświetlanie danych).

F01.04.072. Jeśli na ekranie są wyświetlane duże ilości informacji, muszą być

one wyraźnie podzielone na sekcje.

F01.04.073. Jasne kolory muszą być wyświetlane na ciemnym tle i na odwrót.

F01.04.074. Standardowym sposobem prezentowania tekstu musi być

zastosowanie czarnej (lub ciemnej) czcionki na jasnym tle.

F01.04.075. Kolumny danych muszą być na ekranie odpowiednio ułożone (np.

kolumny danych alfanumerycznych wyrównane do lewej, kolumny

liczb całkowitych wyrównane do prawej).

F01.04.076. Informacje podane na ekranie muszą być ogólnie łatwe do

oglądania i czytania.

F01.04.077. Ekrany (okna) muszą pojawiać się w logicznej kolejności.

F01.04.078. Na ekranie musi być łatwo odnaleźć wymagane informacje.

F01.04.079. Tam, gdzie jest to istotne, kolory powinny być używane zgodnie

z tradycyjnymi skojarzeniami.

1.4.6 PRZEJRZYSTOŚĆ SYTEMU

F01.04.080. Musi być jasno określone, jaki jest stan i postęp zadań

wykonywanych przez system.

F01.04.081. Musi być jasno określona kolejność czynności, jakie użytkownik

powinien wykonać, aby zakończyć zadanie.

F01.04.082. Gdy użytkownik ma do wyboru kilka opcji, musi być jasno

określone, co każda z nich znaczy.

F01.04.083. Musi być jasno określone, w której części systemu aktualnie

pracuje użytkownik.

F01.04.084. Musi być jasno określone, jak zmiany wprowadzone w jednej

części systemu wpływają na pracę innych części systemu.



str. 19

1.4.7 PROWADZENIE I WSPARCIE UŻYTKOWNIKA

F01.04.085. Zamawiający wymaga, aby w system wbudowane było narzędzie

„Pomoc” dostępne dla użytkowników, zapewniające pomoc

kontekstową.

F01.04.086. Zawartość pomocy on-line dostępnej z poziomu Systemu i

samouczka musi odnosić się do typowych zadań wykonywanych

przez użytkownika.

F01.04.087. Jeżeli sekwencje zadań są szczególnie długie, muszą być one

podzielone na odpowiednio mniejsze bloki czynności.

F01.04.088. Użytkownik musi mieć możliwość uruchomienia systemu pomocy

z dowolnego miejsca w systemie.

F01.04.089. Musi być jasno określone, jak się dostać i wydostać z systemu

pomocy.

F01.04.090. Treść informacji pomocy musi być jasno podana, bez przerywania

aktualnej czynności użytkownika. Kiedy użytkownik potrzebuje

pomocy, system musi jasno prezentować możliwe do wykonania

działania w odniesieniu do aktualnych czynności wykonywanych

przez użytkownika.

F01.04.091. Kiedy użytkownik korzysta z pomocy, musi on mieć możliwość

łatwego znalezienia potrzebnej informacji bezpośrednio, bez

konieczności przeglądania pozostałych, nie związanych z jego

problemem.

F01.04.092. Wszystkie dostępne formy prowadzenia użytkownika oraz pomocy

powinny być związane z aktualnie wykonywanym zadaniem

użytkownika. Nie powinno to zmniejszać możliwości dostępu do

całej pomocy systemu.

1.5 ADMINISTROWANIE

F01.05.001. System musi umożliwić zarządzanie całym środowiskiem oraz

zapewnić analizę i optymalizację wydajności, dostępności i

bezpieczeństwa.



str. 20

F01.05.002. System musi umożliwiać zbudowanie własnych zasad dla

zarządzania dostępnością, bezpieczeństwem, wydajnością.

F01.05.003. System musi umożliwiać rozpoznanie konfiguracji farmy SII i

graficzne zarządzanie serwerami SII z poziomu jednej konsoli

zarządzania

F01.05.004. System musi umożliwiać zarządzanie w graficzny sposób

poszczególnymi witrynami oraz kolekcjami witryn.

F01.05.005. System będzie oferował portal webowy do kontroli informacji

umieszczonych na serwerach farmy np. rodzaje plików, największe

witryny, największe bazy danych z zawartością witryny.

F01.05.006. System musi umożliwiać historyczne zbieranie informacji

o konfiguracji oraz zawartości farmy.

F01.05.007. System pozwoli na identyfikowanie witryny lub kolekcji witryn

zawierających najwięcej danych.

F01.05.008. System będzie pokazywać statystyki zmian oraz przyrostu

informacji na serwerach SII.

F01.05.009. System umożliwi raportowanie aktywności użytkowników na

poszczególnych witrynach.

F01.05.010. System musi oferować przejrzysty dostęp do funkcji

administrujących SII z poziomu konsoli graficznej realizowany

poprzez bezpośrednie linki do natywnych komend SII.

F01.05.011. System będzie umożliwiał tworzenie polityk konfigurujących dostęp

do witryn oraz podstawowych ustawień na serwerach SII.

F01.05.012. System dostarczy wyspecjalizowaną usługę, która umożliwi

przeprowadzanie audytu zmian na serwerach/witrynach/obiektach

SII.

F01.05.013. System musi oferować raporty dotyczące poprawności konfiguracji

farmy, użytkowników lub grup użytkowników, zmian

w dokumentach, listach, witrynach oraz kolekcjach witryn.



str. 21

F01.05.014. System będzie wykorzystywać bazę MS SQL Server 2008/2008R2,

której licencję Zamawiający posiada, do przechowywania informacji

historycznych.

F01.05.015. System musi wspierać instalację środowiska na komputerach

z systemem Microsoft Windows XP/Vista/Windows 7 oraz Windows

2003/2008/2008 R2.

1.6 ZARZĄDZANIE PROCESAMI PRACY

1.6.1 WYMAGANIA OGÓLNE

F01.06.001. W ramach rozbudowy systemu SII wykonawca dostarczy

niezbędne komponenty (w tym licencje) i wdroży zintegrowany z

Portalem Korporacyjnym GUS system do zarządzania procesami

pracy (System Elektronicznego Obiegu Dokumentów GUS).

F01.06.002. SEOD musi zapewnić obsługę następujących procesów:

a. proces podstawowy (kancelaryjny) – punkt 3 załącznika nr 8,

b. procesy dedykowane – np. punkty 4-6 załącznika nr 8 oraz inne

przewidziane przez Zamawiającego do samodzielnego wdrożenia w

terminie późniejszym.

F01.06.003. Zamawiający dopuszcza spełnienie wymagań na wdrożenie SEOD

w pełnym zakresie funkcjonalnym na dwa sposoby:

a. Dostarczenie jednych licencji pozwalających wdrożyć podpunkty

a i b punktu F02.05.002 spełniających wszystkie Wymagania

Zamawiającego. W tym wypadku wdrożenie zarówno procesu

podstawowego jak i pozostałych procesów odbywa się dzięki tym

samym licencjom, a dostarczony produkt musi spełniać wszystkie

wymagania Zamawiającego.

b. dostarczenia osobnych licencji na wdrożenie procesów z

podpunktów a i b punktu F02.05.002. W tym wypadku licencje na Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 22

podpunkt a muszą spełniać tylko wymagania na wdrożenie

procesu podstawowego (kancelaryjnego) bez wszystkich

wymagań z punktu 1.1.7, natomiast licencje na wdrożenie

procesów z podpunktu b (dedykowanych) punktu F02.05.2002

muszą spełniać wszystkie wymagania punktu 1.1.7 Zarządzanie

procesami pracy.

F01.06.004. System musi umożliwiać obsługę przepływu pracy (BPM) –

automatycznie przemieszczać pisma pomiędzy użytkownikami

systemu zgodnie ze zdefiniowaną wcześniej ścieżką procedowania

pism.

F01.06.005. System musi umożliwiać uczestnictwo użytkowników w procesach,

m.in. wyświetlać i realizować zadania w procesie, z poziomu Portalu

Korporacyjnego lub w środowisku zintegrowanym z Portalem

Korporacyjnym.

F01.06.006. System musi umożliwić dostosowanie samodzielnie, przez

Zamawiającego, wdrożonych procesów do zmieniających się

warunków organizacyjnych i prawnych oraz pozwalać na

optymalizację procesów.

F01.06.007. System musi zapewnić możliwość udokumentowania procesów

w formie modeli (map procesów) i zestawu niezbędnych do opisania

procesu informacji, w tym opisu poszczególnych kroków.

F01.06.008. System musi umożliwić zdefiniowanie zestawu kluczowych

wskaźników, mierników procesu (KPI) niezbędnych do

monitorowania ich efektywności aby osiągnąć założone cele dla

poszczególnych procesów.

F01.06.009. System musi umożliwiać dostęp do statystyk każdego z przepływów

pracy np. średni czas wykonania, łączna liczba uruchomień, czy

liczba przepływów pracy w toku.



str. 23

F01.06.010. System musi umożliwić prowadzenie pomiaru poszczególnych

procesów, analizowania danych uzyskanych z pomiarów

w porównaniu z KPI i możliwość optymalizacji oraz ciągłego

doskonalenia procesów.

1.6.2 ZARZĄDZANIE PROCESAMI

F01.06.011. Wykonawca przekaże Zamawiającemu dokument opisujący sposób

(metodykę) klasyfikacji procesów wspierającą pracowników

Zamawiającego w samodzielnej identyfikacji kluczowych procesów.

F01.06.012. Wskazane przez Zamawiającego w Załączniku nr 8 procesy

wykonawca podda analizie, opisze i wykona model w standardzie

BPMN, wyznaczy mierniki oraz wdroży w Systemie Elektronicznego

Obiegu Dokumentów GUS.

F01.06.013. Wykonawca wdroży wskazane procesy w sposób wystarczający do

samodzielnego monitoringu, analizy i zarządzania przez

pracowników Zamawiającego z wykorzystaniem dostarczonych

narzędzi.

F01.06.014. Wykonawca na potrzeby Zamawiającego przygotuje dokument

„Szablon opisu procesu” (karta procesu). W dokumencie muszą się

znaleźć informacje (wytyczne) pozwalające pracownikom

Zamawiającego na:

a) opisanie procesu;

b) wyznaczenie celu(ów) procesu;

c) opracowanie wskaźników i mierników procesu przy czym

mierniki procesu mogą bazować na wielu źródłach danych,

pozyskanych z systemów przetwarzających dane w ramach

procesu, dzięki badaniom ankietowym itp.;

d) agregowanie danych z pomiarów w celu przedstawienia

informacji zarządczej.



str. 24

1.6.3 PORTAL PROCESÓW

F01.06.015. Wykonawca, korzystając z funkcjonalności Portalu Korporacyjnego

GUS, przygotuje i odda Zamawiającemu Portal Procesów.

F01.06.016. Celem udostępnienia Portalu Procesów jest zapewnienie

pracownikom Zamawiającego nieograniczonego dostępu do

informacji o bieżącym kształcie procesów, planowanych i

implementowanych zmianach, zapewnienie prostego i szybkiego

kontaktu z właścicielami procesów oraz budowanie zaufania

do realizowanego przedsięwzięcia procesowego.

F01.06.017. Portal Procesów musi być dostępny dla każdego uwierzytelnionego

pracownika Zamawiającego.

F01.06.018. Na Portalu Procesów publikowana będzie dokumentacja procesowa

zdefiniowanych procesów wraz z mapami procesów w formacie

html.

F01.06.019. Portal procesów musi zapewniać możliwość zróżnicowanych

rodzajów uprawnień:

a) administrator (zarządzanie Portalem),

b) autor (publikowanie dokumentacji),

c) użytkownik zwyczajny (wgląd do dokumentacji).

F01.06.020. Portal musi umożliwić zarządzanie wersjami dokumentacji

procesowej.

F01.06.021. Portal musi umożliwić dodawanie komentarzy do dokumentacji

przez użytkowników (np. pomysłów na usprawnienie procesu).

F01.06.022. Portal musi umożliwić definiowanie obiegu informacji zawartych

w komentarzach (np. kolejne stopnie akceptacji).



str. 25

1.6.4 WYMAGANIA SZCZEGÓŁOWE

1.6.4.1 MAPOWANIE/MODELOWANIE PROCESÓWF01.06.023. System musi umożliwiać obsługę przepływu pracy (BPM) –

automatycznie przemieszczać sprawy pomiędzy użytkownikami

systemu zgodnie ze zdefiniowaną wcześniej ścieżką procedowania

sprawy.

F01.06.024. System musi pozwalać na definiowanie zarówno procesów

powiązanych z dokumentem jak i nie powiązanych.

F01.06.025. System musi posiadać graficzny interfejs (modeler) zintegrowany z

interfejsem SII, dostępny przez przeglądarkę, pozwalający na

projektowanie (modelowanie) oraz automatyzowanie wdrożenia

procesów bez konieczności pisania kodu.

F01.06.026. Modeler musi działać na zasadzie wizualnego kreatora przepływów

pracy zapewniającego mechanizmy integracji i dodatkowe funkcje

budowy zaawansowanych workflow.

F01.06.027. System musi umożliwiać tworzenie workflow dla witryn, typów

zawartości oraz zestawów dokumentów.

F01.06.028. System musi zawierać repozytorium obiektów, modeli, kształtów i

łączników.

F01.06.029. System musi zapewniać dostępność podstawowych kategorii

elementów graficznych jak:

a) elementy aktywne,

b) połączenia,

c) miejsca realizacji procesu,

d) artefakty.

F01.06.030. System musi umożliwić zarządzanie wszystkimi obiektami i

połączeniami w ramach modelu z jednego miejsca.



str. 26

F01.06.031. System musi umożliwić automatyczne układanie i porządkowanie

obiektów oraz połączeń na modelach.

F01.06.032. System musi umożliwiać tworzenie map procesów na zasadzie

„drag and drop”.

F01.06.033. System musi umożliwić stosowanie łączników poprzez wybranie

obiektu początkowego i końcowego.

F01.06.034. System musi umożliwić tworzenie zarówno poziomych jak i

pionowych torów odzwierciedlających komórki organizacyjne lub

role, realizujące poszczególne kroki procesu.

F01.06.035. System musi umożliwić umieszczanie nazw poszczególnych torów..

F01.06.036. System musi zapewnić możliwość kopiowania lub wycinania i

wklejania torów wraz z ich zawartością.

F01.06.037. System musi zapewniać mechanizmy walidacji poprawności

projektowanego procesu (poprawność i kompletność), tj.

sprawdzenie, czy procedura nie zawiera martwych punktów albo

zakleszczeń.

F01.06.038. System musi posiadać mechanizmy obsługi procesów

zapewniające możliwość definiowania logicznych warunków (reguł

biznesowych), które mogą mieć wpływ i korzystają z danych

wprowadzanych przez użytkownika poprzez formularze, jak również

zebranych w czasie trwania procesu.

F01.06.039. System musi zapewniać operacje na datach oraz operacje

matematyczne, wstrzymanie (np. podczas czekania na aktualizację)

czy zatrzymanie procesu.

F01.06.040. System musi umożliwiać dołączenie dokumentów i plików w

dowolnym momencie przebiegu procesu.



str. 27

F01.06.041. System musi pozwalać na określenie akcji rozpoczęcia i

zakończenia procesu (wyzwalacze), etapów realizacji procesu oraz

warunków uruchomienia danego etapu – zasad regulujących

przejścia pomiędzy etapami.

F01.06.042. System musi dawać możliwość zdefiniowania jako wyzwalacza

faktu pojawienia się dokumentu określonego typu np. formularza

(schemat dokumentu powiązany z procesem).

F01.06.043. System musi pozwalać na zdefiniowanie podprocesów możliwych

do ponownego (wielokrotnego) wykorzystania.

F01.06.044. System musi pozwalać na przydzielenie czynności do jednej bądź

do wielu osób z grupy osób, które mogą ją wykonać oraz musi

pozwalać na zdefiniowanie reguł biznesowych, które taką grupę

pozwolą wybrać (np. grupa z AD, pracownicy komórki

organizacyjnej).

F01.06.045. System musi zapewnić metody integracji z zewnętrznymi danymi

lub procesami oraz pozwalać w prosty sposób (bez pisania kodu)

na integrację co najmniej dla web services oraz używanych u

Zamawiającego MS SLQ (2005 i nowsze) i BizTalk Server (2006 i

nowsze).

F01.06.046. System musi umożliwić zakładanie terminów i zadań w Exchange

Server.

F01.06.047. System musi umożliwić automatyczne i cykliczne uruchamianie

procesów.

F01.06.048. System musi umożliwiać dodawanie/aktualizowanie/usuwanie grup

członków i członkowstw w grupach użytkowników SII.

F01.06.049. Lista akcji możliwych do wykorzystania podczas budowania procesu

musi obejmować co najmniej:



str. 28

a) zapis i odczyt z bazy danych (co najmniej używane u

Zamawiającego MS SQL 2005 i nowsze);

b) wywołanie usługi sieciowej (web service);

c) wysłanie wiadomości e-mail;

d) połączenie zarówno odbierające, jak i przekazujące dane z/do

bibliotek i list Portalu Korporacyjnego GUS;

e) tworzenie i usuwanie list;

f) ewidencjonowanie i wyewidencjonowanie elementów;

g) zapis informacji w module Indywidualnego kalendarza

pracownika;

h) złożenie podpisu elektronicznego akceptującego krok w procesie

przy użyciu komponentu do podpisu;

i) tworzenie zadań dla uczestników procesu;

j) otwarcie, zapisanie zmian, usunięcie istniejącego dokumentu;

k)utworzenie dokumentu (według wskazanego schematu);

l) zapis danych zebranych za pomocą formularza;

m) wyliczanie pól w oparciu o dane wprowadzone podczas

definiowania procesu lub zebrane podczas realizacji workflow;

n) zmiana zawartości pól lub wartości atrybutów dokumentów lub

spraw w oparciu o dane wprowadzone podczas definiowania

procesu lub zebrane podczas realizacji workflow;

o) wygenerowanie nowej sprawy;

p) zarejestrowanie pisma w sprawie;

q) ustawianie uprawnienia do elementu.

F01.06.050. System musi wspierać reguły w procesie służące do kierowania

jego przebiegiem co najmniej następujące typy reguł:

a) reguły przepływu definiują rozwidlenia i połączenia przepływów

między czynnościami za pomocą operacji XOR, OR, AND oraz

złożonych operacji warunkowych na stanie procesu;



str. 29

b) zdarzenia (początkowe, pośrednia i końcowe), przy czym

konieczne jest uwzględnienie typów zdarzeń takich jak:

nieokreślone, wysłanie/odebranie wiadomości, zasada, czas,

anulowanie, zerwanie (terminacja), wyjątek/usterka,

kompensacja, łącze do i wielokrotne,

c) reguły kierowania wytyczają, kto (użytkownik, grupa lub rola)

powinien wykonać daną czynność w procesie;

d) reguły wyjątków (razem z odliczaniem czasu) decydują, kiedy

należy podjąć kroki w procesie związane z występującym

wyjątkiem;

e) zdarzenia wywołujące wskazują, który proces należy wywołać,

gdy przyjdzie wyznaczone zdarzenie.

f) reguły Service Level Agreement (SLA) oceniają kluczowe

wskaźniki (KPI) procesu względem określonych progów i

wyzwalają zawiadomienia lub zdarzenia, gdy te zostaną

przekroczone.

F01.06.051. System musi zapewniać następujące mechanizmy dotyczące

liczności wykonawców:

a) wielu wykonawców;

b) wielu wykonawców, liczność ustalana w czasie definiowania

procesu;

c) wielu wykonawców, liczność ustalana w czasie wykonywania

procesu;

d) wielu wykonawców bez informacji o ich liczności.

F01.06.052. System musi umożliwiać określenie czasu wykonania czynności

(zadania) oraz całego procesu w przypadku ograniczeń czasowych.

F01.06.053. System musi umożliwiać wyświetlenie w kolejnych aktywnościach

(krokach) procesu informacji o złożonych wcześniej podpisach

elektronicznych.



str. 30

F01.06.054. System musi dawać możliwość obsługi zdarzeń błędów i

kompensacji – zachowanie procesu w przypadku błędnych sytuacji

musi być możliwe do zaprojektowania.

F01.06.055. System musi zapewnić możliwość zarówno ręcznego jak i

automatycznego numerowania kroków procesu.

F01.06.056. System musi zapewnić możliwość przypisania do czynności

procesu danych/informacji dodatkowych, co najmniej:

a) czas trwania czynności;

b) systemy informatyczne wspierające realizację kroku;

c) opisy czynności;

d) klasyfikacja czynności (np. manualna, automatyczna);

e) definiowanie odniesień do dokumentów zewnętrznych (pliki,

linki URI) zawierających dodatkowe informacje odnośnie

czynności.

f) definiowanie dokumentów (wejście, wyjście, dokumenty

powiązane) wykorzystywanych w czynności.

g) komentarze dotyczące czynności.

F01.06.057. System musi umożliwić definiowanie wymaganych atrybutów.

F01.06.058. System musi umożliwić przypisanie do punktów decyzyjnych

procesu danych/informacji dodatkowych:

a) wyjść tak/nie,

b) wyjść prawda/fałsz,

c) samodzielne zdefiniowanie innych typów wyjść,

d) definiowanie algorytmu dla każdego z wyjść na podstawie:

wartości progowych (np. kosztu),

zależności od innych kroków procesu.



str. 31

F01.06.059. System musi umożliwić podpięcie linków do zewnętrznych

dokumentów/aplikacji, adresów URI dla poszczególnych elementów

modelu.

F01.06.060. System musi umożliwić zdefiniowanie czynników uruchamiających

przebieg procesu dla punktu startowego np. zakończenie innego

procesu.

F01.06.061. System musi umożliwić zdefiniowanie czynników kończących

przebieg procesu dla punktu końcowego.

F01.06.062. System musi zapewnić dostępność pomocy dla poszczególnych

typów obiektów oraz atrybutów.

F01.06.063. System musi zapewnić możliwość definiowania statusu modelu

(wersja robocza, do przeglądu, produkcyjna, archiwalna).

F01.06.064. System musi zapewnić możliwość zapoznania się z historią zmian

modelu.

F01.06.065. System musi zapewnić wsparcie dla zarządzania wersjami oraz

akceptacji modeli i ich definicji, w celu dalszego procedowania

procesu zgodnie z definicją, która obowiązywała w momencie jego

startu.

1.6.4.2 PUBLIKACJA

F01.06.066. System musi zapewnić możliwość zapisu modelu do co najmniej

następujących standardów:

a) PDF,

b) HTML,

c) plików graficznych (JPEG lub PNG).

F01.06.067. System musi zapewnić odwzorowanie przejść do podprocesów i

powiązań miedzy procesami i obiektami poprzez hyperlinki

w generowanym HTML.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 32

F01.06.068. System musi zapewniać tworzenie szablonów dokumentacji

procesowej.

1.6.4.3 ANALIZA PROCESÓW

F01.06.069. System musi zapewniać możliwość śledzenia zdefiniowanych

parametrów procesów (KPI).

F01.06.070. System musi pozwalać na analizę już wykonanych procesów,

w celu zwiększenia efektywności pracy.

F01.06.071. System musi zapewnić symulację przebiegu procesu wraz

z obserwowaniem wybranych parametrów symulacji i

sygnalizowaniem wąskich gardeł.

F01.06.072. System musi umożliwić raportowanie zrealizowanych symulacji

co najmniej:

a) czas trwania przejścia całego procesu;

b) czas trwania poszczególnych kroków.

F01.06.073. System musi zapewnić możliwość eksportu raportów do MS Excel.

F01.06.074. System musi umożliwić raportowanie z wykorzystaniem raportów

standardowych.

1.6.4.4 ZARZĄDZANIE PROCESAMI

F01.06.075. Moduł definiowania procesów musi zapewnić możliwość

zarządzana procesami, dzięki czemu możliwe będzie wywoływanie,

zarządzanie i monitorowanie stopnia wykonania czynności i działań

oraz utrzymywanie definicji procesów.

F01.06.076. Moduł definiowania procesów musi posiadać interfejs panelu dla

kadry zarządzającej zapewniający intuicyjny podgląd kluczowych

danych związanych z procesami.



str. 33

F01.06.077. Zarządzanie procesami musi być możliwe poprzez graficzny

interfejs użytkownika.

F01.06.078. Moduł definiowania procesów musi zapewnić import danych

w formie XML.

F01.06.079. Moduł definiowania procesów musi zapewnić możliwość

obrazowania kontrolowanych KPI w formie dashboardu

zawierającego graficzne oraz/lub tabelaryczne zestawienie danych.

F01.06.080. Moduł definiowania procesów musi zapewnić możliwość tworzenia

różnych widoków dashboardu np. ze względu na rolę.

F01.06.081. Moduł definiowania procesów musi zapewnić możliwość filtrowania

danych oraz wyników analiz.

F01.06.082. Moduł definiowania procesów musi umożliwić wyświetlanie wyników

wielu analiz jednocześnie.

F01.06.083. Moduł definiowania procesów musi umożliwić udostępnianie

wyników analiz innym użytkownikom.

F01.06.084. Moduł definiowania procesów musi zapewnić różne formaty

publikacji wyników analiz, co najmniej:

a) HTML,

b) PDF.

F01.06.085. Moduł definiowania procesów musi posiadać system monitorowania

i powiadamiania o parametrach krytycznych procesów.

F01.06.086. Moduł definiowania procesów musi posiadać mechanizm

eksportowania danych w formie XML.

F01.06.087. Moduł definiowania procesów musi posiadać silnik wykonywania

procesów obejmujący wstrzymywanie/wznawianie realizacji instancji

procesu.



str. 34

F01.06.088. Moduł definiowania procesów musi umożliwić śledzenie statusów

konkretnych obiegów dokumentów lub spraw.

F01.06.089. Moduł definiowania procesów musi umożliwić delegowanie

przypisanych na użytkownika akcji (np. na czas nieobecności).

1.6.4.5 INNE WYMAGANIA

F01.06.090. Oferowane rozwiązanie musi zapewnić dostęp do pracy w systemie

wszystkim uwierzytelnionym pracownikom Zamawiającego.

F01.06.091. W przypadku licencjonowania rozwiązania Zamawiającemu

przekazane zostaną licencje na środowisko produkcyjne i testowe

pozwalające na bezterminowe użytkowanie dostarczanych

rozwiązań.

F01.06.092. W przypadku licencjonowania rozwiązania dla projektantów

procesów Zamawiającemu zostanie przekazanych 10 licencji

pozwalających na nieograniczone czasowo użytkowanie.

1.7 DOSTOSOWYWANIE SYSTEMU

1.7.1 PROJEKTOWANIE SZABLONÓW DOKUMENTÓW I SPRAW

F01.07.001. System musi umożliwiać definiowanie różnych typów pism,

z właściwym dla danego typu zestawem metadanych.

F01.07.002. System musi umożliwiać tworzenie różnych szablonów pism,

poprzez określenie listy pól metadanych i pól treści pisma,

z możliwością określenia formatu tych pól, reguł poprawności

danych, wartości domyślnych, wartości predefiniowanych itd.

F01.07.003. System musi umożliwiać definiowanie różnych typów spraw

z właściwym dla danego typu zestawem metadanych.



str. 35

F01.07.004. Metadane (atrybuty), które mogą być skojarzone z pismem lub

sprawą, oraz pola szablonu treści pisma, muszą obejmować co

najmniej następujące typy: tekst (czysty i formatowany), liczba, data

i godzina, lista wyboru (jedno- i wielokrotnego wyboru) otwarta

i zamknięta, osoba (użytkownik lub grupy), odnośnik (link) do

jednego lub wielu dokumentów, obliczeniowa.

F01.07.005. System musi mieć możliwość tworzenia definicji typów

metadanych (atrybutów), jako elementów do wielokrotnego

wykorzystania w definicjach typów pism lub spraw.

F01.07.006. System musi umożliwiać definiowanie wartości domyślnych dla

metadanych (atrybutów) pisma lub sprawy oraz pól i sekcji szablonu

treści pisma.

F01.07.007. System musi umożliwiać ustawianie wartości predefiniowanych

(tzn. przypisywanych ręcznie lub automatycznie i nie podlegających

dalszej edycji) dla metadanych (atrybutów) pisma lub sprawy oraz

pól i sekcji szablonu treści pisma.

F01.07.008. System musi umożliwiać zdefiniowanie obowiązkowych

elementów metadanych (atrybutów) pisma lub sprawy,

F01.07.009. System musi zapewnić co najmniej automatycznie wypełniane

następujące wartości: bieżąca data, bieżący czas, bieżący

użytkownik oraz podstawowe informacje o atrybutach plików: data

utworzenia, data modyfikacji, autor utworzenia, autor modyfikacji.

F01.07.010. W momencie dostarczenia systemu podstawowy zestaw

atrybutów dla wszystkich pism powinien obejmować co najmniej

takie elementy jak:

a) data wpływu,

b) typ pisma (wybór ze słownika),

c) komórka, która zajmie się przetworzeniem pisma (wybór ze

słownika),



str. 36

d) sygnatura nadawcy,

e) numer nadawczy,

f) nadawca (wybór ze słownika),

g) adresat - w przypadku korespondencji imiennej,

h) data pisma,

i) odnośniki do dokumentów powiązanych,

j) data odpowiedzi (dla pism wpływających jest to data, do której

jednostka statystyki musi udzielić odpowiedzi, dla pism

wychodzących data, do której oczekujemy odpowiedzi).

F01.07.011. Upoważniony użytkownik musi mieć możliwość definiowania

nowego typu pisma, który automatycznie zostanie dodany do listy

typów pism.

F01.07.012. Upoważniony użytkownik musi mieć możliwość modyfikowania

szablonu pisma określonego typu.

F01.07.013. Musi istnieć możliwość określenia dla typu pisma terminu (np. 30

dni), w jakim wymagane jest sporządzenie odpowiedzi na pisma

tego typu. Przy rejestracji takiego dokumentu system powinien

uzupełnić pole "data odpowiedzi" na podstawie zdefiniowanego

terminu i daty wpływu dokumentu.

F01.07.014. W momencie dostarczenia systemu podstawowy zestaw

atrybutów dla wszystkich spraw musi obejmować:

a) datę wszczęcia, datę zakończenia, opis sprawy,

b) odnośnik do pisma wszczynającego sprawę,

c) opis sprawy,

d) uwagi,

e) znak sprawy (identyfikator komórki organizacyjnej, symbol

z JRWA, numer sprawy w ramach danego symbolu, rok

wszczęcia sprawy),



str. 37

f) pole deklaracji, czy komórka rejestrująca sprawę jest komórka

macierzystą.

F01.07.015. System musi posiadać konfigurowalny pod względem formatu

numeru mechanizm do nadawania unikalnych numerów pism/spraw

wspólny dla całego Systemu, zależny od typu pisma, któremu

numer jest nadawany. Numer referencyjny musi zawierać co

najmniej: rok, miesiąc, numer kolejny oraz oznaczenia tekstowe i

znaki rozdzielające.

F01.07.016. System musi dawać możliwość zapisania szablonu pisma lub

sprawy z możliwością ponownego użycia.

F01.07.017. System musi umożliwiać generowanie na podstawie szablonów

pism w formacie XML.

1.7.2 PROJEKTOWANIE REJESTRÓW

F01.07.018. System musi umożliwiać definiowanie i prowadzenie rejestrów,

w tym rejestrów kancelaryjnych.

F01.07.019. Podczas definiowania rejestru musi istnieć możliwość określenia,

czy rejestr będzie gromadził dokumenty dobrane automatycznie

przez system na podstawie zdefiniowanej kombinacji wartości

wskazanych atrybutów, czy dokumenty ręcznie wybrane przez

użytkownika.

F01.07.020. Musi istnieć możliwość zdefiniowania formatu identyfikatora,

który system nadawał będzie dokumentom należącym do rejestru, a

który będzie umożliwiał lokalizację dokumentu w ramach rejestru.

F01.07.021. Podczas definiowania rejestru musi być możliwość ustalenia,

jakie dodatkowe metadane związane z przynależnością do danego

rejestru będą posiadały zgromadzone w nim pisma. Do metadanych

związanych z przynależnością dokumentu do rejestru stosuje się te

same wymagania, co do metadanych określanych w czasie



str. 38

definiowania szablonu pisma (format, wartości domyślne, walidacja

itp.).

F01.07.022. Musi istnieć możliwość prowadzenia rejestru na dowolnym

poziomie struktury organizacyjnej, czyli zarówno dla całej jednostki

lub grupy jednostek, jak i komórki dowolnego szczebla lub grupy

komórek.

F01.07.023. Musi istnieć możliwość zdefiniowania uprawnień do rejestru

co najmniej następującego rodzaju:

a) prowadzenie rejestru,

b) wgląd do rejestru,

c) tworzenie/modyfikacja schematu rejestru.

F01.07.024. Podczas definiowania rejestru musi istnieć możliwość utworzenia

szablonu wydruku tego rejestru.

F01.07.025. W momencie oddania do użytkowania system powinien mieć

zdefiniowane następujące rejestry:

a) spisów zdawczo-odbiorczych,

b) rejestr protokołów oceny dokumentacji niearchiwalnej

przeznaczonej do zniszczenia,

c) zbiór aktów normatywnych i innych Prezesa GUS,

d) zbiór aktów normatywnych Dyrektora Generalnego GUS,

e) rejestry korespondencji wchodzącej i wychodzącej (na poziomie

poszczególnych komórek organizacyjnych),

f) książka pocztowa (przesyłek wysłanych jako polecone),

g) zestawienie przesyłek wysłanych w formie papierowej,

h) zestawienie przesyłek wysłanych w formie elektronicznej,

i) dokumenty nieprzypisane do spraw,



str. 39

j) dokumenty w trakcie dekretacji,

k) dokumenty rozpatrywane,

l) dokumenty, na które oczekiwana jest odpowiedź,

m) spis spraw w podziale na teczki spraw,

n) spis dokumentów dotyczących sprawy.

1.7.3 PROJEKTOWANIE SZABLONÓW STRON

F01.07.026. Szablony serwisu (wygląd i nawigacja) będą mogły być

zmieniane bez ingerencji w treści, tj. zmiana wyglądu nie będzie

pociągała za sobą konieczności odtwarzania treści serwisu.

F01.07.027. System obsługiwał będzie szablony stron określające sposób

wyświetlania wszystkich elementów składowych strony.

F01.07.028. Uprawnienia do modyfikacji oraz tworzenia nowych szablonów

należeć będą do zdefiniowanej grupy użytkowników.

F01.07.029. System musi oferować możliwość zapisywania utworzonych

stron jako standardowych szablonów stron do poźniejszego

wykorzystania.

F01.07.030. Przygotowanie standardowego szablonu nie może wymagać od

użytkownika znajomości specjalistycznych technologii

informatycznych związanych z projektowaniem stron, powinno być

wykonywane automatyczne przez system i bez potrzeby

wykorzystania narzędzi programistycznych.

F01.07.031. Strony utworzone na podstawie standardowego szablonu muszą

być całkowicie niezależne od strony będącej wzorcem.

F01.07.032. System musi dawać możliwość wykorzystywania, do tworzenia Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 40

stron, zaawansowanych szablonów, przygotowanych przy użyciu

zewnętrznych narzędzi przez projektantów.

F01.07.033. Przygotowanie zaawansowanego szablonu musi być możliwe

przy wsparciu graficznego narzędzia do projektowania stron.

F01.07.034. System musi umieć zapamiętać w szablonie co najmniej:

a) układ graficzny strony (schemat kolorystyki, ikony, czcionki, itp.),

b) układ elementów funkcjonalnych umieszczonych na stronie

(ilość, umiejscowienie, status widoczności),

c) konfigurację elementów funkcjonalnych, w szczególności

ustawienia ich wyglądu – tzw. widoki.

F01.07.035. System musi umożliwiać dodanie do szablonu strony

dodatkowych atrybutów - w tym co najmniej nazwy i opisu szablonu.

F01.07.036. System musi udostępniać mechanizm publikowania i

zarządzania szablonami stron analogiczny do mechanizmów

publikowania i zarządzania pozostałą treścią, w szczególności

powinien zapewniać co najmniej wersjonowanie.

1.7.4 PROJEKTOWANIE FORMULARZY ELEKTRONICZNYCH

F01.07.037. W ramach systemu dostarczony zostanie moduł projektowania i

publikowania formularzy elektronicznych. Moduł może być dostępny

z poziomu SII albo dostarczony w formie aplikacji instalowanych na

komputerach projektantów. W przypadku licencjonowania

rozwiązania Zamawiającemu zostaną przekazane prawa do

nieograniczonego czasowo użytkowania dziesięciu licencji

niezbędnych dla projektowania formularzy.



str. 41

F01.07.038. Moduł formularzy musi zapewnić możliwość projektowania

formularzy, które będą mogły być wypełniane, przez użytkowników,

z poziomu przeglądarki internetowej. Pełna funkcjonalność

formularzy webowych powinna być dostępna co najmniej z poziomu

przeglądarki Internet Explorer (wersja 7.0 i nowsze). Podstawowa

funkcjonalność rozwiązania (nie powodująca jednak braku

możliwości wypełnienia i przekazania zaprojektowanego

formularza) powinna być dostępna z poziomu co najmniej

przeglądarki Mozilla Firefox (wersja 2.0 i nowsze). Specyficzne

funkcjonalności mogą działać z poziomu innych przeglądarek niż

Internet Explorer w ograniczonym zakresie.

F01.07.039. Moduł formularzy musi zapewnić zapisywanie/wysyłanie danych,

wprowadzonych na formularzu, w formacie XML.

F01.07.040. Moduł formularzy musi zapewnić możliwość wskazania miejsca

docelowego przechowywania dla zapisywanych/wysyłanych

danych.

F01.07.041. Moduł formularzy musi zapewnić możliwość testowego

sprawdzenia działania formularza (wypełnienia) bez konieczności

publikowania go w środowisku intranetowym.

F01.07.042. Moduł formularzy musi mieć możliwość automatycznego

publikowania formularza w Portalu Korporacyjnym GUS, w

bibliotece formularzy wskazanej przez projektanta oraz zapewniać

możliwość wypełnienia go przez użytkownika z poziomu Portalu

Korporacyjnego GUS.

F01.07.043. Moduł formularzy musi dodatkowo zapewniać możliwość

publikowania formularzy w lokalizacji sieciowej w tym na ESP oraz

wysłania go do listy adresatów e-mail.



str. 42

F01.07.044. Moduł formularzy musi pozwolić na automatyczne tworzenie

formularza na podstawie dokumentu XML lub schematu xsd.

F01.07.045. Moduł formularzy musi pozwolić na automatyczne tworzenie

formularza na podstawie bazy danych MS SQL, bądź MS Access

jako źródła danych dla formularza.

F01.07.046. Moduł formularzy musi pozwalać na generowanie różnych

widoków danych, w tym widoku do wydruku.

F01.07.047. Moduł formularzy musi dawać możliwość wydrukowania

wypełnionego formularza zgodnie z przygotowanym widokiem

wydruku.

F01.07.048. Moduł formularzy musi być wyposażony w prosty w obsłudze

edytor typu WYSIWYG (What You See Is What You Get) do

tworzenia, publikowania i udostępniania formularzy elektronicznych

pozwalający co najmniej na:

a) zdefiniowanie układu formularza,

b) określenie wielkości, rodzaju i koloru czcionki oraz koloru

wyróżnienia,

c) pogrubienie, zastosowanie kursywy i podkreślenie tekstu,

d) wyrównanie tekstu do lewej, prawej, do środka lub wyjustowanie,

e) numerowanie i wstawianie punktorów,

f) wstawienia nagłówka i stopki,

g) wstawianie symboli.

F01.07.049. Edytor formularzy musi umożliwiać definiowanie reguł

walidacyjnych dla wprowadzanych danych np. dopuszczalna ilość

znaków.

F01.07.050. Edytor formularzy musi pozwalać na wykorzystanie przy

tworzeniu formularza co najmniej następujących typów pól:

a) pole tekstowe,



str. 43

b) pole tekstu sformatowanego posiadające edytor umożliwiający

formatowanie wpisywanej treści,

c) lista rozwijana,

d) pole zaznaczenia (checkbox),

e) pole wyboru (radio),

f)przycisk do generowania zdarzeń,

g) pole przesyłania pliku (załącznik),

h) link umożliwiający umieszczenie adresu URL,

i) wybór daty w formie kalendarza,

j) pole tabeli danych umożliwiające dodawanie, usuwanie, edycję

danych,

k) pole sekcji,

l) pole sekcji powtarzalnej,

m) wyrażenie XPath.

F01.07.051. Pole tekstowe musi mieć możliwość prostego ograniczenia

wprowadzanych wartości co najmniej do następującego typu

danych:

a) tekst (string),

b) liczba całkowita (integer),

c) prawda/fałsz (boolean),

d) ułamek dziesiętny (double),

e) hiperłącze,

f) data,

g) data i godzina.

F01.07.052. Pole tekstu sformatowanego musi zapewnić:

a) możliwość zawijania tekstu,

b) pokazywania pasków przewijania jeśli jest to konieczne,

c) rozszerzenia wielkości pola, aby widoczny był cały tekst.

F01.07.053. Edytor formularzy musi umożliwiać oprogramowanie zdarzeń,

przycisków, wprowadzania reguł, wstawiania wartości domyślnej i Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 44

formatowania warunkowego bez znajomości języków

programowania.

F01.07.054. Edytor formularzy musi posiadać łatwo dostępne przyciski

narzędziowe, które pozwolą wykonać następujące czynności:

a) dodaj obrazek tła formularza,

b) ustaw kolor tła formularza,

c) wytnij/kopiuj/wklej – osobne przyciski pozwalające na wykonanie

określonych czynności na pojedynczych elementach formularza,

bądź grupach elementów,

d) zmień rozmiar i rodzaj czcionki – osobne przyciski do

zwiększania i zmniejszania rozmiaru oraz menu rozwijalne

z możliwością wyboru czcionki.

F01.07.055. Moduł musi umożliwiać podłączenie formularza, zarówno w celu

przesłania danych, jak i odebrania danych, pod zewnętrzne źródło

danych w postaci co najmniej takich obiektów jak: dokument XML,

baza danych MS SQL (w celu pobrania danych), usługa sieci web

(web service), repozytorium Portalu Korporacyjnego (tylko wysłanie

danych), lista Portalu Korporacyjnego (tylko pobranie danych),

wiadomość e-mail.

F01.07.056. Edytor formularzy musi umożliwiać walidowanie poprawności

konstrukcji formularza. W przypadku wystąpienia błędów moduł

musi zapewnić wyświetlenie odpowiednich, zrozumiałych

komunikatów o błędach.

F01.07.057. Edytor formularzy musi umożliwiać utworzenie powiązanego

z szablonem formularza schematu widoku formularza w wersji do

wydruku.



str. 45

1.8 PRZECHOWYWANIE I ANALIZA DANYCH

1.8.1 KONTROLA I WERSJONOWANIE

F01.08.001. System musi dysponować następującymi wbudowanymi

mechanizmami:

a) wyewidencjonowanie – blokada zapisu elementu na czas jego

modyfikacji przez jednego z użytkowników,

b) zatwierdzanie – blokada publikacji elementu, który nie uzyskał

wcześniejszej akceptacji,

c) wersjonowanie – mechanizm oznaczania kolejnych zmian,

poprzez nadawanie automatycznego numeru dla całego

zmienianego elementu, z możliwością podglądu i przywrócenia

dowolnej wersji archiwalnej.

F01.08.002. System musi pozwalać na numerowanie wersji głównych i

pomocniczych.

F01.08.003. System musi być wyposażony w mechanizmy umożliwiające

wersjonowanie co najmniej następujących elementów:

a) pism, w tym utworzonych przy użyciu aplikacji zewnętrznych,

b) umieszczanych dokumentów,

c) szablonów pism,

d) definicji metadanych wykorzystywanych do opisu elementów,

e) treści publikowanych w systemie (innych niż dokumenty).

F01.08.004. System musi umożliwiać przechowywanie informację o historii

wszystkich czynności wykonanych przez użytkowników podczas

pracy z dokumentami oraz podczas prowadzenia spraw.

F01.08.005. Uprawniony użytkownik, przeglądając udostępniony plik, musi mieć

możliwość zapisania jego kopii na lokalnym dysku swego

komputera.



str. 46

F01.08.006. Wyewidencjonowany (edytowany) plik nie może być pobrany do

edycji przez innych użytkowników, uzyskają oni jedynie prawo „do

wglądu” do zawartości pliku.

F01.08.007. Na zbiorczej liście plik wyewidencjonowany oznaczony zostanie

nazwą użytkownika, który aktualnie nad nim pracuje.

F01.08.008. Po wprowadzeniu zmian do pliku, może on być zwrócony

i ponownie udostępniony do edycji dla pozostałych, uprawnionych

do tego użytkowników.

F01.08.009. System musi pozwalać na określenie osób mogących modyfikować

dane w poszczególnych kolumnach list i bibliotek.

F01.08.010. System musi umożliwiać opcjonalne ukrywanie całych kolumn list

i bibliotek wraz z nagłówkiem.

F01.08.011. System oprócz zarządzania uprawnieniami dostępu do

poszczególnych elementów list lub bibliotek musi umożliwić

nadawanie oraz odbieranie uprawnień do określonej kategorii

danych (kolumn list lub bibliotek) co najmniej na następujących

poziomach:

a) edytowanie i wyświetlenie – pełny dostęp do danych z

kolumny,

b) wyświetlenie – może tylko oglądać dane a nie może ich

edytować,

c) brak dostępu

F01.08.012. System musi zabezpieczać chronione informacje przed

niepowołanym dostępem co najmniej w:

a) formularzach listy,

b) alertach,

c) widokach listy (biblioteki),

d) microsoft Excel – eksport do Excel może być możliwy tylko dla

tych danych, do których użytkownik ma dostęp,



str. 47

e) microsoft Access – eksport do Access może być możliwy tylko

dla tych danych, do których użytkownik ma dostęp,

f) usługach web services.

F01.08.013. Uprawnienia muszą być nadawane w samym systemie za

pośrednictwem formularzy.

F01.08.014. Zdefiniowane prawa dostępu muszą objąć zarówno istniejące, jak i

nowo tworzone widoki.

1.8.2 TWORZENIE RAPORTÓW

F01.08.015. System musi być wyposażony w moduł pozwalający na tworzenie

raportów w oparciu o podstawowe dane z użytkowania systemu

(m.in. ilość odwiedzin, najczęściej przeglądane strony, zrealizowane

sprawy, niewykonane zadania, itp.).

F01.08.016. System musi umożliwiać tworzenie raportów parametryzowanych,

czyli takich, dla których część kryteriów jest predefiniowana, a część

podawana przez użytkownika w momencie generowania raportu,

przez przeszkolonych użytkowników bez konieczności używania

języka SQL.

F01.08.017. Raporty z funkcjonowania systemu muszą być podzielone na co

najmniej cztery podstawowe grupy:

a) bezpieczeństwa – informacje o próbach naruszenia

bezpieczeństwa danych, próbach nieautoryzowanego dostępu,

próbach włamań do sytemu, komunikaty o błędach, stan

wykonania backup-ów itd.,

b) aktywności użytkowników – informacje o ilości logowań do

systemu, czasie logowań, itp.,

c) przepływów pracy – informacja o poziomie zaawansowania

realizacji zadań i sprawy, uczestnikach, dokumentach itp.,



str. 48

d) wydajności systemu – informacje o czasach reakcji,

wyszukiwania, zajętości zasobów, itp..

F01.08.018. System musi umożliwiać wykorzystanie, jako źródeł danych, baz

danych przechowujących dane systemu, przy czym chodzi tu

zarówno o bazę centralną, jak i bazy lokalne (o ile takie wystąpią).

F01.08.019. System musi umożliwiać definiowanie wielu takich źródeł danych

(baz danych systemu) dla generowanych raportów.

F01.08.020. System musi umożliwiać tworzenie raportów zawierających na

jednym zestawieniu/wydruku dane z wielu źródeł danych (baz

danych systemu) jednocześnie.

F01.08.021. System musi umożliwiać zadawanie zapytań do bazy danych za

pomocą języka SQL.

F01.08.022. System musi umożliwiać definiowanie raportu na podstawie

obiektów biznesowych.

F01.08.023. System musi umożliwiać prezentację raportów w formie

tabelarycznej.

F01.08.024. System musi umożliwiać prezentację raportów w formie graficznej.

F01.08.025. System musi umożliwiać prezentację raportów w formie tabel

przestawnych.

F01.08.026. System musi umożliwiać generowanie raportów zawierających

podsumowania częściowe i całkowite.

F01.08.027. System musi umożliwiać wydruk raportu.

F01.08.028. System musi umożliwiać zapis raportu do zewnętrznej relacyjnej

bazy danych.

F01.08.029. System musi umożliwiać zapis raportu do pliku – m.in.

do: .CSV, .XLS, .HTML, .PDF.

F01.08.030. System musi umożliwiać udostępnianie raportów na stronach



str. 49

portalu korporacyjnego wybranym użytkownikom lub grupom

użytkowników.

F01.08.031. System musi umożliwiać zapisanie wyników raportu jako

dokumentu i wprowadzenie go do obiegu dokumentów (dołączenie

do procesów przepływu pracy, przypisanie do sprawy itd.).

F01.08.032. System musi umożliwiać wielokrotne tworzenie raportów w oparciu

o zdefiniowane szablony – ręcznie przez użytkownika i

automatycznie z możliwością zdefiniowania harmonogramu

publikacji.

F01.08.033. System musi umożliwić przechowywanie listy wygenerowanych

raportów wszystkich typów wraz z wskazanymi wygenerowanymi

raportami z kopią ich zawartości przy uwzględnieniu zasad

przechowywania zawartości, możliwych do zdefiniowania przez

uprawnionego do tego użytkownika.

F01.08.034. System musi umożliwiać sortowanie danych w raporcie według

dowolnej kombinacji prezentowanych wartości.

F01.08.035. System musi umożliwiać grupowanie danych w raporcie według

dowolnej kombinacji prezentowanych wartości.

F01.08.036. System musi umożliwiać grupowanie danych według interwałów

(np. miesięcy lub tygodni).

F01.08.037. System musi umożliwiać swobodną definicję kryteriów generowania

raportu.

F01.08.038. System musi umożliwiać dowolną kombinację kryteriów za pomocą

operatorów – co najmniej: „lub” oraz „i”.

F01.08.039. System musi umożliwiać zamieszczanie w wygenerowanym

raporcie dowolnych atrybutów obiektów spełniających zadane

kryteria.

F01.08.040. System musi umożliwić wykorzystanie SQL Server Reporting

Services do wyświetlania raportów w osadzonych na niej Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 50

(platformie portalowej) witrynach.

F01.08.041. System musi umożliwiać integrację publikowania podstawowych

raportów z działania systemu dla kadry zarządzającej

z funkcjonującym w statystyce centralnym serwerem raportów.

a) system musi umożliwiać automatyczne wygenerowanie i

zapisanie pliku w formacie HTML lub PDF w określonym katalogu

na serwerze raportowym,

b) Ilość i zawartość publikowanych raportów zostanie zdefiniowana

na etapie projektowym.

1.8.3 WYSZUKIWANIE

F01.08.042. System musi umożliwiać użytkownikom wyszukiwanie co najmniej

następujących typów informacji: dokumentów, osób, treści

opublikowanych na Portalu Korporacyjnym.

F01.08.043. System musi umożliwiać użytkownikom wyszukiwanie informacji

w oparciu o wskazane przez nich kryteria, w tym co najmniej

kryteria: przynależności dokumentów, osób i treści opublikowanych

wprost na PK do określonych kategorii tematycznych i formalnych.

F01.08.044. System musi umożliwiać wyszukiwanie wszystkich haseł wpisanych

przez użytkownika i występujących w tekście, a także konkretnego

ciągu haseł, jeśli jest wpisany w cudzysłów.

F01.08.045. System musi uwzględniać możliwość zastępowania części znaków

znajdujących się w haśle (np. znakiem „*”).

F01.08.046. System musi umożliwiać definiowanie kryteriów wyszukiwania

w dwóch trybach:

a) tryb prosty, w którym kryteria wpisywane byłyby w jednym polu,

b) tryb złożony, w którym możliwe byłoby zawężenie wyszukiwania

tylko do zadanych kategorii, zadanych wartości dowolnych

atrybutów szukanej informacji a także zadanego obszaru

wyszukiwania (np. cały system, dana witryna z podstronami, dane Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 51

repozytorium treści).

F01.08.047. Kryteria wyszukiwania muszą uwzględniać co najmniej takie

operatory jak: równy, nie równy, zawiera, nie zawiera, większy od,

mniejszy od, należy do (grupa osób/kategoria).

F01.08.048. Okno wyszukiwania prostego powinno być cały czas widoczne

podczas pracy z systemem SII. Cały czas widoczny powinien być

też przycisk umożliwiający przeście do formatki wyszukiwania

zaawansowanego.

F01.08.049. Funkcja wyszukiwania prostego musi zapamiętywać przynajmniej

10 ostatnio wpisanych przez użytkownika wyrażeń lub słów oraz

umożliwiać ich wybór z listy. Po wyborze szukane wyrażenie

powinno być automatycznie wpisywane do okna wyszukiwania.

F01.08.050. System musi kontrolować poziom uprawnień dostępu

do wyszukiwanej informacji - nie może w ogóle pokazywać treści,

do której użytkownik nie ma wystarczających uprawnień dostępu.

F01.08.051. System musi prezentować wynik wyszukania w formie listy

elementów z co najmniej: nazwą elementu, typem elementu,

podanym odnośnikiem do lokalizacji elementu i, jeżeli to możliwe, to

z fragmentem treści elementu lub z wybranymi metadanymi

opisującymi element.

F01.08.052. System musi umożliwiać pogrupowanie wyniku wyszukania (listy

elementów), co najmniej według typu elementu.

F01.08.053. System musi umożliwiać stronicowanie wyniku wyszukania (listy

elementów) i definiowanie przez użytkownika liczby elementów

pokazywanych na jednej stronie.

F01.08.054. System musi pokazywać całkowitą liczbę wyszukanych elementów.

F01.08.055. System musi mieć możliwość wyszukiwania „pełnotekstowego”

w popularnych formatach plików, w szczególności w plikach pakietu

Office, plikach XML, przeszukiwalnych PDF, plikach tekstowych Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 52

oraz listach znajdujących się w repozytoriach dokumentów, witrynie

czy grupie witryn.

F01.08.056. System musi mieć możliwość rozszerzenia wyszukiwania (w tym

wyszukiwania pełnotekstowego – tam, gdzie to jest możliwe) na

inne formaty plików, poprzez mechanizm "wtyczek" – gotowych

komponentów, które dołącza się do systemu, w celu zwiększenia

jego funkcjonalności.

F01.08.057. System musi mieć możliwość indeksowania zawartości portalu,

w celu polepszenia szybkości wyszukiwania szczególnie często

stosowanych fraz.

F01.08.058. System musi mieć możliwość gromadzenia i śledzenia statystyk

wyszukiwanych fraz.

F01.08.059. System musi umożliwić kojarzenie alertów mailowych oraz

mechanizmu RSS z wynikami wyszukiwania, w celu informowania

użytkownika o pojawieniu się treści spełniającej zadane kryteria.

F01.08.060. System zapewni możliwość eksportu wyników wyszukiwania do

pliku (w postaci dokumentu XML).

1.8.4 INDYWIDUALNY KALENDARZ PRACOWNIKA

F01.08.061. System powinien udostępniać funkcję indywidualnego kalendarza

każdego z pracowników.

F01.08.062. Kalendarz pracownika musi przedstawiać w formie graficznej

informacje na temat nieobecności czy spotkań z podziałem co

najmniej na: dzień, tydzień, miesiąc.

F01.08.063. Kalendarz pracownika musi umożliwiać wprowadzanie różnych

rodzajów nieobecności i zajęć zarówno całodniowych jak i

w określonym przedziale czasu, jak również pozwolić na zapisanie

informacji o wydarzeniach cyklicznych.

F01.08.064. Kalendarz pracownika musi zapewnić funkcjonalność pozwalającą Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 53

na automatyczne umieszczenie w nim informacji, np.

o nieobecnościach, pozyskanych i przetworzonych w ramach

procesów SEOD, np. wniosku urlopowego czy delegacji.

F01.08.065. Możliwość zapisania informacji w kalendarzu musi być dostępna w

module zarządzania procesami podczas projektowania procesu.

F01.08.066. Kalendarz pracownika musi zapewnić interfejs graficzny

umożliwiający ręczne wprowadzenie informacji niezbędnych

do umieszczenia w kalendarzu np. planowane spotkania.

F01.08.067. Przy ręcznym wprowadzaniu informacji musi być możliwość

określenia, czy informacja ta ma charakter publiczny, służbowy, czy

prywatny. Domyślnym statusem nowo wprowadzanej informacji jest

status służbowy.

F01.08.068. Kalendarz centralny pracownika musi być dostępny dla danego

pracownika oraz jego przełożonych. Dodatkowo system musi

umożliwić dodanie uprawnień w trybie edycji i do odczytu innym

użytkownikom w zależności od potrzeb.

F01.08.069. Kalendarz pracownika musi posiadać co najmniej trzy widoki:

c) prywatny – dostępny tylko dla użytkownika; zawierający

wszystkie dane, w tym wprowadzone przez użytkownika

informacje o charakterze prywatnym,

d) służbowy – dostępny dla pracownika i jego przełożonych oraz

pracowników kadr; zawierający wszystkie informacje

pochodzące z procesów oraz inne oznaczone jako służbowe,

e) publiczny – dostępny dla wszystkich innych użytkowników,

zawierający informacje ogólne, np. o nieobecności, ale bez

określania jej przyczyny, oraz informacje określone jako

publiczne.

F01.08.070. System musi zapewniać dwustronną synchronizację elementów z

używanym w środowisku Zamawiającego MS Outlook 2007/2010.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 54

F01.08.071. System musi zapewniać przeglądanie kalendarzy pracowników

jednostek statystyki publicznej.

F01.08.072. System musi umożliwiać planowanie spotkań z wieloma

pracownikami.

F01.08.073. System musi umożliwić stworzenie dla każdego spotkania obszaru

roboczego umożliwiającego co najmniej: organizację użytkowników,

umieszczanie komunikatów, dodawanie dokumentów, ustalanie

porządku spotkania, przydzielanie zadań.

F01.08.074. System musi zapewniać zaawansowane narzędzia do planowania

terminów z wykorzystaniem danych zawartych w książce

adresowej.

F01.08.075. System musi umożliwiać tworzenie zaawansowanych filtrów

w oparciu o terminy, numery sal konferencyjnych i dane

użytkowników.

F01.08.076. System musi zapewnić możliwość wysłania wiadomości e-mail i/lub

umieszczenia powiadomienia w witrynie osobistej użytkownika,

któremu w kalendarzu dodano, zmodyfikowano lub usunięto termin

spotkania bądź inny termin lub wydarzenie.

F01.08.077. System musi zapewniać odnotowanie w kalendarzu użytkownika

informacji o dokonanej przez niego rezerwacji sali konferencyjnej

bądź innych wskazanych zasobów.

F01.08.078. System musi, w czasie zdefiniowanym przez użytkownika

wprowadzającego informację o wydarzeniu, przypominać

uczestnikom o zbliżającym się terminie tego wydarzenia.

F01.08.079. System musi automatycznie aktualizować informacje w kalendarzu

w trybie rzeczywistym.

F01.08.080. System musi pozwolić na prosty dostęp uprawnionych

użytkowników do raportów rozliczania czasu pracy generowanych

w czasie rzeczywistym: Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 55

a) ilości wolnych dni urlopowych pozostałych do wykorzystania do

końca roku z podziałem na poszczególne typy dni urlopowych (np.

wypoczynkowy, szkolny czy okolicznościowy),

b) ilości nadgodzin/godzin do przepracowania w danym miesiącu,

c) ilość nadgodzin/godzin przepracowanych w danym miesiącu,

d) ilość nadgodzin/godzin do przepracowania w danym roku,

e) ilość nadgodzin/godzin przepracowanych w danym roku,

f) ilość godzin nieobecności w danym miesiącu (np. z tytułu urlopu,

choroby czy delegacji),

g) ilość dni nieobecności w danym roku z tytułu zwolnień lekarskich

i zwolnień na opiekę nad chorym członkiem rodziny,

h) innych raportów definiowanych za pomocą modułu tworzenia

raportów.

F01.08.081. System musi umożliwić każdemu pracownikowi wypełnienie na

koniec miesiąca rozliczenia czasu pracy zgodnie z przyjętym w

statystyce wzorem, zawierającego informacje o nieobecnościach

pozyskane z procesów SEOD.

F01.08.082. System musi pozwolić w prosty sposób na wydruk

wygenerowanego podsumowania za dany miesiąc.

1.9 PORTAL KORPORACYJNY

1.9.1 WYGLĄD I LOGIKA DZIAŁANIA

F01.09.001. Wykonawca we współpracy z Zamawiającym zaprojektuje, wdroży

i dostosuje intranetowy Portal Korporacyjny GUS rozumiany jako

wewnętrzny serwis (strony w technologii internetowej), dzięki

któremu za pomocą przeglądarki internetowej pracownik uzyskuje

dostęp do firmowych informacji, aplikacji, dokumentów oraz poczty.



str. 56

F01.09.002. Portal Korporacyjny musi zawierać stronę główną dostępną pod

wskazanym adresem. Wszystkie moduły, aplikacje, witryny, obszary

robocze itp. musza być podstronami strony głównej.

F01.09.003. Portal zostanie przez wykonawcę dostosowany w warstwie

graficznej do wytycznych identyfikacji wizualnej firmy oraz musi

umożliwić dostosowanie funkcjonalności do potrzeb

poszczególnych oddziałów/komórek organizacyjnych.

F01.09.004. Dostęp do poszczególnych modułów/aplikacji/witryn czy obszarów

roboczych będzie odbywał się za pomocą menu umieszczonego na

stronie głównej.

F01.09.005. Strona główna Portalu musi zawierać m.in. następujące elementy:

a) informacje zamieszczane na Portalu,

b) odnośniki do modułów Portalu,

c) wyszukiwarkę Portalu,

d) odnośniki umożliwiające przejście do wybranych procesów pracy.

F01.09.006. Strona główna Portalu musi zawierać następujące obszary:

a) obszar wspólny dla wszystkich jednostek Portalu,

b) obszar właściwej komórki organizacyjnej/oddziału,

c) witrynę osobistą pracownika.

F01.09.007. Portal musi udostępnić obszary funkcjonalne (witryny)

odzwierciedlające strukturę organizacyjną przedsiębiorstwa,

dokładny wygląd i zawartość poszczególnych obszarów zostanie

zdefiniowany na etapie projektu technicznego:

a) obszar wspólny prezentowany każdemu użytkownikowi -

publikacyjny, w którym prezentowane będą aktualności oraz



str. 57

nowe dokumenty przeznaczone dla użytkowników jak również

umożliwiający przejście w prosty sposób do poszczególnych

modułów PK oraz poszczególnych procesów biznesowych,

b) obszary robocze do pracy z dokumentami dla komórek

organizacyjnych wraz z obszarem publikacyjnym,

c) witryny osobiste użytkowników służące do publikowania pism

oraz prezentowania zagregowanych informacji o przydzielonych

użytkownikowi zadaniach związanych pismem, sprawą,

procesem biznesowym, a także o zbliżającym się terminie

realizacji zadania w całym portalu, tj. niezależnie od lokalizacji

(witryn, procesów biznesowych), w których te informacje się

znajdują, jak również zapewniające dostęp do indywidualnego

kalendarza pracownika.

F01.09.008. Witryny osobiste w zakresie publikowania dokumentów

prezentowane powinny być w trzech rodzajach widoków:

a) widok publiczny, tzn. prezentowany każdemu użytkownikowi,

b) widok prywatny, tzn. prezentowany tylko właścicielowi,

c) widok współdzielony, tzn. prezentowany tylko członkom

wybranej grupy, np. zespołu roboczego, w którego skład

wchodzi właściciel witryny.

F01.09.009. Portal musi także zawierać obszary sieci społecznościowej

umożliwiającej prowadzenie stron typu blog czy wiki, posiadających

funkcjonalności takie jak, m.in., znaczniki czy klasyfikowanie dla

opublikowanej treści.

F01.09.010. Portal musi stwarzać Zamawiającemu możliwość samodzielnej

rozbudowy o nowe obszary zastosowań.



str. 58

1.9.2 PUBLIKOWANIE I ZARZĄDZANIE TREŚCIĄ

F01.09.011. System musi umożliwiać wprowadzanie i edycję treści przy

wykorzystaniu przygotowanych szablonów lub dedykowanych

modułów funkcjonalnych.

F01.09.012. System musi mieć możliwość wprowadzania i edycji treści w trzech

trybach wyświetlania zawartości: zwykły tryb edycyjny (WYSIWYG),

tryb HTML, tryb podglądu strony (preview). System nie może

wymagać od autorów treści znajomości języka HTML lub innej

specjalistycznej technologii prezentacji publikowanej treści.

F01.09.013. System musi umożliwiać proste publikowanie i zarządzanie co

najmniej:

a) komunikatami (krótki tekst formatowany),

b) artykułami (dłuższy tekst formatowany),

c) zbiorami łączy do stron WWW,

d) zbiorami plików multimedialnych (zdjęcia, animacje, pliki audio,

pliki wideo),

e) wykazami osób/użytkowników systemu,

f) wykazami terminów (kalendarz).

F01.09.014. System musi zapewnić możliwość komentowania i oceniania

komunikatów czy artykułów.

F01.09.015. System musi umożliwiać automatyczną publikację daty

wprowadzenia treści oraz autora publikacji.

F01.09.016. System musi umożliwiać dołączanie załączników do publikowanej

treści.

F01.09.017. Moduł zapewni zaawansowane formatowania tekstu oraz tabel.

F01.09.018. Każdy edytowany element będzie mógł być wzbogacony przez -

znajdujące się w katalogu lub nowe (wgrane z dysku lokalnego

użytkownika) ilustracje.



str. 59

F01.09.019. Użytkownik będzie mógł zdecydować o sposobie wyświetlania takiej

ilustracji, tj. miejscu położenia, wielkości, sposobie wyrównania

tekstu, podpisie, możliwości otwarcia powiększonej ilustracji

w nowym oknie.

F01.09.020. System musi umożliwiać wstawienie odwołania w postaci linku do

wybranych przez użytkownika innych treści.

F01.09.021. System musi umożliwiać użytkownikowi wskazanie miejsca

publikacji treści.

F01.09.022. System musi umożliwiać wprowadzanie treści w zdefiniowanych,

wybranych przez uprawnionego użytkownika sekcjach

tematycznych.

F01.09.023. System musi umożliwiać ustalanie reguł i etapów akceptacji treści

oraz ustalanie użytkowników do tej akceptacji uprawnionych.

F01.09.024. System musi umożliwiać monitorowanie statusu akceptacji treści

(np. w przygotowaniu, zgłoszone do akceptacji, w trakcie

weryfikacji, do poprawek, zaakceptowane, itp.).

F01.09.025. System musi umożliwiać publikację treści po zatwierdzeniu przez

uprawnionego użytkownika/użytkowników.

F01.09.026. System musi umożliwiać odesłanie treści do autora w celu

wprowadzenia poprawek.

F01.09.027. System musi umożliwiać dołączanie komentarzy do statusu

akceptacji treści.

F01.09.028. System musi umożliwiać zdefiniowanie reguł dostępności treści dla

osoby lub grupy osób będących użytkownikami Systemu.

F01.09.029. System musi umożliwiać zdefiniowanie reguł dostępności treści

w czasie - co najmniej: terminu początku poblikacji, terminu

zakończenia publikacji, po upłynięciu okresu publikacji treść

automatycznie przenoszona będzie do lokalnego repozytorium

publikacji. Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 60

F01.09.030. System musi domyślnie wyświetlać wiadomości od najnowszej do

najstarszej, zmiana sortowania będzie możliwa według dowolnego

pola znajdującego się w widoku okna głównego.

F01.09.031. System musi umożliwiać wersjonowanie treści oraz przegląd historii

wprowadzanych zmian, z możliwością przywracania i publikacji

wybranej historycznej wersji treści.

F01.09.032. System musi umożliwiać modyfikację zarówno układu treści

warstwy grupowej/korporacyjnej jak i warstwy indywidualnej.

F01.09.033. System musi umożliwiać tworzenie i dodawanie elementów

funkcjonalnych do układu treści.

F01.09.034. System musi umożliwiać dodawanie gotowych elementów

funkcjonalnych, takich jak np. kalendarz, wykaz dokumentów, lista

zadań, lista odnośników, ankieta.

F01.09.035. System musi umożliwiać zarządzanie układem wizualnym

poszczególnych elementów funkcjonalnych - przede wszystkim:

umiejscowieniem elementu funkcjonalnego w obszarze

publikowania, nazwą elementu funkcjonalnego czy widocznością

elementu funkcjonalnego.

F01.09.036. System musi umożliwiać tworzenie i późniejsze wykorzystanie

szablonów dla obszarów Systemu z predefiniowanym układem

i wyglądem elementów funkcjonalnych.

F01.09.037. System musi umożliwiać publikowanie zdalnych portletów zgodnych

z protokołem WSRP.

F01.09.038. System musi umożliwiać jednokrotne logowanie pomiędzy

opublikowanymi portletami.

1.9.3 REPOZYTORIUM DOKUMENTÓW PORTALU KORPORACYJNEGO

F01.09.039. System musi oferować, pod postacią repozytorium dokumentów, Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 61

możliwość przechowywania i zarządzania dokumentami

wykorzystywanymi do pracy bieżącej i nie wchodzącymi w żadne

procesy obiegu dokumentów.

F01.09.040. System musi umożliwiać utworzenie dowolnej liczby, niezależnych

od siebie, repozytoriów dokumentów.

F01.09.041. System musi umożliwiać dostęp do repozytorium dokumentów

poprzez konfigurowalny element funkcjonalny, z możliwością

prezentacji wykazu dokumentów w postaci modyfikowalnej listy,

którą można wykorzystać na dowolnej witrynie PK.

F01.09.042. System musi oferować możliwość zapamiętania zdefiniowanego

sposobu prezentacji repozytorium dokumentów i możliwość

zapisania tego sposobu w szablonach do wielokrotnego użycia –

tzw. widokach, przy czym musi oferować możliwość zapamiętania

co najmniej następujących informacji: występowanie i kolejność

atrybutów, porządek sortowania dokumentów, ustawienia

grupowania.

F01.09.043. Funkcjonalność repozytorium dokumentów musi być kompatybilna

z ogólną funkcjonalnością Systemu w zakresie tworzenia i

publikowania treści, oraz wsparcia pracy grupowej –

w szczególności, repozytorium dokumentów musi umożliwiać co

najmniej: wersjonowanie dokumentów, przegląd historii

wprowadzonych zmian oraz pracę wielu osób nad jednym

dokumentem.

F01.09.044. Repozytorium dokumentów musi mieć możliwość definiowania

uprawnień dostępu do dokumentów w nim zgromadzonych, dla

osób lub grup osób.

F01.09.045. Repozytorium dokumentów musi móc przechowywać dokumenty

dowolnego typu, formatu i wielkości, przy czym musi być możliwość

ustawiania ograniczeń/filtrów na każdą z tych cech.



str. 62

F01.09.046. Repozytorium musi mieć możliwość ustawienia automatycznego

powiadamiania (co najmniej za pośrednictwem e-mail)

o zachodzących w nim zmianach – co najmniej o: nowym

dokumencie i zmianie treści/atrybutów dokumentu.

F01.09.047. Portal musi umożliwić pracę z dokumentami w następującym

zakresie:

a) praca z dokumentami przechowywanych w repozytoriach portalu

bezpośrednio z aplikacji pakietu biurowego

(otwieranie/zapisywanie dokumentów, podgląd wersji i możliwość

przywrócenia wersji, mechanizmy blokowania dokumentu przez

użytkownika do wyłącznej edycji, edycja metadanych

dokumentu),

b) możliwość pracy off-line z dokumentami przechowywanymi

w repozytoriach portalu,

c) możliwość zarządzania uprawnieniami na poziomie całych

lokalizacji, folderów lub pojedynczych dokumentów w

repozytorium.

F01.09.048. Portal powinien umożliwiać przechowywanie w obszarach

roboczych (witrynach) dokumentów wraz z ich metadanymi

w strukturze drzewiastej (foldery i pliki). Zestaw metadanych

skojarzonych z folderem lub dokumentem powinien zależeć

wyłącznie od typu tego elementu, a nie lokalizacji, w której

dokument został umieszczony.

F01.09.049. Portal powinien umożliwiać grupowe umieszczanie i pobieranie

plików do/z portalu na zasadzie udziału sieciowego, metodą

przeciągnij-i-upuść.

F01.09.050. Portal powinien umożliwiać użytkownikom definiowanie widoków

w lokalizacjach przechowujących dokumenty, w ramach których

istnieje możliwość ustalenia:



str. 63

a) które atrybuty folderów i dokumentów pojawią się jako kolumny

widoku,

b) według jakich kolumn dane w widoku będą sortowane lub

grupowane,

c) jakie kryteria muszą spełniać dokumenty (warunki na

metadanych), aby się pojawiły w widoku,

d) czy dokumenty mają być prezentowane wewnątrz folderów, czy

w widoku „spłaszczonym” – na jednym poziomie.

F01.09.051. Portal powinien zapewniać łatwy mechanizm podłączania

odnośników do elementów powiązanych, w tym innych

dokumentów. Elementy powiązane powinny być wskazywane nie za

pomocą wprowadzania tekstowego odnośnika URL (np. metodą

kopiuj-wklej), ale w sposób graficzny, np. poprzez przeprowadzenie

wyszukiwania i podłączenia wybranych wyników wyszukiwania jako

elementów powiązanych.

F01.09.052. Portal powinien umożliwiać przekazywanie dokumentów

do poszczególnych lokalizacji bezpośrednio za pomocą poczty

elektronicznej.

F01.09.053. Portal musi udostępnić mechanizmy umożliwiające użytkownikom

przekazywanie dokumentów wraz z metadanymi pomiędzy

obszarami (witrynami) komórek organizacyjnych. Wskazywanie

lokalizacji docelowej powinno być możliwe w sposób graficzny (np.

struktura portalu w widoku drzewa), a nie poprzez wprowadzenie

tekstowo URL.

F01.09.054. Portal musi udostępnić mechanizmy jednoznacznie identyfikujące

dokument w portalu oraz pozwalające uzyskać trwały odnośnik

do dokumentu, który pozostanie aktualny także w sytuacji, kiedy

dokument zostanie przemieszczony pomiędzy różnymi lokalizacjami

w portalu lub nazwa dokumentu ulegnie zmianie.



str. 64

F01.09.055. System powinien pozwolić na otwieranie i zapisywanie dokumentów

bezpośrednio do repozytorium z programów pakietu MS Office

2007/2010 (co najmniej: Word, Excel, PowerPoint) zainstalowanych

na stacjach klienckich Zamawiającego.

F01.09.056. System musi mieć możliwość modyfikowania szablonu metadanych

dokumentów - dodawanie nowych metadanych z poziomu

administratora i automatyczne uwzględnianie tak dodanych

dodatkowych pól w funkcjach wyszukujących dokumenty.

F01.09.057. System musi zapewnić możliwość zdefiniowania w systemie

procesu zatwierdzania nowych lub modyfikowanych dokumentów.

System musi umożliwiać poinformowanie użytkowników

recenzujących materiały o oczekujących na nich elementach do

zatwierdzenia i pozwala podjąć decyzję o ich publikacji lub

odrzuceniu.

1.9.4 PRACA GRUPOWA

F01.09.058. System musi oferować możliwość utworzenia i zarządzania

specjalnymi witrynami, zwanymi obszarami pracy grupowej,

w których opublikowane będą treści/dokumenty przeznaczone tylko

dla wydzielonej grupy użytkowników.

F01.09.059. Obszary pracy grupowej muszą być zgodne pod względem

wizualnym oraz funkcjonalnym z całym systemem.

F01.09.060. Administracja obszarem pracy grupowej nie może wymagać

od administratora tego obszaru zaawansowanej wiedzy technicznej

i musi być realizowana w całości poprzez podstawowe

funkcjonalności systemu.

F01.09.061. System musi oferować możliwość łatwego i swobodnego

definiowania osób oraz grup osób, które mogą mieć dostęp Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 65

do obszarów pracy grupowej, także w strukturach rozproszonych.

F01.09.062. System musi oferować możliwość swobodnego definiowania

poziomów uprawnień do poszczególnych elementów funkcjonalnych

obszaru pracy grupowej oraz do treści/dokumentów tam

publikowanych.

F01.09.063. System zapewni generowanie powiadomień pocztą elektroniczną

dla użytkowników grupy z informacją o publikacji/modyfikacji treści.

F01.09.064. System zapewni funkcjonalność alertów informujących o zmianie

wcześniej zdefiniowanego fragmentu informacji bądź dodaniu

nowych informacji. Alerty wysyłane muszą być np. za pomocą

poczty e-mail bądź w formie okresowych zestawień, bądź

pojedynczych komunikatów, informujących o konkretnej zmianie.

F01.09.065. System musi oferować domyślnie co najmniej następujące poziomy

uprawnień do treści/dokumentów opublikowanych w obszarze pracy

grupowej.

a) poziom „Administratorzy” – pełny dostęp administracyjny

do obszaru (co najmniej czytanie, zapis i możliwość zmian

w układzie i podstawowej funkcjonalności obszaru pracy

grupowej),

b) poziom „Członkowie” – standardowy dostęp niezbędny do pracy

z treściami/dokumentami (co najmniej czytanie i zapis),

c) poziom „Czytający” – dostęp pozwalający tylko na przeglądanie

zawartości obszaru pracy grupowej (tylko czytanie).

F01.09.066. System musi udostępniać możliwość jednoczesnej pracy wielu

użytkowników nad jednym dokumentem.

F01.09.067. System musi udostępniać mechanizmy zabezpieczające

treści/dokumenty, opublikowane w obszarze pracy grupowej, przed

przypadkowym nadpisaniem/usunięciem w przypadku dostępu

wielu osób jednocześnie.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 66

F01.09.068. System zapewni synchronizację wersji po zakończeniu pracy, tak by

wszyscy mieli dostęp do najbardziej aktualnych wersji.

F01.09.069. System musi umożliwiać śledzenie zmian dokonywanych przez

użytkowników przechowując informację co najmniej o autorze

i czasie zmiany.

F01.09.070. System zapewni możliwość tworzenia obszaru roboczego

dokumentu zawierającego narzędzia i informacje pomocne podczas

wspólnej pracy nad dokumentem.

F01.09.071. System musi zapewnić mechanizmy pracy grupowej nad projektami

dokumentów. W szczególności system umożliwi utworzenie witryny

pracy grupowej nad dokumentem posiadającej co najmniej

możliwości:

a) określenia harmonogramu prac nad dokumentem,

b) przypisania zadań,

c) tworzenia dokumentów roboczych, załączników itp.,

d) określenie norm, jakim powinien odpowiadać dokument.

F01.09.072. System zapewni funkcjonalności wspierające gromadzenie

dokumentów, wsparcie komunikacji, planowanie zadań i wydarzeń.

F01.09.073. Moduł pracy grupowej zapewni mechanizm przepływu pracy.

F01.09.074. W ramach przepływu pracy w module pracy grupowej dokument

może zostać przesłany do określonej osoby lub grupy osób w celu

uzyskania recenzji i zatwierdzenia, a następnie, względem

dokumentu mogą zostać wykonane akcje zależne od wyniku tego

przepływu.

F01.09.075. Jeśli dokument zostanie zatwierdzony, jego stan może zostać

zaktualizowany i dokument może zostać automatycznie skopiowany

do repozytorium dokumentów.

F01.09.076. Jeśli dokument zostanie odrzucony, jego stan może pozostać

niezmieniony i nie zostaną podjęte żadne dalsze akcje.

F01.09.077. W trakcie wykonywania przepływu pracy jego uczestnicy mogą

wyświetlać stronę informującą o stanie przepływu, aby sprawdzić, Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 67

którzy z uczestników ukończyli swoje zadania w ramach przepływu

pracy.

F01.09.078. Gdy uczestnicy przepływu pracy ukończą swoje zadania w ramach

przepływu pracy, zatwierdzając lub odrzucając dokument, przepływ

pracy dobiega końca.

F01.09.079. W przepływie pracy automatycznie są wykonywane odpowiednie

akcje w odniesieniu do dokumentu i do zdefiniowanych osób

wysyłany jest alert z wynikiem przepływu pracy.

1.9.5 PRACA OFFLINE

F01.09.080. System musi umożliwić wybranym użytkownikom na korzystanie

z witryn Portalu Korporacyjnego w trybie offline przy jednocześnie

zachowanych funkcjach edycji.

F01.09.081. System musi pozwalać na początkowe pobranie określonej

zawartości witryny oraz dostęp do niej w trybie offline.

F01.09.082. System musi zapewnić pełen dostęp do witryn współpracy

zespołowej wliczając w to biblioteki dokumentów, listy i dyskusje.

F01.09.083. System musi umożliwić pracę nad dokumentami

w zsynchronizowanej witrynie.

F01.09.084. System musi umożliwiać przeprowadzenie procesu synchronizacji

(w obu kierunkach) w dowolnym momencie oraz sprawdzenie stanu

ostatnio przeprowadzonej synchronizacji.

1.9.6 KSIĄŻKA ADRESOWA PRACOWNIKÓW

F01.09.085. W Portalu Korporacyjnym GUS zostanie przygotowany moduł

zawierający książkę teleadresową pracowników jednostek statystyki

publicznej, do której dane będą automatycznie pobierane z katalogu



str. 68

LDAP.

F01.09.086. Książka adresowa będzie zawierała co najmniej następujące

informacje:

a) imię,

b) nazwisko,

c) stanowisko,

d) jednostka/komórka organizacyjna,

e) telefon wewnętrzny,

f) telefon komórkowy,

g) adres e-mail,

h) miasto,

i)lokalizacja biura (budynek, pokój).

F01.09.087. System musi umożliwić wyszukiwanie pracowników za pomocą

okna zawierającego kryteria wyszukiwania, po wprowadzeniu

danych dotyczących szukanej osoby zostaną wyświetlone

wszystkie osoby spełniające odpowiednie kryteria domyślnie

posortowane wg nazwiska. Kryteriami wyszukiwania mogą być

wszystkie wartości, jakimi opisany jest pracownik.

F01.09.088. System musi umożliwić posortowanie wyników po dowolnej

kolumnie.

F01.09.089. Wybranie odpowiedniej osoby spowoduje wyświetlenie okna

zawierającego wszystkie informacje dotyczące danej osoby.

F01.09.090. System musi zapewnić prosty wydruk wyświetlonej listy

pracowników oraz informacji o wybranej osobie.

F01.09.091. System musi umożliwiać definiowanie prywatnych list

kontaktowych.

F01.09.092. System musi umożliwiać definiowanie dowolnej liczby list

kontaktowych oraz udostępnianie ich zdefiniowanym grupom

użytkowników.



str. 69

1.10 PRACA Z PISMAMI, ZADANIAMI I SPRAWAMI

1.10.1 OGÓLNE

F01.10.001. System musi umożliwiać obsługę pism zeskanowanych,

dostarczonych w postaci elektronicznej z załącznikami w postaci

plików, poprzez pocztę elektroniczną, z modułu elektronicznej

skrzynki podawczej, za pomocą nośników cyfrowych (płyty CD i

DVD, pamięci Flash), poprzez faksmodem, jak również

wygenerowanych w systemie oraz na PC użytkowników poza

systemem.

F01.10.003. System wraz z pismami musi przechowywać ich metadane,

logicznie powiązane z właściwym pismem informacje opisujące

dany dokument.

F01.10.004. System zapewni możliwość eksportu metadanych pisma w postaci

dokumentu XML.

F01.10.005. System zapewni możliwość tworzenia relacji pomiędzy pismami.

Musi istnieć możliwość zdefiniowania co najmniej następujących

rodzajów powiązań:

a) odpowiedź na wskazane pismo,

b) aneks do wskazanego pisma,

c) notatka do wskazanego pisma,

d) dekretacja.

1.10.2 SKANOWANIE PISM

F01.10.006. System musi umożliwiać skanowanie pism bezpośrednio z poziomu

wbudowanego narzędzia uruchamianego i osadzonego w oknie

przeglądarki oraz przechowywanie ich w postaci źródłowej w bazie

danych lub w systemie plików np. folder sieciowy.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 70

F01.10.007. System musi umożliwiać automatyczne (bez ingerencji

użytkownika) skanowanie dokumentów papierowych do formatu

przeszukiwalnego PDF i przechowywanie w formacie PDF/A

pozwalającym na wyszukiwanie pełnotekstowe przez wyszukiwarkę

systemu.

F01.10.008. System musi umożliwiać zmniejszenie wielkości skanowanych

plików poprzez domyślne ustawienie skanowania do trybu czarno-

białego oraz zmianę (zmniejszenie) rozdzielczości zeskanowanego

dokumentu co najmniej do 150 dpi.

F01.10.009. Przy domyślnym ustawieniu skanowania w trybie czarno-białym

i zmniejszaniu rozdzielczości, system musi umożliwiać ręczne

ustawienie skanowania pisma np. zawierającego grafikę w kolorze i

w rozdzielczości obrazu źródłowego.

F01.10.010. Zamawiający, z uwagi na wydajność sieci WAN, nie dopuszcza

zainstalowania centralnego serwera skanowania w lokalizacji

w Warszawie. Zamawiający dopuszcza instalację serwerów

skanowania w lokalizacjach Urzędów Statystycznych obsługujących

swoje oddziały każdy, jak również instalację dodatkowego

oprogramowania na stanowiskach w kancelariach wszystkich

jednostek.

F01.10.011. Zamawiający na poziomie Urzędów Statystycznych dysponuje

odpowiednim środowiskiem niezbędnym do zainstalowania

serwerów skanowania oraz dodatkowych aplikacji.

F01.10.012. System musi umożliwić wyświetlenie zeskanowanych pism.

F01.10.013. System musi umożliwić digitalizację pism papierowych przynajmniej

w formatach A3, A4, A5, B5, letter.

F01.10.014. System musi zapewnić możliwość skanowania masowego (wraz z

łączeniem zeskanowanych stron do jednego pliku), z późniejszym

uzupełnieniem metadanych pism.



str. 71

F01.10.015. System musi zapewnić współpracę ze skanerami sieciowymi i

standardowymi (interfejs TWAIN).

F01.10.016. System musi umożliwiać skanowanie zarówno jednostronnych jak i

dwustronnych dokumentów.

F01.10.017. System musi umożliwiać poprawę jakości zeskanowanego obrazu.

F01.10.018. System musi umożliwiać oznaczanie kodem kreskowym pisma

papierowego (nadruk, naklejka), ewidencjonowanie w systemie

przydzielonego pismu kodu kreskowego oraz identyfikowanie pisma

przy użyciu czytnika kodów kreskowych.

F01.10.019. System musi umożliwiać automatyczne przenoszenie

zdigitalizowanych pism do SEOD.

F01.10.020. System musi umożliwiać konwersję plików graficznych do

wybranych formatów (PDF – w tym przeszukiwalny, GIF, TIFF).

F01.10.021. System musi dawać możliwość elastycznego definiowania

konwencji nazewniczej dokumentów.

F01.10.022. System musi umożliwić nadanie znaku sprawy podczas

wprowadzania pisma do systemu według instrukcji kancelaryjnej

Zamawiającego.

1.10.3 REJESTRACJA DOKUMENTÓW WPŁYWAJĄCYCH

F01.10.023. System musi zapewnić jednoczesne, wielostanowiskowe

rejestrowanie pism wpływających zarówno w postaci papierowej jak

i elektronicznej.

F01.10.024. Podczas rejestracji użytkownik musi mieć możliwość dodania pisma

(jeśli wpłynęło w formie elektronicznej) lub pliku powstałego przez

zeskanowanie pisma, które wpłynęło w formie papierowej.



str. 72

F01.10.025. Do pisma głównego dołączonych może być dowolnie wiele pism

określonych jako załączniki.

F01.10.026. Musi być możliwość powiązania w czasie rejestracji wpływającego

pisma z istniejącym w systemie pismem, na który pismo wpływające

jest odpowiedzią. Może być wiele odpowiedzi na jedno pismo.

F01.10.027. System musi zapewnić możliwość rejestracji pism przychodzących

poza kancelarią (faksy, protokoły, poczta elektroniczna etc), przez

użytkowników mających określone uprawnienia.

F01.10.028. System musi umożliwić podczas rejestracji pisma ciągły podgląd

skanu pisma na ekranie rejestracji.

F01.10.029. System musi wspierać ciągłość rejestrowania korespondencji

przychodzącej, tzn. po zakończeniu rejestracji jednego pisma

i zapisaniu danych, powinien automatycznie otworzyć się formularz

do zarejestrowania kolejnego pisma.

F01.10.030. Po zarejestrowaniu pisma metadane wprowadzone w czasie

rejestracji muszą być zabezpieczone przed zmianą. Ewentualna ich

edycja (spowodowana np. koniecznością skorygowania błędu)

powinna być możliwa tylko dla uprawnionych osób.

F01.10.031. Musi być możliwość przekazania zarejestrowanego pisma do wielu

odbiorców jednocześnie.

F01.10.032. System musi wspierać rozdzielanie korespondencji poprzez

wskazywanie domyślnego procesu obiegu dla danego pisma.

F01.10.033. Pisma zawierające metadane pozwalające na jednoznaczną

identyfikację procesu muszą być automatycznie kierowane na

właściwy dla nich proces, dla pozostałych pism system powinien

podpowiadać właściwy proces. Domyślnym procesem dla pism nie

powiązanych z procesami dedykowanymi będzie proces ogólny

(kancelaryjny).

F01.10.034. System musi wspierać rozdzielanie korespondencji poprzez

wskazywanie domyślnej komórki (komórek), do której pismo



str. 73

powinno być skierowane. Przy typowaniu domyślnej komórki

system powinien uwzględniać kolejno:

a) twórcę pisma, na które rejestrowane pismo jest odpowiedzią,

b) imię i nazwisko adresata, jeśli występuje,

c) komórkę, na którą zaadresowane jest pismo,

d) komórkę właściwą merytorycznie dla rodzaju poruszonej

w piśmie sprawy (np. dzięki słownikowi zadań),

e) sekretariat Prezesa GUS dla pism pozbawionych innych

wskazówek.

F01.10.035. Typowanie komórki domyślnej, do której należy wysłać pismo, musi

uwzględniać reguły określone w danym procesie przepływu, czyli

np. pismo, którego obieg regulowany jest przez proces ogólny,

a które zostało zaadresowane do Wydziału Archiwalnego, będzie

z poziomu Kancelarii kierowane do komórki nadrzędnej, w tym

wypadku do sekretariatu Biura Dyrektora Generalnego.

1.10.4 TWORZENIE PISM

F01.10.036. System musi dawać możliwość tworzenia nowych pism poprzez:

a) generowanie pism na podstawie szablonów pism przy użyciu

formularzy elektronicznych bez użycia zewnętrznego edytora,

F01.10.037. System musi być niezależny od wyboru pakietów biurowych (edytor

tekstów, arkusz kalkulacyjny itp.) służących do tworzenia

i uaktualniania poszczególnych dokumentów przez pracowników

urzędu. Dla dokumentów pakietu Microsoft Office 2007/2010 musi

zapewnić bezpośrednią integrację z poziomu systemu (otwarcie

pisma bezpośrednio z systemu, edycję pisma w odpowiednim

narzędziu pakietu Office oraz zapisanie do systemu bezpośrednio

z aplikacji Office).Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 74

F01.10.038. Do każdego wytworzonego pisma musi istnieć możliwość

dołączenia dowolnej liczby aneksów w postaci plików dowolnego

formatu, w tym także pism wygenerowanych w systemie bez użycia

aplikacji zewnętrznych.

F01.10.039. Muszą istnieć następujące tryby tworzenia nowego pisma:

a) pismo inicjujące sprawę,

b) nowe pismo w istniejącej sprawie,

c) pismo będące odpowiedzią na wskazane pismo,

d) pismo będące załącznikiem do istniejącego pisma,

e) pismo będące notatką do istniejącego pisma,

f) pismo nie powiązane ze sprawą (robocze).

F01.10.040. System zapewni możliwość tworzenia prywatnych i publicznych

komentarzy do pism (prywatne widoczne będą tylko dla

użytkownika, który jest ich autorem, publiczne – będą widoczne dla

wszystkich uprawnionych użytkowników lub dla użytkowników

wskazanych przez autora komentarza).

F01.10.041. W zależności od trybu, w jakim tworzone jest pismo, system

powinien wspierać użytkownika poprzez ustawienie wartości

domyślnych wszystkich możliwych metadanych oraz pól pisma (np.

adresat, znak sprawy, powiązania z innymi dokumentami itp.).

F01.10.042. W przypadku pisma inicjującego sprawę system powinien

wspomagać rejestrację nowej sprawy.

F01.10.043. System zapewni możliwość tworzenia pism roboczych. Pismem

roboczym jest pismo, które nie zostało zarejestrowane jako

dokument SEOD (nie weszło do obiegu dokumentów), nad którym

użytkownik jeszcze pracuje.

F01.10.044. Pismo nie musi być powiązane ze sprawą.



str. 75

F01.10.045. Musi być możliwość definiowania wielu adresatów dla jednego

pisma.

1.10.5 EDYTOR PISM

F01.10.046. System musi umożliwiać wprowadzanie, modyfikację oraz usuwanie

informacji będących metadanymi pisma.

F01.10.047. System musi umożliwiać zaznaczanie, kopiowanie i wklejanie

fragmentów tekstu zarówno w polach treści pisma, jak i w polach

metadanych.

F01.10.048. W czasie wypełniania pól metadanych system musi sprawdzać

poprawność wprowadzanych wartości według kryteriów

poprawności zdefiniowanych dla danego pola w danym szablonie

pisma lub formularzu.

F01.10.049. W czasie tworzenia pism za pomocą formularzy i szablonów

zapisanych w systemie, system musi sprawdzać poprawność

wartości wprowadzanych do pól treści, dla których zdefiniowane

zostały w szablonie kryteria poprawności.

F01.10.050. System musi wspierać tworzenie korespondencji seryjnej.

1.10.6 REJESTROWANIE DOKUMENTÓW W KOMÓRKACH MERYTORYCZNYCH. TECZKI SPRAW. REJESTRY.

F01.10.052. Podczas rejestracji pisma w komórce merytorycznej system musi

wspomagać dołączenie go do jednej ze spraw zarejestrowanych

w komórce, o ile nie jest to pismo wszczynające sprawę.

F01.10.053. Podczas rejestracji pisma wszczynającego sprawę system musi

wspomagać zarejestrowanie nowej sprawy i nadanie jej znaku Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 76

zgodnego z JRWA.

F01.10.054. System musi umożliwiać wprowadzanie, modyfikację oraz usuwanie

informacji będących elementami metadanych sprawy.

F01.10.055. System musi umożliwiać zaznaczanie, kopiowanie i wklejanie

fragmentów tekstu w polach metadanych sprawy.

F01.10.056. W czasie wypełniania pól metadanych sprawy system musi

sprawdzać poprawność wprowadzanych wartości według kryteriów

poprawności zdefiniowanych dla danego pola w schemacie sprawy.

F01.10.057. Numeracja spraw w ramach teczek i pism w sprawach musi być

przeprowadzana przez system w sposób automatyczny,

z możliwością manualnej korekty nadawanych numerów przez

uprawnionych użytkowników.

F01.10.058. W przypadku, kiedy pismo wszczynające sprawę tworzone jest na

podstawie szablonu powiązanego z procesem przepływu pracy,

musi być możliwość automatycznego wygenerowania przez system

nowej sprawy (o ile przewiduje to scenariusz procesu).

F01.10.059. System musi umożliwiać dołączanie tego samego pisma do różnych

spraw.

F01.10.060. System musi umożliwiać uprawnionym użytkownikom dodawanie

ręczne pisma do rejestru.

F01.10.061. System musi automatycznie dodawać do rejestru pismo spełniające

kryteria określone w definicji tego rejestru.

F01.10.062. System musi umożliwiać wprowadzanie, modyfikację i usuwanie

elementów opisu pisma związanych z jego przynależnością do

rejestru w takim samym zakresie i przy użyciu takich samych

mechanizmów, jak w przypadku pozostałych metadanych pisma.

F01.10.063. System musi umożliwiać uprawnionym użytkownikom przeglądanie,

filtrowanie i sortowanie zawartości rejestru.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 77

F01.10.064. System musi umożliwiać wydruk prowadzonych w nim rejestrów

w całości lub w części, na podstawie zdefiniowanych parametrów

zgodnie z zaprojektowanymi szablonami wydruków.

1.10.7 PREZENTOWANIE PISM I SPRAW

F01.10.065. Podstawowy zestaw pism domyślnie prezentowanych

użytkownikowi musi wynikać z aktualnej listy zadań użytkownika.

Lista zadań związanych z obsługą pism powinna zawierać co

najmniej następujące elementy:

a) data dekretacji na użytkownika (utworzenia zadania),

b) data realizacji zadania,

c) identyfikator dokumentu, którego dotyczy zadanie,

d) nadawca pisma,

e) znak pisma nadawcy,

f) znak pisma, na który dany dokument jest odpowiedzią (o ile taki

istnieje),

g) opis pisma,

h) typ zadania (określony przez dekretującego),

i) w przypadku użytkowników, do których przekazywane są pisma

dekretowane zarówno na nich osobiście jak i na komórką

organizacyjną (np. pracownicy sekretariatów, naczelnicy

wydziałów/działów) – informacja, na kogo pismo jest

zadekretowane.

F01.10.066. Na liście zadań system powinien wyróżniać te, dla których zbliża się

termin realizacji i te, których termin realizacji minął.

F01.10.067. Z widoku listy zadań użytkownik musi mieć możliwość łatwego

wykonania następujących czynności:Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 78

a) otwarcie szczegółów pisma,

b) otwarcie tekstu pisma,

c) przejrzenie listy pism powiązanych (według typu powiązania),

w tym przede wszystkim komentarza do ostatniej dekretacji,

d) otwarcie szczegółów sprawy, do której należy pismo,

e) zarejestrowanie wskazanego pisma w istniejącej sprawie,

f) zarejestrowanie nowej sprawy ze wskazanym pismem jako

wszczynającym sprawę.

F01.10.068. Prezentacja szczegółów pisma musi uwzględniać co najmniej

następujące informacje:

a) informacja o związanym z pismem zadaniu użytkownika,

b) dane podstawowe pisma (wszystkie metadane wprowadzone

podczas rejestracji),

c) informacja, jaka komórka (lub komórki) organizacyjna i osoba

(osoby) zajmuje się aktualnie dokumentem,

d) aktualny status pisma (we wszystkich komórkach, które się nim

zajmują),

e) lista pism powiązanych (według rodzaju powiązania),

f) historia obsługi pisma.

F01.10.069. W widoku szczegółów pisma użytkownik musi mieć możliwość

łatwego wykonania następujących czynności:

a) edytowanie metadanych, których edycja na tym etapie obsługi

pisma jest dopuszczalna,

b) otwarcie tekstu pisma,

c) otwarcie szczegółów lub tekstu dowolnego pisma powiązanego,




str. 79

e) zarejestrowanie przeglądanego pisma w istniejącej sprawie,

f) przejście do zarejestrowania nowej sprawy z przeglądanym

pismem jako pismem wszczynającym sprawę,

g) utworzenie nowego pisma w następujących trybach (możliwych

do wybrania z listy):

nowego pisma w tej samej spraw sprawie, co pismo

przeglądane (dotyczy spraw zarejestrowanych w komórce,

do której należy użytkownik),

pisma będącego odpowiedzią na przeglądane pismo,

pisma będącego załącznikiem do przeglądanego pisma,

komentarza do istniejącego pisma (publicznego bądź

prywatnego).

F01.10.070. W widoku tekstu pisma (utworzonego przy użyciu edytora SEOD,

bez wykorzystania aplikacji zewnętrznej) użytkownik musi mieć

możliwość łatwego wykonania następujących czynności:

a) edytowanie pisma (o ile taka operacja na piśmie jest w danej

sytuacji dopuszczalna),

b) otwarcie szczegółów pisma,

c) wyświetlenie listy pism powiązanych (według typu powiązania)

w taki sposób, by można z niej było przejść do szczegółów i/lub

tekstu wybranego powiązanego pisma,


e) zarejestrowanie przeglądanego pisma w istniejącej sprawie,

f) zarejestrowanie nowej sprawy z przeglądanym pismem jako

pismem wszczynającym sprawę,

g) utworzenie nowego pisma w następujących trybach (możliwych



str. 80

do wybrania z listy):

nowego pisma w tej samej spraw sprawie, co dokument

przeglądany (dotyczy spraw zarejestrowanych w komórce,

do której należy użytkownik),

pisma będącego odpowiedzią na przeglądane pismo,

pisma będącego załącznikiem do przeglądanego pisma,

komentarza do przeglądanego pisma (publicznego bądź

prywatnego).

F01.10.071. Widok szczegółów sprawy musi zawierać co najmniej następujące

informacje:

a) znak sprawy,

b) data wszczęcia sprawy,

c) opis sprawy,

d) lista pism w sprawie (głównych i pomocniczych, jak: załączniki,

komentarze, dekretacje itp.),

F01.10.072. W widoku szczegółów sprawy użytkownik musi mieć możliwość

wykonania jednym kliknięciem następujących czynności:

a) utworzenia nowego pisma w sprawie,

b) otwarcia istniejącego pisma w sprawie (zarówno głównego, jak

i pomocniczego, np. notatki),

c) odnotowania faktu zamknięcia sprawy.

1.10.8 WYSZUKIWANIE PISM I SPRAW

F01.10.073. Pracownik musi mieć możliwość łatwego przeglądania wszystkich

pism i spraw, do których ma uprawnienia. Domyślnie pracownik

posiadać powinien uprawnienia do edycji pism, które zostały na

niego zadekretowane oraz spraw, w ramach których dokumenty te Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 81

zostały zarejestrowane w jego komórce, oraz do przeglądania

wszystkich pism i spraw zarejestrowanych w jego komórce (na

najniższym szczeblu organizacyjnym).

F01.10.074. System musi umożliwiać sortowanie i filtrowanie spraw i pism

według wybranych kryteriów.

F01.10.075. W przypadku użytkowników, do których przekazywane są pisma

dekretowane zarówno na nich osobiście jak i na komórką

organizacyjną (np. pracownicy sekretariatów, naczelnicy

wydziałów/działów) system musi umożliwiać filtrowanie pism

w zależności od tego, w jaki sposób został zdefiniowany odbiorca.

F01.10.076. System musi umożliwiać łatwe tworzenie zestawień korespondencji

przychodzącej i wychodzącej dla poszczególnych komórek

organizacyjnych różnego szczebla.

F01.10.077. System musi umożliwiać przeglądanie pism uporządkowanych

hierarchicznie według teczek spraw i spraw oraz w układzie

pomijającym przynależność do spraw.

F01.10.078. System musi zapewnić szybkie wyszukanie osoby prowadzącej

sprawę.

F01.10.079. System musi zapewnić szybkie wyszukanie wszystkich osób

aktualnie realizujących zadania związane z pismem.

F01.10.080. System w wynikach wyszukiwania musi graficznie wyróżniać pisma,

dla których zbliża się termin zakończenia wykonywania

przydzielonego zadania oraz dla których ten termin minął, przy

czym dla każdej z powyższej sytuacji powinien zostać wykorzystany

inny kolor.

F01.10.081. Dla wybranych atrybutów pism lub spraw system musi posiadać

mechanizm wspierający wyszukiwanie kontekstowe podczas

wprowadzania danych dotyczących pism i spraw dla wybranych

atrybutów (np. komórka organizacyjna, nadawca/odbiorca itp.).



str. 82

Mechanizm ten musi pozwalać na szybkie odszukanie żądanych

danych poprzez ograniczanie w kontekstowym okienku wyboru

danych spełniających określone kryterium (np. fragment nazwiska

lub też nazwisko i miasto itp.). Użytkownik wybiera żądaną pozycję

z wyświetlonej listy, na której prezentowane są szczegółowe dane

(np. imię, nazwisko, adres) bez potrzeby przechodzenia na inny

ekran.

F01.10.082. System musi umożliwiać wydruk kodu paskowego dla

zarejestrowanego pisma lub dla poszczególnych załączników pisma

oraz musi mieć możliwość odnalezienia pism po tym kodzie.

1.10.9 DRUKOWANIE DOKUMENTÓW

F01.10.083. System musi umożliwiać wydruk dokumentów papierowych

przynajmniej w formatach A3, A4, A5, B5 oraz letter

o rozdzielczości przynajmniej 600 DPI w trybie czarno-białym

i kolorowym.

F01.10.084. System musi umożliwiać wydruk jednostronny i dwustronny

dokumentów.

F01.10.085. System musi umożliwiać wydruk na drukarkach obsługujących język

PCL5 lub PCL6 oraz PJL.

F01.10.086. System musi zawierać funkcje wspierające drukowanie

korespondencji seryjnej, w szczególności: wydruk wielu

egzemplarzy pisma skierowanego do wielu adresatów, definiowanie

szablonów etykiet oraz wydruk na etykietach adresowych.

F01.10.087. System musi umożliwiać automatyzację obsługi pism

wychodzących z Urzędu – prowadzić pocztową książkę nadawczą,

drukować na kopertach oraz drukować pocztowe potwierdzenia

odbioru.



str. 83

1.10.10 WYSYŁKA PISM

F01.10.088. System musi umożliwiać użytkownikowi tworzącemu pismo

określenie, w jaki sposób powinno zostać wysłane. Dostępne

muszą być co najmniej następujące opcje wysyłki:

a) wewnątrz systemu (pismo wysłane tym trybem musi być w

komórce nadawcy oznaczane jako pismo wychodzące);

b) poprzez ESP,

c) w formie papierowej:

pocztą - przesyłka polecona,

przesyłka kurierska,

doręczenie bezpośrednie,

tryb zwykły (list zwykły, punkt wymiany itp.)

F01.10.089. System musi zapewnić jednoczesną wielostanowiskową obsługę

wysyłki pism wychodzących.

F01.10.090. System musi zapewnić możliwość określenia, czy na pismo

wychodzące oczekujemy odpowiedzi, a jeśli tak, to w jakim terminie.

F01.10.091. System musi powiadomić referenta odpowiedzialnego za sprawę,

której dotyczyło pismo, o upłynięciu terminu spodziewanej

odpowiedzi.

F01.10.092. System musi wspierać proces wysłania korespondencji pocztą

elektroniczną oraz w postaci faksu.

F01.10.093. System musi wesprzeć proces wysłania dokumentów w formie

elektronicznej na zdefiniowany adres skrzynki podawczej podmiotu

w tym na platformie ePUAP. W tym wypadku system musi

umożliwić podpisanie pisma bezpiecznym podpisem elektronicznym

bądź profilem zaufanym.



str. 84

F01.10.094. System musi automatycznie rejestrować fakt wysłania pism

wychodzących drogą elektroniczną z podpisem elektronicznym i z

profilem zaufanym.

F01.10.095. System powinien umożliwiać pracownikowi kancelarii przeglądanie

listy pism skierowanych do wysyłki w formie papierowej i filtrowanie/

sortowanie ich ze względu na opcję wysyłki.

F01.10.096. Dla pism wysyłanych pocztą kurierską system musi prowadzić

odrębny rejestr uwzględniający możliwość wprowadzenia takich

danych jak numer przesyłki, nazwa firmy, opłata.

F01.10.097. Dla pism wysyłanych przesyłką poleconą system musi prowadzić

odrębny rejestr uwzględniający możliwość wprowadzenia takich

danych jak waga przesyłki, kwota pobrania, numer nadawczy i

opłata, urząd pocztowy.

F01.10.098. Dla pism wysyłanych w trybie zwykłym system musi określić na

podstawie adresata domyślny sposób wysyłki:

a) listem zwykłym,

b) za pośrednictwem punktu wymiany międzyresortowej,

c) doręczenie przez pracownika kancelarii.

F01.10.099. System musi umożliwiać edycję dostępnych opcji i sposobów

wysyłki bez konieczności ingerencji w kod.

F01.10.100. Dla pism doręczanych przez pracownika kancelarii i dostarczanych

do punktu wymiany międzyresortowej system musi drukować

odpowiednie listy służące zbieraniu pokwitowań.

F01.10.101. System musi umożliwiać zaznaczenie faktu, że próba doręczenia

była nieskuteczna – pismo nie zostało odebrane przez adresata.

F01.10.102. System musi umożliwiać definiowanie grup odbiorców.

F01.10.103. Przy wysyłaniu pisma do zdefiniowanej grupy odbiorców musi

istnieć możliwość ręcznego zaznaczenia pominięcia przy danej

wysyłce konkretnego odbiorcy (odbiorców).

1.10.11 PROCESY PRZEPŁYWÓW PRACY

F01.10.104. System musi obsługiwać procesy przepływów pracy dotyczące



str. 85

zarówno zadań powiązanych z obiegiem pism, jak i zadań nie

związanych z pismami.

F01.10.105. Musi istnieć możliwość oznaczenia zadania jako zakończonego

zarówno przez pracownika zajmującego się jego realizacją, jak i

przez system w ramach realizacji zdefiniowanego procesu

przepływu pracy.

F01.10.106. Musi istnieć możliwość zdefiniowania statusów pism

(w poszczególnych komórkach organizacyjnych) nadawanych

zarówno przez użytkownika, jak i automatycznie przez system

w zależności od operacji dokonywanych na piśmie. W różnych

komórkach to samo pismo może mieć różny status. Musi istnieć

możliwość identyfikowania co najmniej następujących statusów:

a) do rozdzielenia – pisma znajdujące się na poziomie kancelarii,

b) w trakcie dekretacji – pisma znajdujące się w komórkach

urzędu, ale których nie zarejestrowano jeszcze jako spraw,

c) rozpatrywane – przydzielone do spraw, ale takie, dla których nie

sporządzono jeszcze odpowiedzi i nie uznano, że nie wymagają

odpowiedzi,

d) wysłano odpowiedź – nadawany w momencie, kiedy pismo

powiązane jako "odpowiedź na" zostało wysłane przez formalnego

nadawcę (np. dyrektora departamentu),

e) oczekiwana odpowiedź,

f) nie wymaga odpowiedzi – jeśli taki status został przez

użytkownika nadany ręcznie,

g) należy do sprawy zamkniętej – jeśli sprawa, której częścią jest

pismo, ma status sprawy zamkniętej.



str. 86

F01.10.107. System musi umożliwiać wyświetlanie listy zadań (w tym dla

pracownika w jego witrynie osobistej) oraz umożliwiać

posortowanie jej według takich kryteriów jak: data rozpoczęcia,

stan realizacji czy termin.

F01.10.108. System musi dać możliwość powiadomienia użytkownika (jak

również zapewnić podgląd) o zmianach związanych z realizacją

jego zadań, np. dotyczących pisma, którym się zajmował lub

sprawy, w której załatwianiu brał udział.

F01.10.109. System musi umożliwiać wyłączenie powiadamiania użytkownika o

zmianach w elementach, do których ten ma dostęp. Wyłączenie

powiadamiania powinno być dostępne zarówno na poziomie grupy

elementów, jak i pojedynczego elementu (np. dla wszystkich spraw

oraz dla wybranej sprawy).

F01.10.110. System musi umożliwiać przydzielanie zadań użytkownikom

automatycznie w ramach zdefiniowanych procesów, jak również

poprzez ręczny wybór pracowników zajmujących się danym

zadaniem, sprawą lub pismem.

F01.10.111. Przekazanie pisma do użytkownika musi wygenerować

automatycznie zadanie dla użytkownika związane z tym pismem -

szczegóły dekretacji określają sposób realizacji zadania. Musi

istnieć możliwość (nie obowiązek) określenia w momencie

przekazania następujących elementów:

a) adresat przekazania,

b) data realizacji,

c) typ zadania (definiowany przy pomocy pola listy rozwijanej – na

poziomie administratora musi istnieć możliwość edytowania

elementów tej listy),

d) wskazówki – pole tekstowe.



str. 87

F01.10.112. Musi być możliwość przekazania pisma do wielu użytkowników,

z określeniem daty realizacji, typu zadania i wskazówek zarówno

dla pojedynczego użytkownika, jak i kilku z nich.

F01.10.113. Musi być możliwość tworzenia na poziomie użytkownika

rozdzielników: gotowych list adresatów wykorzystywanych przy

dekretacjach pism.

F01.10.114. Musi być możliwość wybrania adresata dekretacji/przekazania

z listy prezentowanej w formie drzewa struktury organizacyjnej.

F01.10.115. Dekretacja, wraz ze wszystkimi jej szczegółami, jest rodzajem

dokumentu automatycznie powiązanego z pismem, którego

dotyczy i jest częścią tej samej sprawy (w ramach danej komórki

organizacyjnej), a zatem podlega archiwizacji jako element

sprawy.

a) znaku sprawy - w przypadku zadania związanego z obsługą

pisma w istniejącej sprawie system powinien podpowiadać

dekretację na komórkę i pracownika zajmującego się tą sprawą,

b) adresata – w przypadku pism zaadresowanych na konkretną

komórkę lub osobę,

c) numeru JRWA – w przypadku pism o znanym (np. zapisanym

w szablonie) numerze JRWA; powinna być możliwość powiązania

komórek organizacyjnych z numerami JRWA oznaczającymi

dziedziny wchodzące w skład zadań tych komórek,

d) numeru REGON,

e) symbolu badania statystycznego.

F01.10.117. System musi umożliwić śledzenie przebiegu sprawy (raport

zawierający wszystkie wątki dekretacji pism w sprawie).

F01.10.118. System musi sygnalizować poprzez alerty upływanie granicznych

terminów realizacji zadań. Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 88

F01.10.119. System musi sygnalizować poprzez alerty zadania, których termin

jest zagrożony.

F01.10.120. System musi dać możliwość powiadomienia użytkownika pocztą

elektroniczną o otrzymaniu nowych pism.

F01.10.121. System musi umożliwić anulowanie lub zmianę przekazania lub

dekretacji przez uprawnione osoby.

F01.10.122. System umożliwi wykonanie dekretacji w imieniu szefa

komórki/jednostki przez pracowników kancelarii (sekretariatu).

F01.10.123. System zapewni możliwość odesłania błędnie przekazanego pisma.

F01.10.124. System zapewni możliwość oznaczenia otrzymania papierowej wersji

pisma.

1.10.12 PODPIS ELEKTRONICZNY

F01.10.125. System musi zapewnić mechanizmy integracji z komponentami

podpisu elektronicznego (podpisywanie, weryfikacja, serwer

znakowani czasem, HSM) wyszczególnionymi w punkcie 1.16.

F01.10.126. System dla procesu ogólnego (kancelaryjnego) musi zapewniać

możliwość podpisywania bezpiecznym podpisem elektronicznym lub

profilem zaufanym pism przeznaczonych do wysłania na zewnątrz

przez wyznaczonych w Urzędzie pracowników.

F01.10.127. System dla procesu ogólnego (kancelaryjnego) musi zapewniać

możliwość podpisywania niekwalifikowanym podpisem

elektronicznym wewnętrznego PKI GUS pism wytworzonych w

Urzędzie, przeznaczonych do obiegu wewnętrznego (np. między

jednostkami)

F01.10.128. System w określonych przypadkach musi zapewniać weryfikację Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 89

pism, które wpłynęły do systemu (ESP, web serwisy), w zakresie

posiadania przez te pisma podpisu elektronicznego (kwalifikowanego

i niekwalifikowanego).

1.11 MODUŁ ELEKTRONICZNEJ SKRZYNKI PODAWCZEJ (ESP)

F01.11.001. Elektroniczne skrzynki podawcze dla dokumentu ogólnego

jednostek statystyki publicznej zostaną usytuowane na platformie

ePUAP i muszą zapewnić automatyczne przekazywanie złożonych

pism do SEOD oraz obsługę przyjmowania dokumentów

elektronicznych zgodnie z aktualnymi uwarunkowaniami prawnymi.

F01.11.002. Elektroniczna skrzynka podawcza musi zapewnić generowanie

poświadczenia przedłożenia (Urzędowego Poświadczenia Odbioru).

F01.11.003. System musi archiwizować w elektronicznym archiwum GUS

powiązane ze sprawą poświadczenia przedłożenia (UPO).

F01.11.004. ESP musi automatycznie przesyłać do SEOD poświadczenia

przedłożenia nadawcy dokumentu elektronicznego oraz

archiwizować je w elektronicznym archiwum GUS w powiązaniu ze

sprawą.

F01.11.005. ESP zawierać będzie adres schemy XSD, z którą dokument

przychodzący zostanie zwalidowany. W przypadku niezgodności

dokumentu ze wzorem, dokument nie zostanie przyjęty przez ESP.

F01.11.006. Dla procesów innych niż ogólny (kancelaryjny) wymagających

publikowania formularzy dostępnych z sieci internet (np. uwagi do

PBSSP, pytanie do GUS) wykonawca zapewni możliwość

publikowania formularzy projektowanych w module formularzy na

serwerze Zamawiającego dostępnym z sieci internet. Dokumenty

przyjmowane za pośrednictwem formularzy dostępnych z sieci

internet będą kierowane na odpowiednie ścieżki procesów w Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 90

zależności od wartości metadanych służących jako identyfikatory

wiążące dokument z procesem. Dokumenty z ePUAP nie

powiązane z żadnym konkretnym procesem kierowane będą na

ścieżkę obsługi ogólnego pisma kancelaryjnego.

F01.11.007. System zapewni integrację z Modułem projektowania formularzy w

taki sposób, aby formularze przygotowane przy użyciu tego modułu

mogły być publikowane i wypełniane przez użytkowników w sieci

internet z poziomu przeglądarki internetowej.

F01.11.008. ESP musi zapewnić obsługę stanowiska przyjmowania dokumentów

elektronicznych przyniesionych przez Klienta i zapisywania

poświadczenia przedłożenia na informatycznym nośniku danych

osoby.

1.12ELEKTRONICZNE ARCHIWUM

F01.12.001. System musi umożliwiać wprowadzenie oraz modyfikowanie

Jednolitego Rzeczowego Wykazu Akt. System powinien

przechowywać historię zmian w JRWA.

F01.12.002. System musi kwalifikować pisma do odpowiedniej kategorii

archiwalnej na podstawie obowiązującego w momencie wszczęcia

sprawy JRWA.

F01.12.003. System musi zapewnić dostępny dla uprawnionych użytkowników

interfejs umożliwiający zarządzanie pismami należącymi do spraw

zamkniętych (archiwum elektroniczne), w tym przeprowadzanie

procedur brakowania, przekazywania do archiwum państwowego

bądź udostępniania (przyznawania uprawnień do przeglądania)

takich pism.

F01.12.004. System musi umożliwić wyszukiwanie zarchiwizowanych pism na

podstawie wprowadzonych metadanych co najmniej:



str. 91

a) identyfikator - jednoznaczny w danym zbiorze dokumentów

znacznik dokumentu, który umożliwia jego identyfikację,

b) twórca – podmiot odpowiedzialny za treść pisma, z podaniem

jego roli w procesie tworzenia lub akceptacji dokumentu,

c) tytuł pisma,

d) data - data zdarzenia związanego z tworzeniem pisma,

e) format - nazwa formatu danych zastosowanego przy tworzeniu

pisma,

f) dostęp - określenie komu, na jakich zasadach i w jakim

zakresie można udostępnić pismo,

g) relacja - określenie bezpośredniego powiązania z innym

pismem i rodzaju tego powiązania,

h) odbiorca - podmiot, do którego pismo jest adresowane,

i) grupowanie – wskazanie przynależności do zbioru

dokumentów,

j) kwalifikacja - kategoria archiwalna pisma,

k) język - kod języka naturalnego zgodnie z normą ISO-639-2 lub

inne określenie języka, o ile nie występuje w normie,

l) opis - streszczenie, spis treści lub krótki opis treści pisma,

m) uprawnienia - wskazanie podmiotu uprawnionego do

dysponowania pismem.

F01.12.005. System musi wyodrębniać automatycznie pisma przeznaczone do

przekazania do archiwum państwowego.

F01.12.006. System musi eksportować pisma i ich metadane do systemu

teleinformatycznego archiwum państwowego w następujący

sposób:

a) metadane eksportowane w formacie XML,



str. 92

b) pisma przekazywane w takim formacie, w jakim były ostatnio

przechowywane.

a) identyfikator,

b) nazwę wytwórcy,

c) tytuł,

d) datę wytworzenia,

e) informację o formacie danych,

f) określenie zasad udostępniania pisma,

g) rodzaj dokumentu (obraz, dźwięk, tekst itp.),

h) typ pisma.

F01.12.008. Dodatkowo, jeśli istnieją, muszą być do pism przekazywanych

dołączane następujące informacje:

a) bezpośrednie powiązania z innymi pismami,

b) nazwa odbiorcy,

c) kod języka naturalnego,

d) opis treści,

e) wskazanie podmiotu uprawnionego do dysponowania pismem.

F01.12.009. Na najwyższym poziomie struktury zapisu przekazywanych

materiałów powinny znajdować się trzy foldery:

a) dokumenty (zawierający pliki dla dokumentów złożonych

z pojedynczych plików i foldery dla dokumentów złożonych z

więcej niż jednego pliku),

b) metadane,

c) sprawy (zawierający metadane spraw).

F01.12.010. Moduł archiwum elektronicznego musi umożliwiać swobodny dobór

elementów metadanych dołączanych do przekazywanych do



str. 93

archiwum państwowego akt (na wypadek zmian prawnych i

organizacyjnych).

F01.12.011. System musi sporządzać automatycznie spis dokumentacji

przeznaczonej do przekazania do archiwum państwowego. Spis

musi zawierać następujące kolumny: liczba porządkowa, znak

sprawy, hasło z JRWA odpowiadające symbolowi ze znaku sprawy,

datę wszczęcia i datę zakończenia sprawy oraz liczbę dokumentów

w sprawie. Schemat spisu musi być możliwy do modyfikacji co

najmniej w zakresie pozycji, liczby i nazwy kolumn (na wypadek

zmian prawnych i organizacyjnych).

F01.12.012. System musi oznaczać dokumenty przekazane do archiwum

państwowego i umożliwiać odróżnienie ich od dokumentów

nieprzekazanych.

F01.12.013. System musi wyodrębniać automatycznie pisma przeznaczone do

brakowania.

F01.12.014. System musi sporządzać automatycznie spis dokumentacji

przeznaczonej do brakowania, gdzie pozycją w spisie będzie hasło

z JRWA. Spis musi zawierać następujące kolumny: liczba

porządkowa, symbol z JRWA, odpowiadające symbolowi hasło

z JRWA , daty skrajne dokumentów tworzących akta danej sprawy

oraz uwagi. Schemat spisu musi być możliwy do modyfikacji co

najmniej w zakresie pozycji, liczby i nazwy kolumn (na wypadek

zmian prawnych i organizacyjnych).

F01.12.015. System musi umożliwiać fizyczne usunięcie dokumentów, które

zostały poddane procedurze brakowania. Czynność taka musi

wymagać autoryzacji i powinna być udokumentowana.

F01.12.016. System musi umożliwiać dla spraw zarchiwizowanych

zautomatyzowany eksport załączonych plików: zdefiniowanych,

wybranych lub wszystkich dotyczących sprawy z pozostawieniem

wpisu o sprawie w rejestrze na zewnętrzne nośniki (z możliwością Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 94

ewentualnego usunięcia ich z systemu), natomiast dla dokumentów

przekazywanych do archiwum państwowego - generować

odpowiednią paczkę archiwalną.

F01.12.017. Z automatycznie wyodrębnionych przez system materiałów

przeznaczonych do przekazania do archiwum państwowego lub

wybrakowania osoba uprawniona musi mieć możliwość utworzenia

ręcznego listy materiałów podlegających przekazaniu lub

wybrakowaniu zarówno poprzez filtrowanie ze względu na wartości

atrybutów, jak i poprzez ręczne wskazanie dokumentów, które nie

będą podlegały przekazaniu lub wybrakowaniu. Na podstawie takiej

listy system musi stworzyć automatycznie spis materiałów

przeznaczonych do przekazania lub wybrakowania.

F01.12.018. System musi umożliwiać po spełnieniu określonych procedur,

zmianę kategorii archiwalnej wynikającej z JRWA:

b) w przypadku dokumentacji, której czas przechowywania

upłynął, ale komisja oceny dokumentacji niearchiwalnej

zdecydowała o jej dalszym przechowywaniu,

c) w przypadku dokumentacji niearchiwalnej przekwalifikowanej

do materiałów archiwalnych.

F01.12.019. System musi umożliwiać przywracanie spraw zamkniętych do

obiegu.

F01.12.020. System musi umożliwiać zdefiniowanie pism spraw zamkniętych

jako dokumentów wyłączonych z obiegu, według dowolnego i

możliwego do zmiany kryterium (np. w momencie zamknięcia

sprawy lub po upływie określonego czasu od zamknięcia sprawy).

F01.12.021. System musi umożliwiać sformułowanie innych zasad kontroli

dostępu do dokumentów zarchiwizowanych, a innych dla

dokumentów bieżących.

F01.12.022. System musi dawać możliwość swobodnego kształtowania zasad



str. 95

dostępu do pism wyłączonych z obiegu, łącznie z opcją

przyznawania prawa dostępu do pojedynczego pisma konkretnej

osobie na określony czas.

F01.12.023. System musi zapewnić integralność pism i przypisanych do nich

metadanych (ochrona przed wprowadzaniem zmian poza

ustalonymi procedurami).

F01.12.024. System musi umożliwiać zapisywanie informacji o lokalizacji

fizycznego miejsca składowania papierowych wersji materiałów

archiwalnych oraz dokumentacji niearchiwalnej.

F01.12.025. System musi umożliwiać złożenie za pomocą formularza wniosku

o wypożyczenie dokumentacji papierowej oraz wniosku

o udostępnienie dokumentacji w postaci elektronicznej.

F01.12.026. System musi umożliwiać sporządzenie i przekazanie do Archiwum

elektronicznego spisu zdawczo-odbiorczego dotyczącego

materiałów papierowych.

F01.12.027. System musi umożliwiać długoterminowe zabezpieczenie ważności

kryptograficznej dokumentów z podpisem elektronicznym dzięki

dostarczonemu serwerowi znakowania czasem.

F01.12.028. System musi być zintegrowany z bazą archiwum GUS przynajmniej

w zakresie:

a) rejestracji wypożyczeń,

b) eksportowania do bazy danych Archiwum GUS spisów zdawczo-

odbiorczych sporządzonych w postaci elektronicznej,

c) możliwości przeszukiwania zasobu archiwalnego

zinwentaryzowanego w bazie Archiwum.

F01.12.029. System musi posiadać usługę sieciową (WebService opisany z

pomocą opisu usług sieciowych WSDL) służącą do przesyłania

plików i meta danych z innych Systemów. Usługa musi umożliwiać

na odebranie dokumentu (w tym załącznika do sprawy) oraz Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 96

zwrócenie zawartości dokumentu na żądanie z innego systemu.

Szczegółowa specyfikacja tej usługi zostanie określona na etapie

wdrożenia.

1.13 DODATKOWE KOMPONENTY

1.13.1 MODUŁ STRUKTURY ORGANIZACYJNEJ

F01.13.001. System musi umożliwiać prowadzenie ewidencji struktury

organizacyjnej jednostek statystyki publicznej i stanowisk pracy

(z możliwością prezentacji w oparciu o graficzny model drzewa) i

zawierać podstawowe informacje na temat jednostek, komórek

organizacyjnych i pracowników.

F01.13.002. Struktura powinna jak najwierniej oddawać rzeczywisty stan

organizacji jednostek statystyki i umożliwiać modyfikowanie

struktury przez uprawnionych użytkowników.

F01.13.003. Struktura organizacyjna będzie mogła odzwierciedlać zarówno

pionowe formy organizacji (komórki organizacyjne), jak i poziome

(np. zespoły zadaniowe).

F01.13.004. Struktura powinna zostać całkowicie stworzona przez wykonawcę

na bazie informacji przechowywanych w katalogu LDAP i systemie

HR w toku konsultacji z Zamawiającym.

F01.13.005. Moduł powinien umożliwić wyszukanie danych na podstawie

dowolnych kryteriów opisujących pracownika, jednostkę itd.

F01.13.006. Moduł struktury organizacyjnej musi przechowywać co najmniej

dane (aktualne i historyczne) na temat:

a) pracownikówProjekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 97

numer ewidencyjny,

imię i nazwisko,

stanowisko,

telefon wewnętrzny (tylko aktualny),

telefon komórkowy (tylko aktualny),

e-mail (tylko aktualny),

numer pokoju,

zdjęcie,

przynależność służbowa do komórki (komórek)

organizacyjnej,

podległość służbowa,

przynależność do struktur poziomych,

inne zdefiniowane przez administratora.

b) jednostek organizacyjnych

nazwa,

skrót,

adres,

REGON,

NIP,

kierownictwo.

c) komórek organizacyjnych

nazwa,

miejsce w strukturze jednostki,

zakres zadań,

kierownik.

d) etatów

symbol etatu w komórce,

stanowisko,

opis,

miejsce w strukturze,

przynależność do Służby Cywilnej.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 98

e) struktur poziomych

nazwa,

cel utworzenia,

zakres działania,

kierownictwo,

skład.

F01.13.007. Moduł struktury organizacyjnej powinien też przechowywać

informacje na temat następujących faktów:

a) utworzenie lub likwidacja jednostki:

data,

podstawa prawna.

b) utworzenie, likwidacja lub zmiana podległości komórki

organizacyjnej:

data,

podstawa prawna.

c) zatrudnienie lub zwolnienie pracownika:

data.

d) utworzenie lub likwidacja stanowiska:

data,

podstawa prawna.

e) zmiana zakresu zadań jednostki lub komórki organizacyjnej:

data,

podstawa prawna,

zakres zmian.

f) zmiana opisu stanowiska pracy:

data,

zakres zmian.

g) zmiana przez pracownika stanowiska pracy:



str. 99

data,

stanowiska, jakich dotyczyła.

h) zmiana umiejscowienia stanowiska pracy w strukturze

organizacyjnej:

data,

podstawa prawna,

komórki, których dotyczyła.

F01.13.008. System musi umożliwić zaimportowanie zdjęć pracowników

w formacie JPG przechowywanych w systemie folderów. Każde

zdjęcie umieszczone w folderach opisane jest imieniem i

nazwiskiem pracownika.

F01.13.009. Moduł w zakresie danych przechowywanych w AD musi zapewnić

pełną integralność z usługą katalogową (MS Active Directory) w

zakresie prezentacji informacji o użytkownikach.

F01.13.010. Informacje zgromadzone za pomocą modułu muszą umożliwić

wykorzystanie w trakcie realizacji procesów w celu zidentyfikowania

osób zdefiniowanych za pomocą ról typu "bezpośredni przełożony",

"pracownik sekretariatu" itp..

F01.13.011. Informacje zgromadzone w module muszą umożliwić wykorzystanie

ich w trakcie realizacji procesów jako źródło list słownikowych

pracowników danej komórki, podwładnych danej osoby, komórek

danej jednostki lub list zdefiniowanych w oparciu o inne kryteria.

F01.13.012. Z dowolnego miejsca w systemie, w którym pojawi się nazwisko

dowolnego pracownika (informacja systemowa), musi istnieć

możliwość szybkiego podglądu jego danych kontaktowych.

F01.13.013. Z dowolnego miejsca w systemie, w którym pojawi się nazwa

jednostki lub komórki organizacyjnej (informacja systemowa), musi

być możliwość szybkiego podglądu dotyczących jej danych.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 100

F01.13.014. Moduł musi posiadać usługę sieciową dedykowaną dla innych

systemów m.in. Systemu Edukacyjnego (WebService opisany za

pomocą języka opisu usług sieciowych WSDL) służącą do

wykorzystania struktury organizacyjnej w innych systemach.

Szczegółowa specyfikacja tej usługi zostanie określona na

wdrożenia.

.

1.13.2 MODUŁ REZERWACJI ZASOBÓW

F01.13.015. Moduł rezerwacji zasobów umożliwi dysponowanie niezbędnymi do

prawidłowego wykonywania pracy wspólnymi zasobami (sale

konferencyjne, , samochody służbowe, projektory multimedialne

itp.). Lista zasobów objętych rezerwacją zostanie zdefiniowana na

etapie wdrożenia.

F01.13.016. System umożliwi dodawanie, modyfikację i usuwanie zasobów

przeznaczonych do rezerwacji w podziale na poszczególne

jednostki statystyki publicznej.

F01.13.017. Każdy użytkownik musi mieć możliwość zarezerwowania

określonej pozycji, ustalenia zakresu czasowego i priorytetu, a

także uzasadnienia konieczności dokonania rezerwacji.

F01.13.018. Przełożony użytkownika musi mieć możliwość anulowania

rezerwacji dokonanej przez podwładnego, o czym jest

automatycznie powiadamiana osoba, która dokonała rezerwacji.

F01.13.019. System musi umożliwić nadawanie uprawnień dotyczących

pojedynczych zasobów (np. pojedynczego komputera, wybranego

rzutnika) w zakresie następujących czynności:

a) możliwość rezerwacji zasobu z dokładnością co najmniej do 15

minut,



str. 101

b) wgląd w rezerwacje,

c) możliwość usuwania rezerwacji zasobu,

d) możliwość wglądu w widoki kalendarza rezerwacji z podziałem

co najmniej na: dzień, tydzień, miesiąc.

F01.13.020. System musi zawierać mechanizm eliminacji konfliktów czasowych

wynajmowanych zasobów.

F01.13.021. System musi zawierać panel administrowania zasobami

udostępniony uprawnionym użytkownikom.

F01.13.022. System musi zawierać narzędzie do monitoringu eksploatacji

zasobów.

F01.13.023. System musi zawierać narzędzie do prezentacji zestawień

(raportów) dostępności zasobów.

F01.13.024. System zapewni możliwość pobierania prezentowanych danych

bezpośrednio z aplikacji MS Access, MS Excel, a także mechanizm

importowania/eksportowania danych z/do baz danych SQL.

F01.13.025. Dane te prezentowane będą w postaci szczegółowych kart

informacyjnych pojedynczych elementów opisanych

w poszczególnych bazach, zestawień zbiorczych i raportów.

F01.13.026. System umożliwi dołączenie zdjęcia oraz dokładnego opisu

elementu do karty informacyjnej.

F01.13.027. Moduł musi posiadać usługę sieciową dedykowaną dla innych

Systemu Edukacyjnego (WebService opisany za pomocą języka

opisu usług sieciowych WSDL) zapewniającą możliwość rezerwacji

określonych zasobów z poziomu tego systemu. Szczegółowa

specyfikacja tej usługi zostanie określona na wdrożenia.



str. 102

1.14 WYMAGANIA SZCZEGÓŁOWE DLA PROCESÓW

1.14.1 PYTANIE DO GUSF01.14.001. System zapewni obieg dokumentów w procesie „Pytanie do GUS”,

realizowanym przez Departament Informacji GUS, zdefiniowanym

na schemacie znajdującym się w Załączniku nr 8 oraz według

zamieszczonych poniżej funkcjonalności.

F01.14.002. System musi zapewnić utworzenie rejestru Pytań do GUS.

F01.14.003. System musi zapewnić przypisanie referentom DI uprawnień do

poszczególnych rekordów w rejestrze.

F01.14.004. System musi umożliwić zadanie Pytania do GUS na dedykowanym

formularzu, dostępnym z poziomu Portalu Informacyjnego GUS.

F01.14.005. System musi umożliwić import danych z dedykowanego formularza

do odpowiadających im pól w rejestrze.

F01.14.006. System musi umożliwić wprowadzanie do rejestru, przez

uprawnionych referentów DI, pytań wpływających w inny sposób,

niż za pomocą dedykowanego formularza (fax, e-mail).

F01.14.007. System musi zapewniać nadanie nowemu pytaniu kolejnego

numeru w rejestrze.

F01.14.008. System musi zapewniać powiadamianie referentów DI o nowych

pytaniach.

F01.14.009. System musi zapewniać wsparcie wysyłania do klienta odpowiedzi

w formie e-maila oraz wydruk udzielonej odpowiedzi.

F01.14.010. System musi umożliwiać opublikowanie pytania i udzielonej na nie

odpowiedzi w module Najczęściej zadawane pytania FAQ w Portalu

Informacyjnym GUS.



str. 103

F01.14.011. System musi umożliwiać skierowanie pytania - przez uprawnionego

referenta DI - na proces związany z udostępnianiem danych

statystycznych.

F01.14.012. System musi umożliwiać wyszukiwanie pytań według

zdefiniowanych kryteriów.

F01.14.013. System musi umożliwiać generowanie statystyk dotyczących ilości i

tematyki wpływających pytań.

1.14.2 UDOSTĘPNIANIE DANYCH STATYSTYCZNYCH

F01.14.014. System zapewni obieg dokumentów w procesie „Udostępnianie

danych statystycznych” (z wyłączeniem zamówień odpłatnych),

realizowanego przez jednostki statystyki publicznej, zdefiniowanego

na schemacie znajdującym się w Załączniku nr 8 oraz według


F01.14.015. System musi zapewnić utworzenie rejestru zamówień na dane

statystyczne – z uwagi na ilość wpływających zamówień oddzielnie

dla każdego roku kalendarzowego.

F01.14.016. System musi zapewnić zaewidencjonowanie wszystkich zamówień

na dane statystyczne (w tym zamówień płatnych) i obsługiwane ich

z poziomu aplikacji „Rejestr zamówień na dane statystyczne”.

F01.14.017. System musi umożliwić stworzenie w rejestrze obowiązkowych pól

związanych z realizacją zamówienia: dane zlecającego zamówienie,

jednostka przypisana do obsługi zamówienia, częstotliwość (przy

zamówieniach cyklicznych), sposób realizacji, wyliczenie kosztów

zamówienia, status realizacji zamówienia.

F01.14.018. System musi zapewnić migrację danych z funkcjonującej obecnie w

Departamencie Informacji GUS aplikacji „Rejestr zamówień GUS”,

opartej o bazę MySQL.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 104

F01.14.019. System musi zapewnić migrację danych z baz danych

funkcjonujących w urzędach statystycznych (m.in. xls, mdb).

F01.14.020. System musi umożliwić nadawanie pracownikom jednostek

statystyki publicznej uprawnień do poszczególnych rekordów w

rejestrze.

F01.14.021. System musi umożliwić złożenie zamówienia na dane statystyczne

na dedykowanym formularzu, dostępnym z poziomu Portalu

Informacyjnego GUS, z możliwością wyboru jednostki statystyki

publicznej, do której kierowane jest zamówienie.

F01.14.022. System musi zapewniać import danych z dedykowanego formularza

do odpowiednich pól w rejestrach zamówień na dane statystyczne

poszczególnych jednostek.

F01.14.023. System musi umożliwiać wprowadzanie do rejestrów jednostek

statystyki publicznej, przez uprawnionych pracowników jednostek

statystyki publicznej, zamówień wpływających w inny sposób, niż

za pomocą dedykowanego formularza (fax, e-mail).

F01.14.024. System musi zapewniać nadanie nowemu zamówieniu kolejnego

numeru w rejestrze.

F01.14.025. System musi zapewniać dołączenie do sprawy skanu pisma, faxu

lub e-maila z zamówieniem.

F01.14.026. System musi posiadać system podpowiedzi (połączony z

metadanymi zamówienia) ułatwiający dekretację zamówienia w

systemie.

F01.14.027. System musi zapewniać przypisanie kolejnego wpływającego pisma

do istniejącej już sprawy związanej z zamówieniem.

F01.14.028. System musi zapewniać powiadamianie pracowników statystyki

publicznej o nowych zamówieniach do dekretacji i realizacji



str. 105

(dyrektorów, kierowników komórek/referentów w DI i urzędach

statystycznych).

F01.14.029. System musi umożliwić określanie poziomów dostępu do

zamówienia dla określonych osób (np. do realizacji, do

wiadomości).

F01.14.030. System musi umożliwić zaawansowane wyszukiwanie zamówień

według zdefiniowanych kryteriów.

F01.14.031. System musi umożliwić generowanie statystyk dotyczących

zamówień, m.in. ilość zamówień na jednostkę statystyki publicznej,

ilość zamówień na komórkę/referenta, ilość zamówień w podziale

na statusy zamówienia, tematy itd.

F01.14.032. System musi umożliwić utworzenie bazy osób i instytucji

zamawiających dane statystyczne.

F01.14.033. System musi umożliwić utworzenie i wykorzystywanie bazy

szablonów pism, z możliwością automatycznego wypełniania

szablonu danymi teleadresowymi Zamawiającego oraz treścią

odpowiedzi.

F01.14.034. System musi umożliwić wydawanie poleceń i określanie terminu

realizacji zamówienia.

F01.14.035. System musi zapewniać monitorowanie terminów realizacji

zamówień oraz powiadomienia w przypadku ich przekroczenia.

F01.14.036. System musi umożliwić oznaczenie zamówień, których termin

realizacji dobiega końca się jako spraw pilnych.

F01.14.037. System musi umożliwić sporządzanie raportów zamówień

przeterminowanych, pilnych i ich wydruk.



str. 106

F01.14.038. System musi zapewniać wsparcie wysyłania odpowiedzi na

zamówienia na dane statystyczne za pomocą faxu i e-maila,

bezpośrednio z systemu.

F01.14.039. System musi zapewniać skierowanie zamówienia na dane

statystyczne na proces „Pytanie do GUS”.

F01.14.040. System musi umożliwić skierowanie zamówienia na dane

statystyczne do innej jednostki statystyki publicznej.

F01.14.041. System musi umożliwić publikowanie statusu realizacji sprawy

(podpięcie informacji o statusie) poprzez Biuletyn Informacji

Publicznej Portalu Informacyjnego GUS w celu sprawdzenia przez

składającego zamówienie statusu sprawy.

1.14.3 WYMAGANIA OGÓLNE DLA PROCESÓW ZWIĄZANYCH Z DYSCYPLINĄ PRACY

F01.14.042. System zapewni dla wszystkich pracowników jednostek statystyki

publicznej obieg dokumentów w procesach związanych z procesami

związanymi z dyscypliną pracy, realizowanymi w jednostkach

statystyki publicznej, zdefiniowanymi na schematach znajdujących

się w Załączniku nr 8 (właściwych dla GUS) oraz według


F01.14.043. System musi umożliwiać pracownikom wypełnienie elektronicznych

formularzy a następnie edycję danych właściwych dla danego

procesu. System w tym celu musi umożliwić wykorzystanie danych

systemowych:

a) imię i nazwisko,

b) komórka organizacyjna,

c) stanowisko,



str. 107

d) bieżąca data.

F01.14.044. System musi umożliwić weryfikację informacji (np. o ilości

dostępnego urlopu) i wprowadzenie w momencie zakończenia

procesu informacji do systemu HR (np. informacji o przydzielonym

urlopie) właściwych dla danego procesu.

F01.14.045. System musi aktualizować indywidualny kalendarz pracownika na

podstawie danych uzyskanych w trakcie procesów. System musi

zaznaczać w kalendarzu:

a) nieobecności zarówno całodniowe jak i w określonych godzinach

z uwzględnieniem przyczyn tych nieobecności,

b) pracę wykonaną poza godzinami służbowymi,

c) fakt sprawowania zastępstwa (kiedy i za kogo),

d) termin zaplanowanego przez pracownika urlopu i delegacji,

e) Inne wynikające z przebiegu procesów.

1.14.4 PROCES DELEGACJI

F01.14.046. System zapewni możliwość edytowania na formularzu delegacji

następujących elementów:

a) miejsca przeznaczenia delegacji,

b) terminu rozpoczęcia i zakończenia delegacji,

c) określenia środka transportu,

d) wartości wnioskowanej do wypłacenia zaliczki,

e) miejsc wyjazdu i przyjazdu,

f) dat wyjazdu i przyjazdu,

g) godzin wyjazdu i przyjazdu,

h) kosztów przejazdów,

i) wyliczanie kosztów delegacji i ich składowych (ryczałty, diety itp).



str. 108

F01.14.047. System zapewni możliwość automatycznego przekazywania

delegacji do zatwierdzenia.

F01.14.048. System zapewni możliwość generowania zastępstw w związku

z zaakceptowaniem delegacji, musi przy tym automatycznie

przekierowywać zadania przydzielone osobie zastępowanej

(zarówno dekretowane na nią jak i wynikające ze zdefiniowanych

procesów) na osobę zastępującą i automatycznie nadawać jej

uprawnienia do dokumentów związanych z tymi zadaniami (w takim

zakresie, jaki przysługiwał osobie zastępowanej).

F01.14.049. System zapewni możliwość automatycznego zapisania

w indywidualnym kalendarzu pracownika dni zaakceptowanej

delegacji jako dni nieobecności w pracy.

F01.14.050. System zapewni możliwość modyfikacji terminów delegacji

i modyfikacji liczby dni delegacji a także usunięcia delegacji.

1.14.5 OBSŁUGA WNIOSKU URLOPOWEGO

F01.14.051. System zapewni automatyczną weryfikację dostępności urlopu do

wykorzystania na podstawie przechowywanych w systemie HR

danych na temat:

a) liczby dni przysługującego pracownikowi urlopu

wypoczynkowego,

b) liczby dni przysługującego pracownikowi urlopu szkoleniowego

(przyznanego na podstawie Umowy o skierowanie na studia),

c) liczby dni przysługującego pracownikowi urlopu

okolicznościowego, wynikającego z ogólnych przepisów prawa/(np.

ślub własny lub dziecka, zgony),

d) liczby dni przysługującego pracownikowi urlopu dodatkowego

(np. urlop kombatancki, orzeczenie o niepełnosprawności etc)

wynikającej z przepisów prawa,

e) liczby dni wolnych na opiekę nad dzieckiem do lat 14,



str. 109

f) liczby wykorzystanych dni urlopu (z uwzględnieniem rodzaju

urlopu),

g) planu urlopów (dla urlopów dłuższych niż 10 dni).

F01.14.052. Wprowadzenie zmian w danych dotyczących liczby dni

przysługującego pracownikowi urlopu musi być możliwe bez

wprowadzania zmian w oprogramowaniu.

F01.14.053. W przypadku zmian liczby przysługującego urlopu dotyczących

wielu pracowników (np. wskutek zmiany przepisów prawa) musi

istnieć możliwość zaktualizowania danych dla wszystkich

pracowników, których dotyczy zmiana, jednocześnie.

F01.14.054. Listę urlopów oraz przysługujące ilości dni system za każdym razem

musi pobrać z systemu HR.

F01.14.055. System zapewni możliwość modyfikacji terminów urlopu

i modyfikacji liczby dni urlopu.

F01.14.056. System zapewni możliwość automatycznego zapisania

w indywidualnym kalendarzu pracownika dni zaakceptowanego

urlopu jako dni przewidywanej nieobecności w pracy.

F01.14.057. System zapewni możliwość edytowania wniosku urlopowego.

F01.14.058. System zapewni możliwość zatwierdzenia wniosku urlopowego

według przygotowanej ścieżki obowiązującej dla danego

pracownika.

F01.14.059. System zapewni możliwość generowania zastępstw w związku

z zaakceptowaniem wniosku urlopowego, musi przy tym

automatycznie przekierowywać zadania przydzielone osobie

zastępowanej (zarówno ręczne jak i wynikające ze zdefiniowanych

procesów) na osobę zastępującą i automatycznie nadawać jej

uprawnienia do dokumentów związanych z tymi zadaniami (w takim

zakresie, jaki przysługiwał osobie zastępowanej).Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 110

1.14.6 ZGŁASZANIE UWAG DO PROJEKTU BADAŃ STATYSTYCZNYCH STATYSTYKI PUBLICZNEJ

F01.14.060. System zapewni obieg dokumentów w procesie „Zgłaszanie uwag

do PBSSP”, realizowanym przez jednostki statystyki publicznej,

zdefiniowanym na schemacie znajdującym się w Załączniku nr 8

oraz według zamieszczonych poniżej funkcjonalności.

F01.14.061. System musi zapewnić możliwość wypełnienia formularza

zgłoszenia uwag dostępnego z poziomu ESP dla użytkowników

spoza jednostek statystyki publicznej.

F01.14.062. System musi zapewnić możliwość wypełnienia formularza

zgłoszenia uwag dostępnego z poziomu aplikacji przez pracownika

wewnętrznego dla zgłoszeń przekazanych w inny sposób niż przez

formularz elektroniczny.

F01.14.063. System musi zapewnić możliwość obsługi pełnej ścieżki procesu

zgodnie ze zdefiniowanym schematem procesu.

F01.14.064. System musi zapewnić podpięcie słowników pod formularz

wspomagający wypełnienie poszczególnych pól.

F01.14.065. System musi zapewnić automatyczną podpowiedź pracownikowi

dekretującemu ścieżkę dekretacji na podstawie rodzaju badania.

F01.14.066. System automatycznie powiadomi uprawnionych użytkowników

o wpłynięciu nowej uwagi, dekretacji bądź stanowiska do uwagi.

F01.14.067. System wyśle automatyczne potwierdzenie składającemu uwagę

o przyjęciu uwagi.

F01.14.068. System musi umożliwić wydruk raportu z uwagami.



str. 111

F01.14.069. System musi zapewnić ewidencjonowanie uwag w formie

zestawienia dostępnego dla upoważnionych użytkowników.

F01.14.070. Rejestr musi umożliwić wyszukanie sprawy wg zdefiniowanych

kryteriów.

F01.14.071. Dane z formularza muszą automatycznie trafić do odpowiadających

im pól w rejestrze.

F01.14.072. System musi umożliwić zadekretowanie uwag do odpowiednich

osób w celu zajęcia stanowiska do uwag.

F01.14.073. System musi umożliwić wprowadzanie stanowisk do uwag przez

zadekretowane osoby.

F01.14.074. System musi umożliwić generowanie statystyk m.in. ilości złożonych

uwag do punktów PBSSP.

F01.14.075. System musi umożliwić pokazanie zgłaszającemu uwagę statusu

rozpoczętej przez niego sprawy.

F01.14.076. System musi umożliwić monitorowanie terminów realizacji spraw

oraz powiadomienie w przypadku ich przekroczenia.

F01.14.077. System musi umożliwić zamknięcie raportu i zablokowanie

możliwości edycji poszczególnych pól przez upoważnionych

użytkowników w momencie zakończenia prac nad procesem.

F01.14.078. System musi umożliwić generowanie i wydruk raportów zbiorczych.

1.14.7 RAPORTY Z PRZEBIEGU BADAŃ

F01.14.079. System zapewni obieg dokumentów w procesie „raporty z przebiegu

badań”, realizowanym przez jednostki statystyki publicznej,





str. 112

F01.14.080. System musi zapewnić możliwość wypełnienia formularzy

zgłoszenia uwag dla badań i zgłoszenia uwag do badań zbiorczych

dostępnych z poziomu Portalu Korporacyjnego dla użytkowników

z jednostek statystyki publicznej.

F01.14.081. System musi umożliwiać zapisanie roboczej wersji formularza i

wielokrotne edytowanie przed wysłaniem.

F01.14.082. System musi umożliwiać podpięcie słowników pod formularz

wspomagający wypełnienie poszczególnych pól.

F01.14.083. System musi zapewniać podpowiedź pracownikowi dekretującemu

zgodnie z punktem badania.

F01.14.084. System musi zapewnić możliwość obsługi pełnej ścieżki procesu

zgodnie ze zdefiniowanym schematem procesu.

F01.14.085. System musi automatycznie powiadamiać uprawnionych

użytkowników o wpłynięciu nowej uwagi, dekretacji bądź stanowiska

do uwagi.

F01.14.086. System musi automatycznie wysyłać potwierdzenie składającemu

uwagę o przyjęciu raportu.

F01.14.087. System musi umożliwiać wydruk raportu.

F01.14.088. System musi zapewnić ewidencjonowanie uwag w formie rejestru

dostępnego dla upoważnionych użytkowników.

F01.14.089. Rejestr musi umożliwić wyszukanie sprawy według zdefiniowanych

kryteriów.

F01.14.090. Dane z formularza muszą automatycznie trafić do odpowiadających

im pól w rejestrze.

F01.14.091. System musi umożliwiać scalenie raportów z badań zbiorczych

przekazanych przez poszczególne Urzędy Statystyczne (dla tego



str. 113

samego badania zbiorczego) w jeden raport kierowany do

dekretacji.

F01.14.092. System musi umożliwiać zadekretowanie uwag do odpowiednich

osób w celu zajęcia stanowiska do uwag.

F01.14.093. System musi umożliwiać wprowadzenie stanowisk do uwag przez

zadekretowane osoby.

F01.14.094. System musi umożliwiać generowanie statystyk, m.in. ilości

złożonych uwag.

F01.14.095. System musi zapewnić monitorowanie terminów realizacji spraw

oraz powiadomienie w przypadku ich przekroczenia.

F01.14.096. System musi umożliwiać zamknięcie raportu i zablokowanie

możliwości edycji poszczególnych pól poprzez upoważnionych

użytkowników w momencie zakończenia prac nad procesem.

F01.14.097. System musi umożliwiać generowanie i wydruk raportów

zbiorczych.

1.14.8 OPRACOWYWANIE WZORÓW FORMULARZY STATYSTYCZNYCH

F01.14.098. System zapewni obieg dokumentów w procesie „wzory formularzy

statystycznych”, realizowanym przez jednostki statystyki publicznej,



F01.14.099. System musi zapewnić przechowywanie dokumentów z wzorami

formularzy w centralnym repozytorium z podziałem (co najmniej) na

poszczególne roczniki.



str. 114

F01.14.0100.System musi zapewnić przechowywanie dokumentów dodatkowych

(instrukcji, wytycznych) w oddzielnym repozytorium dla dokumentów

nie biorących udziału w procesie.

F01.14.0101.System musi zapewnić możliwość nadawania użytkownikom

zróżnicowanych praw dostępu i widoczności do plików z wzorami

formularzy, w oparciu o następujące role:

a. administratorzy zatwierdzający wzory formularzy,

b. graficy,

c. autorzy formularzy,

d. współautorzy formularzy,

e. organizatorzy,

f. przedstawiciele Gabinetu Prezesa.

F01.14.0102.System musi zapewnić możliwość przydzielania do każdego

dokumentu osobno, odpowiedzialnych za niego użytkowników, w

oparciu o wymienione wyżej role 1-6.

F01.14.0103. System musi zapewnić możliwość oznaczenia dokumentów

dodatkowymi atrybutami np. komentarz, rok, informacja o typie

wersji (ostateczna, robocza).

F01.14.0104.System musi zapewnić możliwość wieloetapowej pracy w grupie

nad jednym dokumentem wzoru formularza.

F01.14.0105.System musi zapewnić możliwość dynamicznego określania

następnego etapu procesu (udostępnienia dokumentu dla dowolnej

innej roli w procesie).

F01.14.0106.System musi zapewnić możliwość dodania komentarza w

momencie wskazania następnego etapu procesu (wiadomość do

kolejnego użytkownika).Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 115

F01.14.0107.System musi zapewnić automatyczne powiadamianie użytkownika,

co najmniej poprzez e-mail, o udostępnionym mu dokumencie

(wskazaniu jako wykonawcy kolejnego etapu procesu), wraz z

pokazaniem mu wprowadzonego komentarza (wiadomości od

poprzedniego użytkownika).

F01.14.0108.System musi zapewnić możliwość ograniczenia jednoczesnego

dostępu do dokumentu wzoru formularza – widoczny tylko dla

aktualnie przypisanego, w danym etapie procesu, użytkownika.

F01.14.0109.System musi zapewnić możliwość modyfikacji wprowadzonego do

systemu dokumentu wzoru formularza z poziomu interfejsu

systemu.

F01.14.0110.System musi zapewnić wersjonowanie dokumentów wzorów

formularzy z zapewnieniem historii wersji i możliwości ich

przywrócenia.

F01.14.0111.System musi zapewnić możliwość dodania i podglądu komentarzy

do wersji.

F01.14.0112.System musi zapewnić możliwość archiwizacji zatwierdzonych

wzorów formularzy, po wcześniejszym ich zatwierdzeniu przez

Administratora zatwierdzającego.

F01.14.0113.System musi zapewnić wymuszenie wskazania osoby

zatwierdzającej w momencie zatwierdzania dokumentu.

F01.14.0114.System musi zapewnić możliwość wycofania z archiwum

dokumentu ze wzorem formularza i przywrócenie go do obiegu, z

jednoczesnym wycofaniem jego zatwierdzenia.

F01.14.0115.System musi zapewnić możliwość ograniczenia widoczności i

dostępu do archiwum dokumentów – pełna kontrola tylko dla roli

Administratora zatwierdzającego; pozostałe role – tylko podgląd.



str. 116

F01.14.0116.System musi zapewnić zapamiętanie atrybutów dokumentu i

przypisanych do dokumentu osób, w momencie przenoszenia

dokumentu do archiwum i wycofywania go z archiwum.

1.15 INTEGRACJA

1.15.1 EPUAP

F01.15.001. System musi posiadać wbudowany interfejs komunikacyjny

pozwalający na wymianę informacji (dokumentów wraz z zestawem

niezbędnych metadanych) z platformą ePUAP.

F01.15.002. System musi zapewniać komunikację zarówno w trybie

Urzędowego Poświadczenia Odbioru (UPO) jak i Urzędowego

Poświadczenia Doręczenia (UPD).

F01.15.003. System musi umożliwiać obsługę identyfikatorów korelacyjnych

ePUAP w celu identyfikacji konta użytkownika, z którego do SII

został przekazany komunikat.

F01.15.004. System musi umożliwiać przekazywanie dokumentów

wychodzących z poziomu SEOD na konta użytkowników i instytucji

na ePUAP.

1.15.2 EXCHANGE

F01.15.005. System musi współpracować z istniejącym u Zamawiającego

systemem poczty opartym na Exchange 2010.

F01.15.006. System musi pozwalać na wykorzystanie, w witrynach bądź listach

Systemu, elementów funkcjonalnych, które umożliwią dostęp do

następujących folderów konta e-mail danego użytkownika:

a) kalendarz,

b) kontakty,

c) zadania,

d) skrzynka odbiorcza.Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 117

F01.15.007. System musi umożliwiać taką konfigurację, aby poczta wysłana pod

adres przypisany do listy Portalu (kalendarz lub repozytorium

dokumentów) została w niej zapisana.

F01.15.008. System musi zapewnić, że prezentowane informacje, będą

dotyczyły tylko aktualnie zalogowanego użytkownika Systemu.

1.15.3 BROKER KOMUNIKACYJNY

System musi komunikować się z Brokerem Komunikacyjnym opartym o technologię

BizTalk Server w następujący sposób:

1.15.3.1 INTERFEJSYF01.15.009. Zamawiający dopuszcza zastosowanie do budowy interfejsów

integracyjnych następujących metod:

a) usługi (WebServices),

b) tabele interfejsowe w bazie danych,

c) pliki XML.

F01.15.010. Dostęp do poszczególnych interfejsów musi być ograniczony

jedynie dla Brokera Komunikacyjnego, poprzez nałożenie,

odpowiednich dla wykorzystywanego protokołu, zabezpieczeń.

1.15.3.2 USŁUGI (WEBSERVICES)F01.15.011. Interfejs musi umożliwiać komunikację w oparciu o protokół http i

https. Komunikacja może być jednokierunkowa i dwu kierunkowa

(żądanie – odpowiedz). Dopuszcza się dwa rodzaje kodowania:

Text i MTOM.

F01.15.012. Mechanizm autentykacji klientów usługi (Client authentication

mechanism) musi pozwalać na autentykację na poziomie warstwy

transportowej, jak i komunikatu (Transport Security and Message

Security). Może być to autentykacja Windows lub autentykacja



str. 118

z wykorzystaniem certyfikatu X.509.

F01.15.013. Interfejs musi być zgodny z rozszerzeniami WS-*:

a) WS-Security, wspierając poniższe standardy:

Web Services Security: SOAP Message Security (WS-

Security) 1.0 i 1.1,

Web Services Secure Conversation Language (WS-

SecureConversation 1.3),

Web Services Trust Language (WS-Trust 1.3),

Web Services Security X.509 Certificate Token Profile 1.0 i

1.1,

Web Services Security Username Token Profile 1.0 i 1.1,

Web Services Security Kerberos Token Profile 1.0 i 1.1.

b) WS-AtomicTransaction 1.1:

transakcyjne odbieranie komunikatów,

transakcyjne wysyłanie komunikatów.

c) WS-Adressing 1.0:

definicja powiązania punktów końcowych i nagłówków

informacyjnych wiadomości.

1.15.3.3 TABELE INTERFEJSOWE W BAZIE DANYCHF01.15.014. System do komunikacji z Brokerem Komunikacyjnym może

wykorzystywać tabele interfejsowe w bazie danych. Do komunikacji

z Brokerem Komunikacyjnym powinny zostać utworzone tabele do

wysyłania informacji do innych systemów i tabele do pobierania

danych od brokera.

Wspierane wersje Oracle:

a) Oracle 9i (9.2.0.2),

b) Oracle 10g (10.1.0.2.0 & 10.2.0.1.0),

c) Oracle 11g.

Wersje bazy danych SQL Server:Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 119

a) SQL Server 2000,

b) SQL Server 2005,

c) SQL Server 2008.

F01.15.015. Wykonawca musi zapewnić możliwość oznaczenia statusu wymiany

informacji poprzez dodanie do tabel kolumny określającej status

np.: 0 – do odczytu, 1 – odczytane, 2 – potwierdzone dostarczenie.

F01.15.016. Tabele interfejsowe w bazie danych muszą zawierać kolumny

o typach prostych, bez typów XML.

F01.15.017. W celu ograniczenia dostępu do tabel interfejsowych muszą być

wykorzystane mechanizmy autentykacji i autoryzacji bazy danych

w połączeniu z funkcjonalnością usług katalogowych.

1.15.3.4 PLIKI XMLF01.15.018. Wymiana informacji musi być możliwa poprzez zapis i odczyt plików

XML z systemu NTFS. Pliki mogą być umieszczane lokalnie lub na

udziale sieciowym. System udostępnia swoje informacje poprzez

zapis ich do plików, które są odczytywane przez brokera

komunikacyjnego. Broker może też tworzyć pliki z informacjami dla

systemu. Pliki XML powinny być kodowane w formacie UTF-16.

F01.15.019. Do zabezpieczenia bezpieczeństwa przesyłanych danych musi być

wykorzystany mechanizm uprawnień NTFS.

F01.15.020. Specyfikacja funkcji realizowanych przez interfejsy zostanie

określona przez zespoły po stronie Zamawiającego i wykonawcy na

etapie tworzenia specyfikacji technicznej systemu.

1.15.4 SYSTEM SOFTUSF01.15.021. System musi umożliwić automatyczne pobranie i przekazanie przez

Broker Komunikacyjny oparty o technologię BizTalk Server do

modułu kadrowego systemu SOFTUS (system HR) niezbędnych Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 120

informacji z procesów związanych z dyscypliną pracy.

F01.15.022. Zakres przekazanych informacji zostanie opracowany na etapie

projektu technicznego.

1.15.5 UNIFIED COMMUNICATION

F01.15.001. System musi umożliwić integrację z użytkowanym u Zamawiającego

Microsoft Lync poprzez wyświetlanie w systemie SII statusu

dostępności danego pracownika wraz z możliwością wykonania z

poziomu SII:

a. połączenia typu chat, głos czy video,

b. zaplanowania spotkania,

c. wysłania e-mail,

d. dodania do kontaktów Outlook,

e. wyświetlenia właściwości Outlook.

1.15.6 SYSTEM EDUKACYJNY

F01.15.023. System musi umożliwić rezerwację (w tym zmianę rezerwacji i

usunięcie rezerwacji) zasobów zdefiniowanych w module rezerwacji

zasobów z poziomu Sytemu Edukacyjnego GUS.

F01.15.024. System musi umożliwić wykorzystanie modułu struktury

organizacyjnej SII z poziomu Systemu Edukacyjnego GUS w

zakresie akceptacji zapisów na szkolenia pracowników jednostek

statystyki publicznej.

1.15.7 PORTAL INFORMACYJNY GUSF01.15.025. System musi posiadać usługe sieciową dedykowaną dla Biuletynu

Informacji Publicznej Portalu Internetowego GUS (WebService

opisany z pomocą opisu usług sieciowych WSDL) służącą do Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 121

przesyłania meta danych i plików z Systemu. Szczegółowa

specyfikacja tej usługi zostanie określona na etapie wdrożenia.

1.16PODPIS ELEKTRONICZNY

1.16.1 WERYFIKACJA PODPISU ELEKTRONICZNEGO F01.16.001 Wykonawca dostarczy niezbędne komponenty technologiczne

pozwalające na weryfikację poprawności podpisu elektronicznego i

statusu powiązanego z nim certyfikatu klucza publicznego. Wynik

weryfikacji powinien pozwalać na dostarczenie wszystkich

niezbędnych informacji związanych z wynikiem weryfikacji danego

podpisu elektronicznego oraz powiązanego z nim certyfikatu klucza

publicznego.

F01.16.002 Rozwiązanie musi zapewnić wiarygodną weryfikację poprawności

podpisu (-ów) elektronicznego złożonego pod dokumentami

elektronicznymi, statusu certyfikatu (-ów) klucza publicznego oraz

statusu znacznika (-ów) czasu.

F01.16.003 Rozwiązanie musi pozwalać na realizację co najmniej 5 000 000

weryfikacji w ciągu roku.

F01.16.004 Rozwiązanie musi zapewnić wiarygodną weryfikację poprawności

certyfikatów wszystkich krajowych kwalifikowanych Centrów

Certyfikacji, wpisanych do rejestru podmiotów kwalifikowanych,

opublikowanym na stronach Narodowego Centrum Certyfikacji

(www.nccert.pl), zgodnie ze specyfikacją ETSI TS 101 903 v1.3.2

lub nowszą.

F01.16.005 Rozwiązanie musi zapewnić weryfikację formatów certyfikatów

niekwalifikowanych zgodnych ze standardem X.509 v3 z

wewnętrznego PKI GUS.

F01.16.006 Rozwiązanie musi zapewnić możliwość dodania wystawcy (zgodnie

z odpowiednimi wymaganiami dla wystawców) w czasie działania



str. 122

systemu.

F01.16.007 Rozwiązanie musi zapewnić dostęp do usługi (weryfikację podpisu

elektronicznego) dla dokumentów przekazywanych przez

najpopularniejsze protokoły komunikacyjne (co najmniej usługi

sieciowe WebServices z wykorzystaniem protokołu SOAP, http,

https).

F01.16.008 Rozwiązanie musi w prosty sposób umożliwić dostarczenie usługi

dla usług sieciowych.

F01.16.009 Rozwiązanie musi zapewniać pełną automatyzację procesu

weryfikacji.

F01.16.010 Rozwiązanie musi zapewniać dostęp do usługi za pośrednictwem

dedykowanych bibliotek API, przy czym jako API można także

rozumieć udostępnienie usług sieciowych (WebServices).

F01.16.011 Rozwiązanie musi zapewnić pełną weryfikację zarówno samego

podpisu, jak i całej ścieżki certyfikacji certyfikatu.

F01.16.012 Rozwiązanie musi zapewnić możliwość odróżnienia certyfikatów

kwalifikowanych od pozostałych certyfikatów.

F01.16.013 Rozwiązanie musi zapewnić weryfikację podpisu złożonego na

platformie ePUAP.

F01.16.014 Rozwiązanie musi zapewnić weryfikację po CRL.

F01.16.015 Rozwiązanie musi zapewnić weryfikację po OCSP.

F01.16.016 Rozwiązanie musi zapewnić weryfikację podpisów złożonych

w formie kontrasygnaty.

F01.16.017 Rozwiązanie musi zapewnić weryfikację zarówno podpisów

elektronicznych w postaci wewnętrznej, jak i zewnętrznej.

F01.16.018 Rozwiązanie musi zapewnić możliwość weryfikacji ważności

podpisu złożonego przy wykorzystaniu profilu zaufanego za pomocą

platformy ePUAP.



str. 123

F01.16.019 Rozwiązanie powinno umożliwić określenie maksymalnej wielkości

weryfikowanych plików zarówno za pośrednictwem protokołu SOAP

jak i API.

F01.16.020 W przypadku, gdyby rozwiązanie nie dawało możliwości

parametryzacji wielkości weryfikowanych plików, rozwiązanie

powinno umożliwiać zweryfikowanie co najmniej plików o wielkości

do 5 MB.

1.16.2 PODPISYWANIE

F01.16.021 Rozwiązanie musi zawierać aplet podpisujący, rozumiany jako

komponent służący do składania podpisu elektronicznego.

F01.16.022 Aplet podpisujący musi umożliwiać podpisanie danych

z wykorzystaniem podłączonego do stacji komponentu

sprzętowego bezpiecznego urządzenia do składania podpisów

elektronicznych (np. karty kryptograficznej) dostarczającego

interfejs zgodny ze standardem PKCS#11.

F01.16.023 Aplet podpisujący musi pozwalać na realizację co najmniej

2 000 000 podpisów w ciągu roku przy założeniu standardowego

pliku o wielkości ok. 100 KB.

F01.16.024 Aplet podpisujący musi zapewnić możliwość podpisania

dokumentów certyfikatami wszystkich krajowych kwalifikowanych

Centrów Certyfikacji, wpisanych do rejestru podmiotów

kwalifikowanych, opublikowanym na stronach Narodowego

Centrum Certyfikacji (www.nccert.pl), zgodnie ze specyfikacją

ETSI TS 101 903 v1.3.2 lub nowszą (po zainstalowaniu na stacji

podpisującej sterownika pkcs#11 dostarczonego przez dostawcę

komponentu sprzętowego bezpiecznego urządzenia do składania

podpisów).



str. 124

F01.16.025 Rozwiązanie musi umożliwić złożenie podpisu za pomocą profilu

zaufanego ePUAP.

F01.16.026 Aplet podpisujący musi zapewnić podpisanie dokumentów,

zarówno w dowolnym formacie binarnym (PDF, XLS, inne) jak i

dokumentów XML.

F01.16.027 Aplet podpisujący musi zapewnić podpisywanie dokumentów

podpisem niekwalifikowanym z certyfikatem zgodnym ze

standardem X.509 v3 z wewnętrznego PKI GUS.

F01.16.028 Aplet podpisujący poza integracją z procesem podstawowym musi

zapewniać dobrze zdefiniowany i opisany interfejs

programistyczny, umożliwiający co najmniej zainicjowanie operacji

podpisu, wskazanie danych do podpisania i odebranie

podpisanych danych. Interfejs ten musi umożliwiać wywołanie go

np. poprzez kontrolki z następujących źródeł:

a) formularze - po wykonaniu czynności podpisania podpisane

dane muszą zostać przekazane pod wskazany w ustawieniach

adres,

b) biblioteki dokumentów użytkowanego w jednostkach statystyki

MS Sharepoint - po wykonaniu czynności podpisania

podpisane dane muszą zostać przekazane pod wskazany w

ustawieniach adres,

F01.16.029 Aplet podpisujący musi umożliwiać zintegrowanie go z portalem

lub aplikacją, w ramach której składane są podpisy elektroniczne

pod dokumentami.

F01.16.030 Aplet podpisujący musi zapewnić możliwość wybrania z magazynu

certyfikatów dowolnego certyfikatu do podpisu z możliwością

wyboru kwalifikowany/wszystkie.

F01.16.031 Aplet podpisujący musi zapewnić możliwość podejrzenia treści

podpisywanego pliku (co najmniej format XML) samodzielnie przez



str. 125

aplikację bądź z wykorzystaniem aplikacji zewnętrznych.

F01.16.032 W przypadku podejrzenia pliku z wykorzystaniem aplikacji

zewnętrznej rozwiązanie musi zapewnić możliwość wyboru

aplikacji wykorzystując mechanizmy wbudowane w system

operacyjny.

F01.16.033 Rozwiązanie musi zapewnić możliwość oznakowania podpisu

znacznikiem czasu z dowolnego źródła spełniającego normę RFC

3161 dla znakowania czasem w tym z wewnętrznego TSA GUS i

kwalifikowanych centrów certyfikacji przy zapewnieniu przez

Zamawiającego dostępu do kwalifikowanego znacznika czasu.

F01.16.034 Rozwiązanie musi zapewnić możliwość konfiguracji ustawień

podpisywania przynajmniej w zakresie:

a) rodzaj XADES (XADES-BES, XADES-T),

b) podpis w postaci wewnętrznej, zewnętrznej.

F01.16.035 Rozwiązanie musi zapewnić parametryzację i skonfigurowanie

apletu w celu dostosowania go do wymagań konkretnego systemu

co najmniej w następującym zakresie:

a) wymuszenie certyfikatu kwalifikowanego,

b) tryb podpisu – zwykły podpis bądź kontrasygnata,

c) adres serwera znakowania czasem,

d) generowanie osobnych podpisów dla wszystkich

przekazanych danych czy jednego podpisu pod wszystkimi

danymi.

F01.16.036 Rozwiązanie musi umożliwić wygenerowanie jednego wspólnego

podpisu dla wielu danych (podpis wielokrotny), jak również

dodanie kontrasygnat pod już istniejącymi podpisami.



str. 126

1.16.3 BUDOWA WEWNĘTRZNEGO SERWERA ZNAKOWANIA CZASEM (TSA)

F01.16.037 Rozwiązanie musi umożliwiać zaopatrywanie dokumentów

elektronicznych w stempel czasowy.

F01.16.038 Rozwiązanie musi zapewnić zgodność z normami RFC 3161,

ETSI TS 101 861, ETSI TS 102 023, ETSI TS 101 731.

F01.16.039 Rozwiązanie musi zapewnić dostarczenie dowodu na istnienie

danych w momencie oznaczania czasem.

F01.16.040 Zdarzenie oznaczenia czasem powinno być rejestrowane w bazie

danych żądań znakowania czasem.

F01.16.041 Rejestracji powinny podlegać przesyłane zapytania i udzielone

odpowiedzi.

F01.16.042 Rozwiązanie powinno zawierać interfejs służący co najmniej do

przeglądania bazy danych żądań znakowania czasem.

F01.16.043 Rozwiązanie musi zapewnić synchronizację z wzorcowym

serwerem czasu Głównego Urzędu Miar poprzez protokół NTP.

F01.16.044 Rozwiązanie musi zapewnić zapasowy wzorzec czasu w

przypadku przerw w działaniu serwerów Głównego Urzędu Miar.

F01.16.045 Zamawiający dopuszcza instalację na serwerach Zamawiającego

sprzętowego wzorca sekundy jako drugiego wzorca czasu.

F01.16.046 Rozwiązanie musi zapewnić możliwość synchronizacji z innymi

zewnętrznymi wzorcowymi serwerami czasu przez protokół NTP.

F01.16.047 Rozwiązanie musi zapewnić obsługę minimum 5 żądań o znacznik

czasu na sekundę.

F01.16.048 Rozwiązanie musi zapewnić dostęp do znaczników czasu dla

elektronicznego archiwum GUS umożliwiając długoterminowe

przechowywanie dokumentów podpisanych podpisem

elektronicznym w sposób zapewniający zabezpieczenie ich Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 127

wartości dowodowej.

1.16.4 SPRZĘTOWY MODUŁ KRYPTOGRAFICZNY (HARDWARE SECURITY MODULE)

F01.16.049 Rozwiązanie musi zapewnić możliwość przechowywania klucza prywatnego Centrum Certyfikacji (CA) w urządzeniu HSM.

F01.16.050 HSM musi być zgodny z standardem co najmniej FIPS 140-2 poziom 3.

F01.16.051 HSM musi zapewnić możliwość podpisania (rozumianego jako złożenie podpisu pod przesłanymi danymi) Urzędowego Potwierdzenia Odbioru (UPO) dla dokumentów przyjmowanych ze źródeł zewnętrznych w tym Elektronicznej Skrzynki Podawczej GUS.

F01.16.052 Rozwiązanie musi umożliwiać nawiązywanie połączeń z HSM przez sieć opartą na protokole TCP/IP z co najmniej 3 korzystających z niego urządzeń.

F01.16.053 HSM musi potrafić wykonać co najmniej 60 operacji RSA z wykorzystaniem kluczy o długości 4096 bit na sekundę.

F01.16.054 HSM musi zapewnić ochronę przed nieupoważnionym dostępem i powinien znajdować się w bezpiecznej obudowie odpornej na nieuprawnioną ingerencję zewnętrzną.

F01.16.055 HSM musi zapewniać możliwość ochrony klucza prywatnego RSA o długości 2048–bitów i powyżej.

F01.16.056 HSM musi poprawnie współpracować co najmniej z następującymi systemami operacyjnymi:

a) MS Windows Serwer 2003R2 w środowisku co najmniej 32-bitowym,

b) MS Windows Server 2008R2 w środowisku 32-bitowym i 64-bitowym,

c) Linux.

F01.16.057 HSM musi obsługiwać co najmniej następujące API:

a) PKCS#11,

b) CSP for Microsoft CryptoAPI,



str. 128

c) OpenSSL,

d) CNG (Cryptography Next Generation).

F01.16.058 HSM musi obsługiwać następujące algorytmy:

a) symetryczne: AES, DES, 3DES,

b) asymetryczne: DSA, El Gamal, RSA,

c) wymiany kluczy: Diffie-Hellman,

d) hash: MD5, SHA-1, SHA-2.

F01.16.059 HSM musi zapewniać w przyszłości możliwość pracy w układach wysokiej dostępności (ang. High Availability) umożliwiających pełną redundantność i rozkładanie obciążenia.

F01.16.060 HSM musi zapewniać możliwość obsługi wielu serwerów, w tym również zbudowanych w oparciu o maszyny wirtualne, przez jeden moduł HSM.

F01.16.061 HSM musi zapewniać możliwość obsługi wielu aplikacji przez jeden moduł HSM.

F01.16.062 HSM musi zapewniać możliwość równoległej obsługi, przez jeden moduł HSM, wielu kompletów kluczy.

F01.16.063 HSM nie powinien mieć ograniczeń na liczbę chronionych przez moduł kluczy.

F01.16.064 HSM powinien zapewniać możliwość wykonywania kopii zapasowych kluczy prywatnych chronionych przez HSM.

2 WYMAGANIA NIEFUNKCJONALNE

2.1 WYMAGANIA OGÓLNE

N02.01.001. Rozbudowany System będzie użytkowany na terenie całego kraju.

Wykaz lokalizacji objętych zasięgiem wdrożenia sytemu zawiera

tabela umieszczona w Załączniku nr 2 do SIWZ: Opis Przedmiotu

Zamówienia. Zaproponowane rozwiązanie będzie kompletne, nie

wymagające od Zamawiającego prac dostosowawczych.

N02.01.002. Przy rozbudowie architektury należy zastosować technologie Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 129

wysokiej dostępności oraz technologie wirtualizacji, uwzględniając

posiadane przez Zamawiającego zasoby sprzętowo-programowe,

opisane w Załączniku nr 3 do SIWZ - – Opis środowiska

Zamawiającego, oraz realizowane projekty – a w szczególności

wdrożenie platformy wirtualizacji DataCenter w oparciu o produkty

VMWare.

N02.01.003. Wykonawca musi opracować i wdrożyć rozbudowany System

Informacyjny Intranet w środowiskach:

a) produkcyjnym – środowisko, w którym będzie funkcjonowało

rozwiązanie produkcyjnie. W środowisku tym będą tylko

komponenty wykorzystywane produkcyjnie,

b) testowym – środowisko funkcjonalnie zbliżone do środowiska

produkcyjnego, ale bez redundancji komponentów, fizycznie od

niego odseparowane – dedykowane do testów funkcjonalnych

oraz testowania poprawek i upgrade.

N02.01.004. Wykonawca musi zaprojektować i wdrożyć system monitorowania

SII w oparciu o eksploatowane obecnie przez Zamawiającego

Systemy.

N02.01.005. Wykonawca dostarczy wytyczne jak dostosować eksploatowane

aktualnie środowisko System Center Operations Manager (SCOM)

w celu monitorowania SII i wdroży monitorowanie.

N02.01.006. Wykonawca musi opracować i wdrożyć procedury zachowania

spójności pomiędzy środowiskami (produkcyjnym i testowym) w

zakresie konfiguracji oprogramowania oraz danych. Konfiguracja

środowiska testowego powinna odzwierciedlać środowisko

produkcyjne w zakresie umożliwiającym wykonanie procedur

testowych.

N02.01.007. System będzie skutecznie funkcjonował w ramach dostępnej

w jednostkach statystyki publicznej infrastruktury intranetowej Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 130

i internetowej.

N02.01.008. Poszczególne moduły systemu SII będą miały możliwość dalszego

rozwoju bez konieczności znaczących zmian projektowych w

wyniku zwiększania, w miarę upływu czasu, liczby przetwarzanych

procesów oraz pomnażania liczby faktycznych użytkowników,

w celu pozostawiania czasu oczekiwania na odpowiedź na

niezmienionym poziomie.

N02.01.009. System będzie posiadał możliwość rozwoju poprzez implementację

procesów przewidzianych do wdrożenia w terminie późniejszym

w oparciu o dostarczone w ramach jego budowy narzędzia.

N02.01.010. Przez wzgląd na obecnie istniejące uwarunkowania

u Zamawiającego, w szczególności posiadany już zasób sprzętowo-

systemowy oraz oprogramowanie wraz z licencjami wymienione w

w Załączniku nr 3 do SIWZ: Opis środowiska Zamawiającego,

Zamawiający wymaga wykorzystania go do rozbudowy systemu SII.

N02.01.011. Dla apletów kryptograficznych rozwiązanie nie może wymagać

instalacji dodatkowego oprogramowania na komputerach

użytkowników (dopuszczalna jest konieczność włączenia obsługi

języka Java i Javascript w przeglądarce) oraz musi dostarczyć

niezbędne sterowniki i biblioteki do komunikacji, z wyjątkiem

sterowników do kart dostarczanych zawsze przez dostawcę podpisu

elektronicznego oraz sterowników objętych licencjami innych

producentów.

2.2 UŻYWALNOŚĆ/ERGONOMIA

N02.02.001. System musi umożliwiać pracę minimum w trzech standardowych

rozdzielczościach ekranu: 1024x768, 1280x1024 i 1280x960 bez

zmiany układu widoku.



str. 131

N02.02.002. System musi umożliwiać zmianę wielkości czcionki bez zmiany

układu widoku, zdefiniowane powinny być przynajmniej trzy

wielkości czcionek.

N02.02.003. Dostęp do systemu dla użytkownika musi odbywać się ze stacji

klienckiej przy użyciu przeglądarki internetowej Pełna

funkcjonalność rozwiązania powinna być dostępna co najmniej z

poziomu przeglądarki Internet Explorer (wersja 7.0 i nowsze)

Podstawowa funkcjonalność rozwiązania (przeglądanie stron

portalu, publikowanie dokumentów, obsługa procesów) powinna być

dostępna z poziomu co najmniej przeglądarki Mozilla Firefox

(wersja 2.0 i nowsze). Specyficzne funkcjonalności mogą działać z

poziomu innych przeglądarek niż Internet Explorer w ograniczonym

zakresie.

N02.02.004. Czas reakacji systemu na działanie (akcję) użytkownika nie może

przekroczyć 3 sekund.

N02.02.005. System nie może podczas dostępu do żadnej z funkcji wymagać

podania informacji niezbędnych do uwierzytelnienia od osób już

uwierzytelnionych w tym samym systemie lub w domenie.

N02.02.006. System będzie zapewniać obsługę transakcji - złożona informacja

zostanie na trwale zapisana w bazie danych tylko wówczas, gdy

zapisane zostaną wszystkie elementy składowe.

2.3 BEZPIECZEŃSTWO

N02.03.001. System musi wspierać model uprawnień do wykonywania operacji

na każdym poziomie architektury, w tym uprawnień do

wykonywania każdej z wyspecyfikowanych w niniejszym

dokumencie operacji na treści portalu, operacji na strukturze portalu

oraz operacji związanych z integracją (dostępem do interfejsów

integracyjnych) i funkcji bezpieczeństwa.



str. 132

N02.03.002. Model uprawnień w ramach Systemu musi przewidywać możliwość

ustalenia uprawnień na dowolnym poziomie architektury Systemu

oraz możliwość ustalenia, że na danym poziomie architektury

uprawnienia będą dziedziczone z elementu nadrzędnego.

N02.03.003. Model uprawnień w ramach Systemu powinien przewidywać

możliwość ustalenia polityk dostępu do informacji na poziomie

całego Systemu, które mają pierwszeństwo nad uprawnieniami

nadanymi lokalnie. Polityki powinny przewidywać możliwość

udzielenia, jak również odmowy udzielenia uprawnień

użytkownikom lub grupom.

N02.03.004. System musi posiadać konfigurowalny mechanizm audytów

pozwalający:

a) umieszczać w dzienniku audytu operacje wykonane strukturze

portalu oraz na mechanizmach bezpieczeństwa,

b) zdefiniować, na jakich obiektach Portalu będą działać audyty

oraz które zdarzenia podlegają audytowi,

c) wyświetlać zawartość logów audytowych przez osoby

uprawnione i eksportować ich zawartość do arkusza

kalkulacyjnego lub pliku tekstowego.

N02.03.005. System powinien ułatwiać zarządzanie uprawnieniami do

dokumentów i folderów poprzez atrybuty typu "Uprawniona osoba"

lub "Uprawniona grupa", których ustawienie będzie jednoznaczne z

automatycznym nadaniem odpowiednich uprawnień (zgodnie z

konfiguracją) osobom lub grupom do nich przypisanym.

N02.03.006. Konfiguracja uprawnień Systemu powinna być zrealizowana

zgodnie z zasadą minimalnych uprawnień.

N02.03.007. Podczas umieszczania nowych folderów lub dokumentów

w korzeniu lokalizacji (folder główny), użytkownicy nie mogą mieć Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 133

uprawnień do dostępu do nowo umieszczonych dokumentów i

folderów, jeśli nie zostały im one jawnie nadane na poziomie tych

elementów. Ta reguła nie dotyczy grup uprzywilejowanych, które na

poziomie lokalizacji posiadają dostęp do wszystkich dokumentów na

określonym poziomie.

N02.03.008. Wszystkie przepływy pracy opisane w załączniku nr 8, w momencie

przydzielania użytkownikom zadań, powinny automatycznie

przydzielać użytkownikom odpowiednie uprawnienia do obiektów,

na których pracują oraz do obiektów powiązanych, zgodnie z logiką

przepływu. Delegowanie zadań do innych pracowników musi

pociągać za sobą nadanie odpowiednich uprawnień pracownikom,

którzy otrzymali delegowane zadanie do realizacji.

N02.03.009. Zamawiający wymaga, aby system posiadał mechanizmy obronne

przed atakami informatycznymi na bazy danych, w których

przechowywane są informacje.

N02.03.010. System musi zapewniać ochronę zatwierdzonych elementów przed

nieautoryzowanymi zmianami.

N02.03.011. System będzie zapewniać synchronizację zegara systemowego ze

źródłami czasu za pomocą protokołu NTP lub mechanizmów Active

Directory w celu utrzymania wiarygodności logów systemowych.

N02.03.012. System musi umożliwiać korzystanie z protokołu SSL dla

zabezpieczenia przesyłanych informacji lub w inny sposób

zapewniać szyfrowanie przesyłania danych.

N02.03.013. System będzie zapewniać monitorowanie prób naruszenia

bezpieczeństwa systemu, w tym prób nieuprawnionego dostępu

do systemu (tj. próby nieudane, ostrzeżenia systemowe i błędy).

N02.03.014. System musi zawierać mechanizmy wysyłania powiadomień

o incydentach na adres e-mail.



str. 134

N02.03.015. System musi udostępnić mechanizm monitorowania dostępności

usług, zintegrowany z scentralizowanym systemem monitorowania

posiadanym przez Zamawiającego.

N02.03.016. System musi zapewnić pełną identyfikowalność użytkowników

i przypisanie odpowiedzialności za działania wykonane w systemie.

N02.03.017. System musi zapewnić blokowanie dostępu określonych

użytkowników do zasobów systemu.

N02.03.018. System zapewni mechanizmy zachowania integralności danych.

N02.03.019. System zapewni taką budowę struktur danych, aby pozwalały na

szybkie odtworzenie ich zawartości i właściwego stanu, jak również

pozwalały na łatwe wykonanie kopii bieżących oraz odtwarzanie

z kopii zapasowych.

N02.03.020. System uniemożliwi modyfikowanie logów systemowych.

N02.03.021. System zapewni logowanie prób usuwania logów systemowych.

N02.03.022. System zapewni interfejs umożliwiający sprawne przeszukanie

logów według zadanych kryteriów.

N02.03.023. W przypadku awarii spowodowanej błędem oprogramowania

systemu operacyjnego lub bazy danych istniała będzie możliwość

odzyskania wszystkich możliwych do odczytania transakcji.

2.4 SKALOWALNOŚĆ I WYDAJNOŚĆ

N02.04.001. System zapewni skalowalność gwarantującą rozszerzenie ilości

obsługiwanych użytkowników (stanowisk) oraz pracę w środowisku

rozproszonym.

N02.04.002. System zapewni możliwość rozbudowy warstwy prezentacyjnej,

aplikacyjnej i bazodanowej przy zachowaniu odpowiedniej jakości Projekt SISP współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju


str. 135

usług i wydajnej synchronizacji danych pomiędzy poszczególnymi

serwerami poprzez zwiększenie zasobów komputerów

obsługujących warstwy, poprzez rozbudowę pamięci, zwiększenie

liczby procesorów, zwiększenie pojemności pamięci masowych itp.

N02.04.003. System musi sprawnie funkcjonować w warunkach rosnącej liczby

użytkowników, objętości przetwarzania danych lub/i rozwoju sieci

komputerowej.

N02.04.004. Liniowy wzrost liczby i rozmiaru danych przechowywanych w

ramach Systemu nie może zwiększać czasu wyszukiwania bardziej

niż liniowo.

N02.04.005. Sposób rozbudowy Systemu oraz dostarczone przez wykonawcę

źródła i dokumentacja dla rozbudowywanych modułów muszą

umożliwiać wykonywanie zmian w elementach Systemu

wytworzonych w ramach realizacji zlecenia bez udziału wykonawcy.

2.5 INTEROPERACYJNOŚĆ

N02.05.001. System w maksymalnym stopniu będzie bazował na dorobku

portalu interoperacyjności ePUAP w zakresie struktur danych oraz

sposobu komunikacji z zewnętrznymi instytucjami (np. przy

przyjmowaniu danych z systemów innych instytucji). W

maksymalnym stopniu zostaną w systemie użyte struktury atomowe

ePUAP a wszystkie stworzone wzory dokumentów muszą umożliwić

opublikowanie ich w Centralnym Repozytorium Dokumentów na

ePUAP.

N02.05.002. System zapewni możliwość integracji danych i aplikacji z innymi

systemami – relacyjnymi bazami danych (minimum obsługa ODBC).

N02.05.003. System musi umożliwiać synchroniczną i asynchroniczną

komunikację pomiędzy systemami lub samodzielnymi modułami.



str. 136

N02.05.004. System musi umożliwiać zidentyfikowanie i wykorzystanie usług

udostępnianych przez systemy lub samodzielne moduły.

N02.05.005. System musi wykorzystywać standard XML do wymiany danych.

N02.05.006. W przypadku wymiany dokumentów w formacie XML system będzie

używać standardu XSD do ich weryfikacji.

N02.05.007. System musi być oparty o standardowe protokoły, standardy

kodowania, standardy realizacji interfejsów użytkownika, język

programowania oraz protokoły komunikacyjne.

2.6 NIEZAWODNOŚĆ

N02.06.001. System po rozbudowie musi zapewniać dostępność ciągłą

w systemie 24 godziny dziennie, 7 dni w tygodniu. Dopuszczalna

jest chwilowa przerwa w pracy systemu na czas uruchamiania

aplikacji w trybie awaryjnym.

N02.06.002. Dopuszczalna jest ustalona z Zamawiającym z tygodniowym

wyprzedzeniem przerwa w pracy Systemu, na czas konserwacji.

Przerwa ta nie może wystąpić częściej niż dwa razy w miesiącu

i nie może trwać dłużej niż 4 godziny w godzinach pracy.

Jednocześnie wykonawca uwzględni przy planowaniu przerw

w czasie dostępności Systemu dobowe i tygodniowe obciążenie, tj.

zaplanuje przerwy w okresach spodziewanego niskiego obciążenia

Systemu.

N02.06.003. Nieplanowana niedostępność Systemu rozumiana jako wystąpienie

błędu uniemożliwiającego częściową lub całkowitą pracę

środowiska w sposób odczuwalny dla Zamawiającego nie może

w skali miesiąca wynieść więcej niż 0,05% (dostępność systemu –

99,5%).



str. 137

2.7 ŁATWOŚĆ PIELĘGNACJI

N02.07.001. Wykonawca dostarczy kod źródłowy aplikacji rozbudowywanych lub

wykonanych w ramach wdrożenia systemu. Dla każdego elementu

funkcjonalnego oprogramowania wykonanego w ramach

zamówienia zostanie dostarczona dokumentacja dotycząca funkcji

realizowanych w elemencie funkcjonalnym oprogramowania.

N02.07.002. Gwarancja musi umożliwiać modyfikację szablonów raportów,

dokumentów, spraw, formularzy, pól w rejestrach oraz definicji

przepływów pracy za pomocą funkcji systemu bez utraty gwarancji.

2.8 STANDARDY

N02.08.001. Wykonawca zapewni zgodność zaproponowanego rozwiązania

z powszechnie akceptowalnymi standardami.

N02.08.002. System musi wspierać standard XMLsig (XML-Signature Syntax

and Processing).

N02.08.003. System musi wspierać standard XMLenc (XML Encryption Syntax

and Processing).

N02.08.004. System musi wspierać standard WSDL (Web Services Description

Language).

N02.08.005. System musi wspierać protokół SOAP (Simple Object Access

Protocol).

N02.08.006. System musi posiadać interfejs dostępu zgodny z JDBC/ODBC.

N02.08.007. System musi wspierać standard XML (Extensible Markup

Language).



str. 138

N02.08.008. System musi wspierać standard XSD.

N02.08.009. System musi wspierać język XSL (Extensible Stylesheet Language).

N02.08.010. System musi wspierać język XSLT (Extensible Stylesheet Language

Transformation).

N02.08.011. System musi wspierać standard Unicode UTF-8 (Universal Multiple-

Octet Coded Character Set, UCS transformation format UTF-8).

N02.08.012. System musi wspierać format RTF (Rich Text Format Specification).

N02.08.013. System musi wspierać format PDF (Portable Document Format).

N02.08.014. System musi wspierać format DOC.

N02.08.015. System musi wspierać format XLS.

N02.08.016. System musi wspierać format PPT.

N02.08.017. System musi wspierać format Office Open XML.

N02.08.018. System musi wspierać format ODT (Open Document Format for

Office Application).

N02.08.019. System musi wspierać format JPG i JPEG (Joint Photographic

Experts Group).

N02.08.020. System musi wspierać format GIF (Graphics Interchange Format).

N02.08.021. System musi wspierać format TIF i TIFF (Tagged Image File

Format).

N02.08.022. System musi wspierać format PNG (Portable Network Graphics).

N02.08.023. System musi wspierać format SVG (Scalable Vector Graphics).

N02.08.024. System musi obsługiwać jeden z protokołów SAML (Security



str. 139

Assertion Markup Language) lub Kerberos oraz protokół NTP

(Network Time Protocol).

N02.08.025. Aplikacja systemu zapewni obsługę powszechnie przyjętych i

stosowanych standardów: SMTP, MIME, S/MIME, SSL, POP3,

IMAP4, LDAP, HTTP, HTML, SNMP, X.509.

N02.08.026. Interfejs musi być zgodny ze standardem minimum XHTML 1.0

Transitional.

N02.08.027. Na potrzeby prezentacji treści musi wykorzystywać arkusze stylów

CSS.



str. 140

wymagania - stat.gov.pl file · Web viewsprawa numer: 59/SISP/PN/2011. WYMAGANIA FUNKCJONALNE I...

Documents

Transcript of wymagania - stat.gov.pl file · Web viewsprawa numer: 59/SISP/PN/2011. WYMAGANIA FUNKCJONALNE I...