Requisiti non funzionali. Si elencano di seguito i requisiti non funzionali, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura.
Requisiti non funzionali. Si elencano di seguito i requisiti non funzionali, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura. Tutti i requisiti non funzionali oggetto del presente capitolo sono da considerarsi “obbligatori” (ovvero, ATS li ritiene indispensabili per l’avvio del sistema in produzione).
Requisiti non funzionali. La componente hardware e software del Sistema GUS-N dovranno essere progettate e realizzate al fine di soddisfare tutti i seguenti principali requisiti non funzionali: • le componenti principali del Sistema dovranno essere installate ed attivate presso il Centro Elettronico Nazionale della Polizia di Stato sito in Napoli, nel pieno rispetto delle caratteristiche dell’infrastruttura HW/SW in esso presente, al fine di garantire una totale integrazione; • la componente sw del Sistema dovrà essere accessibile in modalità web, tramite la sola rete intranet della Polizia di Stato (Ministero dell’Interno), diffusa sul territorio nazionale; • il Sistema dovrà essere capace di garantire in esercizio la stessa fluida esperienza d’uso dell’attuale GUS, servendo circa mille utenti, di cui almeno la metà in maniera concorrente; in tale ottica, dovrà essere in grado di gestire, con tempi di risposta ragionevoli, le schede di tutti i dipendenti della Polizia di Stato in esso contenute (circa 100.000 ÷ 110.000, con un tasso di crescita annuo dell’1%), sia per le normali funzionalità di gestione che per le più evolute funzioni statistiche; • il Sistema dovrà prevedere la simultanea esistenza di un ambiente di esercizio/produzione e di un secondo ambiente di test, di ridotte capacità rispetto al primo ma funzionalmente analogo, che, un volta ultimato il progetto, verrà utilizzato per svolgere attività di formazione; questo ambiente dovrà essere in grado di servire almeno cinquanta utenti in maniera concorrente, gestendo almeno un centinaio di schede pazienti; • il Sistema dovrà essere sviluppato nel pieno rispetto del D.Lgs. 196/03, per quanto concerne il trattamento di dati sensibili tramite l’ausilio di strumenti elettronici; • le Piattaforme e gli Applicativi sw del Sistema dovranno essere interamente basate su software concesso in licenza GPL (General Public License), secondo standard non proprietari; • l’Applicativo GUS-N dovrà essere realizzato mantenendo per quanto possibile lo stesso aspetto grafico dell’applicativo GUS (interfaccia utente, UI) e riutilizzando, laddove possibile, il codice sorgente per quest’ultimo sviluppato; • l’intero Sistema dovrà essere progettato per garantire la sua totale sostenibilità per almeno tre anni (ciclo di vita del sistema) successivi alla data di positivo collaudo finale, allo scopo di evitare alla Amministrazione di dover sostenere ulteriori spese per il suo mantenimento, a parte quelle di gestione ordinaria, oltre l’investimento ...
Requisiti non funzionali. Le attività di assistenza e manutenzione richieste al Fornitore nel presente Capitolato Tecnico dovranno essere condotte anche nel rispetto di vincoli e requisiti non strettamente funzionali, riguardanti in generale la qualità e l’operatività del servizio.
Requisiti non funzionali. 5.1 Requisiti organizzativi 15
5.2 Requisiti di security 15
5.3 Requisiti e vincoli tecnologici e infrastrutturali 16
5.4 Requisiti di usabilità 19
5.5 Requisiti di migrazione 19
Requisiti non funzionali. Nel presente Capitolo si descrivono le caratteristiche non funzionale che la soluzione CCER dovrà soddisfare.
Requisiti non funzionali. L’implementazione del Sistema ERP - Dyamics AX, oggetto del presente capitolato, dovrà rispondere pienamente ai requisiti non funzionali di seguito dettagliati:
A) Unicità, tracciabilità e storicizzazione di dati e documenti
B) Sicurezza, privacy e gestione utenti:
C) Integrazione, interoperabilità, aderenza agli standard
Requisiti non funzionali. Req. Descrizione Risposta H Requisiti non funzionali H1 Portabilità # Req. Descrizione Risposta
Requisiti non funzionali. Req. Descrizione Risposta H Requisiti non funzionali H1 Portabilità
Requisiti non funzionali. L’applicazione (tutti i moduli funzionali) dovranno avere una interfaccia web ed essere utilizzabili su postazioni fisse, preferibilmente anche mobili, utilizzando i più comuni browser quali IE9, IE11, Chrome. Sulle postazioni di lavoro client non deve essere necessario installare alcun componente aggiuntivo oltre al SW di base standard del sistema operativo. Il sistema dovrà utilizzare coma base dati la piattaforma RDBMS Oracle 11 o successive, messa a disposizione dall’Azienda sui propri server. La gestione dei backup sarà a cura dell’Azienda e sarà messa a punto con la collaborazione del fornitore per gli aspetti di dettaglio. Il fornitore dovrà rilasciare credenziali di accesso al database con diritti applicativi e di amministratore e fornire tutto il supporto necessario per l’accesso ai dati. Le normali attività di amministrazione del database (quali backup, allocazione tablespace) saranno a carico dell’Azienda. E’ però richiesto al fornitore una attività di manutenzione straordinaria, con cadenza almeno annuale, per la verifica delle prestazioni e il fine-tuning del database. Il fornitore dovrà indicare i requisiti mini e ottimali della infrastruttura HW che l’Azienda deve mettere a disposizione per l’installazione dei sistemi forniti. Le risorse di calcolo che l’Azienda metterà a disposizione sono necessariamente basate su architettura virtuale VmWare con sistema operativo host windows 2008R2 o 2012 oppure Linux. Il database verrà ospitato nella attuale infrastruttura basata su Oracle RAC 11 standard edition. Il sistema deve potersi integrare attraverso i più comuni protocolli e metodologie riconosciute standard di mercato. E’ richiesta al sistema la capacità di integrazione tramite l’adozione di formati XML e dei protocolli di scambio da esso derivati (Web Services) per consentire il completo automatismo e impedire l’ accesso diretto al dato, nonché garantire il massimo livello di sicurezza. Nel caso di integrazioni che prevedono accessi di sola lettura possono essere utilizzate anche delle viste di database con le opportune regole per garantirne la sicurezza. Il sistema deve consentire a seconda della tipologia di integrazione la definizione di tempi e modi del processo di integrazione: asincrono con cadenza prefissata e configurabile, sincrono (real- time) a fronte della variazione del dato. Laddove non sia possibile garantire un’integrazione standard per le integrazioni in essere o per problematiche relative all’applicativo aziendale coinvolto, ...