Wymagania funkcjonalne I niefunkcjonalne


Wymagania niefunkcjonalne 2.1Wymagania ogólne



Pobieranie 0.56 Mb.
Strona14/14
Data28.04.2016
Rozmiar0.56 Mb.
1   ...   6   7   8   9   10   11   12   13   14

2Wymagania niefunkcjonalne

2.1Wymagania ogólne


  1. 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.

  2. Przy rozbudowie architektury należy zastosować technologie 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.

  3. Wykonawca musi opracować i wdrożyć rozbudowany System Informacyjny Intranet w środowiskach:

    1. produkcyjnym – środowisko, w którym będzie funkcjonowało rozwiązanie produkcyjnie. W środowisku tym będą tylko komponenty wykorzystywane produkcyjnie,

    2. 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.

  1. Wykonawca musi zaprojektować i wdrożyć system monitorowania SII w oparciu o eksploatowane obecnie przez Zamawiającego Systemy.

  2. Wykonawca dostarczy wytyczne jak dostosować eksploatowane aktualnie środowisko System Center Operations Manager (SCOM) w celu monitorowania SII i wdroży monitorowanie.

  3. 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.

  4. System będzie skutecznie funkcjonował w ramach dostępnej w jednostkach statystyki publicznej infrastruktury intranetowej i internetowej.

  5. 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.

  6. 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.

  7. 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.

  8. 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.2Używalność/ergonomia


  1. System musi umożliwiać pracę minimum w trzech standardowych rozdzielczościach ekranu: 1024x768, 1280x1024 i 1280x960 bez zmiany układu widoku.

  2. System musi umożliwiać zmianę wielkości czcionki bez zmiany układu widoku, zdefiniowane powinny być przynajmniej trzy wielkości czcionek.

  3. 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.

  4.  Czas reakacji systemu na działanie (akcję) użytkownika nie może przekroczyć 3 sekund.

  5. 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.

  6. 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.3Bezpieczeństwo


  1. 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.

  2. 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.

  3. 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.

  4. System musi posiadać konfigurowalny mechanizm audytów pozwalający:

    1. umieszczać w dzienniku audytu operacje wykonane strukturze portalu oraz na mechanizmach bezpieczeństwa,

    2. zdefiniować, na jakich obiektach Portalu będą działać audyty oraz które zdarzenia podlegają audytowi,

    3. wyświetlać zawartość logów audytowych przez osoby uprawnione i eksportować ich zawartość do arkusza kalkulacyjnego lub pliku tekstowego.

  1. 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.

  2. Konfiguracja uprawnień Systemu powinna być zrealizowana zgodnie z zasadą minimalnych uprawnień.

  3. Podczas umieszczania nowych folderów lub dokumentów w korzeniu lokalizacji (folder główny), użytkownicy nie mogą mieć 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.

  4. 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.

  5. Zamawiający wymaga, aby system posiadał mechanizmy obronne przed atakami informatycznymi na bazy danych, w których przechowywane są informacje.

  6. System musi zapewniać ochronę zatwierdzonych elementów przed nieautoryzowanymi zmianami.

  7. 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.

  8. System musi umożliwiać korzystanie z protokołu SSL dla zabezpieczenia przesyłanych informacji lub w inny sposób zapewniać szyfrowanie przesyłania danych.

  9. 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).

  10. System musi zawierać mechanizmy wysyłania powiadomień o incydentach na adres e-mail.

  11. System musi udostępnić mechanizm monitorowania dostępności usług, zintegrowany z scentralizowanym systemem monitorowania posiadanym przez Zamawiającego.

  12. System musi zapewnić pełną identyfikowalność użytkowników i przypisanie odpowiedzialności za działania wykonane w systemie.

  13. System musi zapewnić blokowanie dostępu określonych użytkowników do zasobów systemu.

  14. System zapewni mechanizmy zachowania integralności danych.

  15. 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.

  16. System uniemożliwi modyfikowanie logów systemowych.

  17. System zapewni logowanie prób usuwania logów systemowych.

  18. System zapewni interfejs umożliwiający sprawne przeszukanie logów według zadanych kryteriów.

  19. 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.4Skalowalność i Wydajność





  1. System zapewni skalowalność gwarantującą rozszerzenie ilości obsługiwanych użytkowników (stanowisk) oraz pracę w środowisku rozproszonym.

  2. System zapewni możliwość rozbudowy warstwy prezentacyjnej, aplikacyjnej i bazodanowej przy zachowaniu odpowiedniej jakości 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.

  3. System musi sprawnie funkcjonować w warunkach rosnącej liczby użytkowników, objętości przetwarzania danych lub/i rozwoju sieci komputerowej.

  4. Liniowy wzrost liczby i rozmiaru danych przechowywanych w ramach Systemu nie może zwiększać czasu wyszukiwania bardziej niż liniowo.

  5. 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ść


  1. 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.

  2. System zapewni możliwość integracji danych i aplikacji z innymi systemami – relacyjnymi bazami danych (minimum obsługa ODBC).

  3. System musi umożliwiać synchroniczną i asynchroniczną komunikację pomiędzy systemami lub samodzielnymi modułami.

  4. System musi umożliwiać zidentyfikowanie i wykorzystanie usług udostępnianych przez systemy lub samodzielne moduły.

  5. System musi wykorzystywać standard XML do wymiany danych.

  6. W przypadku wymiany dokumentów w formacie XML system będzie używać standardu XSD do ich weryfikacji.

  7. 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ść


  1. 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.

  2. 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.

  3. 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%).

2.7Łatwość pielęgnacji


  1. 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.

  2. 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





  1. Wykonawca zapewni zgodność zaproponowanego rozwiązania z powszechnie akceptowalnymi standardami.

  2. System musi wspierać standard XMLsig (XML-Signature Syntax and Processing).

  3. System musi wspierać standard XMLenc (XML Encryption Syntax and Processing).

  4. System musi wspierać standard WSDL (Web Services Description Language).

  5. System musi wspierać protokół SOAP (Simple Object Access Protocol).

  6. System musi posiadać interfejs dostępu zgodny z JDBC/ODBC.

  7. System musi wspierać standard XML (Extensible Markup Language).

  8. System musi wspierać standard XSD.

  9. System musi wspierać język XSL (Extensible Stylesheet Language).

  10. System musi wspierać język XSLT (Extensible Stylesheet Language Transformation).

  11. System musi wspierać standard Unicode UTF-8 (Universal Multiple-Octet Coded Character Set, UCS transformation format UTF-8).

  12. System musi wspierać format RTF (Rich Text Format Specification).

  13. System musi wspierać format PDF (Portable Document Format).

  14. System musi wspierać format DOC.

  15. System musi wspierać format XLS.

  16. System musi wspierać format PPT.

  17. System musi wspierać format Office Open XML.

  18. System musi wspierać format ODT (Open Document Format for Office Application).

  19. System musi wspierać format JPG i JPEG (Joint Photographic Experts Group).

  20. System musi wspierać format GIF (Graphics Interchange Format).

  21. System musi wspierać format TIF i TIFF (Tagged Image File Format).

  22. System musi wspierać format PNG (Portable Network Graphics).

  23. System musi wspierać format SVG (Scalable Vector Graphics).

  24. System musi obsługiwać jeden z protokołów SAML (Security Assertion Markup Language) lub Kerberos oraz protokół NTP (Network Time Protocol).

  25. 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.

  26. Interfejs musi być zgodny ze standardem minimum XHTML 1.0 Transitional.

  27. Na potrzeby prezentacji treści musi wykorzystywać arkusze stylów CSS.

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   ...   6   7   8   9   10   11   12   13   14


©absta.pl 2019
wyślij wiadomość

    Strona główna