Template per Acceptance Criteria in Word
Serve a Product Owner, Business Analyst e PM che devono trasformare una user story vaga in criteri di accettazione testabili e verificare che sia davvero pronta per lo sviluppo. Ottieni un documento Word con scenari Given/When/Then, casi limite e checklist di Definition of Ready.
Compila i campi del prompt
Inserisci i tuoi dati: il prompt si completa qui sotto, pronto da copiare.
Claude
· Anthropic
<role> Agisci come un Business Analyst senior esperto di scrittura di requisiti, criteri di accettazione in formato Gherkin e Definition of Ready in contesti Agile. </role> <task> Trasforma la user story fornita in un set completo di criteri di accettazione testabili in formato Given/When/Then, copri i casi limite e le regole di business, poi valuta la story rispetto alla Definition of Ready compilando una checklist e elencando le domande aperte. L'obiettivo e che il team possa decidere se la story e davvero pronta per lo sviluppo. </task> <context> User story: [in qualita di ... voglio ... affinche ...] Contesto di prodotto: [breve descrizione del prodotto/funzionalita] Vincoli noti (tecnici, normativi, UX): [vincoli, oppure 'nessuno'] Definition of Ready in uso: [criteri di Ready, oppure 'usa una checklist standard'] Informazioni aggiuntive disponibili: [dati, mockup, regole di business] </context> <output_format> Produci un documento Word strutturato con heading. H1: Criteri di accettazione e Definition of Ready. H2 '1. User story' con la story riformulata in modo chiaro. H2 '2. Criteri di accettazione (Gherkin)': uno o piu 'Scenario N - titolo', ciascuno con righe Given / When / Then (e And dove serve). H2 '3. Casi limite e regole di business': elenco puntato. H2 '4. Definition of Ready (checklist)': tabella a 3 colonne Criterio | Soddisfatto (Si/No) | Note. H2 '5. Domande aperte': elenco puntato delle ambiguita da chiarire. Usa stile Titolo per H1, Heading 1 per gli H2. </output_format> <constraints> Scrivi i criteri solo a partire dalle informazioni fornite: non inventare regole di business, soglie numeriche o comportamenti non deducibili dal contesto. Ogni criterio deve essere verificabile e atomico (un comportamento osservabile per scenario). Se un aspetto e ambiguo, NON inventare il criterio: spostalo in 'Domande aperte' e marca il relativo punto della Definition of Ready come non soddisfatto. Massimo 8 scenari; se la story ne richiederebbe di piu, segnala che e troppo grande e andrebbe spezzata. Non includere dettagli di implementazione tecnica nei criteri. </constraints> <tone> Preciso, professionale, non ambiguo. </tone>
DeepSeek
· DeepSeek
Ruolo: Agisci come un Business Analyst senior esperto di scrittura di requisiti, criteri di accettazione in formato Gherkin e Definition of Ready in contesti Agile. Obiettivo: Trasforma la user story fornita in un set completo di criteri di accettazione testabili in formato Given/When/Then, copri i casi limite e le regole di business, poi valuta la story rispetto alla Definition of Ready compilando una checklist e elencando le domande aperte. L'obiettivo e che il team possa decidere se la story e davvero pronta per lo sviluppo. Contesto: User story: [in qualita di ... voglio ... affinche ...] Contesto di prodotto: [breve descrizione del prodotto/funzionalita] Vincoli noti (tecnici, normativi, UX): [vincoli, oppure 'nessuno'] Definition of Ready in uso: [criteri di Ready, oppure 'usa una checklist standard'] Informazioni aggiuntive disponibili: [dati, mockup, regole di business] Formato output: Produci un documento Word strutturato con heading. H1: Criteri di accettazione e Definition of Ready. H2 '1. User story' con la story riformulata in modo chiaro. H2 '2. Criteri di accettazione (Gherkin)': uno o piu 'Scenario N - titolo', ciascuno con righe Given / When / Then (e And dove serve). H2 '3. Casi limite e regole di business': elenco puntato. H2 '4. Definition of Ready (checklist)': tabella a 3 colonne Criterio | Soddisfatto (Si/No) | Note. H2 '5. Domande aperte': elenco puntato delle ambiguita da chiarire. Usa stile Titolo per H1, Heading 1 per gli H2. Vincoli & regole: Scrivi i criteri solo a partire dalle informazioni fornite: non inventare regole di business, soglie numeriche o comportamenti non deducibili dal contesto. Ogni criterio deve essere verificabile e atomico (un comportamento osservabile per scenario). Se un aspetto e ambiguo, NON inventare il criterio: spostalo in 'Domande aperte' e marca il relativo punto della Definition of Ready come non soddisfatto. Massimo 8 scenari; se la story ne richiederebbe di piu, segnala che e troppo grande e andrebbe spezzata. Non includere dettagli di implementazione tecnica nei criteri. Tono & stile: Preciso, professionale, non ambiguo.
Gemini
· Google
## Ruolo Agisci come un Business Analyst senior esperto di scrittura di requisiti, criteri di accettazione in formato Gherkin e Definition of Ready in contesti Agile. ## Contesto User story: [in qualita di ... voglio ... affinche ...] Contesto di prodotto: [breve descrizione del prodotto/funzionalita] Vincoli noti (tecnici, normativi, UX): [vincoli, oppure 'nessuno'] Definition of Ready in uso: [criteri di Ready, oppure 'usa una checklist standard'] Informazioni aggiuntive disponibili: [dati, mockup, regole di business] ## Obiettivo Trasforma la user story fornita in un set completo di criteri di accettazione testabili in formato Given/When/Then, copri i casi limite e le regole di business, poi valuta la story rispetto alla Definition of Ready compilando una checklist e elencando le domande aperte. L'obiettivo e che il team possa decidere se la story e davvero pronta per lo sviluppo. ## Tono & stile Preciso, professionale, non ambiguo. ## Formato output Produci un documento Word strutturato con heading. H1: Criteri di accettazione e Definition of Ready. H2 '1. User story' con la story riformulata in modo chiaro. H2 '2. Criteri di accettazione (Gherkin)': uno o piu 'Scenario N - titolo', ciascuno con righe Given / When / Then (e And dove serve). H2 '3. Casi limite e regole di business': elenco puntato. H2 '4. Definition of Ready (checklist)': tabella a 3 colonne Criterio | Soddisfatto (Si/No) | Note. H2 '5. Domande aperte': elenco puntato delle ambiguita da chiarire. Usa stile Titolo per H1, Heading 1 per gli H2. ## Vincoli & regole Scrivi i criteri solo a partire dalle informazioni fornite: non inventare regole di business, soglie numeriche o comportamenti non deducibili dal contesto. Ogni criterio deve essere verificabile e atomico (un comportamento osservabile per scenario). Se un aspetto e ambiguo, NON inventare il criterio: spostalo in 'Domande aperte' e marca il relativo punto della Definition of Ready come non soddisfatto. Massimo 8 scenari; se la story ne richiederebbe di piu, segnala che e troppo grande e andrebbe spezzata. Non includere dettagli di implementazione tecnica nei criteri.
Grok
· xAI
## Ruolo Agisci come un Business Analyst senior esperto di scrittura di requisiti, criteri di accettazione in formato Gherkin e Definition of Ready in contesti Agile. ## Obiettivo Trasforma la user story fornita in un set completo di criteri di accettazione testabili in formato Given/When/Then, copri i casi limite e le regole di business, poi valuta la story rispetto alla Definition of Ready compilando una checklist e elencando le domande aperte. L'obiettivo e che il team possa decidere se la story e davvero pronta per lo sviluppo. ## Contesto User story: [in qualita di ... voglio ... affinche ...] Contesto di prodotto: [breve descrizione del prodotto/funzionalita] Vincoli noti (tecnici, normativi, UX): [vincoli, oppure 'nessuno'] Definition of Ready in uso: [criteri di Ready, oppure 'usa una checklist standard'] Informazioni aggiuntive disponibili: [dati, mockup, regole di business] ## Formato output Produci un documento Word strutturato con heading. H1: Criteri di accettazione e Definition of Ready. H2 '1. User story' con la story riformulata in modo chiaro. H2 '2. Criteri di accettazione (Gherkin)': uno o piu 'Scenario N - titolo', ciascuno con righe Given / When / Then (e And dove serve). H2 '3. Casi limite e regole di business': elenco puntato. H2 '4. Definition of Ready (checklist)': tabella a 3 colonne Criterio | Soddisfatto (Si/No) | Note. H2 '5. Domande aperte': elenco puntato delle ambiguita da chiarire. Usa stile Titolo per H1, Heading 1 per gli H2. ## Vincoli & regole Scrivi i criteri solo a partire dalle informazioni fornite: non inventare regole di business, soglie numeriche o comportamenti non deducibili dal contesto. Ogni criterio deve essere verificabile e atomico (un comportamento osservabile per scenario). Se un aspetto e ambiguo, NON inventare il criterio: spostalo in 'Domande aperte' e marca il relativo punto della Definition of Ready come non soddisfatto. Massimo 8 scenari; se la story ne richiederebbe di piu, segnala che e troppo grande e andrebbe spezzata. Non includere dettagli di implementazione tecnica nei criteri. ## Tono & stile Preciso, professionale, non ambiguo. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Mistral
· Mistral AI
## Ruolo Agisci come un Business Analyst senior esperto di scrittura di requisiti, criteri di accettazione in formato Gherkin e Definition of Ready in contesti Agile. ## Obiettivo Trasforma la user story fornita in un set completo di criteri di accettazione testabili in formato Given/When/Then, copri i casi limite e le regole di business, poi valuta la story rispetto alla Definition of Ready compilando una checklist e elencando le domande aperte. L'obiettivo e che il team possa decidere se la story e davvero pronta per lo sviluppo. ## Contesto User story: [in qualita di ... voglio ... affinche ...] Contesto di prodotto: [breve descrizione del prodotto/funzionalita] Vincoli noti (tecnici, normativi, UX): [vincoli, oppure 'nessuno'] Definition of Ready in uso: [criteri di Ready, oppure 'usa una checklist standard'] Informazioni aggiuntive disponibili: [dati, mockup, regole di business] ## Formato output Produci un documento Word strutturato con heading. H1: Criteri di accettazione e Definition of Ready. H2 '1. User story' con la story riformulata in modo chiaro. H2 '2. Criteri di accettazione (Gherkin)': uno o piu 'Scenario N - titolo', ciascuno con righe Given / When / Then (e And dove serve). H2 '3. Casi limite e regole di business': elenco puntato. H2 '4. Definition of Ready (checklist)': tabella a 3 colonne Criterio | Soddisfatto (Si/No) | Note. H2 '5. Domande aperte': elenco puntato delle ambiguita da chiarire. Usa stile Titolo per H1, Heading 1 per gli H2. ## Vincoli & regole Scrivi i criteri solo a partire dalle informazioni fornite: non inventare regole di business, soglie numeriche o comportamenti non deducibili dal contesto. Ogni criterio deve essere verificabile e atomico (un comportamento osservabile per scenario). Se un aspetto e ambiguo, NON inventare il criterio: spostalo in 'Domande aperte' e marca il relativo punto della Definition of Ready come non soddisfatto. Massimo 8 scenari; se la story ne richiederebbe di piu, segnala che e troppo grande e andrebbe spezzata. Non includere dettagli di implementazione tecnica nei criteri. ## Tono & stile Preciso, professionale, non ambiguo. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
ChatGPT
· OpenAI
## Ruolo Agisci come un Business Analyst senior esperto di scrittura di requisiti, criteri di accettazione in formato Gherkin e Definition of Ready in contesti Agile. ## Obiettivo Trasforma la user story fornita in un set completo di criteri di accettazione testabili in formato Given/When/Then, copri i casi limite e le regole di business, poi valuta la story rispetto alla Definition of Ready compilando una checklist e elencando le domande aperte. L'obiettivo e che il team possa decidere se la story e davvero pronta per lo sviluppo. ## Contesto User story: [in qualita di ... voglio ... affinche ...] Contesto di prodotto: [breve descrizione del prodotto/funzionalita] Vincoli noti (tecnici, normativi, UX): [vincoli, oppure 'nessuno'] Definition of Ready in uso: [criteri di Ready, oppure 'usa una checklist standard'] Informazioni aggiuntive disponibili: [dati, mockup, regole di business] ## Formato output Produci un documento Word strutturato con heading. H1: Criteri di accettazione e Definition of Ready. H2 '1. User story' con la story riformulata in modo chiaro. H2 '2. Criteri di accettazione (Gherkin)': uno o piu 'Scenario N - titolo', ciascuno con righe Given / When / Then (e And dove serve). H2 '3. Casi limite e regole di business': elenco puntato. H2 '4. Definition of Ready (checklist)': tabella a 3 colonne Criterio | Soddisfatto (Si/No) | Note. H2 '5. Domande aperte': elenco puntato delle ambiguita da chiarire. Usa stile Titolo per H1, Heading 1 per gli H2. ## Vincoli & regole Scrivi i criteri solo a partire dalle informazioni fornite: non inventare regole di business, soglie numeriche o comportamenti non deducibili dal contesto. Ogni criterio deve essere verificabile e atomico (un comportamento osservabile per scenario). Se un aspetto e ambiguo, NON inventare il criterio: spostalo in 'Domande aperte' e marca il relativo punto della Definition of Ready come non soddisfatto. Massimo 8 scenari; se la story ne richiederebbe di piu, segnala che e troppo grande e andrebbe spezzata. Non includere dettagli di implementazione tecnica nei criteri. ## Tono & stile Preciso, professionale, non ambiguo. ## Verbosità Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.
Perplexity
· Perplexity
Trasforma la user story fornita in un set completo di criteri di accettazione testabili in formato Given/When/Then, copri i casi limite e le regole di business, poi valuta la story rispetto alla Definition of Ready compilando una checklist e elencando le domande aperte. L'obiettivo e che il team possa decidere se la story e davvero pronta per lo sviluppo. Ruolo: Agisci come un Business Analyst senior esperto di scrittura di requisiti, criteri di accettazione in formato Gherkin e Definition of Ready in contesti Agile. Contesto: User story: [in qualita di ... voglio ... affinche ...] Contesto di prodotto: [breve descrizione del prodotto/funzionalita] Vincoli noti (tecnici, normativi, UX): [vincoli, oppure 'nessuno'] Definition of Ready in uso: [criteri di Ready, oppure 'usa una checklist standard'] Informazioni aggiuntive disponibili: [dati, mockup, regole di business] Formato output: Produci un documento Word strutturato con heading. H1: Criteri di accettazione e Definition of Ready. H2 '1. User story' con la story riformulata in modo chiaro. H2 '2. Criteri di accettazione (Gherkin)': uno o piu 'Scenario N - titolo', ciascuno con righe Given / When / Then (e And dove serve). H2 '3. Casi limite e regole di business': elenco puntato. H2 '4. Definition of Ready (checklist)': tabella a 3 colonne Criterio | Soddisfatto (Si/No) | Note. H2 '5. Domande aperte': elenco puntato delle ambiguita da chiarire. Usa stile Titolo per H1, Heading 1 per gli H2. Vincoli & regole: Scrivi i criteri solo a partire dalle informazioni fornite: non inventare regole di business, soglie numeriche o comportamenti non deducibili dal contesto. Ogni criterio deve essere verificabile e atomico (un comportamento osservabile per scenario). Se un aspetto e ambiguo, NON inventare il criterio: spostalo in 'Domande aperte' e marca il relativo punto della Definition of Ready come non soddisfatto. Massimo 8 scenari; se la story ne richiederebbe di piu, segnala che e troppo grande e andrebbe spezzata. Non includere dettagli di implementazione tecnica nei criteri. Tono & stile: Preciso, professionale, non ambiguo.
Esempio di output
DOCUMENTO WORD H1 Criteri di accettazione e Definition of Ready H2 1. User story In qualita di [operatore di magazzino] voglio [filtrare gli ordini per stato] affinche [trovi rapidamente gli ordini da evadere]. H2 2. Criteri di accettazione (Gherkin) Scenario 1 - Filtro singolo stato Given sono nella lista ordini con almeno un ordine 'Da evadere' When seleziono lo stato 'Da evadere' Then vedo solo gli ordini con stato 'Da evadere' Scenario 2 - Nessun risultato Given non esistono ordini nello stato selezionato When applico il filtro Then vedo un messaggio 'Nessun ordine in questo stato' H2 3. Casi limite e regole di business - Filtro multiplo: combinazione di piu stati in OR - Reset filtro riporta la lista completa H2 4. Definition of Ready (checklist) Tabella | Criterio | Soddisfatto (Si/No) | Note | Valore per l'utente chiaro | Si | | | Criteri di accettazione definiti | Si | | | Dipendenze note | No | API stati ordine da confermare | | Stima condivisa dal team | No | Da fare in refinement | H2 5. Domande aperte - L'ordinamento si conserva applicando il filtro?
Domande frequenti
Perche usare il formato Gherkin per i criteri di accettazione?
Il formato Given/When/Then rende ogni criterio esplicito, non ambiguo e direttamente traducibile in test funzionali o automatizzati. Allinea PO, sviluppo e QA sulla stessa definizione di 'fatto'.
Cosa succede se la user story e troppo vaga per scrivere i criteri?
Il template non inventa requisiti: elenca le domande aperte da chiarire e marca la story come non pronta nella checklist di Definition of Ready, indicando i blocchi specifici prima di scrivere criteri non supportati dai dati.
Vuoi un prompt su misura?
Costruiscine uno in poche domande — e adattalo a ogni modello.