Como rastrear os requisitos do URS por meio de DQ, FAT, SAT, IQ e OQ

Uma cláusula URS redigida durante a definição do projeto só é útil se ainda puder ser encontrada, de forma inequívoca, no registro de testes que encerra a qualificação meses ou anos depois. Quando um leitor pergunta como rastrear os requisitos por meio de DQ, FAT, SAT, IQ e OQ, a verdadeira questão é como manter um requisito identificável em vários documentos, com vários colaboradores e em vários pontos em que o próprio requisito possa sofrer alterações. Essa questão é importante porque um pacote de qualificação que não consiga demonstrar essa ligação com o requisito de origem é difícil de defender durante uma inspeção e difícil de ser considerado confiável internamente quando algo dá errado.

A Matriz de Rastreabilidade como ponto de controle para cada cláusula do URS

A matriz de rastreabilidade existe para responder repetidamente a uma pergunta: para esse requisito, qual decisão de projeto o abordou, qual teste o verificou, o que o teste constatou e o que acontece se ele não for totalmente atendido. A matriz não é um documento resumido elaborado ao final de um projeto; trata-se de uma estrutura de controle que deve ser construída enquanto o URS ainda está sendo redigido e, posteriormente, mantida como o único ponto de referência ao qual todos os documentos subsequentes se remetem.

Isso só funciona se cada requisito possuir um identificador estável desde o momento em que é aprovado. Quando um requisito é reescrito durante a revisão do projeto, dividido em duas cláusulas ou mesclado com outro, o esquema de identificação precisa acomodar essa alteração sem romper o vínculo com qualquer evidência já gerada com base na versão anterior. Uma matriz que permita que os requisitos sejam renumerados livremente, ou que permita que um documento de projeto faça referência ao “URS” de forma genérica, em vez de um número de cláusula específico, perde seu valor como ponto de controle, pois nenhum revisor posterior poderá confirmar qual versão de qual requisito um determinado resultado de teste realmente corrobora.

A prática recomendada consiste em vincular seis elementos a cada cláusula aplicável: o próprio requisito, a resposta do fornecedor a ele, o documento de projeto que mostra como a resposta foi implementada, o protocolo de teste e o critério de aceitação designado para verificá-la, o resultado registrado em relação a esse critério e o status de desvio ou aprovação, caso o resultado não tenha sido uma aprovação sem ressalvas. A ausência de qualquer um desses elementos rompe a cadeia. Uma resposta do fornecedor sem um documento de projeto que a respalde é uma promessa não verificada. Um resultado de teste sem vinculação a um critério de aceitação é apenas um número sem significado. Um desvio sem vinculação ao requisito de origem torna-se impossível de rastrear no momento em que alguém pergunta a qual cláusula ele realmente afeta.

Quando um projeto sofre alterações no escopo no decorrer do processo, a matriz precisa refletir essa mudança de forma visível, e não silenciosamente. Se um requisito for retirado porque não se aplica mais, a matriz deve indicar que ele foi retirado, quando isso ocorreu e por qual aprovação, e não simplesmente omitir a linha. Se um requisito for adicionado tardiamente, ele precisa da mesma ligação em seis partes que tudo o que foi definido anteriormente, mesmo que tenha perdido a etapa de qualificação do projeto pela qual o restante do conjunto de requisitos passou em conjunto. É nesse ponto que muitas matrizes apresentam falhas: os requisitos adicionados tardiamente são verificados informalmente porque a disciplina formal de ligação já era considerada “concluída”.”

A qualificação do projeto vincula os requisitos às evidências do projeto aprovado

A qualificação do projeto existe para responder a uma questão mais específica do que a matriz como um todo: o projeto proposto, no papel, realmente atende a cada cláusula aplicável do URS, antes que esse projeto se torne um sistema fabricado cujas alterações sejam onerosas? Essa é a etapa em que a disciplina de rastreabilidade se mostra vantajosa, pois uma lacuna identificada aqui custa apenas uma revisão do documento, enquanto a mesma lacuna detectada no FAT (Teste de Aceitação de Fábrica) ou posteriormente implica retrabalho no equipamento físico.

A DQ não verifica o desempenho; ela verifica a cobertura. Para cada cláusula do URS que se aplique à fase de projeto, o registro da DQ deve indicar qual desenho, especificação ou documento de projeto demonstra que o requisito foi traduzido em uma característica do projeto e se um revisor com autoridade técnica relevante confirmou essa tradução. Quando um requisito é amplo ou subjetivo, é na fase de DQ que ele precisa ser tornado testável — reformulado, se necessário, em termos suficientemente específicos para que um protocolo posterior possa realmente verificá-lo. Um requisito que não possa ser traduzido em uma condição testável na fase de DQ não se tornará mais testável posteriormente; ele será simplesmente verificado de forma inconsistente, se é que será verificado.

A condição que altera essa avaliação é o grau de consolidação do projeto no momento em que a DQ é realizada. Quando a DQ ocorre em relação a um projeto maduro e amplamente definido, a revisão pode comparar os requisitos com o desenho final, com a certeza de que nada mudará antes da fabricação. Quando a DQ ocorre mais cedo, em relação a um projeto conceitual ou preliminar, a revisão precisa distinguir entre os requisitos que o conceito satisfaz claramente e aqueles que permanecem em aberto, aguardando a engenharia detalhada — e a matriz precisa de um valor de status para essa condição “em aberto, aguardando projeto adicional” que seja distinto de “aprovado” e de “não aplicável”. Agrupar esses três em uma única caixa de seleção é uma forma comum pela qual a rastreabilidade falha discretamente: um requisito marcado como concluído na DQ porque o conceito parecia razoável, sem que houvesse uma revisão posterior quando o projeto detalhado divergiu do conceito.

Nem todas as cláusulas da URS são aplicáveis na DQ. Os requisitos de condições operacionais, por exemplo, podem não ser comprováveis até que o equipamento exista e possa ser colocado em funcionamento. A matriz deve indicar esses itens como “ainda não verificáveis” nesta fase, em vez de deixá-los em branco, para que um revisor que analise a matriz posteriormente possa distinguir entre “ainda não vencido” e “omissão”.”

Os testes de aceitação em fábrica verificam as funções antes do envio

O FAT responde a uma questão diferente daquela abordada pelo DQ: não se trata de saber se o projeto atende ao requisito, mas se o equipamento fabricado realmente desempenha a função descrita no requisito, nas condições em que a fábrica pode produzi-lo. A tarefa de rastreabilidade nesta etapa é a atribuição — decidir, para cada cláusula que chega a este ponto, se o FAT é o local adequado para verificá-la ou se a condição realmente exige instalação no local ou integração ao processo para ser comprovada.

É nessa decisão de atribuição que o bom senso é mais importante, pois algumas condições podem ser verificadas igualmente bem na fábrica ou no local da instalação, enquanto outras só podem ser verificadas em um único local. Uma função que dependa apenas do próprio sistema de controle do equipamento e de seu comportamento mecânico geralmente pode ser verificada no FAT, já que o ambiente da fábrica é capaz de reproduzir as entradas relevantes. Uma função que dependa de interfaces com os serviços do local, integração com salas ou sistemas adjacentes, ou condições ambientais específicas do local de instalação não pode ser verificada de forma confiável até que essas interfaces existam — por mais minucioso que seja o projeto do teste de fábrica. Atribuir tal requisito ao FAT resulta em uma aprovação documentada que, na verdade, não demonstra a condição descrita pelo requisito.

Quando um resultado gerado no FAT se destina a substituir um teste SAT posterior — transferido, em vez de repetido no local —, a matriz precisa registrar não apenas o resultado, mas também a justificativa para sua reutilização. Essa justificativa deve abordar se algum fator entre a fábrica e o local poderia, de forma plausível, alterar o resultado: transporte, remontagem, um fornecimento de energia diferente ou uma condição ambiental diferente. Um resultado reutilizado sem essa justificativa suscita, na inspeção, a mesma dúvida que um requisito não atribuído — a saber, se a condição foi realmente verificada onde precisava ser verificada, ou se foi verificada uma vez em algum local conveniente e, então, presumida válida em todos os outros lugares.

A consequência para o planejamento é que o escopo do FAT deve ser definido requisito por requisito com base nesse teste de credibilidade, e não partindo do princípio de que “tudo o que for possível deve ser verificado na fábrica” simplesmente porque é mais barato ou mais rápido testar lá do que após a instalação.

Aceitação no local e qualificação da instalação: confirmar a configuração entregue

Tanto o SAT quanto o IQ ocorrem após a entrega e ambos dizem respeito ao equipamento já instalado, e não ao projeto ou à fabricação na fábrica; no entanto, eles respondem a questões diferentes, e a matriz precisa manter essa distinção bem clara. O SAT reconfirma o comportamento funcional nas condições do local — a mesma categoria de verificação do FAT, mas agora realizada com os serviços reais do local, pontos de integração reais e quaisquer condições locais que a fábrica não pudesse reproduzir. O IQ, por outro lado, confirma que o que foi efetivamente instalado corresponde ao que foi especificado e aprovado — componentes corretos, configuração correta, documentação correta — independentemente de o equipamento já estar funcionando corretamente.

A condição que determina se uma determinada cláusula do URS deve ser incluída no SAT ou no IQ é o tipo de evidência que a cláusula realmente exige. Um requisito relacionado a um atributo físico ou de configuração — um material, um acessório, uma revisão documentada do desenho instalada no local — é um fato de instalação, e o IQ é a etapa que pode encerrá-lo. Um requisito relacionado ao comportamento em condições operacionais — uma função que responde corretamente quando testada — exige que o equipamento esteja em funcionamento, o que o coloca na fase SAT, e não na IQ. Requisitos que descrevem tanto um atributo de instalação quanto uma resposta funcional precisam ser divididos entre as duas fases, em vez de serem forçados a se encaixar em uma única, com a matriz apresentando ambas as partes em relação ao mesmo requisito pai.

A própria configuração entregue é também onde a matriz mostra seu valor operacionalmente, pois é nesse ponto que as decisões específicas do projeto tomadas anteriormente — as escolhas de configuração de um fornecedor, as opções selecionadas durante a cotação, os detalhes de interface acordados durante a revisão do projeto — correspondem ou não ao que aparece no local da obra. Quando surgem discrepâncias entre o registro de projeto aprovado e o que foi efetivamente entregue, a matriz é o que permite ao revisor rastrear a discrepância até o ponto em que ela foi introduzida, em vez de tratá-la como uma constatação isolada no local, desconectada de seu histórico de projeto.

A qualificação operacional testa as funções em todas as condições operacionais aprovadas

A OQ responde à pergunta que a DQ e a FAT não conseguiram responder totalmente por si só: o equipamento funciona corretamente não apenas uma vez, sob uma única condição de demonstração, mas em toda a gama de condições operacionais que os requisitos aprovados realmente descrevem. Enquanto a FAT e a SAT confirmam, em grande parte, que uma função é executada, a OQ é estruturada para testar os limites dessa função — para avaliar o comportamento nos limites de sua faixa operacional pretendida, sob condições variáveis e em combinação com outras funções operando simultaneamente, em vez de isoladamente.

Essa distinção altera o que a matriz precisa registrar nesta etapa. Um único resultado de aprovação/reprovação em relação a uma condição operacional não encerra um requisito que foi elaborado para abranger uma gama de condições. Se a cláusula do URS especificar que uma função deve operar corretamente sob cargas variáveis, condições ambientais variáveis ou combinações variáveis de operações simultâneas, a entrada da matriz para essa cláusula precisa indicar quais condições específicas foram testadas e confirmar que a gama testada realmente abrange o que o requisito descreve — e não apenas que alguma instância da função foi executada com sucesso uma vez.

Quando um requisito foi redigido de forma vaga na fase do URS — uma consequência comum de requisitos elaborados antes da existência do projeto —, é na OQ que essa imprecisão se torna um problema prático, pois um requisito redigido de forma vaga não pode ser traduzido em uma condição de teste específica e defensável sem que alguém decida, a posteriori, o que o requisito realmente pretendia abranger. É por isso que a disciplina anterior de tornar os requisitos testáveis na fase de DQ é importante: um requisito reescrito para fins de testabilidade durante a DQ oferece aos planejadores da OQ uma condição específica para ser testada, enquanto um requisito mantido em sua forma ampla original força essa interpretação a ocorrer tardiamente, de maneira informal e sem o mesmo nível de revisão que o requisito original recebeu.

A matriz também deve distinguir os resultados da OQ que confirmam o funcionamento em condições normais aprovadas daqueles que testam condições limite ou combinadas, uma vez que estes representam diferentes níveis de rigor em relação ao mesmo requisito subjacente, e um revisor que verifica a cobertura precisa saber qual nível de rigor foi efetivamente alcançado.

Alterações, desvios e status de aprovação até a entrega final

Quando um projeto chega à fase de entrega, a matriz de rastreabilidade geralmente já incorporou várias rodadas de alterações — requisitos revisados após a aprovação inicial, resultados que não atenderam aos critérios de aceitação na primeira tentativa e decisões de reutilizar evidências anteriores em vez de repetir um teste. A tarefa nessa etapa final não é gerar novas evidências, mas confirmar que nada nesse histórico acumulado tenha ficado oculto.

Uma revisão aprovada do URS precisa permanecer vinculada ao requisito que substituiu, e não simplesmente sobrescrevê-lo, para que um revisor que examine evidências geradas antes da revisão possa identificar qual versão do requisito essas evidências realmente corroboram. Quando essa ligação é rompida — quando um requisito revisado substitui discretamente um anterior, sem nenhuma conexão visível entre eles —, as etapas posteriores de qualificação correm o risco de realizar a verificação com base em um conjunto de requisitos que não corresponde mais ao que foi formalmente aprovado, o que é difícil de detectar internamente e difícil de defender caso seja questionado durante uma inspeção.

Os requisitos não resolvidos precisam da mesma visibilidade, e não de serem ocultados. Um requisito que não pôde ser totalmente verificado, ou que gerou um desvio ainda em avaliação no momento da transferência, deve permanecer na matriz com seu registro de desvio e seu status de aprovação atual anexados, em vez de ser removido da lista ativa apenas porque o projeto está sendo encerrado. Isso está de acordo com EudraLex Volume 4 Anexo 15‘a abordagem do ciclo de vida da validação, no qual a URS atua como um ponto de referência constante ao longo da qualificação do projeto até os testes de aceitação, com as funções de FAT e SAT e a distinção entre Evidências de IQ e OQ mantidos separados, em vez de serem tratados como intercambiáveis — uma estrutura que só se sustenta se a exigência e seu status atual permanecerem rastreáveis no momento em que as evidências forem finalmente analisadas.

Os resultados reutilizados do FAT merecem o mesmo escrutínio final. Se um resultado de fábrica foi transferido para substituir uma verificação na fase de instalação, a justificativa documentada para essa reutilização precisa ainda estar presente e ser defensável no momento da entrega, e não ter sido perdida em algum ponto entre o FAT e a revisão final. O Anexo 15 apoia FAT e SAT uma vez que possuem funções justificadas e distintas, o que significa que um resultado reutilizado sem a justificativa anexada não atende a esse padrão por si só — a justificativa faz parte das evidências, não é uma formalidade separada delas.

Quando as informações do projeto fornecidas pelo cliente — o URS original, as revisões subsequentes e as condições específicas do local — foram registradas com precisão durante a configuração e a análise da cotação, essa reconciliação final da matriz consiste, em grande parte, em confirmar que nada foi perdido ao longo do processo, em vez de reconstruir os elos que faltam após o fato.

Perguntas frequentes

Q: Como um comprador deve preparar as cláusulas do URS relativas à rastreabilidade antes da avaliação do fornecedor?
A: Atribua a cada cláusula um identificador fixo e mantenha esse identificador ao longo das revisões aprovadas. Estruture a matriz de forma a vincular a resposta do fornecedor, o documento de projeto relevante, o protocolo de teste planejado, o critério de aceitação específico do projeto, o resultado, o desvio e o status de aprovação a esse identificador, para que as lacunas permaneçam visíveis ao longo das etapas de qualificação.

Q: O que o comprador deve verificar antes de aceitar a qualificação do projeto?
A: Confirme se todas as cláusulas aplicáveis do URS remetem tanto à resposta do fornecedor quanto às evidências do projeto aprovado, demonstrando como o projeto proposto atende ao requisito. Qualquer cláusula sem uma ligação clara deve permanecer visível, com seu desvio e status de aprovação, antes que as escolhas de fabricação se tornem dispendiosas de alterar.

Q: Como um requisito deve ser atribuído a FAT, SAT, IQ ou OQ?
A: Atribua-a à etapa em que sua condição possa ser comprovada de forma confiável: resultados de fábrica para verificações pré-embarque adequadas, resultados no local para condições comprovadas no local, verificações de instalação para a configuração entregue e desafios operacionais para condições operacionais aprovadas. Registre a escolha da etapa e o critério de aceitação específico do projeto ao lado da cláusula, para que as evidências posteriores possam ser avaliadas em relação à verificação pretendida.

Q: Quando é que um resultado do FAT pode ser reutilizado, em vez de se repetir a verificação posteriormente?
A: Reutilize-a somente quando a matriz identificar a cláusula aplicável do URS, associar o resultado de fábrica registrado e documentar a justificativa para se basear nela. Verifique se a entrega, a instalação, as condições do local ou uma revisão aprovada alteraram a condição que está sendo verificada; se for o caso, designe uma verificação adicional em uma etapa posterior confiável.

Q: O que deve ser verificado na matriz antes da entrega final?
A: Verifique se as evidências se referem à revisão atual aprovada do URS e se cada verificação planejada apresenta um resultado ou um desvio visível, além do status de aprovação. Dê atenção especial aos requisitos não resolvidos e às evidências reutilizadas do FAT, de modo que seu status atual e a justificativa documentada permaneçam explícitos no momento da transferência.