Gestão de Requisitos, Evidências e Critérios de Aceite

A gestão de requisitos, evidências e critérios de aceite estabelece uma linha de rastreabilidade entre aquilo que um empreendimento precisa atender e a forma objetiva de demonstrar que o atendimento ocorreu. Em projetos, obras, aquisições e comissionamentos, requisitos podem estar distribuídos entre contratos, termos de referência, memoriais, desenhos, normas, atas, RFIs, especificações de fabricantes e decisões formais. Sem consolidação, parte dessas obrigações pode desaparecer entre documentos, revisões e interfaces.

O problema não é apenas localizar requisitos. É necessário transformar cada obrigação relevante em um elemento controlável: identificar sua origem, interpretar o que deve ser atendido, atribuir responsabilidade, relacionar entregáveis, definir como será verificado e estabelecer qual evidência sustentará a decisão de aceite. Quando esse encadeamento não existe, o aceite tende a ocorrer por percepção geral de conclusão, e não pela comprovação de conformidade.

Requisito, método de verificação, evidência e aceite são conceitos diferentes. O requisito define a condição esperada; o método de verificação define como essa condição será avaliada; a evidência registra o resultado; e o aceite formaliza a decisão de que o critério estabelecido foi satisfeito. Misturar essas funções cria matrizes extensas, mas pouco úteis para controlar engenharia.

A solução deve, portanto, operar como uma arquitetura de assurance técnico: conectar necessidade, requisito, projeto, aquisição, implantação, teste, documentação e decisão final em uma cadeia recuperável e auditável.

Condição observada	Risco técnico	Resposta de engenharia
Requisitos dispersos em contratos e documentos	Obrigações esquecidas, contraditórias ou verificadas tarde demais	Base consolidada com origem, identificação e responsável
Critérios de aceite definidos apenas no fim	Discussões subjetivas sobre conformidade e retrabalho	Critérios e métodos de verificação definidos junto ao requisito
Testes sem vínculo com requisito	Grande volume de evidências sem capacidade de provar conformidade	Matriz requisito → verificação → evidência → decisão
Mudanças de projeto sem análise de impacto	Requisitos deixam de ser atendidos após revisões	Gestão de baseline, mudança e rastreabilidade bidirecional
Documentação final desconectada do aceite	Ativo recebido sem dossiê tecnicamente defensável	Critérios documentais, punch list e dossiê de aceite integrados

Arquitetura da solução

A arquitetura parte de uma base estruturada de requisitos. Cada registro precisa possuir identificador, origem, disciplina, objeto aplicável, responsável, criticidade, status, método de verificação e relação com entregáveis. Em projetos maiores, requisitos também podem ser organizados por sistema, subsistema, pacote, ativo, contrato ou fase do ciclo de vida.

A rastreabilidade precisa ser bidirecional. Deve ser possível partir de um requisito e encontrar o documento, equipamento, teste ou evidência que o atende; e, no sentido inverso, partir de um teste ou entrega e compreender quais requisitos estão sendo comprovados. Essa capacidade reduz evidências órfãs e ajuda a identificar requisitos que ainda não possuem mecanismo de verificação definido.

O modelo também precisa distinguir baseline e evolução. Requisitos podem mudar por revisão de escopo, esclarecimento, decisão técnica ou condição de campo. Alterações relevantes devem preservar histórico, justificativa, aprovação e análise de impacto, evitando que versões diferentes de uma obrigação coexistam sem controle.

Levantamento, decomposição e classificação dos requisitos

Fontes e autoridade do requisito

Contratos, termos de referência, especificações, normas, desenhos, requisitos de operação e decisões formais podem possuir níveis diferentes de autoridade. A consolidação precisa registrar a fonte e permitir identificar precedência quando existem conflitos. Uma exigência de contrato não pode ser tratada da mesma forma que uma recomendação interna sem vínculo obrigatório.

RFIs, atas e esclarecimentos também podem produzir requisitos derivados. Quando uma decisão altera interpretação, desempenho ou escopo, ela precisa ser incorporada à base controlada para que sua consequência apareça nos documentos e verificações posteriores.

Requisitos funcionais, de desempenho e de interface

Requisitos funcionais descrevem o que um sistema deve fazer; requisitos de desempenho estabelecem níveis mensuráveis; requisitos de interface tratam da relação com outros sistemas, utilidades, disciplinas ou usuários. Essa distinção ajuda a escolher métodos de verificação adequados. Uma função pode ser comprovada por teste; uma dimensão por inspeção ou medição; uma interface pode exigir teste integrado.

Também podem existir requisitos de segurança, disponibilidade, manutenção, documentação, treinamento, sobressalentes, capacidade futura e operação. Se esses itens forem tratados como acessórios, tendem a aparecer apenas perto do encerramento, quando mudanças são mais caras.

Decomposição e requisito verificável

Um bom requisito precisa permitir verificação. Formulações genéricas como “o sistema deverá possuir alta confiabilidade” são insuficientes sem critério que defina o que significa confiabilidade aceitável. A decomposição transforma expectativas amplas em condições avaliáveis, preservando a intenção original.

Decompor não significa fragmentar indiscriminadamente. O nível de detalhe deve ser suficiente para atribuir responsabilidade e verificação sem criar milhares de registros sem valor operacional. O critério é a capacidade de demonstrar atendimento e controlar impacto de mudança.

Matriz de rastreabilidade e responsabilidades

A matriz de rastreabilidade organiza as relações entre requisitos, entregáveis, responsáveis e verificações. Ela não deve funcionar como uma planilha estática de conferência final. Precisa acompanhar a evolução do projeto e apontar lacunas: requisitos sem responsável, sem documento associado, sem teste definido, sem evidência ou ainda com desvio aberto.

O vínculo com a Estrutura Analítica do Projeto, documentos, contratos e ativos melhora a leitura. Um requisito pode pertencer a uma disciplina, mas depender de outra para ser atendido. A matriz deve tornar interfaces visíveis, especialmente quando diferentes fornecedores entregam partes de uma mesma função.

A responsabilidade também deve ser separada por papel. Quem desenvolve a solução pode ser diferente de quem verifica, testemunha, aprova ou aceita. Dependendo da criticidade, a independência entre execução e verificação pode ser condição de governança.

Métodos de verificação, validação e evidências

Inspeção, análise, demonstração e teste

O método precisa corresponder ao requisito. Condições físicas podem ser verificadas por inspeção ou medição; desempenho pode exigir ensaio; capacidade pode exigir cálculo ou análise; comportamento integrado pode demandar demonstração funcional ou teste de cenário. Utilizar um método inadequado gera evidência que parece completa, mas não comprova a condição exigida.

O plano de verificação deve indicar momento, pré-condições, instrumentos, participantes, procedimento, resultado esperado e registro a ser produzido. Em FAT e SAT, por exemplo, a clareza prévia evita que critérios sejam negociados durante a execução do teste.

Verificação não é validação

Verificação pergunta se a solução atende ao requisito especificado. Validação pergunta se a solução resultante é adequada ao uso e à necessidade que originou o requisito. Um sistema pode estar tecnicamente conforme com sua especificação e ainda assim não satisfazer a operação se os requisitos iniciais foram incompletos ou inadequados.

Essa distinção é especialmente relevante em interfaces operacionais, automação, software, sistemas de missão crítica e processos em que o comportamento integrado só pode ser avaliado após montagem ou configuração final.

Evidência suficiente e evidência rastreável

Evidência precisa ser proporcional ao requisito. Fotografias são adequadas para algumas inspeções visuais, mas não comprovam desempenho elétrico, funcional ou de comunicação. Certificados podem demonstrar fabricação ou calibração, mas não substituem testes de integração quando o critério se refere ao sistema completo.

Cada evidência deve permitir identificar o objeto testado, revisão ou configuração, data, responsável, método e resultado. Sem esse contexto, o arquivo existe, mas sua força probatória é limitada.

Critérios de aceite e tratamento de desvios

Critérios de aceite devem ser definidos antes da etapa em que serão aplicados. Isso reduz interpretações divergentes entre contratante, projetista, fornecedor, fiscalização e operação. O critério pode ser quantitativo, qualitativo ou documental, mas precisa indicar com clareza a condição mínima para aprovação.

Nem todo desvio exige rejeição automática. Em alguns casos pode existir concessão, aceitação condicionada ou risco residual formalmente assumido. Essas situações precisam possuir autoridade definida, justificativa técnica, avaliação de impacto e registro de validade. Uma exceção não pode desaparecer apenas porque o item foi marcado como concluído.

Pendências de baixa criticidade podem ser transferidas para punch list quando isso for previsto e não comprometer segurança, funcionalidade, conformidade ou operação. A transição precisa preservar responsável, prazo e evidência necessária para fechamento definitivo.

Integração com projeto, procurement, implantação e comissionamento

Requisitos precisam atravessar o ciclo de vida. Na fase de projeto, orientam critérios e entregáveis. No procurement, precisam aparecer em especificações, folhas de dados, critérios de equalização e condições de fornecimento. Na implantação, orientam inspeções e controles. No comissionamento, determinam testes e condições de aceite.

Quando requisitos são tratados apenas no projeto e não chegam aos documentos de contratação, fornecedores podem entregar soluções formalmente compatíveis com sua proposta, mas incompatíveis com a necessidade original. O mesmo ocorre quando testes de comissionamento são definidos sem recuperar os requisitos que deram origem à função.

A rastreabilidade também melhora gestão de mudanças. Uma alteração de equipamento, arquitetura ou interface deve permitir identificar quais requisitos, testes, documentos e aprovações precisam ser revistos antes da liberação.

Ciclo de vida da solução

A implantação começa pelo levantamento das fontes e pela definição da estrutura de classificação. Em seguida são consolidados requisitos, eliminadas duplicidades, identificados conflitos e atribuídos responsáveis. A base inicial precisa ser validada com as partes que detêm autoridade sobre escopo, operação e engenharia.

Na etapa seguinte, cada requisito recebe método de verificação, evidência esperada, fase de aplicação e critério de aceite. As relações com documentos, pacotes, contratos e testes são estabelecidas progressivamente conforme o empreendimento amadurece.

Durante execução e comissionamento, a base passa a registrar resultados, desvios, exceções e evidências. No encerramento, o conjunto fornece uma visão objetiva dos requisitos atendidos, pendentes ou aceitos sob condição e sustenta a montagem do dossiê final.

Verificação do sistema de requisitos e dossiê de aceite

O próprio sistema de gestão de requisitos deve ser auditável. É necessário verificar requisitos sem origem, registros sem responsável, itens sem método de verificação, evidências ausentes, desvios vencidos e relações quebradas após mudanças de revisão. A qualidade da base é condição para que a rastreabilidade seja confiável.

O dossiê de aceite pode consolidar matriz final de conformidade, protocolos de inspeção e teste, certificados, relatórios, listas de pendências, concessões, aprovações e documentos finais. Ele precisa permitir que uma auditoria futura compreenda por que o ativo ou sistema foi aceito.

Essa lógica também reduz a dependência de conhecimento tácito. Quando responsáveis deixam o projeto, as decisões e evidências permanecem associadas aos requisitos que justificaram sua existência.

Cobertura de interfaces e maturidade dos requisitos

Uma das principais fontes de falha está nas interfaces. Requisitos podem estar individualmente atendidos por cada disciplina e, ainda assim, a função integrada falhar porque responsabilidades de fronteira não foram explicitadas. Alimentação elétrica, comunicação, sinais de controle, espaço físico, condições ambientais, protocolos, pontos de entrega e responsabilidades de configuração precisam ser tratados como requisitos de interface.

A matriz deve permitir identificar requisitos compartilhados entre sistemas e fornecedores. Quando uma interface depende de duas partes, o aceite não pode se limitar à comprovação isolada de cada entrega. É necessário verificar a condição integrada e definir quem coordena o teste, quais pré-condições devem existir e qual evidência demonstra compatibilidade.

Maturidade, baseline e congelamento progressivo

Requisitos não possuem todos o mesmo nível de maturidade desde o início. Alguns nascem como necessidades de alto nível e são refinados conforme estudos, projeto e decisões de contratação avançam. O processo precisa distinguir requisito proposto, analisado, aprovado, incorporado à baseline, alterado e retirado.

O congelamento progressivo reduz mudanças tardias, mas não deve impedir correções necessárias. A baseline serve para tornar alterações visíveis: quando um requisito aprovado muda, a equipe consegue avaliar impacto em projeto, custo, prazo, aquisição, testes e documentação antes de aceitar a nova condição.

Essa disciplina é especialmente importante quando o empreendimento evolui por pacotes. Um requisito definido para uma etapa futura pode condicionar decisões atuais de infraestrutura, reserva de capacidade ou compatibilidade. Preservar essas dependências reduz soluções localmente adequadas que inviabilizam expansões previstas.

Considerações de Engenharia

Mais requisitos não significam melhor especificação

Uma base extensa, duplicada e ambígua pode ser pior que uma estrutura menor e verificável. O foco deve ser clareza, origem, aplicabilidade e capacidade de comprovação.

Evidência não substitui critério

Acumular relatórios, fotos e certificados não demonstra conformidade se não houver relação explícita entre cada evidência e a condição que ela pretende comprovar.

Aceite condicionado precisa permanecer rastreável

Concessões e pendências aceitas temporariamente devem possuir autoridade, prazo, responsável e condição de fechamento. Caso contrário, exceções temporárias tendem a se tornar configuração permanente sem decisão formal.

Mudança sem análise de impacto rompe a cadeia de conformidade

Alterar um elemento do projeto pode invalidar testes, documentos e aprovações anteriores. A rastreabilidade deve permitir localizar essas dependências antes da liberação da mudança.

Aplicações e serviços que materializam a solução

A solução é aplicável a projetos multidisciplinares, Owner’s Engineering, aquisição de sistemas e equipamentos, fiscalização, implantação, FAT, SAT, comissionamento, recebimento técnico e auditorias de conformidade. Seu valor aumenta em ambientes com múltiplos fornecedores e grande volume de interfaces.

A estruturação pode começar pelo Programa de Necessidades e Requisitos de Engenharia, que consolida necessidades e critérios ainda nas fases iniciais. Durante implantação, o Apoio Técnico à Fiscalização utiliza requisitos e evidências como base de controle.

Na etapa de entrega, a solução se conecta ao Comissionamento de Equipamentos, ao Recebimento Técnico de Obras e Serviços de Engenharia e à Auditoria Técnica de Data Book e Documentação Final.

Modelo de contratação

O trabalho pode ser iniciado ainda na definição do empreendimento, com estruturação dos requisitos e critérios de aceite, ou aplicado a projetos em andamento que precisam recuperar rastreabilidade. Nesse segundo caso, é realizada uma engenharia reversa documental para consolidar obrigações, decisões e evidências existentes.

O escopo pode incluir base de requisitos, matriz de rastreabilidade, plano de verificação e validação, matriz de evidências, critérios de aceite, governança de mudanças e suporte ao encerramento. A profundidade depende da criticidade, quantidade de interfaces e necessidade de assurance independente.

O resultado esperado é uma estrutura capaz de responder, para cada obrigação relevante: de onde veio, quem responde por ela, como foi implementada, como foi verificada e qual evidência sustenta seu aceite.