Sviluppo sicuro del software, come formalizzarlo: ingegneria dei requisiti

I requisiti di sicurezza rappresentano il termine di paragone con cui confrontarci per tutta la durata del processo di sviluppo e la messa in produzione di un sistema finito. Dopo averli enunciati e aver risolto eventuali conflitti tra di loro, occorre implementare un processo formale per identificarli, analizzarli e valutarli. Approfondiremo quindi il tema dell’Ingegneria dei Requisiti (Requirements Engineering). Essa consiste in un processo formale per l’elicitazione (identificazione, analisi, valutazione) dei requisiti ed è normalmente adottato in ambienti complessi, dove i requisiti possono essere molti, espressi da un gran numero di stakeholder diversi e soggetti a un iter di discussione e approvazione. Pensiamo, ad esempio, ai requisiti per un progetto aerospaziale o di fisica delle particelle elementari.

Le discipline del Requirements Engineering

Lo sviluppo dei requisiti: ecco come procedere

Lo sviluppo dei requisiti si compone di quattro fasi:

1. scoprire i requisiti (elicitazione e analisi)
2. conversione di questi requisiti in qualche formato standard (specification)
3. controllo che i requisiti definiscano il sistema che il cliente vuole (validazione)

L’elicitazione dei requisiti è il processo di raccolta delle informazioni sul sistema da analizzare. Le persone coinvolte nel processo (utenti finali, fornitori, team di progetto, sviluppatori ecc.) sono noti collettivamente con il nome di Stakeholders.

I requisiti devono essere opportunamente validati, cioè devono possedere le tre proprietà:

• correttezza il requisito deve rispecchiare fedelmente il vincolo esposto dall’utente
• completezza i requisiti individuati devono coprire completamente i vincoli esposti dagli utenti
• consistenza i requisiti non devono essere incongruenti tra loro

Dal momento che i requisiti formano una gerarchia, il processo di ingegneria dei requisiti non sarà sequenziale ma iterativo. Ad esempio, prima i requisiti di business (elicitazione, analisi, specifica, validazione), poi i requisiti utente, o di stakeholder, (elicitazione, analisi, specifica, validazione), poi i requisiti di sistema (elicitazione, analisi, specifica, validazione), successivamente i requisiti del sottosistema software (elicitazione, analisi, specifica, validazione) e così via, aumentando a ogni step il livello di dettaglio.

Rappresentazione gerarchica dei requisiti di sicurezza

La prima iterazione, che serve a identificare i requisiti di livello più alto, produrrà come output lo studio di fattibilità. Questo dovrà rispondere alla domanda se vale la pena implementare il sistema in analisi a partire dai requisiti di business espressi, e se ciò possa essere fatto con il budget assegnato, le capacità tecniche attuali, la schedulazione prevista ecc.

Formalizziamo il documento dei requisiti

Lo scopo del processo complessivo è la produzione di un documento, il documento dei requisiti, che definisca le funzionalità e i servizi offerti dal sistema da analizzare.

La struttura di un documento dei requisiti deve essere come segue:

1. Introduzione
   • Obiettivo del documento dei requisiti
   • Obiettivo del prodotto
   • Definizioni, acronimi, abbreviazioni
   • Riferimenti
   • Struttura del documento
2. Descrizione generale
   • Descrizione del prodotto dai diversi punti di vista
   • Funzionalità del prodotto
   • Caratteristiche utente
   • Vincoli sul prodotto

3. I requisiti (funzionali, non-funzionali, lato utente…)
4. Appendici
5. Indice

dove, rispettivamente:

• Glossario definisce i termini tecnici utilizzati
• Modelli del sistema definisce i modelli mostrando i componenti del sistema e le loro relazioni
• Definizione dei requisiti funzionali descrive i servizi forniti
• Definizione requisiti non funzionali definisce i vincoli sul sistema ed il processo di sviluppo
• Evoluzione del sistema definisce le assunzioni principali su cui si basa il sistema e le modifiche future
• Specifica dei requisiti specifica dettagliata dei requisiti funzionali
• Appendici descrizione dettagliata collegata all’applicazione da sviluppare. (es. piattaforma hardware da usare, schema della base dei dati)

I requisiti possono essere di due tipi:

• requisiti funzionali: descrivono le funzionalità e i servizi offerti dal sistema. Possono essere descritti da Use Cases
• requisiti non funzionali: definiscono vincoli sul sistema, ad esempio sul suo utilizzo, sulla sua manutenzione, sul suo sviluppo ecc. Non possono essere descritti da Use Cases. Un esempio potrebbe essere un vincolo sulle performances o il fatto che, in un’interfaccia grafica, un certo elemento debba essere di colore rosso.

Strettamente correlati con il concetto di requisito ci sono due altri concetti, quello di priorità e quello di attore.

I requisiti, dopo essere stati enunciati, devono essere classificati per priorità. Questo step si aggancia direttamente alla fase iniziale del lavoro progettuale, in quanto, aver chiare le priorità permette di gestire meglio i tempi e i costi del progetto.

L’altro concetto è quello di punto di vista, che porta a sua volta al concetto di attore.  Un attore è, in generale, una persona o un sistema che interagisce col sistema in studio, senza farne parte.

Ogni requisito è espresso da persone che hanno ruoli diversi all’interno o all’esterno dell’organizzazione. Avremo, perciò

• Requisiti di business, espressi da figure che lavorano in ambito economico/finanziario/commerciale
• Requisiti tecnici, espressi da figure che lavorano in ambito IT
• Requisiti normativi, espressi dall’aderenza a policies, regolamenti o leggi
• Requisiti di progetto, enunciati come vincoli alla triade costi, tempi e qualità e espressi sia dal cliente che dal team di progetto
• Requisiti di funzionamento, espressi dal cliente
• Requisiti di utilizzo, espressi dagli utenti finali
• Requisiti di sicurezza, espressi da esperti di sicurezza
• Requisiti di processo, che evidenziano come un certo processo dovrebbe essere svolto e che possono essere espressi da Process Engineers o da Project Managers

Ognuno di questi requisiti evidenzia la necessità di classificazione anche in base all’attore (cliente, utente finale, team di progetto, designer ecc.) che ha generato il requisito. L’attore esprime un punto di vista, il suo appunto. Il fatto che esistano punti di vista diversi vuol dire anche che esiste la possibilità di conflitti tra i requisiti, conflitti che devono essere risolti prima di cominciare la fase architetturale vera e propria.

Definire i requisiti funzionali: il metodo Use Case

Uno Use Case definisce un insieme di interazioni orientate a uno scopo tra un attore esterno e il sistema. Così, lo Use case è usato per esprimere chi fa cosa con il sistema e per quale scopo. Se l’attore è, ad esempio, un utente internet e il sistema è un’applicazione di e-commerce, uno Use Case potrebbe essere “l’Utente vuole acquistare un oggetto dal catalogo”.

Ogni Use Case è una collezione di scenari d’uso, che rappresentano ciascuno un singolo modo per raggiungere l’obiettivo specificato. Così è possibile costruire tanti scenari quanti sono i modi possibili, comprese eccezioni, condizioni d’errore ecc. per giungere allo scopo. Nel caso visto sopra, scenari possibili potrebbero essere “l’Utente sfrutta il motore di ricerca del sito per trovare un oggetto e acquistarlo”, oppure “l’Utente compra l’oggetto dopo aver sfogliato il catalogo”, oppure ancora “l’Utente compra l’oggetto, perché visualizzato tra gli articoli in promozione nell’apposita sezione del sito”. Uno strumento grafico per esprimere gli scenari è quello dei diagrammi di sequenza. Uno strumento testuale è invece quello dello storyboard, che consiste in una specie di narrazione, magari rivestita con elementi “di colore”, dello scenario. Un esempio di storyboard potrebbe essere il seguente “Anna, 30 anni, sposata, è commessa in un grande magazzino e vuole collegarsi al sito web aziendale per controllare la disponibilità di un articolo.” Il vantaggio di uno storyboard è che permette di raccontare uno scenario magari aggiungendo dettagli sul profilo dell’attore.

Lo stile con cui è scritto uno Use Case va dall’informale allo pseudo-formale. Il suo scopo principale è condividere con gli stakeholder una visione comune.

Nella sua forma base uno Use Case è espresso come in figura e rappresenta una relazione di associazione tra un attore e un Use Case.

Un esempio di Use Case

La linea rappresenta la “comunicazione” tra un attore e il sistema.

UML fornisce tre modalità con cui creare Use Case più complessi e strutturati. Esse sono, rispettivamente:

• Inclusione è una relazione obbligatoria tra due use case (un “incluso” e uno “che include”) che indica che la sequenza di azioni descritta da uno use case è compresa pure dall’altro. Continuando con l’esempio dell’acquisto via web, lo use case “l’utente deve inserire i dati di spedizione” è incluso da quello “l’Utente acquista un oggetto da catalogo sul sito”.
• Estensione permette di evidenziare una variante a uno use case. Non rappresenta uno use case esso stesso ma la variazione nei passi da compiere nello use case. Sempre nell’esempio dell’acquisto via internet potremmo considerare varie possibilità di pagamento, dal bonifico bancario, al contrassegno, alla carta di credito ondine. Un’estensione potrebbe consistere nel fatto che, se l’utente sceglie la carta di credito come pagamento, allora deve inviare via fax una fotocopia di un documento d’identità.
• Generalizzazione è una relazione tra due use case o tra due attori che indica che lo use case/attore “figlio” è completamente contenuto nello use case/attore “padre”. Un esempio può essere l’acquisto di un oggetto da catalogo che potrebbe essere fatto in vari modi, dall’acquisto in negozio, a quello via internet a quello per via telefonica. In tal caso, lo Use Case “Acquisto di un oggetto da catalogo” generalizza lo Use Case “Acquisto via web di un oggetto da catalogo”.

Un esempio di varie relazioni tra Use Case

I sequence diagrams, o diagrammi di sequenza, sono utilizzati per descrivere gli scenari e hanno la caratteristica di indicare la dinamica dell’interazione tra l’attore e il sistema, cioè, in più, è presente la variabile tempo. Essi descrivono la collaborazione tra più oggetti che, collettivamente, interagiscono per compiere una determinata attività.

Un esempio di sequence diagram

La norma ISO/IEC 9126, che risale nella sua prima versione al 1991, ha definito il modello di requisiti qualitativi del software.

Secondo il modello, i requisiti sono raggruppati in 6 caratteristiche (di cui una, la Funzionalità, funzionale e 5 non funzionali) e in 21 sotto caratteristiche, distinte fra caratteristiche esterne, che sono orientate all’utente, e caratteristiche interne, orientate allo sviluppo e manutenzione.

Esse sono:

• Funzionalità: capacità di soddisfare esigenze implicite o esplicite. Le sotto caratteristiche sono

          – Idoneità: le funzionalità sono appropriate ai compiti specificati

          – Accuratezza: precisione nei risultati

          – Interoperabilità: capacità di interagire con altre applicazioni

          – Sicurezza: protezione da utilizzi non autorizzati. In questo caso, sono disponibili cataloghi di requisiti utilizzabili, come nel caso dei Common Criteria (ISO 15408), che esplicitano i componenti funzionali.

          – Concordanza: aderenza a standard o regolamentazioni legislative

• Disponibilità: capacità di fornire una continuità di servizio. Le sotto caratteristiche sono:

          – Maturità: mancanza di interruzioni o malfunzionamenti

          – Tolleranza: ridotto degrado in caso di malfunzionamenti

          – Recupero: capacità e velocità di ripristino dalle interruzioni

• Usabilità: facilità di utilizzo da parte degli utenti. Le sotto caratteristiche sono:

          – Comprensione: acquisizione di un adeguato livello di conoscenza

          – Apprendimento: velocità di familiarizzazione

          – Utilizzabilità: facilità di uso e controllo

          – Attrattiva: livello di gradimento nell’utilizzo

• Efficienza: capacità di fornire prestazioni adeguate. Le sotto caratteristiche sono:

          – Tempo di risposta: reattività agli stimoli dell’utente

          – Utilizzo delle risorse: utilizzo adeguato delle risorse del sistema

• Manutenubilità: facilità di manutenzione correttiva ed evolutiva. Le sotto caratteristiche sono:

          – Analizzabilità: facilità di diagnosi e di identificazione dei componenti

          – Modificabilità: facilità di inserimento di modifiche

          – Stabilità: limitazione di effetti indesiderati dovuti alle modifiche

          – Collaudabilità: facilità di sottoporre a test le modifiche apportate

• Portabilità: trasferibilità da un ambiente ad un altro. Le sotto caratteristiche sono:

          – Adattabilità: facilità di adeguamento ad un nuovo ambiente

          – Installabilità: velocità e completezza di installazione

          – Coesistenza: capacità di risiedere con altre applicazioni nello stesso ambiente

          – Sostituibilità: capacità di rimpiazzare un’altra applicazione

Come abbiamo visto inizialmente, nella fase di Specifica occorre esprimere i requisiti in formato standard.

In particolare, potremmo usare la nomenclatura:

Priorità.Attore.Caratteristica_Sottocaratteristica.X.Y…

dove caratteristica e sottocaratteristica sono espresse con le prime tre iniziali di ogni nome, ad esempio POR_COE indica un requisito sulla portabilità e coesistenza.

Per la priorità potremmo usare tre numeri, che individuano 3 categorie di priorità:

1. priorità elevata
2. priorità media
3. priorità bassa

Occorre fare attenzione al fatto che la priorità non è intesa come priorità temporale, nel senso che un requisito, che all’inizio del progetto è a priorità bassa, diventa poi a priorità alta a metà progetto, perché altrimenti, il nome del requisito dovrebbe cambiare in corso d’opera.

La priorità di cui si parla è l’importanza del requisito da parte dell’attore che lo ha enunciato.

I diversi attori devono essere individuati, caso per caso, nella fase di analisi.

Gli ultimi simboli, alla fine del nome, sono numeri, del tipo, 2.4.3 ecc., che individuano gerarchie di requisiti.

Un requisito sarà così espresso tramite la notazione:

1.Fornitore.MAN_STA.1.2

indicando così un requisito di priorità elevata, espresso dal fornitore sulla manutenibilità e la stabilità. Il requisito appartiene a una gerarchia ed è così il secondo di un elemento padre avente il numero 1.