Planejamento, Cronograma e Custos
Matriz de rastreabilidade de requisitos: modelo e exemplo
A matriz de rastreabilidade de requisitos é a tabela que liga cada requisito à razão de ele existir e ao lugar onde ele foi atendido. De um lado, o objetivo de negócio e quem pediu; do outro, a entrega da Estrutura Analítica do Projeto (EAP), o componente construído e o teste que comprovou o resultado. Parece burocracia até o dia em que alguém pede uma mudança e o projeto precisa responder, em uma hora, o que mais será afetado.
Sem a matriz, essa resposta depende da memória de quem estava nas reuniões de levantamento. Com ela, basta filtrar uma linha. O mesmo vale para a pergunta do patrocinador na homologação ("tudo o que pedimos foi testado?") e para a pergunta inversa, mais rara e mais cara: por que a equipe construiu uma função que ninguém pediu?
Formação relacionada
Microsoft Project Professional
Cronogramas confiáveis, linha de base, controle de desvio e relatórios que sustentam decisão de diretoria.
O que é a matriz de rastreabilidade de requisitos
No Guia PMBOK (6ª edição), a matriz de rastreabilidade dos requisitos é uma das saídas do processo de coletar os requisitos, ao lado da documentação dos requisitos. O guia a descreve como uma grade que liga os requisitos do produto, desde a origem, às entregas que os satisfazem, e indica rastrear, entre outros pontos:
- as necessidades, oportunidades e objetivos do negócio;
- os objetivos do projeto;
- o escopo do projeto e as entregas da EAP;
- o desenho e o desenvolvimento do produto;
- a estratégia e os cenários de teste;
- os requisitos de alto nível até os detalhados.
Na engenharia de software, a mesma ideia aparece com a sigla RTM (requirements traceability matrix) e costuma ter foco na ligação entre requisito, código e caso de teste. Ela acompanha o projeto inteiro, do levantamento ao aceite, e é atualizada a cada mudança aprovada. O lugar dela no conjunto dos processos de escopo está no artigo sobre gerenciamento do escopo do projeto.
Para que a matriz serve no dia a dia
- Analisar o impacto de uma mudança. A linha do requisito mostra as entregas, os componentes e os testes que serão refeitos. É o insumo que o fluxo de gestão de mudanças em projetos precisa para estimar prazo e custo.
- Achar requisitos órfãos. Requisito sem entrega ou sem teste é promessa que ninguém está cumprindo.
- Achar trabalho sem pedido. Entrega ou componente que não aparece em nenhuma linha é escopo não aprovado, o chamado gold plating.
- Organizar o aceite. Na homologação, a matriz vira o roteiro: cada requisito, o teste que o comprova e o resultado.
- Sustentar auditorias. Em projetos regulados ou com contrato, ela demonstra que o que foi contratado foi entregue e verificado.
Rastreabilidade bidirecional: para frente e para trás
| Sentido | Pergunta | Exemplo |
|---|---|---|
| Para frente | Este requisito virou entrega e foi testado? | RF-02 está na entrega 2.1 e no caso de teste CT-05 |
| Para trás | Por que esta entrega ou este teste existe? | O componente de notificações atende ao RF-04, que vem do objetivo OBJ-01 |
A matriz que só funciona para frente garante cobertura, mas não pega o trabalho desnecessário. A que funciona nos dois sentidos fecha as duas portas. Na planilha, a rastreabilidade para trás exige que os identificadores das entregas e dos testes também possam ser buscados, por exemplo com um filtro na coluna de testes.
Modelo de matriz de rastreabilidade para copiar
Comece pelas colunas essenciais e acrescente as opcionais só se alguém for usá-las.
| Coluna | Conteúdo | Essencial? |
|---|---|---|
| ID | Identificador único e estável (RN-01, RF-01, RNF-01) | Sim |
| Requisito | Descrição curta e verificável | Sim |
| Tipo | Negócio, parte interessada, funcional, não funcional, transição | Sim |
| Origem | Quem pediu e em que reunião ou documento | Sim |
| Objetivo ligado | Objetivo de negócio ou do projeto que justifica o requisito | Sim |
| Prioridade | Obrigatório, importante, desejável | Sim |
| Requisito pai | ID do requisito de nível acima, quando houver | Não |
| Entrega da EAP | Código do pacote de trabalho | Sim |
| Componente ou desenho | Tela, módulo, documento de arquitetura | Não |
| Caso de teste | ID dos testes que verificam o requisito | Sim |
| Critério de aceite | Como saber que está atendido | Sim |
| Status | Proposto, aprovado, em construção, testado, aceito, cancelado | Sim |
| Versão e data | Última alteração aprovada | Não |
O critério de aceite pode morar na documentação dos requisitos em vez da matriz; o importante é que exista e que a matriz aponte para ele. A descrição detalhada de cada pacote, por sua vez, fica no dicionário da EAP, e a matriz só cita o código.
Exemplo preenchido: sistema de protocolo eletrônico
O exemplo é ilustrativo. Uma prefeitura vai implantar um sistema de protocolo eletrônico para que os cidadãos abram e acompanhem requerimentos pela internet. Os objetivos do projeto são reduzir o tempo de tramitação dos processos (OBJ-01) e permitir a abertura de requerimentos sem ida ao balcão (OBJ-02).
| ID | Requisito | Tipo | Origem | Objetivo | Prioridade | Entrega | Teste | Status |
|---|---|---|---|---|---|---|---|---|
| RN-01 | Cidadão abre requerimento pela internet | Negócio | Secretaria de Administração | OBJ-02 | Obrigatório | 2.0 | CT-01 a CT-03 | Aprovado |
| RF-01 | Formulário de abertura com anexo de documentos em PDF | Funcional | Oficina com o protocolo | OBJ-02 | Obrigatório | 2.1 | CT-01, CT-02 | Em construção |
| RF-02 | Consulta do andamento pelo número do protocolo | Funcional | Oficina com o protocolo | OBJ-02 | Obrigatório | 2.1 | CT-05 | Em construção |
| RF-03 | Encaminhamento entre setores com prazo de análise | Funcional | Chefes de setor | OBJ-01 | Obrigatório | 2.2 | CT-06, CT-07 | Aprovado |
| RF-04 | Aviso por e-mail a cada mudança de etapa | Funcional | Ouvidoria | OBJ-01 | Importante | 2.3 | CT-08 | Aprovado |
| RNF-01 | Atender aos requisitos de acessibilidade definidos pelo órgão | Não funcional | Comitê de governo digital | OBJ-02 | Obrigatório | 2.1 | CT-10 | Aprovado |
| RT-01 | Servidores do protocolo treinados antes da virada | Transição | Secretaria de Administração | OBJ-01 | Obrigatório | 4.1 | Avaliação do treinamento | Proposto |
Duas leituras que a tabela permite em segundos:
- Mudança. A ouvidoria pede que o aviso também saia por mensagem no celular. Filtrando RF-04, você vê a entrega 2.3 e o teste CT-08, e sabe que a mudança não toca nas entregas 2.1 e 2.2.
- Cobertura. RF-02 tem um único teste. Se a consulta precisa funcionar também para processos antigos migrados, falta um caso de teste, e a matriz mostra isso antes da homologação.
Em projetos de software, a distinção entre requisitos de negócio, funcionais e não funcionais pesa mais; o artigo sobre escopo de projeto de software mostra como documentá-los antes de levá-los à matriz.
Como montar a matriz no Excel passo a passo
- Crie a tabela (Inserir, Tabela) com as colunas do modelo. A tabela formatada facilita filtros e fórmulas que crescem sozinhas.
- Defina a regra dos identificadores. Prefixo por tipo e número sequencial que nunca é reaproveitado. Requisito cancelado continua na tabela, com status "cancelado".
- Crie listas suspensas (Dados, Validação de Dados) para tipo, prioridade e status. Texto livre nessas colunas impede filtrar e contar.
- Preencha a origem e o objetivo no levantamento, não depois. É a parte que ninguém consegue reconstruir meses depois.
- Preencha entrega e teste quando a EAP e o plano de testes existirem. Até lá, deixe em branco, e o vazio funciona como alerta.
- Acrescente verificações. Uma contagem condicional como =CONT.SES(Tabela1[Teste];"";Tabela1[Status];"<>cancelado") mostra quantos requisitos ativos estão sem teste. Faça o mesmo para entrega.
- Proteja o histórico. Salve uma versão a cada mudança aprovada ou use o histórico de versões do armazenamento em nuvem.
Matriz de rastreabilidade em projetos ágeis
Em projetos ágeis, a matriz raramente é uma planilha separada. A rastreabilidade fica nas próprias ferramentas: o épico se liga ao objetivo, a história de usuário ao épico, os critérios de aceite à história e os testes automatizados ou manuais à história. A pergunta continua a mesma, só muda o lugar da resposta. O cuidado é garantir que os vínculos sejam preenchidos de fato e que exista um relatório que mostre histórias sem teste e testes sem história. Em projetos contratados ou regulados, ainda é comum exportar essas ligações para uma matriz na homologação.
Erros comuns na matriz de rastreabilidade
- Requisitos não verificáveis. "Sistema rápido" não tem teste possível. Reescreva com um número ou um critério observável antes de levar para a matriz.
- Colunas demais. Matriz com 25 colunas não é mantida. Fique com as essenciais.
- Montar no fim do projeto. A matriz feita na homologação só documenta; a feita no levantamento orienta.
- Atualizar só o status. Mudança aprovada que não atualiza entrega e teste deixa a matriz mentindo.
- Dono indefinido. Alguém precisa ser responsável por mantê-la, em geral o analista de requisitos ou o gerente do projeto.
O guia de planejamento de projetos mostra onde os requisitos entram no plano, antes da EAP e do cronograma.
Para começar, pegue a lista de requisitos do seu projeto, aplique o modelo com as colunas essenciais e preencha origem e objetivo de cada linha; os vazios que aparecerem são as primeiras perguntas a levar às partes interessadas. Em seguida, use o plano do projeto da Projeto Diário, que reúne num documento só o que você preenche nas ferramentas gratuitas do site, como termo de abertura, EAP, cronograma e riscos, e gera o plano em Word para você anexar a matriz.
