Requisitos de produto: como escrever um PRD a partir de entrevistas

Pedir um botão deixa a tarefa em aberto

Um cliente diz «Adicionem um botão de exportação». Isso não diz quem precisa do arquivo, o que entra nele ou o que fará depois. O documento de requisitos de produto, ou PRD, dá à equipe entendimento comum da tarefa e dos limites do resultado.

O artigo trata de um documento curto para uma funcionalidade. Arquitetura, contratos e requisitos técnicos da organização continuam tendo seu lugar. O PRD torna o problema verificável antes de escolher a implementação.

Do pedido do usuário aos requisitos

1. Volte ao último caso real

   Pergunte quando precisou exportar, o que fez no lugar, quais dados transferiu e onde houve dificuldade. Marque exemplo e consequência na transcrição. «É inconveniente» precisa de detalhes para que a melhoria possa ser testada.

2. Descreva o cenário antes de escolher a interface

   Registre quem inicia a ação, com quais dados e qual resultado espera. Botão, e-mail e relatório automático são opções. Examine a necessidade e as restrições antes de tornar a primeira sugestão obrigatória.

3. Defina o escopo da versão

   Escreva o que entra na tarefa e o que fica fora por decisão da equipe. Liste à parte permissões, campos e casos sem resultado. Combine as condições de medição antes de fixar velocidade ou volume.

4. Escreva como verificar

   Para cada requisito, descreva um resultado observável e dados de exemplo. Relacione o teste ao problema inicial. Se um ponto não foi confirmado, registre uma pergunta aberta, um responsável e a data em que precisa ser decidida.

Exportar uma lista de solicitações encerradas

O exemplo é fictício. Nomes, condições e resultados servem apenas para explicar o método.

A necessidade é compartilhar certos dados de um período. A entrevista não pede a exportação de toda a base, de anexos ou da conversa completa.

Exemplo de critério: depois de escolher o período, a exportação contém as solicitações encerradas nele e apenas os campos combinados. Esclareça separadamente as regras de limite das datas.

Modelo de PRD para uma funcionalidade

Relacione cada requisito a uma observação. Uma fonte pode apoiar vários pontos, mas ainda é preciso confirmar a aprovação.

Nome e versão da funcionalidade:
Problema do usuário:
Caso concreto da entrevista:
Usuário e contexto:
Cenário principal:
Resultado esperado:
Dados e restrições:
Dentro e fora do escopo:
Critérios de verificação:
Suposições e questões em aberto:
Fontes e marcas de tempo:
Quem aprovou e quando:

Dá para verificar os requisitos sem quem escreveu o documento?

• Cada requisito explica o problema que resolve.
• O resultado verificável está separado da implementação.
• Os limites da versão estão explícitos.
• Questões em aberto estão indicadas.