Template Documento Requisiti di Prodotto (+ un Esempio Completo da Copiare)

Template Documento Requisiti di Prodotto (+ un Esempio Completo da Copiare)

Ultimo aggiornamento: 28 luglio 2026.

La maggior parte delle pagine sul template documento requisiti di prodotto ti consegna un modulo vuoto. Quello di Atlassian è quattro sezioni di istruzioni intorno a una tabella di metriche di successo vuota. Quello di Product School ha "(with Example)" nel titolo e non contiene nessun esempio. Il blocco markdown in 12 sezioni qui sotto è l'intero template, libero, copia-incollabile. La Sezione 4 poi riempie ognuna di quelle 12 sezioni per un progetto completo: un portale fatture per un cliente che legge PDF con un LLM e instrada i casi dubbi a una revisione umana. Copia quello vuoto. Leggi quello compilato. Scrivi il tuo.

In Sintesi

• Un PRD risponde a cosa costruire e perché; il documento tecnico di design risponde a come.
• Le 12 sezioni funzionano per progetti di qualsiasi dimensione. Un one-pager è lo stesso template con meno righe.
• I non-obiettivi vanno scritti. Un agente AI di coding non può inferire lo scope da un'omissione.
• I criteri di accettazione devono essere verificabili in automatico: "p95 sotto i 400ms", mai "veloce".

Quale Forma di PRD Dovresti Usare?

Scegli la forma in base a chi legge il documento, non a quanto grande sembra il prodotto. Una singola feature destinata ai tuoi stessi ingegneri richiede un one-pager. Un progetto affidato a un team esterno richiede il PRD completo in 12 sezioni, perché i criteri di accettazione fanno anche da sign-off gate. Una spec destinata a un agente AI di coding richiede le stesse dodici sezioni tagliate in fasi.

Il template di documento requisiti di prodotto in una pagina che tutti chiedono non è un artefatto separato. Il one-pager di Lenny Rachitsky, ampiamente copiato, pubblicato con esempi reali nella sua newsletter, è lo stesso scheletro con la cerimonia tolta di mezzo. Un one-pager non è un documento diverso. È le stesse dodici sezioni con le righe vuote cancellate.

Anche i team agili se lo chiedono spesso, di solito nella forma: se un PRD regge una volta che esiste un backlog. Regge, come one-pager: il PRD tiene il perché e i confini, i ticket tengono il lavoro.

Il Template PRD (Markdown da Copiare)

Ecco l'intero documento in markdown, libero, senza email wall. Incollalo in Notion, Confluence, Google Docs, Linear, Word, oppure committalo su GitHub come PRD.md e lascialo versionare insieme al codice. Il template viene richiesto in nove formati diversi; il markdown è quello che sopravvive a un copia-incolla in tutti loro, ed è l'unico che un agente AI di coding legge senza perdere struttura.

# PRD: [Nome prodotto o feature]

## 1. Intestazione
- Owner (prodotto):
- Lead ingegneria:
- Lead design:
- Stato: Bozza | In revisione | Approvato | Rilasciato
- Ultimo aggiornamento:
- Cronologia modifiche: data / autore / cosa è cambiato

## 2. Descrizione del problema
Un paragrafo. Chi ne soffre, quanto spesso, quanto costa oggi. Nessun linguaggio di soluzione.

## 3. Obiettivi e metriche di successo
| Obiettivo | Metrica | Baseline | Target | Misurato da | Data |
|---|---|---|---|---|---|

## 4. Non-obiettivi
Espresso in positivo: "Questa fase non include X."

## 5. Utenti e persona
Chi lo usa, cosa sa già, quale dispositivo, con che frequenza.

## 6. User story e criteri di accettazione
Come [persona], voglio [azione], così che [risultato].
- Given [contesto], when [evento], then [risultato osservabile].

## 7. Requisiti funzionali
Numerati. Un requisito per riga. Verificabile. Nessuna frase con la congiunzione "e".

## 8. Requisiti non funzionali
Performance / sicurezza e tenancy / residenza e conservazione dei dati / accessibilità / disponibilità.

## 9. Dipendenze e integrazioni
Sistemi esterni, API, credenziali, chi possiede l'accesso, tempi di consegna.

## 10. Milestone e fasi
| Fase | Scope | Criteri di uscita | Data target |
|---|---|---|---|

## 11. Domande aperte e rischi
| Domanda o rischio | Owner | Necessario entro | Impatto se non risolto |
|---|---|---|---|

## 12. Appendice e link
Design, ricerche, note sui competitor, ticket precedenti, contratti.

Le dodici sezioni, in ordine: intestazione, descrizione del problema, obiettivi e metriche di successo, non-obiettivi, utenti e persona, user story con criteri di accettazione, requisiti funzionali, requisiti non funzionali, dipendenze e integrazioni, milestone e fasi, domande aperte e rischi, appendice.

Cosa Deve Includere un PRD? Le 12 Sezioni, e la Versione Debole di Ciascuna

Un documento requisiti di prodotto dovrebbe includere una descrizione del problema, obiettivi misurabili, non-obiettivi espliciti, persona, user story con criteri di accettazione, requisiti funzionali e non funzionali, dipendenze, milestone, domande aperte con owner, e una cronologia modifiche. Tutto il resto è appendice. Il test per ogni riga è quello che ISO/IEC/IEEE 29148:2018 applica ai requisiti in generale: verificabile, non ambiguo, singolare.

La maggior parte dei PRD fallisce quel test negli stessi tre punti.

Due sezioni meritano più di quanto ricevono di solito.

I requisiti non funzionali sono dove lo scope raddoppia silenziosamente. Performance, tenancy, residenza dei dati, conservazione, accessibilità, disponibilità: ognuno di questi è una decisione ingegneristica con un costo, e nessuno compare in una user story. Metti la riga sulla sicurezza qui invece che in un cenno vago, e scrivila nel modo in cui vorresti che venisse verificata, usando qualcosa come la nostra checklist di sicurezza pre-lancio come elenco di partenza. Se il progetto ha una componente AI, anche i requisiti di prontezza per la produzione vanno qui, non in una successiva fase di "hardening" che non viene mai calendarizzata: la nostra checklist da PoC a produzione è la versione che usiamo.

Le domande aperte hanno bisogno di tre colonne, non una. Domanda, owner, data necessaria entro. Una domanda senza owner è una decisione che nessuno sta prendendo, e riemergerà come change request alla sesta settimana. Vale la pena dirlo: un PRD è quello che scrivi dopo aver deciso di costruire invece di comprare. Se la descrizione del problema sembra ancora una lista della spesa di funzionalità, la decisione build-versus-buy non è ancora stata presa davvero.

L'Esempio Pratico: un PRD per un Portale Fatture, Compilato

Ecco un esempio pratico completo, tutte e 12 le sezioni popolate. Il progetto: un portale fatture per un cliente, un operatore logistico di media dimensione. I clienti caricano fatture PDF, un LLM estrae le righe, il sistema segnala le discrepanze rispetto al record dell'ordine, e tutto ciò di cui non è sicuro finisce in una coda di revisione umana. Stack: Next.js, Supabase/Postgres, un passaggio di estrazione LLM. Copialo, stampalo, esportalo in PDF, quello che ti serve.

# PRD: Portale Fatture Cliente, Fase 1

## 1. Intestazione
- Owner (prodotto): Direttore operativo, lato cliente
- Lead ingegneria: Delivery lead, Techsy
- Lead design: Product designer, Techsy
- Stato: Approvato per lo sviluppo
- Ultimo aggiornamento: 2026-07-28
- Cronologia modifiche:
  - 2026-07-14 / prodotto / prima bozza
  - 2026-07-21 / ingegneria / aggiunta regola soglia di confidenza alla 6.2
  - 2026-07-28 / prodotto / spostato il write-back ERP nei non-obiettivi

## 2. Descrizione del problema
Il team operativo riceve le fatture dei clienti come PDF via email e le
reinserisce manualmente nel sistema ordini. Il volume supera le 300 fatture
a settimana, il tempo medio di gestione è di circa 6 minuti ciascuna, e circa
il 4% presenta un errore di inserimento individuato solo in fase di
riconciliazione di fine mese. Ogni correzione costa un secondo passaggio e
una telefonata.

## 3. Obiettivi e metriche di successo
| Obiettivo | Metrica | Baseline | Target | Misurato da | Data |
|---|---|---|---|---|---|
| Ridurre la gestione manuale | Tempo medio di gestione | 6 min | sotto i 90 sec | Dashboard ops, mediana settimanale | 2026-11-01 |
| Ridurre gli errori di inserimento | Fatture corrette in riconciliazione | 4% | sotto l'1% | Report di fine mese finance | 2026-12-01 |
| Contenere il carico di revisione | Quota instradata a revisione umana | n/d | sotto il 25% | Metriche coda del portale | 2026-11-01 |

## 4. Non-obiettivi
Questa fase non supporta fatture multi-valuta, write-back ERP, note di
credito self-service per il cliente, né un'app mobile. L'estrazione copre
solo PDF. Foto di fatture cartacee e scansioni sotto i 200 DPI vengono
rifiutate al caricamento con un messaggio che ne spiega il motivo.

## 5. Utenti e persona
- Operatore ops (primario, 6 persone): lavora sulla coda delle eccezioni
  tutto il giorno, conoscenza approfondita del dominio, solo desktop.
- Referente AP del cliente (esterno, ~140 account): carica le fatture, bassa
  tolleranza per attriti nella configurazione dell'account.
- Finance manager (secondario): estrae il report di fine mese, ha bisogno di
  una audit trail per ogni fattura.

## 6. User story e criteri di accettazione
6.1 Come referente AP del cliente, voglio caricare un PDF di fattura, così
da non doverlo inviare via email e aspettare.
- Given un PDF sotto i 20 MB a 200 DPI o superiore, when lo carico, then il
  portale restituisce un numero di riferimento entro 5 secondi e mostra
  "In elaborazione".

6.2 Come operatore ops, voglio che le estrazioni a bassa confidenza vengano
trattenute, così che nulla di errato venga approvato automaticamente.
- Given una fattura analizzata, when la confidenza di estrazione di una
  qualsiasi riga è inferiore a 0.85, then la fattura viene instradata alla
  coda di revisione e non viene mai approvata automaticamente.

6.3 Come operatore ops, voglio vedere la discrepanza in un unico posto, così
da poterla risolvere senza aprire il sistema ordini.
- Given una fattura abbinata a un ordine, when la quantità o il prezzo
  unitario di una riga differisce dal record dell'ordine, then il portale
  mostra entrambi i valori affiancati e segnala la differenza.

6.4 Come finance manager, voglio filtrare le fatture, così da poter chiudere
il mese.
- Given la lista fatture, when filtro per fornitore, intervallo di date e
  stato, then i risultati vengono restituiti in meno di 400ms al p95 e lo
  stato vuoto offre "Cancella filtri".

## 7. Requisiti funzionali
1. Il caricamento accetta solo PDF, massimo 20 MB, un file per invio.
2. L'estrazione restituisce fornitore, numero fattura, data, valuta e le
   righe con quantità, prezzo unitario e totale.
3. Ogni riga ha un punteggio di confidenza tra 0 e 1.
4. Il matching confronta la fattura estratta con l'ordine aperto tramite il
   numero di PO.
5. Le eccezioni entrano in una coda ordinata dalla più vecchia, assegnabile
   a un singolo operatore.
6. Ogni cambio di stato scrive una voce di audit con attore, timestamp,
   valore precedente.
7. Le fatture approvate vengono esportate come batch CSV per il sistema
   finance.

## 8. Requisiti non funzionali
- Performance: lista fatture p95 sotto i 400ms. L'estrazione si completa
  entro 90 secondi dal caricamento al p95.
- Sicurezza e tenancy: isolamento per tenant applicato a livello di riga del
  database. Un cliente non può mai leggere la fattura di un altro cliente.
  Verificato da un test automatico a ogni release.
- Residenza e conservazione dei dati: documenti archiviati nella UE.
  Originali conservati 7 anni, i payload di estrazione 90 giorni.
- Accessibilità: coda completamente operabile da tastiera, contrasto
  WCAG 2.2 AA.
- Disponibilità: 99.5% mensile, supporto durante l'orario lavorativo.

## 9. Dipendenze e integrazioni
- Record ordini: replica Postgres in sola lettura. Accesso di competenza
  dell'IT del cliente, credenziali necessarie entro il 2026-08-15.
- Provider di estrazione LLM: contratto e accordo sul trattamento dati
  firmati prima dell'inizio dello sviluppo.
- Notifiche email: provider transazionale esistente, dominio mittente
  verificato dal cliente.

## 10. Milestone e fasi
| Fase | Scope | Criteri di uscita | Data target |
|---|---|---|---|
| P1 | Caricamento, estrazione, instradamento per confidenza | 50 fatture reali end-to-end, sotto il 25% in coda | 2026-09-19 |
| P2 | Matching ordini e vista discrepanze | Discrepanza segnalata correttamente su 20 casi di test | 2026-10-10 |
| P3 | Audit trail, export CSV, reporting | Il finance chiude un mese nel portale | 2026-11-01 |

## 11. Domande aperte e rischi
| Domanda o rischio | Owner | Necessario entro | Impatto se non risolto |
|---|---|---|---|
| Quale numero PO è quello valido quando una fattura ne mostra due? | Direttore ops del cliente | 2026-08-08 | Logica di matching bloccata |
| I 12 clienti più grandi inviano PDF scansionati o nativi? | Delivery lead | 2026-08-08 | La soglia di confidenza potrebbe essere sbagliata |
| La conservazione di 7 anni è confermata con l'ufficio legale del cliente? | Finance manager del cliente | 2026-08-22 | Cambia il design dello storage e i costi |
| Costo di estrazione per fattura a 300/settimana | Delivery lead | 2026-09-05 | Unit economics sconosciuta |

## 12. Appendice e link
Set di fatture di esempio anonimizzate (40 file), schema della tabella
ordini, studio attuale sui tempi di gestione, flussi Figma per caricamento e
coda, statement of work firmato.

Quattro scelte in questo esempio meritano attenzione, perché la versione pigra di ciascuna costa soldi veri.

Sezione 3, la baseline. "6 minuti" non è un dettaglio decorativo. Senza una baseline non puoi dire se la cosa ha funzionato, e sei mesi dopo qualcuno ne discute in una riunione senza dati. La versione pigra, "migliorare l'efficienza", rende il progetto infalsificabile.

Sezione 4, il non-obiettivo. Il write-back ERP è stato spostato nei non-obiettivi il 2026-07-28, dopo essere stato dato per scontato durante una call di revisione. Scriverlo come non-obiettivo è costato una riga e ha evitato una discussione sullo scope.

Sezione 6.2, la soglia di confidenza. È la regola che le nostre stesse prime bozze dimenticano più spesso. Ometterla significa che il sistema approva automaticamente fatture che un umano avrebbe dovuto vedere, esattamente l'errore che cancella i risparmi di tempo promessi nella sezione 3.

Sezione 11, gli owner. Ogni domanda aperta ha un nome e una data. Quella colonna è la differenza tra un documento e una to-do list di cui nessuno è responsabile.

Il PRD ti dice cosa. Non ti dice quanto ci vuole né quanto costa, che è un esercizio separato: vedi come definire lo scope del progetto per quella metà. E un non-obiettivo che non hai scritto è una funzionalità che qualcuno costruirà.

Come si Scrive un PRD da cui un Agente AI di Coding Può Davvero Costruire?

Un PRD scritto per un agente AI di coding scambia la brevità con l'esplicitezza. L'agente non ha contesto informale condiviso, nessuna storia comune, e nessun istinto per capire cosa ovviamente non intendevi. Quattro regole coprono la maggior parte della differenza, e derivano dall'aver osservato spec che funzionano e falliscono nei nostri stessi sviluppi assistiti da agenti.

1. Esprimi i non-obiettivi in positivo. Gli umani inferiscono lo scope dalle omissioni. Gli agenti no. "Non aggiungere l'autenticazione in questa fase" deve essere una frase scritta nel documento, altrimenti l'auth viene costruita, testata e consegnata.

2. Dimensiona il lavoro per fasi. Un monolite di 40 pagine produce una pull request sicura di sé, dispersiva e mezza corretta. Suddividi il PRD in passaggi che un agente completa in un'unica run delimitata, ciascuno con i propri criteri di uscita.

3. Rendi i criteri di accettazione verificabili in automatico. "Veloce" non è un requisito, è uno stato d'animo. "p95 sotto i 400ms sull'endpoint della lista fatture" è un test che l'agente può scrivere prima ancora di scrivere la funzionalità.

4. Metti i percorsi dei file e i vincoli dello stack nel documento, non in chat. Il contesto della chat evapora tra una sessione e l'altra. La spec no. È anche per questo che la plan mode di Claude Code conta: legge i tuoi file e propone un piano senza modificare nulla finché non lo approvi, e quel passaggio di approvazione è molto più utile quando il piano viene verificato rispetto a una spec scritta invece che al tuo ricordo di cosa avevi chiesto.

Ecco il portale fatture, suddiviso in una fase che un agente può eseguire in un unico passaggio.

# Attività di sviluppo: Caricamento ed estrazione fatture (Fase 1 di 3)

## Vincoli di stack (non sostituibili)
Next.js 15 App Router, TypeScript, Supabase Postgres con row-level security,
deploy su Vercel. Nessuna nuova dipendenza senza chiedere prima.

## File che puoi creare o modificare
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Non toccare
- lib/auth/*  (l'auth arriva nella Fase 2; non aggiungere flussi di login ora)
- Qualsiasi cosa sotto app/(marketing)/
- Lo schema ordini esistente. Leggilo. Non migrarlo mai.

## Criteri di accettazione (scrivili prima come test)
1. POST /api/invoices rifiuta i file non-PDF con 415 e i file oltre 20 MB
   con 413.
2. Una riga con confidence < 0.85 imposta invoice.status = 'review',
   mai 'approved'.
3. Ogni insert scrive una riga di audit con actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= risponde in meno di 400ms su
   un 10,000-row seed.

## Fuori scope per questo passaggio
Matching ordini, UI delle discrepanze, export CSV, notifiche email.

Tre cose sono cambiate rispetto alla versione per umani: sono comparsi i percorsi dei file, è comparsa una lista di cosa non toccare, e i criteri di accettazione sono diventati asserzioni invece che frasi. A quale agente lo affidi conta meno di quanto si pensi, anche se il confronto tra agenti di coding vale la pena leggerlo prima di scegliere. Tieni requisiti e regole di progetto in file separati: Cursor Rules e CLAUDE.md contengono convenzioni e tooling, il PRD contiene cosa costruire. Se vuoi che l'AI ti aiuti a produrre lo scope invece che limitarti a consumarlo, è un workflow diverso. E per la fase di estrazione stessa, la scelta del modello e il loop di valutazione sono un lavoro di integrazione AI a parte.

Cosa Cambia Quando il PRD Va a un Team Esterno

Quando il PRD passa a un'agenzia o a un contractor, smette di essere un documento di allineamento e diventa linguaggio contrattuale. L'ambiguità che un team interno risolve con una conversazione di due minuti diventa una change request con un prezzo. Il Pulse of the Profession di PMI ha rilevato che il 47% dei progetti falliti manca gli obiettivi a causa di una gestione imprecisa dei requisiti. È tutta la ragione per cui esiste questo documento.

Tre sezioni acquisiscono un peso sproporzionato in questo contesto. I criteri di accettazione diventano sign-off gate, quindi devono essere osservabili anche da chi non è un ingegnere. Le domande aperte hanno bisogno di un owner nominato lato cliente, perché il fornitore non può rispondere e costruirà intorno al vuoto. E la cronologia modifiche smette di essere burocrazia: è il registro di cosa è stato concordato e quando, la prima cosa a cui chiunque si aggrappa in caso di disaccordo.

La frase che abbiamo visto andare storta più di una volta è qualche versione di "gli utenti possono esportare i loro dati". Nessuno scrive in che formato. La versione costosa di questo, per noi, è finita in un export CSV quando il cliente intendeva un pacchetto di fatture in PDF formattato con il proprio branding, e rifarlo ha bruciato circa una settimana di ingegneria che nessuno aveva messo a budget. La lettura onesta è che la colpa stava nel documento, non nella delivery. Un criterio di accettazione l'avrebbe intercettato in cinque minuti: given una richiesta di export, when il file viene generato, then è un PDF conforme al layout fornito. Anche una riga nei non-obiettivi l'avrebbe intercettato, dall'altro lato. Quindi ora è una regola della nostra discovery: qualsiasi requisito legato a un sostantivo come "export", "report" o "notifica" riceve un formato, un trigger e un esempio pratico allegato prima di firmare uno statement of work.

È praticamente tutto ciò che il nostro modo di gestire lo sviluppo di applicazioni web significa in pratica: trasformare la metà vaga della spec di un cliente in righe verificabili prima che qualcuno scriva codice.

Cosa Dice Davvero r/ProductManagement sui Template PRD

Cerca product requirements document template reddit e trovi la stessa lamentela ripetuta su r/ProductManagement: template bloat, template gonfiati di sezioni inutili. PRD che nessuno legge. Sezioni compilate solo perché il template aveva un'intestazione, non perché qualcuno avesse bisogno di quel contenuto. Documenti che diventano obsoleti il giorno dopo il kickoff e vengono silenziosamente sostituiti da un thread su Slack. È una critica giusta rivolta alla maggior parte dei template, inclusi diversi tra i primi dieci risultati per questa query.

La nostra risposta: elimina le sezioni invece di riempirle con niente. Le persona vanno per prime quando gli utenti sono ovvi. L'appendice va per seconda. Le milestone possono vivere nel tracker. L'unica che non eliminiamo mai è i non-obiettivi, perché è l'unica sezione che si accorcia più lavori fai e l'unica che previene in modo affidabile la discussione che altrimenti avresti alla sesta settimana.

Domande Frequenti

Cos'è un documento requisiti di prodotto?

Un documento requisiti di prodotto (PRD) dichiara cosa sta costruendo un team e perché: il problema, gli obiettivi con le loro metriche, i non-obiettivi, per chi è pensato, e i requisiti che definiscono il completamento. Esclude deliberatamente i dettagli implementativi, che appartengono a un documento tecnico di design scritto successivamente dall'ingegneria.

Come si scrive un documento requisiti di prodotto?

Inizia dalla descrizione del problema e rifiuta di usare linguaggio da soluzione. Aggiungi obiettivi misurabili con una baseline e una data target, poi scrivi i non-obiettivi. Compila persona, user story con criteri di accettazione Given/When/Then, requisiti funzionali e non funzionali, dipendenze, milestone e domande aperte con owner.

Cosa deve includere un PRD?

Dodici sezioni: intestazione con cronologia modifiche, descrizione del problema, obiettivi e metriche di successo, non-obiettivi, utenti e persona, user story con criteri di accettazione, requisiti funzionali, requisiti non funzionali, dipendenze e integrazioni, milestone e fasi, domande aperte e rischi, e un'appendice. Qualsiasi cosa non rientri in una di queste probabilmente non è un requisito.

Quanto dovrebbe essere lungo un PRD?

Una o due pagine per una singola feature, tre-cinque per una fase di prodotto, cinque-otto quando è un team esterno a costruirla e i criteri di accettazione fungono da sign-off gate. La lunghezza segue il numero di decisioni registrate, non la dimensione del prodotto. Le sezioni vuote vanno eliminate, non imbottite.

Un PRD è la stessa cosa di un BRD?

No. Un business requirements document dichiara il risultato commerciale che l'organizzazione vuole e i vincoli intorno ad esso, di solito prima che venga scelta una soluzione. Un PRD descrive il prodotto che lo realizza: utenti, comportamento, criteri di accettazione, non-obiettivi. Nelle aziende più piccole il BRD è spesso solo la sezione della descrizione del problema.

I team agili scrivono ancora PRD?

Sì, di solito come one-pager. Il backlog contiene il lavoro, ma i ticket sono pessimi nel contenere il perché, i non-obiettivi e la metrica di successo. I team che saltano del tutto il PRD tendono a riscoprirlo come una pagina Confluence chiamata "contesto" tre sprint dopo l'inizio del progetto.

Si può scrivere un PRD in markdown?

Il markdown è il formato migliore per un PRD. Si incolla pulito in Notion, Confluence, Google Docs e Linear, versiona in Git accanto al codice come PRD.md, mostra diff corretti in una pull request, ed è l'unico formato che un agente AI di coding legge senza perdere struttura. Il template qui sopra è markdown esattamente per questi motivi.

Come si scrive un PRD per un agente AI di coding?

Sii esplicito dove normalmente saresti sintetico. Esprimi i non-obiettivi in positivo, perché un agente non può inferire lo scope da un'omissione. Suddividi il documento in fasi completabili in un unico passaggio. Scrivi i criteri di accettazione come asserzioni con numeri. Indica i file che l'agente può modificare e quelli che non deve toccare.

Qual è la differenza tra un PRD e un documento tecnico di design?

Il PRD risponde a cosa e perché: problema, utenti, comportamento, criteri di accettazione, non-obiettivi. Il documento tecnico di design risponde a come: architettura, modello dati, contratti API, trade-off considerati. Il prodotto di solito possiede il primo, l'ingegneria il secondo, e il documento di design dovrebbe leggersi come una risposta al PRD.

Chi possiede il PRD: prodotto, ingegneria o il cliente?

Il prodotto possiede il documento e le decisioni al suo interno. L'ingegneria possiede il feedback sulla fattibilità e i requisiti non funzionali. Nei progetti in agenzia il cliente possiede la descrizione del problema, gli obiettivi, e ogni domanda aperta sulla propria attività. La proprietà condivisa dell'intero documento di solito significa che nessuno lo mantiene.

Per Concludere

Tre cose da portare a casa. Il template è utile solo una volta compilato, quindi copia la forma dell'esempio pratico piuttosto che quella vuota. I non-obiettivi sono la sezione col valore più alto per parola nel documento e la prima che le persone saltano. E i criteri di accettazione scritti come asserzioni verificabili servono bene due lettori: un ingegnere che firma una delivery, e un agente che scrive il test.

Se stai scrivendo un PRD da consegnare a un team esterno e vuoi un secondo paio d'occhi prima che diventi contratto, siamo felici di leggerlo e segnare le righe ambigue. È lo stesso passaggio che eseguiamo su i nostri stessi progetti di applicazioni web.