zał nr 9 do projektu umowy

Transkrypt

zał nr 9 do projektu umowy
1.
Wymagania techniczne/dodatkowe:
1.1.
System musi
być zgodny z obowiązującymi
oraz tymi
przepisami
prawa
powszechnego, których termin wejścia w życie został już określony, a także
przepisami
prawa
miejscowego
(uchwałami
Rady
Miasta
Wrocławia)
oraz
Decyzjami i Zarządzeniami Prezydenta Miasta Wrocławia dotyczącymi realizacji
zadań z zakresu windykacji należności Gminy Wrocław oraz Skarbu Państwa.
1.2.
System musi pozwalać na jednoczesny dostęp do Bazy wielu użytkownikom
(minimum 60).
1.3.
System musi zapewniać ochronę Bazy przed utratą spójności lub zniszczeniem.
1.4.
System musi zapewniać ciągły dostęp do Bazy i działać w trybie on-line.
1.5.
System musi działać na maszynach wirtualnych.
1.6.
System winien wykorzystywać do stałego lub okresowego eksportu bądź importu
danych standard XML
1.7.
System powinien być zintegrowany z ESB (Enterprise Service Bus), systemem
KSAT 2000i w zakresie danych z systemu GNK (webservice), EZD w zakresie
obiegu dokumentów (webservice) oraz współpracować z platformą PLIP.
1.8.
System powinien posiadać moduł dla Administratora systemu, umożliwiający
zarządzanie operatorami, nadawanie uprawnień (do edycji, , do dodawania pozycji
poszczególnych słowników). Zamawiający nie dopuszcza, aby użytkownicy musieli
pracować na kontach z uprawnieniami administratora Systemu. Administrator ma
mieć
możliwość
częstotliwości
konfiguracji
jego
zmiany.
mechanizmów
Zamawiający
kontroli
wymaga,
złożoności
aby
wszelkie
hasła
i
działania
administracyjne były możliwe do przeprowadzenia we własnym zakresie – przez
administratorów
Systemu
lub
użytkowników,
którym
nadano
odpowiednie
uprawnienia – bez pośrednictwa Wykonawcy. Wykonawca może zaproponować
inny podział uprawnień, jednakże musi on być funkcjonalnie równoważny.
Powyższy
wymóg
dotyczy
wszelkich
działań,
zarówno
podstawowych
(np.
założenie użytkownika, nadanie mu uprawnień) jak zaawansowanych (np.
edytowanie / dodanie szablonu dokumentu / raportu, modyfikacja),
1.9.
System powinien mieć półotwartą strukturę programu (możliwość dokonywania
modyfikacji przez zamawiającego)
1.10.
Każdy użytkownik Systemu musi mieć własny login i hasło. Do każdego konta
użytkownika mają być przypisane następujące informacje:
•
Login.
•
Imię, nazwisko.
•
Rodzaj konta (użytkownik Zamawiającego, pracownik firmy).
•
Instytucja / Firma (dot. Firm; powiązanie z rejestrem firm).
•
Daty od / do obowiązywania konta.
•
1.11.
Uprawnienia do funkcji (role).
Każdy
użytkownik
Systemu
z
UMW
powinien
mieć
konto
użytkownika
zintegrowane z Active Directory.
1.12.
System musi działać w środowisku zintegrowanych baz danych posiadającym
następujące cechy: relacyjność i transakcyjność oraz komunikacja z aplikacjami w
standardzie SQL.
1.13.
System musi posiadać „Pomoc” kontekstową oraz interfejs w języku polskim.
1.14.
Struktura danych musi cechować się brakiem redundancji danych za wyjątkiem
sytuacji gdzie wymagania wydajności systemu uzasadniają odstąpienie od tej
zasady. W takich wypadkach wszelkie replikacje danych muszą odbywać się w
trybie on-line w pełni transakcyjnie. Zamawiający oczekuje, iż odpowiedź Systemu
na proste zapytanie zadane równocześnie przez 50 użytkowników nie będzie
trwała dłużej niż 2 sekundy. Realizacja ograniczeń wartości lub powiązań
pomiędzy danymi musi odbywać się z wykorzystaniem tej samej procedury lub
funkcji. Ma to na celu ograniczenie ilości procedur i funkcji w bazie danych.
1.15.
System musi wykorzystywać zesłownikowane wartości oraz atrybuty a także
uwzględniać
możliwość
automatycznego
słownikowania
często
stosowanych
informacji i pojęć.
1.16.
Polecenia dotyczące typowych funkcji Systemu (np. drukowanie, generowanie
raportów, monitorowanie, alerty) muszą być realizowane w sposób ujednolicony
dla całego systemu i wszystkich użytkowników.
1.17.
System musi umożliwiać generowanie raportów w postaci plików co najmniej w
formatach: DOC, PDF, RTF, CSV, XLS. dowolnych raportów z możliwością
sortowania,
filtrowania,
wyszukiwania
i
grupowania
wyników
raportów
po
dowolnych polach wchodzących w skład raportu z wbudowanym mechanizmem
grill down.
1.18.
Dodatkowym atutem systemu będzie rozbudowany o system analityczny ( dane
do raportów mogą być pozyskiwane z różnych źródeł, nie tylko z systemu
dziedzinowego)
1.19.
System musi zostać wyposażony w system alertów istotnych zdarzeń z punktu
widzenia Zamawiającego, o następujących własnościach:
•
System musi umożliwiać ustalanie przez każdego użytkownika, niezależnie
od modułu, alertów zdefiniowanych na dzień tygodnia, dzień miesiąca, dzień
roku oraz datę w określonej porze (godzinie i minucie) z opisem zadania do
wykonania przez użytkownika,
•
System
musi
umożliwiać
śledzenie
uruchamiania
odczytania oraz zaakceptowania przez użytkownika,
się
alertów
i
jego
•
system
alertów
musi
umożliwiać
wprowadzanie
alertów
dla
grup
użytkowników.
•
ustalenie alertów typowych dla określonych zdarzeń.
•
przypomnienia powinny się wyświetlać użytkownikowi po zalogowaniu do
Systemu.
1.20.
System musi umożliwić współpracę funkcjonalną Zakładek (bądź rozwiązań
równoważnych
funkcjonalnie),
tzn.
każda
z
Zakładek
musi
funkcjonalnie
współpracować z pozostałymi.
1.21.
System musi na etapie projektowania umożliwiać zmianę etykiet pól.
1.22.
System musi umożliwiać definiowanie i wprowadzanie, przez użytkownika o
odpowiednich uprawnieniach, nowych pól opisowych i zesłownikowanych.
1.23.
System
musi
umożliwiać
definiowanie
skrótów
klawiaturowych
przez
administratora systemu.
1.24.
System powinien wspomagać dekretację pism od komorników (technologia OCR
rozpoznaje treść pisma i dopasowuje je do odpowiedniej sprawy).
1.25.
System powinien posiadać możliwość integracji z kalendarzem Google.
1.26.
System powinien mieć wbudowany wewnętrzny komunikator.
1.27.
System powinien mieć responsywną wersję mobilną.
1.28.
System powinien mieć możliwość skalowania ekranów użytkowników.
1.29.
Obsługa systemu powinna być intuicyjna.
1.30.
System powinien mieć możliwość personalizacji interfejsu użytkownika możliwej
do samodzielnego wykonania przez użytkownika.
1.31.
System powinien posiadać narzędzie do budowy ról/uprawnień dostępne dla
administratorów.
1.32.
System powinien posiadać narzędzia do automatycznego tworzenia dokumentacji.
1.33.
System powinien posiadać narzędzie do automatycznego testowania.
1.34.
System powinien posiadać funkcjonalność tworzenia i zmiany szablonów pism
1.35.
w prosty sposób.
1.36.
Szkolenie e-learningowe.
1.37.
System musi gwarantować bezpieczeństwo przechowywania oraz dostępu do
gromadzonych danych zgodnie z przepisami ustawy z dnia 29 sierpnia 1997 o ochronie
danych osobowych (Dz. U. z 2014 r. poz. 1182 z późn. zm.) oraz wydanych do tej ustawy
rozporządzeń.
1.38.
System musi spełniać warunki określone w Rozporządzeniu Rady Ministrów z dnia
12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych
wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej
oraz minimalnych wymagań dla systemów teleinformatycznych.
1.39.
System musi zapewniać:
•
poufność – ochrona przed ujawnieniem nieuprawnionemu odbiorcy,
•
integralność
–
ochrona
przed
nieuprawnioną
modyfikacją
lub
zniekształceniem,
•
dostępność – dostęp do zasobów informacyjnych,
•
rozliczalność
–
określenie
i
weryfikowanie
odpowiedzialności
za
wykorzystanie systemu informacyjnego,
•
autentyczność
–
weryfikacja
–
gwarancja
tożsamości
podmiotów
i prawdziwości
zasobów,
•
niezawodność
oczekiwanego
zachowania
Systemu
i otrzymywanych wyników.
1.40.
Każdy komunikat o błędzie w Oprogramowaniu Aplikacyjnym musi być oznaczony
kodem błędu, musi być krótko opisany i zostać udokumentowany w Dokumentacji
Technicznej.