30 marzo 2026

Come scrivere analisi funzionali efficaci

Erika è analista funzionale specializzata in applicativi Power Apps e Dynamics 365. Quando non lavora alle analisi funzionali, le piace leggere, scrivere, andare a cinema o teatro.

L’analisi funzionale rappresenta uno strumento essenziale nei progetti di sviluppo software, in quanto ponte tra i requisiti di business e la soluzione tecnica, traducendo i bisogni in specifiche chiare e verificabili.

Cosa si intende per “specifiche chiare”?

L’analisi funzionale (spesso abbreviata in AFU) consente di poter sempre ricercare in maniera efficace le implementazioni e logiche dell’applicativo. Scrivere un documento funzionale efficace consente un on-boarding più rapido per eventuali nuovi membri e decentralizza la conoscenza del software dai membri più storici. Tutte le informazioni circa le funzionalità sono alla portata di tutti, dallo sviluppatore allo stakeholder, creando quindi una knowledge base comune e facilmente consultabile.

Cosa si intende per “specifiche verificabili”?

Il documento funzionale consente di tenere traccia di tutte le implementazioni funzionali di un progetto. Se scritta con chiarezza, quindi, consente di:

Risalire (consultando magari versioni precedenti) a ragionamenti effettuati nel passato che non sono più in essere nel caso in cui il business desideri ripristinarli, riducendo al minimo la perdita di informazioni;
Verificare la situazione attuale (as-is), ossia di consultare in maniera puntuale quindi le funzionalità ad oggi presenti nell’applicativo sviluppato;
Descrivere i cambiamenti che arriveranno, le Change Request, richieste dagli stakeholder. In questo particolare caso, l’AFU è spesso utilizzata come mezzo, dopo gli allineamenti tramite mail e call, per convalidare quanto concordato prima di procedere con i nuovi sviluppi previsti.

Queste sue importanti funzioni rendono il documento funzionale uno strumento fondamentale per conoscere, in ogni dato momento, il perimetro del proprio progetto con precisione, distinguendo ciò che rientra o non rientra tra le richieste effettuate.

Scrivere una buona analisi funzionale, quindi, è una skill che migliora nel suo insieme la qualità del lavoro day-by-day all’interno di un progetto e quindi è fondamentale imparare a redigere delle buone analisi e spendere del tempo, soprattutto, per farlo come si deve. Purtroppo non sempre abbiamo la possibilità di far parte di un gruppo di lavoro abbastanza strutturato da riconoscere una figura sola che assolva alla funzione di analista funzionale e potrebbe capitarci di doverne scrivere una. Per questo motivo, ho scelto un piccolo modello che possa essere di aiuto anche a chi si affaccia alla scrittura di questi documenti senza nessuna esperienza pregressa.

Vediamo cosa è importante includere in un’analisi funzionale con specifiche chiare e verificabili.

1. Introduzione

In questa sezione, è importante definire il contesto del progetto, gli obbiettivi che si intendono raggiungere. Nell’introduzione si andrà a definire il nome del progetto e si descriveranno le motivazioni che hanno spinto il business a richiedere questo sviluppo.

Es. Assicurazione X necessita di un portale per gestire in maniera efficace le pratiche relative ai sinistri. Il nome scelto è Y, e si mira a gestire i seguenti aspetti: A, B, C

Es 2. Banca D necessitava di un sistema più snello per la gestione delle richieste mutuo, che possa essere automatico e che richieda meno lavoro da parte del personale in sede. Rientra nel perimetro, quindi, l’integrazione con il sistema E utilizzato da Banca D.

2. Cronologia delle modifiche

Personalmente consiglio la creazione di una tabella che tenga conto delle varie modifiche che sono state effettuate al documento funzionale, per due ragioni principali:

Per avere subito presente la data dell’ultima modifica effettuata (e comprendere quindi se sia già ora di modificarla)
Per chiarezza verso chi dovrà leggere, per esempio nel momento in cui l’approvatore dovrà risalire a che cosa è stato modificato.

All’interno di questa tabella si andranno a inserire delle colonne come “Data modifica AFU”, “Ambiti oggetto di modifica AFU”, “Colore della modifica apportata”.

Andando a sottolineare nell’interno documento esclusivamente le modifiche apportate è un ottimo strumento per rendere chiara ed efficace una consultazione puntale solo delle ultime implementazioni, senza la necessità di dover ricercare nel testo quello che ci serve.

3. Elenco degli stakeholder di progetto (approvatori)

Un capitolo di fondamentale importanza (soprattutto nei grandi progetti) è una definizione precisa degli attori del progetto lato business con cui si andrà a condividere il documento funzionale: si tratta di chi in effettivo si occuperà dell’approvazione dell’AFU.

Per una rapida compilazione lato business, consiglio la creazione di una tabella con colonne come “Nome Stakeholder” “Ruolo” e “Data approvazione” al fine di tenere traccia degli OK o dei KO del reparto business rispetto a quanto scritto in AFU.

4. Indice

In questo capitolo è necessario creare un sommario dei contenuti.

5. (Facoltativa) Allegati

Una tabella pensata per facilitare la consultazione dei documenti allegati all’interno dell’AFU senza la necessità di raggiungere la pagina in questione.

6. Requisiti funzionali

A questo punto siamo pronti per andare a elencare le nostre funzionalità capitolo per capitolo. E’ importante tenere a mente qualche appunto quando andiamo a descriverle una per una:

E’ importante che il titolo sia estremamente chiaro: spesso potrebbe capitare di dover andare a ricercare una funzionalità di cui non ci ricordiamo precisamente la locazione all’interno del documento; scrivere dei titoli parlanti ci consente di ricercare più agevolmente il punto giusto tramite parola chiave. Assicuriamoci quindi di inserire un titolo che riassuma al meglio la funzionalità stessa.
In caso di CR, nel descrivere la funzionalità vale la pena di soffermarsi su qual è la situazione as-is al momento in cui si scrive, per poi procedere a dettagliare la modifica richiesta, sempre per questioni di chiarezza e verificabilità.

Es. Quest’evolutiva mira a modificare il processo as-is…

In caso di prima implementazione, invece, è dovere di chi sta scrivendo l’AFU di descrivere chiaramente il contesto in cui si andrà a inserire la nuova funzionalità (che cosa impatterà, che cosa aggiungerà al funzionamento generale e le logiche di compilazione, (avvalendosi anche di strumenti come i diagrammi, mock-up, screen o altro per spiegare in maniera più efficace il ragionamento);
Fondamentale un rimando al capitolo obbligatorio “Vincoli e assunzioni”, di cui parliamo subito.

7. Vincoli e Assunzioni

Se la soluzione tecnica concordata include delle limitazioni di funzionalità per qualsiasi motivo (performance, impossibilità di aggiornare in tempo reale un dato, una mancata feature per ragioni tecniche) è importante esplicitare qui di cosa si tratta. Il capitolo “Vincoli e assunzioni” si rivelerà di estrema importanza quando ci sarà la necessità di ricordare come mai non si è potuto, per esempio, dettagliare ed esplodere oltre una certa funzionalità in un dato momento della fase di sviluppo.

Ogni progetto vedrà questa scaletta modificarsi: ogni analisi funzionale è unica e vi capiterà di incontrare (o redigere voi stessi!) delle AFU molto dettagliate o molto più superficiali di quanto ho spiegato qui, ma è fondamentale tenere a mente che una buona analisi funzionale è un solido punto di partenza e come tale è importante tenere a mente che il tempo speso per scrivere analisi non è tempo perso, ma assicurazione di un proseguimento più lineare e chiaro per tutto il team.