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

tanto da poter rendere il sistema inutilizzabile nel caso in cui non trovino corrispondenza nella
specifica. Infatti, essi possono essere vincolati a limiti di budget, alle politiche organizzative, di
sicurezza, privacy 30 , alla necessità di interoperabilità con altri sistemi software o hardware.
Una difficoltà che accompagna tali requisiti riguarda la loro verificabilità: infatti, è abbastanza
comune che gli utenti o i clienti si riferiscano ad essi come obiettivi generali che il sistema deve
perseguire, dando la libertà agli sviluppatori di interpretarli in maniera arbitraria. Questa potrebbe
essere una causa di malcontento da parte del commitente, una volta rilasciato il prodotto.
1.6 I requisiti utente e di sistema
I requisiti utente, essendo rivolti a personale non esperto, specificano solo il comportamento
esterno del sistema attraverso una descrizione chiara dei requisiti funzionali e non funzionali. In
effetti, in essi dovrebbero essere concentrati i servizi chiave che devono essere forniti (bisogni ed
esigenze degli utenti), in quanto un requisito che contiene troppe informazioni potrebbe risultare di
difficile comprensione per l'utente e, d'altro canto, limitare lo slancio degli sviluppatori verso
soluzioni innovative.
Dunque, nella definizione di tali requisiti, bisognrebbe evitare l'utilizzo di un linguaggio
specifico che descriva in che modo il sistema venga implementato, così come è sconsigliato
l'utilizzo del linguaggio naturale.
Infatti, mentre l'adozione del primo ci condurrebbe certamente ad un requisito che per
definizione non sarà di utente, l'utilizzo del linguaggio naturale, sebbene possa sembrare il mezzo
più immediato ai fini della comprensione dell'utente, proietterebbe sul requisito ottenuto tutte le sue
lacune (requisiti funzionali, non funzionali, obiettivi di sistema e di progettazione potrebbero non
essere chiaramente distinti, oppure si potrebbe definire in un unico requisito più requisiti).
Dunque, per la definizione dei requisiti utente 31 si potrebbe prediligere un linguaggio naturale,
corredato da diagrammi, che rappresenti il giusto compromesso tra formalismo e comprensibilità.
Essendo destinati agli specialisti, gli aspetti tecnici prendono forma nei requisiti di sistema, ai
quali potremmo pensare come versioni maggiormente dettagliate dei requisiti utente, dato che
esprimono cosa un sistema debba fare e sotto quali vincoli debba operare.
che, coinvolgendo l'intero sistema, non può essere eluso allo stesso modo.
30 I principali tipi di requisiti non funzionali sono: i requisiti di prodotto, i requisiti esterni, i requisiti organizzativi.
31 Durante questa attività, potrebbe essere interessante etichettare i requisiti utente a seconda dell'importanza che riveste
per l'utente, ad esempio come OBBLIGATORIO o DESIDERATO.
20