Se chiediamo all'AI di disegnarci una mappa applicativa senza dirle su quale progetto stiamo lavorando, otteniamo un disegno plausibile ma non specifico. Abbiamo fornito all'AI una richiesta incompleta, ottenendo un risultato mediocre.

Un Business Analyst può adottare un Prompt Engineering efficace applicando sei tecniche descrittive:

• dare contesto
• mostrare esempi
• specificare i vincoli di output
• spezzare i task complessi in step
• chiedere all'AI di ragionare prima di eseguire
• e definire ruolo, stile o tono.

Sono le sei best practice di Prompting indicate da Anthropic all'interno della competenza Description del framework di AI Fluency.

In questo articolo, le vediamo applicate a sei deliverable che il BA lavora comunemente (mappa applicativa as-is, modello entità relazioni, mappa delle integrazioni, diagramma di flusso, workshop di raccolta requisiti e documento di analisi funzionale).

Per ognuno di questi deliverable dell'analisi funzionale di progetto, vediamo un prompt vago e un prompt efficace messi a confronto.

Guarda il video

Questo articolo nasce da un video del canale YouTube di Augmented Consultant.

Se preferisci la versione parlata, puoi guardarlo qui sotto.

1. Cosa cambia tra un prompt vago e un prompt descritto bene?

La competenza che sta alla base delle sei best practice che vedremo esemplificate tra poco si chiama Description, ed è la seconda delle quattro D del framework di AI Fluency di Anthropic.

Imparare a dominare la competenza Description ci permette di alimentare l'AI con prompt efficaci.

Cosa cambia tra un prompt vago, e uno descritto bene?

In primis, cambia la quantità di rilavorazione: un prompt vago produce un output plausibile ma generico, che va corretto riga per riga, mentre un prompt descritto bene produce un primo draft già utilizzabile.

La Description si articola su tre dimensioni:

1. la Product description (cosa vogliamo, in termini di output, formato, audience e stile)
2. la Process description (come vogliamo che l'AI affronti il lavoro, con istruzioni, passaggi ed esempi)
3. e la Performance description (come vogliamo che l'AI si comporti durante la collaborazione, se concisa o dettagliata, se vogliamo che ci assecondi o che ci sfidi nel ragionamento).

Se vuoi il quadro completo delle quattro competenze che costituiscono il framework dell'AI Fluency, lo trovi in questo articolo del blog: Le 4 D dell'AI Fluency per Business Analyst e Project Manager.

Se invece vuoi entrare nel vivo del Prompting efficace per il BA, continua a leggere qui sotto.

Un'avvertenza: il Prompting è un processo iterativo, che si affina attraverso cicli brevi di Description e Discernment.

I prompt che seguono non sono formule da copiare alla lettera, ma template di partenza utili per pensare la comunicazione con l'AI, da cui prendere spunto per le tue prossime interazioni.

Vediamo, per prima cosa, come si configura il cliente fittizio che utilizziamo per esemplificare la competenza descrittiva di Prompt Engineering, nel caso di un Business Analyst alle prese con un progetto.

2. Su quale progetto sono calati gli esempi?

Gli esempi sono calati sul cliente fittizio ACME: un ente della Pubblica Amministrazione che introduce Salesforce nell'ambito di un'architettura legacy preesistente.

ACME eroga strumenti finanziari agevolati alle PMI e sta realizzando un nuovo portale autenticato dove le imprese potranno presentare in digitale la domanda di accesso ai prodotti finanziari.

Il portale, che sarà realizzato su tecnologia Salesforce, si appoggia a un'architettura legacy fatta di anagrafica, gestionale, middleware e documentale.

Nel progetto, il Business Analyst è la persona che deve capire e rappresentare i sistemi, i processi, e i dati della soluzione as-is e to-be, unendo alla raccolta requisiti l'analisi degli applicativi.

Per farlo, il Business Analyst produce una serie di deliverable, tra cui: diagrammi di flusso, mappe architetturali, matrici e documenti.

3. Esempi delle sei tecniche di prompt engineering per il Business Analyst?

Vediamo come il Business Analyst può utilizzare le best practice di Prompt Engineering per realizzare i deliverable di progetto di cui è responsabile.

a. Come si dà contesto all'AI per disegnare la mappa applicativa as-is?

Dare contesto significa dire all'AI chi siamo, da dove partiamo e perché stiamo lavorando: senza queste informazioni è costretta a indovinare i sistemi del cliente.

È la prima best practice ed è anche la più sottovalutata.

Prendiamo la mappa applicativa di alto livello as-is, quella che serve a fotografare i sistemi del cliente prima di disegnare la soluzione.

Prompt vago:

> "Disegnami la mappa applicativa as-is di un cliente che sta introducendo Salesforce."

Con una richiesta di questo tipo l'AI produce una mappa plausibile ma generica, con sistemi inventati che non c'entrano con ACME, e ci ritroviamo a lavorare su un output quasi inutilizzabile.

Dobbiamo buttare via tutto oppure correggere riga per riga.

Non perché l'AI abbia sbagliato, ma perché non le abbiamo dato niente su cui lavorare.

Prompt efficace:

> "Sono un Business Analyst nel team di un system integrator che sta realizzando un nuovo portale Salesforce per un ente della PA che eroga finanziamenti agevolati alle PMI. Devo disegnare la mappa applicativa di alto livello as-is da presentare al prossimo incontro con l'IT del cliente. I sistemi esistenti sono: un'anagrafica che espone i dati tramite un layer di API, un gestionale legacy dove il backoffice lavora le pratiche, un middleware che fa da strato di integrazione, un sistema documentale per gli allegati e un portale B2C già esistente. Disegnami la mappa applicativa as-is rappresentando questi sistemi e i flussi di dati principali tra loro."

La differenza è evidente, e sta in quattro informazioni che nel primo prompt non c'erano: chi siamo, cosa esiste già, perché ci serve la mappa applicativa, e per chi la stiamo preparando.

b. Come si usa un esempio per far disegnare il modello entità relazioni?

Mostrare un esempio del formato che vogliamo fissa il pattern: l'AI lo emula invece di scegliere da sola notazione e livello di dettaglio.

A volte mostrare è più efficace che spiegare.

Diamo all'AI un campione del tipo di output che ci serve, e lei lo replica su tutto il resto.

Prompt vago:

> "Fammi il modello entità-relazioni della soluzione target del portale."

Il rischio, qui, è che l'AI scelga una notazione e un livello di dettaglio casuali, magari descrivendo tutto a parole invece di produrre il diagramma.

Prompt efficace:

> "Devo modellare le entità della soluzione target del portale. Voglio che usi questa notazione, ti do un esempio: 'Impresa, attributi (ragione sociale, partita IVA, stato), relazione: una Impresa ha da uno a molti Utenti'. Seguendo esattamente questo formato per ogni entità, modella le entità principali della soluzione: Impresa, Utente, Domanda, Allegato, Esito della domanda. Per ogni entità elenca gli attributi chiave e le relazioni con la cardinalità."

Con una sola riga di esempio abbiamo eliminato l'ambiguità sulla forma, e possiamo concentrare la revisione sul contenuto del modello invece che sulla formattazione.

c. Come si vincolano i formati di output per la mappa delle integrazioni?

Dichiarare formato, lunghezza, struttura e notazione serve ogni volta che il deliverable deve entrare in un documento con una forma precisa.

La mappa delle integrazioni della soluzione target è un buon banco di prova: deve dire chi parla con chi, con quale dato e in quale direzione.

Prompt vago:

> "Descrivimi le integrazioni della soluzione target."

Con una richiesta così aperta rischiamo di ottenere un testo lungo e discorsivo, dove le informazioni ci sono ma sono annegate nella prosa, inutilizzabili in un documento di analisi senza un lavoro di riscrittura.

Prompt efficace:

> "Mappa le integrazioni della soluzione target del portale. Voglio l'output in due formati. Primo: una tabella con queste colonne: sistema sorgente, sistema destinazione, dato scambiato, direzione del flusso, modalità di integrazione. Secondo: una vista sintetica a blocchi che mostri il portale Salesforce al centro, il middleware come strato di integrazione, e i sistemi legacy collegati (anagrafica via API, gestionale, documentale per gli allegati). Non superare le quindici righe nella tabella e tieni i nomi dei sistemi coerenti tra tabella e vista a blocchi."

Notiamo il dettaglio finale, che è quello che fa risparmiare più tempo: chiedere la coerenza dei nomi tra i due formati evita la revisione incrociata che di solito ci tocca fare a mano.

d. Come si spezza in step il diagramma di flusso di acquisizione di un nuovo utente?

Quando il compito è articolato, indicare all'AI l'ordine dei passaggi evita il flusso lineare che ignora attori, decision point e casi negativi.

Il processo as-is con cui un nuovo utente impresa viene acquisito sul portale ha più attori e più diramazioni, quindi è il candidato perfetto per questa tecnica.

Prompt vago:

> "Disegnami il flusso di acquisizione di un nuovo utente del Portale."

Il rischio è un flusso lineare e troppo semplificato, che parte dalla registrazione e arriva all'accesso al portale ignorando l'autenticazione, la validazione del backoffice e tutti i casi in cui qualcosa va storto.

Prompt efficace:

> "Devo disegnare il diagramma di flusso del processo as-is di acquisizione di un nuovo utente impresa sul portale. Procedi in questo ordine. Primo: identifica gli attori coinvolti (referente dell'impresa, infrastruttura di autenticazione esistente, sistema di anagrafica, backoffice che valida le pratiche, gestionale). Secondo: elenca gli step in sequenza, dalla richiesta di registrazione fino all'esito visibile sul portale. Terzo: individua i decision point, in particolare la differenza tra registrazione di una nuova impresa e aggiornamento di un'anagrafica esistente, e i tre esiti possibili della domanda: accettata, rifiutata, oppure con richiesta di chiarimenti o integrazioni. Per ogni decision point indica sia il percorso positivo sia quello negativo. Solo dopo aver completato questi tre passaggi, componi il diagramma di flusso."

La richiesta esplicita del percorso negativo per ogni decision point è la parte che, nella mia esperienza, fa la differenza tra un flusso da rifare e un flusso da rivedere.

e. Come si chiede all'AI di ragionare prima di preparare il workshop requisiti?

Dare spazio al ragionamento prima dell'output migliora la qualità e ci permette di accorgerci subito se l'AI ha frainteso il contesto del progetto.

Anthropic è esplicita su questo punto: lo spazio di pensiero va dato prima dell'esecuzione, perché è lì che la qualità migliora ed è lì che possiamo intercettare una deriva.

Applichiamo questa best practice a un'attività molto concreta, la preparazione del workshop di analisi e raccolta requisiti con ACME.

Si tratta della sessione in cui ci sediamo con i referenti di business e di IT del cliente per capire cosa serve davvero.

Prompt vago:

> "Preparami l'agenda del workshop di raccolta requisiti con ACME."

L'AI ci darà un'agenda generica, che potrebbe andare bene per qualsiasi progetto e per nessuno in particolare.

Manca il ragionamento su cosa rende questo workshop diverso dagli altri.

Prompt efficace:

> "Devo preparare il workshop di analisi e raccolta requisiti con ACME per il nuovo portale Salesforce. Prima di scrivere l'agenda, ragiona ad alta voce su questi punti: quali aree del processo dobbiamo coprire, dato che il portale deve gestire registrazione imprese, aggiornamento anagrafiche e sottomissione domande; quali referenti del cliente vanno coinvolti per ciascuna area, distinguendo tra business e IT; quali sono le informazioni che probabilmente ci mancano e che dovremo estrarre durante la sessione; e quali sono i punti di integrazione con i sistemi legacy su cui rischiamo di trovare ambiguità. Dopo questo ragionamento, e solo dopo, proponimi l'agenda del workshop con tempi e obiettivi per ciascun blocco."

Dando spazio al ragionamento prima dell'output otteniamo un'agenda costruita sulle peculiarità del progetto.

Leggendo il ragionamento vediamo subito se l'AI ha capito il contesto o se dobbiamo correggere il tiro prima di arrivare al deliverable.

f. Come si assegna un ruolo e uno stile per il documento di analisi funzionale?

Dire all'AI chi essere e con quale stile scrivere cambia il registro dell'output e il modo in cui l'AI interagisce con noi durante la stesura.

Prompt vago:

> "Scrivimi il documento di analisi funzionale della soluzione portali."

Senza un ruolo e senza uno stile, l'AI produce un testo neutro, di lunghezza imprevedibile, con un registro che potrebbe risultare troppo tecnico o troppo vago per chi dovrà leggerlo.

Prompt efficace:

> "Comportati come un Business Analyst senior che scrive un documento di analisi funzionale per un cliente della Pubblica Amministrazione. Lo stile deve essere preciso, strutturato e leggibile sia dal business sia dall'IT del cliente: ogni requisito funzionale numerato, descritto in linguaggio chiaro, con i casi d'uso principali e le eccezioni. Evita il gergo tecnico non spiegato. Scrivi la sezione del documento dedicata alla funzionalità di sottomissione della domanda di accesso ai prodotti finanziari, partendo dal flusso che abbiamo già definito. Prima di scrivere, dimmi quali assunzioni stai facendo."

Assegnando un ruolo e uno stile preciso abbiamo trasformato l'AI da assistente generico in un BA senior che scrive per un'audience mista.

E vale la pena notare l'ultima riga: chiedendo di dichiarare le assunzioni abbiamo combinato questa tecnica con quella del ragionare prima.

Le sei pratiche si compongono, cioè si usano contestualmente in fase di stesura del prompt, a seconda dell'esigenza.

4. Checklist finale su Prompt Engineering per Business Analyst

Le sei tecniche coprono le tre dimensioni della Description:

1. quando diamo contesto o specifichiamo i vincoli di output stiamo facendo Product description, cioè definiamo cosa vogliamo
2. quando mostriamo esempi, spezziamo in step o chiediamo di ragionare prima stiamo facendo Process description, cioè guidiamo il come
3. quando assegniamo un ruolo e uno stile stiamo facendo Performance description, cioè modelliamo il comportamento.

Se dovessimo portarci a casa una cosa sola, applicabile dal prossimo deliverable su cui mettiamo mano, è questa: prima di premere invio, aggiungiamo due righe di contesto e una riga di vincolo sull'output.

Chi siamo, su cosa stiamo lavorando, e che forma deve avere il risultato.

È un investimento di pochi secondi che ci risparmia molto più tempo altrimenti speso in rilavorazioni.

E quando non sappiamo come formulare una richiesta, c'è quella che Anthropic chiama non a caso l'arma segreta: spiegare a Claude cosa vogliamo ottenere e chiedergli di aiutarci a scrivere il prompt.

5. Domande frequenti

a. Cos'è il Prompt Engineering per un Business Analyst?
‍

È l'applicazione di sei tecniche di descrizione (dare contesto, mostrare esempi, vincolare l'output, spezzare in step, far ragionare prima, definire ruolo e stile) alle richieste che il BA fa all'AI sui propri deliverable, come mappe applicative, modelli dati, diagrammi di flusso e documenti di analisi funzionale.

b. Serve saper programmare per scrivere prompt AI efficaci?

‍
No.

Le sei tecniche sono competenze di descrizione e di metodo, non di sviluppo: chiedono di saper esplicitare contesto, formato e processo di lavoro, cioè esattamente quello che un consulente funzionale fa già quando prepara un brief per un collega.

c. Qual è l'errore più frequente nei prompt di analisi?

‍
Dare per scontato il contesto.

Senza sapere chi siamo, su quale progetto lavoriamo e quali sistemi esistono già, l'AI produce un output plausibile ma generico, con sistemi inventati che non appartengono al nostro cliente.

d. Le sei tecniche si possono usare insieme nello stesso prompt?

‍
Sì, e spesso conviene.

Nell'esempio del documento di analisi funzionale, per esempio, ruolo e stile si combinano con la richiesta di dichiarare le assunzioni prima di scrivere, cioè con la tecnica del far ragionare prima di eseguire.

e. Che differenza c'è tra Product, Process e Performance Description?

‍
La Product description definisce cosa vogliamo (output, formato, audience, stile), la Process description definisce come vogliamo che l'AI affronti il lavoro (istruzioni, passaggi, esempi), la Performance description definisce come vogliamo che si comporti durante la collaborazione (concisa o dettagliata, accondiscendente o critica).

f. Un prompt scritto bene basta al primo colpo?

‍
Quasi mai, ed è normale.

Il prompting è un processo iterativo che si affina con cicli brevi di Description e Discernment: i prompt di questo articolo sono template di partenza, non formule da copiare alla lettera.

‍

Continua il percorso

Su Augmented Consultant condivido, partendo dal mio lavoro reale, strumenti, demo, e risorse per evolvere la professionalità consulenziale con l'AI, per Consulenti, Business Analyst e Project Manager.

Se è un percorso che ti interessa, iscriviti al canale YouTube di Augmented Consultant per non perdere la prossima tappa.

Fonti

- Rick Dakan, Joseph Feller e Anthropic, AI Fluency: Framework & Foundations (2025), licenza CC BY-NC-SA 4.0. Competenza Description, dimensioni Product, Process e Performance, e le sei tecniche di prompting efficace
- Augmented Consultant, Le 4 D dell'AI Fluency per Business Analyst e Project Manager

‍