URS, Spec, Risk: a tríade que sustenta validação que passa

Os 3 documentos que decidem o destino do projeto antes da execução. Faça bem e a validação flui — faça mal e nenhum esforço de teste compensa.

Existe uma verdade incômoda sobre validação de sistemas computadorizados: o destino do projeto é decidido nas primeiras 4 semanas. Especificamente, em 3 documentos: URS (User Requirements Specification), Spec (Functional/Design Specification), e Risk Assessment. Quando os 3 são bem feitos, todo o resto — IQ, OQ, PQ, VSR — flui naturalmente. Quando algum dos 3 está mal, nenhum esforço de teste subsequente conserta. O inspetor pega na rastreabilidade.

Esse artigo cobre como escrever cada um, e os erros que mais comprometem o projeto na origem.

URS — User Requirements Specification

O URS é o documento do cliente. Define o que o sistema precisa fazer pra atender ao processo de negócio e à regulação. Não é "o que o software faz" — é "o que eu preciso que faça". A diferença é gigante.

URS bem feita tem requisitos que são:

• Únicos — cada requisito com ID rastreável (ex.: URS-DOC-001)
• Testáveis — pode-se verificar objetivamente se foi atendido
• Não-ambíguos — uma única interpretação possível
• Justificados — referência ao processo ou cláusula regulatória que sustenta
• Priorizados — must / should / nice-to-have

Erro mais comum: URS que descreve solução em vez de requisito. "O sistema deve ter botão 'Aprovar' em vermelho" é solução. "O sistema deve permitir aprovação two-person rule conforme RDC 658 Art. 11" é requisito.

Spec — Functional / Design Specification

Spec é o documento do fornecedor. Responde ao URS dizendo como cada requisito vai ser atendido. Função, tela, fluxo, dado, regra de negócio. É a ponte entre URS e código.

Spec bem feita tem:

• Cobertura completa dos requisitos URS
• Detalhe técnico suficiente pra implementação e teste
• Rastreabilidade explícita ao URS (matriz)
• Decisões de design justificadas

Erro mais comum: Spec que ignora algum requisito URS ou que adiciona funcionalidade sem requisito. Auditor cruza URS × Spec — qualquer descasamento aparece.

Risk Assessment

Análise de risco conforme ICH Q9. Pra cada requisito (ou agrupamento), avaliação de:

• Severidade — qual o dano se a função falhar?
• Probabilidade — qual a chance de falhar?
• Detectabilidade — quão fácil é perceber a falha?

O resultado prioriza o esforço de teste. Funcionalidade de alta severidade + alta probabilidade + baixa detectabilidade = profundidade de teste alta. Funcionalidade de baixo impacto = teste leve. Isso é GAMP 5 + Q9 aplicados.

A matriz de rastreabilidade

O documento que amarra a tríade ao resto é a matriz de rastreabilidade: URS → Spec → Risk → Caso de Teste → Evidência. Quando o auditor pega o URS-DOC-001 e pergunta "como esse requisito foi testado?", a matriz tem que apontar pra o caso de teste específico, executado, com evidência anexada.

Sem matriz, validação é coleção desorganizada de documentos. Com matriz, é sistema rastreável.

Como o NOAH OS entrega isso

O NOAH chega com URS template (que o cliente adapta), Spec completa, análise de risco GAMP 5 cat 4, e matriz de rastreabilidade já preenchida pra requisitos do produto. Cliente foca em adicionar requisitos específicos da sua operação — não em construir tudo do zero. Isso é o que viabiliza prazo de 30-60 dias até estado validado.