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

Capitolo 1
1. I requisiti
Il termine "requisito" ha una natura controversa 2 , che viene chiarita da Alan Mark Davis, uno
dei maggiori esperti di ingegneria dei requisiti, come segue:
" Se una compagnia vuole dare in appalto un grande progetto di sviluppo software, deve
definire i requisiti in modo abbastanza astratto da non predefinire alcuna soluzione. I requisiti
devono essere scritti in modo che diversi appaltatori possano fare le offerte proponendo vari metodi
per soddisfare le necessità del cliente. Quando l'appalto è stato assegnato, l'appaltatore deve
scrivere per il cliente una definizione del sistema molto dettagliata, in modo che il cliente possa
capire e verificare cosa il software farà. Entrambi questi documenti possono essere chiamati
documenti dei requisiti del sistema " [1].
La prima distinzione proposta da Davis è, dunque, quella tra requisiti utente 3 , che
rappresentano l'entità (bisogni/necessità dello stakeholder 4 ) ad un alto livello di astrazione ed i
requisiti di sistema 5 (cosa farà il sistema ed i vincoli operativi),nche ne offrono una descrizione al
un livello di maggior dettaglio.
Sebbene la distinzione tra i "ruoli" utente-sistema possa sembrare chiara, alcune volte non è
semplice attuare una separazione netta tra i due livelli descrittivi, così da cadere in errore in questa
fase del processo di sviluppo.
Una seconda classificazione dei requisiti, ancora una volta proposta da A.M. Davis, si basa
sulla pratica del triage 6 : secondo questo approccio, la priorità del requisito rappresenta uno dei
presupposti per stipulare un contratto tra gli stakeholder, che stabiliranno quali requisiti debbano
essere soddisfatti ed entro quali limiti di tempo e di costo.
Per meglio comprendere questo principio, potremmo immaginare di operare con un progetto
ipotetico dotato di risorse illimitate: in tal caso, pur essendo pronti a soddisfare tutte le esigenze
degli stakeholder coinvolti, sarebbe opportuno valutare gli aspetti che siano in grado di apportare
una maggiore soddisfazione e che diverrebbero prioritari.
2 In alcuni casi, un requisito è una formulazione astratta e di alto livello di un servizio che il sistema dovrebbe fornire,
oppure un vincolo di sistema; in altri casi, un requisito è visto come una definizione formale e dettagliata di una
funzione del sistema.
3 Requisiti utente: rappresentano i bisogni/necessità degli stakeholder
4 Stakeholder: Un individuo, un gruppo di persone, un'organizzazione, o altra entità direttamente o indirettamente
interessata al sistema.
5 Requisiti di sistema: definiscono le funzioni, i servizi ed i vincoli operativi del sistema in modo dettagliato. Il
documento dei requisiti ad essi relativo, noto come Documento dei Requisiti di Sistema (o Functional Requirements
Specification) , dovrebbe essere preciso nel descrivere accuratamente cosa debba essere implementato. Esso può
essere parte del contratto tra l'acquirente e lo sviluppatore.
6 Triage: Questo termine, adoperato in campo medico, consiste nel distinguere le urgenze nei pronto soccorso, così da
garantire l'intervento tempestivo ai casi inidcati come urgenti.
10