Załącznik nr 6- Funkcjonalność

Załącznik nr 6
Funkcjonalności
Symbol
wymagania
Wymagania ogólne dotyczące
aplikacji
Kategoria
wymagania
Oświadczenie
oferenta
(jest/będzie/
brak)
System Obiegu Dokumentów – Moduł Administratora
SEOD/ADM/01
MoŜliwość definiowania Rzeczowego
Wykazu Akt
Wymaganie
krytyczne
SEOD/ADM/02
MoŜliwość definiowania rodzajów pism
Wymaganie
krytyczne
SEOD/ADM/03
Definiowanie szablonów dokumentów dla
pism wychodzących. Funkcjonalność ta
powinna być realizowana w aplikacjach
Open Office Writer, Microsoft WORD.
Edytor powinien posiadać moŜliwość
wstawania grafik, niezbędnych do
wysyłania dokumentów na papierze
firmowym.
Wymaganie
krytyczne
SEOD/ADM/04
Łączenie rodzajów pism z rodzajami
spraw.
Wymaganie
krytyczne
SEOD/ADM/05
MoŜliwość definiowania teczek i podteczek
Wymaganie
krytyczne
SEOD/ADM/06
Zarządzanie strukturą organizacyjną
jednostki.
Wymaganie
krytyczne
SEOD/ADM/07
Obsługa wielu kancelarii, poprzez
odpowiednie przypisanie komórek do
kancelarii. MoŜliwość zdefiniowania
kancelarii głównej i kancelarii
pomocniczych oraz odpowiednie podpięcie
komórek, by wybrana korespondencja
przychodząca i wychodząca wpływała do
zdefiniowanych i przypisanych kancelarii,
Wymaganie
krytyczne
SEOD/ADM/08
Zarządzanie uŜytkownikami: tworzenie
uŜytkowników i przydzielanie do grup dla
których określane są uprawnienia,
nadawanie uprawnień do teczek i
rejestrów, przypisywanie ról
systemowych, definiowanie zastępstw,
przypisywanie uŜytkowników do komórek,
blokowanie i odblokowywanie
uŜytkowników,
Wymaganie
krytyczne
SEOD/ADM/09
Deaktywacja uŜytkowników z całego
systemu lub wybranej komórki.
Wymaganie
krytyczne
SEOD/ADM/10
MoŜliwość definiowania rejestrów
automatycznych i ręcznych.
Wymaganie
krytyczne
SEOD/ADM/11
Tworzenie szablonów kopert, pism
wychodzących.
Wymaganie
krytyczne
SEOD/ADM/12
Definiowanie szablonów znaków teczek,
spraw i pism.
Wymaganie
krytyczne
1
SEOD/ADM/13
MoŜliwość tworzenia statusów dla stanów
spraw.
Wymaganie
krytyczne
SEOD/ADM/14
Całościowe rejestrowanie zmian
wprowadzanych w strukturze
organizacyjnej, zmian uprawnień grup
uŜytkowników i zmian uprawnień
uŜytkowników.
Wymaganie
krytyczne
SEOD/ADM/15
MoŜliwość pielęgnowania słowników:
rodzajów, załączników, nadawców,
adresatów, ról osób, kategorii
archiwalnych, rodzajów przesyłek,
rodzajów listów, sposobów wysyłki,
przyczyn zwrotów przesyłki, rodzajów
nazw adresowych, miast, gmin,
województw, powiatów (integracja z
systemem TERYT), stanowisk.
Wymaganie
krytyczne
SEOD/ADM/16
Rozpoczęcie pracy w systemie w
dowolnym momencie w roku. MoŜliwość
ustawiania numeracji spraw, pism w
teczkach oraz numerów kancelaryjnych,
Wymaganie
krytyczne
SEOD/ADM/17
MoŜliwość blokowania i odblokowywania
całego systemu.
Wymaganie
krytyczne
SEOD/ADM/18
MoŜliwość zdefiniowania kont e-mail do
wymiany korespondencji drogą
elektroniczną.
Wymaganie
krytyczne
SEOD/ADM/19
MoŜliwość zmian organizacyjnych poprzez
przenoszenie pisma i spraw z jednego
uŜytkownika na innego oraz z jednej
komórki na drugą.
Wymaganie
krytyczne
SEOD/ADM/20
MoŜliwość definiowania zakresu dostępu
do dokumentów tajnych dla
poszczególnych uŜytkowników, określanie
poziomu dostępu do teczek.
Wymaganie
krytyczne
SEOD/ADM/21
MoŜliwość korzystania z definicji procesów
workflow i powiązanie definicji procesu z
teczką spraw albo rodzajem pisma.
Wymaganie
krytyczne
SEOD/ADM/22
MoŜliwość prowadzenia sprawy trybem
„ad hoc” - poprzez określanie na bieŜąco
kolejnych stanowisk zajmujących się
sprawą/pismem bez wykorzystywania
uprzednio zdefiniowanych procesów
workflow oraz umoŜliwienie zaniechania
na dowolnym etapie prowadzenia sprawy
zgodnie z definicją i kontynuowanie jej
trybem „ad hoc” z automatycznym
zamknięciem procesu workflow.
Wymaganie
krytyczne
SEOD/ADM/23
MoŜliwość eksportu i importu definicji
procesu do / z plików w formacie XML.
Wymaganie
krytyczne
SEOD/ADM/24
MoŜliwość skorzystania z graficznego
edytora definicji procesów,
umoŜliwiającego przeszkolonym
uŜytkownikom samodzielne tworzenie,
modyfikację i wizualizację definicji
procesów.
Wymaganie
krytyczne
MoŜliwość zastosowania zintegrowanego z
SEOD Instant Messengera do
2
powiadamiania uŜytkowników o pismach,
sprawach i dokumentach a takŜe
prowadzenia rozmów słuŜbowych
(pisemnych) z moŜliwością automatycznej
ich ewidencji w SEOD
System Obiegu Dokumentów – Kompleksowa Obsługa Korespondencji
SEOD/KOR/01
Rejestracja pism przychodzących,
wychodzących oraz pism wewnętrznych,
Wymaganie
krytyczne
SEOD/KOR/02
Rejestracja dokumentów w dowolnym
rejestrze na dowolnym stanowisku
zgodnie ze zdefiniowanymi
uprawnieniami,
Wymaganie
krytyczne
SEOD/KOR/03
Klasyfikacja korespondencji,
Wymaganie
krytyczne
SEOD/KOR/04
Wysyłanie dokumentów do wiadomości z
potwierdzeniem przyjęcia do wiadomości,
grupowanie dokumentów wchodzących w
skład korespondencji (dokument główny i
załączniki),
Wymaganie
krytyczne
SEOD/KOR/05
Rejestracja korespondencji w wielu
sprawach za pomocą referencji do pism,
Wymaganie
krytyczne
SEOD/KOR/06
Jednoczesna praca wielu komórek
organizacyjnych nad daną sprawą
zainicjowaną przez korespondencję,
Wymaganie
krytyczne
SEOD/KOR/07
Anulowanie korespondencji wychodzącej
Wymaganie
krytyczne
SEOD/KOR/08
Usuwanie korespondencji wychodzącej do
momentu nadania znaku pisma
Wymaganie
krytyczne
SEOD/KOR/09
Rejestracja e-maili przychodzących i
wychodzących oraz faxów.
Wymaganie
krytyczne
SEOD/KOR/10
Generowanie i wydruk potwierdzeń
dostarczenia korespondencji papierowej
do komórek organizacyjnych i
pracowników.
Wymaganie
krytyczne
SEOD/KOR/11
Obsługa (wysyłania i przyjmowania)
korespondencji za zwrotnym
potwierdzeniem odbioru
Wymaganie
krytyczne
SEOD/KOR/12
Automatyczna rejestracja historii
korespondencji.
Wymaganie
krytyczne
SEOD/KOR/13
Drukowanie potwierdzenia przyjęcia
pisma, przyniesionego osobiście przez
zainteresowanego do kancelarii lub
sekretariatu jednostki.
Wymaganie
krytyczne
SEOD/KOR/14
Drukowanie pieczęci wpływu
korespondencji za pomocą drukarki
etykiet samoprzylepnych z moŜliwością
cechowania pism kodem kreskowym.
Wymaganie
krytyczne
SEOD/KOR/15
Obsługa kodów kreskowych –
skojarzenia szablonów pism
przychodzących z kodem kreskowym na
formularzu papierowym.
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Obsługa spraw
SEOD/OSP/01
Rejestracja spraw z wykorzystywaniem
Wymaganie
3
Jednolitego Rzeczowego Wykazu Akt
oraz zgodna z Instrukcją Kancelaryjną
krytyczne
SEOD/OSP/02
KaŜda sprawa powinna otrzymać
automatycznie numer w spisie spraw,
teczkach, podteczkach
Wymaganie
krytyczne
SEOD/OSP/03
MoŜliwość tworzenia spraw na podstawie
pisma przychodzącego, wychodzącego,
notatki, dokumentu wewnętrznego, bez
pisma prowadzącego.
Wymaganie
krytyczne
SEOD/OSP/04
Dołączanie i odłączanie pism od sprawy
Wymaganie
krytyczne
SEOD/OSP/05
Łączenie dokumentów w sprawy i teczki
Wymaganie
krytyczne
SEOD/OSP/06
MoŜliwość zmiany dysponenta
realizującego sprawę,
Wymaganie
krytyczne
SEOD/OSP/07
Odnotowywanie kaŜdej zmiany stanu i w
ramach stanu - statusu sprawy
Wymaganie
krytyczne
SEOD/OSP/08
MoŜliwość wznowienia postępowania
sprawy
Wymaganie
krytyczne
SEOD/OSP/09
MoŜliwość dopisania komentarza do
sprawy
Wymaganie
krytyczne
SEOD/OSP/10
MoŜliwość zmiany terminu zakończenia
sprawy dla pracownika z odpowiednią
rolą w danej komórce. Dokonanie
zmiany terminu zakończenia
postępowania powinno być zapisywane
w systemie, zapamiętywana data
dokonania zmiany, zmieniający oraz
powód dokonania zmiany
Wymaganie
krytyczne
SEOD/OSP/11
Mechanizm informowania pracowników o
zbliŜającym się terminie załatwienia
sprawy. Sprawy przeterminowane
powinny być specjalnie w systemie
wyróŜniane.
Wymaganie
krytyczne
SEOD/OSP/12
Dostęp dla kierowników komórek
organizacyjnych do raportu spraw
przeterminowanych oraz innych
raportów, w tym równieŜ statystyk.
Wymaganie
krytyczne
SEOD/OSP/13
Monitorowanie przez przełoŜonych
prowadzonych spraw z kontrolą
terminów realizacji z sygnalizowaniem
opóźnień
Wymaganie
krytyczne
SEOD/OSP/14
Automatyczna rejestracja historii sprawy
Wymaganie
krytyczne
SEOD/OSP/15
Wydruk spisu spraw
Wymaganie
krytyczne
SEOD/OSP/16
Mechanizm trybu pracy „w zastępstwie”
polegający na moŜliwości obsługi
wszystkich dokumentów zastępowanego
pracownika
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Raporty i zestawienia
SEOD/RIZ/01
Pocztowa ksiąŜka nadawcza
Wymaganie
krytyczne
4
SEOD/RIZ/02
Raport dekretacji
Wymaganie
krytyczne
SEOD/RIZ/03
Raport z ksiąŜki doręczeń
Wymaganie
krytyczne
SEOD/RIZ/04
Raport pism przychodzących
Wymaganie
krytyczne
SEOD/RIZ/05
Raport pism przychodzących
przekazanych
Wymaganie
krytyczne
SEOD/RIZ/06
Raport pism wychodzących
Wymaganie
krytyczne
SEOD/RIZ/07
Raporty przeznaczone dla kierownika (w
tym statystyka, sprawy nieodebrane,
sprawy przeterminowane, sprawy w
toku, sprawy zakończone, pisma
nieodebrane i pisma odebrane)
Wymaganie
krytyczne
SEOD/RIZ/08
Rejestr zwrotów
Wymaganie
krytyczne
SEOD/RIZ/09
Spis spraw
Wymaganie
krytyczne
SEOD/RIZ/10
Program powinien mieć moŜliwość
exportu do formatu xls zawartości
wszystkich przeglądanych i
odfiltrowanych danych w postaci
tabelarycznej
Wymaganie
krytyczne
SEOD/RIZ/11
MoŜliwość tworzenia własnych raportów i
zestawień
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Podpis elektroniczny
SEOD/POE/01
MoŜliwość składania podpisów
elektronicznych (np. w celu podpisania
korespondencji wychodzącej)
Wymaganie
krytyczne
SEOD/POE/02
MoŜliwość weryfikacji podpisanych
dokumentów
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Wyszukiwanie
SEOD/WYS/01
Wyszukiwanie pełnotekstowe po treści
dokumentów (równieŜ zeskanowanych).
Wymaganie
krytyczne
SEOD/WYS/02
Wyszukiwanie po kodzie kreskowym.
Wymaganie
krytyczne
SEOD/WYS/03
MoŜliwość wyszukiwania pism, spraw i
dokumentów po atrybutach
zdefiniowanych przez uŜytkownika.
Wymaganie
krytyczne
SEOD/WYS/04
MoŜliwość zapisu kryteriów
wyszukiwania i korzystania z nich na
dalszym etapie prac.
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Współpraca z systemami
Zamawiającego
SEOD/INT/01
Wymiana informacji z systemami
zewnętrznymi za pośrednictwem
standardów opartych o język XML
Wymaganie
krytyczne
SEOD/INT/02
Integracja z portalem „Wrota Bogatyni”
w zakresie przekazywania informacji
dotyczących spraw klienta, etapu, na
którym znajduje się sprawa oraz
Wymaganie
krytyczne
5
dodatkowych informacji zapisanych w
systemie
SEOD/INT/03
Eksport do BIP informacji dotyczących
spraw klienta, etapu, na którym
znajduje się sprawa oraz dodatkowych
informacji zapisanych w systemie
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Ewidencja dokumentów
SEOD/EWID/01
Prowadzenie segregatorów z
dokumentami jednostki: uchwałami,
protokołami, zarządzeniami itp.
Wymaganie
krytyczne
SEOD/EWID/02
Definiowanie systemu numerowania
dokumentów w sposób odpowiadający
jednostce poprzez ustalenie maski
numeracji dokumentu.
Wymaganie
krytyczne
SEOD/EWID/03
MoŜliwość tworzenia systemu powiązań i
zaleŜności pomiędzy dokumentami
Wymaganie
krytyczne
SEOD/EWID/04
Klasyfikowanie dokumentów zgodnie z
Jednolitym Rzeczowym Wykazem Akt
zgodnym z instrukcją kancelaryjną
Wymaganie
krytyczne
SEOD/EWID/05
MoŜliwość nadzorowania dokumentów
przez kierownictwo jednostki – terminów
i statusów. MoŜliwość bezpośredniego
wglądu do treści kaŜdego dokumentu
zgodnie z posiadanymi uprawnieniami
Wymaganie
krytyczne
SEOD/EWID/06
Śledzenie historii dokumentu od chwili
zarejestrowania w systemie
Wymaganie
krytyczne
SEOD/EWID/07
MoŜliwość tworzenia własnych rejestrów
i definiowania w nich dodatkowych pól o
z góry określonym typie danych
(tekstowe, numeryczne, datowe,
słownikowe)
Wymaganie
krytyczne
SEOD/EWID/08
MoŜliwość prezentacji dokumentów wg
róŜnych definiowalnych kryteriów.
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Kontrola i bezpieczeństwo
SEOD/KIB/01
Logowanie do systemu na podstawie
identyfikatora i hasła
Wymaganie
krytyczne
SEOD/KIB/02
MoŜliwość wymuszania zmiany hasła co
30 dni, hasło posiada określone
wymagania co do złoŜoności
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Przechowywanie danych
SEOD/DAN/01
Sposób przechowywania i archiwizowania
danych zgodny z obowiązującymi
przepisami prawa
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Monitorowanie
SEOD/MON/01
Dostęp do listy spraw obsługiwanych
przez danego referenta
Wymaganie
krytyczne
SEOD/MON/02
MoŜliwość ustalenia indywidualnych
terminów załatwienia dla dokumentów i
spraw
Wymaganie
krytyczne
SEOD/MON/03
Określanie kategorii archiwizacji dla
poszczególnych typów spraw z JRWA
Wymaganie
krytyczne
System Elektronicznego Obiegu Dokumentów – Dodatkowe funkcjonalności
6
SEOD/DOD/01
Skalowalna architektura systemu,
moŜliwość pracy na darmowej bazie
danych i moŜliwość alternatywnego
podpięcia do komercyjnej bazy danych
zgodnej z ANSI SQL: np. Oracle
Wymaganie
krytyczne
SEOD/DOD/02
MoŜliwość przyznawania uprawnień do
teczek osobno dla opcji rejestracji
sprawy w danego RWA w konkretnej
komórce lub tylko do wyszukiwania w
teczce kaŜdej osobie w strukturze
organizacyjnej Urzędu
Wymaganie
krytyczne
SEOD/DOD/03
Automatyczne zapamiętywanie i
podpowiadanie tematu pisma i sprawy
Wymaganie
krytyczne
SEOD/DOD/04
MoŜliwość zdefiniowania dodatkowych
pól na piśmie lub sprawie: atrybuty
dodatkowe i wyszukiwania po nich
dokumentów
Wymaganie
krytyczne
SEOD/DOD/05
Wersjonowanie treści pisma
wychodzącego
Wymaganie
krytyczne
SEOD/DOD/06
MoŜliwość wybrania uŜytkownika ze
struktury organizacyjnej urzędu jako
adresata pisma (pisma wewnętrzne)
Wymaganie
krytyczne
SEOD/DOD/07
Mechanizm wspomagający masowe
nadawanie uprawnień. Przyznawanie
uprawnień do teczek, rejestrów, ról
systemowych dla wszystkich
pracowników wybranych komórek
Wymaganie
krytyczne
SEOD/DOD/08
MoŜliwość definiowania własnych
sposobów wysyłki pism wychodzących
(w tym równieŜ ZPO)
Wymaganie
krytyczne
SEOD/DOD/09
MoŜliwość wywoływania wszystkich
funkcjonalności z menu kontekstowego i
głównego w zaleŜności od potrzeb
uŜytkownika
Wymaganie
krytyczne
SEOD/DOD/10
Odrębna funkcjonalność szybkiej
rejestracji pism przychodzących
Wymaganie
krytyczne
SEOD/DOD/11
Centralna baza danych korespondentów.
Przechowywanie historycznych danych
teleadresowych korespondenta w kaŜdej
sprawie (przydatne w przypadku zmiany
danych osobowych).
Wymaganie
krytyczne
SEOD/DOD/12
Skanowanie załączników powinno
odbywać się z wewnątrz programu z
zastosowaniem protokołu TWAIN.
UŜytkownik powinien móc określić
poziom kompresji, rozdzielczość, format
zapisu (np. tif, jpg), a takŜe kolor
(czarno-białe czy kolorowe). Wielkość
skanowanego druku strony A4 nie
powinna przekraczać 350 kb przy
zachowaniu dobrej widoczności.
UŜytkownik powinien mieć moŜliwość
zastosowania technologii OCR w celu
zaimportowania do systemu treści
skanowanego dokumentu.
Wymaganie
krytyczne
SEOD/DOD/13
MoŜliwość przeglądania zalogowanych
Wymaganie
7
uŜytkowników
krytyczne
SEOD/DOD/14
Przejrzyste przyznawanie np. ról
systemowych, moŜliwość przyznania
uŜytkownikowi kilku ról w róŜnych
komórkach (ma to poprawić szybkości
prac administracyjnych)
Wymaganie
krytyczne
SEOD/DOD/15
MoŜliwość zaznaczania pism jako
załatwionych, bez konieczności
tworzenia spraw
Wymaganie
krytyczne
SEOD/DOD/16
MoŜliwość automatycznej
(niewymagającej wykonywania Ŝadnych
akcji dla uŜytkownika końcowego)
aktualizacji kolejnych wersji
oprogramowania na wszystkich stacjach
roboczych
Wymaganie
krytyczne
SEOD/DOD/17
Tryb pracy „w zastępstwie” polegający
na moŜliwości obsługi wszystkich
dokumentów zastępowanego
pracownika. Wszystkie zmiany mają być
rejestrowane. MoŜliwość przeglądania
rejestru operacji wykonywanych „w
zastępstwie” innego pracownika,
Wymaganie
krytyczne
SEOD/DOD/18
MoŜliwość przekazywania spraw do
archiwum,
Wymaganie
krytyczne
SEOD/DOD/19
MoŜliwość wypoŜyczenia akt sprawy z
archiwum,
Wymaganie
krytyczne
SEOD/DOD/20
MoŜliwość definiowania spisów zdawczoodbiorczych,
Wymaganie
krytyczne
SEOD/DOD/21
UŜytkownik z rolą repozytor ma być
odpowiedzialny za spisy zdawczoodbiorcze, dodawanie spraw do spisów,
zamykanie spisów oraz przekazywanie
zamkniętych spisów do Archiwum,
Wymaganie
krytyczne
SEOD/DOD/22
UŜytkownik z rolą archiwista ma mieć
moŜliwość obsługi funkcji związanych z
Archiwum oraz funkcji realizowanych w
ramach Komponentu Archiwum
dokumentów elektronicznych
Wymaganie
krytyczne
SEOD/DOD/23
Przechowywanie dokumentów
zeskanowanych i plików będących
załącznikami korespondencji poza bazą
danych pod zmienioną nazwą
uniemoŜliwiającą zidentyfikowanie
dokumentu źródłowego.
Wymaganie
krytyczne
SEOD/DOD/24
MoŜliwość generowania pism
wychodzących. Program powinien
automatycznie zamieniać zdefiniowane
znaczniki (kod kreskowy, znak pisma,
data pisma, nazwa rodzaju pisma, osoba
kontaktowa za strony urzędu, dane
adresata, sekcja do wiadomości) na
konkretne wartości danego pisma. W
przypadku, gdy adresujemy pismo do
kilku uŜytkowników jednocześnie,
program powinien mieć moŜliwość
automatycznego adresowania treści
pisma bezpośrednio do kaŜdego z
Wymaganie
krytyczne
8
adresatów z osobna, pozostałych
zapisując w sekcji do wiadomości,
SEOD/DOD/25
MoŜliwość przyporządkowywania
sprawom i pismom stopni tajności oraz
uŜytkownikom prawa do nadawania
stopni tajności na poziomie teczki
(uprawnienia do teczek, wyszukiwanie).
Wymaganie
krytyczne
SEOD/DOD/26
Powiadamianie uŜytkowników za pomocą
wyskakujących komunikatów o nowych
pismach, dokumentach, dokumentach i
pismach do akceptacji itp.
Wymaganie
krytyczne
SEOD/DOD/27
MoŜliwość zdefiniowania dowolnych
zasobów (np. sale, samochody,
projektor itp.) i kalendarza rezerwacji
zasobów oraz zarządzanie zasobami.
Wymaganie
krytyczne
„Wrota Bogatyni” – Wymagania ogólne
EFESP/OGL/01
Oprogramowanie aplikacyjne ma
umoŜliwiać obsługę komunikacji z
Klientami w zakresie świadczenia przez
Zamawiającego usług publicznych drogą
elektroniczną oraz obsługę komunikacji
ze sobą poszczególnych komponentów.
Wymaganie
krytyczne
EFESP/OGL/02
Oprogramowanie musi umoŜliwiać
obsługę klientów typu osoby fizyczne,
osoby prawne.
Wymaganie
krytyczne
EFESP/OGL/03
Elektroniczna Skrzynka Podawcza
obsługiwana jest z wykorzystaniem
przeglądarki internetowej. Elektroniczne
Formularze obsługiwane są za pomocą
przeglądarki internetowej lub innej
darmowej aplikacji.
Wymaganie
krytyczne
EFESP/OGL/04
Oprogramowanie musi zawierać
automatyczny mechanizm
bezpieczeństwa:
Blokowanie konta uŜytkownika
po określonej liczbie nieudanych
próbach zalogowania,
MoŜliwość wymuszania zmiany
hasła po określonej liczbie dni,
Hasło posiada określone
wymagania, co do złoŜoności.
Wymaganie
krytyczne
EFESP/OGL/05
Oprogramowanie aplikacyjne musi
umoŜliwiać komunikację z Interesantem
przy uŜyciu połączenia szyfrowanego
(SSL) 128 bitowym certyfikatem.
Certyfikat musi zostać wygenerowany
przez zaufane Centrum Autoryzacji.
Wymaganie
krytyczne
EFESP/OGL/06
Oprogramowanie aplikacyjne musi
umoŜliwiać Interesantom dostęp do eusług publicznych on-line. Interesant
będzie logował się do swojej skrzynki
kontaktowej, aby uzyskać informacje o
sprawie, złoŜyć pismo.
Wymaganie
krytyczne
EFESP/OGL/07
Oprogramowanie aplikacyjne musi
generować Urzędowe Poświadczenie
Odbioru.
Wymaganie
krytyczne
9
EFESP/OGL/08
Oprogramowanie aplikacyjne musi być
zgodne z następującymi aktami
prawnymi:
Ustawa z dnia 17 lutego 2005 r.
o informatyzacji działalności
podmiotów realizujących zadania
publiczne (Dz. U. Nr 64, poz.
565),
Ustawa z dnia 18 lipca 2002 r. o
świadczeniu usług drogą
elektroniczną (Dz. U. z dnia 9
września 2002 r.),
Rozporządzenie Prezesa Rady
Ministrów z dnia 29 września
2005 r. w sprawie warunków
organizacyjno–technicznych
doręczania dokumentów
elektronicznych podmiotom
publicznym (Dz. U. z dnia 13
października 2005 r.),
Rozporządzenie Prezesa Rady
Ministrów z dnia 11 października
2005 r. w sprawie minimalnych
wymagań dla systemów
teleinformatycznych (Dz. U. z
dnia 28 października 2005 r.),
Ustawa z dnia 18 września 2001
r. o podpisie elektronicznym
(Dz.U. z 2001 r. Nr 130, poz.
1450).
Wymaganie
krytyczne
EFESP/OGL/09
Oprogramowanie aplikacyjne eUrząd
musi być zbudowana z następujących
części (obszarów funkcjonalnych):
Moduł Usług Publicznych,
Moduł Integracyjny,
Moduł Repozytorium Formularzy
Elektronicznych,
Wymaganie
krytyczne
EFESP/OGL/10
Oprogramowanie ma działać jako system
centralny w architekturze
trójwarstwowej z wydzieloną logiką
warstwy aplikacji, bazą danych oraz
aplikacjami uŜytkowników.
Wymaganie
krytyczne
EFESP/OGL/11
Oprogramowanie ma działać w oparciu o
relacyjną bazę danych. Komunikacja
pomiędzy bazą danych a serwerem
aplikacyjnym powinna odbywać się przy
uŜyciu standardowych metod dostępu
poprzez ODBC lub JDBC.
Wymaganie
krytyczne
„Wrota Bogatyni” – Moduł Usług Publicznych
EFESP/MUP/01
Moduł Usług Publicznych będzie
umoŜliwiał Klientom urzędu dostęp do eusług publicznych on-line. Klient będzie
logował się do swojej skrzynki
kontaktowej, aby uzyskać informacje o
sprawie, złoŜyć wniosek oraz odebrać
urzędowe potwierdzenie odbioru.
Wymaganie
krytyczne
EFESP/MUP/02
Warunkiem wysyłania do klienta przez
urząd skierowanych do niego informacji
dotyczących złoŜonych wniosków spraw
będzie potwierdzenie toŜsamości klienta
Wymaganie
krytyczne
10
podpisem elektronicznym bądź osobiście
w urzędzie.
EFESP/MUP/03
Moduł Usług Publicznych będzie
odpowiedzialny za dwukierunkową
elektroniczną komunikację Interesantów
z Urzędami uczestniczącymi w sprawie.
Wymaganie
krytyczne
EFESP/MUP/04
Moduł Usług Publicznych będzie
publicznie dostępnym portalem
internetowym, niewymagającym
logowania. Będzie tam znajdowała się
m.in. informacja o świadczonych
elektronicznie usługach oraz będzie
moŜliwość załoŜenia skrzynki
kontaktowej.
Wymaganie
krytyczne
EFESP/MUP/05
Komunikacja dwukierunkowa będzie
odbywać się poprzez skrzynkę
kontaktową, która będzie
spersonalizowanym, wymagającym
uwierzytelniania, interfejsem dostępu
interesanta do usług publicznych przez
przeglądarkę WWW.
Wymaganie
krytyczne
EFESP/MUP/06
Po zalogowaniu się do skrzynki
identyfikatorem i hasłem Klient Urzędu
będzie miał dostęp do następujących
funkcjonalności - będzie mógł:
1. Wypełnić dowolny spośród
udostępnionych w Platformie
e-Usług Publicznych eformularzy, dołączyć
załączniki i wysłać go do
urzędu, otrzymując w
odpowiedzi elektroniczne
potwierdzenie odbioru,
2. Podpisać wysyłane
dokumenty podpisem
elektronicznym
weryfikowanym przez
certyfikat kwalifikowany,
3. Przerwać swoje działania
zachowując częściowo
wypełniony danymi
formularz do edycji, którego
moŜe powrócić później,
4. Zarządzać ustawieniami
skrzynki - zmienić hasło,
wprowadzić lub zmienić dane
osobowe, które będą
automatycznie wypełniać
odpowiednie pola składanych
formularzy oraz podać adres
poczty elektronicznej (email),
5. Uzyskać informacje o
zdarzeniach, które zaszły w
związku z jego wnioskami
złoŜonymi w urzędach,
6. Zamówić automatyczne
powiadomienia na podany
przez siebie adres e-mail o
zmianach statusów spraw,
7. Odebrać Urzędowe
Wymaganie
krytyczne
11
Poświadczenie Odbioru,
EFESP/MUP/07
Klient Urzędu będzie miał ponadto
moŜliwość odbioru decyzji
administracyjnej wydanej drogą
elektroniczną i zapisu jej w celu dalszego
wykorzystania.
Wymaganie
krytyczne
EFESP/MUP/08
Skrzynka kontaktowa załoŜona przez
klienta on-line zostaje automatycznie
skasowana po określonym czasie
(konfigurowalnym przez administratora),
jeŜeli w tym czasie nie zostanie przez
urząd potwierdzona toŜsamość
właściciela skrzynki.
Wymaganie
krytyczne
EFESP/MUP/09
Aplikacja powinna umoŜliwić
automatyczne powiadomienia za pomocą
SMS na podany przez siebie nr telefonu
komórkowego o zmianach statusów
spraw.
Wymaganie
krytyczne
„Wrota Bogatyni” – Moduł Repozytorium Formularzy Elektronicznych
EFESP/RFE/01
W celu ujednolicenia przyjmowanych
elektronicznych wniosków, przewiduje
się stworzenie w repozytorium eformularzy dla określonych kategorii
spraw załatwianych przez urzędy.
Formularze te będą wypełniane przez
Interesantów on-line w Module Usług
Publicznych.
Wymaganie
krytyczne
EFESP/RFE/02
Moduł Repozytorium Formularzy
Elektronicznych ma umoŜliwiać
tworzenie, przechowywanie i
wyświetlanie e-formularzy,
przeznaczonych dla klientów urzędu.
Wymaganie
krytyczne
EFESP/RFE/03
Moduł Repozytorium Formularzy
Elektronicznych musi umoŜliwiać
składanie się e-Formularzy z gotowych
struktur informacyjnych (tzw.
„metadanych”), słuŜących do opisu i
walidacji określonego typu informacji
takich jak adres, kod pocztowy, NIP,
data, załącznik, formularz.
Wymaganie
krytyczne
EFESP/RFE/04
Moduł Repozytorium Formularzy
Elektronicznych musi umoŜliwiać
tworzenie i modyfikowanie e-formularzy
przez uprawnionego administratora.
Tworzenie i zarządzenie e-formularzami
jest moŜliwe w ramach Modułu
Repozytorium Formularzy
Elektronicznych.
Wymaganie
krytyczne
EFESP/RFE/05
Moduł Repozytorium Formularzy
Elektronicznych musi umoŜliwiać
wersjonowanie e-formularzy.
Wymaganie
krytyczne
EFESP/RFE/06
Edytor e-formularzy musi realizować:
Tworzenie e-formularzy,
Tworzenie e-formularzy
umoŜliwiających klientowi
dodanie załączników, z
moŜliwością ograniczania ich
Wymaganie
krytyczne
12
ilości i wielkości,
Definiowanie słowników i
dodawanie do e-formularzy pól
korzystających z tych słowników,
Zamieszczanie dowolnych
elementów tekstowych i
graficznych w ramach eformularza,
Definiowanie reguł wyświetlania
oraz reguł walidacji w ramach eformularza,
Zapis tworzonych e-formularzy
w wersji roboczej,
podgląd, wypełnianie treścią i
walidację e-formularza w celach
testowych,
Wykorzystanie raz
wprowadzonych treści (reguły
wyświetlania, teksty, eformularze itp.) do tworzenia
nowych e-formularzy.
„Wrota Bogatyni” – Moduł integracyjny
EFESP/INT/01
Moduł Integracyjny ma realizować
funkcje obsługi komunikacji pomiędzy
poszczególnymi komponentami.
Wymaganie
krytyczne
EFESP/INT/02
Moduł Integracyjny ma umoŜliwiać
funkcje obsługi komunikacji pomiędzy
elektronicznymi formularzami i
systemem elektronicznego obiegu
dokumentów.
Wymaganie
krytyczne
EFESP/INT/03
Moduł Integracyjny będzie obsługiwał
komunikację pomiędzy poszczególnymi
elementami systemu poprzez usługi Web
Services.
Wymaganie
krytyczne
EFESP/INT/04
Moduł Integracyjny będzie zapewniał
potwierdzenie wykonania wszystkich
operacji dokonywanych za pomocą Web
Services oraz będzie zwracał komunikaty
o stanie wykonania (powodzenie lub
niepowodzenie z opisem przyczyny
błędu).
Wymaganie
krytyczne
Portal Informacyjny – Część publiczna
PORT/PUB/01
Przygotowanie portalu w 4 wersjach
językowych: polska, niemiecka,
angielska i czeska
Wymaganie
krytyczne
PORT/PUB/02
Poprawne działanie w portalu (serwis
publiczny oraz system CMS) w
przeglądarkach Internet Explorer 6.0 i
wyŜszych, opera 9.0 i wyŜszych, Mozilla
1.0 i wyŜszych oraz FireFox 2.0 i
wyŜszych
Wymaganie
krytyczne
PORT/PUB/03
Portal powinien zawierać wymagane
formularze kontaktowe zabezpieczone
przed spamem poprzez mechanizm
captcha
Wymaganie
krytyczne
PORT/PUB/04
Adresy e-mail internetowe udostępnione
poprzez system CMS zabezpieczone
Wymaganie
krytyczne
13
przed harvestingiem
PORT/PUB/05
Portal powinien posiadać moŜliwość
wyświetlenia informacji archiwalnych
Wymaganie
krytyczne
PORT/PUB/06
Mechanizm obsługi archiwum informacji
powinien posiadać podział na lata i
miesiące
Wymaganie
krytyczne
PORT/PUB/07
Mechanizm obsługi archiwum informacji
powinien posiadać wyszukiwarkę treści
archiwalnych
Wymaganie
krytyczne
PORT/PUB/08
Portal powinien posiadać mapę serwisu
automatycznie budowaną na postawie
struktury menu
Wymaganie
krytyczne
PORT/PUB/09
Formularz internetowy powinien być
zabezpieczony przed spamem
Wymaganie
krytyczne
PORT/PUB/10
MoŜliwość wydruku pojedynczej
informacji
Wymaganie
krytyczne
Portal Informacyjny – system CMS
PORT/CMS/01
Poprawne działanie w portalu (serwis
publiczny oraz system CMS) w
przeglądarkach Internet Explorer 6.0 i
wyŜszych, opera 9.0 i wyŜszych, Mozilla
1.0 i wyŜszych oraz FireFox 2.0 i
wyŜszych
Wymaganie
krytyczne
PORT/CMS/02
System CMS musi umoŜliwiać
zdefiniowanie elementów
wspomagających pozycjonowanie w
wyszukiwarkach w zakresie:
definiowanie tytułu w oknie
przeglądarki dla kaŜdej pozycji
menu
definiowanie słów kluczowych
dla kaŜdej pozycji menu
definiowanie słów kluczowych
dla kaŜdej informacji
Wymaganie
krytyczne
PORT/CMS/03
System CMS musi działać z
wykorzystaniem protokołu HTTPS
Wymaganie
krytyczne
PORT/CMS/04
System CMS musi posiadać dodatkowe
mechanizmy zabezpieczające przed
nieautoryzowanym dostępem do
danych:
Automatyczne blokowanie
uŜytkownika po określonej
liczbie nieudanych prób
logowania
Automatyczne wymuszenie
zmiany hasła dostępowego
uŜytkownika co określoną liczbę
dni
Wymaganie
krytyczne
PORT/CMS/05
System CMS musi umoŜliwiać dodawanie
nowych grup uŜytkowników
Wymaganie
krytyczne
PORT/CMS/06
System CMS musi umoŜliwiać dodawanie
nowych uŜytkowników oraz
przyporządkowanie ich do grup
uŜytkowników
Wymaganie
krytyczne
PORT/CMS/07
System CMS musi umoŜliwiać określenie
Wymaganie
14
uprawnień dla grup uŜytkowników na
poziomie
Dostępu grupy uŜytkowników do
modułu funkcjonalnego
Dostępu grupy do pojedynczego
wpisu w module funkcjonalnym
Dostępu do wykonywanych
operacji w module
funkcjonalnym
krytyczne
PORT/CMS/09
System CMS musi posiadać dziennik
zmian automatycznie rejestrujący
działania uŜytkowników w systemie
administracyjnym
Wymaganie
krytyczne
PORT/CMS/10
System CMS musi posiadać dziennik
logowań automatycznie rejestrujący
próby logowania uŜytkowników
Wymaganie
krytyczne
PORT/CMS/11
System CMS musi umoŜliwiać dodawanie
załączników w postaci plików do
pobrania
Wymaganie
krytyczne
PORT/CMS/12
System CMS musi posiadać mechanizm
automatycznego przyporządkowania
ikony graficznej na podstawie
rozszerzenia pliku
Wymaganie
dodatkowe
PORT/CMS/13
System CMS musi posiadać alternatywne
rozwiązanie uploadu plików na serwer z
wykorzystaniem protokołu FTP
(wykorzystanie tego rozwiązania dotyczy
głównie jednorazowego wczytywania
duŜej ilości plików lub plików o duŜej
objętości np. galerie zdjęć)
Wymaganie
krytyczne
PORT/CMS/14
System CMS musi umoŜliwiać publikację
informacji wyłącznie przez uŜytkowników
posiadających odpowiednie uprawnienia
Wymaganie
krytyczne
PORT/CMS/15
System CMS musi posiadać mechanizm
podglądu informacji przed jej
upublicznieniem w układzie graficznym
publicznej strony portalu
Wymaganie
krytyczne
PORT/CMS/16
System CMS musi umoŜliwiać tworzenie
struktury menu przez uŜytkowników
uprawnionych
Wymaganie
krytyczne
PORT/CMS/17
System CMS musi umoŜliwiać tworzenie
struktury co najmniej do 3 poziomów
zagłębienia
Wymaganie
krytyczne
PORT/CMS/18
System CMS musi umoŜliwiać tworzenie
struktury menu indywidualnie dla kaŜdej
z wersji językowych
Wymaganie
krytyczne
PORT/CMS/19
System CMS musi umoŜliwiać
dodawanie, edycję, usunięcie pozycji
menu na kaŜdym z poziomów
zagłębienia
Wymaganie
krytyczne
PORT/CMS/20
System CMS musi umoŜliwiać
definiowanie nowych informacji przez
uŜytkowników uprawnionych
Wymaganie
krytyczne
PORT/CMS/21
System CMS musi umoŜliwiać
definiowanie informacji wyświetlonych w
widoku pełnej treści oraz w formie
Wymaganie
krytyczne
15
skrótu i rozwinięcia (zajawka + czytaj
więcej)
PORT/CMS/22
System CMS musi umoŜliwiać
przyporządkowanie dowolnej ilości
załączników do pobrania do kaŜdej
informacji
Wymaganie
krytyczne
PORT/CMS/23
System CMS musi umoŜliwiać określenie
przedziału czasowego wyświetlania
informacji – system posiada wbudowany
mechanizm, który umoŜliwia
automatyczną publikację informacji w
portalu oraz zakończenie publikacji
informacji w portal wg podanych dat
Wymaganie
krytyczne
PORT/CMS/24
System CMS musi posiadać moŜliwość
zmiany statusu informacji na informację
archiwalną w dwóch formach:
Na podstawie daty przejścia do
archiwum zdefiniowanej przez
operatora systemu CMS
Na podstawie statusu
„archiwum” zdefiniowanego
przez operatora systemu CMS
Wymaganie
krytyczne
PORT/CMS/25
System CMS musi posiadać wbudowany
edytor tekstu WYSIWYG umoŜliwiający
podstawowe formatowanie tekstu
(pogrubienie, pochylenie, podkreślenie,
kolor czcionki, wstawianie tabel,
wstawianie zdjęć, kopiowanie z WORD
bez przeniesienia formatowania,
wstawianie linków internetowych, itp.)
Wymaganie
krytyczne
PORT/CMS/26
System CMS posiada wbudowany moduł
definiowania galerii zdjęć. Moduł galerii
zdjęć musi umoŜliwiać tworzenie galerii
zdjęć w formie:
dodawania pojedynczych plików
zdjęć do galerii
automatycznego budowania
galerii zdjęć na podstawie zbioru
plików (kategorii) zdjęć
dostępnych w menadŜerze
plików systemu CMS
automatycznego budowania
galerii zdjęć na podstawie
wydzielonego katalogu „galeria
zdjęć” na serwerze
wczytywania zdjęć do galerii lub
menadŜera plików z
wykorzystaniem FTP
Wymaganie
krytyczne
PORT/CMS/27
System CMS musi umoŜliwiać
skojarzenie jednej lub kilku galerii zdjęć
z informacją np. relacja ze spotkania
Wizyta Ambasadora Królestwa
Niderlandów
Wymaganie
krytyczne
PORT/CMS/28
System CMS powinien posiadać
mechanizm zarządzania banerami
graficznymi, jako zarządzanie rozumiane
jest:
moŜliwość wyboru miejsca
wyświetlenia banera w portalu
Wymaganie
krytyczne
16
na podstawie przygotowanego
projektu graficznego
moŜliwość określenia czasu
wyświetlania banera w portalu
(od-do)
moŜliwość ponownego włączenia
banera nieaktywnego
poprawną obsługę banerów w
formacie: jpg, png, gif, gif
animowany, flash
moŜliwość wyświetlania kilku
banerów jednocześnie
PORT/CMS/29
Portal powinien posiadać moduł
statystyk umoŜliwiający zapoznanie się z
odwiedzinami strony w zakresie (ilości
wejść, czasu wejścia, lokalizacji
uŜytkowników, przeglądarek,
rozdzielczości itp. – zakres będący
ogólnie przyjętym standardem dla
systemów monitorowania statystyk
odwiedzin stron)
Wymaganie
krytyczne
PORT/CMS/30
System CMS musi umoŜliwiać monitoring
odwiedzin strony dla kaŜdej z pozycji
menu indywidualnie
Wymaganie
krytyczne
PORT/CMS/31
System CMS musi być zintegrowany z
systemem statystyk w zakresie
umoŜliwiającym zdefiniowanie
mechanizmu zliczania nowo dodanej
pozycji w menu bez konieczności
wstawiania skryptów zliczających
poprzez kod strony. System statystyk
moŜe być rozwiązaniem zewnętrznym
Wymaganie
krytyczne
Publiczne Punkty Dostępu do Informacji
PPDI/01
MoŜliwość zaprogramowania ustawień
kiosku przy starcie (rozdzielczość
ekranu, liczba kolorów, wstępna
głośność) oraz restarcie.
Wymaganie
krytyczne
PPDI/02
Zabezpieczenie dostępu do ustawień i
konfiguracji hasłem.
Wymaganie
krytyczne
PPDI/03
MoŜliwość automatycznego
wyłączania/restartu komputera o
określonej godzinie.
Wymaganie
krytyczne
PPDI/04
Wyświetlenie menu umoŜliwiającego
uŜytkownikowi wybór
zaprogramowanych funkcji kiosku
multimedialnego, jak równieŜ
wyświetlenie i przywołanie tego menu w
dowolnym momencie funkcjonowania z
moŜliwością modyfikacji wyglądu menu.
Wymaganie
krytyczne
PPDI/05
MoŜliwość zablokowania klawiszy
krytycznych dla pracy systemu takich
jak: CTRL+ ALT+DEL, Windows-Logo,
ALT+TAB,Shift+F10, CTRL+ESC,
ALT+ESC.
Wymaganie
krytyczne
PPDI/06
Monitorowanie systemu operacyjnego
(tzw. Software WatchDog), które
kontroluje zajętość pamięci oraz innych
Wymaganie
krytyczne
17
krytycznych elementów systemu i
dokonuje jego reinicjalizacji w sytuacji
zagraŜającej zablokowaniem
oprogramowania.
PPDI/07
Kontrolowanie systemu okien w celu
zablokowania okien określonego typu lub
zamknięcia określonych okien, które
znalazły się w tle.
Wymaganie
krytyczne
PPDI/08
Współpraca z przeglądarką WWW
Wymaganie
krytyczne
PPDI/09
MoŜliwość wymuszenia wyświetlenia
wybranej strony WWW w przeglądarce
poprzez wybranie pozycji menu, ew.
przycisku funkcyjnego na klawiaturze,
jak równieŜ przy starcie/restarcie kiosku
multimedialnego.
Wymaganie
krytyczne
PPDI/10
MoŜliwość blokowania dostępu do stron
WWW dostępnych poprzez sieć i
ograniczenia dostępu wyłącznie do
określonych lokalnych dokumentów.
Wymaganie
krytyczne
PPDI/11
Definiowanie ustawień wpływających na
bezpieczeństwo pracy kiosku
(ograniczanie dostępu do róŜnych
rodzajów zasobów: filmy, skrypty.
Wymaganie
krytyczne
PPDI/12
Definiowanie stron WWW i adresów
dostępnych oraz zablokowanych do
przeglądania.
Wymaganie
krytyczne
PPDI/13
Definiowanie programów dostępnych do
uruchomienia przez uŜytkownika kiosku
Wymaganie
krytyczne
PPDI/14
Automatyczne zamykanie otwartych
okien i programów w wypadku braku
reakcji uŜytkownika przez
zaprogramowany czas z moŜliwością
uruchomienia pokazu slajdów zamiast
wygaszacza ekranu.
Wymaganie
krytyczne
PPDI/15
Klient poczty pop3/imap do przeglądania
on-line podanej przez uŜytkownika
skrzynki pocztowej (z wykluczeniem
moŜliwości trwałego zapisywania
zawartości skrzynki – treści poczty i
załączników oraz uruchamiania jako
programów załączników i ich treści.
Wymaganie
krytyczne
18