A IHM (Interface Homem-Máquina) é o conjunto de recursos que permite ao operador visualizar informações de equipamentos e processos e executar comandos autorizados. HMI é a sigla equivalente em inglês. Em automação industrial, a interface pode ser implementada em painéis locais, terminais de operação ou estações conectadas a sistemas supervisórios. A IHM não substitui o […]
Confira!
A IHM (Interface Homem-Máquina) é o conjunto de recursos que permite ao operador visualizar informações de equipamentos e processos e executar comandos autorizados. HMI é a sigla equivalente em inglês. Em automação industrial, a interface pode ser implementada em painéis locais, terminais de operação ou estações conectadas a sistemas supervisórios. A IHM não substitui o CLP: o controlador executa as funções de controle e os intertravamentos atribuídos à sua arquitetura, enquanto a interface organiza a interação entre pessoa e processo.
Um projeto de IHM envolve mais do que desenhar telas. Exige definir estados, alarmes, permissões, unidades, qualidade dos dados, navegação, prioridades e comportamento quando comunicação ou equipamentos falham. A interface deve reduzir ambiguidade operacional, permitir diagnóstico e apoiar decisões coerentes com a função do sistema.
IHM, HMI, CLP e SCADA: diferenças
IHM e HMI designam o mesmo conceito em idiomas diferentes. Um terminal local conectado ao controlador pode apresentar valores de processo e permitir operação. O SCADA normalmente agrega recursos de supervisão, históricos, alarmes e múltiplas áreas, mas as fronteiras dependem da plataforma e da arquitetura.
O CLP executa lógica operacional, e não é correto presumir que um comando selecionado na tela foi necessariamente executado. É necessário distinguir pedido, comando emitido, retorno físico e confirmação de processo. O artigo sobre CLP detalha essa separação.
| Componente | Papel | Falha a evitar |
| CLP | Lógica e comando | Controle dependente da tela |
| IHM | Operação e informação | Estado exibido sem confirmação |
| SCADA | Supervisão ampla e históricos | Dados sem qualidade e contexto |
| Instrumentação | Medição do processo | Escalas inconsistentes |
Arquitetura de telas e hierarquia operacional
A definição técnica dos requisitos e interfaces orienta a contratação e reduz adaptações durante a implantação.
A navegação deve refletir o processo e a frequência das tarefas, não apenas a disposição física dos equipamentos. Telas de visão geral, área, equipamento e diagnóstico cumprem papéis distintos. Uma tela inicial precisa permitir reconhecer condições anormais e localizar a origem sem percorrer muitos menus.
O excesso de elementos decorativos e a repetição de alarmes reduz a legibilidade. A seleção de cores deve ter significado operacional consistente, com redundância de codificação por texto e símbolos quando necessário. Contraste, densidade de informação e uso em diferentes resoluções devem ser verificados na aplicação real.
O projeto deve explicitar quais tarefas exigem confirmação, quais podem ocorrer em modo automático e quais comandos são restritos a usuários autorizados. Uma interface bonita não necessariamente é uma interface operacionalmente adequada.
Variáveis de processo, escalas e qualidade de informação
Cada variável exibida precisa ter origem, unidade, faixa, frequência de atualização e qualidade definidas. A IHM não deve apresentar valores congelados após falha de comunicação como se estivessem atuais. Também deve distinguir medição real, valor estimado, setpoint, comando e retorno.
Alterações de parâmetros devem possuir limites, permissões e confirmação compatíveis com o risco. Um setpoint inserido fora da faixa prevista precisa ser bloqueado ou tratado conforme especificação. A apresentação da unidade de engenharia reduz erros de operação.
A lista de tags da IHM deve ser rastreável à especificação funcional do CLP e aos testes. Alterações de endereço ou tipo de variável podem provocar informação equivocada mesmo quando a conexão física permanece ativa.
Telas de operação, diagnóstico e manutenção
Uma tela de operação deve ajudar o usuário a responder: qual é o estado, o que está impedindo a partida, quem possui autoridade de comando e que ação é permitida? Um motor não deve ser marcado como ligado apenas porque a saída lógica foi acionada; confirmação depende do sinal apropriado.
Telas de diagnóstico podem apresentar estado de comunicação, módulos, intertravamentos e alarmes relevantes, sem expor controles de manutenção a operadores não autorizados. Intervenções com forçamento de sinais exigem procedimentos próprios e não devem ser viabilizadas por permissões genéricas.
| Tela | Informação principal | Aceite |
| Visão geral | Estado e alarmes prioritários | Localização rápida de anomalias |
| Área | Fluxo e variáveis relevantes | Coerência com processo |
| Equipamento | Comando, modo e retorno | Permissões verificadas |
| Diagnóstico | Motivos de bloqueio | Causa identificável |
Alarmes e prioridades na interface
Um alarme precisa representar condição que exige conhecimento ou ação do operador. Sua prioridade deve se relacionar à consequência e ao tempo disponível para agir, não apenas ao tipo de sinal. Excesso de alarmes pouco relevantes provoca fadiga e torna eventos críticos menos visíveis.
A interface deve mostrar identificação, descrição, momento, condição ativa, reconhecimento e orientação operacional quando apropriada. O reconhecimento não equivale à normalização física da causa. Históricos e relatórios precisam preservar essas distinções.
Mudanças de setpoint, supressões e comandos relevantes devem possuir mecanismos de registro conforme os requisitos operacionais. O tratamento de alarmes deve ser coordenado com o SCADA e com o controlador para evitar inconsistência entre telas.
Regras de comando, autoridade e modos
Os modos local, remoto, manual e automático devem ser definidos tecnicamente. Alterar o modo pode ter consequências sobre comandos pendentes, temporizações, permissivos e continuidade da operação. A IHM deve informar claramente quem controla o equipamento e quando um comando não será aceito.
As funções de segurança e os dispositivos de proteção não devem depender da aparência de uma tela. A interface pode refletir bloqueios e estados de segurança, mas sua visualização não substitui a avaliação da arquitetura responsável pela proteção.
O desenho de permissões deve considerar operação, manutenção e engenharia. Um usuário autorizado a consultar dados não deve necessariamente poder modificar parâmetros ou executar comandos. Isso precisa ser testado.
Arquitetura funcional da operação
A IHM integra o sistema como interface de operação conectada aos dados do controlador ou da supervisão. O comportamento em perda de rede precisa ser projetado, e o controlador deve continuar exercendo suas funções essenciais conforme especificação.
A arquitetura real pode envolver múltiplas estações, servidores e remotas. O projeto deve identificar claramente as origens de dados, permissões e responsabilidades.
Ensaios de usabilidade e FAT/SAT
O FAT da IHM deve verificar telas, navegação, comandos, escalas, alarmes e comportamento em falha de comunicação. Não basta constatar que objetos gráficos estão carregados. É necessário confirmar que cores, textos e estados representam informações reais e que comandos respeitam os permissivos.
O SAT exige validar a interface com instrumentos e equipamentos instalados e testar fluxos de operação em diferentes modos. A operação deve participar da avaliação para identificar lacunas de usabilidade que não aparecem em revisão exclusivamente de software.
| Ensaio | Critério | Evidência |
| Comando autorizado | Permissivos atendidos | Estado confirmado |
| Usuário sem permissão | Comando bloqueado | Registro de tentativa |
| Falha de rede | Dado inválido identificado | Tela e alarme |
| Navegação | Diagnóstico localizável | Roteiro operacional |
Como especificar e contratar uma IHM
O escopo deve definir telas, símbolos, convenções, arquitetura, listas de tags, matriz de alarmes, níveis de acesso, hardware ou estação e integração com CLP ou SCADA. A quantidade de telas não é métrica suficiente de qualidade; funções de operação e diagnóstico precisam ser verificáveis.
A engenharia de projeto de automação industrial organiza requisitos e responsabilidades antes do desenvolvimento. O recebimento deve incluir arquivos editáveis quando contratados, versões, testes, licenças e documentação de operação.
Uma interface com aparência sofisticada mas estados ambíguos pode aumentar risco de erro humano. O critério de escolha deve privilegiar compreensão operacional, resposta a falhas e manutenibilidade.
Requisitos de usuário e análise das tarefas operacionais
Uma interface homem-máquina deve ser concebida a partir das ações efetivamente realizadas pelos operadores. Isso inclui identificar processos, modos de operação, frequência de comandos, situações de emergência e necessidades de diagnóstico. Um desenho que reproduz o diagrama físico da planta nem sempre facilita a localização das informações necessárias. A especificação deve traduzir objetivos operacionais em telas e fluxos de navegação verificáveis.
Entrevistas de operação e manutenção ajudam a identificar pontos de confusão: estados com nomes semelhantes, alarmes sem consequência clara, parâmetros que não apresentam unidade e comandos cuja confirmação não está visível. Os requisitos precisam ser aprovados antes do desenvolvimento. Na ausência dessa etapa, o número de telas passa a orientar o orçamento, mas não garante que a interface reduz erros operacionais ou atende à rotina real.
Hierarquia visual, contexto e densidade de dados
A estrutura das telas deve distinguir visão geral, áreas, equipamentos e diagnóstico. A visão geral apresenta desvios significativos e estado operacional; a tela de área detalha relações entre unidades; a de equipamento mostra comandos, retornos, permissivos e variáveis relevantes. Diagnósticos aprofundados devem ser acessíveis sem sobrecarregar a operação normal. A navegação precisa permitir que uma anomalia seja localizada rapidamente.
O uso de cores deve ter semântica consistente em toda a aplicação. Elementos piscantes ou excessivamente saturados podem prejudicar a atenção se usados indiscriminadamente. Informações críticas precisam de texto e símbolos além de cores, respeitando condições reais de iluminação, distância de leitura e resolução. A avaliação de usabilidade deve ser feita no dispositivo previsto, e não somente na tela de desenvolvimento.
Qualidade da informação e estados inválidos
Uma IHM não deve apresentar o último valor recebido como se fosse medição atual quando a rede falha. A interface precisa distinguir condição válida, desatualizada, inválida ou simulada, conforme recursos disponíveis e requisitos da aplicação. Tags analógicas devem apresentar escala e unidade adequadas; estados discretos precisam distinguir pedido, comando, retorno e falha. Um ícone de motor em funcionamento não pode ser alimentado exclusivamente por um bit de comando.
A falta de qualidade dos dados é particularmente perigosa quando a tela permanece visualmente normal. Ensaios devem provocar perda de comunicação, falha de instrumento e retorno de serviço, observando como a interface sinaliza degradação. A equipe de operação deve conseguir identificar se pode confiar no valor mostrado antes de executar uma ação. Essas regras integram a especificação funcional e não podem ser definidas apenas pela aparência do objeto gráfico.
Matriz de comandos e autoridades de operação
Falhas de integração e comportamento degradado exigem diagnóstico antes de mudanças no sistema.
O sistema pode ter comandos locais, remotos, manuais e automáticos com precedências distintas. A IHM deve indicar a autoridade atual e impedir solicitações incoerentes com o modo. Ainda assim, a rejeição de comandos precisa estar implementada no nível responsável pelo controle, porque falhas da tela ou de comunicação não devem contornar permissivos funcionais. A interface informa o resultado do pedido e a confirmação real da ação quando disponível.
Uma matriz de comandos deve conter nome da ação, origem, papéis autorizados, condição de habilitação, confirmação exigida, alarme associado e registro de evento. Alterações de parâmetros precisam respeitar limites e aprovação quando aplicável. Os testes devem abranger usuários diferentes, tentativa de comando sem permissão, perda de autoridade e mudança de modo durante transições de processo.
Racionalização de alarmes e orientação de resposta
Um alarme útil informa uma condição que requer atenção ou ação. Prioridade, descrição e recomendação devem estar relacionadas ao risco e ao tempo disponível para resposta. Excesso de alarmes sem utilidade provoca fadiga e pode ocultar eventos críticos. A interface deve distinguir informação, aviso e alarme, com nomenclatura padronizada entre equipamentos e áreas.
O reconhecimento pelo operador deve ser separado da normalização da condição de campo. Supressão, inibição e manutenção precisam de regras próprias e registro de intervenções quando necessários. A equipe de operação deve participar da revisão para verificar se as descrições são compreensíveis. No FAT, é possível ensaiar ativação, reconhecimento e retorno; no SAT, a verificação com instrumentos reais ajuda a detectar divergências entre estados e dados.
IHM local e integração com SCADA
Uma IHM local pode permanecer disponível quando o supervisório central perde comunicação, desde que a arquitetura do controlador e da rede permita essa operação. Por isso, o projeto precisa definir limites e prioridades entre comandos locais e remotos. Um botão de partida na tela central e outro na interface local não devem gerar comandos incompatíveis ou estados que não possam ser rastreados.
A lista de variáveis deve usar significados coerentes nas duas aplicações. Quando o SCADA mostra uma bomba indisponível, mas a IHM a apresenta como disponível, o problema pode ser escala, endereço, estado de qualidade ou modelo de dados. Ensaios de integração precisam comparar sinais e respostas em ambos os ambientes. Os cenários de retorno da comunicação também devem ser verificados.
Diagnóstico para manutenção e tempo de recuperação
A qualidade da interface também se mede pela rapidez com que o operador consegue identificar a causa de uma falha. Uma mensagem genérica de equipamento indisponível oferece pouco apoio quando existem diferentes permissivos elétricos, hidráulicos e de comunicação. Uma tela de diagnóstico pode listar bloqueios, estados de remotas e confirmações, preservando a distinção entre causa comprovada e informação ausente.
O projeto deve definir quais diagnósticos são pertinentes ao operador e quais exigem acesso de manutenção. Essa separação reduz riscos de intervenções inadequadas e evita excesso de informações nas telas de operação. O conjunto de indicadores deve estar alinhado à documentação funcional do controlador. Uma informação inconsistente entre HMI e programa prejudica a recuperação da planta.
Ensaios de usabilidade com cenários reais
Os ensaios precisam comprovar funcionamento, falhas e recuperação com evidências vinculadas aos requisitos.
A validação de uma IHM deve simular situações concretas: localizar a bomba em falha, identificar o permissivo ausente, reconhecer um alarme, verificar uma mudança de modo e confirmar uma partida. O roteiro precisa avaliar se o operador encontra a informação sem ambiguidades. Também é necessário observar legibilidade, unidades, nomenclatura, sequência de navegação e respostas após perda de rede.
O teste não deve avaliar apenas se cada objeto aparece na tela. É preciso verificar se o comportamento apresentado representa corretamente o processo. Participação de operadores e mantenedores permite identificar problemas que escapam a uma revisão de engenharia exclusivamente documental. As correções devem resultar em versão controlada e novos ensaios dos fluxos afetados.
Design de interfaces e controle de mudanças
A filosofia visual deve ser um documento controlado, com convenções de símbolos, cores, identificadores, permissões e alarmes. Isso possibilita expansões futuras sem gerar telas inconsistentes. Mudanças em bibliotecas gráficas ou padrões de representação podem afetar vários equipamentos, e o impacto precisa ser avaliado antes da aplicação em produção.
O backup da IHM deve contemplar arquivos editáveis e versões conforme contrato, além de configuração, licenças e procedimentos de restauração. A manutenção precisa conhecer dependências com CPU, comunicação e sistemas supervisórios. Alterar o nome ou tipo de uma tag no controlador pode quebrar a apresentação ou o comando da interface mesmo quando a tela ainda abre normalmente.
Contratação por requisitos e aceite operacional
O termo de referência deve definir tarefas, funções, telas, arquitetura, lista de tags, acessos, alarmes e entregáveis. Uma proposta baseada apenas na quantidade de telas pode incentivar soluções gráficas extensas sem atender às necessidades operacionais. É necessário avaliar complexidade das interações, número de equipamentos, modos, integrações e exigência de diagnósticos.
Os marcos de medição podem contemplar filosofia aprovada, telas desenvolvidas, FAT, integração, SAT e documentação final. A matriz de aceite deve relacionar requisitos a casos de uso e evidências. A empresa contratante precisa receber treinamento e documentação suficientes para manter o sistema e revisar parâmetros de forma controlada. A qualidade de uma IHM se demonstra pela operação verificável, não apenas pelo acabamento gráfico.
Exemplo de operação: transferência de bomba principal e reserva
Considere uma instalação com duas bombas em que o operador pode visualizar disponibilidade e selecionar a preferência de operação. A IHM deve mostrar separadamente comando emitido, retorno elétrico, estado da bomba e condições que impedem a partida. Se a principal falhar, a tela precisa indicar causa e estado da reserva, sem permitir assumir que a transferência ocorreu apenas porque foi solicitado um novo comando.
Os cenários de ensaio incluem falha de confirmação, nível baixo, modo local selecionado no painel e comunicação indisponível. É necessário verificar que o operador identifica a situação com rapidez e que comandos não autorizados são recusados pelo controlador. A interface deve apoiar entendimento operacional e não criar a impressão de controle onde existem bloqueios ou informações inválidas.
Indicadores de qualidade e alarmes de comunicação
Uma falha de rede pode deixar vários valores congelados simultaneamente. O projeto deve indicar dados não confiáveis com representação distinta, preservando a informação de origem e evitando transformar toda perda de comunicação em alarmes de processo falsos. Um operador que recebe inúmeras mensagens sem causa identificável pode perder visibilidade de um evento prioritário. A filosofia de alarmes deve distinguir indisponibilidade de dados de desvio real da grandeza física.
A interface precisa mostrar último horário válido quando esse dado for relevante, status de comunicação e limites de operação degradada. O ensaio deve forçar desconexão, reconexão e atualização de dados, verificando se valores antigos são invalidados corretamente. Essa abordagem aumenta confiabilidade sem depender de decoração gráfica adicional.
Padronização de símbolos e vocabulário
A biblioteca de objetos gráficos deve possuir convenções documentadas para motores, válvulas, sensores, bombas e dispositivos de controle. Símbolos semelhantes precisam representar estados equivalentes em diferentes áreas. A nomenclatura deve refletir o processo e a identificação adotada nos diagramas, evitando abreviações que apenas o programador original compreende. O uso coerente de unidades e alarmes facilita treinamento.
Quando um projeto reúne fornecedores diferentes, um padrão de interface permite preservar continuidade de operação. As exceções devem ser registradas e aprovadas em vez de introduzidas informalmente durante o desenvolvimento. A revisão deve incluir legibilidade no tamanho real do painel e situações de iluminação previstas no ambiente.
Matriz de testes com participação de operadores
O plano de aceitação deve envolver usuários representativos para percorrer tarefas críticas. Entre os cenários estão localizar alarme, identificar permissivo ausente, alterar setpoint autorizado, verificar o modo de operação e confirmar atuação física. A evidência precisa registrar qual tela foi usada, qual condição foi apresentada, qual decisão era esperada e se o resultado foi compreendido. O teste deve avaliar função, não somente aparência.
Situações anormais merecem atenção especial, pois uma interface que funciona bem em operação estável pode gerar ambiguidades durante falha de instrumento. As correções de texto, cor, hierarquia ou lógica devem ser versionadas e retestadas. O recebimento técnico se apoia na capacidade demonstrada de operar e diagnosticar, não no número de telas desenvolvidas.
Entrega, recuperação e treinamento
A documentação final deve disponibilizar filosofia de telas, biblioteca de símbolos, lista de variáveis, permissões, alarmes, versões e procedimento de backup, conforme limites contratuais. Também deve indicar como reconstruir a aplicação e restaurar uma estação de operação. Em uma IHM conectada a diferentes sistemas, a equipe precisa conhecer dependências de firmware, controladores e redes.
O treinamento deve cobrir funções normais, estados degradados, limites de autoridade e diagnóstico. Quando uma interface é modificada após entrada em operação, a atualização dos operadores precisa acompanhar as novas funções. Isso reduz dependência do fornecedor e ajuda a manter coerência entre software, documentação e prática operacional.
Requisitos de acessibilidade e legibilidade operacional
A apresentação visual precisa favorecer compreensão sob diferentes condições de uso. Elementos relevantes devem ser identificáveis por texto e símbolos além da cor; números e unidades precisam ter contraste e tamanho compatíveis com o painel ou monitor. Um estado de alarme não deve depender exclusivamente de um indicador piscante ou de uma tonalidade que possa ser confundida com outra condição. Essas decisões precisam ser avaliadas no equipamento real.
Uma interface usada por operadores em turnos extensos deve reduzir carga cognitiva e favorecer reconhecimento de estados. A consistência de navegação, a escolha de nomes e a organização de diagnósticos são tão relevantes quanto a precisão das leituras. A engenharia deve registrar as convenções de interface e realizar testes com cenários representativos.
Método de aceitação das telas de operação
Cada tela precisa estar associada a funções aprovadas e a uma matriz de variáveis. O ensaio deve comparar valores conhecidos com os números exibidos, provocar estados de falha e verificar a resposta de elementos gráficos. Botões e campos editáveis devem ser testados sob diferentes permissões, incluindo tentativa de alteração fora dos limites previstos. A interface deve indicar claramente quando um pedido foi recusado pelo CLP.
A avaliação também precisa verificar navegação, descrição dos alarmes, mudança de modo e recuperação após desconexão. O SAT deve confirmar que os dados representam os equipamentos reais. O registro de testes deve identificar versão da tela, configuração do controlador, resultado e pendências.
Desenvolvimento para futuras expansões da planta
A arquitetura gráfica precisa permitir acrescentar equipamentos sem introduzir padrões visuais contraditórios. Bibliotecas de objetos, convenções de tags, estruturas de menus e critérios de alarmes devem ser documentados. Uma expansão não deve exigir redesenhar toda a interface apenas porque as telas originais foram construídas sem padronização. O projeto pode prever componentes reutilizáveis desde que os parâmetros e permissões sejam testados.
A manutenção deve dispor de arquivos editáveis quando contratados, licenças, backups e versões compatíveis. Alterações de CPU ou protocolo precisam ser analisadas quanto ao impacto nas variáveis e telas. A governança de mudanças reduz falhas introduzidas por atualizações aparentemente simples.
Critérios comerciais e responsabilidade pelo aceite
A especificação de contratação deve detalhar quantidade de equipamentos, funções de operação, grupos de telas, diagnósticos, permissões, alarmes e integração. O preço por tela é uma referência incompleta quando existem complexidades muito diferentes entre interfaces. Um painel com poucas telas pode exigir validação rigorosa de comandos e estados, enquanto várias telas informativas podem ter menor complexidade.
Os marcos de entrega podem considerar filosofia aprovada, arquitetura, desenvolvimento, FAT, testes integrados, SAT e documentação final. A aceitação precisa comprovar usabilidade e comportamento funcional. Responsabilidades entre programadores do CLP, integradores e operadores devem estar claramente atribuídas para evitar lacunas de verificação.
Considerações finais
O desempenho de uma IHM industrial deve ser avaliado pela qualidade das decisões que permite ao operador tomar. Uma interface adequada apresenta estados, modos, permissivos, comandos e confirmações sem ambiguidades, organiza a navegação de acordo com as tarefas reais e distingue dados válidos de medições indisponíveis ou desatualizadas. O acabamento gráfico, isoladamente, não garante que um operador consiga identificar rapidamente a causa de uma falha ou executar a ação correta.
O projeto deve manter a separação entre intenção de comando, autorização no controlador e confirmação física do processo. Matrizes de permissões, filosofia de alarmes, padrões de símbolos, escalas e hierarquia das telas são documentos de engenharia que precisam estar coerentes com as funções do CLP e com o supervisório. A mesma lógica deve orientar modos locais e remotos, intervenções de manutenção e condições degradadas, evitando que a interface apresente um estado aparente diferente da condição operacional.
O aceite de uma IHM precisa ir além da inspeção estética: requer casos de uso com operadores, verificações de comandos permitidos e bloqueados, perda de comunicação, alarmes, navegação e recuperação. Cada cenário deve produzir evidência associada à versão entregue e à especificação funcional. Quando essas verificações são incorporadas ao contrato e à documentação final, a interface passa a apoiar operação segura, manutenção e expansão da planta de forma consistente.
Referências técnicas
[1] IEC. IEC 61131-3:2025 — Programming languages. Disponível em: https://webstore.iec.ch/en/publication/68533.
[2] NIST. Guide to Operational Technology Security. Disponível em: https://csrc.nist.gov/pubs/sp/800/82/r3/final.
[3] PLCOPEN. Software Construction Guidelines. Disponível em: https://www.plcopen.org/guidelines/software-construction-guidelines/.
[4] SIEMENS. Industry Online Support. Disponível em: https://support.industry.siemens.com/.
[5] ISA. Standards and Publications. Disponível em: https://www.isa.org/standards-and-publications.
Perguntas frequentes
Por requisitos, desempenho, interfaces, disponibilidade e manutenção.
Testes em fábrica ou bancada conforme escopo documentado.
Ensaios de aceitação no ambiente instalado e nas interfaces reais.
Descrição funcional, arquitetura, sinais, versões, configurações, planos e evidências de teste.
Com diagnóstico, qualidade dos dados e estados de contingência especificados.
Testes rastreáveis aos requisitos e registro das pendências e retestes.
Com controle de versões, avaliação de impacto, backup e regressão.
Escopo, interfaces, responsabilidades, entregáveis e critérios de verificação.
Controle, interface de operação e supervisão, respectivamente.
