Análise sobre a ISO 9126 – NBR 13596 – O Guia Definitivo de Qualidade de Software que Salva Projetos (e TCCs)

O problema é que “qualidade” soa subjetivo. Intangível. Quase uma questão de fé. Era assim, pelo menos, até que gente mais esperta que nós decidiu criar
um padrão para medir essa tal de qualidade. Primeiro, veio a ISO/IEC 9126, uma tentativa nobre de colocar ordem na casa.
Hoje, temos sua evolução muito mais poderosa: a
ISO/IEC 25000, ou SQuaRE.

Neste guia definitivo, vamos parar de tratar qualidade como um conceito místico. Vamos transformar a ISO 9126 e a ISO 25000 em ferramentas práticas que você pode usar
para diagnosticar problemas, defender suas decisões e, quem sabe, até entregar um software que não te dê dor de cabeça na hora da manutenção.

Aviso Importante: A ISO 9126 Morreu? Viva a ISO 25000 (SQuaRE)!

Vamos direto ao ponto: se você está lendo sobre a
ISO 9126
em 2025 e achando que é a última palavra em qualidade, cuidado. A ISO 9126 foi a base, o alicerce.
Mas ela foi oficialmente substituída e aprimorada pela série ISO/IEC 25000, conhecida como
SQuaRE (System and Software Quality Requirements and Evaluation).

Ignorar essa evolução é como usar um mapa de 1996 para navegar com o Waze. Você pode até chegar perto, mas vai perder os melhores atalhos.
Neste artigo, vamos honrar o legado da 9126, mas com os olhos no presente e futuro da ISO 25000.

As 6 Características Clássicas da Qualidade (Resolvendo Problemas Reais)

A ISO 9126 definiu 6 pilares que, até hoje, são o coração da análise de qualidade. O pulo do gato não é decorar os nomes,
mas entender que dor de cabeça cada um deles resolve.

1. Funcionalidade

• O que é: O software faz o que deveria fazer?
• Problema que Resolve: “O cliente disse que o sistema não atende às necessidades dele”.
• Exemplo Prático: Um sistema de e-commerce que permite ao usuário buscar um produto, colocar no carrinho, calcular o frete e pagar.
  Se qualquer uma dessas etapas falhar (adequação), der resultados errados (precisão) ou não conversar com o sistema de estoque (interoperabilidade),
  a funcionalidade está comprometida.

2. Confiabilidade

• O que é: O software continua funcionando, mesmo sob pressão ou por longos períodos?
• Problema que Resolve: “O sistema vive caindo na sexta-feira à tarde!”.
• Exemplo Prático: Um aplicativo de banco que processa milhares de transações por minuto sem travar ou gerar resultados errados.
  Ele é robusto e tolerante a falhas.

3. Usabilidade

• O que é: É fácil de entender e usar?
• Problema que Resolve: “Os usuários precisam de um manual de 300 páginas para conseguir emitir um relatório”.
• Exemplo Prático: A interface do
  Spotify.
  Você não precisa de um curso para encontrar uma música, criar uma playlist ou seguir um podcast. É intuitivo.

4. Eficiência (Hoje chamada de ‘Desempenho’)

• O que é: O software usa os recursos (processador, memória, rede) de forma inteligente?
• Problema que Resolve: “Essa tela demora uma eternidade para carregar e o servidor está pedindo arrego!”.
• Exemplo Prático: Um editor de imagens que aplica um filtro complexo em segundos, sem consumir 100% da sua CPU e travar o computador.

5. Manutenibilidade

• O que é: É fácil corrigir um bug ou adicionar uma nova função?
• Problema que Resolve: “Cada vez que o Zezinho mexe no código, outras cinco coisas param de funcionar. Ninguém mais entende essa gambiarra!”.
• Exemplo Prático: Um
  código bem escrito,
  modular e documentado. Se um novo desenvolvedor entra no time, ele consegue entender a estrutura e fazer alterações de forma segura e rápida.

6. Portabilidade

• O que é: É fácil fazer o software rodar em outro ambiente (outro sistema operacional, outro servidor)?
• Problema que Resolve: “Decidimos migrar da AWS para o Azure e agora precisamos reescrever metade da aplicação”.
• Exemplo Prático: Uma aplicação web construída com tecnologias padrão que roda perfeitamente no Chrome, Firefox e Safari,
  seja em Windows, macOS ou Linux.

Como Isso Funciona na Prática? O Processo de Avaliação Descomplicado

A norma propõe um processo lógico para não se perder. Esqueça o “normês”, o fluxo é este:

1. Definir o que é Importante (Requisitos):
   Antes de escrever a primeira linha de código, decida quais daquelas características são CRÍTICAS para o sucesso do projeto.
   Um sistema de controle de usina nuclear precisa de Confiabilidade e Segurança no nível máximo. Um blog pessoal pode focar mais em Usabilidade e Eficiência.
   Ninguém consegue ser nota 10 em tudo.
2. Escolher a Régua (Métricas):
   Para cada característica escolhida, defina como você vai medi-la. Falar “quero mais usabilidade” não adianta.
   O correto é: “quero que um novo usuário consiga completar a tarefa X em menos de 30 segundos”. Agora você tem uma meta clara.
3. Medir e Avaliar:
   Com as métricas na mão, aplique-as ao software. Meça os tempos, conte os bugs, analise o consumo de memória.
   Compare os resultados com as metas que você definiu. O resultado não é “bom” ou “ruim”, é um dado.
   Com ele, você decide se o produto é aceitável ou se precisa de melhorias.

Para os Estudantes (e Professores Espertos): Como Usar Isso no seu TCC

Se você está na graduação ou pós em Engenharia de Software, este tema é uma mina de ouro.

• Fundamentação Teórica:
  Pare de citar fontes de 2010. Use este artigo (e as normas ISO oficiais) para construir uma introdução sólida,
  explicando a transição da ISO 9126 para a ISO 25000. Isso já mostra que você está atualizado.
• Estudo de Caso:
  Escolha um software (pode ser o da sua empresa, um app famoso ou um projeto da faculdade) e aplique o modelo de avaliação.
  Defina 2 ou 3 características importantes para ele, selecione métricas e faça uma análise.
  É um trabalho prático, com base teórica sólida e que resolve um problema real.
• Diferencial no Currículo:
  Chegar em uma entrevista e saber debater sobre métricas de qualidade, indo além do “meu código é limpo”, coloca você em outro patamar.

Conclusão: Qualidade Não é Acidente, é Engenharia

A ISO 9126 e sua sucessora, a ISO 25000, não são burocracias para engessar projetos. São ferramentas estratégicas.
Elas nos dão um vocabulário comum para discutir algo que antes era subjetivo e transformam “achismo” em dados.

Usar esses padrões é a diferença entre ser um programador que apenas entrega tarefas e ser um engenheiro de software que constrói produtos robustos,
eficientes e que, principalmente, não vão te acordar de madrugada com um chamado de emergência.

A escolha é sua. O caos ou o controle.

Base Acadêmica e Referências

Nota do Editor: Este artigo foi significativamente reescrito e atualizado em 2025 pela equipe do TI Especialistas para refletir as evoluções das normas
e alinhar com uma abordagem mais prática. A base conceitual, referências e a autoria original são do trabalho acadêmico apresentado à Universidade Nove de Julho (UNINOVE),
que agradecemos e creditamos abaixo.

Referências Originais

• USABILIDEIROS. Norma ISO 9126. Acesso em 10/Out/2016.
• BIANCHI, Luiz. Qualidade de produtos de software. Acesso em 10/Out/2016.
• COSTA, Aécio. ISO – 9126. Acesso em 10/Out/2016.
• SANDI, Rogério Carlos. O que é a ISO/IEC 9126? Acesso em 10/Out/2016.
• EMER, Maria Cláudia F. P. Qualidade de Produto. Acesso em 10/Out/2016.
• ABNT CATÁLOGO. ISO/IEC 9126:1991. Acesso em 10/Out/2016.
• GOMES, Vanessa. Métricas de qualidade de software. Acesso em 10/Out/2016.
• FERNANDES, Rosane Antunes; VOSTOUPAL, Tânia Mara. Avaliação de Produto de Software: as aplicações da NBR 13596 (ISO 9126) na CELEPAR. Acesso em 10/Out/2016.

Autoria Original

Trabalho de Conclusão do Módulo de Gerência da Configuração do curso de Pós-Graduação em “Engenharia de Software” da UNINOVE, apresentado por:

• AMANDA CRISTINA DOS SANTOS
• CARLOS GUSTAVO BARBARULLO
• GERALDO NUCCI JÚNIOR
• KAUANA HELOÍSE
• LUCAS GOMES DE OLIVEIRA