Metodologie e strumenti dell'Ingegneria dei Requisiti ... - MobiLab

Di conseguenza, la fase di deduzione e comprensione dei requisiti può rivelarsi
particolarmente impegnativa, poichè gli aspetti trattati saranno quelli specifici del dominio di
applicazione, con il quale l'ingegnere del software potrebbe non avere familiarità.
Ancora, capita non di rado, che gli stakeholder non riescano ad esprimere in modo chiaro le
proprie esigenze, che vi siano conflitti tra i requisiti dichiarati dalle diverse figure, oppure di trovarsi
di fronte ad un ambiente dinamico.
Tutti gli aspetti sopraccitati convincono del fatto che, durante questa fase, sia indispendabile
avvalersi del supporto dei committenti, con i quali potrebbero nascere incomprensioni dovute
all'utilizzo da parte di questi ultimi di linguaggi troppo tecnici e punti di vista, a volte, divergenti.
D'altro canto, confrontarsi con un ambiente dinamico, in cui i requisiti cambiano rapidamente,
non consente la definizione precisa del loro numero e delle funzionalità che esprimono.
L'evoluzione, così come una cattiva comunicazione tra l'ingegnere del software ed i
committenti, può comportare una revisione nell'espressione e/o nel contenuto di un requisito;
dunque, terminato lo studio di fattibilità, le successive fasi possono richiamarsi tra loro durante tutto
il processo.
L'obiettivo di questa fase è, infatti, a fronte di una buona comprensione del dominio in cui sarà
sviluppato un sistema software, la definizione dei requisiti che esso debba essere in grado di
soddisfare.
In primo luogo, una profonda comprensione del dominio in cui il sistema opererà aiuterà anche
a calarsi nei diversi scenari che possano verificarsi nell'interazione tra sistema software ed ambiente
circostante. Inoltre, una definizione chiara ed inequivocabile dei requisiti è sicuramente decisiva per
le successive fasi di specifica, progettazione ed, infine, realizzazione del sistema.
Questi due obiettivi possono essere raggiunti in vari modi, a seconda dei fattori che dovranno
caratterizzare il prodotto finale, ma qualunqe metodo di analisi deve prevedere due azioni:
• la costruzione di un glossario ai fini della definizione del dominio;
• la redazione dei requisiti utente, relativi sia agli aspetti funzionali che non funzionali del
sistema.
Il glossario sarà un documento nel quale verranno definiti in maniera univoca tutti i termini
significativi in relazione allo specifico contesto e che verranno adoperati nella descrizione degli
obiettivi.
L'operazione attraverso la quale si perviene ad un documento siffatto consta di alcune fasi , in
ciascuna delle quali viene attuata una operazione di 'filtraggio' su di un testo iniziale, fino a
40