Raccolta requisiti: il primo passo verso un progetto di successo
Metodi di raccolta requisiti per i software
Ogni progetto ha inizio con il manifestarsi di un bisogno da parte di un committente che viene condiviso con un fornitore, il quale ha la responsabilità di soddisfarlo attraverso una soluzione che sarà il risultato del progetto stesso.
Durante questa prima fase, nella quale il bisogno è sentito ma non completamente definito, viene richiesto al fornitore un grande sforzo di inventiva per comprendere l’esigenza e progettare, anche se solo grossolanamente, una soluzione attuabile. Tale sforzo di ingegno e creatività normalmente daranno vita ad una serie di condizioni che determineranno lo svolgimento del progetto stesso, tra cui tempistiche stimate e budget.
E' responsabilità del project manager (o dell’analista qualora ne esista uno) raccogliere tutte le informazioni dal cliente ed organizzarle per definire al meglio le aspettative, il bisogno ed il comportamento atteso della soluzione.
Questo è il motivo per cui questa fase è una delle più delicate di un progetto. Specialmente nel settore informatico, durante la stesura e l'approvazione del documento di analisi dei requisiti si possono verificare le peggiori incomprensioni che porteranno ad un risultato non adeguato alle aspettative del cliente, e a volte neppure coerente con il reale bisogno di quest’ultimo.
Per riuscire ad ottenere una rappresentazione efficiente del bisogno, e poterla trasferire con la massima efficacia al team che dovrà implementare la soluzione attesa, esistono diversi metodi, alcuni dei quali più orientati alla rappresentazione del flusso funzionale, altri più orientati alla rappresentazione del flusso delle informazioni e della loro archiviazione; altre infine ad una rappresentazione più visuale e fortemente legata alla capacità “scenica” della narrativa.
Procediamo con ordine e vediamo il primo metodo di raccolta requisiti per il software, presentato da Ivar Jacobson nel 1996 che si basa sulla rappresentazione del flusso di azioni che rappresentano il comportamento di un utente (o del sistema) in una determinata situazione. Tale “meta linguaggio” descrittivo ha preso il nome diUML (Unified Modeling Language,) e ancora oggi è spesso impiegato in discipline come ilBPMN (Business Process Model and Notation) per la descrizione non solo di sistemi informatici, ma di comportamenti e processi aziendali. Questa descrizione del processo si basa sulla rappresentazione visiva di azioni e scelte (o condizioni) che caratterizzano una procedura. E’ spesso impiegato nell’esposizione di una soluzione IT, o nella raccolta requisiti per illustrare cosa dovrà fare una soluzione informatica per soddisfare un’aspettativa, e quindi quale comportamento atteso dovrà riprodurre.
Il secondo metodo è antecedente all’UML, e descrive come le informazioni trattate da una soluzione informatica verranno immagazzinate e trattate: il modello Entity-Relationship (o E-R). Questo modello di rappresentazione dei dati è basato sulla descrizione delle strutture di dati relazionali che saranno impiegate per l’archiviazione ed il trattamento delle informazioni del sistema. Il modello di descrizione ER è basato sulla definizione di entità, ovvero contenitori di dati strutturati, e relazioni, ovvero connessioni logiche tra le informazioni disponibili in entità distinte. Il modello ER fonda le sue radici nel 1976 grazie all’ingegno del prof. Peter Chen il quale decise di tradurre l’algebra relazionale - matematica insiemistica alla base delle logiche di funzionamento di tutti i RDBMS oggi diffusi sul mercato (da MySQL a Oracle, da SQL Server a PostgreSQL) - in un meta linguaggio visivo dove ogni tabella (o insieme) fosse rappresentato da un’entità astratta, ed ogni relazione tra entità distinte fosse caratterizzata dal concetto di cardinalità, e potesse essere descritta come un semplice collegamento.
Questi linguaggi di descrizione insieme alla capacità di ascolto costituiscono degli strumenti essenziali per comprendere e rappresentare in modo comprensibile e ripetibile i bisogni del cliente. Tuttavia si tratta di strumenti molto tecnici che richiedono all’interlocutore una capacità di astrazione ed una competenza che non si può dare per scontata per ogni committente.
ecco perché alla fine degli anni ’90 si è cominciato a sviluppare un nuovo approccio per la raccolta requisiti di un software basato sulla narrazione. E’ stato provato, infatti, che la narrazione coinvolge molto di più l’interlocutore, e che lo proietta all’interno di un contesto non tecnico nel quale può immedesimarsi e descrivere con maggior precisione l’aspettativa e simulare - virtualmente - quali azioni compirà, o vorrà compiere, con il sistema che verrà creato. Questo approccio mutuato dall’ambito pubblicitario viene rappresentato dal termine Storytelling, che nell’ambito informatico assume la sua accezione più stretta di “racconto della storia di un utente”. L’approccio narrativo, partendo dall’esperienza immaginaria di un utente all’interno del sistema, permette a chi deve descrivere il comportamento atteso di immedesimarsi e immaginare, attraverso il coinvolgimento delle proprie esperienze, il sistema non nella sua interezza - che richiederebbe un grande sforzo di astrazione - ma nell’azione specifica che compirà un utente in un istante specifico del tempo.
La raccolta di storie diviene quindi la base del documento di raccolta requisiti attraverso cui è possibile descrivere il funzionamento del sistema, creando un filo conduttore comune a tutte le storie e consentendo al team a sua volta di immedesimarsi nell’utilizzo del sistema che andrà a generare. Questo approccio risulta particolarmente efficace per descrivere soluzioni complesse, ed è facilmente comprensibile da qualunque interlocutore consentendo un’approvazione più rapida ed una rappresentazione più chiara della fase progettuale della soluzione proposta.
Marco Merlino
Questo articolo è stato pubblicato anche da European School of Project Management consultabile attraverso il seguente link