Template per Feature Spec e PRD in Word
Smetti di passare a design ed engineering brief vaghi: ottieni un PRD strutturato con problema, soluzione, requisiti numerati, edge case e criteri di accettazione, pronto da incollare in un documento Word.
Esempio di output
# Feature Spec — Notifiche smart per scadenze fatture ## 1. Sommario esecutivo Introdurre notifiche configurabili che avvisano l'utente X giorni prima della scadenza di una fattura, riducendo i pagamenti in ritardo. Stato: Draft. Owner: [nome PM]. ## 2. Problema e contesto | Elemento | Dettaglio | |---|---| | Problema utente | I clienti dimenticano scadenze e accumulano mora | | Evidenza | [link a ricerca / ticket / dato] | | Segmento | PMI con >50 fatture/mese | | Costo del non fare nulla | [da quantificare — domanda aperta] | ## 3. Obiettivi e metriche di successo | Obiettivo | Metrica | Baseline | Target | |---|---|---|---| | Ridurre ritardi | % fatture pagate entro scadenza | [baseline] | [target] | ## 4. Requisiti funzionali | ID | Requisito | Priorità (MoSCoW) | Note | |---|---|---|---| | RF-01 | L'utente può impostare l'anticipo (1/3/7 gg) | Must | | | RF-02 | Notifica via email e in-app | Must | | | RF-03 | Snooze della notifica | Could | | ## 5. Requisiti non funzionali | ID | Categoria | Requisito | |---|---|---| | RNF-01 | Performance | Invio entro 60s dalla soglia | | RNF-02 | Privacy | Nessun dato fattura in chiaro nel push | ## 6. Edge case e gestione errori - Fattura modificata dopo programmazione notifica → riprogramma - Utente senza email verificata → fallback solo in-app ## 7. Fuori scope - Notifiche SMS (valutare in v2) ## 8. Dipendenze | Dipendenza | Team | Stato | |---|---|---| | Servizio email transazionale | Platform | Da confermare | ## 9. Criteri di accettazione - [ ] Dato un anticipo di 3 gg, la notifica arriva il giorno corretto - [ ] Disattivando le notifiche, non viene inviato nulla ## 10. Domande aperte - Quale baseline reale per i ritardi attuali? - Costo del non fare nulla da quantificare con Finance
Domande frequenti
Sì, ma la qualità del documento dipende dalla precisione degli input. Se non hai metriche di successo, il prompt ti segnalerà esplicitamente la lacuna come 'open question' invece di inventare numeri, così sai cosa devi ancora decidere prima del handoff.
Una user story descrive un bisogno in una frase. Questo prompt produce il documento completo che sta a monte: contesto, requisiti funzionali e non funzionali numerati, edge case, dipendenze, criteri di accettazione e metriche. Le user story diventano una sezione del PRD, non il PRD intero.
Il prompt impone di derivare i requisiti solo dagli input forniti e di marcare come 'assunzione da validare' qualsiasi elemento dedotto. Tutto ciò che non è ricavabile dagli input finisce nella sezione 'Domande aperte', non tra i requisiti.
Vuoi un template su misura?
Costruiscine uno in poche domande — con la struttura corretta per il tuo standard.