Ingegneria dei requisiti
Requisito
I requisiti di un sistema sono le descrizioni di cosa il sistema deve fare, cioè i servizi che offre e i vincoli sul suo funzionamento. Due definizioni un po' più formali sono:
- ponendoci dal punto di vista del bisogno, requisito è una condizione necessaria a un utente per risolvere un problema o raggiungere un obiettivo;
- dal punto di vista della soluzione, invece, requisito è una condizione che dev'essere soddisfatta da un sistema per adempiere a un obbligo.
I requisiti hanno a che vedere con il processo di sviluppo del software; tuttavia la loro gestione è qualcosa di costante, che viene iterato lungo tutto il ciclo di vita di un progetto.
Requisiti utente e di sistema
"Requisito" è un termine leggermente ambiguo, in quanto viene usato per indicare sia una richiesta generale (astratta, di alto livello) sia una definizione formale e dettagliata di una funzione del sistema. È bene separare questi differenti livelli di descrizione; per questo, distinguiamo tra requisiti utente (di alto livello) e requisiti di sistema (più dettagliati).
Requisiti di prodotto e di processo
È bene anche distinguere tra requisiti di prodotto (dei bisogni o dei vincoli sul software da sviluppare) e requisiti di processo (dei vincoli sullo sviluppo del software).
Requisiti funzionali e non
Un'ulteriore distinzione viene fatta tra:
- requisiti funzionali — i servizi che il sistema deve fornire (cioè la sua interfaccia);
- requisiti non funzionali — i vincoli sui servizi che il sistema fornisce (requisiti su prestazioni, manutenibilità, sicurezza, affidabilità...).
Ma tale distinzione non è sempre netta: ad esempio, il requisito di limitare l'accesso ai soli utenti autorizzati (apparentemente non funzionale) può essere sviluppato più in dettaglio fino a richiedere un servizio di autenticazione (requisito chiaramente funzionale)!
Piano di qualifica
Per garantire il rispetto dei requisiti entra in gioco il piano di qualifica, che consiste nel definire le strategie di verifica e scegliere metodi, tecniche e procedure da usare per la validazione; ha quindi a che fare con due processi:
- Verifica: accertare che l'esecuzione delle attività di processo non abbia introdotto errori (
Did I build the system right?
); rivolta ai processi (e svolta sui loro prodotti), per accertare il rispetto di norme e procedure. - Validazione: accertare che il prodotto realizzato corrisponda alle attese (
Did I build the right system?
); rivolta ai prodotti finali.
La validazione dev'essere una self fulfilling prophecy, cioè bisogna essere certi che non fallirà; la verifica serve proprio a garantire questo. Infatti, il processo di verifica deve assicurarci che lavoriamo bene non a posteriori ma mentre lavoriamo. Se la verifica assicura i requisiti, la validazione li accerta. Il piano di qualifica nasce assieme ai requisiti.
Attività
Il processo di ingegneria dei requisiti raggruppa quattro attività:
- studio di fattibilità (stabilire se il sistema in questione è redditizio);
- acquisizione[1] e analisi dei requisiti;
- specifica dei requisiti (cioè formalizzare i requisiti);
- validazione dei requisiti.
Tale processo riguarda tutti gli stakeholders. In genere non è possibile soddisfare i requisiti di ognuno di essi, quindi bisogna quindi trovare un buon compromesso; questo presuppone quindi che gli stakeholders vengano identificati, "pesati" e interpellati.
Studio di fattibilità
Lo studio di fattibilità è uno studio breve e chiaro che consiste nel valutare rischi, costi e benefici legati al sistema da sviluppare: tale sistema contribuisce agli obiettivi generali dell'organizzazione? può essere sviluppato rispettando determinati vincoli economici, con la tecnologia corrente? può essere integrato con altri sistemi in uso? una risposta negativa in una qualunque tra queste domande inficia la fattibilità del sistema. Lo studio di fattibilità dovrebbe descrivere in modo chiaro gli obiettivi del progetto e valutare approcci alternativi, per capire se il progetto proposto è la migliore alternativa.
Acquisizione e analisi dei requisiti
Dopo aver compiuto uno studio di fattibilità, gli ingegneri del software devono lavorare assieme a clienti e utenti per individuare il dominio di applicazione e i requisiti del sistema. In generale, tutti gli stakeholders sono coinvolti in questa attività, che prende il nome di "acquisizione e analisi dei requisiti" e si svolge a grandi linee nel seguente modo.
- Studio dei bisogni e delle fonti; si cerca di individuare un insieme (non strutturato) di requisiti. Per fare questo, si può:
- interrogare gli stakeholders — con interviste chiuse (insieme predefinito di domande) o aperte;
- discutere con gli stakeholders alcuni scenari del sistema (uno scenario è la descrizione di un esempio di interazione col sistema);
- discutere con gli stakeholders i casi d'uso del sistema (tramite diagrammi che individuino le interazioni tra il sistema e i suoi utenti);
- studiare un prototipo del sistema;
- discutere in modo creativo, tramite brainstorming;
- osservare il sistema in modo etnografico, concentrandosi sul suo funzionamento abituale.
- Classificazione e organizzazione dei requisiti; l'insieme dei requisiti viene strutturato, dividendo i requisiti in gruppi che rispecchino l'architettura del software (qui, progettazione e analisi procedono spesso insieme).
- Modellazione concettuale del sistema (ad esempio tramite un diagramma dei casi d'uso).
- Assegnazione dei requisiti a parti distinte del sistema.
- Negoziazione con il committente e con i sotto-fornitori: essendoci diversi stakeholders, è normale che alcuni requisiti siano in conflitto; bisogna dare una priorità ad ogni requisito e negoziare quelli incompatibili per trovare un compromesso.
I requisiti possono cambiare (a causa di condizioni esterne o anche solo perché l'analisi si è approfondita e ha introdotto nuovi requisiti); proprio per questo, è bene notare che la sequenza di passi riportata diventa spesso un ciclo che si ripete.
Specifica dei requisiti
I requisiti vanno specificati in un documento, usando un linguaggio formale o grafico. [?? ...] Vanno ordinati per priorità, classificati e identificati univocamente.
Validazione dei requisiti
Validare i requisiti vuol dire controllare che essi definiscano effettivamente il sistema che il cliente richiede. A partire dal documento generato durante la specifica dei requisiti, bisogna assicurarsi che questi siano:
- non ambigui;
- necessari — ogni requisito deve soddisfare qualche bisogno esplicito (dal capitolato di appalto);
- sufficienti — ogni bisogno dev'essere soddisfatto da qualche requisito del documento;
- coerenti;
- realistici — i requisiti devono essere implementabili con la tecnologia a disposizione;
- verificabili — si dev'essere in grado di dimostrare che il sistema soddisfa i requisiti.