Matriz de Rastreabilidade de Requisitos: planilha Excel gratuita e como usar

A Matriz de Rastreabilidade de Requisitos de Engenharia (RTM — Requirements Traceability Matrix) em Excel é um modelo editável para acompanhar cada exigência técnica desde sua origem e aprovação da baseline até as verificações, as evidências e o aceite formal. A planilha gratuita R00 inclui dez abas, 250 posições para requisitos, 350 registros de verificação, 350 evidências documentais, 200 mudanças e um painel com indicadores automáticos. Também contém vinte exemplos fictícios de engenharia multidisciplinar, separados dos dados do projeto.

O objetivo não é produzir mais uma lista de pendências. Uma RTM deve permitir responder qual requisito existe, de onde veio, a qual sistema foi atribuído, qual método comprovará seu atendimento, em que documento está a evidência, quem analisou a prova e qual decisão formal encerra a obrigação. Sem essa cadeia, o empreendimento pode apresentar desenhos aprovados e ainda não conseguir demonstrar que suas necessidades de desempenho, segurança, integração e operação foram realmente atendidas.

O que é uma matriz de rastreabilidade de requisitos?

A RTM é o registro controlado que conecta necessidades, condições técnicas, compromissos de fornecimento, requisitos de projeto, procedimentos de teste, resultados, evidências e decisões. A ferramenta é aplicável a empreendimentos industriais, instalações elétricas, redes e telecomunicações, infraestrutura, automação, CFTV, controle de acesso, obras complexas e outros contextos multidisciplinares. Pode ser utilizada tanto na engenharia consultiva quanto em EPC/EPCM, Owner’s Engineering, fiscalização, suprimentos, comissionamento e entrega final.

Requisito não é sinônimo de solução: “garantir que o sistema opere em condição de contingência” é uma necessidade, mas exige definição de comportamento, limites, eventos, tempo de resposta ou evidências pertinentes antes de se tornar verificável. A RTM ajuda a decompor a necessidade em condições testáveis e a rastrear suas decisões. Veja o artigo Gestão de Requisitos em Engenharia: definição, rastreabilidade, mudanças e aceite para aprofundar a base conceitual.

Matriz RTM, MDR, RACI e Matriz de Interfaces: funções complementares

Esses registros podem compartilhar códigos e referências, porém não devem competir como fontes diferentes da mesma informação. A RTM referencia o documento pelo código controlado; a MDR governa sua emissão e revisão. A RTM identifica o requisito verificável; a gestão de interfaces formaliza fronteiras e atributos compartilhados, conforme o artigo sobre Gestão de Interfaces em Projetos de Engenharia.

O que a planilha de rastreabilidade de requisitos contém?

A planilha não utiliza macros e distingue visualmente dados editáveis, fórmulas e alertas. A identificação editorial A3A Engenharia / by ENGiOS é uma composição gráfica rasterizada, sem arquivos separados das marcas originais. Os exemplos não alimentam os indicadores da base de produção.

Como implantar a RTM: dez etapas de engenharia

1. Identifique a origem real do requisito

Comece pelo escopo contratado, Termo de Referência, especificações técnicas, critérios do proprietário, necessidades dos usuários, restrições de operação, segurança, normas aplicáveis, interfaces e documentos de fornecedores. Registre a fonte e a cláusula ou referência exata. Uma frase como “conforme especificação” sem número, revisão ou item de origem dificulta a análise de mudança e a auditoria posterior.

Evite cadastrar como requisito toda afirmação contida num memorial. O registro deve representar algo que a solução precisa demonstrar, entregar ou preservar. Se o requisito for originado de norma, a equipe deve verificar a edição aplicável e a condição de uso; o modelo não cria automaticamente obrigações normativas universais.

2. Escreva requisitos claros, singulares e verificáveis

Um bom requisito identifica sujeito, comportamento ou condição exigida, contexto e forma de verificar. Em vez de “rede elétrica de boa qualidade”, descreva a grandeza e o critério pertinentes definidos pelo projeto e pelo contrato. Não invente níveis de desempenho para preencher a planilha; utilize parâmetros aprovados ou conduza a análise técnica necessária para estabelecê-los.

A identificação por código único, como REQ-001, permite referenciar o requisito sem depender do título. Requisitos derivados podem apontar um código pai, de modo que a solução de subsistema permaneça ligada à necessidade de nível superior. A auditoria automatizada sinaliza IDs duplicados, referência de pai inexistente e autorreferência.

3. Atribua o requisito a sistema, disciplina, pacote e responsável

Na aba REQUISITOS, informe sistema ou ativo, disciplina, pacote de contratação, owner técnico, criticidade e método previsto. Em uma infraestrutura de CFTV, por exemplo, um requisito pode estar alocado ao pacote de rede, embora sua necessidade original tenha sido definida pelo sistema de videomonitoramento. Esse vínculo deve ser reconciliado com a Matriz de Interfaces para não criar uma lacuna entre fornecedor e consumidor da informação.

A atribuição do owner técnico não equivale automaticamente à autoridade de aprovação contratual. Diferencie quem especifica, quem verifica, quem emite parecer e quem possui competência para aceitar o requisito em nome do proprietário.

4. Aprove uma baseline e registre sua revisão

A baseline é a referência contra a qual modificações e desempenho serão avaliados. Antes da execução, identifique a revisão aprovada, o responsável pela decisão e o registro que sustenta a aprovação. O campo de baseline não é uma sequência de números decorativos: ele representa um conjunto de requisitos aceitos como referência de escopo e projeto num momento definido.

Quando o requisito mudar, mantenha seu ID e controle a evolução da revisão. Modificar a descrição original sem solicitação, análise e decisão de mudança destrói a rastreabilidade. A RTM permite relacionar solicitação de alteração, impacto em prazo, custo, segurança e disciplina, decisão e versão de baseline atualizada.

5. Associe um plano de verificação específico

Para cada requisito, determine se a conformidade será demonstrada por análise, inspeção, demonstração, simulação, revisão documental ou teste. Em sistemas de engenharia, um requisito poderá exigir mais de uma verificação em diferentes fases: revisão de projeto, FAT no fornecedor, SAT no campo e ensaio integrado. Cadastre cada verificação com ID próprio na aba VERIFICACOES e aponte o mesmo REQ ID da matriz principal.

O critério de aceitação deve existir antes do ensaio. Se não há método, resultado esperado e evidência prevista, o teste corre o risco de se transformar em uma atividade sem conclusão objetiva. A RTM conta todos os testes vinculados válidos como registros e só permite liberar o gate quando a cobertura de verificações está completa.

6. Execute testes e registre resultados observáveis

Registre executor, data prevista, data real, procedimento utilizado, critério, valor ou ocorrência observada, resultado e identificação de quem revisou a execução. “Conforme” sem data, resultado técnico ou revisor não significa verificação validada pela planilha. Resultados não conformes devem gerar análise, correção e eventual repetição do ensaio com uma nova evidência, preservando a histórico do resultado anterior.

A conclusão da verificação não equivale ao aceite final do requisito, mesmo que todos os valores tenham atendido aos critérios do procedimento. A autoridade de aceite pode exigir consolidação de diferentes testes, outras evidências e atendimento de condições contratuais.

7. Vincule evidências ao requisito e ao teste correto

Na aba EVIDENCIAS, cada registro deve informar seu ID, o REQ ID, o ID da verificação, tipo, documento, revisão, local de armazenamento, data, emissor, decisão de análise, revisor e data de decisão. O vínculo cruzado evita que um relatório de um subsistema seja contabilizado como comprovação de outro. A prova somente aparece como válida quando os campos críticos estão completos e sua revisão foi expressamente aceita.

O caminho ou link deve apontar para fonte governada — por exemplo, um EDMS, repositório contratual ou documento emitido sob revisão controlada. A existência do arquivo não certifica, por si, a qualidade do ensaio. A fórmula verifica consistência documental, não substitui inspeção do conteúdo técnico da evidência.

8. Trate mudanças antes de atualizar a baseline

Uma alteração solicitada precisa receber ID, justificativa, avaliação de impacto e decisão. Se aprovada, deve registrar autoridade, data, evidência da aprovação e nova baseline. A planilha mantém a mudança como pendência bloqueante quando foi classificada como aprovada, mas não possui comprovação da decisão ou quando a nova revisão ainda não foi incorporada ao registro de requisitos.

Depois da alteração, a equipe deve revisar os procedimentos de teste, as especificações e a pertinência das evidências produzidas sob a configuração anterior. Uma prova válida para a baseline R00 não é automaticamente adequada à R01. A RTM ajuda a localizar esses vínculos, mas a avaliação de revalidação técnica depende do conteúdo modificado.

9. Verifique o gate de conclusão no painel

A aba RASTREIO reúne automaticamente os dados de cada requisito, e o PAINEL apresenta os totais de requisitos, testes, evidências, não conformidades, mudanças abertas, entregas vencidas e registros bloqueados. O gate considera a quantidade de verificações vinculadas, verificações conformes válidas, evidências aceitas, não conformidades e mudanças pendentes.

As situações são sinais de governança, não laudos ou certificações. O indicador “APTO PARA ACEITE” sugere que a cadeia documental está pronta para a decisão competente; não autoriza por si só colocar equipamentos ou sistemas em operação.

10. Formalize o aceite e prepare a entrega técnica

O status informado “Aceito” não é suficiente. É necessário incluir o documento ou protocolo formal de aceite, data e autoridade responsável. A condição automática “ACEITO COMPROVADO” exige adicionalmente o atendimento dos controles documentais e a ausência de mudanças pendentes ou verificações não conformes. Na etapa final, a equipe deve conciliar RTM, MDR, As-Built, resultados de FAT/SAT, registros de comissionamento, documentos de fornecedores, Data Book e manuais de operação.

Exemplos de rastreabilidade em sistemas de engenharia

A aba EXEMPLO inclui vinte requisitos fictícios de redes, CFTV, controle de acesso, instalações elétricas, SPDA, automação, HVAC, comissionamento e outros sistemas. Três exemplos ilustram como a mesma metodologia muda conforme a natureza do requisito.

Não se deve importar os valores de exemplos de outro empreendimento como se fossem critérios normativos. A fonte de cada exigência deve ser definida e verificada no contexto do contrato e das normas aplicáveis.

Indicadores úteis para acompanhar a matriz

Além do número de requisitos cadastrados, recomende acompanhar percentual de requisitos com origem identificada, cobertura de verificação, quantidade de testes não conformes, evidências em análise, mudanças aprovadas ainda não incorporadas à baseline, requisitos críticos vencidos e aceites formais. A edição gratuita traz contagens e uma visão de gates; indicadores adicionais podem ser derivados no processo de gestão conforme o porte e risco do projeto.

O progresso percentual da RTM é apenas uma leitura auxiliar, não uma medição contratual e não equivale ao percentual financeiro ou físico do empreendimento. Se cada requisito tiver pesos ou relevâncias muito diferentes, uma simples contagem pode ser enganosa. Em contratos com grandes volumes, estabeleça metodologia formal para agregação e análise de criticidade.

Erros comuns na gestão de requisitos de engenharia

• Escrever exigências impossíveis de verificar: falta definição operacional e nenhum teste consegue demonstrar atendimento.
• Eliminar a origem: requisitos perdem vínculo com cláusulas, necessidades do Owner ou normas aplicáveis.
• Trocar o ID quando a revisão muda: quebra a cadeia entre baseline, teste, evidência e decisão.
• Contabilizar “Conforme” sem prova revisada: o resultado informado não é, sozinho, uma evidência aceita.
• Confundir aprovação de documento com atendimento do requisito: um projeto aprovado ainda pode não estar implantado ou testado.
• Fechar teste de uma revisão antiga depois de uma mudança: a validade da prova precisa ser reavaliada.
• Marcar “Aceito” sem documento formal: cria aparência de fechamento contratual sem demonstração suficiente.
• Tratar a matriz como certificação: a planilha não substitui projeto, responsável técnico, inspeção ou autoridade contratual.

Como a RTM complementa a governança e o ENGiOS

Em projetos de menor porte, uma planilha bem estruturada pode ajudar a estabelecer disciplina de requisitos e registros. Quando existem muitos contratos, fases, disciplinas e fornecedores, o desafio passa a ser manter regras, revisões, alçadas, documentos e evidências integradas sem planilhas paralelas. Nesse cenário, um ambiente de gestão de engenharia e Document Control permite tratar a RTM como parte de um processo mais amplo, preservando a relação entre especificação, documento, decisão, mudança e aceite.

O acervo da A3A Engenharia reúne métodos de gestão de engenharia, controle documental e modelos complementares. Na necessidade de implantação organizacional, o serviço de Estruturação da Gestão de Engenharia trata de processos, responsabilidades, interfaces, controles e operacionalização das rotinas, que podem ser apoiadas pelo ENGiOS.

Como obter a Matriz de Rastreabilidade de Requisitos em Excel

Formato: XLSX editável e sem macros. Revisão: R00. Capacidade: 250 requisitos, 350 verificações, 350 evidências e 200 mudanças. Abas: INICIO, REQUISITOS, VERIFICACOES, EVIDENCIAS, MUDANCAS, RASTREIO, PAINEL, EXEMPLO, CONFIG e FLUXO. Identidade editorial: A3A Engenharia / by ENGiOS, em composição rasterizada sem logotipos originais separados.

Para solicitar gratuitamente a Matriz de Rastreabilidade de Requisitos em Excel, preencha o formulário de download desta página com nome e e-mail. A solicitação do material não implica contratação nem adesão automática a comunicações promocionais sem consentimento específico.

Antes de utilizar o material em empreendimento real, personalize suas listas, codificação, critérios, autoridade de aprovação, procedimentos de teste e requisitos contratuais. A planilha é um instrumento de apoio à governança e não substitui a avaliação técnica, a responsabilidade profissional ou o aceite pelo proprietário. Curadoria editorial: Eng. Altair Galvão.