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 - Vstup: Konzultace objednatele - Požadovaný výstup (návrh modulu): o Funkční požadavky o Nefunkční požadavky o Grafická podoba 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 modulu o Návrh archivace dat (zálohovací schéma) - Minimální rozsah požadovaného výstupu (návrh modulu): o Počet uživatelů modulu HelpDesk je cca 130 000 uživatelů o Přizpůsobitelné workflow pro zpracování požadavků podle kategorie a typu požadavku o Základní uživatelské role: ▪ Zadavatel – zadává nové požadavky, sleduje jejich stav, odpovídá upřesňující otázky operátora nebo řešitele a potvrzuje nebo odmítá způsob vyřešení zadaných požadavků ▪ Čtenář – má přístup s omezenými možnostmi ke všem požadavků evidovaným v příslušné kategorii ▪ Operátor – v rámci kategorie má oprávnění čtenáře a zadavatele, navíc schvaluje nově zadané požadavky a předává řešiteli ▪ Řešitel – určuje způsob vyřešení požadavků. Řešitel v rámci dané kategorie vidí pouze požadavky určené k řešení příslušnou skupinou řešitelů.
Funkční požadavky. (Název požadavku) (Komentář k požadavku)
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. 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. Základní funkční požadavky
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. Součástí smlouvy je Technická specifikace Příloha 3 s tabulkou ve formátu Excel, která obsahuje seznam požadavků na funkcionalitu řešení NBA (dále jen „Tabulka požadavků“). Pokud je v Tabulce požadavků některý požadavek označen jako povinný, nebude řešení, které takovému požadavku nevyhovuje, akceptováno a nabídka takového uchazeče bude vyřazena. Tabulka požadavků je rozdělena celkem do pěti částí:
Funkční požadavky. Aplikace pro hlášení závad na objektech a zařízeních
Funkční požadavky. Níže uvedené požadavky budou v rámci analýzy a přípravy Návrhu Realizace s garanty upřesněny a řešení bude rozepsáno v dokumentu Návrhu Realizace verze 2.7. Při návrhu řešení pro oblast P6.02 Poskytovatel zohlední uživatelské postupy v již existujícím AIS EESSI tak, aby se uživatelům nezhoršil uživatelský komfort při přechodu na řešení v IS ZAM. Rozšířené funkcionality aplikace implementované dle funkčních požadavků budou zařazeny do rozsahu školení pro koncové uživatele před nasazením systému do produkčního provozu.