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

Tale attività confluisce in un documento di specifica dei requisiti software, appunto, per il
quale vi è la possibilità di adoperare un linguaggio formale, oppure strutturato, come abbiamo
precedentemente discusso. Esso potrà essere dotato di una semantica formale oppure convenzionale
(dunque più intuitiva) e di una sintassi controllata.
L'operazione di specifica offre, innanzitutto, la possibilità di tradurre in frasi, cioè concetti
concreti, quel che sino a poco prima era solo un'idea di come il sistema software dovesse
comportarsi, poi di poter comunicare e condividere tali concetti con il team di progetto e,
naturalmente, con il committente.
Il documento di specifica dei requisiti potrà essere eventualmente analizzato da uno strumento
automatico.
È, pertanto, necessario adottare un metodo che consenta di svolgere questa attività in maniera
logica e graduale, così da focalizzare la nostra attenzione sugli aspetti più significativi (e, spesso, più
complicati da trattare).
Durante l'attività di specifica dei requisiti bisognerà assegnare a ciascun requisito un
identificativo univoco, così da poter documentarne l'origine 71 più agevolmente e gestirne la
tracciabilità lungo tutto il suo ciclo di vita.
Bisognerà prevedere anche una gestione della versione di ciascun requisito, così da poter
tracciare anche tutte le modifiche effettuate su di esso.
Un requisito può essere specificato, oltre che dall'indentificativo ed dalla descrizione, anche da
un insieme di attributi che ne vanno a caratterizzare:
• la tipologia (funzionale o non funzionale ed, eventualmente, specificare a quele classe
appartiene);
• chi lo ha richiesto, la data di richiesta e dell'ultima modifica apportata al requisito;
• il numero di versione, così da tener traccia dell'evoluzione subita;
• l'importanza secondo il punto di vista del committente (ad esempio: obbligatorio,
desiderabile, opzionale);
• la priorità di implementazione del requisito, quindi rispetto al suo rilascio;
• lo stato che indichi, ad esempio, se il requisito sia stato approvato, implementato, verificato,
eliminato;
• il criterio di accettazione;
• il livello di stabilità del requisito: infatti, la specifica e lo sviluppo di un sistema possono
protrarsi per lungo tempo, durante il quale le esigenze degli stakeholder possono mutare,
71 Casi d'uso, input pervenuti dagli stakeholder, standard aziendali, regole di business, vincoli legislativi, ecc.
52