Funkční požadavky o Nefunkční požadavky o Zdroje dat a procesy propagace dat na portál o Integrace aplikací o Architektura systému o Funkční celky a mapování na funkční/nefunkční požadavky o Technologie HW/SW o Procesy provozu a údržby o Usecases o Testcases o Definice základních reportů o Návrh bezpečnosti IS o Návrh archivace dat (zálohovací schéma) - Minimální rozsah požadovaného výstupu (návrh koncepce): o Procesy rozšiřování rozsahu publikovaných informací (redakční systém) ▪ Články ▪ Novinky ▪ RSS ▪ Obrázky a dokumenty ke stažení ▪ Prezentace validovaných ŠVP a příkladů dobré praxe ▪ Integrační rozhraní pro publikaci informací z jiných systémů ▪ Ankety o Procesy rozšiřování portfolia portálem poskytovaných aplikací (portálový systém) o Interaktivní nápověda o Návrh zakomponování modulů IS (dle bodu 2.1. a 2.2.) do portálu o Datový a procesní model jednotlivých mini-aplikací o Předpoklady, scénář a nutná součinnost zhotovitele v případě migrace služby do jiné lokality o Katalog rolí ve webovém portálu o Podpora jazykových mutací o Možnosti migrace dat ze stávajícího webu
Funkční požadavky. Pož. ID Popis
Funkční požadavky. 31
6.1.1 ESB AgriBus 31
6.1.2 Procesní platforma AgriBus BPM 34
6.1.3 Designér webových formulářů 35
6.1.4 Registr služeb 35
6.1.5 Designér služeb 36
6.1.6 Monitoring 36
6.1.7 Historický archiv 37
Funkční požadavky. Komunikační platforma AgriBus se skládá z několika logických funkčních komponent znázorněných na obrázku Obrázek 4 - Logický model AgriBus. Tato kapitola doplňuje popis požadovaného řešení uvedený v kapitole 5 Popis požadovaného řešení o další funkční požadavky na jednotlivé logické funkční komponenty řešení AgriBus. Vybrané požadavky (výběr z níže uvedených požadavků uvedených v této kapitole 6.1), které jsou klasifikovány jako mandatorní (nabízené plnění je musí splňovat), jsou uvedeny v Příloze č. 5 zadávací dokumentace. ESB AgriBus Mezi základní požadavky kladené na komunikační vrstvu ESB AgriBus patří: Konzistentní práci se službami Integrace systémů na bázi webových služeb, umožňujících implementaci SOA; Integrace koncových bodů využívajících různé komunikační protokoly (např. jeden koncový bod vyžaduje JMS a druhý koncový bod podporuje pouze webové služby); Podpora transportů HTTP, JMS, JCA, Enterprise Java Bean, web services (SOAP 1.2, SOAP 1.1, SOAP 1.1 using JAX-RPC, SOAP 1.1/JMS); Podpora orchestrace služeb (řízení workflow služeb modelované v BPEL);
Funkční požadavky. V rámci této kapitoly budou stručně popsány jednotlivé celky.
Funkční požadavky. Bude provedena analýza stávajícího stavu a popis integrace řešení do prostředí Zadavatele. Bude vypracován a předložen detailní technický návrh řešení obsahující minimálně následující oblasti: konceptuální schéma a celková architektura řešení síťová infrastruktura a integrace do prostředí Zadavatele definice komunikačních pravidel jednotlivých komponent řešení, včetně požadovaných síťových prostupů na firewallech a integrace na stávající firewally integrace na storage a virtualizační infrastrukturu Zadavatele vrstva VDI Horizon včetně popisu řešení vysoké dostupnosti komponent souborové a databázové služby integrace na základní síťové služby (DNS, DHCP, NTP) integrace na Active Directory vč. popisu potřebných úprav prostředí, definice přístupových oprávnění zálohování - integrace do stávajícího řešení dvoufaktorová autentizace, PKI integrace do prostředí správy koncových zařízení MS SCCM, SW aktualizací a antivirové ochrany Bude vypracován a předložen detailní harmonogram prací včetně časování, kapacit zdrojů, zahrnutí etap: příprava, realizace, testování, pilotní provoz, rollout, předání.
Funkční požadavky. (Název požadavku) (Komentář k požadavku)
Funkční požadavky. ID Název požadavku Popis požadavku F1 Škálovatelnost prostředí • Navrhované řešení musí splňovat všechna kritéria pro budoucí rozšíření systému a škálovatelnost o další: a) Zdrojové systémy b) Funkční logování c) Operace s logy d) Filtrování e) Šablony f) Hardware • Navržená architektura prostředí musí umožnovat škálování a zvětšování v rámci použitého HW a SW. • Škálovatelnost celého systému musí být do budoucna schopná akceptovat až pětinásobný objem stávajících logů Systém musí umožnovat funkcionalitu dlouhodobého uložení logů (logy, které se nebudou dále zpracovávat) dle následujících požadavků: F2 Dlouhodobé uložení logů • Dlouhodobě uložené logy musí být uloženy odděleně od CLM úložiště • Úložiště (HW i SW) dlouhodobě ukládaných logů je součástí dodávky budoucího dodavatele • Délka uschování všech logů mimo logů primárných a podpůrných aktiv SŽ v dlouhodobě ukládacím režimu: 12 měsíců • Délka uschování logů primárných a podpůrných aktiv SŽ v dlouhodobě ukládacím režimu: 18 měsíců a v souladu s požadavky § 22, vyhlášky č.82/2018 • CLM systém musí být schopen provádět dlouhodobé ukládání na externím uložišti a mít možnost připojit se na externí uložiště (dlouhodobé úložiště uložiště třetích stran) ID Název požadavku Popis požadavku F3 Požadavky na funkcionality zpracování logů • Minimální délka uchování aktuálních logů s možností zpracování: 30 dnů • Možnost provádění kombinovaných forenzních vyhledávacích možností v uživatelské konzoli s možností nastavení minimálně následujících parametrů: a) Zdroj logu (s možností vlastního pojmenování zdroje nebo skupiny zdrojů) b) Čas vzniku události c) Čas přijetí logu d) Kombinace vyhledání s možností podmiňování IF (tj. na základě jedné události v “systému A“ a současně v případě vzniku další události v „systému B“ vygeneruj akci – e-mail, upozornění, apod.) e) Automatizované a plánované aktivity v podobě výše popsaného požadavku f) Možnost vytvoření aktivit na základě nálezu vyhledávaného řetězce g) vyhledávání musí umožnit hledat kromě zadaných hodnot také s uvedením “wildcards” nebo regulárních výrazů, a to pro všechny podporované atributy (nejen pro vyjmenované) • Sběr a ukládání nestrukturovaných logů všech datových typů • Logy se musí ukládat v původním stavu a nesmí být umožněno jejich editování • Možnost indexace logů • Možnost automatizace zpracování s pomocí skriptů • Možnost vizualizace s přednastavenými šablonami • Možnost normalizace a standardizace dle přednastavených šablon • Možnost autorizačníc...
Funkční požadavky. D.2.1.1. Objekty a atributy dostupné pro externí automatizované zpracování (API) Zadavatel musí mít možnost objekty a atributy API konfigurovat dle vlastních aktuálních potřeb. Pro splnění základní technické specifikace zadavatel požaduje dostupnost objektů a atributů API minimálně v rozsahu: Osoba ● OS_CISLO int id zaměstnance ● Osobní čísla sloučených osob ● RODNE_CISLO nvarchar(10) Rodné číslo ● PRIJMENI nvarchar(50) Příjmení ● JMENO nvarchar(50) Jméno ● RODNE_JMENO nvarchar(50) Rodné příjmení ● TITUL nvarchar(30) Titul před ● TITUL_ZA nvarchar(30) Titul za ● CISLO_OP nvarchar(15) Číslo občanského průkazu ● CISLO_PASU nvarchar(15) Číslo pasu ● MISTO_NAROZENI nvarchar(50) Místo narození ● ULICE_TRV nvarchar(75) Trvalé bydliště - ulice ● MISTO_TRV nvarchar(50) Trvalé bydliště - město ● PSC_TRV nvarchar(10) Trvalé bydliště - PSČ ● ULICE_PRECH nvarchar(75) Přechodné bydliště - ulice ● MISTO_PRECH nvarchar(50) Přechodné bydliště - město ● PSC_PRECH nvarchar(10) Přechodné bydliště - PSČ ● KMEN_STR nvarchar(10) kmenový útvar zaměstnance ● CISLO_PLATBY nvarchar(25) Číslo bankovního účtu ● SPEC_SYMB nvarchar(10) Specifický symbol ● CISLO_BANKY nvarchar(4) Číslo banky ● DATUM_ZMENY nvarchar(10) Datum zahájení (v organizaci) ● ZEMĚ_TRV nvarchar(10) Trvalé bydliště - stát ● DAT_NAROZENI date Datum narození ● POHLAVI nvarchar(1) Pohlaví ● STAT_PRISL nvarchar(10) Státní příslušnost Pracovně-právní vztah (PPV) – vztahuje se vždy k aktuálnímu pracovnímu poměru ● OS_CISLO int id zaměstnance ● CISLO_POM int Číslo pracovního poměru ● DRUH_POM nvarchar(1) Druh pracovního poměru (hlavní, DPP …) – z číselníku ● PRAC_STR nvarchar(10) Útvar pro aktuální pracovní poměr ● PRAC_KATEG int Pracovní kategorie – z číselníku ● JKZ int Klasifikace zaměstnání – z číselníku ISCO ● HOD_UVAZEK float pracovní úvazek - hodiny ● VYKAZ nvarchar(3) Dělnické profese – z číselníku ● DOV_CERPANA float Dovolená čerpaná ● DOV_DODATK float Dovolená dodatková ● ZBYV_RD_MIN_ROK float Dovolená převedená z minulého roku ● RD_LETOS float Dovolená letošní ● DOV_CELKEM float Dovolená celkem ● DATUM_NASTUPU nvarchar(10) Datum zahájení pracovního poměru ● DATUM_UKONC nvarchar(10) Předpokládané datum, pokud není potom skutečné nebo NULL ● DATUM_ZMENY nvarchar(10) Datum zahájení (v organizaci) Organizační struktura ● Identifikátor ústavu nebo pracoviště ● Identifikátor nadřízeného ústavu nebo pracoviště ● Jméno ústavu nebo pracoviště ● Vedoucí ústavu nebo pracoviště (identifikátor osoby) Organizační struktura –...
Funkční požadavky. FP02 Podporované desktopové operační systémy Zohledněno bude fungování na operačních systémech Windows XP a vyšší, MacOS X Lion (10.7) a vyšší. závazný Navržené řešení OpenCms, podporuje zmiňované desktopové systémy