[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.