Exemplos de PRD e contratos de aceitação
[!TIP] Use esta página antes de pedir implementação. Escolha um exemplo, adapte o usuário e o escopo, e transforme suas linhas de aceitação em verificações. Não cole o documento inteiro em instruções de repositório sempre ativas.
| Se a sua situação é… | Use… | Pratique depois |
|---|---|---|
| Nenhuma aplicação em execução existe | Exemplo A: novo comportamento de assinatura | Laboratório greenfield |
| O comportamento existente precisa continuar funcionando enquanto um recurso é adicionado | Exemplo B: delta de metadados | Laboratório brownfield |
| A implementação técnica muda, não o contrato de usuário | Exemplo C: modernização de armazenamento | Laboratório de modernização |
Um documento de requisitos do produto descreve por quê e o quê. Um plano técnico descreve como. Testes e observações registradas estabelecem se o resultado atende aos requisitos; nenhum dos documentos estabelece sucesso por si só.
Trabalhe um requisito por vez
Considere “permitir que leitores adicionem feeds”. É amplo demais para implementar ou revisar de forma confiável.
- Nomeie o usuário e o resultado: um leitor quer curar uma lista local de assinaturas.
- Delimite o comportamento: adicionar e listar URLs; sem busca em rede, conta ou sondagem.
- Escolha um caso de aceitação: adicionar a mesma URL normalizada duas vezes deve ser rejeitado.
- Indique a evidência observável: a segunda operação retorna um erro e a lista ainda contém uma entrada.
- Identifique uma escolha não resolvida: se fragmentos de URL participam da unicidade.
- Resolva essa escolha antes de escrever o plano e os testes.
| Requisito fraco | Substituição testável |
|---|---|
| O app deveria ser inteligente e rápido | Nomeie um fluxo de trabalho específico e uma restrição medida, ou omita a alegação de velocidade não suportada |
| Tratar todos os erros | Liste os casos de vazio, malformado, duplicado e de proprietário incorreto que importam para este escopo |
| Adicionar uploads seguros | Separe validação de arquivo, propriedade, armazenamento e tratamento de malware; não chame de “upload seguro” o registro de metadados |
| Modernizar sem quebrar nada | Nomeie o resultado exato, a ordem, a precisão inteira e os contratos de rollback a preservar |
Modelo mínimo
| Seção | Conteúdo obrigatório |
|---|---|
| Problema e usuário | Quem precisa da capacidade e por quê |
| Escopo | Um fluxo principal e exclusões explícitas |
| Aceitação | IDs, casos dado/quando/então, resultados observáveis esperados |
| Restrições | Limites de dados, acessibilidade, compatibilidade, limites de recursos |
| Riscos e perguntas | Incógnitas que devem ser resolvidas antes da implementação |
| Evidências | Verificações e artefatos exatos; deixe em branco os resultados não executados |
| Controle de alterações | Quem aceita uma alteração de escopo e como ela atualiza os testes |
Exemplo A - Assinaturas RSS em um projeto novo
Usuário: uma pessoa leitora que organiza uma pequena lista local de assinaturas. Objetivo: adicionar e listar URLs de feeds sem buscar conteúdo remoto. Excluído: autenticação, análise de feeds, consulta periódica, dados reais de usuários e armazenamento persistente.
| ID | Dado / quando | Então |
|---|---|---|
| RSS-1 | Uma URL HTTPS válida de feed é adicionada | Retornar um ID estável e mantê-lo no processo atual |
| RSS-2 | A mesma URL normalizada é adicionada duas vezes | Rejeitar a duplicata; não criar silenciosamente outro registro |
| RSS-3 | Uma URL vazia, malformada ou não HTTP(S) é adicionada | Rejeitá-la sem modificar a lista |
| RSS-4 | A lista retornada a um chamador é modificada | O armazenamento interno permanece inalterado |
Exemplo B - Metadados de documentos em um projeto existente
Usuário: um membro da equipe que procura documentos de projetos em um painel existente. Objetivo: cadastrar primeiro os metadados, preservando o contrato de integridade/projetos. Excluído: uploads binários, compartilhamento público, verificação de malware e dados reais de funcionários.
| ID | Dado / quando | Então |
|---|---|---|
| DOC-1 | A listagem existente de projetos é solicitada | Preservar os IDs e a estrutura da resposta |
| DOC-2 | Metadados válidos de um projeto conhecido são cadastrados | Retornar um ID e permitir a listagem para esse projeto |
| DOC-3 | Um projeto inexistente ou título inválido é enviado | Retornar um erro documentado sem estado parcial |
| DOC-4 | Os resultados da listagem são alterados por um chamador | Os metadados armazenados não são modificados |
Exemplo C - Modernizar um registro de pedidos
Usuário: um operador que depende da saída JSON existente da CLI. Objetivo: substituir leituras de CSV por SQLite, preservando o comportamento observável. Excluído: novos preços, regras de status, endpoints HTTP, contas ou dados de produção.
| ID | Dado / quando | Então |
|---|---|---|
| MOD-1 | A mesma fixture é lida pelo armazenamento antigo e pelo novo | Registros ordenados e totais em centavos inteiros idênticos |
| MOD-2 | Uma linha inválida ou duplicada é migrada | Falha com código diferente de zero; nenhum banco de dados parcial apresentado como bem-sucedido |
| MOD-3 | A migração é executada novamente contra um destino existente | Recusar a sobrescrita e preservar o arquivo existente |
| MOD-4 | A reversão seleciona o leitor de CSV | O arquivo e a saída originais permanecem disponíveis |
A escolha da stack é uma decisão de planejamento
Mantenha os mesmos critérios de aceitação ao comparar:
- .NET Minimal API e uma pequena interface em Blazor;
- Node/TypeScript e HTML/CSS nativos do navegador;
- Python e suas ferramentas de armazenamento da biblioteca padrão;
net/httpdo Go para uma implementação independente.
Não afirme que todas as alternativas foram executadas. Registre a pilha escolhida e os testes realmente executados. Consulte os laboratórios do Spec Kit para os fluxos de implementação e modernização.
Pronto para planejar?
- Um usuário e o fluxo principal estão nomeados.
- Os não objetivos evitam geração não relacionada.
- Os IDs de aceitação descrevem resultados observáveis, não preferências de implementação.
- Entradas inválidas e efeitos colaterais de falha são explícitos.
- A compatibilidade existente é congelada quando aplicável.
- As perguntas em aberto estão resolvidas ou bloqueiam visivelmente a implementação.
- Os campos de evidência permanecem em branco até que as verificações sejam realmente executadas.
Estes exemplos são contratos iniciais compactos. Os laboratórios completos adicionam seus próprios requisitos e testes; não suponha que as quatro linhas desta página os esgotem.
| Anterior | Próximo |
|---|---|
| Delimitar um exercício | Escolha um kit de laboratório |