Caratteristiche, a cosa serve e fasi dell’Analisi dei Requisiti per lo sviluppo software

In Ingegneria del Software, l’analisi dei requisiti è un’attività preliminare allo sviluppo di un sistema software, il cui scopo è quello di definire le funzionalità che il nuovo prodotto deve offrire, ovvero i requisiti che devono essere soddisfatti dal software sviluppato per soddisfare le esigenze del commitente. L’analisi dei requisiti è una fase presente essenzialmente in tutti i modelli di ciclo di vita del software, pur con diverse enfasi e diverse connotazioni.

Nel tradizionale modello a cascata, l’analisi dei requisiti è la prima fase del processo di sviluppo, e deve concludersi con la stesura di una dettagliata specifica dei requisiti che descrive le funzionalità del nuovo software nella loro interezza ed tale specifica guida le fasi successive di sviluppo, che complessivamente sono volte a realizzare quanto previsto da tale specifica.
Data una specifica, esistono molti modi per realizzarla. Naturalmente la scelta fra le diverse possibiltà non è arbitraria, ma è guidata sia da vincoli di carattere economico, sia dalla necessità di conseguire un’adeguata qualità del prodotto o del progetto stesso.

Per qualità del progetto si intendono quelle caratteristiche che, pur non essendo visibili all’utente, determinano la qualità del prodotto e quelle caratteristiche che offrono un vantaggio economico al produttore del software, rendendo più efficace il processo di sviluppo. Fra le caratteristiche che determinano la qualità del prodotto o del progetto, citiamo l’affidabilità, la modificabilità, la comprensibilità e la riusabilità. L’esperienza accumulata finora dimostra che queste proprietà dipendono fortemente da un’altra, la modularità. Un sistema è definito modulare se è composto da un certo numero di sottosistemi, ciascuno dei quali svolge un compito ben definito e dipende dagli altri in modo semplice.

E’ chiaro che un sistema così strutturato è più comprensibile di uno la cui struttura venga oscurata dalla mancanza di una chiara suddivisione dei compiti fra i suoi componenti, e dalla complessità delle dipendenze reciproche.
La comprensibilità a sua volta, insieme alla semplicità delle interdipendenze, rende il sistema più facile da verificare, e quindi più affidabile.
Inoltre, il fatto che ciascun sottosistema sia il più possibile indipendente dagli altri ne rende più facili la modifica e il riuso. Prima di proseguire nella descrizione, facciamo un accenno a cosa sono queste caratteristiche sopracitate:

• Correttezza: Un programma o comunque un software si dice corretto se si comporta esattamente secondo quanto è previsto dalla sua specifica dei requisiti.
• Affidabilità: Un sistema si dice affidabile quando non esistono o comunque si presentano molto raramente dei malfunzionamenti.
• Robustezza: In termini molto generali un software si dice robusto quando si comporta in maniera ragionevole in situazioni impreviste che vanno dal inserimento di input scorretti a fallimenti sia del software che dell’hardware.
• Efficienza: un sistema si dice efficiente se è poco esoso sia in termini di memoria che tempo CPU.

Alla base della costruzione di un qualsiasi programma vi è un particolare problema elaborativo da risolvere. Questo particolare problema però dovrà essere analizzato prima di partire a scrivere il Software atto a risolverlo. Individuata cioè l’esigenza servirà esplicitarle e verificarne le condizioni di realizzabilità

Questa macrofase si può suddividere ulteriormente in due:

1. Studio di fattibilità, nella quale si chiariscono le istanze dell’utente (ovvero della persona che intende risolvere un problema e intende farsi costruire un sistema di elaborazione).
2. Definizione delle specifiche funzionali, nella quale si precisano le particolari funzioni che debbono essere soddisfatte e i limiti entro i quali si possono realizzare, (tutto ciò derivante dalla caratteristica del problema).

In particolare, la prima delle due fasi di questa macrofase è lo studio di fattibilità, che serve per definire se il progetto è realizzabile o meno. Questa fase prende in esame:

• Le richieste dell’utente.
• Il contesto ambientale in cui verrà calato il prodotto finito (settore, ufficio,ecc).
• Le risorse fisiche disponibili ovvero personale dedicato al progetto, hardware esistente o acquistabile, gli uffici a cui fare riferimento per avviare una ricerca dettagliata delle richieste, le capacità professionali del personale, ecc.
• Le risorse economiche messe a disposizione dal committente che è il nostro l’cliente.
• Un’indagine sui progetti software esistenti che risolvono in parte o completamente il problema.