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:

1. Navegue para qualquer user story
2. Clique no separador Detalhes
3. Encontre a secção Critérios de Aceitação
4. 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:

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 utilizadores

Formato 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 dashboard

Especificaçã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 calculadas

Crité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íficos

Crité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 logs

Anti-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 timeout

Demasiado 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 downtime

Testar 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 existentes

Scope 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ões

Integração com Workflow

Durante Planeamento

1. Criação de story: Rascunhar critérios iniciais
2. Refinement: Equipa discute, adiciona edge cases
3. Estimativa: Critérios informam atribuição de story points
4. Planeamento de sprint: Critérios verificam que story está pronta

Durante Desenvolvimento

1. Referência: Developer verifica critérios enquanto codifica
2. Auto-teste: Developer verifica cada critério antes de PR
3. Code review: Revisor verifica cobertura de critérios

Durante Testes

1. Criação de test case: Cada critério torna-se test case
2. Verificação: Tester valida todos critérios
3. Bug reports: Referenciam critérios específicos que falharam

Durante Demo

1. Walkthrough: Mostrar cada critério sendo cumprido
2. Sign-off: Stakeholder confirma aceitação

Atalhos de Teclado

No editor de critérios de aceitação:

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 utilizador

4. 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 protegidas

6. 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 2FA

Templates 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 completamente

Validaçã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 exibe

Endpoint 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 erro

Resoluçã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

Criar User Story

User stories capturam requisitos da perspetiva do utilizador final. Cada story segue o formato: "Como [quem], eu quero [o quê], para que [porquê]." Esta estrutura garante que cada funcionalidade tem propósito claro e valor mensurável.

Abrir a Modal

Aceda à modal de criação através de múltiplos caminhos:

• Cabeçalho do projeto: Clique no botão "Nova" na secção de user stories
• Atalho de teclado: Cmd/Ctrl + Shift + U de qualquer lugar no projeto
• Estado vazio: Clique no link "Crie a sua primeira user story"
• Criação rápida: Use menu de criação rápida global e selecione "User Story"

A modal abre com o seu projeto atual pré-selecionado. Se abriu do menu global, selecione workspace e projeto primeiro.

Modos de Criação

Modo Tradicional

Escreva user stories no formato standard:

Estrutura do template:

Como [tipo de utilizador],
Eu quero [algum objetivo],
Para que [alguma razão].

Exemplo:

Como gestor de projeto,
Eu quero ver gráficos de burndown de sprint,
Para que possa acompanhar a velocidade da equipa.

O formato tradicional garante:

• Identificação clara da persona do utilizador
• Declaração de objetivo específica e acionável
• Justificação de valor de negócio

Escrever stories eficazes:

1. Seja específico sobre o utilizador. "Como utilizador" é demasiado vago. Use "Como administrador de faturação" ou "Como visitante de primeira vez"

1. Foque num objetivo. Se escrever "e" na cláusula do quero, considere dividir em múltiplas stories

1. Declare valor mensurável. "Para que possa poupar tempo" é fraco. "Para que possa processar 50% mais faturas" é acionável

Modo AI

Descreva o que precisa em linguagem natural. A AI gera uma user story corretamente formatada:

Input:

Preciso de uma forma para managers aprovarem entradas de tempo antes de irem para faturação

Story gerada:

Como gestor de equipa,
Eu quero rever e aprovar entradas de tempo antes de exportação,
Para que a precisão de faturação melhore e disputas diminuam.

Modo AI destaca-se quando:

• Converter pedidos de stakeholders em formato user story
• Transformar bug reports em stories de melhoria
• Decompor requisitos vagos em necessidades específicas

Campos da Modal

Título (Obrigatório)

Em modo Tradicional, este é o texto completo da sua user story. Em modo AI, esta é a sua descrição em linguagem natural.

Limite de caracteres: 500 caracteres Melhor prática: Mantenha títulos escaneáveis. A primeira linha deve resumir a story.

Critérios de Aceitação

Defina o que "pronto" significa para esta story. Use condições testáveis:

Critérios fracos:

- Deve funcionar corretamente
- Deve ser rápido
- Precisa ter boa aparência

Critérios fortes:

- Entradas de tempo exibem em ordem cronológica
- Manager pode aprovar/rejeitar entradas individuais
- Entradas rejeitadas retornam ao submissor com comentário obrigatório
- Entradas aprovadas marcadas com timestamp e nome do aprovador
- Página carrega em menos de 2 segundos para até 500 entradas

Opções de formato:

Given/When/Then:

Dado que sou um manager logado
Quando vejo entradas de tempo pendentes
Então vejo entradas agrupadas por membro de equipa

Estilo checklist:

- [ ] Filtrar por intervalo de datas funciona
- [ ] Aprovar em massa entradas selecionadas funciona
- [ ] Exportar entradas aprovadas para CSV funciona

Informação Adicional

Contexto que ajuda durante implementação:

• Links para mockups de design
• Restrições técnicas
• Documentação relacionada
• Contactos de stakeholders
• Edge cases a considerar

Este campo suporta formatação Markdown completa incluindo links, blocos de código e imagens.

Prioridade

Defina nível de urgência da lista de prioridades do seu projeto:

Prioridade afeta:

• Ordenação padrão em vistas de backlog
• Sugestões de planeamento de sprint
• Cálculos de carga de trabalho de equipa

Epic

Ligue a story a um epic pai para organização:

Nenhum Epic selecionado: Story aparece no backlog sem agrupamento Epic selecionado: Story agrupa sob epic em roadmap e vistas de planeamento

Criar Epic inline: Clique "Criar novo epic" para adicionar um epic sem sair da modal. Introduza título e guarde—o novo epic fica imediatamente selecionável.

Isto é valioso quando:

• Uma story revela necessidade de uma nova iniciativa
• Stakeholder pede uma funcionalidade fora dos epics existentes
• Está a decompor um requisito grande em epic + stories

Validação de Formulário

O botão criar ativa quando:

1. Projeto selecionado: Obrigatório para todas stories
2. Título fornecido: Mínimo 3 caracteres
3. Conteúdo apropriado ao modo: Formato tradicional ou descrição AI

Erros de validação aparecem inline:

• Título vazio: "Título é obrigatório"
• Título demasiado curto: "Mínimo 3 caracteres"
• Sem projeto: "Selecione um projeto primeiro"

Após Criação

Estado de Sucesso

A modal confirma criação com opções:

Ir para User Stories: Navegar para o board de user stories do projeto Criar Outra: Limpar formulário, manter na modal para criação em batch

O Que Acontece

1. Story criada com estado "Aberta"
2. Aparece no backlog pronta para planeamento de sprint
3. Ligada ao epic se selecionado
4. Equipa notificada via feed de atividade do projeto
5. Sincronização em tempo real entre todas as vistas dos membros de equipa

Atalhos de Teclado

Melhores Práticas

Escrever Independentemente

Cada story deve ser completável sem dependências:

Dependente (evitar):

Como utilizador, quero ver o dashboard que foi criado na US-123

Independente (preferido):

Como utilizador, quero ver métricas chave no meu dashboard

Dimensionar Apropriadamente

Stories devem completar dentro de um sprint. Se maiores:

• Divida em múltiplas stories
• Use epic para agrupar stories relacionadas
• Considere padrão "Como utilizador, quero [parte 1]"

Incluir Critérios de Aceitação

Cada story precisa de condições testáveis. Isto não é opcional—é como a sua equipa sabe quando trabalho está completo.

Investimento de tempo: 5 minutos escrevendo critérios poupa 2 horas de perguntas de esclarecimento depois.

Conectar a Epics

Stories órfãs criam caos no planeamento. Mesmo "melhorias diversas" merecem um epic para agrupamento.

Padrões Comuns

Story de Funcionalidade

Como [tipo de utilizador],
Eu quero [capacidade],
Para que [valor de negócio].

Conversão Bug-para-Story

Como [utilizador afetado],
Eu quero [coisa quebrada] corrigida,
Para que [impacto quando corrigido].

Story Técnica

Como developer,
Eu quero [melhoria técnica],
Para que [benefício de manutenção/performance].

Story de Pesquisa

Como product manager,
Eu quero entender [desconhecido],
Para que [decisões futuras].

Resolução de Problemas

Modal não abre:

• Verifique permissões de projeto (precisa createuserstories)
• Garanta que projeto está selecionado na navegação
• Tente atualizar página

Modo AI não gera:

• Forneça mais detalhe na descrição
• Inclua contexto sobre tipo de utilizador e objetivo
• Verifique conexão de rede

Não consegue selecionar epic:

• Epics carregam após seleção de projeto
• Crie novo epic se nenhum existir
• Verifique se epic não está arquivado

Dropdown de prioridade vazio:

• Prioridades vêm de configurações do projeto
• Admin pode adicionar prioridades em Configurações do Projeto → Prioridades