Use este modelo
Na maioria das implementações de sistemas, os requisitos vivem num documento, os designs noutro, os casos de teste numa ferramenta de testes e os SOPs, runbooks e formação em pastas a que ninguém liga. Depois, um requisito muda, surge um defeito ou um auditor pergunta como é que um controlo foi testado, e ninguém consegue dizer onde é que aquele requisito foi parar. Um modelo de matriz de rastreabilidade de requisitos resolve isso ao ligar cada requisito, numa única tabela, a tudo o que o entrega e prova que funciona.
Este modelo gratuito de matriz de rastreabilidade de requisitos liga cada requisito ao seu documento de requisitos funcionais (FRD) na respetiva secção, ao design, ao item de configuração ou de construção, ao SOP ou runbook que o opera, aos casos de teste que o verificam, à formação que o ensina e ao seu estado atual. Inclui um exemplo preenchido, os tipos de rastreabilidade a usar e uma forma de manter a matriz atualizada à medida que o projeto evolui. Copie a estrutura abaixo ou abra-a no Trupeer e personalize-a para o seu projeto.
O que é um modelo de matriz de rastreabilidade de requisitos?
Um modelo de matriz de rastreabilidade de requisitos, frequentemente chamado RTM, é uma tabela estruturada que liga cada requisito aos documentos e aos itens de trabalho que o entregam e verificam. Cada linha começa com um requisito e faz o seu seguimento até à especificação funcional, ao design e à construção, ao SOP ou runbook que as pessoas usam para o operar, aos casos de teste que provam que funciona e à formação que prepara os utilizadores. Também pode fazer rastreio para trás, de um caso de teste ou SOP até ao requisito que serve.
O resultado é uma única visão que responde às perguntas que todo o projeto acaba por fazer: todos os requisitos estão cobertos? O que é afetado se isto mudar? E como é que sabemos que funciona?
Porque usar uma matriz de rastreabilidade de requisitos?
Nada fica por preencher. Cada requisito tem de ter um design, um teste e um responsável.
O impacto da mudança é visível. Quando um requisito muda, pode ver todos os documentos, testes e SOPs afetados.
O teste está completo. Cada requisito liga-se a pelo menos um caso de teste, e cada caso de teste liga-se de volta a um requisito.
As operações estão prontas. Os requisitos ligam-se aos SOPs e runbooks que as pessoas vão usar após o go-live, não apenas à construção.
As auditorias são mais fáceis. Pode mostrar como é que um requisito de controlo foi concebido, testado e documentado.
As transições são mais limpas. A equipa de operações herda um mapa do que foi construído e do porquê.
Quem usa um modelo de matriz de rastreabilidade de requisitos?
Analistas de negócio que detêm os requisitos e as respetivas ligações.
Gestores de projeto e de programa que acompanham a cobertura e o impacto da mudança.
Arquitetos de soluções e consultores funcionais que concebem e constroem com base nos requisitos.
Gestores de testes que confirmam a cobertura de testes.
Equipas de operações e suporte que detêm os SOPs e runbooks após o go-live.
Responsáveis por formação que garantem que cada processo alterado tem formação.
Equipas de qualidade, risco e auditoria que precisam de evidência dos requisitos de controlo.
Pré-visualize o modelo de matriz de rastreabilidade de requisitos
O modelo abre com um resumo do projeto e convenções de ID. Segue-se a matriz principal, com uma linha por requisito: ID, descrição, origem, prioridade, secção do FRD, item de design ou de construção, SOP ou runbook, casos de teste, estado do teste, conteúdo de formação, responsável e estado geral. Um resumo de cobertura mostra os requisitos sem designs, testes, SOPs ou formação, e um registo de alterações regista cada mudança a um requisito e o respetivo impacto. Todas as colunas são editáveis, para que possa adicionar referências regulamentares, números de versão ou ligações às suas ferramentas.
Como personalizar este modelo no Trupeer
Passo 1: Abra a secção Templates
Aceda à secção Templates no menu principal.
Passo 2: Selecione e abra um modelo
Clique em qualquer modelo com que queira trabalhar para o abrir.
Passo 3: Expanda a vista do modelo
Se necessário, expanda a vista do modelo para ver o layout completo e os detalhes com clareza.
Passo 4: Edite o modelo
Clique em Edit para começar a modificar o modelo selecionado.
No editor, pode:
Adicionar novas secções
Definir ou atualizar regras de formatação
Adicionar um logótipo e ajustar a sua posição e definições relacionadas
Passo 5: Guarde o seu modelo personalizado
Depois de fazer todas as alterações necessárias, clique em Save para guardar o modelo atualizado como seu.
Passo 6: Pré-visualize e ajuste o modelo
Quando quiser ver como fica o seu modelo personalizado, abra o Preview.
A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o pretende.
Com um modelo de matriz de rastreabilidade de requisitos, pode:
Comprovar a cobertura: Veja de relance quais os requisitos que estão concebidos, construídos, testados e documentados.
Rastrear requisitos até às operações: Ligue cada requisito ao SOP ou runbook que o executa após o go-live.
Avaliar rapidamente o impacto da mudança: Encontre, em segundos, todos os documentos, testes e SOPs afetados.
Apoiar auditorias e conformidade: Mostre como cada requisito foi entregue e verificado.
Fazer uma transição limpa: Dê à equipa de operações um mapa completo do sistema.
O que um modelo de matriz de rastreabilidade de requisitos tem de conter
Coluna | O que registar |
|---|---|
ID do requisito | Uma referência única e estável, como REQ-P2P-014 |
Descrição do requisito | O que o negócio precisa, em linguagem simples |
Origem | De onde veio: workshop, regulamento, linha fit-gap ou registo as-is |
Prioridade | Deve ter, devia ter ou podia ter |
Secção do FRD | A secção do documento de requisitos funcionais que o especifica |
Item de design ou de construção | Configuração, objeto de desenvolvimento ou interface que o entrega |
SOP ou runbook | O procedimento de operação que as pessoas seguem para o executar ou suportar |
IDs dos casos de teste | Os casos de teste ou scripts de UAT que o verificam |
Estado do teste | Não executado, aprovado, reprovado ou bloqueado |
Conteúdo de formação | O guia ou vídeo que ensina a mudança aos utilizadores |
Responsável | A pessoa responsável pelo requisito |
Estado | Aberto, em design, em construção, testado, documentado ou fechado |
Histórico de alterações | Alterações ao requisito e o respetivo impacto |
Modelo gratuito de matriz de rastreabilidade de requisitos: a estrutura para copiar
Copie a estrutura abaixo para a sua própria folha de cálculo ou abra-a no Trupeer e personalize-a.
1. Resumo do projeto. Projeto: [name]. Sistema: [system and release]. Âmbito: [processes]. Responsável pela RTM: [business analyst or PMO]. Última atualização: [date].
2. Convenções de ID. Requisitos: REQ-[process]-[number]. Secções do FRD: FRD-[section]. Itens de construção: [development or configuration IDs]. SOPs e runbooks: SOP-[number] ou RB-[number]. Casos de teste: TC-[number] ou UAT-[number].
3. Matriz de rastreabilidade.
Req ID | Requisito | Origem | Prioridade | Secção do FRD | Item de design ou de construção | SOP ou runbook | Casos de teste | Estado do teste | Formação | Responsável | Estado |
|---|---|---|---|---|---|---|---|---|---|---|---|
[REQ-ID] | [Description] | [Source] | [Must / should / could] | [FRD-x.x] | [Item ID] | [SOP or RB ID] | [TC or UAT IDs] | [Status] | [Guide or video] | [Owner] | [Status] |
4. Resumo de cobertura. Requisitos sem uma secção do FRD, sem um item de construção, sem um caso de teste, sem um SOP ou runbook e sem formação.
5. Registo de alterações. Data, ID do requisito, alteração, motivo, itens afetados e aprovação.
Exemplo de matriz de rastreabilidade de requisitos: procure to pay
Veja como parte de uma RTM pode ficar para procure to pay numa implementação de ERP. Os detalhes são apenas ilustrativos.
Req ID | Requisito | Secção do FRD | Item de construção | SOP ou runbook | Casos de teste | Estado do teste | Formação | Estado |
|---|---|---|---|---|---|---|---|---|
REQ-P2P-014 | Faturas de mercadorias com correspondência a três vias dentro da tolerância | FRD-4.2 | Configuração de tolerância | SOP-AP-003 processamento de faturas | Passos UAT-P2P-001 3–4 | Aprovado | Vídeo de faturas AP | Fechado |
REQ-P2P-015 | Bloquear faturas acima da tolerância de preço para revisão do comprador | FRD-4.3 | Configuração de bloqueio de pagamento | SOP-AP-003, tabela de exceções | UAT-P2P-001 passo 5 | Reprovado e depois aprovado na reavaliação | Vídeo de exceções AP | Fechado |
REQ-P2P-021 | Interface noturna de faturas aprovadas para o sistema de pagamento | FRD-6.1 | Interface INT-07 | Runbook de monitorização da interface RB-INT-07 | TC-INT-07-01 a 04 | Aprovado | Percurso do runbook da equipa de suporte | Testado |
REQ-P2P-030 | Verificar alterações nos dados bancários do fornecedor antes do pagamento | FRD-3.5 | Fluxo de trabalho de dupla aprovação | SOP-VMD-002 verificação de alteração bancária | UAT-VMD-004 | Não executado | Vídeo do mestre de fornecedores | Em construção |
Cada linha mostra não só se o requisito foi construído e testado, mas também como vai ser operado: o SOP para utilizadores de negócio e o runbook para as equipas de suporte.
Tipos de rastreabilidade
Tipo | Direção | O que responde |
|---|---|---|
Rastreabilidade para a frente | Requisito → design → construção → teste → SOP | Todos os requisitos são entregues, testados e documentados? |
Rastreabilidade para trás | Teste, SOP ou item de construção → requisito | Tudo o que construímos ou escrevemos serve um requisito? |
Rastreabilidade bidirecional | As duas direções | Cobertura total e sem trabalho desnecessário; o padrão para a maioria dos projetos |
Use rastreabilidade bidirecional na maioria das implementações de sistemas. Apanha testes e documentação em falta e também apanha trabalho personalizado e procedimentos que já não fazem rastreio até um requisito.
A cadeia de rastreabilidade ao longo de uma implementação
A matriz liga documentos que normalmente são produzidos por equipas diferentes em momentos diferentes. É assim que se encaixam:
Fase | Documento | O que a matriz liga |
|---|---|---|
Descobrir | Registos as-is e documentos | A evidência por trás de cada requisito |
Explorar | Análise fit-gap | Quais os requisitos que se enquadram no padrão e como é que as lacunas são resolvidas |
Especificar | Documento de requisitos funcionais (FRD) | A secção que especifica cada requisito |
Construir | Itens de configuração e de desenvolvimento | O que entrega cada requisito |
Testar | Casos de teste e scripts de UAT | Como cada requisito é verificado, com resultados |
Implementar | SOPs, runbooks e formação | Como as pessoas operam e suportam cada requisito após o go-live |
Executar | Pedidos de alteração e releases | O que muda e quais os documentos e testes afetados |
Para os requisitos e as decisões de lacunas no início da cadeia, use o modelo de análise fit-gap.
Rastreabilidade de requisitos para processos regulamentados e auditados
Em indústrias regulamentadas e para controlos financeiros, a rastreabilidade não é opcional. Normalmente, os auditores e as equipas de validação querem ver, para cada controlo ou requisito regulamentado, a especificação, a evidência de teste e o procedimento que as pessoas seguem. Adicione uma coluna para a referência do regulamento ou do controlo, assinale quais os requisitos que são controlos e anexe a evidência de teste, como registos de UAT, diretamente a essas linhas. Revise os requisitos de controlo antes de cada release, porque uma mudança que quebra um controlo é muito mais dispendiosa de corrigir depois de uma constatação de auditoria.
Porque rastrear requisitos até SOPs e runbooks?
A maioria das matrizes de rastreabilidade termina nos testes. Isso prova que o sistema funciona no dia em que é testado, mas não que as pessoas o conseguem executar depois. Ao adicionar SOPs e runbooks, fecha-se essa lacuna:
Os utilizadores de negócio recebem um SOP para cada requisito que altera a forma como trabalham.
As equipas de suporte recebem um runbook para cada interface, job e requisito técnico que vão monitorizar.
As exceções no requisito aparecem na tabela de exceções do SOP e nos passos de resolução de problemas do runbook.
As alterações a um requisito mostram exatamente quais SOPs e runbooks precisam de atualização.
Para um formato de procedimento operacional pronto a usar, utilize o modelo de runbook.
Como criar uma matriz de rastreabilidade de requisitos passo a passo
Defina convenções de ID para requisitos, secções do FRD, itens de construção, SOPs, runbooks e testes.
Liste todos os requisitos com a respetiva origem, ligando a evidência as-is quando a tiver; veja recolha de requisitos de ERP a partir de registos de processos.
Ligue cada requisito à sua secção do FRD e ao item de design ou de construção.
Ligue os casos de teste à medida que são escritos, incluindo scripts de UAT; use o modelo de script de teste de UAT.
Ligue SOPs, runbooks e formação para cada requisito antes do go-live.
Atualize o estado do teste após cada ciclo de teste.
Revise o resumo de cobertura em cada stage gate e feche as lacunas.
Registe todas as alterações a um requisito com o respetivo impacto e aprovação.
Como manter a matriz atualizada
Defina uma pessoa como responsável pela RTM, normalmente o analista de negócio líder ou o PMO.
Atualize-a como parte de cada pedido de alteração, e não depois.
Revise a cobertura em cada stage gate: validação do design, saída de testes e prontidão para o go-live.
Entregue à equipa de operações no go-live, com responsáveis por cada SOP e runbook.
Mantenha os SOPs e runbooks ligados com controlo de versões, para que a matriz aponte sempre para o procedimento atual; veja controlo de versões de SOP.
Formatos para uma matriz de rastreabilidade de requisitos
Folha de cálculo é o formato mais comum, com filtros para estado, responsável e lacunas de cobertura.
Ferramenta de gestão de requisitos ou de testes é adequada para programas grandes que precisam de ligações automatizadas e dashboards.
Documento é adequado para um resumo assinado da cobertura em cada stage gate.
Independentemente do formato que usar, mantenha uma matriz-mestra e crie ligações a partir dos documentos do projeto.
Boas práticas para rastreabilidade de requisitos
Use IDs estáveis e únicos que nunca sejam reutilizados.
Escreva um requisito por linha, e não requisitos combinados.
Ligue à evidência, como registos do processo as-is, e não apenas às notas do workshop.
Rastreie até às operações, com SOPs e runbooks, e não apenas até aos testes.
Revise o resumo de cobertura regularmente, e não apenas no fim.
Mantenha a matriz suficientemente leve para que as pessoas a consigam manter.
Erros comuns a evitar
Construir a matriz no final do projeto para satisfazer uma auditoria.
Parar nos casos de teste, sem ligação a SOPs, runbooks ou formação.
Combinar vários requisitos numa única linha, para que a cobertura não fique clara.
Sem responsável, para que a matriz não fique desatualizada.
Não registar alterações, para que o impacto não possa ser rastreado.
Checklist da matriz de rastreabilidade de requisitos
As convenções de ID são acordadas para cada tipo de item.
Todos os requisitos têm uma origem, prioridade e responsável.
Todos os requisitos ligam-se a uma secção do FRD e a um item de construção.
Todos os requisitos ligam-se a pelo menos um caso de teste, com estado atual.
Todos os requisitos que alteram a forma como as pessoas trabalham ligam-se a um SOP ou runbook e à formação.
O resumo de cobertura não mostra lacunas sem explicação.
As alterações são registadas com o respetivo impacto e aprovação.
Como o Trupeer o ajuda a completar a cadeia de rastreabilidade
Desafio de rastreabilidade | Como o Trupeer ajuda |
|---|---|
Faltam evidências para os requisitos | Registe os SMEs a executar o processo real e ligue cada requisito ao registo e ao documento as-is que o Trupeer cria a partir dele |
Ainda não existem SOPs e runbooks | Registe o processo configurado ou a tarefa de suporte e o criador de SOP do Trupeer transforma-o num SOP ou runbook passo a passo |
A evidência de teste está dispersa | Registe execuções de UAT e ligue os registos aos casos de teste na matriz |
Falta formação para requisitos alterados | Os mesmos registos tornam-se vídeos de formação e guias para cada função |
Os documentos ficam desatualizados após alterações | Atualize SOPs e vídeos editando o script e substitua um único passo em vez de voltar a gravar |
Para equipas de suporte, o gerador de runbooks com IA do Trupeer transforma registos de tarefas técnicas em runbooks que pode ligar a partir da matriz.
A Genpact usou esta abordagem centrada em registos para um rollout Workday a nível de empresa, transformando sessões de processo gravadas em mais de 500 materiais de formação em 20 workstreams, em cinco línguas, para 140.000 colaboradores em 40 países, em 3 meses em vez de 12. Leia a história do cliente Genpact.
Descarregue o modelo gratuito de matriz de rastreabilidade de requisitos
Abra o modelo no Trupeer, adicione os seus requisitos, ligue o seu FRD, itens de construção, SOPs, runbooks e testes e partilhe-o com a sua equipa de projeto. Obtenha o modelo gratuito de matriz de rastreabilidade de requisitos.
Modelos relacionados
Perguntas Frequentes
O que é um modelo de matriz de rastreabilidade de requisitos?
É uma tabela estruturada que liga cada requisito aos documentos e aos itens de trabalho que o entregam e verificam, como a secção do FRD, o item de design ou de construção, o SOP ou runbook, os casos de teste e a formação, com estado e responsável.
O que deve incluir uma matriz de rastreabilidade de requisitos?
ID do requisito, descrição, origem, prioridade, secção do FRD, item de design ou de construção, SOP ou runbook, casos de teste, estado do teste, conteúdo de formação, responsável, estado e histórico de alterações, além de um resumo de cobertura.
Qual é a diferença entre rastreabilidade para a frente e para trás?
A rastreabilidade para a frente segue um requisito através do design, construção, teste e documentação. A rastreabilidade para trás começa num caso de teste, SOP ou item de construção e faz o rastreio até ao requisito que serve.
Porque ligar requisitos a SOPs e runbooks?
Porque os testes provam que o sistema funciona no dia, enquanto os SOPs e runbooks provam que as pessoas o conseguem operar depois. Ao ligá-los, mostra quais os procedimentos que precisam de atualização quando um requisito muda.
Quem é responsável pela matriz de rastreabilidade de requisitos?
Normalmente, o analista de negócio líder ou o PMO, com os responsáveis pelos requisitos a manterem as respetivas linhas atualizadas e a equipa de operações a assumir a responsabilidade no go-live.
Quando deve criar uma matriz de rastreabilidade de requisitos?
No início do projeto, à medida que os requisitos são recolhidos, e atualize-a em cada stage: design, construção, teste e go-live.
Existe um modelo de matriz de rastreabilidade de requisitos no Excel?
Sim. A matriz funciona bem no Excel, com filtros para estado, responsável e lacunas de cobertura. Abra o modelo no Trupeer, personalize-o e exporte-o, ou copie a estrutura para o Excel.
Existe um modelo de matriz de rastreabilidade de requisitos no Word ou PDF?
Sim. Use Word ou PDF para resumos de cobertura assinados em stage gates e mantenha a matriz de trabalho numa folha de cálculo ou ferramenta.
O modelo de matriz de rastreabilidade de requisitos é gratuito?
Sim. Registe-se gratuitamente para abrir o modelo no Trupeer, personalize-o e exporte-o.
Como é usado um RTM em implementações de ERP?
Liga requisitos fit-gap a especificações funcionais, itens de configuração e de desenvolvimento, scripts de UAT, SOPs, runbooks e formação, para que o programa possa provar a cobertura e gerir a mudança.
Como manter uma matriz de rastreabilidade atualizada?
Defina uma pessoa como responsável, atualize-a como parte de cada pedido de alteração, reveja a cobertura em cada stage gate e mantenha os SOPs e runbooks ligados com controlo de versões.
Uma matriz de rastreabilidade pode apoiar auditorias?
Sim. Para requisitos de controlo, mostra o design, a evidência de teste e o procedimento de operação, que é o que os auditores normalmente pedem para ver.
