Como escrever requisitos de produto verificáveis.
Um PRD conecta o problema do usuário ao comportamento observável do produto. Separe requisitos de propostas de implementação e decisões ainda pendentes.
Adapte o fluxo à sua tarefa.
Traduza o problema do usuário em comportamento observável, definindo entradas, saídas e condições de aceitação. Separe comportamento exigido de propostas de implementação e mantenha visíveis decisões pendentes sobre escala, permissões ou tratamento de erros.
- O que você fornece
- Problema do produto, restrições e notas de interessados.
- O que você recebe
- Rascunho de PRD com objetivos, requisitos e decisões pendentes.
Veja a entrada e o resultado.
Entrada e saída ilustrativas · exemplo didático, não uma execução real do WebAct
Exemplo campo
Draft a small PRD for comparing two CSV supplier files before a catalog update. Required fields: SKU and Price. Match exact SKUs; show old and new prices; export a review list. Duplicate SKUs must be flagged. Volume limits and permissions are undecided.
Exemplo completo
Problem: catalog managers need to inspect supplier price changes before an update. Inputs: two CSV files containing SKU and Price. Matching: exact SKU values; duplicate keys require review rather than automatic pairing. Result: a list containing SKU, old price, new price and change status. Export: the reviewed comparison is downloadable; the workflow does not update the live catalog. Acceptance example: A12 changes from 10 to 12 and appears as a price change. Open decisions: supported volume, permissions and treatment of missing prices.
Carregue esta entrada no prompt e copie para o WebAct para testar a tarefa. Seu resultado pode ser diferente da ilustração.
Decisões e solução de problemas.
Um PRD deve prescrever o banco de dados ou framework?
Inclua restrições técnicas apenas quando forem requisitos estabelecidos. Caso contrário, descreva o comportamento e deixe as escolhas de implementação para o processo de design adequado.
Por que engenheiros interpretam o mesmo requisito de formas diferentes?
Acrescente exemplos concretos e condições de aceitação, incluindo estados de falha. Formulações amplas como fácil de usar não definem comportamento observável.
Teste com sua própria fonte.
Substitua o exemplo pelo seu material no prompt. Mantenha os requisitos necessários e copie a tarefa para o WebAct.
Personalizar e copiar a tarefa ↑