A — B
O que o ator faz para disparar um comportamento do sistema. Sempre descrita no bloco 'Quando'. Ex: 'Quando o vendedor clica em Confirmar Pedido'
Qualquer entidade que interage com o sistema — pessoa, sistema externo ou serviço automatizado. Ator primário: quem inicia. Ator secundário: quem é acionado durante.
Lista priorizada de tudo que precisa ser desenvolvido. Organizado em: Temas → Épicos → Features → User Stories → Tarefas.
Comportamento do sistema diferente do especificado. Distinto de melhoria: um bug é algo que deveria funcionar de um jeito e não funciona. Se não havia especificação, é comportamento indefinido — e isso implica que especificar bem previne bugs.
C — E
Documento formal que descreve todas as interações possíveis entre um ator e o sistema para atingir um objetivo. Mais detalhado que a User Story — cobre todos os fluxos alternativos e de exceção.
Condição objetiva e testável que define quando uma User Story está corretamente implementada. Escrito em Gherkin (Dado/Quando/Então). Não confundir com regra de negócio: a regra define o comportamento, o critério de aceite testa se a regra foi implementada.
Checklist acordado pelo time que define quando uma User Story está completa — inclui desenvolvimento, testes, revisão de código e validação do analista.
Conjunto de funcionalidades relacionadas que entregam um objetivo de negócio maior. Composto por múltiplas User Stories. Exemplo: 'Gestão de pedidos' é um épico.
F — H
Funcionalidade específica dentro de um épico. Agrega múltiplas User Stories relacionadas. Exemplo: 'Registro de pedido manual' é uma feature dentro do épico 'Gestão de pedidos'.
Variação do fluxo principal que ainda resulta em conclusão bem-sucedida, mas por caminho diferente. Exemplo: pedido com desconto acima do limite vai para fila de aprovação.
Situação de erro ou falha que impede a conclusão normal do caso de uso. Exemplo: sistema de estoque indisponível durante o registro do pedido.
O caminho feliz — o que acontece quando tudo funciona como esperado, sem desvios. Não contém condicionais.
Diagrama que mostra os possíveis estados de uma entidade (pedido, contrato, ticket) e as transições entre eles. Exemplo de estados de pedido: Rascunho → Aprovado → Em separação → Concluído.
Linguagem estruturada para critérios de aceite em formato legível por humanos e automatizável. Estrutura: Dado que [contexto] / Quando [ação] / Então [resultado].
Momento de passagem da especificação da analista para o time de DEV — inclui apresentação dos artefatos e esclarecimento de dúvidas antes do desenvolvimento.
L — P
Modelo de IA treinado com grandes volumes de texto para gerar e raciocinar sobre linguagem natural. É o que está por trás do Claude, Gemini, ChatGPT, etc.
Linguagem de texto para diagramas (fluxogramas, sequência, estado) renderizáveis em GitHub, Notion, GitLab e outras ferramentas. Digite em texto, visualize como diagrama.
Conjunto mínimo de funcionalidades necessárias para entregar valor real. No backlog: as USs que precisam estar prontas para o módulo funcionar.
Arquivo padronizado com informações do sistema (personas, módulos, regras globais, integrações) usado para dar contexto à IA antes de qualquer tarefa de especificação.
Representação de um perfil de usuário com características, objetivos e permissões definidas. Diferente de 'usuário' (genérico) — a persona tem nome e papel específico. Ex: 'Vendedor interno' é uma persona.
Estado que deve existir antes da execução de um caso de uso. Se a pré-condição não for verdadeira, o caso de uso não pode começar.
Estado do sistema após a execução de um caso de uso — tanto em caso de sucesso quanto de falha.
R — V
Capacidade de identificar a relação entre artefatos — qual US gerou qual UC, qual épico contém quais USs, qual bug motivou qual especificação.
Restrição ou comportamento que o sistema deve respeitar conforme determinado pelo negócio. Independente da tecnologia. Ex: 'Desconto máximo de 15% sem aprovação gerencial'. Diferente de requisito técnico: a regra define o quê, não o como.
Comportamento que o sistema deve ter — o que ele faz. Ex: 'O sistema deve enviar e-mail de confirmação após o registro do pedido'.
Restrição de qualidade — performance, segurança, disponibilidade. Ex: 'O sistema deve responder em até 2 segundos para 95% das requisições'.
Prompt configurado e reutilizável, salvo como instrução de sistema em uma ferramenta de IA. Garante que a IA siga o mesmo padrão para um tipo de tarefa.
Descrição de uma funcionalidade do ponto de vista do usuário, no formato 'Como [persona], quero [ação], para que [valor]', com critérios de aceite testáveis.
O benefício concreto que uma funcionalidade entrega. Bom: 'para que eu possa aprovar pedidos sem acessar dois sistemas diferentes'. Vago: 'para melhorar minha produtividade'.
Termos a evitar
| Evite | Use | Por quê |
|---|---|---|
| "Usuário" como persona | Nome específico da persona | "Usuário" é vago — qual usuário? |
| "O sistema deve funcionar corretamente" | Descreva o comportamento específico | Não é testável |
| "Rapidamente" / "eficientemente" | "Em até 2 segundos (95% das req.)" | Sem número não é requisito |
| "Simples" / "intuitivo" | Descreva o comportamento esperado | Subjetivo — cada um interpreta diferente |
| "Etc." em listas de regras | Liste todas as regras explicitamente | "Etc." significa que você não sabe o que mais existe |
| "Conforme combinado" | Documente o que foi combinado | O que foi combinado verbalmente não existe |
| "Igual ao sistema antigo" | Especifique o comportamento | O sistema antigo pode ter comportamentos indesejados |
Siglas e acrônimos
| Sigla | Significado |
|---|---|
| AN | Analista de Negócio |
| AS IS | Como é hoje (processo atual) |
| TO BE | Como deve ser (processo desejado) |
| DEV | Desenvolvedor / Time de desenvolvimento |
| DoD | Definition of Done |
| EP | Épico |
| LLM | Large Language Model |
| MVP | Minimum Viable Product |
| PO | Product Owner |
| QA | Quality Assurance |
| RF | Requisito Funcional |
| RN | Regra de Negócio |
| RNF | Requisito Não Funcional |
| UC | Use Case (Caso de Uso) |
| US | User Story |