Critérios de Aceitação
Critérios de aceitação definem as condições que devem ser cumpridas para uma user story ser considerada completa. Transformam requisitos vagos em especificações testáveis, eliminando ambiguidade e prevenindo scope creep.
Propósito
Critérios de aceitação servem múltiplos papéis:
Para developers: Requisitos claros antes de começar a codificar Para testers: Condições exatas a verificar Para stakeholders: Definição transparente de entregáveis Para product owners: Enforcement de fronteiras de scope
Sem critérios de aceitação, "pronto" torna-se subjetivo. Com eles, conclusão é binária—todos critérios passam ou trabalho continua.
Aceder ao Editor
Abra critérios de aceitação a partir dos detalhes da user story:
- Navegue para qualquer user story
- Clique no separador Detalhes
- Encontre a secção Critérios de Aceitação
- Clique no botão Editar (ícone de lápis)
O editor abre numa modal com opções de formatação de texto rico.
Funcionalidades do Editor
Barra de Formatação
O editor de critérios de aceitação suporta:
| Ferramenta | Propósito | Exemplo de Uso |
|---|---|---|
| Negrito | Enfatizar termos chave | Obrigatório: Utilizador deve estar autenticado |
| Itálico | Termos técnicos, notas | Dados guardados assincronamente |
| Sublinhado | Avisos críticos | Não deve eliminar sem confirmação |
| Cabeçalho 1 | Secções principais | # Requisitos Funcionais |
| Cabeçalho 2 | Subsecções | ## Validação de Input |
| Lista ordenada | Passos sequenciais | 1. Clicar Submeter 2. Ver confirmação |
| Lista com bullets | Itens não-sequenciais | • Chrome • Firefox • Safari |
| Bloco de código | Specs técnicas | status: 200 |
| Linha horizontal | Separadores de secção | --- |
Suporte de Texto Rico
O editor preserva formatação ao colar de:
- Google Docs
- Confluence
- Notion
- Microsoft Word
Cole conteúdo formatado diretamente—estrutura transfere automaticamente.
Escrever Critérios Eficazes
Formato Given-When-Then
Esta estrutura cria condições não-ambíguas e testáveis:
Dado [pré-condição]
Quando [ação]
Então [resultado esperado]Exemplo:
Dado que estou logado como administrador
Quando clico "Eliminar Utilizador" e confirmo o diálogo
Então o utilizador é removido do sistema
E vejo uma notificação de sucesso
E o utilizador deixa de aparecer na lista de utilizadoresFormato de Checklist
Para validações mais simples, use checkboxes:
- [ ] Formulário valida formato de email
- [ ] Password requer 8+ caracteres
- [ ] Botão submeter desativado até formulário válido
- [ ] Mensagens de erro aparecem abaixo dos campos inválidos
- [ ] Sucesso redireciona para dashboardEspecificação por Exemplo
Mostre comportamento exato esperado:
Input: "joao@exemplo.com"
Esperado: Válido, proceder para próximo passo
Input: "joao@"
Esperado: Erro "Formato de email inválido"
Input: ""
Esperado: Erro "Email é obrigatório"Categorias de Critérios
Critérios Funcionais
O que a funcionalidade deve fazer:
Dado um utilizador com itens no carrinho
Quando clica "Checkout"
Então vê o formulário de pagamento
E total do carrinho exibe corretamente
E opções de envio são calculadasCritérios Não-Funcionais
Como a funcionalidade deve desempenhar:
Performance:
- Página carrega em menos de 2 segundos
- Pesquisa retorna resultados em menos de 500ms
- Suporta 100 utilizadores simultâneos
Acessibilidade:
- Todos campos de formulário têm labels
- Navegação por tab funciona corretamente
- Compatível com leitores de ecrãEdge Cases
Condições de fronteira e estados de erro:
Edge cases tratados:
- Pesquisa vazia retorna mensagem útil
- Timeout de rede mostra opção de retry
- Expiração de sessão redireciona para login
- Dados inválidos mostram erros específicosCritérios de Segurança
Requisitos de proteção:
Requisitos de segurança:
- Passwords hasheadas antes de armazenamento
- Sessão expira após 30 min de inatividade
- Logins falhados limitados a 5 tentativas
- Dados sensíveis não registados em logsAnti-Padrões a Evitar
Demasiado Vago
❌ Mau:
- Deve funcionar corretamente
- Deve ser rápido
- Precisa tratar erros✅ Bom:
- Retorna status 200 em input válido
- Responde em menos de 500ms em carga normal
- Mostra "Erro de rede, por favor retry" em timeoutDemasiado Técnico
❌ Mau (a menos que equipa seja toda de developers):
- Usa Redis pub/sub para updates em tempo real
- Implementa optimistic locking com ETag
- Deploy via Kubernetes rolling update✅ Bom:
- Alterações aparecem para todos utilizadores em 3 segundos
- Edições simultâneas mostram aviso de conflito
- Deployment causa zero downtimeTestar a Implementação
❌ Mau:
- Usa React hooks corretamente
- Queries de base de dados são otimizadas
- Código segue style guide✅ Bom:
- Componente re-renderiza apenas quando dados mudam
- Lista carrega em menos de 1 segundo para 10.000 itens
- Consistente com padrões de UI existentesScope Creep
❌ Mau (adiciona trabalho não incluído na story):
- Também adicionar suporte dark mode
- Incluir exportação para PDF
- Adicionar atalhos de teclado✅ Bom (manter scope da story):
- Dashboard exibe todos widgets
- Widgets carregam configuração guardada do utilizador
- Layout persiste entre sessõesIntegração com Workflow
Durante Planeamento
- Criação de story: Rascunhar critérios iniciais
- Refinement: Equipa discute, adiciona edge cases
- Estimativa: Critérios informam atribuição de story points
- Planeamento de sprint: Critérios verificam que story está pronta
Durante Desenvolvimento
- Referência: Developer verifica critérios enquanto codifica
- Auto-teste: Developer verifica cada critério antes de PR
- Code review: Revisor verifica cobertura de critérios
Durante Testes
- Criação de test case: Cada critério torna-se test case
- Verificação: Tester valida todos critérios
- Bug reports: Referenciam critérios específicos que falharam
Durante Demo
- Walkthrough: Mostrar cada critério sendo cumprido
- Sign-off: Stakeholder confirma aceitação
Atalhos de Teclado
No editor de critérios de aceitação:
| Ação | Atalho |
|---|---|
| Negrito | Cmd/Ctrl + B |
| Itálico | Cmd/Ctrl + I |
| Sublinhado | Cmd/Ctrl + U |
| Guardar | Cmd/Ctrl + Enter |
| Cancelar | Escape |
Melhores Práticas
1. Escrever Critérios Antes do Desenvolvimento
Critérios escritos após codificação tendem a corresponder à implementação ao invés dos requisitos. Escreva primeiro, codifique depois.
2. Envolver a Equipa
Developers identificam gaps técnicos. Testers encontram edge cases. Inclua ambas perspetivas ao escrever critérios.
3. Manter Critérios Atómicos
Cada critério testa uma coisa:
❌ Combinado:
Utilizador pode fazer login com credenciais corretas e vê dashboard com os seus dados✅ Atómico:
- Credenciais válidas concedem acesso
- Credenciais inválidas mostram erro
- Dashboard exibe após login
- Dashboard mostra apenas dados do utilizador4. Usar Linguagem Consistente
Estabeleça convenções de equipa:
- "Utilizador" vs "Cliente" vs "Membro"
- "Clicar" vs "Selecionar" vs "Escolher"
- "Exibir" vs "Mostrar" vs "Renderizar"
5. Incluir Casos Negativos
O que NÃO deve acontecer também importa:
- Password nunca é exibida em logs
- Dados eliminados não podem ser recuperados
- Sessão expirada não pode aceder rotas protegidas6. Versionar Critérios
Quando requisitos mudam, atualize critérios e note porquê:
Atualizado 2024-01-15: Adicionado requisito 2FA por auditoria de segurança
Anterior: Login requer email + password
Atual: Login requer email + password + código 2FATemplates Comuns
Operações CRUD
Create:
- Input válido cria registo
- Input inválido mostra erros específicos
- Prevenção de duplicados funciona
Read:
- Utilizadores autorizados veem dados
- Utilizadores não-autorizados veem erro
- Estado vazio mostra mensagem útil
Update:
- Alterações guardam corretamente
- Validação aplica-se a updates
- Tratamento de edição simultânea funciona
Delete:
- Confirmação obrigatória
- Soft delete preserva dados
- Hard delete remove completamenteValidação de Formulário
Campo: Email
- Obrigatório (mostra erro quando vazio)
- Validação de formato (utilizador@dominio.com)
- Comprimento máximo: 254 caracteres
- Verificação de unicidade (mostra erro se existe)
Campo: Password
- Obrigatório
- Mínimo 8 caracteres
- Pelo menos um número
- Pelo menos um caractere especial
- Indicador de força exibeEndpoint de API
Endpoint: GET /api/users/{id}
Sucesso (200):
- Retorna objeto utilizador
- Exclui campos sensíveis (password, tokens)
- Tempo de resposta < 200ms
Não Encontrado (404):
- Retorna formato de erro standard
- Mensagem: "Utilizador não encontrado"
Não Autorizado (401):
- Token em falta retorna erro
- Token expirado retorna erro
- Token inválido retorna erroResolução de Problemas
Formatação não guarda:
- Verifique consola do browser para erros
- Tente limpar cache do browser
- Garanta conexão de rede estável
Editor não abre:
- Verifique permissão
edituserstories - Verifique se story não está arquivada
- Atualize página e tente novamente
Conteúdo colado perde formato:
- Tente Colar e Igualar Estilo (
Cmd/Ctrl + Shift + V) - Use formato Markdown para conteúdo complexo
- Divida em operações de colagem menores
Alterações não visíveis para equipa:
- Verifique que guardar completou (modal fechou)
- Verifique erros de sincronização no feed de atividade
- Membros de equipa podem precisar atualizar