Solucionado
Por exemplo, na aula quando o professor fala dos requisitos e o que deveria ser observado:
Disponibilidade e confiança: possui como métricas principais uptime, mtbf, mttr...
Existe algo que possamos ir preenchendo durante a fase de requisitos e gere um visão gerão se atende às métricas principais de cada requisito não funcional?
Oii, Antonio!
Que pergunta interessante. É muito comum sentirmos falta de algo mais palpável para "ticar" durante a fase de concepção, especialmente com requisitos não funcionais (RNFs), que costumam ser mais subjetivos.
Na arquitetura de software, não existe um template único e universal, mas existem frameworks e abordagens estruturadas que servem exatamente para esse preenchimento e acompanhamento que você mencionou.
O ADR é uma técnica para documentar decisões de arquitetura. Embora não seja um "check-list" de métricas, ele obriga o time a registrar o motivo de uma escolha, as alternativas e as consequências. Ao definir um RNF de disponibilidade, você cria um ADR especificando que o uptime esperado é de 99,9% e quais métricas (MTBF/MTTR) serão monitoradas.
Se você busca uma lista exaustiva para não esquecer de nada, este padrão internacional é o melhor guia. Ele divide a qualidade do software em 8 características principais (Funcionalidade, Desempenho, Usabilidade, Confiabilidade, Segurança, Manutenibilidade, Portabilidade e Compatibilidade), cada uma com subcaracterísticas.
| Característica | O que observar (Métrica/Check) |
|---|---|
| Confiabilidade | Taxa de falhas, Disponibilidade (Uptime), MTTR. |
| Desempenho | Tempo de resposta (Latência), Vazão (Throughput). |
| Manutenibilidade | Cobertura de testes, Complexidade ciclomática. |
Como você está estudando o Modelo C4, uma forma de visualizar se os requisitos estão sendo atendidos é anotar as restrições diretamente nos diagramas de Container ou Componente.
Por exemplo, ao desenhar um Container de Banco de Dados, você pode adicionar uma nota técnica sobre a estratégia de replicação para garantir o RNF de disponibilidade definido.
Uma ferramenta que ajuda muito a "gerar essa visão" de forma dinâmica é o uso de Dashboards de Observabilidade (como Grafana ou Datadog) desde o início do desenvolvimento (ambiente de Staging). Assim, as métricas de MTBF e latência que você definiu no papel começam a ser visualizadas em tempo real.
Espero que essas referências ajudem a estruturar suas análises!
Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!
Muitíssimo obrigado! Agora sei por onde seguir!