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.