Gleam.br Wiki

[EARS](https://alistairmavin.com/ears/) (Easy Approach to Requirements Syntax) | Governança

Documentação de engenharia e especificações técnicas da Gleam-BR.

EARS (Easy Approach to Requirements Syntax)

É um método de escrita estruturada criado por Alistair Mavin na Rolls-Royce.

*Seu objetivo* principal é transformar descrições ambíguas em requisitos individuais claros, concisos e testáveis, utilizando padrões de linguagem natural.

*O método* baseia-se em uma regra de ouro: cada requisito atômico deve seguir uma ordem lógica e conter, no máximo, quatro elementos: (Condições) + (Gatilho) + (Nome do Sistema) + (Ação do Sistema).

Os 5 Padrões de Requisitos

Para cobrir diferentes comportamentos, o EARS utiliza cinco templates estruturais:

  • *Ubíquo* (Permanente): Aplica-se a todo o momento e define as propriedades fundamentais do sistema. - Estrutura: O (Nome do Sistema) deve (Ação do Sistema). - Exemplo: O sistema deve manter o histórico de transações por 5 anos.
  • Acionado por *Evento* (Event-driven): Entra em ação apenas em resposta a um evento específico. - Estrutura: Quando (o Gatilho ocorrer), o (Nome do Sistema) deve (Ação do Sistema). - Exemplo: Quando o botão de emergência for pressionado, o sistema deve desligar o motor principal.
  • Acionado por *Estado* (State-driven): Válido apenas enquanto o sistema está em um estado ou condição contínua. - Estrutura: Enquanto (a Condição for verdadeira), o (Nome do Sistema) deve (Ação do Sistema). - Exemplo: Enquanto a aeronave estiver em voo, o sistema deve exibir a luz de alerta no painel.
  • *Comportamento Indesejado* (Unwanted behavior): Define como o sistema deve reagir diante de falhas ou exceções. - Estrutura: Se (um evento indesejado ocorrer), então o (Nome do Sistema) deve (Ação do Sistema). - Exemplo: Se houver uma queda de energia, então o sistema deve salvar o estado atual no disco rígido.
  • *Recursos Opcionais* (Optional features): Aplicável apenas se um componente, módulo ou recurso específico estiver presente. - Estrutura: Onde (o Recurso Opcional estiver incluído), o (Nome do Sistema) deve (Ação do Sistema). - Exemplo: Onde o módulo de reconhecimento facial estiver incluído, o sistema deve autenticar o usuário via câmera.

Por que ele foca na escrita estruturada?

  • *Evita ambiguidade:* Força o autor a pensar exatamente sob quais condições o sistema deve agir, acabando com frases vagas.
  • *Fácil aprendizado:* Usa palavras-chave do inglês cotidiano (when, while, shall, if), não exigindo que a equipe aprenda uma linguagem de programação ou modelagem complexa.
  • *Facilita testes:* Como a estrutura é direta e focada em resultados observáveis, a criação de casos de teste se torna muito mais precisa.