Analisi dei requisiti

Il reperimento e lŠanalisi dei requisiti sono attivit‘a difficilmente standardizzabili perch´e dipendono notevolmente dal sistema da realizzare. ‘E importante chiarire, innanzitutto, che per raccolta dei requisiti si intende la completa individuazione dei problemi che il sistema da realizzare deve risolvere e delle caratteristiche che esso dovr‘a avere. Questi requisiti, tendenzialmente, vengono pattuiti con gli stakeholder del progetto nelle fasi iniziali di questŠultimo e, spesso, soffrono il difetto di essere espressi in linguaggio naturale, che porta a conseguenti fenomeni di ambiguit‘a e incertezza. Da qui, quindi, capiamo che ‘e fondamentale formalizzare questi ultimi senza correre il rischio di incappare in una delle problematiche appena citate. Que-stŠimportante processo, che si pone lŠobiettivo di formalizzare i requisiti, prende il nome di analisi dei requisiti e ricopre un ruolo fondamentale nella progettazione di un sistema software, dal momento che, secondo i dettami dellŠingegneria del soft-ware, ‘e il primo dei quattro indispensabili step da seguire per la progettazione di un sistema.

Quando parliamo di requisiti ‘e utile separare i requisiti funzionali da quelli non funzionali; nelle omonime sotto-sezioni di questo capitolo vedremo le differenze fra queste due tipologie di requisiti e la deĄnizione degli stessi per ci‘o che concerne il nostro sistema.

2.1.1 Requisiti funzionali

I requisiti funzionali sono requisiti che deĄniscono una o pi‘u funzioni di un sistema (oppure i requisiti di uno o pi‘u componenti di questŠultimo), speciĄcando la tipolo-gia degli ingressi e delle uscite, nonch´e il comportamento. Essi si presentano come

elenchi di funzionalit‘a o servizi che il sistema deve fornire, e descrivono, inoltre, il comportamento del sistema a fronte di particolari input, oltre a come esso dovrebbe reagire in determinate situazioni.

Due caratteristiche importanti delle speciĄche dei requisiti sono la completezza e la coerenza. In particolare, un documento di speciĄca dei requisiti pu‘o essere deĄnito ŞcompletoŤ se tutti i requisiti richiesti dagli utenti sono deĄniti; esso, inoltre, pu‘o essere deĄnito coerente e consistente quando non vi sono dei requisiti in conĆitto tra di loro. Sebbene questi risultati siano facili da ottenere per i piccoli sistemi, ‘e chiaramente necessario uno sforzo maggiore per i sistemi con un numero elevato di requisiti. In questo secondo caso, infatti, la difficolt‘a ‘e racchiusa proprio nella maggiore incidenza di errori e, soprattutto, di omissioni.

In conclusione, quindi, i requisiti funzionali descrivono cosa dovrebbe fare il sistema che si intende realizzare e si basano sulla seguente forma: Şil sistema deve fare <requisito>Ť.

Per delineare i requisiti funzionali del sistema Ąnale ‘e doveroso porre lŠattenzione sui tre seguenti ambiti: dati satellitari e gestione di questi ultimi, piattaforma soft-ware e architettura cloud. In accordo con quanto appena detto, i requisiti funzionali che dovr‘a avere il sistema Ąnale che verr‘a realizzato sono i seguenti:

• RF1: il sistema dovr‘a consentire lŠelaborazione di dati satellitari.

• RF2: per quanto concerne lŠambito dei dati satellitari, sar‘a necessario che il siste-ma possa elaborare dati di diverso tipo (sia prisiste-mari che secondari) e provenienti da diverse fonti (Copernicus, Sentinel, Landsat, ecc...); pi‘u in dettaglio, saranno di particolare interesse i dati secondari appartenenti al progetto Copernicus.

• RF3: il sistema dovr‘a consentire lŠimplementazione di una pipeline automatica di ETL per i dati satellitari di interesse.

• RF4: il sistema dovr‘a consentire di effettuare lŠanalisi di dati satellitari speciĄ-cando unŠarea geograĄca, un intervallo temporale e un satellite.

• RF5: il sistema dovr‘a prevedere unŠinterfaccia Web attraverso la quale lŠutiliz-zatore Ąnale potr‘a interagire con esso.

• RF6: il sistema dovr‘a consentire allŠutilizzatore Ąnale di lasciare un feedback riguardante la sua user experience, i bug rilevati e ulteriori problemi riscontrati durante lŠutilizzo.

• RF7: il sistema dovr‘a consentire agli sviluppatori di effettuare le analisi dei dati satellitari predisponendo un notebook Jupyter che si possa interfacciare con la piattaforma IT e possa sfruttare le sue potenzialit‘a; grazie a Jupyter Notebook, dunque, lŠanalista sar‘a in grado di fare le analisi su una sandbox integrata che supporti formati standard ed open.

• RF8: il sistema dovr‘a essere accessibile tramite Web in modo tale da poter offrire agli utenti le sue risorse in cloud (considerevolmente cospicue) piuttosto che utilizzare le capacit‘a computazionali e di storage di questi ultimi (decisamente esigue rispetto a quelle del sistema cloud).

2.1.2 Requisiti non funzionali

I requisiti non funzionali, a differenza di quelli funzionali presentati in precedenza, descrivono vincoli sui servizi offerti dal sistema, nonch´e sul suo processo di sviluppo.

Questo tipo di requisiti, tipicamente, non si applicano a singole funzioni o servizi,

bens‘ı allŠinterno del sistema; pi‘u precisamente, essi non riguardano le speciĄche funzioni fornite dal sistema, ma possono riferirsi sia a caratteristiche che si deside-rano per esso (come, ad esempio, lŠaffidabilit‘a, i tempi di risposta o lŠoccupazione di memoria), sia a vincoli ai quali esso deve sottostare (come, ad esempio, la capacit‘a dei dispositivi di I/O e la rappresentazione dei dati utilizzata nelle interfacce del sistema). I requisiti non funzionali, inoltre, sono strettamente vincolati alla neces-saria modalit‘a di interazione del relativo sistema con altri componenti. Pertanto, una classiĄcazione che si potrebbe effettuare in base ai vari tipi di requisiti non funzionali ‘e la seguente:

• requisiti di prodotto, che descrivono le caratteristiche del prodotto, in termini di usabilit‘a, efficienza, affidabilit‘a e portabilit‘a;

• requisiti organizzativi (o di processo), che derivano dalle politiche e dalle proce-dure organizzative relative al cliente ed allo sviluppatore;

• requisiti esterni, che si riferiscono a fattori esterni al sistema ed al relativo processo di sviluppo, come requisiti legislativi o requisiti di interoperabilit‘a.

In Figura 2.1 viene rappresentata una classiĄcazione gerarchica dei requisiti non funzionali, in linea con quanto detto sopra, che mostra i tre tipi appena descritti e le varie speciĄcazioni di ognuno di essi.

Figura 2.1.ClassiĄcazione gerarchica dei requisiti non funzionali

In conclusione, quindi, i requisiti non funzionali impongono vincoli su come il sistema dovrebbe fare una determinata cosa e si basano sulla seguente forma: Şil sistema deve essere <requisito>Ť.

Nel caso preso in esame, il sistema Ąnale che verr‘a messo in piedi dovr‘a avere i seguenti requisiti non funzionali:

• RNF1: i dati satellitari che dovranno essere ingeriti dal sistema dovranno poter essere sia di tipo NetCDF che di tipo GeoTIFF o GeoTIFF ottimizzato per il cloud (denominato COG - Cloud Optimized GeoTIFF).

• RNF2: il sistema dovr‘a essere in grado di gestire una grande quantit‘a di dati satellitari e, in particolare, singoli Ąle di dati satellitari di dimensioni considerevoli.

• RNF3: i dati che verranno gestiti dal sistema dovranno essere estratti da sorgenti completamente open che dovranno essere sempre disponibili.

• RNF4: il sistema dovr‘a essere sempre disponibile assicurando allŠutilizzatore Ąnale la continua attivit‘a.

• RNF5: il sistema dovr‘a assicurare affidabilit‘a.

• RNF6: il sistema dovr‘a garantire i principi di conĄdenzialit‘a ed integrit‘a per i dati degli account (relativi agli utenti) salvati nel database del sistema.

• RNF7: il sistema dovr‘a essere sufficientemente veloce; nonostante la grande mole dei dati da elaborare, infatti, la piattaforma dovr‘a essere in grado di elaborare i dati in tempi ragionevoli per agevolare sia lŠanalisi di questi ultimi che i relativi risultati.

• RNF8: il sistema dovr‘a garantire adeguati livelli di sicurezza per tutte le va-rie componenti del sistema, ovvero accesso allŠinterfaccia Web gestito attraverso un sistema di autenticazione, accesso ai vari database (sia degli utenti che del sistema) chiuso agli utilizzatori ed accessibile solo ed esclusivamente agli ammi-nistratori, impossibilit‘a di poter accedere ai singoli servizi se non utilizzando la Web user interface come vettore.

• RNF9: la piattaforma IT che verr‘a scelta dovr‘a essere open source.

• RNF10: il sistema dovr‘a garantire, attraverso la piattaforma software scelta, lŠastrazione dei dati che permetter‘a agli sviluppatori di lavorare ad un alto livello di astrazione nascondendo i dettagli implementativi dei dati satellitari.

• RNF11: lŠinterfaccia graĄca che verr‘a messa a disposizione dal sistema dovr‘a essere chiara, intuitiva e di facile utilizzo per permettere una user experience ottimale; questŠinterfaccia dovr‘a permettere di visualizzare i dataset disponibili su determinate aree del globo e di selezionare facilmente sotto-aree di interesse per visualizzare i risultati delle analisi.

• RNF12: il sistema Ąnale dovr‘a essere agevolmente utilizzato anche da utenti che non hanno esperienza in ambito IT.

• RNF13: il sistema dovr‘a essere accessibile agli utenti sul Web tramite un browser.

• RNF14: la piattaforma IT che verr‘a scelta dovr‘a offrire allo sviluppatore la possibilit‘a di replicare lŠinfrastruttura su un sistema di cloud computing.

• RNF15: il servizio di cloud computing che ospiter‘a il sistema sar‘a il servizio AWS offerto da Amazon.