Definizione e classificazione dei requisiti nell’Ingegneria dei Requisiti
Il termine “requisito” ha una natura controversa in quanto 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. Questa controversa 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”.
La prima distinzione proposta da Davis è, dunque, quella tra requisiti utente, che rappresentano l’entità ovvero bisogni/necessità dello stakeholder ad un alto livello di astrazione ed i requisiti di sistema (cosa farà il sistema ed i vincoli operativi),nche ne offrono una descrizione al un livello di maggior dettaglio. Bisogna ricordare che lo stakeholder è rappresentato da un individuo, un gruppo di persone, un’organizzazione, o altra entità direttamente o indirettamente interessata al sistema.
D’altra parte, 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: 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.
La situazione appena descritta non è realistica, dunque è ancor più evidente quanto nei progetti concreti sia necessario ridurre la quantità dei requisiti da soddisfare così da semplificare i progetti ed eliminare inutili sprechi di risorse. Questa considerazione comporterebbe, in definitiva, validazioni più mirate da parte del committente e degli altri stakeholder, fornendo anche una flessibilità maggiore rispetto alle eventuali modifiche da apportare ai requisiti. Ciò risulta perfettamente in linea se consideriamo le ultime stime pubblicate dallo Standish Group, dalle quali si evince che circa il 45% delle funzionalità di un sistema sia completamente inutilizzato, ed il 20% viene utilizzato solo raramente.
Tuttavia, i requisiti rappresentano il patrimonio di progetto più importante, dal momento che costituiscono l’anello di congiunzione tra i bisogni e le percezioni degli stakeholder e le soluzioni tecnologiche progettate dagli esperti software.
Pseudo requisiti
Una considerazione interessante in merito alle caratteristiche richieste ad un sistema riguarda il concetto di “pseudo requisito”, ovvero un requisito secondario. Vengono così indicati i vincoli imposti dal cliente o dall’ ambiente in cui opererà il sistema, come quelli sull’implementazione, relativi alle interfacce, operazioni, packaging, vincoli di natura legale.
Ne sono un esempio:
“Il linguaggio di programmazione adottato dovrà essere Java”,
oppure
“La piattaforma dovrà interfacciarsi con documenti scritti con MS Word su Windows XP”.
