Download do Template
Template completo de PRD em Markdown. Inclui secoes para requisitos, epicos, stories e priorizacao.
📄 Do Brief ao PRD
O PRD traduz a visao do Brief em requisitos executaveis. Enquanto o Brief responde "O QUE e POR QUE", o PRD responde "O QUE EXATAMENTE e COMO MEDIR".
Transicao Brief → PRD
Brief (Alto Nivel)
- • Visao e proposito
- • Problema e usuarios
- • Escopo macro
- • Restricoes gerais
PRD (Detalhado)
- • Requisitos numerados
- • Criterios de aceitacao
- • Epicos e stories
- • Metricas de sucesso
✓ Requisitos Funcionais
Requisitos funcionais definem O QUE o sistema DEVE fazer. Cada requisito deve ser testavel, mensuravel e inequivoco.
Formato Padrao
💡 Dica de Ouro
Se voce nao consegue escrever um teste automatizado para o requisito, ele nao esta especifico o suficiente. Reescreva ate ser testavel.
⚡ Requisitos Nao-Funcionais
Requisitos nao-funcionais definem COMO o sistema deve se comportar. Sao as "-ilities" que definem qualidade: performance, security, scalability, availability.
Categorias de RNFs
🚀 Performance
Tempo de resposta < 200ms para 95% das requisicoes
🔒 Seguranca
Dados em transito via TLS 1.3, em repouso via AES-256
📈 Escalabilidade
Suportar 10x usuarios sem degradacao
✅ Disponibilidade
SLA de 99.9% uptime mensal
⚠️ Atencao
RNFs sao frequentemente ignorados ate serem problemas em producao. Defina-os desde o inicio - retroffitar performance e seguranca e muito mais caro.
📦 Epicos e Sequenciamento
Epicos sao grandes blocos de trabalho que agrupam funcionalidades relacionadas. Cada epico deve entregar valor incremental e ser deployavel independentemente.
Sequencia Tipica de Epicos
💡 Regra de Ouro
Epico 1 SEMPRE e fundacao. Sem CI/CD, sem auth, sem infra = sem projeto. Nao pule para features antes da fundacao estar solida.
📝 User Stories
User Stories descrevem funcionalidades do ponto de vista do usuario. O formato padrao garante que sempre haja contexto, acao e beneficio.
Formato Padrao
eu quero [acao/funcionalidade],
para que [beneficio/valor]
Criterios de Aceitacao (OBRIGATORIOS)
Criterios de aceitacao sao o contrato de "done". Sem eles, nao ha como validar a story.
Story: Como usuario, eu quero fazer login, para acessar minha conta.
Criterios de Aceitacao:
- ✓ Login com email/senha validos redireciona para dashboard
- ✓ Login com credenciais invalidas exibe mensagem de erro
- ✓ 5 tentativas falhas bloqueiam conta por 15 minutos
- ✓ Opcao "Esqueci senha" envia email de reset
🎯 Priorizacao MoSCoW
MoSCoW e um framework de priorizacao que classifica requisitos por criticidade. Use para alinhar expectativas e evitar scope creep.
M - Must Have
Sem isso, o produto NAO lanca.
Ex: Auth basica, core feature, deploy pipeline
S - Should Have
Importante, mas nao bloqueante.
Ex: Notificacoes, filtros avancados
C - Could Have
Nice to have se sobrar tempo.
Ex: Dark mode, exportacao PDF
W - Won't Have
Explicitamente FORA do escopo.
Ex: Mobile app, integracao com X
💡 Distribuicao Saudavel
Um PRD saudavel tem ~60% Must, ~20% Should, ~15% Could, e ~5% Won't. Se tudo e Must, nada e Must.
🎨 UI Goals no PRD
A secao de UI Goals define direcao de experiencia, nao design detalhado. E o brief para o designer/frontend entender a visao.
O que Incluir
Principios de UX
Simplicidade, consistencia, feedback imediato
Telas Principais
Dashboard, cadastro, listagens, detalhes
Acessibilidade
WCAG 2.1 AA, navegacao por teclado
Responsividade
Mobile-first, breakpoints definidos
🔗 Handoff para Arquitetura
O PRD termina com um prompt estruturado para o Arquiteto. Esse handoff garante que nenhuma premissa tecnica seja perdida na transicao.
Checklist de Handoff
💡 Prompt para Arquiteto
"Com base neste PRD, projete a arquitetura tecnica considerando: [RNFs listados], [integracoes], [restricoes de stack]. Foco em [area prioritaria]."