In un progetto di sviluppo software, la formalizzazione dei requisiti è una fase complessa. Quando un utente generico (ad esempio un committente) si ritrova a dover descrivere all’analista quelle che dovranno essere le caratteristiche (funzionali e non) del software che quest’ultimo dovrà sviluppare, ha infatti bisogno di utilizzare un linguaggio esaustivo e il meno ambiguo possibile ritrovandosi a parlare di questioni tecniche per le quali in genere non ha particolare competenza (requisiti utente, del sistema, funzionalità operative, qualità dell’applicativo, appeal grafico, usabilità e così via). Sta dunque all’analista guidare l’utente in modo che il processo di collezione dei dati sia completo e chiaro.
Esempi
Se l’obiettivo è tradurre le specifiche richieste in un formato vicino al linguaggio di programmazione prescelto, il rischio è quello di perdere qualche caratteristica importante, e scoprirlo solo durante il test davanti all’utente! Chi da anni si occupa di sviluppo software propone diversi strumenti in termini di tecniche e strumenti che possano aiutare in questa delicata fase di formalizzazione.
La guida “Requisiti by Example” può essere uno strumento utile per chi, meno pratico, ha la necessità di accostarsi a questi processi per la prima volta. Non si tratta di uno standard ma solo di un insieme di buone pratiche (esempi) proposte dall’esperto di sviluppo software Adriano Comai, uno schema di classificazione per organizzare domande ed esempi senza che mai venga usato il termine “vincolo”, che solitamente indica un requisito non negoziabile, perché sulla base della propria esperienza alcuni requisiti considerati bloccanti sono stati modificati se non addirittura eliminati in corso d’opera.
Lo schema di classificazione è strutturato in otto categorie principali sintetizzate in un acronimo facile da ricordare (FOCUS-TBD): Funzionalità, Operatività, Conformità, Usabilità, Sicurezza, Tempi, Budget, Documentazione, manutenzione e supporto. Per ognuno degli otto punti viene fornita una scheda che si può usare come check list e che è corredata da esempi pratici, per far capire allo stakeholder (l’utente generico) il livello di astrazione necessario a descrivere le sue esigenze.
Casi d’uso
Un’altra tecnica abbastanza diffusa è il metodo dei casi d’uso: un insieme di descrizioni su come può essere utilizzato un sistema, da leggere come fosse un manuale utente. Pioniere di questo sistema è stato Ivar Jacobson, nel 1987 che lo ha implementato mediante il linguaggio UML, e che ne ha aumentato la diffusione dal 1992 mediante il libro “Object-Oriented Software Engineering. A Use Case Driven Approach“.
I casi d’uso sono storie concrete di utilizzo e identificano in modo puntuale: utenti finali del sistema (persone o altri sistemi esterni), obiettivi da conseguire usando il sistema (solitamente un caso d’uso per ogni obiettivo), scenari concreti di ogni modalità d’uso (condizioni di inizio, aspettative dell’utente finale, iter dell’interazione, eventuali altri soggetti coinvolti, ecc.).
Pur se rapidamente diffusi in relazione ai linguaggi a oggetti, non costituiscono però la panacea di ogni male, perché si deve prestare attenzione all ‘ ambito di applicazione e ad alcuni errori da evitare nel loro utilizzo. L’ambito adeguato riguarda i sistemi che prevedono interazioni operative, strutturate da e verso attori esterni al sistema. Non sono invece adatti per la descrizione di sistemi di datawarehouse, di CAD o in caso di Compilatori. Gli errori più comuni? Scrivere troppi casi d’uso (l’utente finale non li leggerà né approverà mai); descrizioni di funzionalità interne al sistema inadeguate; eccessiva frammentazione nell’analisi delle funzionalità elementari; rappresentazione esclusiva mediante diagrammi senza opportune descrizioni di testo.
Entità
La tecnica dell’Entity Relationship è stata ideata per la modellazione dei dati e verte sulle Entità cioè i concetti principali dell’ambito applicativo (del problema) che si sta affrontando, cercando di elencarli e poi di associare gli opportuni attributi. In ultimo, si richiede di stabilire le relazioni fra le entità. Sembra evidente che questo sistema venga usato nei requisiti relativi ai sistemi di database ma di fatto si applica bene anche ad altri ambiti applicativi rispetto a qualsiasi ambito di business.
