Nefunkční požadavky. ID Název požadavku Popis požadavku
Nefunkční požadavky. Pož. ID Popis
Nefunkční požadavky. 6.1.1 Třívrstvá architektura Řešení bude založeno na třívrstvé architektuře s oddělením databázové, aplikační a prezentační vrstvy.
Nefunkční požadavky. D.2.2.1. Odezvy Zadavatel si vyhrazuje ověření splnění těchto technických podmínek po uvedení PAM do zkušebního provozu naplnění systému PAM údaji cca. 1200 osob. ● Inkrementální načtení změn do 30 sekund. ● Během Inkrementálního načtení maximální doba zdržení ostatních operací max. 5 sekund jednorázově a max 15 sekund celkově. ● Celkové načtení max. 5 minut. Lze řešit i předgenerovanými sestavami. ● Založení jedné osoby přes API max. 5 sekund
Nefunkční požadavky. Dimenzování a výkonnost: licenčně neomezený počet konfiguračních položek a uložených dat; technologické omezení pouze na základě poskytnutých IT zdrojů, licenčně neomezený počet napojených externích systémů, licenčně neomezený počet evidovaných aktivních uživatelů, možnost plné souběžné interaktivní práce s definovanou maximální dobou odezvy v řádech jednotek sekund pro minimálně 20 konkurenčních uživatelů, škálovatelnost, možnost zvětšovat počty paralelně pracujících uživatelů apod. přidáváním IT zdrojů. Spolehlivost a podpora provozu: průběžná údržba a záplatování řešení, dle životního cyklu vývoje a doporučení dodavatele, provoz řešení v major verzi ekvivalentní k last-stable a s maximálním tolerovaným zpožděním nasazení minor verze na last-stable (-1) / (-2) dle doporučení dodavatele, aplikace kritických záplat dodavatele do 2 dnů od jejich zveřejnění, podpora provozu 24/7/365, s OLA alespoň 92% a časem odezvy na provozní nebo bezpečnostní incident do 4 hodin, zvýšená podpora provozu v průběhu pracovní doby, s OLA alespoň 96% a časem odezvy na provozní incident do 2 hodin a na bezpečnostní incident do 1 hodiny, možnost provozování řešení na virtualizační platformě MMB (VMWare), možnost hromadné instalace softwarových komponent určených koncovým uživatelům standardními prostředky; dle cílové platformy - např. Microsoft / System Center, Android / Google Play, iOS / App Store aj. Bezpečnost uživatelské rozhraní musí být bezpečné do té míry, že ho je možné bez dodatečného zabezpečení třetí stranou (hardering, aplikační firewall, filtrace provozu apod.) zpřístupnit do internetu, pokud jsou komponenty a funkcionality řešení dodávány formou webových služeb, musí být zabezpečeny proti běžným útokům dle doporučení OWASP, řešení musí obsahovat dodatečné prvky pro posílení bezpečnosti při práci z nedůvěryhodných zdrojů, zejména neznámých veřejných IP adres, pro interaktivní práci se za takové prvky považují například vícefaktorová autorizace, autorizace pomocí krypto-tokenů apod., pro strojové zpracování se za takové prvky považují například serverové certifikáty, veškerá komunikace musí být šifrovaná (například SSL/TLS, VPN apod. Příloha č. 2 Poskytovatel se zavazuje provádět Expertní služby po jednotlivých fázích tvořících dílčí plnění. Fáze provádění Expertních služeb jsou stanoveny v následující tabulce: Název fáze Výstupy fáze (předané plnění) [seznam] Termín ukončení fáze (termín převzetí plnění) [T + t]*) Platební milník (k termínu ukončení fáze) [ano/ne] ...
Nefunkční požadavky. Následující kapitola popisuje nefunkční požadavky systému formou níže uvedené tabulky: NFP_1 Rozšiřitelnost Snadná rozšiřitelnost systému zejména ve funkčních oblastech. Systém bude navržen a realizován, jako modulární. I s ohledem na dokumentaci bude možné jej dále rozšiřovat. Maximalizace snížení provázání jednotlivých komponent.
Nefunkční požadavky. Platforma
Nefunkční požadavky. Z dlouhodobého hlediska zajištění provozuschopnosti řešení postavených s využitím Platformy je požadováno splnění parametrů zejména v následujících oblastech: Platforma musí prokázat na úrovni koncepce, architektury, integrace, použitých technologií a standardů, dlouhodobou stabilitu a jasnou vizi směřující k zajištění provozuschopnosti na minimálně 10 let. Platforma musí být stabilní a poskytovat vysokou dostupnost s rozumnou mírou redundance s využitím dostupných softwarových prostředků na poskytnuté provozní infrastruktuře objednatele.
Nefunkční požadavky. Obsah Požadavky na bezpečnost 3
Nefunkční požadavky. V rámci zavedení GRC jsou zásadními požadavky: Schopnost integrace na ostatní systémy, a to dle stavu připravenosti a možností těchto systémů. Pokud není k dispozici integrační platforma, bude požadována přímá integrace na jednotlivé ostatní dílčí systémy a postupné integrace systémů či postupné náhrady větších celků za funkčně úzce vymezené. Nový systém musí umožnit sdílet integrační vazby, a především respektovat primární zdroje dat jako jsou např. centrální číselníky, centrální registry apod. Otevřenost vůči externím systémům formou API v dále uvedeném rozsahu Bezpečnost