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

Nota editorial — TI Especialistas:
Este artigo faz parte do acervo do TI Especialistas e preserva a visão publicada no contexto original. Como as normas e práticas de qualidade de software evoluíram desde então, recomendamos também a leitura atualizada: Qualidade de software em 2026: ISO/IEC 25010, ISO 25000 e o legado da ISO 9126.

\n
\n
\n

Qualidade de software. Uma daquelas coisas que todo mundo em uma reunião de projeto jura que é a prioridade número um.
\nAí, duas semanas depois, o prazo aperta, o café acaba e a “qualidade” vira só uma palavra bonita em um slide de PowerPoint esquecido.
\n
\nO 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
\num padrão para medir essa tal de qualidade. Primeiro, veio a ISO/IEC 9126, uma tentativa nobre de colocar ordem na casa.
\nHoje, temos sua evolução muito mais poderosa: a
\nISO/IEC 25000, ou SQuaRE.
\n
\nNeste 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
\npara 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.
\n

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

\nVamos direto ao ponto: se você está lendo sobre a
\nISO 9126
\nem 2025 e achando que é a última palavra em qualidade, cuidado. A ISO 9126 foi a base, o alicerce.
\nMas ela foi oficialmente substituída e aprimorada pela série ISO/IEC 25000, conhecida como
\nSQuaRE (System and Software Quality Requirements and Evaluation).
\n
\nIgnorar 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.
\nNeste artigo, vamos honrar o legado da 9126, mas com os olhos no presente e futuro da ISO 25000.
\n
\n
\n

Eventos tech no Brasil Agenda monitorada pelo Virtual Arena AI

Ver agenda completa →

TDC Florianópolis 2026 📅 22 jul. 📍 Florianópolis, Brazil ✓ Confirmado Inteligência Artificial
DevOpsDays Rio de Janeiro 2026 📅 15 ago. 📍 Rio de Janeiro, Brazil ✓ Confirmado Plataformas
DevOpsDays Curitiba 2026 📅 22 ago. 📍 Curitiba, Brazil ✓ Confirmado Plataformas

Leitura recomendada (pra parar de “achismo”):
\nSe você quer entender de verdade o que mudou da ISO/IEC 9126 para o SQuaRE (ISO/IEC 25000) — e como isso impacta métricas, requisitos e avaliação na prática —
\naqui está o comparativo completo:

\nISO/IEC 9126 vs ISO/IEC 25000 (SQuaRE): o comparativo completo (com exemplos)
\n

\n
\n

O que a 9126 fez bem (vocabulário e pilares) — e onde ela fica curta hoje.

\n \t

Como o SQuaRE organiza o jogo (modelo, métricas, requisitos e processo).

\n \t

Como usar isso pra defender decisões sem apelar pra “fé” na reunião.

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

\nA 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,
\nmas entender que dor de cabeça cada um deles resolve.
\n

1. Funcionalidade

O que é: O software faz o que deveria fazer?

\n \t

Problema que Resolve: “O cliente disse que o sistema não atende às necessidades dele”.

\n \t

Exemplo Prático: Um sistema de e-commerce que permite ao usuário buscar um produto, colocar no carrinho, calcular o frete e pagar.
\nSe qualquer uma dessas etapas falhar (adequação), der resultados errados (precisão) ou não conversar com o sistema de estoque (interoperabilidade),
\na funcionalidade está comprometida.

2. Confiabilidade

O que é: O software continua funcionando, mesmo sob pressão ou por longos períodos?

\n \t

Problema que Resolve: “O sistema vive caindo na sexta-feira à tarde!”.

\n \t

Exemplo Prático: Um aplicativo de banco que processa milhares de transações por minuto sem travar ou gerar resultados errados.
\nEle é robusto e tolerante a falhas.

3. Usabilidade

O que é: É fácil de entender e usar?

\n \t

Problema que Resolve: “Os usuários precisam de um manual de 300 páginas para conseguir emitir um relatório”.

\n \t

Exemplo Prático: A interface do
\nSpotify.
\nVocê 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?

\n \t

Problema que Resolve: “Essa tela demora uma eternidade para carregar e o servidor está pedindo arrego!”.

\n \t

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?

\n \t

Problema que Resolve: “Cada vez que o Zezinho mexe no código, outras cinco coisas param de funcionar. Ninguém mais entende essa gambiarra!”.

\n \t

Exemplo Prático: Um
\ncódigo bem escrito,
\nmodular 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)?

\n \t

Problema que Resolve: “Decidimos migrar da AWS para o Azure e agora precisamos reescrever metade da aplicação”.

\n \t

Exemplo Prático: Uma aplicação web construída com tecnologias padrão que roda perfeitamente no Chrome, Firefox e Safari,
\nseja em Windows, macOS ou Linux.

Infográfico circular com fundo claro e 6 seções com ícones representando as características da qualidade de software (ISO 9126): Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e Portabilidade.

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

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

Definir o que é Importante (Requisitos):
\nAntes de escrever a primeira linha de código, decida quais daquelas características são CRÍTICAS para o sucesso do projeto.
\nUm 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.
\nNinguém consegue ser nota 10 em tudo.

\n \t

Escolher a Régua (Métricas):
\nPara cada característica escolhida, defina como você vai medi-la. Falar “quero mais usabilidade” não adianta.
\nO correto é: “quero que um novo usuário consiga completar a tarefa X em menos de 30 segundos”. Agora você tem uma meta clara.

\n \t

Medir e Avaliar:
\nCom as métricas na mão, aplique-as ao software. Meça os tempos, conte os bugs, analise o consumo de memória.
\nCompare os resultados com as metas que você definiu. O resultado não é “bom” ou “ruim”, é um dado.
\nCom ele, você decide se o produto é aceitável ou se precisa de melhorias.

\n Fluxograma horizontal minimalista ilustrando o processo de avaliação de qualidade em 3 passos simples. As etapas são: 1. Definir Requisitos (ícone de alvo), 2. Escolher Métricas (ícone de régua) e 3. Medir e Avaliar (ícone de lupa).
\n

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

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

Fundamentação Teórica:
\nPare de citar fontes de 2010. Use este artigo (e as normas ISO oficiais) para construir uma introdução sólida,
\nexplicando a transição da ISO 9126 para a ISO 25000. Isso já mostra que você está atualizado.

\n \t

Estudo de Caso:
\nEscolha um software (pode ser o da sua empresa, um app famoso ou um projeto da faculdade) e aplique o modelo de avaliação.
\nDefina 2 ou 3 características importantes para ele, selecione métricas e faça uma análise.
\nÉ um trabalho prático, com base teórica sólida e que resolve um problema real.

\n \t

Diferencial no Currículo:
\nChegar 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

\nA ISO 9126 e sua sucessora, a ISO 25000, não são burocracias para engessar projetos. São ferramentas estratégicas.
\nElas nos dão um vocabulário comum para discutir algo que antes era subjetivo e transformam “achismo” em dados.
\n
\nUsar 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,
\neficientes e que, principalmente, não vão te acordar de madrugada com um chamado de emergência.
\n
\nA escolha é sua. O caos ou o controle.
\n
\n

\n
\n

Base Acadêmica e Referências

\nNota do Editor: Este artigo foi significativamente reescrito e atualizado em 2025 pela equipe do TI Especialistas para refletir as evoluções das normas
\ne 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),
\nque agradecemos e creditamos abaixo.
\n

Referências Originais

USABILIDEIROS. Norma ISO 9126. Acesso em 10/Out/2016.

\n \t

BIANCHI, Luiz. Qualidade de produtos de software. Acesso em 10/Out/2016.

\n \t

COSTA, Aécio. ISO – 9126. Acesso em 10/Out/2016.

\n \t

SANDI, Rogério Carlos. O que é a ISO/IEC 9126? Acesso em 10/Out/2016.

\n \t

EMER, Maria Cláudia F. P. Qualidade de Produto. Acesso em 10/Out/2016.

\n \t

ABNT CATÁLOGO. ISO/IEC 9126:1991. Acesso em 10/Out/2016.

\n \t

GOMES, Vanessa. Métricas de qualidade de software. Acesso em 10/Out/2016.

\n \t

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.