PŘÍLOHA Č. 1













PŘÍLOHA Č. 1





SMLOUVY O NÁVRHU, VÝVOJI, IMPLEMENTACI A SPRÁVĚ
INFORMAČNÍHO SYSTÉMU PORTÁL SLUŽEB SFDI







TECHNICKÉ VYMEZENÍ SLUŽEB









Verze: 1.0



OBSAH



SEZNAM ZKRATEK

Zkratka

Význam

API

Application Programming Interface je rozhraní pro výměnu dat mezi aplikacemi

CSIRT

Computer Security Incident Response Team, bezpečnostní tým

DDoS

Distributed Denial of Service, typ útoku pro záměrné přehlcení cílové služby

CMS2

Centrální místo služeb

FO

Fyzická osoba

GDPR

Nařízení Evropského parlamentu a Rady (EU) 2016/679 o ochraně osobních údajů

IPSEC

IPsec (IP security) je bezpečnostní rozšíření IP protokolu určený zejména pro přenosy zabezpečené a šifrované komunikace na bázi sítí TCP/IP

IS

Informační systém

ISMS

Information Security Management System, systém řízení bezpečnosti informací

ISZR

Informační systém základních registrů

JIP/XXXX

Jednotný identitní prostor informačních systémů veřejné správy a Katalog autentizačních a autorizačních služeb

XXX

Xxxx také NIA ID je identifikační prostředek umožňující zaručené prokazovaní totožnosti při přihlašování k online službám, které požadují alespoň značnou úroveň důvěry prostředků identifikace.

XXX

Xxxxx hlavního architekta eGovernmentu, Digitální informační agentura

OVM

Orgán veřejné moci

MS Azure

Cloudová platforma společnosni Microsoft



SaaS

Software as a service, služba cloud computingu

PO

Právnická osoba

ROB

Registr obyvatel

ROS

Registr osob

RPO

Recovery Point Objective neboli čas, ze kterého existuje poslední záloha dat, a který reprezentuje interval časového úseku, která již nebude s největší pravděpodobností možno obnovit

SFDI

Státní fond dopravní infrastruktury

SLA

Service level agreement, úroveň poskytované podpory, smluvní ukazatele

SZR

Správa základních registrů

TCP

Transmission Control Protocol, umožňující aplikacím obousměrně přenášet data

XML

Extensible Markup Language (rozšiřitelný značkovací jazyk)

ZR

Základní registry

ZVA

Závěrečné vyhodnocení akce





  1. ANALÝZA

Na základě článku 3.1.1. Smlouvy a v termínech dle harmonogramu definovaném v článku 5. této Přílohy č. 1 Smlouvy vyhotoví Poskytovatel dle Harmonogramu Analýzu, jejíž rozsah je uveden ve výše uvedeném článku. Cílem analýzy bude zpřesnit návrh vytvoření IS PORTÁL SLUŽEB SFDI na základě informací uvedených v této Příloze.

  1. VÝVOJ IS PORTÁL SLUŽEB SFDI vč. zajištění služeb systémové integrace

    1. Legislativní požadavky

Zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů;

Zákonem č. 181/2014 Sb., o kybernetické bezpečnost, ve znění pozdějších předpisů a vyhláška č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), ve znění pozdějších předpisů, je IS PORTÁL SLUŽEB SFDI klasifikován jako významný informační systém;

Vyhláška č. 442/2006 Sb., kterou se stanoví struktura informací zveřejňovaných o povinném subjektu způsobem umožňujícím dálkový přístup, ve znění pozdějších předpisů;

Usnesení vlády České republiky č. 86 ze dne 27. ledna 2020;

Zákon č. 365/2000 Sb., o informačních systémech veřejné správy, ve znění pozdějších předpisů;

Zákon č. 104/2000 Sb., o Státním fondu dopravní infrastruktury, ve znění pozdějších předpisů;

Zákon č. 12/2020 Sb., o právu na digitální služby, ve znění pozdějších předpisů;

Zákon č. 250/2017 Sb., o elektronické identifikaci, ve znění pozdějších předpisů;

Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů;

Zákon č. 499/2004 Sb., o archivnictví a spisové službě, ve znění pozdějších předpisů;

Zákon č. 110/2019 Sb. o zpracování osobních údajů; Nařízení Evropského parlamentu a Rady (EU) č. 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů, ve znění pozdějších předpisů.





    1. Popis architektury systému IS PORTÁL SLUŽEB SFDI

V rámci naplnění primárních business potřeb budou v rámci implementovaného celku IS PORTÁL SLUŽEB SFDI (implementační název systému IS PORTÁL SLUŽEB SFDI) vytvořeny dvě primární komponenty:






  • IS PORTÁL SLUŽEB SFDI

    • Primární webová aplikace dostupná pro širší veřejnost a vybrané skupiny mimo pracovníky SFDI, kteří ji používají pro primární business procesy.

    • Aplikace je také dostupná pro pracovníky SFDI, kdy umožňuje správu portálu a řešení.

  • SFDI Middleware

    • Sada backendových mikroslužeb, které zajišťují implementaci business a technický procesů, spolu s realizací integračních služeb.

    1. Popis jednotlivých komponent

Tyto primární části systému se dále rozpadají na tyto komponenty:







V rámci sady komponent SFDI Middleware rozeznáváme následující samostatné služby:



  • Portal Storage Service

    • Služba pro ukládání dokumentů v rámci portálového úložiště.

  • Portal Backend-for-Frontend Service

    • Služba pro poskytování specifických API pro implementaci webové aplikace IS PORTÁL SLUŽEB SFDI.

  • Email API

    • Služba pro odesílání notifikací pomocí emailu.

  • Document Service

    • Služba pro generování a vytváření PDF dokumentů v rámci řešení.

  • Internal Messaging Service

    • Služba pro implementování interního „pošťáka“ – messaging služby pro interní uživatele portálu.

  • Business Logic Service

    • Služba pro správu a vyhodnocení formulářů a dalších business procesů v rámci portálu.

  • External Integration Service

    • Sada služeb zajišťujících integraci na externí služby.



V rámci komponenty SFDI Portal rozeznáváme následující samostatné části:

  • SFDI Portal Web App Frontend

    • SPA samostatná webová aplikace poskytující uživatelské rozhraní pro jednotlivé služby na venek.

  • External Authorization

Modul autorizace zajišťuje vyhodnocení identity a mandátu přihlášeného uživatele a jeho předání do dalších částí aplikace.


Hlavní rozhraní jádra systému

Externí systém

Popis funkce

Základní registry, tj. ISZR

Integrace zajišťuje dotažení údajů z ROB a ROS.

Národní bod EID (NIA)

Zajišťuje autorizaci, ověření uživatele / osoby při přihlašování do IS PORTÁL SLUŽEB SFDI.

JIP/XXXX

Zajišťuje dvou faktorové ověření Interních i externích uživatelů Objednatele a Klientů z řad OVM.

Spisová evidence / Spisová služba SFDI

Zajištuje uložení dokumentů / příloh z IS PORTÁL SLUŽEB SFDI do hlavní spisové služby správce a zpět. Rozhraní je oboustranné a jak pro přenos dokumentů / příloh, tak pro přenos metadat dokumentů / příloh.

IS Evidence

Zajišťuje přenos dat do interního agendového informačního systému SFDI - IS Evidence. Rozhraní je oboustranné.

Email server

Zajišťuje rozesílání notifikací uživatelům.

Mandátní rejstřík / Xxxxxxx zastupování

Zajistí evidenci a ověření mandátů / zmocnění zastupujících uživatelů.



    1. Základní funkční požadavky

Objednatel požaduje, aby Poskytovatel implementoval následující funkce IS PORTÁL SLUŽEB SFDI. Uvedené požadavky jsou pouze demonstrativním výčtem základních požadavků na IS PORTÁL SLUŽEB SFDI.

Vybrané funkční požadavky - viz tabulka níže - budou předmětem další diskuse mezi Objednatelem a Poskytovatelem v rámci Analýzy.

Požadavky na IS PORTÁL SLUŽEB SFDI, dále také jako Webová aplikace jsou členěny do následujících oblastí / fází:

  • Konzultace

  • Příspěvky

    • Žádost o poskytnutí finančních prostředků

    • Vyhodnocení žádosti Hodnotiteli

    • Smluvní dokumentace

    • Žádost o změnu

    • Žádost o výjimku

    • Žádost o proplacení a uvolnění

    • Závěrečné vyhodnocení akce (ZVA)

    • Audit

    • ISPROFOND

  • Přehledy

    • Klienti a Žádosti

    • Programy a Žádosti

    • Vlastní úkoly

  • Mandáty a zastupování

    • Nastavení zastupování

    • Ověření zastupování

  • Administrace / Vnitřní správa

    • Šablony a vzory dokumentů

    • Nápověda

    • Číselníky - Programy - Typy příspěvků, Zdroje

    • Globální technické nastavení

  • Portálové úložiště

    • Práce s Dokumenty

  • Pošta

    • Pošta

    • Notifikace

  • Uživatel

    • User management

    • Dotažení údajů o Klientovi z registrů

    • Autentizace & Autorizace

  • Ostatní

    • Nápověda

    • Obecné dotazy

Kód požadavku

        1. KONZ – 1

Název

        1. ­Rezervace konkrétního času Konzultace - Vyplnění nové Konzultace

Popis

Oblast / fáze: Konzultace

Webová aplikace musí obsahovat formulář pro rezervaci konzultace s referentem SFDI, a to jak konzultace osobní, tak i korespondenční.

Webová aplikace musí umožnit pouze omezené množství konzultací v předem definovaných časových slotech a dnech.



Kód požadavku

        1. KONZ – 2

Název

        1. Vytvoření/výběr unikátní Akce a kategorie Akce

Popis

Oblast / fáze: Konzultace

Při rezervaci konzultace musí Webová aplikace přednabízet již vytvořené Akce, tj. jednotlivé projekty, a musí umožnit vytvořit další novou Akci, a zároveň zajistit, aby Akce nebyly založeny duplicitně. Konzultlaci bude možné využít pouze 1x pro Akci, s výjimkou opakování konzultace po předchozím zamítnutí Žádosti o financování dané Akce - další podmínky možného opakování konzultace budou předmětem detailní analýzy.



Kód požadavku

KONZ – 3

Název

        1. Průběžné ukládání Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Při vyplňování formuláře a přikládání příloh musí Webová aplikace zajistit průběžné ukládání vyplněných údajů a příloh, tak aby se uživatel mohl např. při výpadku připojení mohl k rozpracovanému a průběžně ukládanému formuláři vrátit a pokračovat ve vyplňování.

        3. Takovýto formulář je ve stavu rozpracovaný a při průběžném uložení se neaplikují validace na povinné vyplnění údajů, tyto se aplikují až při uložení jako kompletní / finální verze - viz navazující požadavky níže.

        4. Rozpracovaný formulář je uložený permanentně, dokud jej uživatel sám nesmaže.



Kód požadavku

        1. KONZ – 4

Název

        1. Nahrání podkladů ke Konzultaci - Přiložení příloh(y) ke Konzultaci

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        3. Velikost 1 souboru může být až 1,5GB.

        4. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.

        5. Tento požadavek specificky pokrývá přiložení přílohy externím uživatelem.



Kód požadavku

        1. KONZ – 5

Název

        1. Zobrazení seznamu Konzultací (včetně filtrování, řazení)

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu.



Kód požadavku

        1. KONZ – 6

Název

        1. Zobrazení detailu Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí zajistit zobrazení detailu případu včetně přiložených příloh, včetně informace o stavu­­­­­­, je-li případ rozpracován, podán, uzavřen. Případné další stavy budou předmětem další analýzy.

        3. Detail případu musí být zajištěn formou webového formuláře a data musí být systémem zpracována na úrovni jednotlivých atributů.



Kód požadavku

        1. KONZ – 7

Název

        1. Zobrazení podkladů ke Konzultaci - Zobrazení přílohy - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. KONZ – 8

Název

        1. Přiložení příloh(y) - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        3. Velikost 1 souboru může být až 1,5GB.

        4. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.

        5. Tento požadavek specificky pokrývá přiložení přílohy interním uživatelem.



Kód požadavku

        1. KONZ – 9

Název

        1. Stažení příloh(y) - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. KONZ – 10

Název

        1. Zobrazení přílohy - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. KONZ – 11

Název

        1. Smazání příloh(y) - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit smazání přílohy přiložené k případu, přičemž ke smazání musí dojít ve všech úložištích aplikace. Pouze pokud již příloha byla zpracována v interním agendovém informačním systému, tato již nesmí být smazána.



Kód požadavku

        1. KONZ – 12

Název

        1. Uložení příloh(y) do "Spisové evidence" - příloha(y) Konzultace - integrace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        3. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. KONZ – 13

Název

        1. Uložení dat Konzultace do "IS Evidence" - integrace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit uložení dat z webového formuláře do interního agendového informačního systému SFDI k dalšímu zpracování referentem SFDI - formou přímé integrace Webové aplikace a interního agendového informačního systému SFDI.



Kód požadavku

        1. KONZ – 14

Název

        1. Přenos aktualizovaných dat Konzultace z "IS Evidence" - Aktualizace a uzavření Konzultace v "IS Evidence" - integrace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit přijetí dat zpět z interního agendového informačního systému SFDI do Webové aplikace - formou přímé zpětné integrace interního agendového informačního systému SFDI a Webové aplikace.



Kód požadavku

        1. KONZ – 15

Název

        1. Uložení aktualizovaných dat Konzultace - aktualizace a uzavření

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí po přijetí aktualizovaných dat zajistit jejich validaci, zpracování a uložení, včetně návazné změny stavu zpracovávaného případu.



Kód požadavku

        1. KONZ – 16

Název

        1. Notifikace Klienta o aktualizaci a uzavření Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí notifikovat uživatele při změně stavu případu nebo při dokončení zahájené operace.

        3. Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a Webová aplikace musí uživateli umožnit prohlížet si vytvořené notifikace.



Kód požadavku

        1. KONZ – 17

Název

        1. Zobrazení příloh(y)/vyjádření - Zobrazení přílohy - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. KONZ – 18

Název

        1. Stažení příloh(y)/vyjádření - Stažení příloh(y) - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. KONZ – 19

Název

        1. Editace Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit editaci případu a editaci / změnu / smazání / přiložení dalších příloh a uložení rozpracovaného případu, dokud není podaný. A naopak, pokud je případ již podaný, Xxxxxx aplikace nesmí umožnit editaci údajů a příloh případu.

        3. Webová aplikace musí zajistit předání editovaných údajů do interního agendového informačního systému SFDI v jejich poslední verzi.



Kód požadavku

        1. KONZ – 20

Název

        1. Změna stavu Konzultace na "vyřízená"

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        3. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        4. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. KONZ – 21

Název

        1. Odeslání příloh(y)/vyjádření Klientovi ze "Spisové evidence" do "Portálu" - integrace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        3. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat automatickou změnou stavu a notifikací uživatele.



Kód požadavku

        1. KONZ – 22

Název

        1. Zobrazení příloh(y)/vyjádření - Zobrazení přílohy - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. KONZ – 23

Název

        1. Stažení příloh(y)/vyjádření - Stažení příloh(y) - Konzultace

Popis

        1. Oblast / fáze: Konzultace

        2. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

KONZ – 24

Název

Smazání příloh(y)/vyjádření - Smazání příloh(y) - Konzultace - integrace

Popis

Oblast / fáze: Konzultace

Webová aplikace musí umožnit smazání přílohy přiložené k případu, přičemž ke smazání musí dojít ve všech úložištích aplikace. Pouze pokud již příloha byla zpracována v interním agendovém informačním systému SFDI, tato již nesmí být smazána.



Kód požadavku

KONZ – 25

Název

Nastavení kalendáře volných slotů SFDI ke Konzultacím a nastavení počtů volných slotů pro elektronické Konzultace per Typ příspěvku

Popis

Oblast / fáze: Konzultace

Webová aplikace musí umožnit nastavení volných slotů pro jak elektronické, tak i korespondenční konzultace pro vybrané období a pro vybrané typy příspěvků.

Webová aplikace musí umožnit kdykoliv změnit toto nastavení, odebrat vybrané volné sloty, nebo celé dny, týdny, dle potřeby a kapacity pracoviště SFDI.



Kód požadavku

        1. PRIS-ZF – 26

Název

        1. Zobrazení seznamu Žádostí (včetně filtrování, řazení)

Popis

Oblast / fáze: Žádost o financování - Příspěvky

Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu.



Kód požadavku

        1. PRIS-ZF – 27

Název

        1. Zadání nové Žádosti ­- Žádost o financování akce / projektu formou příspěvku (včetně vytvoření/výběru unikátní Akce a kategorie Akce)

Popis

Oblast / fáze: Žádost o financování - Příspěvky

Webová aplikace musí obsahovat formulář pro vytvoření žádost daného typu - přičemž každý typ žádosti může mít specifický formulář, bude se jednat pouze o základní formulář s hlavičkou Žadatele, typem příspěvku, názvem akce / projektu apod., nikoliv s detailními daty, které budou k formuláři přiloženy formou souboru jako samostatná příloha.

Webová aplikace musí zajistit, aby nebylo možno založit dvě akce / projekty se stejným názvem pro daný rok.

Při zadávání nové Žádosti musí Webová aplikace přednabízet již vytvořené Akce, tj. jednotlivé projekty, a musí umožnit vytvořit další novou Akci, a zároveň zajistit, aby Akce nebyly založeny duplicitně.



Kód požadavku

PRIS-ZF – 28

Název

        1. Průběžné ukládání Žádosti ­- Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Při vyplňování formuláře a přikládání příloh musí Webová aplikace zajistit průběžné ukládání vyplněných údajů a příloh, tak aby se uživatel mohl např. při výpadku připojení mohl k rozpracovanému a průběžně ukládanému formuláři vrátit a pokračovat ve vyplňování.

        2. Takovýto formulář je ve stavu rozpracovaný a při průběžném uložení se neaplikují validace na povinné vyplnění údajů, tyto se aplikují až při uložení jako kompletní / finální verze - viz navazující požadavky níže.



Kód požadavku

        1. PRIS-ZF – 29

Název

        1. Zobrazení detailu Žádosti ­- Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí zajistit zobrazení detailu případu včetně přiložených příloh, včetně informace o stavu­­­­­­, je-li případ rozpracován, podán, uzavřen. Případné další stavy budou předmětem další analýzy.

        2. Detail případu musí být zajištěn formou webového formuláře pro základní data hlavičky případu, ale hlavní data případu, která budou následně předána internímu uživateli SFDI ke zpracování musí být přiložena ve formě XLSx datového souboru, tzn. mimo webový formulář aplikace a tato hlavní data nebudou systémem zpracována na úrovni jednotlivých atributů.



Kód požadavku

        1. PRIS-ZF – 30

Název

        1. Přiložení příloh(y) - Žádost ­- Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        2. Velikost 1 souboru může být až 1,5GB.

        3. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.



Kód požadavku

        1. PRIS-ZF – 31

Název

        1. Stažení příloh(y) - Žádost ­- Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZF – 32

Název

        1. Zobrazení přílohy - Žádost ­- Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZF – 33

Název

        1. Editace Žádosti ­- Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit editaci případu a editaci / změnu / smazání / přiložení dalších příloh a uložení rozpracovaného případu, dokud není podaný. A naopak, pokud je případ již podaný, Xxxxxx aplikace nesmí umožnit editaci údajů a příloh případu.

        2. Webová aplikace musí zajistit předání editovaných údajů do interního agendového informačního systému SFDI v jejich poslední verzi.



Kód požadavku

        1. PRIS-ZF – 34

Název

        1. Uložení Žádosti k podání - Mandátem - Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit uložení žádosti ve stavu, kdy je hotová a finální za zmocněného uživatele - Mandáta, a je připravena k podání uživatelem zmocněným pro podání.

        2. Webová aplikace musí rozlišit kompletní vyplnění žádosti Mandátem formou dedikovaného stavu, ve kterém bude Mandátovi znemožněno dělat v žádosti další změny.

        3. Workflow stavů žádosti a přechody mezi nimi budou předmětem další analýzy.



Kód požadavku

        1. PRIS-ZF – 35

Název

        1. Podání Žádosti ­- Žádost o financování akce / projektu formou příspěvku

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit podání žádosti, tj. provedení úkonu v souladu s platnou legislativou, kdy dojde k uložení podaných dat žádosti, evidenci okamžiku podání a zaznamenání podání do auditního logu.

        2. Jednotlivé navazující operace, které Webová aplikace musí provést v návaznosti na podání, jsou uvedeny v dalších samostatných požadavcích níže.



Kód požadavku

        1. PRIS-ZF – 36

Název

        1. Uložení záznamu do historie změn

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí při libovolné změně dat, stavu, příloh případu provést uložení záznamu do historie změn a u vybraných změn, které podléhají úkonům prováděným v souladu s platnou legislativou, např. "podání žádosti", apod., u těchto vybraných změn musí Webová aplikace zaznamenat také úkon do auditního logu.



Kód požadavku

        1. PRIS-ZF – 37

Název

        1. Tisk opisu formuláře Žádosti do PDF - při podání

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit otisknout aktuální formulář do PDF, např. pomocí funkčnosti tisk do PDF, přičemž musí Webová aplikace zajistit korektní rozložení polí na formuláři.

        2. Tisk opisu formuláře Žádost do PDF bude plnit předdefinovanou šablonu PDF. Šablonu nebude možné měnit uživatelem.

        3. Webová aplikace musí takto vytvořené PDF uložit k dokumentům / přílohám žádost a pokud se jedná o otisk vzniklý v návaznosti na úkon prováděný v souladu s platnou legislativou, např. "podání žádosti", pak bude PDF opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZF – 38

Název

        1. Vytvoření pečetě a razítka na dokumentu - opisu formuláře Žádosti - při podání - integrace

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZF – 39

Název

        1. Uložení dokumentu / PDF opisu formuláře Žádost včetně pečetě a razítka do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí umožnit uložení také PDF opisu formuláře včetně pečetě a razítka do "Spisové evidence" prostřednictvím integrace.

        3. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZF – 40

Název

        1. Vygenerování Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí vygenerovat Potvrzení o digitálním úkonu u operací, které jsou úkony prováděné v souladu s platnou legislativou, např. "podání žádosti", pak bude Potvrzení o digitálním úkonu vygenerováno do předdefinovaného layoutu šablony PDF.

        2. Následně bude toto Potvrzení opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZF – 41

Název

        1. Vytvoření pečetě a razítka a uložení Potvrzení o digitálním úkonu do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZF – 42

Název

        1. Notifikace Klienta o podané Žádosti a o vygenerovaném Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí notifikovat uživatele při změně stavu případu nebo při dokončení zahájené operace.

        2. Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a Webová aplikace musí uživateli umožnit prohlížet si vytvořené notifikace.



Kód požadavku

        1. PRIS-ZF – 43

Název

        1. Uložení příloh(y) do "Spisové evidence" - příloha(y) Žádosti - integrace

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZF – 44

Název

        1. Uložení dat Žádost do "Spisové evidence" jako příloha - integrace

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit uložení dat případu, která jsou ve formě přílohy, do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí takovouto přílohu s daty předávat jako specifický typ přílohy, neb na něj bude navázán proces jejího zpracování ze strany "Spisové evidence", resp. interního agendového systému SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZF – 45

Název

        1. Validace důvěryhodnosti Žádosti a příloh při podání - integrace

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí zajistit prostřednictvím integrace se systémem "Spisová evidence" validaci důvěryhodnosti a digitálního podpisu dokumentů / příloh případu, např. v případě, kdy klient / externí uživatel přiloží přílohy s digitálním podpisem.



Kód požadavku

        1. PRIS-ZF – 46

Název

        1. Manuální změna stavu Žádosti (např. na stav "k vyhodnocení", ...)

Popis

Oblast / fáze: Žádost o financování - Příspěvky

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-VH – 47

Název

        1. Zobrazení detailu Žádosti

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

        1. Webová aplikace musí zajistit zobrazení detailu případu včetně přiložených příloh, včetně informace o stavu­­­­­­, je-li případ rozpracován, podán, uzavřen. Případné další stavy budou předmětem další analýzy.

Detail případu musí být zajištěn formou webového formuláře pro základní data hlavičky případu, ale hlavní data případu, která budou následně předána internímu uživateli SFDI ke zpracování musí být přiložena ve formě XLSx datového souboru, tzn. mimo webový formulář aplikace a tato hlavní data nebudou systémem zpracována na úrovni jednotlivých atributů.



Kód požadavku

        1. PRIS-VH – 48

Název

        1. Stažení příloh(y) - Žádost

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

PRIS-VH – 49

Název

        1. Zobrazení přílohy - Žádost

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-VH – 50

Název

        1. Odeslání dokumentu/rozhodnutí Klientovi ze "Spisové evidence" do "Portálu" - integrace

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-VH – 51

Název

        1. Zobrazení dokumentu/rozhodnutí - Zobrazení přílohy - Vyhodnocení

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-VH – 52

Název

        1. Stažení dokumentu/rozhodnutí - Stažení příloh(y) - Vyhodnocení

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-VH – 53

Název

        1. Smazání dokumentu/rozhodnutí - Smazání příloh(y) - Vyhodnocení - integrace

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

        1. Webová aplikace musí umožnit smazání přílohy přiložené k případu, přičemž ke smazání musí dojít ve všech úložištích aplikace. Pouze pokud již příloha byla zpracována v interním agendovém informačním systému, tato již nesmí být smazána.



Kód požadavku

        1. PRIS-VH – 54

Název

        1. Změna stavu Žádosti na "schválená" / "schválená s podmínkou" / "zamítnutá"

Popis

Oblast / fáze: Vyhodnocení Žádosti o financování - Příspěvky

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-SD – 55

Název

        1. Přiložení podkladů ke smlouvě - Přiložení příloh(y) - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí zajistit možnost přiložení příloh k případu, který je ve stavu očekávaných podkladů pro tvorbu smluvní dokumentace.

        2. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        3. Velikost 1 souboru může být až 1,5GB.

Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.



Kód požadavku

        1. PRIS-SD – 56

Název

        1. Uložení podkladů ke smlouvě do "Spisové evidence" - integrace

Popis

Oblast / fáze: Smluvní dokumentace

Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace.

Příloha musí mít definovaný typ přílohy ve smyslu typů dokumentů / příloh případů, aby bylo možno je správně kategorizovat jak ve Webové aplikaci, tak ve "Spisové evidenci", tak i při následném zpracování v interním agendovém informačním systému SFDI "IS Evidence".



Kód požadavku

PRIS-SD – 57

Název

        1. Zobrazení podkladů ke smlouvě - Zobrazení přílohy - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-SD – 58

Název

        1. Stažení podkladů ke smlouvě - Stažení příloh(y) - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-SD – 59

Název

        1. Odeslání smlouvy/dodatku k podpisu Klientovi do "Portálu" - integrace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat automatickou změnou stavu a notifikací uživatele.



Kód požadavku

        1. PRIS-SD – 60

Název

        1. Zobrazení smluv/dodatků k Žádosti

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu.

        2. Webová aplikace musí umožnit zobrazení dokumentů / příloh případu označených daným typem, např. "smluvní dokumenty", nebo "žádosti", apod. v jedné skupině, v jedné sekci, tzn. Webová aplikace musí tyto dokumenty / přílohy zřetelně pro uživatele odlišit pro zajištění komfortní práce s dokumenty / přílohami jednoho typu.

        3. Webová aplikace musí vizuálně odlišit zdroj dokumentu / přílohy případu, jestli se jedná o dokument / přílohu od uživatele, nebo od interního uživatele referenta SFDI, nebo automaticky generovaný dokument (např. "potvrzení podání"), apod.



Kód požadavku

        1. PRIS-SD – 61

Název

        1. Zobrazení smlouvy/dodatku k podpisu - Zobrazení přílohy - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-SD – 62

Název

        1. Stažení smlouvy/dodatku k podpisu - Stažení příloh(y) - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-SD – 63

Název

        1. Přiložení podepsané smlouvy/dodatku - Přiložení příloh(y) - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí zajistit možnost přiložení příloh typu "Smluvní dokumentace".

        2. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.



Kód požadavku

        1. PRIS-SD – 64

Název

        1. Validace digitálního podpisu dokumentu přes "Spisová evidence" - integrace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí zajistit prostřednictvím integrace se systémem "Spisová evidence" validaci důvěryhodnosti a digitálního podpisu dokumentů / příloh případu, např. v případě, kdy klient / externí uživatel přiloží přílohy s digitálním podpisem.



Kód požadavku

        1. PRIS-SD – 65

Název

        1. Uložení podepsané smlouvy/dodatku do "Spisové evidence" - integrace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Při ukládání musí Webová aplikace zajistit správné označení typem přílohy / dokumentu.



Kód požadavku

        1. PRIS-SD – 66

Název

        1. Zobrazení podepsané smlouvy/dodatku - Zobrazení přílohy - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-SD – 67

Název

        1. Stažení podepsané smlouvy/dodatku - Stažení příloh(y) - Smluvní dokumentace

Popis

Oblast / fáze: Smluvní dokumentace

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZZ – 68

Název

        1. Zobrazení seznamu Žádostí (včetně filtrování, řazení)

Popis

Oblast / fáze: Žádost o změnu

Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu.



Kód požadavku

        1. PRIS-ZZ – 69

Název

        1. Zadání nové Žádosti - Žádost o změnu

Popis

Oblast / fáze: Žádost o změnu

Webová aplikace musí obsahovat formulář pro vytvoření žádost daného typu - přičemž každý typ žádosti může mít specifický formulář, bude se jednat pouze o základní formulář s hlavičkou Žadatele, typem příspěvku, názvem akce / projektu apod., nikoliv s detailními daty, které budou k formuláři přiloženy formou souboru jako samostatná příloha.

Webová aplikace musí zajistit, aby Žádost byla zadána v kontextu vybrané / zobrazené akce / projektu, tzn. uživatel musí nejdříve vybrat konkrétní akci a teprve poté může zadat tuto žádost.



Kód požadavku

PRIS-ZZ – 70

Název

        1. Průběžné ukládání Žádosti

Popis

Oblast / fáze: Žádost o změnu

        1. Při vyplňování formuláře a přikládání příloh musí Webová aplikace zajistit průběžné ukládání vyplněných údajů a příloh, tak aby se uživatel mohl např. při výpadku připojení k rozpracovanému a průběžně ukládanému formuláři vrátit a pokračovat ve vyplňování.

        2. Takovýto formulář je ve stavu rozpracovaný a při průběžném uložení se neaplikují validace na povinné vyplnění údajů, tyto se aplikují až při uložení jako kompletní / finální verze - viz navazující požadavky níže.



Kód požadavku

        1. PRIS-ZZ – 71

Název

        1. Zobrazení detailu Žádosti

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí zajistit zobrazení detailu případu včetně přiložených příloh, včetně informace o stavu­­­­­­, je-li případ rozpracován, podán, uzavřen. Případné další stavy budou předmětem další analýzy.

        2. Detail případu musí být zajištěn formou webového formuláře pro základní data hlavičky případu, ale hlavní data případu, která budou následně předána internímu uživateli SFDI ke zpracování musí být přiložena ve formě XLSx datového souboru, tzn. mimo webový formulář aplikace a tato hlavní data nebudou systémem zpracována na úrovni jednotlivých atributů.



Kód požadavku

        1. PRIS-ZZ – 72

Název

        1. Přiložení příloh(y) - Žádost

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        2. Velikost 1 souboru může být až 1,5GB.

        3. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.



Kód požadavku

        1. PRIS-ZZ – 73

Název

        1. Stažení příloh(y) - Žádost

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZZ – 74

Název

        1. Zobrazení přílohy - Žádost

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZZ – 75

Název

        1. Editace Žádosti

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit editaci případu a editaci / změnu / smazání / přiložení dalších příloh a uložení rozpracovaného případu, dokud není podaný. A naopak, pokud je případ již podaný, Xxxxxx aplikace nesmí umožnit editaci údajů a příloh případu.

        2. Webová aplikace musí zajistit předání editovaných údajů do interního agendového informačního systému SFDI v jejich poslední verzi.



Kód požadavku

        1. PRIS-ZZ – 76

Název

        1. Uložení Žádosti k podání - Mandátem

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit uložení žádosti ve stavu, kdy je hotová a finální za zmocněného uživatele - Mandáta, a je připravena k podání uživatelem zmocněným pro podání.

        2. Webová aplikace musí rozlišit kompletní vyplnění žádosti Mandátem formou dedikovaného stavu, ve kterém bude Mandátovi znemožněno dělat v žádosti další změny.

        3. Workflow stavů žádosti a přechody mezi nimi budou předmětem další analýzy.



Kód požadavku

        1. PRIS-ZZ – 77

Název

        1. Podání Žádosti

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit podání žádosti, tj. provedení úkonu v souladu s platnou legislativou, kdy dojde k uložení podaných dat žádosti, evidenci okamžiku podání a zaznamenání podání do auditního logu.

        2. Jednotlivé navazující operace, které Webová aplikace musí provést v návaznosti na podání, jsou uvedeny v dalších samostatných požadavcích níže.



Kód požadavku

        1. PRIS-ZZ – 78

Název

        1. Uložení záznamu do historie změn

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí při libovolné změně dat, stavu, příloh případu provést uložení záznamu do historie změn a u vybraných změn, které podléhají úkonům prováděným v souladu s platnou legislativou, např. "podání žádosti", apod., u těchto vybraných změn musí Webová aplikace zaznamenat také úkon do auditního logu.



Kód požadavku

        1. PRIS-ZZ – 79

Název

        1. Tisk opisu formuláře Žádosti do PDF - při podání

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit otisknout aktuální formulář do PDF, např. pomocí funkčnosti tisk do PDF, přičemž musí Webová aplikace zajistit korektní rozložení polí na formuláři.

        2. Tisk opisu formuláře Žádost do PDF bude plnit předdefinovanou šablonu PDF. Šablonu nebude možné měnit uživatelem.

        3. Webová aplikace musí takto vytvořené PDF uložit k dokumentům / přílohám žádost a pokud se jedná o otisk vzniklý v návaznosti na úkon prováděný v souladu s platnou legislativou, např. "podání žádosti", pak bude PDF opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZZ – 80

Název

        1. Vytvoření pečetě a razítka na dokumentu - opisu formuláře Žádosti - při podání - integrace

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využítím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZZ – 81

Název

        1. Uložení dokumentu / PDF opisu formuláře Žádost včetně pečetě a razítka do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZZ – 82

Název

        1. Vygenerování Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí vygenerovat Potvrzení o digitálním úkonu u operací, které jsou úkony prováděné v souladu s platnou legislativou, např. "podání žádosti", pak bude Potvrzení o digitálním úkonu vygenerováno do předdefinovaného layoutu šablony PDF.

        2. Následně bude toto Potvrzení opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZZ – 83

Název

        1. Vytvoření pečetě a razítka a uložení Potvrzení o digitálním úkonu do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZZ – 84

Název

        1. Notifikace Klienta o podané Žádosti a o vygenerovaném Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí notifikovat uživatele při změně stavu případu nebo při dokončení zahájené operace.

        2. Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a Webová aplikace musí uživateli umožnit prohlížet si vytvořené notifikace.



Kód požadavku

        1. PRIS-ZZ – 85

Název

        1. Uložení příloh(y) do "Spisové evidence" - příloha(y) Žádosti - integrace

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZZ – 86

Název

        1. Uložení dat Žádost do "Spisové evidence" jako příloha - integrace

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit uložení dat případu, která jsou ve formě přílohy, do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí takovouto přílohu s daty předávat jako specifický typ přílohy, neb na něj bude navázán proces jejího zpracování ze strany "Spisové evidence", resp. interního agendového systému SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZZ – 87

Název

        1. Validace důvěryhodnosti Žádosti a příloh při podání - integrace

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí zajistit prostřednictvím integrace se systémem "Spisová evidence" validaci důvěryhodnosti a digitálního podpisu dokumentů / příloh případu, např. v případě, kdy klient / externí uživatel přiloží přílohy s digitálním podpisem.



Kód požadavku

        1. PRIS-ZZ – 88

Název

        1. Manuální změna stavu Žádosti (např. na stav "k vyhodnocení", ...)

Popis

Oblast / fáze: Žádost o změnu

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZV – 89

Název

        1. Zobrazení seznamu Žádostí (včetně filtrování, řazení)

Popis

Oblast / fáze: Žádost o výjimku

Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu.



Kód požadavku

        1. PRIS-ZV – 90

Název

        1. Zadání nové Žádosti - Žádost o výjimku

Popis

Oblast / fáze: Žádost o výjimku

Webová aplikace musí obsahovat formulář pro vytvoření žádost daného typu - přičemž každý typ žádosti může mít specifický formulář, bude se jednat pouze o základní formulář s hlavičkou Žadatele, typem příspěvku, názvem akce / projektu apod., nikoliv s detailními daty, které budou k formuláři přiloženy formou souboru jako samostatná příloha.

Webová aplikace musí zajistit, aby Žádost byla zadána v kontextu vybrané / zobrazené akce / projektu, tzn. uživatel musí nejdříve vybrat konkrétní akci a teprve poté může zadat tuto žádost.



Kód požadavku

PRIS-ZV – 91

Název

        1. Průběžné ukládání Žádosti

Popis

Oblast / fáze: Žádost o výjimku

        1. Při vyplňování formuláře a přikládání příloh musí Webová aplikace zajistit průběžné ukládání vyplněných údajů a příloh, tak aby se uživatel mohl např. při výpadku připojení k rozpracovanému a průběžně ukládanému formuláři vrátit a pokračovat ve vyplňování.

        2. Takovýto formulář je ve stavu rozpracovaný a při průběžném uložení se neaplikují validace na povinné vyplnění údajů, tyto se aplikují až při uložení jako kompletní / finální verze - viz navazující požadavky níže.



Kód požadavku

        1. PRIS-ZV – 92

Název

        1. Zobrazení detailu Žádosti

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí zajistit zobrazení detailu případu včetně přiložených příloh, včetně informace o stavu­­­­­­, je-li případ rozpracován, podán, uzavřen. Případné další stavy budou předmětem další analýzy.

        2. Detail případu musí být zajištěn formou webového formuláře pro základní data hlavičky případu, ale hlavní data případu, která budou následně předána internímu uživateli SFDI ke zpracování musí být přiložena ve formě XLSx datového souboru, tzn. mimo webový formulář aplikace a tato hlavní data nebudou systémem zpracována na úrovni jednotlivých atributů.



Kód požadavku

        1. PRIS-ZV – 93

Název

        1. Přiložení příloh(y) - Žádost

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        2. Velikost 1 souboru může být až 1,5GB.

        3. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.



Kód požadavku

        1. PRIS-ZV – 94

Název

        1. Stažení příloh(y) - Žádost

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZV – 95

Název

        1. Zobrazení přílohy - Žádost

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZV – 96

Název

        1. Editace Žádosti

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit editaci případu a editaci / změnu / smazání / přiložení dalších příloh a uložení rozpracovaného případu, dokud není podaný. A naopak, pokud je případ již podaný, Xxxxxx aplikace nesmí umožnit editaci údajů a příloh případu.

        2. Webová aplikace musí zajistit předání editovaných údajů do interního agendového informačního systému SFDI v jejich poslední verzi.



Kód požadavku

        1. PRIS-ZV – 97

Název

        1. Uložení Žádosti k podání - Mandátem

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit uložení žádosti ve stavu, kdy je hotová a finální za zmocněného uživatele - Mandáta, a je připravena k podání uživatelem zmocněným pro podání.

        2. Webová aplikace musí rozlišit kompletní vyplnění žádosti Mandátem formou dedikovaného stavu, ve kterém bude Mandátovi znemožněno dělat v žádosti další změny.

        3. Workflow stavů žádosti a přechody mezi nimi budou předmětem další analýzy.



Kód požadavku

        1. PRIS-ZV – 98

Název

        1. Podání Žádosti

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit podání žádosti, tj. provedení úkonu v souladu s platnou legislativou, kdy dojde k uložení podaných dat žádosti, evidenci okamžiku podání a zaznamenání podání do auditního logu.

        2. Jednotlivé navazující operace, které Webová aplikace musí provést v návaznosti na podání, jsou uvedeny v dalších samostatných požadavcích níže.



Kód požadavku

        1. PRIS-ZV – 99

Název

        1. Uložení záznamu do historie změn

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí při libovolné změně dat, stavu, příloh případu provést uložení záznamu do historie změn a u vybraných změn, které podléhají úkonům prováděným v souladu s platnou legislativou, např. "podání žádosti", apod., u těchto vybraných změn musí Webová aplikace zaznamenat také úkon do auditního logu.



Kód požadavku

        1. PRIS-ZV – 100

Název

        1. Tisk opisu formuláře Žádosti do PDF - při podání

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit otisknout aktuální formulář do PDF, např. pomocí funkčnosti tisk do PDF, přičemž musí Webová aplikace zajistit korektní rozložení polí na formuláři.

        2. Tisk opisu formuláře Žádost do PDF bude plnit předdefinovanou šablonu PDF. Šablonu nebude možné měnit uživatelem.

        3. Webová aplikace musí takto vytvořené PDF uložit k dokumentům / přílohám žádost a pokud se jedná o otisk vzniklý v návaznosti na úkon prováděný v souladu s platnou legislativou, např. "podání žádosti", pak bude PDF opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZV – 101

Název

        1. Vytvoření pečetě a razítka na dokumentu - opisu formuláře Žádosti - při podání - integrace

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZV – 102

Název

        1. Uložení dokumentu / PDF opisu formuláře Žádost včetně pečetě a razítka do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí umožnit uložení také PDF opisu formuláře včetně pečetě a razítka do "Spisové evidence" prostřednictvím integrace.

        3. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZV – 103

Název

        1. Vygenerování Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí vygenerovat Potvrzení o digitálním úkonu u operací, které jsou úkony prováděné v souladu s platnou legislativou, např. "podání žádosti", pak bude Potvrzení o digitálním úkonu vygenerováno do předdefinovaného layoutu šablony PDF.

        2. Následně bude toto Potvrzení opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZV – 104

Název

        1. Vytvoření pečetě a razítka a uložení Potvrzení o digitálním úkonu do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZV – 105

Název

        1. Notifikace Klienta o podané Žádosti a o vygenerovaném Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí notifikovat uživatele při změně stavu případu nebo při dokončení zahájené operace.

        2. Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a Webová aplikace musí uživateli umožnit prohlížet si vytvořené notifikace.



Kód požadavku

        1. PRIS-ZV – 106

Název

        1. Uložení příloh(y) do "Spisové evidence" - příloha(y) Žádosti - integrace

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZV – 107

Název

        1. Uložení dat Žádost do "Spisové evidence" jako příloha - integrace

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit uložení dat případu, která jsou ve formě přílohy, do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí takovouto přílohu s daty předávat jako specifický typ přílohy, neb na něj bude navázán proces jejího zpracování ze strany "Spisové evidence", resp. interního agendového systému SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZV – 108

Název

        1. Validace důvěryhodnosti Žádosti a příloh při podání - integrace

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí zajistit prostřednictvím integrace se systémem "Spisová evidence" validaci důvěryhodnosti a digitálního podpisu dokumentů / příloh případu, např. v případě, kdy klient / externí uživatel přiloží přílohy s digitálním podpisem.



Kód požadavku

        1. PRIS-ZV – 109

Název

        1. Manuální změna stavu Žádosti (např. na stav "k vyhodnocení", ...)

Popis

Oblast / fáze: Žádost o výjimku

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZP – 110

Název

        1. Zobrazení seznamu Žádostí (včetně filtrování, řazení)

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu.



Kód požadavku

        1. PRIS-ZP – 111

Název

        1. Zadání nové Žádosti - Žádost o proplacení

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

Webová aplikace musí obsahovat formulář pro vytvoření žádost daného typu - přičemž každý typ žádosti může mít specifický formulář, bude se jednat pouze o základní formulář s hlavičkou Žadatele, typem příspěvku, názvem akce / projektu apod., nikoliv s detailními daty, které budou k formuláři přiloženy formou souboru jako samostatná příloha.

Webová aplikace musí zajistit, aby Žádost byla zadána v kontextu vybrané / zobrazené akce / projektu, tzn. uživatel musí nejdříve vybrat konkrétní akci a teprve poté může zadat tuto žádost.



Kód požadavku

PRIS-ZP – 112

Název

        1. Průběžné ukládání Žádosti

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Při vyplňování formuláře a přikládání příloh musí Webová aplikace zajistit průběžné ukládání vyplněných údajů a příloh, tak aby se uživatel mohl např. při výpadku připojení k rozpracovanému a průběžně ukládanému formuláři vrátit a pokračovat ve vyplňování.

        2. Takovýto formulář je ve stavu rozpracovaný a při průběžném uložení se neaplikují validace na povinné vyplnění údajů, tyto se aplikují až při uložení jako kompletní / finální verze - viz navazující požadavky níže.



Kód požadavku

        1. PRIS-ZP – 113

Název

        1. Zobrazení detailu Žádosti

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí zajistit zobrazení detailu případu včetně přiložených příloh, včetně informace o stavu­­­­­­, je-li případ rozpracován, podán, uzavřen. Případné další stavy budou předmětem další analýzy.

        2. Detail případu musí být zajištěn formou webového formuláře pro základní data hlavičky případu, ale hlavní data případu, která budou následně předána internímu uživateli SFDI ke zpracování musí být přiložena ve formě XLSx datového souboru, tzn. mimo webový formulář aplikace a tato hlavní data nebudou systémem zpracována na úrovni jednotlivých atributů.



Kód požadavku

        1. PRIS-ZP – 114

Název

        1. Přiložení příloh(y) - Žádost

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        2. Velikost 1 souboru může být až 1,5GB.

        3. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.



Kód požadavku

        1. PRIS-ZP – 115

Název

        1. Stažení příloh(y) - Žádost

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZP – 116

Název

        1. Zobrazení přílohy - Žádost

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZP – 117

Název

        1. Editace Žádosti

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit editaci případu a editaci / změnu / smazání / přiložení dalších příloh a uložení rozpracovaného případu, dokud není podaný. A naopak, pokud je případ již podaný, Xxxxxx aplikace nesmí umožnit editaci údajů a příloh případu.

        2. Webová aplikace musí zajistit předání editovaných údajů do interního agendového informačního systému SFDI v jejich poslední verzi.



Kód požadavku

        1. PRIS-ZP – 118

Název

        1. Uložení Žádosti k podání - Mandátem

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit uložení žádosti ve stavu, kdy je hotová a finální za zmocněného uživatele - Mandáta, a je připravena k podání uživatelem zmocněným pro podání.

        2. Webová aplikace musí rozlišit kompletní vyplnění žádosti Mandátem formou dedikovaného stavu, ve kterém bude Mandátovi znemožněno dělat v žádosti další změny.

        3. Workflow stavů žádosti a přechody mezi nimi budou předmětem další analýzy.



Kód požadavku

        1. PRIS-ZP – 119

Název

        1. Podání Žádosti

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit podání žádosti, tj. provedení úkonu v souladu s platnou legislativou, kdy dojde k uložení podaných dat žádosti, evidenci okamžiku podání a zaznamenání podání do auditního logu.

        2. Jednotlivé navazující operace, které Webová aplikace musí provést v návaznosti na podání, jsou uvedeny v dalších samostatných požadavcích níže.



Kód požadavku

        1. PRIS-ZP – 120

Název

        1. Uložení záznamu do historie změn

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí při libovolné změně dat, stavu, příloh případu provést uložení záznamu do historie změn a u vybraných změn, které podléhají úkonům prováděným v souladu s platnou legislativou, např. "podání žádosti", apod., u těchto vybraných změn musí Webová aplikace zaznamenat také úkon do auditního logu.



Kód požadavku

        1. PRIS-ZP – 121

Název

        1. Tisk opisu formuláře Žádosti do PDF - při podání

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit otisknout aktuální formulář do PDF, např. pomocí funkčnosti tisk do PDF, přičemž musí Webová aplikace zajistit korektní rozložení polí na formuláři.

        2. Tisk opisu formuláře Žádost do PDF bude plnit předdefinovanou šablonu PDF. Šablonu nebude možné měnit uživatelem.

        3. Webová aplikace musí takto vytvořené PDF uložit k dokumentům / přílohám žádost a pokud se jedná o otisk vzniklý v návaznosti na úkon prováděný v souladu s platnou legislativou, např. "podání žádosti", pak bude PDF opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZP – 122

Název

        1. Vytvoření pečetě a razítka na dokumentu - opisu formuláře Žádosti - při podání - integrace

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZP – 123

Název

        1. Uložení dokumentu / PDF opisu formuláře Žádost včetně pečetě a razítka do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit uložení přílohy případu včetně PDF opisu formuláře včetně pečetě a razítka do "Spisové evidence" prostřednictvím integrace.



Kód požadavku

        1. PRIS-ZP – 124

Název

        1. Vygenerování Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí vygenerovat Potvrzení o digitálním úkonu u operací, které jsou úkony prováděné v souladu s platnou legislativou, např. "podání žádosti", pak bude Potvrzení o digitálním úkonu vygenerováno do předdefinovaného layoutu šablony PDF.

        2. Následně bude toto Potvrzení opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZP – 125

Název

        1. Vytvoření pečetě a razítka a uložení Potvrzení o digitálním úkonu do "Spisové evidence" - integrace

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZP – 126

Název

        1. Notifikace Klienta o podané Žádosti a o vygenerovaném Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí notifikovat uživatele při změně stavu případu nebo při dokončení zahájené operace.

        2. Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a Webová aplikace musí uživateli umožnit prohlížet si vytvořené notifikace.



Kód požadavku

        1. PRIS-ZP – 127

Název

        1. Uložení příloh(y) do "Spisové evidence" - příloha(y) Žádosti - integrace

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZP – 128

Název

        1. Uložení dat Žádost do "Spisové evidence" jako příloha - integrace

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit uložení dat případu, která jsou ve formě přílohy, do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí takovouto přílohu s daty předávat jako specifický typ přílohy, neb na něj bude navázán proces jejího zpracování ze strany "Spisové evidence", resp. interního agendového systému SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZP – 129

Název

        1. Validace důvěryhodnosti Žádosti a příloh při podání - integrace

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí zajistit prostřednictvím integrace se systémem "Spisová evidence" validaci důvěryhodnosti a digitálního podpisu dokumentů / příloh případu, např. v případě, kdy klient / externí uživatel přiloží přílohy s digitálním podpisem.



Kód požadavku

        1. PRIS-ZP – 130

Název

        1. Manuální změna stavu Žádosti (např. na stav "k vyhodnocení", ...)

Popis

Oblast / fáze: Žádost o proplacení / uvolnění

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZVA – 131

Název

        1. Zobrazení seznamu Žádostí (včetně filtrování, řazení)

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu.



Kód požadavku

        1. PRIS-ZVA – 132

Název

        1. Zadání nové Žádosti - Závěrečné vyhodnocení

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

Webová aplikace musí obsahovat formulář pro vytvoření žádost daného typu - přičemž každý typ žádosti může mít specifický formulář, bude se jednat pouze o základní formulář s hlavičkou Žadatele, typem příspěvku, názvem akce / projektu apod., nikoliv s detailními daty, které budou k formuláři přiloženy formou souboru jako samostatná příloha.

Webová aplikace musí zajistit, aby Žádost byla zadána v kontextu vybrané / zobrazené akce / projektu, tzn. uživatel musí nejdříve vybrat konkrétní akci a teprve poté může zadat tuto žádost.



Kód požadavku

PRIS-ZVA – 133

Název

        1. Průběžné ukládání Žádosti

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Při vyplňování formuláře a přikládání příloh musí Webová aplikace zajistit průběžné ukládání vyplněných údajů a příloh, tak aby se uživatel mohl např. při výpadku připojení k rozpracovanému a průběžně ukládanému formuláři vrátit a pokračovat ve vyplňování.

        2. Takovýto formulář je ve stavu rozpracovaný a při průběžném uložení se neaplikují validace na povinné vyplnění údajů, tyto se aplikují až při uložení jako kompletní / finální verze - viz navazující požadavky níže.



Kód požadavku

        1. PRIS-ZVA – 134

Název

        1. Zobrazení detailu Žádosti

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí zajistit zobrazení detailu případu včetně přiložených příloh, včetně informace o stavu­­­­­­, je-li případ rozpracován, podán, uzavřen. Případné další stavy budou předmětem další analýzy.

        2. Detail případu musí být zajištěn formou webového formuláře pro základní data hlavičky případu, ale hlavní data případu, která budou následně předána internímu uživateli SFDI ke zpracování musí být přiložena ve formě XLSx datového souboru, tzn. mimo webový formulář aplikace a tato hlavní data nebudou systémem zpracována na úrovni jednotlivých atributů.



Kód požadavku

        1. PRIS-ZVA – 135

Název

        1. Přiložení příloh(y) - Žádost

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí zajistit možnost přiložení příloh k případu v předem definovaných formátech / typech souborů. Tento výčet typů souborů bude upřesněn během detailní analýzy, nicméně bude zahrnovat i formáty MS Office, obrázky, videa, typy souborů projektové dokumentace a grafického návrhu.

        2. Velikost 1 souboru může být až 1,5GB.

        3. Webová aplikace musí zajistit bezpečné uložení příloh a jejich zpřístupnění pro externího i interního uživatele.



Kód požadavku

        1. PRIS-ZVA – 136

Název

        1. Stažení příloh(y) - Žádost

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZVA – 137

Název

        1. Zobrazení přílohy - Žádost

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-ZVA – 138

Název

        1. Editace Žádosti

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit editaci případu a editaci / změnu / smazání / přiložení dalších příloh a uložení rozpracovaného případu, dokud není podaný. A naopak, pokud je případ již podaný, Xxxxxx aplikace nesmí umožnit editaci údajů a příloh případu.

        2. Webová aplikace musí zajistit předání editovaných údajů do interního agendového informačního systému SFDI v jejich poslední verzi.



Kód požadavku

        1. PRIS-ZVA – 139

Název

        1. Uložení Žádosti k podání - Mandátem

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit uložení žádosti ve stavu, kdy je hotová a finální za zmocněného uživatele - Mandáta, a je připravena k podání uživatelem zmocněným pro podání.

        2. Webová aplikace musí rozlišit kompletní vyplnění žádosti Mandátem formou dedikovaného stavu, ve kterém bude Mandátovi znemožněno dělat v žádosti další změny.

        3. Workflow stavů žádosti a přechody mezi nimi budou předmětem další analýzy.



Kód požadavku

        1. PRIS-ZVA – 140

Název

        1. Podání Žádosti

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit podání žádosti, tj. provedení úkonu v souladu s platnou legislativou, kdy dojde k uložení podaných dat žádosti, evidenci okamžiku podání a zaznamenání podání do auditního logu.

        2. Jednotlivé navazující operace, které Webová aplikace musí provést v návaznosti na podání, jsou uvedeny v dalších samostatných požadavcích níže.



Kód požadavku

        1. PRIS-ZVA – 141

Název

        1. Uložení záznamu do historie změn

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí při libovolné změně dat, stavu, příloh případu provést uložení záznamu do historie změn a u vybraných změn, které podléhají úkonům prováděným v souladu s platnou legislativou, např. "podání žádosti", apod., u těchto vybraných změn musí Webová aplikace zaznamenat také úkon do auditního logu.



Kód požadavku

        1. PRIS-ZVA – 142

Název

        1. Tisk opisu formuláře Žádosti do PDF - při podání

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit otisknout aktuální formulář do PDF, např. pomocí funkčnosti tisk do PDF, přičemž musí Webová aplikace zajistit korektní rozložení polí na formuláři.

        2. Tisk opisu formuláře Žádost do PDF bude plnit předdefinovanou šablonu PDF. Šablonu nebude možné měnit uživatelem.

        3. Webová aplikace musí takto vytvořené PDF uložit k dokumentům / přílohám žádost a pokud se jedná o otisk vzniklý v návaznosti na úkon prováděný v souladu s platnou legislativou, např. "podání žádosti", pak bude PDF opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZVA – 143

Název

        1. Vytvoření pečetě a razítka na dokumentu - opisu formuláře Žádosti - při podání - integrace

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZVA – 144

Název

        1. Uložení dokumentu / PDF opisu formuláře Žádost včetně pečetě a razítka do "Spisové evidence" - integrace

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí umožnit uložení také PDF opisu formuláře včetně pečetě a razítka do "Spisové evidence" prostřednictvím integrace.

        3. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZVA – 145

Název

        1. Vygenerování Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí vygenerovat Potvrzení o digitálním úkonu u operací, které jsou úkony prováděné v souladu s platnou legislativou, např. "podání žádosti", pak bude Potvrzení o digitálním úkonu vygenerováno do předdefinovaného layoutu šablony PDF.

        2. Následně bude toto Potvrzení opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZVA – 146

Název

        1. Vytvoření pečetě a razítka a uložení Potvrzení o digitálním úkonu do "Spisové evidence" - integrace

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. PRIS-ZVA – 147

Název

        1. Notifikace Klienta o podané Žádosti a o vygenerovaném Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí notifikovat uživatele při změně stavu případu nebo při dokončení zahájené operace.

        2. Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a Webová aplikace musí uživateli umožnit prohlížet si vytvořené notifikace.



Kód požadavku

        1. PRIS-ZVA – 148

Název

        1. Uložení příloh(y) do "Spisové evidence" - příloha(y) Žádosti - integrace

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. PRIS-ZVA – 149

Název

        1. Uložení dat Žádost do "Spisové evidence" jako příloha - integrace

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit uložení dat případu, která jsou ve formě přílohy, do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí takovouto přílohu s daty předávat jako specifický typ přílohy, neb na něj bude navázán proces jejího zpracování ze strany "Spisové evidence", resp. interního agendového systému SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZVA – 150

Název

        1. Validace důvěryhodnosti Žádosti a příloh při podání - integrace

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí zajistit prostřednictvím integrace se systémem "Spisová evidence" validaci důvěryhodnosti a digitálního podpisu dokumentů / příloh případu, např. v případě, kdy klient / externí uživatel přiloží přílohy s digitálním podpisem.



Kód požadavku

        1. PRIS-ZVA – 151

Název

        1. Manuální změna stavu Žádosti (např. na stav "k vyhodnocení", ...)

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZVA – 152

Název

        1. Manuální změna stavu Žádosti (např. na stav "čeká na ZVA")

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-ZVA – 153

Název

        1. Manuální změna stavu Žádosti (např. na stav "schváleno ZVA")

Popis

Oblast / fáze: Závěrečné vyhodnocení akce

        1. Webová aplikace musí umožnit manuální změnu stavu uživatelem - nicméně změna stavu je možná pouze v rámci definovaného workflow stavů.

        2. Webová aplikace musí umožnit tuto manuální změnu stavu jen pro interního uživatele referenta SFDI, který bude disponovat dedikovaným oprávněním pro tuto funkčnost.

        3. Workflow stavů a povolené přechody budou definovány v průběhu detailní analýzy a Webová aplikace musí respektovat toto workflow. Workflow nebude konfigurovatelné s ohledem na to, že musí být napojené i na data přicházející prostřednictvím rozhraní se systémem "Spisová evidence" a prostřednictvím rozhraní se interním agendovým systémem SFDI "IS Evidence".



Kód požadavku

        1. PRIS-AU – 154

Název

        1. Odeslání dokumentu/oznámení Klientovi ze "Spisové evidence" do "Portálu" - integrace

Popis

Oblast / fáze: Audit

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat automatickou změnou stavu a notifikací uživatele.



Kód požadavku

        1. PRIS-AU – 155

Název

        1. Zobrazení dokumentu/oznámení - Zobrazení přílohy - Audit

Popis

Oblast / fáze: Audit

Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

PRIS-AU – 156

Název

        1. Stažení dokumentu/oznámení - Stažení příloh(y) - Audit

Popis

Oblast / fáze: Audit

        1. Webová aplikace musí umožnit zobrazení a stažení přílohy přiložené k případu.



Kód požadavku

        1. PRIS-AU – 157

Název

        1. Smazání dokumentu/oznámení - Smazání příloh(y) - Audit - integrace

Popis

Oblast / fáze: Audit

        1. Webová aplikace musí umožnit smazání přílohy přiložené k případu, přičemž ke smazání musí dojít ve všech úložištích aplikace. Pouze pokud již příloha byla zpracována v interním agendovém informačním systému, tato již nesmí být smazána.



Kód požadavku

        1. PRIS-IS – 158

Název

        1. Přenos detailu ISPROFOND čísla ze "Spisové evidence" v rámci přílohy v metadatech - integrace

Popis

Oblast / fáze: Přidělení ISPROFOND

Webová aplikace musí umožnit přijetí ISPROFOND čísla prostřednictvím integrace se systémem "Spisová evidence" v metadatech přílohy specifického typu.

Předpokladem je, že ISPROFOND číslo bude přiděleno v interním agendovém informačním systému "IS Evidence" a bude předáno formou rozšířených metadat k dokumentu oznamujícím Žadateli přidělení ISPROFOND čísla.



Kód požadavku

        1. PRIS-IS – 159

Název

        1. Uložení detailu ISPROFOND čísla - přidělení

Popis

Oblast / fáze: Přidělení ISPROFOND

Webová aplikace musí zajistit korektní zpracování ISPROFOND čísla načteného prostřednictvím integrace - viz separé požadavek výše.

Webová aplikace musí ISPROFOND číslo uložit k případu, aby bylo k dispozici pro následnou práci uživatele ve Webové aplikaci - připraveno k zobrazení, k použití ve formulářích, apod.



Kód požadavku

PRIS-IS – 160

Název

        1. Automatické založení Financované akce při založení konzultace nebo podání žádosti

Popis

Oblast / fáze: Přidělení ISPROFOND

        1. Webová aplikace provede automatické založení Financované akce při založení konzultace nebo podání žádosti o financování. Datový objekt "Financovaná akce" musí být následně propojen se všemi dokumenty, přílohami, návaznými objekty souvisejícími s danou akcí / projektem.



Kód požadavku

        1. DOKU – 161

Název

        1. Odeslání libovolného odchozího/příchozího dokumentu ze "Spisové evidence" do "Portálu" - integrace

Popis

Oblast / fáze: Předávání Dokumentace a generování

Webová aplikace musí umožnit tuto funkčnost při přijetí a aktualizace dokumentu / přílohy v rámci oblasti Příspěvky.

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat automatickou změnou stavu a notifikací uživatele.



Kód požadavku

        1. DOKU – 162

Název

        1. Odeslání aktualizace metadat libovolného dokumentu ze "Spisové evidence" do "Portálu" - integrace

Popis

Oblast / fáze: Předávání Dokumentace a generování

Webová aplikace musí umožnit přijetí aktualizace metadat libovolného dokumentu / přílohy.

Webová aplikace musí zajistit integraci se systémem "Spisové evidence" tak, aby bylo možno načíst aktualizaci metadat libovolného i existujícího dokumentu / přílohy, tzn. samotný dokument / příloha se nemusí změnit, ale metadata se aktualizují a Webová aplikace na to musí zareagovat jejich přijetím, tj. musí umožnit přijetí aktualizace metadat ve chvíli, kdy tuto aktualizaci systém "Spisová evidence" odešle Webové aplikaci.



Kód požadavku

DOKU – 163

Název

        1. Uložení libovolného dokumentu a aktualizace metadat / přesun libovolného dokumentu v "Portálu"

Popis

Oblast / fáze: Předávání Dokumentace a generování

        1. Dokumentace - přijetí a aktualizace dokumentu - Příspěvky, Financované akce, Správa rozpočtu

        2. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        3. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.

        4. Webová aplikace musí umožnit přijmout aktualizaci dat přílohy případu a dle aktualizace dat, zejména identifikačních dat, musí Webová aplikace zareagovat případným napojením přílohy / dokumentu na nové entity a objekty v aplikaci dle aktualizovaných identifikačních dat.



Kód požadavku

        1. DOKU – 164

Název

        1. Tisk opisu libovolného formuláře do PDF

Popis

Oblast / fáze: Předávání Dokumentace a generování

        1. Webová aplikace musí umožnit tisk opisu libovolného web formuláře do PDF, např. formou použití šablony, nebo formou generování web formuláře do PDF.

        2. Webová aplikace musí umožnit otisknout aktuální formulář do PDF, např. pomocí funkčnosti tisk do PDF, přičemž musí Webová aplikace zajistit korektní rozložení polí na formuláři.

        3. Tisk opisu formuláře Žádost do PDF bude plnit předdefinovanou šablonu PDF. Šablonu nebude možné měnit uživatelem.

        4. Webová aplikace musí takto vytvořené PDF uložit k dokumentům / přílohám žádost a pokud se jedná o otisk vzniklý v návaznosti na úkon prováděný v souladu s platnou legislativou, např. "podání žádosti", pak bude PDF opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. DOKU – 165

Název

        1. Vytvoření pečetě a razítka na dokumentu - opisu libovolného formuláře - integrace

Popis

Oblast / fáze: Předávání Dokumentace a generování

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. DOKU – 166

Název

        1. Uložení libovolného dokumentu a příloh do "Spisové evidence" - integrace

Popis

Oblast / fáze: Předávání Dokumentace a generování

        1. Webová aplikace musí umožnit uložení přílohy případu do "Spisové evidence" prostřednictvím integrace. Stejně tak musí Webová aplikace umožnit aktualizaci přílohy případu ze "Spisové evidence" prostřednictvím integrace.

        2. Webová aplikace musí na následnou aktualizaci přílohy případu specifického typu umět reagovat změnou stavu.



Kód požadavku

        1. DOKU – 167

Název

        1. Vygenerování Potvrzení o digitálním úkonu

Popis

Oblast / fáze: Předávání Dokumentace a generování

        1. Webová aplikace musí umožnit generování a uložení dokumentace dle předdefinované šablony nebo formou tisku do PDF u operací, kde to bude požadování - viz separé požadavky výše a níže.

        2. Webová aplikace musí vygenerovat Potvrzení o digitálním úkonu u operací, které jsou úkony prováděné v souladu s platnou legislativou, např. "podání žádosti", pak bude Potvrzení o digitálním úkonu vygenerováno do předdefinovaného layoutu šablony PDF.

        3. Následně bude toto Potvrzení opatřeno pečetí a razítkem - viz separé požadavek níže.



Kód požadavku

        1. DOKU – 168

Název

        1. Vytvoření pečetě a razítka na Potvrzení o digitálním úkonu - integrace

Popis

Oblast / fáze: Předávání Dokumentace a generování

        1. Webová aplikace musí disponovat funkčností vytvoření pečetě a razítka na libovolném dokumentu, nebo integrací a využitím této funkčnosti prostřednictvím externího systému.

        2. Webová aplikace musí umožnit uložení takto opečetěného a orazítkovaného dokumentu do úložiště Webové aplikace a do "Spisové služby" prostřednictvím integrace - viz separé požadavek níže.



Kód požadavku

        1. DOKU – 169

Název

        1. Uložení Potvrzení o digitálním úkonu do "Spisové evidence" - integrace

Popis

Oblast / fáze: Předávání Dokumentace a generování

        1. Webová aplikace musí umožnit uložení přílohy případu včetně vygenerovaného Potvrzení o digitálním úkonu do "Spisové evidence" prostřednictvím integrace.



Kód požadavku

        1. PREH – 170

Název

        1. Přehled Klientů - Zobrazení seznamu Klientů (včetně filtrování, řazení)

Popis

Oblast / fáze: Přehledy

Webová aplikace musí umožnit zobrazit seznam klientů, tj. subjektů, za které zmocnění uživatelé žádají o financování.

Zároveň musí Webová aplikace umožnit přejít vybráním jednoho klienta na seznam jeho případů - dále viz separátní požadavek níže.

Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování tohoto seznamu.



Kód požadavku

        1. PREH – 171

Název

        1. Přehled Klientů - Zobrazení seznamu Žádostí a Konzultací Klienta (včetně filtrování, řazení)

Popis

Oblast / fáze: Přehledy

Při výběru jednoho klienta Webová aplikace musí zajistit zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu, ale pouze, které jsou ve vazbě pouze na daného klienta, ostatní jsou z tohoto specifického seznamu vyloučeny.

Webová aplikace musí následně umožnit přejít na zobrazení detailu jednoho vybraného případu ze seznamu - dále viz separátní požadavek výše.



Kód požadavku

PREH – 172

Název

        1. Přehled Programů a Žádostí - Zobrazení seznamu Programů - Typů příspěvků (včetně filtrování, řazení)

Popis

Oblast / fáze: Přehledy

Webová aplikace musí umožnit zobrazit seznam programů, tj. typů projektů / typů příspěvků, u kterých je možno žádat o financování - např. "Cyklostezky 2024", "Bezpečnost 2024", apod. - číselník typů projektů / typů příspěvků bude definován v průběhu detailní analýzy.

Zároveň musí Webová aplikace umožnit přejít vybráním jednoho typu projektu / typu příspěvku na seznam případů daného typu - dále viz separátní požadavek níže.

Webová aplikace musí zajistit možnost zobrazení, řazení, filtrování tohoto seznamu.



Kód požadavku

        1. PREH – 173

Název

        1. Přehled Programů a Žádostí - Zobrazení seznamu Žádostí a Konzultací vybraného Programu - Typu příspěvku (včetně filtrování, řazení)

Popis

Oblast / fáze: Přehledy

Při výběru jednoho typu projektu / typu příspěvku Webová aplikace musí zajistit zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu, ale pouze, které jsou daného typu projektu / typu příspěvku, ostatní jsou z tohoto specifického seznamu vyloučeny.

        1. Webová aplikace musí následně umožnit přejít na zobrazení detailu jednoho vybraného případu ze seznamu - dále viz separátní požadavek výše.



Kód požadavku

        1. PREH – 174

Název

        1. Vlastní úkoly - Zobrazení seznamu všech Žádostí a Konzultací, které jsou přiřazeny přihlášenému uživateli

Popis

Oblast / fáze: Přehledy

Webová aplikace musí zajistit zobrazení, řazení, filtrování seznamu všech případů, na které má uživatel právo je zobrazit, tzn. jeho vlastní případy, nebo všechny případy daného typu, ale pouze, které jsou ve vazbě pouze na daného interního uživatele referenta SFDI, ostatní jsou z tohoto specifického seznamu vyloučeny.

        1. Webová aplikace musí následně umožnit přejít na zobrazení detailu jednoho vybraného případu ze seznamu - dále viz separátní požadavek výše.



Kód požadavku

        1. MAND – 175

Název

        1. Mandáty a zastupování - Nastavení zastupování

Popis

Oblast / fáze: Mandáty a zastupování

Webová aplikace musí umožnit níže uvedené funkčnosti, přičemž je musí umožnit prostřednictvím budovaného externího a centrálního systému "Registru zastupování" vyjma případu, kdy centrální systém "Registr zastupování" nebude níže uvedené funkčnosti poskytovat:

  • Nastavení globálního zastupování

    • Nastavení globálního zastupování Klientem, včetně specifikace neomezení/omezení na vybrané operace

      • včetně CRUD operací nad tímto nastavením/těmito nastaveními

    • Nabídka a Výběr globálního zastupování Mandátem po přihlášení

  • Nastavení zastupování pro vybraný Typ akce (Program) - nastavení per Typ akce (Program), bude-li technicky a funkčně možné

    • Nastavení zastupování Klientem pro vybraný Typ akce (Program), včetně specifikace neomezení/omezení na vybrané operace

      • včetně CRUD operací nad tímto nastavením/těmito nastaveními

    • Nabídka a Výběr zastupování pro vybraný Typ akce (Program) Mandátem při práci s danou Žádostí

Možnosti nastavení zastupování budou upřesněny v rámci detailní analýzy.



Kód požadavku

        1. MAND – 176

Název

        1. Mandáty a zastupování - Ověření a výběr zastupování

Popis

Oblast / fáze: Mandáty a zastupování

Webová aplikace musí umožnit níže uvedené funkčnosti, přičemž je musí umožnit prostřednictvím budovaného externího a centrálního systému "Registru zastupování" vyjma případu, kdy centrální systém "Registr zastupování" nebude níže uvedené funkčnosti poskytovat:

  • Ověření implicitního mandátu/zastupování v ROB/ROS (včetně ověření povinného jednání více statutárních zástupců právních subjektů společně).

  • Ověření explicitního mandátu/zastupování v Mandátním registru.

Možnosti nastavení zastupování budou upřesněny v rámci detailní analýzy.



Kód požadavku

        1. ADMIN – 177

Název

        1. Šablony a vzory dokumentů - import, aktualizace

Popis

Oblast / fáze: Administrace

Webová aplikace musí umožnit iniciální technické nahrání šablon a případnou pozdější aktualizaci - vždy ve vazbě a koordinaci s verzí web formulářů. Šablony nebude možné nahrát uživatelem.



Kód požadavku

        1. ADMIN – 178

Název

        1. Nápověda - import, aktualizace

Popis

Oblast / fáze: Administrace

Webová aplikace bude umožňovat iniciální technické nahrání souborů nápovědy a případnou pozdější aktualizaci. Nápovědu nebude možné nahrát uživatelem.



Kód požadavku

ADMIN – 179

Název

        1. Číselníky - Programy - Typy příspěvků - import, aktualizace, verzování

Popis

        1. Oblast / fáze: Administrace

        2. Webová aplikace bude umožňovat iniciální technické nahrání číselníků a případnou pozdější aktualizaci. Číselníky nebude možné nahrát / změnit uživatelem.

        3. Výčet a hodnoty číselníků budou upřesněny v průběhu analýzy a implementace.



Kód požadavku

        1. ADMIN – 180

Název

        1. Globální technické nastavení

Popis

Oblast / fáze: Administrace

        1. Webová aplikace musí umožnit nastavit na počátku globální technické nastavení (např. seznam povolených příloh, maximální velikosti a počty příloh, apod.) a případně jej později změnit. Toto nastavení nebude možné uživatelsky měnit, ale změny bude možné provést pouze v rámci dalšího rozvoje aplikace technickým zásahem.



Kód požadavku

        1. POST – 181

Název

        1. Pošta - Notifikace - Vytvoření notifikace automaticky

Popis

Oblast / fáze: Pošta & Notifikace

Webová aplikace musí zajistit automatické vytvoření notifikace v případě, kdy např. dorazí nový dokument / příloha ze "Spisové evidence", nebo kdy dojde k automatické nebo manuální změně stavu, nebo kdy dojde k úspěšnému provedení vybrané operace, kterou uživatel spustil - např. "podání žádosti".

Forma zobrazení notifikace bude záviset také na jejím typu, kdy vybraný typ notifikace (např. "upozornění na validační chybu ve formuláři") bude zobrazen pouze jako "toast message", nebo jiný typ (např. "notifikace potvrzující úspěšné podání žádosti") bude zobrazena jak formou "toast message", tak i formou záznamu do seznamu notifikací k pozdějšímu prohlídnutí uživatelem přes menu notifikací, apod. Finální podoba a výčet typů a výčet notifikací bude definována v průběhu detailní analýzy.

Přesný výčet situací, kdy bude automatická notifikace vytvořena a jakého typu bude, bude předmětem detailní analýzy.



Kód požadavku

        1. POST – 182

Název

        1. Pošta - Notifikace - Zobrazení badge notifikace

Popis

Oblast / fáze: Pošta & Notifikace

Webová aplikace musí zajistit zobrazení notifikace v okamžiku jejího vzniku, nebo následně po přihlášení a otevření menu notifikací.

Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a je uživateli zobrazena pouze formou tzv. "badge" - ikony a číslovky symbolizující počet nových / nepřečtených zpráv.

Forma zobrazení notifikace bude záviset také na jejím typu, kdy vybraný typ notifikace (např. "upozornění na validační chybu ve formuláři") bude zobrazen pouze jako "toast message", nebo jiný typ (např. "notifikace potvzující úspěšné podání žádosti") bude zobrazena jak formou "toast message", tak i formou záznamu do seznamu notifikací k pozdějšímu prohlídnutí uživatelem přes menu notifikací, apod. Finální podoba a výčet typů a výčet notifikací bude definována v průběhu detailní analýzy.



Kód požadavku

POST – 183

Název

        1. Pošta - Notifikace - Zobrazení náhledu notifikací

Popis

        1. Oblast / fáze: Pošta & Notifikace

        2. Webová aplikace musí zajistit zobrazení notifikace v okamžiku jejího vzniku, nebo následně po přihlášení a otevření menu notifikací.

        3. Notifikace bude zobrazena jednak formou dočasné zprávy v případě, že je uživatel v okamžiku notifikování přihlášen a má otevřenou Webovou aplikaci, tak i je uložena do seznamu notifikací a je uživateli zobrazena pouze formou tzv. "badge" - ikony a číslovky symbolizující počet nových / nepřečtených zpráv.

        4. Webová aplikace musí zejména umožnit zobrazení notifikace v náhledu - např. posledních 5 zpráv a dočasné zobrazení poslední / aktuální notifikace.



Kód požadavku

        1. POST – 184

Název

        1. Pošta - Notifikace - Zobrazení notifikací

Popis

Oblast / fáze: Pošta & Notifikace

        1. Webová aplikace musí uživateli umožnit prohlížet si všechny notifikace formou přehledu / seznamu notifikací se stránkováním, seřazeno podle data a času vzniku notifikace - nejnovější jako první a nejstarší jako poslední.



Kód požadavku

        1. POST – 185

Název

        1. Pošta - Notifikace - Zobrazení detailu notifikace

Popis

Oblast / fáze: Pošta & Notifikace

        1. Webová aplikace musí umožnit zobrazení detailu jedné vybrané notifikace včetně jejích parametrů a plné délky zprávy notifikace.



Kód požadavku

        1. POST – 186

Název

        1. Pošta - Notifikace - Označení notifikace jako přečtené / nepřečtené

Popis

        1. Oblast / fáze: Pošta & Notifikace

        2. Webová aplikace musí umožnit automatické označení notifikace jako přečtená, pokud ji bude mít uživatel zobrazenou déle než definovaný počet vteřin, nebo pokud se zobrazí uživateli jako "toast message" definovanou dobu.

        3. Webová aplikace musí uživateli umožnit označit si notifikaci v seznamu notifikací opět jako nepřečtenou manuálně, nebo zpět jako přečtenou manuálně.



Kód požadavku

        1. USER – 187

Název

        1. User management - Nastavení profilu uživatele

Popis

Oblast / fáze: User management

Webová aplikace musí umožnit uživateli provést základní nastavení - parametry tohoto nastavení budou upřesněny v průběhu analýzy.



Kód požadavku

        1. USER – 188

Název

        1. User management - Zobrazení seznamu Mandátů Klienta

Popis

Oblast / fáze: User management

Webová aplikace musí umožnit uživateli zobrazit si seznam jeho mandátů, pro jaké subjekty má zmocnění a umožnit mu si vybrat v zástupu za jaký subjekt právě vystupuje ve Webové aplikaci.



Kód požadavku

USER – 189

Název

        1. User management - Nastavení dovolené a zástupu Uživatele SFDI a Hodnotitele

Popis

Oblast / fáze: User management

        1. Webová aplikace musí umožnit internímu uživateli SFDI nastavit si dovolenou a zástup. Pro externí uživatele není toto umožněno, u nich se nastavení zástupu provádí formou přidělení mandátu, zmocnění.



Kód požadavku

        1. USER – 190

Název

        1. User management - Vyhledání a zobrazení informace o osobě (uživatel / osoba na formuláři) pro účely GDPR, tj. veškeré informace evidované o dané osobě

Popis

Oblast / fáze: User management

        1. Webová aplikace musí internímu uživateli SFDI umožnit vyhledání osoby a zobrazení detailů o této osobě, zobrazení všech evidovaných informací pro účely GDPR.



Kód požadavku

        1. USER – 191

Název

        1. User management - Zobrazení seznamu všech uživatelů (včetně filtrování, řazení, tisku a exportu do XML/JSON, CSV, XLS, PDF)

Popis

Oblast / fáze: User management

        1. Webová aplikace musí internímu uživateli SFDI s příslušným oprávněním umožnit zobrazit seznam všech uživatelů včetně filtrování, řazení, tisku a exportu do XML/JSON, CSV, XLS, PDF.



Kód požadavku

        1. USER – 192

Název

        1. User management - Zobrazení detailu uživatele (zobrazení role, oprávnění, kontaktních a identifikačních údajů)

Popis

        1. Oblast / fáze: User management

        2. Webová aplikace musí internímu uživateli SFDI s příslušným oprávněním umožnit zobrazení detailů vybraného uživatele včetně přidělené role a oprávnění.

        3. Webová aplikace může zajistit zobrazení detailů buď prostřednictvím vlastní funkcionality a nebo prostřednictvím integrace se systémem správy uživatelských oprávnění a rolí.



Kód požadavku

        1. USER – 193

Název

        1. User management - Založení účtu Uživatele SFDI a Hodnotitele a externích uživatelů a nastavení role (definující oprávnění)

Popis

Oblast / fáze: User management

        1. Webová aplikace musí mít zajištění proces založení účtu interního uživatele SFDI a Hodnotitele, stejně tak externího uživatele, pro tento proces se předpokládá využití existujícího externího systému správy uživatelských oprávnění a rolí JIP/XXXX a integrace s tímto systémem.

        2. Postup založení uživatele a procesní a nebo technická integrace bude upřesněna v rámci detailní analýzy.



Kód požadavku

        1. USER – 194

Název

        1. User management - Editace uživatele (nastavení role (definující oprávnění), editace vybraných údajů)

Popis

Oblast / fáze: User management

        1. Webová aplikace musí mít zajištění proces nastavení role a oprávnění pro vybraného uživatele a editace vybraných údajů uživatele.

        2. Pro tento proces se předpokládá využití existujícího externího systému správy uživatelských oprávnění a rolí a integrace s tímto systémem.

        3. Postup editace údajů, rolí, oprávnění uživatele a procesní a nebo technická integrace bude upřesněna v rámci detailní analýzy.



Kód požadavku

        1. USER – 195

Název

        1. User management - Administrace, CRUD rolí a vazeb na oprávnění

Popis

Oblast / fáze: User management

        1. Webová aplikace musí umožnit technickou administraci, CRUD rolí a vazeb rolí na oprávnění, stejně tak vazeb rolí / oprávnění Webové aplikace na role v externím systému správy uživatelských rolí a uživatelů. Tato technická administrace / nastavení bude zajištěno před spuštěním systému a pak následně upravováno dle potřeby v rámci implementace dalších funkcionalit.



Kód požadavku

        1. USER – 196

Název

        1. User management - Dotažení údajů o Klientovi z registrů

Popis

Oblast / fáze: User management

        1. Webová aplikace musí zajistit průběžné dotahování aktuálních údajů o Klientovi, tj. externím uživateli z registrů XXX, ROS. Perioda aktualizace údajů bude předmětem detailní analýzy, předpokladem je pravidelná aktualizace např. při přihlášení do Webové aplikace.



Kód požadavku

        1. USER – 197

Název

        1. User management - Autentizace & Autorizace - Přihlášení Klienta, včetně ověření

Popis

Oblast / fáze: User management

        1. Webová aplikace musí umožnit uživateli přístup k funkcím Webové aplikace pouze po předchozím přihlášení, autentizaci a autorizaci.



Kód požadavku

        1. USER – 198

Název

        1. User management - Autentizace & Autorizace - Přihlášení Mandáta, včetně ověření

Popis

Oblast / fáze: User management

        1. Webová aplikace musí umožnit uživateli přístup k funkcím Webové aplikace pouze po předchozím přihlášení, autentizaci a autorizaci - včetně přihlášení Mandáta a ověření jeho zmocnění.



Kód požadavku

        1. USER – 199

Název

        1. User management - Autentizace & Autorizace - Přihlášení Uživatele SFDI, včetně ověření

Popis

Oblast / fáze: User management

        1. Webová aplikace musí umožnit uživateli přístup k funkcím Webové aplikace pouze po předchozím přihlášení, autentizaci a autorizaci - včetně přihlášení interního uživatele SFDI a ověření jeho role.



Kód požadavku

        1. USER – 200

Název

        1. User management - Autentizace & Autorizace - Přihlášení Hodnotitele, včetně ověření

Popis

Oblast / fáze: User management

        1. Webová aplikace musí umožnit uživateli přístup k funkcím Webové aplikace pouze po předchozím přihlášení, autentizaci a autorizaci - včetně přihlášení Hodnotitele.



Kód požadavku

        1. OSTA – 201

Název

        1. Obecné dotazy - Zobrazení obecných dotazů

Popis

Oblast / fáze: Ostatní požadavky

Webová aplikace musí umožnit uživateli zobrazit přehled vznesených obecných dotazů, jednak externímu uživateli jeho vlastních obecných dotazů, tak i internímu uživateli referentovi SFDI všech obecných dotazů, případně dotazů vztažených ke konkrétnímu Klientovi, případu, typu programu.



Kód požadavku

        1. OSTA – 202

Název

        1. Obecné dotazy - Zadání nového obecného dotazu

Popis

Oblast / fáze: Ostatní požadavky

Webová aplikace musí externímu uživateli umožnit zadání nového dotazu obecného bez vazby na konkrétní případ, nebo obecného ve vazbě na konkrétní případ. Obecný dotaz má formu čistě textové zprávy.



Kód požadavku

OSTA – 203

Název

        1. Obecné dotazy - Zobrazení detailu obecného dotazu

Popis

Oblast / fáze: Ostatní požadavky

        1. Webová aplikace musí umožnit uživateli zobrazení detailu jednoho vybraného obecného dotaz včetně případné informace o vazbě na případ.



Kód požadavku

        1. OSTA – 204

Název

        1. Obecné dotazy - Zadání odpovědi na obecný dotaz

Popis

Oblast / fáze: Ostatní požadavky

        1. Webová aplikace musí internímu uživateli umožnit zadání odpovědi na vybraný dotaz. Odpověď na obecný dotaz má formu čistě textové zprávy, případně URL odkazu.



Kód požadavku

        1. OSTA – 205

Název

        1. Obecné dotazy - Zobrazení detailu obecného dotazu včetně odpovědi

Popis

Oblast / fáze: Ostatní požadavky

        1. Webová aplikace musí umožnit uživateli zobrazení detailu jednoho vybraného obecného dotaz včetně případné informace o vazbě na případ a včetně odpovědi.



Kód požadavku

        1. OSTA – 206

Název

        1. Obecné dotazy - Zobrazení notifikace pro nově příchozí obecný dotaz a odpověď na obecný dotaz

Popis

Oblast / fáze: Ostatní požadavky

        1. Webová aplikace musí zajistit vytvoření, uložení a zobrazení notifikace pro nově příchozí / vytvořený obecný dotaz a novou odpověď. Vytvoření notifikace je předmětem tohoto požadavku.

        2. Zobrazení a uložení notifikace a další práce s ní je předmětem separé požadavků - viz výše.



Kód požadavku

        1. OSTA – 207

Název

        1. Zálohování a Skartace - Skartace příloh/dokumentace a dat Žádosti 6 let od stavu Žádosti "schváleno ZVA"

Popis

Oblast / fáze: Ostatní požadavky

        1. Webová aplikace musí zajistit skartaci příloh/dokumentace a dat Žádosti 6 let od stavu Žádosti "schváleno ZVA". Uvedených 6 let je předběžná lhůta, přesná lhůta bude ještě předmětem detailní analýzy, přičemž lhůta může být i 10 let. Lhůta nemá technickou vazbu na lhůty a procesy "Spisové evidence", nicméně nastavení lhůty bude odpovídat požadavkům na zálohování a skartaci.



Kód požadavku

        1. OSTA – 208

Název

        1. Zálohování a Skartace - Denní zálohování veškerých dat a dokumentace IS PORTÁLU SLŽEB SFDI

Popis

Oblast / fáze: Ostatní požadavky

        1. Webová aplikace musí zajistit denní zálohování veškerých dat a dokumentace IS PORTÁLU SLUŽEBSFDI.



Kód požadavku

        1. OSTA – 209

Název

        1. Nápověda - Zobrazení nápovědy k IS PORTÁLU SLUŽEBSFDI

Popis

Oblast / fáze: Ostatní požadavky

        1. Webová aplikace musí zajistit zobrazení nápovědy - pro celou aplikaci, např. formou zobrazení PDF souboru, nebo PDF souborů pro každou část Webové aplikace, nebo jednu celkovou nápovědu pro celou Webovou aplikaci.





    1. Obecné požadavky

Smluvní strany se dohodly, aby Poskytovatel implementoval následující obecné požadavky, kladené na IS PORTÁL SLUŽEB SFDI. Uvedené požadavky jsou pouze demonstrativním výčtem obecných požadavků na IS PORTÁL SLUŽEB SFDI.



Kód požadavku

        1. OPO – 1

        1. Název

        1. Ovládání klávesnicí

        1. Popis

        1. Veškerá funkcionalita uživatelského rozhraní musí být přístupná i v případě ovládání výhradně pomocí klávesnice, tj. pomocí klávesových zkratek. Chování používaných zkratek musí být identické v uživatelském rozhraní jako celku, tj. jedna klávesová zkratka nesmí být použita pro principiálně jiné účely podle aktuálního kontextu zobrazeného rozhraní.

Kód požadavku

OPO – 2

        1. Název

        1. Grafické zpracování

        1. Popis

        1. Grafické vyobrazení uživatelského rozhraní aplikace, sestav a výstupů bude realizováno v layoutu dle zpracovaného UX/UI prototypu připraveného Poskytovatelem a odsouhlaseného Objednatelem. UX/UI prototyp bude definovat požadovanou barevnost, fonty, povinné grafické prvky (loga, nadpisy).

Kód požadavku

OPO – 3

        1. Název

        1. Responzivní vzhled

        1. Popis

        1. Uživatelské rozhraní bude poskytovat responzivní vzhled, tj. bude se dynamicky přizpůsobovat aktuální velikosti okna, ve kterém bude uživatel pracovat tak, aby nedocházelo k nutnosti rolování okna do šířky.

Kód požadavku

OPO – 4

        1. Název

        1. Zadání nepovolených údajů

        1. Popis

        1. Logika kontroly zadání nepovolených údajů musí být kontrolována výhradně v kontextu zobrazených informací.

Kód požadavku

OPO – 5

        1. Název

        1. Zobrazování chybových hlášení

        1. Popis

        1. Hlášení o chybách uživatele vzniklých zadáním nedovoleného údaje musí být zobrazeny tak, aby byly jasně vztažené k ovládacímu prvku, v němž je údaj nutné upravit.

Kód požadavku

OPO – 6

Název

Vkládání kalendářního data

Popis

Systém bude u vstupních datumových polí umožňovat intuitivní výběr datumu z kalendáře.

Kód požadavku

OPO – 7

Název

        1. Technologie aktualizace dat v uživatelském rozhraní

Popis

        1. Uživatelské rozhraní bude realizováno s využitím konceptu asynchronní aktualizace dat. To jest aktualizace datových položek v rámci jedné obrazovky bude realizována z pohledu uživatele skrytě.

Kód požadavku

        1. OPO – 8

Název

        1. Podpora více jazyků

Popis

        1. Prezentační rozhraní nebude připraveno pro lokalizaci do více jazyků a nebude poskytovat možnost uživatelské volby jazyka při přihlášení do aplikace.

        2. Aplikace bude realizována pouze s podporou jednoho jazyka - češtiny.

Kód požadavku

        1. OPO – 9

Název

        1. Nápověda k prováděné činnosti

Popis

        1. Ke každé samostatné stránce (části) uživatelského rozhraní bude volitelně možné zobrazit nápovědu vysvětlující význam a činnost zobrazené části rozhraní, vazeb zadávaných a zobrazovaných údajů a informaci o návazných či souvisejících úkonech. Nápověda bude formou PDF souboru.

Kód požadavku

        1. OPO – 102

Název

        1. Často kladené otázky

Popis

        1. Systém musí obsahovat odkaz na aplikační podporu, aby uživateli byla poskytována informace o často kladených otázkách a odpovědích na ně (FAQ).

        2. Obsah, texty FAQ budou připraveny uživateli SFDI. A samotná aplikační podpora a FAQ budou mimo Systém, bude na ně ze Systému pouze odkazováno.

Kód požadavku

        1. OPO – 113

Název

        1. Kontaktní údaje

Popis

        1. Systém musí obsahovat odkaz na aplikační podporu, aby uživateli byla poskytována informace o relevantních kontaktech v příslušném procesu (všeobecné informace, podpora nákupu a podobně).

        2. Kontakty budou připraveny uživateli SFDI. A samotná aplikační podpora bude mimo Systém, bude na ně ze Systému pouze odkazováno.

Kód požadavku

        1. OPO – 4

Název

        1. Prediktivní zadávání textu

Popis

        1. Systém bude umožňovat funkci "našeptávače" (zrychleného prediktivního zadávání vstupních hodnot), který bude minimalizovat možnost chyb a zrychlí vládání údajů z číselníků. Funkčnost bude pro jednotlivá pole konfigurovatelná, ale bude použita pouze u číselníkových polí.

Kód požadavku

        1. OPO – 13

Název

        1. Více instancí v rámci jedné pracovní stanice

Popis

        1. Systém umožní spuštění více instancí v rámci jedné pracovní stanice, tzn. jeden uživatel může mít "Portál služeb SFDI" otevřen vícekrát na jedné pracovní stanici paralelně v samostatných oknech prohlížeče a každá taková instance Webové aplikace běží nezávisle.

Kód požadavku

        1. OPO – 14

Název

        1. Úprava uživatelského vzhledu aplikace

Popis

        1. Uživatelské rozhraní systému bude Poskytovatelem navrženo v souladu s OPO-3. Návrh uživatelského rozhraní bude součástí Analýzy a bude předložen zástupcům Objednatele ke schválení. Uživatelské rozhraní bude využívat moderní ovládací a zobrazovací prvky s cílem maximalizace uživatelské přívětivosti a ergonomie.

Kód požadavku

        1. OPO – 15

Název

        1. Podpora zabezpečení sítě

Popis

        1. Systém musí být koncipovány tak, aby síťová komunikace mezi prezentační, aplikační a databázovou vrstvou využívala výhradně protokol TCP, přičemž na straně komponenty poskytující služby (server) využívala statických, předem známých portů. Použití protokolu UDP je možné výhradně pro nezbytnou komunikaci v rámci dohledu nebo řízení (cluster heartbeat apod.). Volitelně musí umožnit použití šifrované komunikace.

        2. K zajištění ochrany integrity komunikačních sítí Poskytovatel:

        3. - Navrhne segmentaci sítě s ohledem na zajištění bezpečnosti datových toků. Návrh bude obsahovat oddělení jednotlivých vrstev aplikace, zejména pak publikační vrstvy a jednotlivá integrační rozhraní (využití třívrstvé architektury). Spolu s integrací nástrojů na ochranu integrity komunikačních sítí.

        4. - Připraví návrh a součinnostní požadavky na konfiguraci sítě (provozní, bezpečnostní a technologické parametry).

        5. - Zajistí, že logické síťové segmenty budou na úrovni datových toků prověřovány s tím, že nežádoucí komunikace bude aktivně blokována. Mimo řešení prověřování je žádoucí zajistit end-to-end šifrování datových toků souvisejících s primárními aktivy všude, kde to je možné.

        6. - Zajistí ochranu aplikace v podobě validace a filtrace vstupních dat na publikační vrstvě a stejně tak na vrstvě integrační.

        7. - Zajistí ochranu proti KBU a KBI. Cílem je zamezení volumetrického či jiného typu útoku, jejichž cílem je zamezení, nebo omezení dostupnosti aplikace.

Kód požadavku

        1. OPO – 16

Název

        1. Způsoby přihlášení Interního uživatele

Popis

        1. Interní a externí uživatel (úředník Objednatele, Žadatel, apod.) se autentizuje prostřednictvím JIP/XXXX.

        2. Zastupující uživatel (zastupující Žadatele) se autentizuje prostřednictvím NIA.

        3. Pravidla zabezpečení přenosů při přihlašování, pravidla pro bezpečnost, sílu hesla, počty pokusů pro hesla, apod. se řídí plně pravidly danými JIP/XXXX a NIA a nejsou to tudíž požadavky na Systém, jsou mimo Systém.

Kód požadavku

        1. OPO – 17

Název

        1. Správa aplikačních rolí a oprávnění

Popis

        1. Systém musí zajistit možnost správy elementárních oprávnění potřebných k prováděným činnostem ("entitlements"), a správu Aplikačních rolí (kompozitních oprávnění zahrnujících kombinaci elementárních oprávnění) a navázání na role z JIP/XXXX administrátorem aplikace a navázání na uživatele autentifikovaného prostřednictvím NIA.

Kód požadavku

OPO – 18

Název

Přístup ke službám

Popis

Všechny přístupy k poskytované službě musí být jednotné bez ohledu na to, jestli přistupuje uživatel pomocí uživatelského rozhraní nebo aplikace pomocí webové služby. Vždy je nezbytné provést ověření uživatele a jeho oprávnění přístupu k datům na základě role nebo oprávnění a provést auditní záznam o tomto přístupu (ev. zamítnutí přístupu) a činnosti, kterou s daty uživatel provádí. Každý přístup ke službě musí být jednoznačně identifikován a přiřazen ke koncovému, nebo v případě dávkových automatizovaných úloh technickému uživateli, který s daty pracuje (i v případě přístupu přes API je nutné přebírat identitu uživatele a ověřovat oprávnění).

Přístup uživatelů i jednotlivých integrací musí být limitován v závislosti na jejich funkci, tak aby uživatelská role obsahovala pouze práva nutná k vykonání definovaných aktivit.

O přístupu k službám (funkcionalitám systému) musí být veden záznam v rozsahu definovaném ve VoKB, dále typ události/činnosti; datum a čas; časové pásmo; ID uživatele; IP adresa a TCP/UDP port cílového IS; IP adresa a TCP/UDP port zdroje (uživatel/aplikace); ID rozhraní, přes které uživatel/aplikace přistupovali (uživatelské, webová služba, API, ...); výsledek autentizace (povolení/zamítnutí přístupu). V záznamu musí být do ID uživatele propsáno ID uživatele přebírané z jiného IS.

Funkcionalita vedení záznamu musí umožnit na základě změny konfigurace lokální uložení záznamu i jeho odeslání na vzdálený log systém (remote Log). Oprávnění ke změně konfigurace lokální/vzdálené logování musí být přidělitelné odděleně od správce systému.

Systém musí zajistit bezpečnost a důvěryhodnost záznamů a jejich uchování minimálně po dobu 12-ti měsíců pokud vyhláška o kybernetické bezpečnosti nestanovuje dobu delší.

Kód požadavku

OPO – 19

Název

Audit

Popis

Systém musí o sobě poskytovat informace důležité pro audit veškerých prováděných činností. Každá činnost každého uživatele musí být evidována. Auditovány jsou jak úspěšné, tak neúspěšné operace.

Záznam událostí o činnosti uživatele v auditním logu musí obsahovat zejména:

  • datum a čas; časové pásmo;

  • ID uživatele;

  • IP adresu a port cíle komunikace;

  • IP adresu a port zdroje komunikace;

  • identifikaci Interního uživatele a aplikaci nebo komponentu aplikace;

  • operace které uživatel vykonal;

  • položky se kterými uživatel pracoval.

V záznamu nesmí být ukládány datové hodnoty. Funkcionalita musí umožnit na základě změny konfigurace měnit úroveň detailu záznamu až na úroveň databázových položek, výběr logovaných operací a volbu lokální uložení záznamu nebo jeho odeslání na vzdálený log systém (IP adresa +TCP/UDP port).

Oprávnění ke změně konfigurace lokální/vzdálené logování a míra detailu musí být přidělitelné odděleně od správce systému. Výstup logů ve formátu XML/soubor v definovaném úložišti, volba formátu logu (minimální podporovaný formát je CEF).

Úložiště pro události musí zajistit integritu těchto záznamů (např. realizací elektronického podpisu apod.).

Veškeré komponenty využité v rámci řešení musí mít jednotný systémový čas, a tento čas používat i při vytváření záznamu bezpečnostních a systémových událostí.

Předmětem záznamu činností správců a administrátorů budou i veškeré činnosti prováděné v rámci správy operačního systému/middleware/virtualizační platformy (pokud bude použita).

Poskytovatel zajistí uchování auditních událostí minimálně po dobu 12 měsíců a zajistí nepopiratelnost auditních záznamů.

Kód požadavku

OPO – 20

Název

Monitoring

Popis

Systém musí poskytovat podporu pro provozní stavový monitoring na úrovni SNMP, které umožní monitorování výkonu systému.

Poskytovatel zajistí sběr a vyhodnocení provozního monitoringu.

V případě identifikovaného výpadku či nestandardního stavu z pohledu provozního monitoringu Poskytovatel zajistí informování osob pověřených administrací řešení, tak aby bylo možné defektní stav opravit v rámci SLA.

Systém musí dále poskytovat podporu pro business monitoring, ze kterého budou zřejmé vnitřní aplikační metriky systému (počet. přistupujících uživatelů, počet jednotlivých interakcí, počet podání a podobně).

Kód požadavku

OPO – 21

Název

Zálohování

Popis

Systém bude využívat zálohovací prostředky v rámci SaaS. Návrh zálohování je předmětem dodávky Poskytovatele. V rámci dodávky Poskytovatel provede funkční test obnovy.

Poskytovatel zajistí následující:

  • Pravidla a postupy zálohování

  • Pravidla a postupy dlouhodobého ukládání

  • Pravidla bezpečného zálohování a dlouhodobého ukládání informací

  • Pravidla a postupy obnovy

  • Pravidla a postupy testování zálohování a obnovy

  • Politika přístupu k zálohám, ukládaným informacím

  • Zajištění dostupnosti záloh pouze definovaným rolím

Jednotlivé zálohy spravuje a odpovídá za ně provozovatel aplikace/aplikačního celku.

V rámci zálohování a obnovy dat systém naplní požadavky na RTO = 24 hodin a RPO = 0 hodin / minut.

Kód požadavku

OPO – 22

Název

Šifrování

Popis

Systém musí poskytovat možnosti, jak zajistit šifrování komunikací a záznamů na aplikační úrovni.

Veškeré šifrování musí být konfigurovatelné na jednotlivá komunikační spojení, databázové tabulky a položky, tedy šifrování nemusí probíhat na všechna data, ale jen na ta, u kterých to bude nastaveno.

Šifrování bude prováděno pomocí aktuálně odolných kryptografických algoritmů a klíčů.

Poskytovatel zajistí používání nástroje pro správu klíčů a certifikátů, který zajistí generování, distribuci, ukládání, změny, omezení platnosti, zneplatnění certifikátů a klíčů. Zároveň zajistí a umožní auditní kontrolu.

Všechna aplikační data musí být udržována v konzistentním stavu, tj. v případě, že dojde ke konfigurační změně položky z nešifrované na šifrovanou nebo naopak, musí se tato změna promítnout na všechna data uložená v této položce off-line úlohou.

Rozsah a způsob šifrování bude stanoven v Dokumentaci IS PORTÁL SLUŽEB SFDI dle této Smlouvy.

Kód požadavku

OPO – 23

Název

Bezpečnost aplikací

Popis

Systém musí být zabezpečen proti útokům známým v době uvádění aplikací do provozu (primárně různé útoky typu injection, zneužití uploadu aj.). Poskytovatel zvolí a bude dodržovat vhodnou metodiku pro bezpečný vývoj aplikací ověřenou dobrou praxí. Poskytovatel musí zajistit provedení bezpečnostních testů před akceptačními testy a poskytnout podklady a spolupráci pro bezpečnostní testování aplikací ze strany Objednatele.

Poskytovatel zajistí provádění penetračních testů informačního a komunikačního systému se zaměřením na důležitá aktiva:

  • Při jejich uvedení do provozu

  • V souvislosti s významnou změnou, dle VoKB

Poskytovatel zajistí trvalou ochranu aplikací, informací a transakcí:

  • Neoprávněnou činností

  • Popřením provedených činností

Poskytovatel zajistí dostupnost aplikace a její odolnost proti KBU a KBI cílících na zamezení nebo omezení dostupnosti aplikace. Bezpečnost aplikací musí být v souladu s VoKB.

Kód požadavku

OPO – 24

Název

Řízení aktiv

Popis

Poskytovatel v rámci řízení primárních i podpůrných aktiv zajistí naplnění požadavků Vyhlášky o kybernetické bezpečnosti č. 82/2018 Sb. (dále „VoKB“).

V rámci procesu řízení aktiv Poskytovatel zajistí, provede a zdokumentuje zejména následující činnosti, jež budou v souladu s požadavky ZoKB, resp. Vyhlášky o kybernetické bezpečnosti č. 82/2018 Sb. (dále „VoKB“):

  • vypracuje metodiku pro identifikaci aktiv,

  • stanoví metodiku pro hodnocení aktiv alespoň v rozsahu uvedeném v příloze č. 1 k této VoKB,

  • formálně identifikuje, eviduje a klasifikuje veškerá primární a podpůrná aktiva,

  • identifikuje, určí a eviduje garanty primárních a podpůrných aktiv,

  • hodnotí a eviduje primární aktiva z hlediska důvěrnosti, integrity a dostupnosti a zařadí je do jednotlivých úrovní podle písmene b), o čtyřech úrovních a posuzuje, jaký dopad by mělo narušení bezpečnosti informací u jednotlivých aktiv,

  • určí a eviduje vazby a závislosti mezi primárními a podpůrnými aktivy a hodnotí důsledky závislostí mezi primárními a podpůrnými aktivy,

  • hodnotí podpůrná aktiva a zohledňuje přitom zejména vzájemné závislosti,

  • na základě hodnocení aktiv stanovuje a zavádí pravidla ochrany nutná pro zabezpečení jednotlivých úrovní aktiv,

  • stanoví přípustné způsoby používání aktiv, informací v jakékoliv podobě, a pravidla pro manipulaci s aktivy s ohledem na klasifikaci a úroveň aktiv, včetně pravidel pro bezpečné elektronické sdílení a fyzické přenášení aktiv, a

  • definuje požadavky a způsob likvidace dat, provozních údajů, informací a jejich kopií nebo likvidaci technických nosičů dat s ohledem na úroveň aktiv v souladu s přílohou č. 4 k této VoKB.

Při hodnocení důležitosti primárních aktiv posoudí alespoň:

  • rozsah a důležitost osobních údajů, zvláštních kategorií osobních údajů nebo obchodního tajemství,

  • rozsah dotčených právních povinností nebo jiných závazků,

  • rozsah narušení vnitřních řídicích a kontrolních činností,

  • poškození veřejných, obchodních nebo ekonomických zájmů a možné finanční ztráty,

  • dopady na poskytování důležitých služeb,

  • rozsah narušení běžných činností,

  • dopady na zachování dobrého jména nebo ochranu dobré pověsti,

  • dopady na bezpečnost a zdraví osob,

  • dopady na mezinárodní vztahy a

  • dopady na uživatele informačního a komunikačního systému.

Poskytovatel provede posouzení a hodnocení dopadů na narušení bezpečnosti informací v souladu s dokumentem NUKIB „METODIKA K VODÍTKŮM PRO HODNOCENÍ DOPADŮ“. Dokument je dostupný na webu xxxxx://xxx.xxxxxxx.xx/xx/xxxxxxxx-x-xxxxxxxx/xxxxxxxx-xxxxxxxxx/

Poskytovatel musí zohlednit pravidla pro likvidaci dat a musí být aplikována přiměřeně hodnotě a důležitosti aktiv a měla by zejména zohledňovat:

  • hodnotu aktiva (zejména z pohledu důvěrnosti),

  • technologii (typy a velikost nosičů informace),

  • zda se nosič informace nachází pod kontrolou organizace či nikoliv,

  • zda jsou data součástí dedikovaného nebo multitenantního prostředí,

  • kdo bude likvidaci dat provádět (interní zaměstnanec, nebo dodavatel),

  • dostupnost vybavení a nástrojů pro likvidaci,

  • kapacitu likvidovaných nosičů,

  • zda je k dispozici vyškolený personál,

  • časovou náročnost likvidace,

  • cenu likvidace s ohledem na nástroje, školení, validaci, opětovné využití nosiče informace

  • možné způsoby likvidace dat (například zničením nosiče, několikanásobným přepsáním nosiče dat, znečitelněním dat jejich šifrováním a podobně),

  • použitelné způsoby likvidace dat vzhledem ke stavu nosiče informace (například při poškození zařízení nebude možné použít variantu přepisu informace, ale některý ze způsobů fyzické likvidace).

Poskytovatel aplikuje způsoby likvidace všech technických nosičů informace, provozních údajů, dat, informací a jejich kopií v souladu s požadavky VoKB – Likvidace dat, Příloha č. 4, podle požadavků pro tzv. Přípustný způsob likvidace podle úrovně důležitosti aktiva a typu nosiče informace.

Způsoby likvidace:

  • Odstranění – Použitelný způsob pro úroveň důvěrnosti aktiva (vychází z přílohy č. 1): nízká

  • Přepsání – Použitelný způsob pro úroveň důvěrnosti aktiva (vychází z přílohy č. 1): nízká až kritická

  • Fyzická likvidace nosiče informace – Použitelný způsob likvidace pro úroveň důvěrnosti aktiva (vychází z přílohy č. 1): střední až kritická

Tento požadavek a způsoby likvidace dat a informací a nosičů informací se vztahuje na všechna produkční, provozní a testovací data a informace použitá pro testování funkčnosti IS PORTÁL SLUŽEB SFDI, včetně použitých nosičů informací a uložených dat na těchto nosičích.

Kód požadavku

OPO – 25

Název

Kontinuita činností

Popis

Poskytovatel v rámci řízení kontinuity činností provede činnosti a zpracuje dokumentaci, které jsou vyžadovány VoKB pro zajištění kontinuity činností. Poskytovatel připraví postupy, a scénáře, a zajistí zvládání krizových situací a rychlou obnovu IS PORTÁL SLUŽEB SFDI v případě narušení kontinuity činností.

Poskytovatel v rámci řízení a zajištění kontinuity činností organizace rovněž vypracuje související zejména procesy, jež jsou neoddělitelnou součástí procesu řízení kontinuity:

  • proces a postupy pro řízení a zvládání incidentů (incident management),

  • proces zálohování a obnovy dat a informací, zahrnující testování čitelnosti a použitelnosti zálohovaných dat v případě potřeby, včetně popisu podpůrných technických aktiv / nezbytné infrastruktury, a zahrnuje rovněž zálohování systémových a bezpečnostních parametrů, nastavení a konfigurací pro účel obnovy

  • proces pro řízení změn a konfigurací,

  • proces řízení přístupů a oprávnění v rámci procesu řízení kontinuity činností

Kód požadavku

OPO – 26

Název

Řízení rizik

Popis

Poskytovatel zajistí aktivní spolupráci a součinnost při provedení analýzy rizik (identifikace primárních a podpůrných a technických aktiv, identifikace vazeb na primární aktiva, ohodnocení hrozeb a zranitelností podpůrných a technických aktiv), monitorování, reakce a zvládání rizik, zpracování plánu zvládání rizik (návrh technických a organizačních opatření), zpracování prohlášení o aplikovatelnosti, včetně zpracování zprávy o hodnocení aktiv a rizik v oblasti předmětu dodávky.

Řízením a hodnocením rizik se rozumí celkový proces řízení rizik v organizaci jako celku, identifikace, analýzy, vyhodnocení, reakce na rizika a incidenty, řízení přístupů a změn, zavedení opatření pro ošetření a zvládání rizik, dodržování bezpečnostních politik a stanovených zásad a pravidel pro řízení systému bezpečnosti informací, tj. zejména naplnění a splnění požadavků uvedených v tomto dokumentu, v jednotlivých bodech, a v dalších detailních požadavcích uvedených ve VoKB.

Proces řízení rizik zahrnuje vybudování vhodné infrastruktury a použití logického a systematického postupu ke zjištění souvislostí, identifikaci, analýze, vyhodnocení, zvládání, sledování a hlášení rizik spojených s libovolnou činností, postupem nebo funkcí takovým způsobem, který dovolí minimalizovat ztráty a maximalizovat zisky.  Jedná se o postupný, neustále se opakující proces zlepšování.

Xxxxxxx je maximálně předcházet jakýmkoliv bezpečnostním ohrožením, narušení bezpečnosti informací a aktiv, incidentům, neočekávaným událostem, zajistit efektivní řízení rizik a bezpečnost informací a informačních a komunikačních technologií v souladu s požadavky VoKB.

Poskytovatel dodá podklady v následujícím minimálním rozsahu podle požadavků uvedených ve VoKB, zejména:

  • podklady pro provedení analýzy rizik a přípravu zprávy o hodnocení aktiv a rizik

  • přehled a evidence primárních a podpůrných aktiv

  • identifikace a popis podpůrných aktiv,

  • určení garantů primárních a podpůrných aktiv,

  • určení vazeb mezi primárními a podpůrnými aktivy,

  • identifikování a hodnocení rizik,

  • hodnocení existujících hrozeb,

  • hodnocení existujících zranitelností, hodnocení existujících opatření (aplikovaných v IS nebo dodávaných službách),

  • podklady pro plán zvládání rizik,

  • obsah a cíle vybraných bezpečnostních opatření pro zvládání rizik včetně vazby na konkrétní rizika,

  • definici opatření – popis návrhu a způsobu opatření, jež vede k ošetření a zvládání rizik,

  • potřebné zdroje (lidské a finanční) pro jednotlivá bezpečnostní opatření pro zvládání rizik vyhodnocených v rámci analýzy rizik,

  • odpovědnost osoby (funkční role) za opatření v plánu zvládání rizik; osoby zajišťující jednotlivá bezpečnostní opatření pro zvládání rizik,

  • termíny zavedení jednotlivých bezpečnostních opatření pro zvládání rizik,

  • způsob realizace bezpečnostních opatření,

  • způsoby hodnocení úspěšnosti zavedení jednotlivých bezpečnostních opatření pro zvládání rizik,

  • podklady pro Prohlášení o aplikovatelnosti,

  • přehled zavedených bezpečnostních opatření,

  • přehled vyloučených bezpečnostních opatření požadovaných touto vyhláškou včetně zdůvodnění, proč nebyla aplikována,

  • přehled zavedených bezpečnostních opatření včetně způsobu jejich implementace,

  • vytvořená bezpečnostní a provozní dokumentace (Politiky, postupy, směrnice, pravidla, procedury) pro naplnění požadavků,

  • zpráva o hodnocení aktiv a rizik.

Kód požadavku

OPO – 27

Název

Bezpečnostní role

Popis

Poskytovatel zajistí v rámci organizace řízení bezpečnosti informací vytvoření, jmenování a obsazení bezpečnostních a provozních rolí a orgánu, jejich pravidelné odborné školení dle typu zastávané role a výkonu povinností rolí zejména dle aktuálního znění ZoKB a VoKB o kybernetické bezpečnosti a dalších rolí pro zajištění řízení kybernetické bezpečnosti a zároveň bezpečnosti a provozu systému:

  • Výbor pro řízení kybernetické bezpečnosti,

  • Manažer kybernetické bezpečnosti,

  • Architekt kybernetické bezpečnosti,

  • Garant aktiva,

  • Auditor kybernetické bezpečnosti,

  • Incident manažer,

  • Manažer pro řízení a koordinaci změn v rámci ICT prostředí,

  • Manažer bezpečnostního vzdělávání,

  • CSIRT Administrátor / Operátor (analýza a vyhodnocování a reakce na bezpečnostní incidenty v rámci ICT a systému IS PORTÁL SLUŽEB SFDI),

  • Administrátor – bezpečnostní správce (IS, aplikace, DB, …).

Kód požadavku

OPO – 28

Název

Bezpečnost testovacích dat

Popis

Poskytovatel zajistí bezpečnost vývojového a testovacího prostředí a ochranu používaných testovacích dat.

Varianta 1: Pro testovací prostředí jsou použita anonymizovaná data z produkčního prostředí. Anonymizace dat musí probíhat takovým způsobem, aby nebylo možné data reverzním postupem deanonymizovat.

Varianta 2: Testovací prostředí obsahuje data z produkčního systému. Pro tuto variantu je nutné zajistit stejná pravidla fungování jako pro produkční prostředí. Tedy řízený přístup k prostředí, šifrování, auditing. Práce s prostředím podléhá stejným postupům jako v případě produkčního prostředí. Jedinou výjimku tvoří dostupnost systému.

Testovací prostředí slouží jako UAT, obsahuje tedy stejné aplikační vybavení a stejná nastavení jako produkční systém a bude primárně využíván k testování a akceptaci rozvojových aktivit/změn v rámci aplikace. Testovací prostředí neslouží k samotnému vývoji aplikace.

Kód požadavku

OPO – 29

Název

Bezpečnostní testování změn

Popis

Poskytovatel zajistí provádění penetračních testů informačního a komunikačního systému se zaměřením na důležitá aktiva:

  • Při jejich uvedení do provozu

  • V souvislosti s významnou změnou, dle VoKB

Penetrační testování se týká jak aplikace samotné, tak související infrastruktury, v případě provádění významných změn.

Kód požadavku

OPO – 30

Název

Bezpečnostní dokumentace

Popis

Poskytovatel zajistí zpracování, resp. vytvoření a implementování bezpečnostní a provozní dokumentace v souladu s požadavky ZoKB a VoKB, zejména podle požadavků uvedených v příloze č. 5, k této VoKB.

Dokumentace bude pravidelně revidovaná a aktualizovaná odpovědnými Garanty aktiv příp. odpovědnými osobami za jednotlivé oblasti a dokumentaci.

Provozní bezpečnostní dokumentace je zpracována na základě výsledků analýzy rizik, popisuje organizační a technická opatření k pokrytí identifikovaných rizik v souladu se strategií zvládání rizik Objednatele.

Provozní bezpečnostní dokumentace předepisuje činnost bezpečnostních správců informačního systému v jednotlivých rolích, zavedených pro zajištění zabezpečené správy informačního systému.

Bezpečnostní dokumentace musí obsahovat všechny relevantní oblasti bezpečnosti informací vyžadované VoKB, a/ nebo vyplývající z výsledků analýzy rizik.

Struktura a obsah bezpečnostní dokumentace musí vycházet ze struktury dokumentace pro bezpečnostní politiky a další bezpečnostní dokumentace uvedené v příloze č. 5 VoKB.

Součástí Provozní bezpečnostní dokumentace jsou následující dokumenty:

  • Evidence aktiv IS PORTÁL SLUŽEB SFDI,

  • Identifikace, hodnocení a evidence primárních a podpůrných aktiv,

  • určení a evidence jednotlivých primárních a podpůrných aktiv včetně určení jejich garantů,

  • určení vazeb a závislostí mezi primárními a podpůrnými aktivy.

Poskytovatel zajistí vytvoření bezpečnostních politik (BP), příp. jedné BP, jež bude obsahovat tyto bezpečnostní politiky podle požadavku VoKB:

  • Politika systému řízení bezpečnosti informací,

  • Politika řízení aktiv

  • Politika organizační bezpečnosti

  • Politika řízení rizik

  • Politika řízení změn

  • Politika řízení dodavatelů

  • Politika bezpečnosti lidských zdrojů

  • Politika řízení provozu a komunikací

  • Politika řízení přístupu

  • Politika bezpečného chování uživatelů

  • Politika zálohování a obnovy a dlouhodobého ukládání

  • Politika bezpečného předávání a výměny informací

  • Politika řízení technických zranitelností

  • Politika akvizice, vývoje a údržby

  • Politika ochrany osobních údajů

  • Politika fyzické bezpečnosti

  • Politika bezpečnosti komunikační sítě

  • Politika ochrany před škodlivým kódem

  • Politika nasazení a používání nástroje pro detekci kybernetických bezpečnostních událostí

  • Politika využití a údržby nástroje pro sběr a vyhodnocení kybernetických bezpečnostních událostí

  • Politika zvládání kybernetických bezpečnostních incidentů

  • Politika bezpečného používání kryptografické ochrany

  • Politika řízení kontinuity činností

Poskytovatel zajistí vytvoření navazujících bezpečnostních a provozních pravidel a postupů pro zajištění bezpečnosti a provozu podle požadavků ZoKB/ VoKB.

Kód požadavku

OPO – 31

Název

Bezpečnostní kontroly a audity

Popis

Poskytovatel zajistí provedení nezávislého auditu a kontrolu naplnění bezpečnostních požadavků a dodržování bezpečnosti informací interním auditem organizace (SFDI) nebo třetí stranou v rámci implementace a provozu systému, jež zahrnuje následující činnosti:

  • před uvedením systému do provozu zajistí provedení auditu a jeho zdokumentování za účelem posouzení a ověření implementace systému v souladu s definovanými bezpečnostními požadavky a jejich naplnění, dodržování bezpečnostní politiky, včetně přezkoumání technické shody, a výsledky auditu zohlední v plánu rozvoje bezpečnostního povědomí a plánu zvládání rizik, dále

  • posuzuje soulad bezpečnostních opatření s nejlepší praxí, právními předpisy, vnitřními předpisy, jinými předpisy a smluvními závazky vztahujícími se k informačnímu a komunikačnímu systému a určí případná nápravná opatření pro zajištění souladu,

  • provádí vždy audit a posouzení rizik při významných změnách, v rámci jejich rozsahu za účelem řízení rizik a ověření funkčnosti této změny, nebo negativních účinků této změny, s tím, že nebyly zrušeny nebo zmírněny stávající kontrolní mechanismy a opatření před zavedením změny, dále změna nemá negativní dopad na existují funkčnost, bezpečnost a stabilitu systému, testovaná změna v testovacím prostředí systému umožnuje jen takovou funkčnost, která byla požadovaná,

  • zajistí, že každá taková významná změna je dokumentovaná, testovaná, posouzena formou analýzy rizik a schválená před tím, než je implementovaná do produkčního systému,

  • provádí vždy testování nových změn s bezpečnostními aspekty a eliminaci negativních dopadů na stávající informační prostředí, funkčnost a stabilitu systému organizace, za účelem nasazení do produkčního prostředí

  • zajistí dodržování implementovaných pravidel a postupů pro nasazení programového vybavení a změn a jeho evidence

  • provádí pravidelné testování zranitelností systému a řešení oprav či případných work-aroundů k eliminaci zranitelností a snížení dopadů z působení hrozeb tyto zranitelnosti využívající,

  • poskytuje aktivní a nezbytnou součinnost pro přípravu programu a plánu bezpečnostních auditů a realizaci auditů dle plánu, v rámci samotného auditu kybernetické bezpečnosti, a pro následnou implementaci opatření k vyřešení identifikovaných zjištění a ošetření a redukci identifikovaných rizik,

  • provádí provozní monitoring činnosti systému a infrastruktury, identifikuje potenciální nebo vzniklé nedostatky, zranitelnosti nebo hrozby a kontinuálně přijímá opatření a implementuje opatření ke zlepšení a zajištění bezpečnosti informací a dat a celého systému,

  • zajištuje realizaci a naplnění dodržování bezpečnostních politik, požadavků a stanovených pravidel či zásad stanovených ve VoKB a v Bezpečnostní politice organizace pro řízení bezpečnosti informací, a sjednává bez zbytečného prodlení úkony a opatření, která vedou k eliminaci nebo odstranění identifikovaných nedostatků nebo rizik pro bezpečnost a stabilitu provozu systému, dat a související infrastruktury,

  • implementuje a využívá nástroje pro detekci, sběr a vyhodnocování kybernetických bezpečnostních událostí,

  • zajistí spolupráci a provedení auditu kybernetické bezpečnosti u informačního a komunikačního systému podle požadavků VoKB a to min. 1 x ročně, příp. častěji, včetně ad-hoc auditů podle specifických požadavků organizace pro vybrané a určené oblasti, procesy a ICT infrastrukturu,

  • provádí vlastní provozní kontroly a hodnocení dodržování stanovených bezpečnostních a smluvních požadavků formou tzv. samostatného vyhodnocení, v rámci vlastního interně zavedeného kontrolního rámce, jež je však v souladu s požadavky VoKB (příp. ISMS) a reportuje organizaci na týdenní úrovni, formou reportu, výsledky dodržování bezpečnostních politik, požadavků, pravidel a ujednání, úrovní služeb, (SLA), identifikovaných a vyřešených incidentů dle závažnosti a dopadu na organizaci a bezpečnost informací a dopadu na ochranu osobních údajů, včetně přehled změn a významných změn implementovaných do systému

Kód požadavku

OPO – 32

Název

Legislativa

Popis

Poskytovatel zajistí naplnění všech relevantních technických a organizačních požadavků stanovených zákonem č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti - ZoKB), vyhláškou 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti - VoKB) v rozsahu platném pro informační systém významné informační infrastruktury.

Poskytovatel zajistí soulad s požadavky s Nařízením (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů) - GDPR.

Kód požadavku

OPO – 33

Název

Součinnost při integraci

Popis

Poskytovatel bude poskytovat součinnost zástupcům okolních systémů (cílovým i integračním), kteří budou konzumovat jím vystavené API.

Kód požadavku

OPO – 34

Název

Integrace na další systémy Objednatele

Popis

Systém musí být integrován na další nezbytné systémy Objednatele, jako např. (spisová služba, agendový informační systém IS Evidence a podobně)

Kód požadavku

OPO – 35

Název

Rozhraní systému

Popis

Komponenty budou mít dokumentovaná všechna vystavovaná API (DB rozhraní, rozhraní webových služeb, souborová rozhraní). API bude zprostředkováno na základě otevřeného standardu.

Kód požadavku

OPO – 36

Název

Evidence rozhraní

Popis

Poskytovatel bude pravidelně aktualizovat přehled a popis poskytovaných rozhraní Systému (u všech prostředí).

Kód požadavku

OPO – 37

Název

Škálovatelnost

Popis

Systém musí být horizontálně a vertikálně škálovatelný ve všech vrstvách.

Kód požadavku

OPO – 38

Název

Počet uživatelů

Popis

Systém musí být připraven obsloužit 1000 koncových Uživatelů.

Kód požadavku

OPO – 39

Název

Doby odezvy

Popis

Odezvy Systému nesmí překročit hodnoty uvedené v Příloze č.2 této Smlouvy.

Kód požadavku

OPO – 40

Název

Souběžná práce

Popis

Systém musí minimalizovat používání zámků v aplikaci i DB a musí využívat zámky jen v nezbytně nutné míře a na položky tak, aby garantoval souběžnou práci uživatelů Systému.

Kód požadavku

OPO – 41

Název

Ověřování výkonnosti

Popis

Poskytovatel musí provést výkonnostní a zátěžové testy a poskytnout podklady a součinnost pro výkonnostní a zátěžové testování Systému třetí stranou. Objednatel může zátěžové testování prováděné třetí stranou opakovat v průběhu provozu v minimálním intervalu 6 měsíců, zjištěné negativní odchylky od požadované výkonnosti jsou incidentem s kategorií priority SEV3 – Nízká.

Kód požadavku

OPO – 42

Název

Kapacitní požadavky

Popis

Systém musí být připraven zpracovat 30 požadavků (např. rezervace konzultace, nebo podání žádosti) za jednu minutu.

Kód požadavku

OPO – 43

Název

Mazání dat

Popis

Systém musí zajistit řádný výmaz archivovaných dat, která překročí archivační lhůtu danou zákonem.

Kód požadavku

OPO – 44

Název

Provoz Systému

Popis

Systém bude primárně zajišťovat on-line práci koncových uživatelů podle požadavků na výkonnost a dostupnost aplikace. Některé funkcionality mohou být řešeny jako dávkové úlohy (např. generování tisků, synchronizace dat do jiných systémů, exporty dat, archivace a podobně). Tyto dávkové úlohy bude možné plánovat na libovolný čas a budou probíhat nezávisle na on-line systémech tak, aby jejich činnost neovlivnila výkonnost systému.

Kód požadavku

OPO – 45

Název

Architektura

Popis

Komponenty budou realizovány v třívrstvé architektuře. Budou využívat oddělenou databázi a aplikační server, ty budou umístěny odděleně v datové a aplikační vrstvě.

Kód požadavku

OPO – 46

Název

Architektura obsluhy požadavku

Popis

Obsluha uživatelského požadavku bude primárně umístěna v aplikační vrstvě.

Kód požadavku

OPO – 47

Název

Návrh implementace

Popis

Komponenty budou škálovatelné a budou mít vysokou dostupnost bez ztráty kontextu a dat v případě výpadku.

Neuzavřené / nepotvrzené transakce mohou být ztraceny s tím, že uživatel bude upozorněn na nedokončenou aktivitu a vyzván k jejímu opakování.

Kód požadavku

OPO – 48

Název

Ukládání strukturovaných dat

Popis

Komponenty budou ukládat zpracovávaná strukturovaná data v relačním databázovém systému.

Kód požadavku

OPO – 49

Název

Práce s databází

Popis

Komponenty musí přistupovat k databázi výhradně prostřednictvím aplikačního serveru.

Kód požadavku

OPO – 50

Název

Paralelní zpracování

Popis

Prezentační a aplikační logiky budou realizovány s využitím souběžného zpracování požadavků (volání) více vlákny (multi-threading).

Kód požadavku

OPO – 51

Název

Datová vrstva

Popis

Data budou primárně uložena v databázi (SQL server). Mimo databáze mohou být ukládána pouze data určená pro archivaci - specifické úložiště, auditní a monitorovací účely - do souborů umístěných v souborovém systému a dokumenty umístěné ve společném (dokumentovém) úložišti.

Kód požadavku

OPO – 52

Název

Databáze

Popis

Komponenty budou používat databáze as a Service v rámci prostředí SaaS.

Kód požadavku

OPO – 53

Název

Aplikační vrstva

Popis

Pro aplikační vrstvu budou zvoleny takové technologie, které budou zajišťovat vysokou dostupnost (aplikační clustering) bez ztráty session v případě výpadku a škálovatelnost.

Kód požadavku

OPO – 54

Název

Provozní prostředí

Popis

Komponenty budou provozovány v Produkčním, Testovacím prostředí a Vývojovém prostředí. Testovací a Vývojové prostředí může disponovat nižším požadovaným výkonem, ale musí mít stejnou topologii jako produkční prostředí.

Kód požadavku

OPO – 55

Název

Administrace

Popis

Komponenty musí mít administrační rozhraní pro správu parametrů Systému konfigurací, správu potřebných workflow, správu úloh (jobů) a jejich plánování (archivace, generování výstupných sestav, přenos dat do jiných systémů aj.), správu integračních rozhraní umožňujících konfigurovat API na další systémy, správu reportů (template reportů).

Administrace nebude prováděna uživatelským přístupem přes front-end Webové aplikace, ale technickým zásahem odborným zástupcem Poskytovatele na základě změnového požadavku, bude-li se jednat o změnu dle pokynů Objednatele.

Kód požadavku

OPO – 56

Název

Kódování znaků

Popis

Kódování znaků bude UTF-8.

Kód požadavku

OPO – 57

Název

Export a import dat

Popis

Komponenty budou poskytovat možnost pro snadný export dat na základě příslušného oprávnění podle zadaných kritérií. Komponenty budou podporovat pouze ty výstupní exportní formáty, které jsou uvedeny přímo u vybraných funkčních požadavků v kapitole 2.5 této Přílohy č. 1.

Kód požadavku

OPO – 58

Název

Připravenost na modifikace

Popis

Komponenty musí být realizovány modulárním způsobem tak, aby v případě změn byly jasně identifikovány moduly dotčené změnou. V případě provedení změn ve funkcionalitě musí být zajištěno korektní dokončení běžících funkcí a procesů v předchozích verzí modifikované funkcionality, pokud není uvedeno v požadavcích jinak.

Kód požadavku

OPO – 59

Název

Načítání dat

Popis

Načítání dat uživatelem bude prováděno vzhledem k serverové straně jednotným protokolem, bude obsahovat kompletní obchodní funkcionalitu, bude bez stavové a bude rovněž jednotně a samostatně dokumentované.

Kód požadavku

OPO – 60

Název

Statické části

Popis

Statické části Systému, zejména grafické prvky (statické obrázky, kaskádové styly, Javascript apod.), budou odděleny.

Kód požadavku

OPO – 61

Název

Testovací scénáře

Popis

Pro potřeby provedení testů v rámci akceptace díla připraví Poskytovatel Testovací Plán. Poskytovatel připraví do testovacího prostředí sadu testovacích scénářů včetně testovacích dat vážících se ke každému z implementovaných případů. Testovací scénáře budou odrážet business model IS PORTÁL SLUŽEB SFDI. Před každým kolem testů připraví Poskytovatel pro každý použitý testovací scénář testovací data v samotné aplikaci a v navázaných systémech. Provedení testů v rámci akceptace bude na základě připravených scénářů a dat realizovat Objednatel či jím pověřená třetí strana. Případné chyby nalezené při testování je Poskytovatel povinen na své náklady odstranit. Popis a řízení odstranění chyby (bug tracking) je prováděn v prostředí Objednatele.

Kód požadavku

OPO – 62

Název

Testovací skripty

Popis

Pro každý z testovacích scénářů připraví Poskytovatel automatizovaný skript, který umožní opakované, automatické provádění testů. Pokud za tímto účelem Poskytovatel použije komerční produkt, bude licence dostatečná k provedení testů dodána a převedena na Objednatele v rámci plnění.

Kód požadavku

OPO – 63

Název

Bezpečnostní testy

Popis

Poskytovatel poskytne nezbytnou součinnost odborné třetí straně pro provedení bezpečnostních testů (penetrační testy, testy zabezpečení uživatelského rozhraní, testy ochrany údajů, testy havarijních scénářů).

Pokud budou na základě testů identifikována bezpečnostní rizika v důsledku plnění Poskytovatele, je povinen je na své náklady eliminovat. Zároveň je povinen doplnit související dokumentaci, pokud se ukáže jako nedostatečná v rámci bezpečnostních testů. Bezpečnostní problém vyplývající z testů se považuje za incident s kategorií priority SEV2 – Významná.

Kód požadavku

OPO – 64

Název

Výkonnostní testy

Popis

Poskytovatel poskytne nezbytnou součinnost odborné třetí straně pro provedení výkonnostních (zátěžových) testů. Pokud bude na základě testů identifikováno chování systémů přinášející výkonnostní rizika v důsledku plnění Poskytovatele nebo neplnění požadované doby odezvy, je povinen je na své náklady odstranit.

Kód požadavku

OPO – 65

Název

Metodika vývoje

Popis

V rámci Analýzy představí Poskytovatel metodiku vývoje a skladbu vývojových týmů.

Kód požadavku

OPO – 66

Název

Zásady vývoje

Popis

Při modelování je nutné zajistit dodržování jmenných konvencí, obecných zásad pro čitelnost a srozumitelnost a také dodržování pravidelného verzování modelů.

Kód požadavku

OPO – 67

Název

Zdrojové kódy

Popis

Poskytovatel předá s každou novou verzí aplikace zdrojové kódy a související konfigurační soubory k veškerému softwarovému vybavení, které vytvořil v rámci plnění. Zdrojové kódy budou předány podle podmínek určených v této Smlouvě.

Kód požadavku

OPO – 68

Xxxxx

Xxxxxxx projektu

Popis

Poskytovatel je povinen poskytovat součinnost při kontrole kvality projektu ze strany Objednatele nebo jím určené třetí strany. Objednatel je oprávněn na vyžádání provést kontrolu stavu prací Poskytovatele, a to ve všech fázích projektu. Poskytovatel je povinen na vyžádání umožnit Objednateli náhled do prostředí týkajícího se realizovaného projektu, nahlédnout na veškeré zpracovávané výstupy, i když nejsou předmětem předání, představit Objednateli jednotlivé pracovníky účastnící se dodávky předmětu plnění a umožnit Objednateli pokládat těmto pracovníkům otázky ve vztahu ke kontrole plnění Poskytovatele.

Kód požadavku

OPO – 69

Název

Záznamy o kontrole kvality

Popis

Objednatel nebo jím určená třetí strana vytvoří po každé kontrole kvality projektu záznam o kontrole kvality, se kterým bude seznámen řídící výbor projektu. Záznam bude evidován jako výstup jednání řídícího výboru. Nedostatky uvedené v záznamu o kontrole kvality je Poskytovatel povinen odstranit v dohodnutých termínech.

Kód požadavku

OPO – 70

Název

Projektová dokumentace

Popis

Poskytovatel musí v průběhu projektu vést projektovou dokumentaci.

Kód požadavku

OPO – 71

Název

Akceptace dokumentace

Popis

Akceptace dokumentů předávaných Poskytovatelem v rámci plnění projektu se bude řídit akceptační procedurou uvedenou ve znění návrhu Smlouvy.

Kód požadavku

OPO – 72

Název

Implementace požadavků bezpečnostních složek

Popis

Objednatel po Poskytovateli požaduje implementaci IS PORTÁL SLUŽEB SFDI v souladu a rozsahu s metodikami a požadavky bezpečnostních složek, které mohou být vůči Objednateli uplatněny a mohou být předmětem utajení informací.





  1. provoz IS PORTÁL SLUŽEB SFDI vč. zajištění služeb systémové integrace

    1. Popis jednotlivých komponent

IS PORTÁL SLUŽEB SFDI bude využívat pro svůj chod cloudovou platformu MS Azure, na základě přistoupení Poskytovatele CENDIS, s.p. k Rámcové dohodě na pořizování produktů Microsoft (MV- 89474-64/VZ2021) uzavřenou dne 28.4.2022, v rámci centrálního zadávání.

Obsahem budou 3 běhová prostředí (DEV, TEST, PROD), včetně sdíleného prostředí.

Specifikace infrastruktury:

Sdílené prostředí (SHARED) – nedílná součást jádra, která je potřebná pro chod všech běhových prostředí

Typ komponenty (služby)

Popis

Azure DevOps uživatelé

19 uživatelů s licencí na plán Basic

Azure DevOps pipelines

3 časově neomezené paralelní CI/CD úlohy

Visual Studio Professional uživatelé

3 uživatelé s licencí na plán Visual Studio Professional

XxxXxxxx pokročilé klíče v HSM

4 klíče v HSM úložišti KeyVault Premium SKU, 1000 základní a 10 000 pokročilých operací

Azure DNS - zóny

Hostování 2 veřejných DNS zón v rámci Azure DNS (1 milion query)

Azure DNS - zóny (i private linky)

Hostování 2 privátních DNS zón v rámci Azure DNS (1 milion query)

Azure Front Door

Classic SKU, 1TB příchozích dat, 0,5TB odchozích dat, 9 routovacích pravidel, 5x WAF (Web Application Firewall), 3x Vlastní pravidla

App Gateway

2x Standard V2 SKU, Produkční prostředí 2 výpočetní jednotky, DevTest prostředí 1 výpočetní jednotka, 500GB odchozích dat

Azure Firewall

Standard SKU, 744 hodin provozu, 2,5TB přenesených dat

Storage account – certifikáty

Standard V2 – podpůrná blob storage pro automatické generování certifikátů

Storage account - logování

Standard V2 – blob storage pro dlouhodobé logy, COOL tier, redundance LRS, 3TB dat, 10 milionů zápisů, 5 milionů listování dat, 1 milion čtení, 1 milion dalších operací, 100Gi vyhledávání

Virtual Network Veřejná IP

Standard SKU – 3x veřejná IPv4 adresa – 1x Firewall, 2x AppGateway

Virtual Network Peering

Přenos dat mezi jednotlivými subnety – 2TB příchozí, 2TB odchozí

Container Registry

Premium SKU – 500GB

Log Analytics

3GB logů/den

Azure monitoring

15 pravidel upozornění



Vývojové a testovací prostředí (DEV + TEST)

Typ komponenty (služby)

Popis

Storage account - data

2x Standard V2 SKU – blob storage pro data, COOL tier, redundance LRS, dohromady 1,5TB dat, 1 milion write operací, 0,5 milionu list/data operací, 0,1 milionu read operací, 0,1 milionu dalších operací, 100Gi vyhledávání

Storage account - nahrávání příloh

2x Standard V2 SKU – blob storage pro nahrávání příloh a kontrolu pomocí antiviru – HOT tier, 150GB, redundance LRS, 1 milion write operací, 0,5 milionu list/data operací, 0,1 milionu read operací, 0,1 milionu dalších operací, 100Gi vyhledávání

Storage account - nahrávání příloh, Microsoft defender

2x SA Defender – 744 hodin provozu, 10/25GB skenovaných dat

SQL Database Elastic

Standard eDTU – 100eDTU – 100GB pro Test prostředí, 50GB pro Dev prostředí

SQL Database - zálohování

Model zálohování databáze LTRA – 52 týdnů, 12 měsíců, 2 roky

Virtual Network Peering

Přenos dat mezi jednotlivými subnety – 1TB příchozí, 1TB odchozí

Virtual Network Private endpoint (sql)

Privátní endpoint pro DevTest SQL databázi

XxxXxxxx pokročilé klíče v HSM

2 klíče v HSM úložišti KeyVault Premium SKU, 1000 základní a 10 000 pokročilých operací

Log Analytics

3GB logů/den

Load Balancer

Standard SKU – AKS deployment

Virtual Machine Scale Set

e8ads_v5 – AKS node – 8vCPU, 64GB RAM, Managed storage – Premium P10 – 128GB

Komponenty užité pro chod Vývojového a Testovacího prostředí se rozkládají výkonově v poměru 1:1

Produkční prostředí

Typ komponenty (služby)

Popis

Storage account - data

Standard V2 SKU – blob storage pro data, COOL tier, redundance LRS, 5,5TB dat, 4 milion write operací, 2 milionu list/data operací, 0,4 milionu read operací, 0,4 milionu dalších operací, 100Gi vyhledávání

Azure Backup - Azure Files

Zálohování datové storage – 30x denní záloha, redundance GRS

Storage account - nahrávání příloh

Standard V2 SKU – blob storage pro nahrávání příloh a kontrolu pomocí antiviru – HOT tier, 150GB, redundance LRS, 1 milion write operací, 0,5 milionu list/data operací, 0,1 milionu read operací, 0,1 milionu dalších operací, 100Gi vyhledávání

Storage account - nahrávání příloh, Microsoft Defender

SA Defender – 744 hodin provozu, 150GB skenovaných dat

SQL Database Elastic 100 eDTU,

Standard eDTU – 100eDTU, 600GB dat

SQL Database Úložiště point-in-time restore

Model zálohování databáze LTRA – 52 týdnů, 12 měsíců, 10 let

Virtual Network Peering - data 3 TB in, 3 TB out

Přenos dat mezi jednotlivými subnety – 3TB příchozí, 3TB odchozí

Virtual Network Private endpoint (sql)

Privátní endpoint pro produkční databázi

XxxXxxxx pokročilé klíče v HSM

2 klíče v HSM úložišti KeyVault Premium SKU, 1000 základní a 10 000 pokročilých operací

Log Analytics

3GB logů/den

Load Balancer

Standard SKU – AKS deployment

Virtual Machine Scale Set

e8ads_v5 – AKS node – 8vCPU, 64GB RAM, Managed storage – Premium P10 – 128GB

Virtual Machine Scale Set (autoscale koeficient 0,2)

e8ads_v5 – AKS node – 8vCPU, 64GB RAM, Managed storage – Premium P10 – 128GB





    1. Služby provozu IS PORTÁL SLUŽEB SFDI

V souvislosti s článkem 3.1.3 Smlouvy poskytne Poskytovatel služby Provozu IS PORTÁL SLUŽEB SFDI, kterými se rozumí zejména poskytování následujících služeb:

  • výkon činností DevOps specialisty, síťového specialisty, systémového administrátora, operátora CSIRT, manažera kybernetické bezpečnosti, IT architekta, pracovníka technické IT podpory a databázového specialisty,

  • Error: Reference source not foundError: Reference source not foundprostřednictvím výkonu činností jednotlivých zaměstnanců Poskytovatele dle tohoto článku zajistit bezvadný chod Produkčního a Testovacího prostředí při dodržení Parametrů SLA dle Přílohy č.2 této smlouvy,

  • prostřednictvím výkonu činností jednotlivých zaměstnanců Poskytovatele dle tohoto článku zajistit bezvadný chod Vývojového prostředí

  • provádět preventivní a reaktivní údržbu IS PORTÁL SLUŽEB SFDI,

  • provádět bezpečnostní aktualizace, monitoring a pravidelné zálohování IS PORTÁL SLUŽEB SFDI,

  • zajistit a Dodavateli předat měsíční report plnění SLA ve vztahu k Provozu IS PORTÁL SLUŽEB SFDI a

provádět všechny ostatní činnosti, které vyplývají přímo z kontextu této Smlouvy



    1. Služba komunikační infrastruktury



Typ prvku

Název prvku

Vysvětlení významu infrastrukturních funkcí, sítí, cest a služeb

Cesta

Propojení AZURE-NGFW CENDIS, s.p.

VPN Gateway IPSEC (SKU VpnGw1) – Route based, IKEv2, AES256, 650Mbps

Komunikační síť

CMS2

Komunikační síť CMS2 (Centrální místo služeb 2. generace) provozovaná státním podnikem NAKIT. Propojení s komunikační sítí CENDIS je zajištěno pomocí 2x 1 Gbit/s CMS2 KIVS O2 . Komunikace je zabezpečena pomocí dedikovaného virtuálního firewallu vyhrazeného pro služby Provozovatele.

Komunikační síť

Microsoft

Microsoft global network v rámci Cloud computing služeb Azure. Všechny výpočetní prostředky využívají síť pouze na úrovni West Europe, vyjímkou je Azure Front Door, který využívá globálního charakteru Microsoft CDN. Propojení s komunikační sítí CENDIS je zajištěno pomocí IPSEC tunelu.

Komunikační síť

CENDIS, s.p.

2x NGFW Fortigate 200F v geograficky oddělených lokalitách Praha-Jihozápadní Město a Praha-Chodov. Komunikační síť zprostředkovává spojení mezi Azure, CMS2 a CENDIS DNS servery.

Lokace

Microsoft Azure – West Europe

Azure region v rámci nějž, jsou hostovány jednotlivé Cloud computing prostředky (VM, Storage…). Skládá se ze 3 geograficky oddělených datacenter v rámci Nizozemska

Komunikační služba

CENDIS, s.p. – DNS

Pro potřeby interního resolvingu a obsloužení služeb CMS2 je využito služeb DNS serverů CENDIS, s.p.



    1. Služba zajištění bezpečnosti

Veškeré komponenty systému budou vyvíjeny, testovány a implementovány dle standardů bezpečného vývoje, v souladu s funkčními požadavky dle této Přílohy Smlouvy a zároveň také dle požadavky kybernetické bezpečnosti blíže vytyčenými v Příloze č. 4 Smlouvy



    1. Technologická rizika

V souvislosti s Provozem IS PORTÁL SLUŽEB SFDI mohou vznikat následující identifikovaná rizika, k nimž Poskytovatel vykoná příslušné akce, které pomohou ke zmírněním nebo eliminaci rizik:

Technologický prvek

Riziko

Popis zmírnění nebo eliminace

Úložiště

poškození nebo selhání technického anebo programového vybavení

Redundantní řešení a vhodně nastavený proces zálohování a obnovy

zneužití nebo neoprávněná modifikace údajů

Vhodná konfigurace FW, ACL a SAS tokenů, vhodně nastavené mechanismy AAA

Infrastruktura v Cloud computing prostředí Microsoft Azure

poškození nebo selhání technického anebo programového vybavení

Redundantní řešení, zálohy deployment skriptů

Vulnerabilita OS

Implementované a vhodně nakonfigurované bezpečnostní prvky, vulnerability management

Chybná, nebo nevhodná konfigurace

Vhodně nastavené kontrolní mechanismy

napadení elektronické komunikace (odposlech, modifikace)

Implementované a vhodně nakonfigurované bezpečnostní prvky, použití kryptografických prostředků

DoS

Vhodně nakonfigurovaný FW a prvky DDoS ochrany a monitoring provozu.

Bezpečnostní prvky DC Poskytovatele

Vulnerabilita OS

Implementované a vhodně nakonfigurované bezpečnostní prvky

Chybná, nebo nevhodná konfigurace

Vhodně nastavené kontrolní mechanismy

Virtualizace Poskytovatele

Vulnerabilita virtuální platformy

Implementované a vhodně nakonfigurované bezpečnostní prvky, vulnerability management

Chybná, nebo nevhodná konfigurace

Vhodně nastavené kontrolní mechanismy

Aplikační a databázová infrastruktury

Zranitelnosti OS

Pravidelné záplatování a vulnerability management

Chybná, nebo nevhodná konfigurace

Vhodně nastavené kontrolní mechanismy

škodlivý kód (například viry, spyware, trojské koně)

Implementované a vhodně nakonfigurované bezpečnostní prvky, systém hardening

Systémové Aplikace a komponenty

škodlivý kód (například viry, spyware, trojské koně)

Implementované a vhodně nakonfigurované bezpečnostní prvky

Zranitelnosti Aplikací a komponent

Pravidelné záplatování a vulnerability management

Chybná, nebo nevhodná konfigurace

Vhodně nastavené kontrolní mechanismy

Zneužití identity

Vhodně nastavené mechanismy AAA

užívání programového vybavení v rozporu s licenčními podmínkami

Dobře nastavený licenční model a analýza kódu na přítomnost komponent s nevyhovujícím licenčním modelem

zneužití nebo neoprávněná modifikace údajů

Vhodně nastavené mechanismy AAA, vhodně nastavené logování a monitoring, kryptografická ochrana

porušení bezpečnostní politiky, provedení neoprávněných činností, zneužití oprávnění ze strany Interních uživatelů a administrátorů

Vývoj a implementace v souladu s požadavky metodik bezpečného vývoje SW

Interní rozhraní

Zneužití identity

Vhodně nastavené mechanismy AAA

škodlivý kód (například viry, spyware, trojské koně)

Implementované a vhodně nakonfigurované bezpečnostní prvky

napadení elektronické komunikace (odposlech, modifikace)

Implementované a vhodně nakonfigurované bezpečnostní prvky, použití kryptografických prostředků

porušení bezpečnostní politiky, provedení neoprávněných činností, zneužití oprávnění ze strany Interních uživatelů a administrátorů

Vývoj a implementace v souladu s požadavky metodik bezpečného vývoje SW

Externí rozhraní

DoS

Vhodně nakonfigurovaný FW a prvky DDoS ochrany a monitoring provozu.

Zneužití identity

Vhodně nastavené mechanismy AAA

škodlivý kód (například viry, spyware, trojské koně)

Implementované a vhodně nakonfigurované bezpečnostní prvky

napadení elektronické komunikace (odposlech, modifikace)

Dobře nastavená autorizace a kryptografické prostředky

napadení elektronické komunikace (odposlech, modifikace)

Implementované a vhodně nakonfigurované bezpečnostní prvky, použití kryptografických prostředků

porušení bezpečnostní politiky, provedení neoprávněných činností, zneužití oprávnění ze strany Interních uživatelů a administrátorů

Vývoj a implementace v souladu s požadavky metodik bezpečného vývoje SW

Provozní

dlouhodobé přerušení poskytování služeb elektronických komunikací, dodávky elektrické energie nebo jiných důležitých služeb

Redundantní řešení a vhodně nastavená SLA

narušení fyzické bezpečnosti

Dostatečná ochrana na úrovni perimetru, oblasti i objektu, Vhodně zavedené procesy fyzické ochrany

Personál

pochybení ze strany zaměstnanců

Dobře nastavené kontrolní mechanismy, používání kryptografických mechanismů

zneužití vnitřních prostředků, sabotáž

Dobře nastavené kontrolní mechanismy

nedostatek zaměstnanců s potřebnou odbornou úrovní

Zasmluvnění externích zdrojů a vhodně nastavená SLA

Obecné (celý systém)

nedodržení smluvního závazku ze strany Poskytovatele

Vhodně nastavená SLA a penalizace



  1. rozvoj is PORTÁL SLUŽEB SFDI

Rozvoj IS PORTÁL SLUŽEB SFDI je poskytován ze strany Poskytovatele za definované ceny / Manday vývoje dle jednotlivých rolí účastnících se na vývoji dle přílohy č. 5.

Rozvoj IS PORTÁL SLUŽEB SFDI prostřednictvím změnového řízení bude řešen zadáním návrhu změnového požadavku Objednatelem nebo Poskytovatelem do fronty dedikované pro změny IS PORTÁL SLUŽEB SFDI - ZMĚNY - a je popsán v čl. 3.1.4. Smlouvy a článku 7 (Změnové řízení).



  1. Harmonogram realizace

Na základě znění této Smlouvy Objednatel a Poskytovatel sjednávají v rámci této Přílohy č.1 výchozí Harmonogram, který bude upřesněn v rámci Analýzy.

#

Ref

Název úkolu

Zahájení

Dokončení

1


[SFDI+CENDIS] Podpis smlouvy realizace a provozu IS PORTÁLU SLUŽEB SFDI (SFDI+CENDIS)

01.03.2024

01.03.2024

2


[CENDIS] Plánované zahájení budování DEV prostředí

01.03.2024

->

3


[CENDIS] Plánované spuštění TEST prostředí

01.06.2024

->

4


[SFDI] Workshopy nad stanovením rozhraní za IS Evidence

01.03.2024

15.03.2024

5


[SFDI] Pro DEV/TEST prostředí IS PORTÁLU SLUŽEB SFDI - dostupné TEST rozhraní IS Evidence

15.3.2024

30.4.2024

6


[SFDI] Dokumentace vč. popisu rozhraní za eSSL

15.3.2024

30.4.2024

7


[SFDI Pro DEV/TEST prostředí IS PORTÁLU SLUŽEB SFDI – dostupné TEST rozhraní eSSL - předpoklad

15.3.2024

30.4.2024

8


[CENDIS] IT Analýza a technický návrh řešení – jádro systému

01.03.2024

31.03.2024

9


[CENDIS] IT Analýzy a technický návrh řešení – doplňkové/závislé agendy

01.04.2024

30.06.2024

10


[CENDIS] UX/UI Prototyp

01.03.2024

30.04.2024

11


[CENDIS] Implementace jádra systému + integrace

01.03.2024

30.06.2024

12


[DIA/MD] Dokumentace vč. popisu rozhraní za Mandátní rejstříky


01.06.2024

13


[DIA/MD] Pro DEV/TEST prostředí IS PORTÁLU SLUŽEB SFDI dostupné TEST rozhraní za Mandátní rejstříky


30.06.2024

14


[CENDIS] Implementace doplňkových/závislých agend + integrace

01.07.2024

30.11.2024

15


[SFDI] UAT testování a akceptace

01.12.2024

31.01.2025

16


Rutinní provoz

01.02.2025

->





≡ 1 ≡

Document Metadata

Filed: February 29th, 2024