O processo de validar software industrial não é uma tarefa trivial, mas com uma boa orientação e metodologia consistente, tornar-se um procedimento que irá fluir naturalmente conforme o desenrolar das etapas.

O post Preciso validar meu software. Por onde começo? apresentou as considerações e passos iniciais neste processo, desde a identificação se de fato o sistema precisa ou não ser validado até o fluxograma macro das atividades envolvidas. Também vimos no post Como realizar o gerenciamento de riscos na validação de software? como é relevante entender e classificar cada funcionalidade do sistema.

Chegou a hora de apresentar as documentações e protocolos que precisam ser criados e avaliados como parte do escopo do processo de validar software industrial, independente do plano de validação adotado pela sua empresa.

Boa leitura!

Especificação de Requisitos do Usuário (URS – User Requirement Specification)

Este documento precisa definir de forma clara e objetiva todos os requisitos necessários que um sistema computadorizado deve atender. Deve ser revisado e aprovado pelos usuários envolvidos, incluindo a Garantia da Qualidade, e pode ser elaborado em conjunto com o fornecedor do software.

Os requisitos do usuário devem contemplar todas as necessidades da empresa em relação à instalação, operação e desempenho do sistema. Também devem ser consideradas todas as necessidades do usuário em termos de capacidade tecnológica, segurança dos dados e informações, requisitos de engenharia, interfaces, manutenção e atendimento às BPx.

BPx: termo geral para aplicação de boas práticas relacionadas a qualquer área (fabricação, distribuição, pesquisa clínica, laboratório, etc.).

Pela abrangência das áreas envolvidas, é recomendável que a elaboração deste documento seja realizada por uma equipe multidisciplinar para que todas as necessidades sejam devidamente identificadas e descritas como requisitos.

Classificação dos Requisitos

Após definir os requisitos,  o Guia da ANVISA recomenda realizar a classificação dos mesmos para contribuir com a identificação dos possíveis riscos às BPx que um sistema computadorizado pode apresentar.

Algumas das principais classificações a serem utilizadas:

• Informativo: não é exatamente um requisito e sim uma informação que será dada aos fornecedores para auxiliá-los na elaboração de suas propostas comerciais;
• Importante: requisito que obrigatoriamente será verificado durante o desenvolvimento do sistema/equipamento, mas que não será necessariamente avaliado durante o processo de validação do sistema, por não ter impacto em BPx;
• Regulatório e/ou Mandatório: requisito que obrigatoriamente deverá ser considerado durante o desenvolvimento do sistema/equipamento e obrigatoriamente será avaliado durante o processo de validação do sistema por ter impacto em BPx;
• Desejável: requisito que se deseja no desenvolvimento do sistema, porém o mesmo não obrigatoriamente poderá ser considerado pelo fornecedor, ou mesmo desconsiderado se acarretar custos demasiados ou dificuldade técnicas para atendê-lo.

A partir dessa classificação você terá o mapeamento dos itens que requerem um maior detalhamento e que necessariamente devem ser contidos nos protocolos de testes de validação.

Especificação de Requisitos do Sistema (SRS – System Requirement Specification)

Este item descreve todos os requisitos técnicos considerando hardware e software, sendo desejável também a descrição de servidores, arquitetura de rede, estações de trabalho e hardware de automação quando aplicável. Exemplos de itens a considerar:

• Descrição do hardware (considerando computadores, componentes, CPU, memórias, capacidade, etc.);
• Entradas/saídas de dados, considerando sinais analógicos e/ou digitais;
• Temperatura e umidade do ambiente no qual os equipamentos estão instalados;
• Interferências externas;
• Etc.

Uma vez descritas todas as especificações do usuário e sistema, que são a base para desenvolver os protocolos para validar software industrial, segue-se para a etapa da descrição das especificações funcionais.

Especificação de Requisitos Funcionais (FRS – Functional Requirement Specification)

A especificação funcional serve para definir completamente o que o sistema faz e quais funções e instalações são fornecidas para atender as necessidades descritas nos Requisitos do Usuário. 

A especificação funcional deverá ser clara e organizada de uma maneira que permita rastreabilidade entre os requisitos do usuário e as funcionalidades. Por isso, é recomendável que cada requisito e funcionalidade contenham um único número de referência para facilitar a rastreabilidade e a referência cruzada com outros documentos.

De fato o que deve-se fazer é o desdobramento dos requisitos do usuário para um nível de funções individuais, onde podem ser descritos as seguintes informações com os seguintes aspectos:

• Detalhes dos aspectos funcionais e de dados do sistema que atenderão aos requisitos do usuário;
• Todas as limitações do sistema, observando quaisquer divergências entre a funcionalidade fornecida pelo sistema com relação aos requisitos do usuário;
• Objetivo de cada função ou instalação;
• Descrição das interfaces internas e externas;
• Entradas, saídas, cálculos críticos, lógicas de funcionamento, e impactos em outras funções ou outros sistemas;
• Ação em caso de falhas do software selecionado ou falhas no hardware, checagens automáticas, checagem de valores de entrada, redundância, restrições de acesso e recuperação de dados;
• Funções que são parametrizáveis/configuráveis e seus limites;
• Funções relativas à segurança do sistema;
• Etc.

São muitos detalhes não é mesmo?

Para tornar mais simples o entendimento das funcionalidades, recomenda-se também a elaboração do desenho do software (Software Design). Este item fornece detalhe técnico do sistema sendo uma expansão da especificação funcional utilizado fluxogramas e esquemas. Auxilia na descrição de como o sistema atenderá cada uma das funções definidas na especificação funcional.

Testes de Qualificação

Com os requisitos do sistema e usuário definidos e as respectivas funcionalidades detalhadas, o processo de validar software industrial parte para a etapa de elaboração dos protocolos de testes, que possuem como objetivo justamente comprovar as funcionalidades descritas.

As verificações devem ser assinadas e datadas, e os desvios, não-conformidades e/ou condições questionáveis detectados durante a execução da qualificação, devem ser registrados, investigados e controlados.

Qualificação de Instalação (IQ – Installation Qualification)

Visa verificar e documentar as condições de instalação do sistema e se este cumpre satisfatoriamente com os requisitos previamente aprovados na especificação técnica.

Qualificação de Operação (OQ – Operational Qualification)

Tem com objetivo referenciar, verificar e documentar as condições de operação do sistema e se este cumpre satisfatoriamente com os requisitos pré-definidos para sua operação. Quando possível, o protocolo deve ser executado em ambiente de testes, sendo este cópia fiel do ambiente que será usado em produção.

Qualificação do Desempenho (PQ – Performance Qualification)

Tem como objetivo referenciar, verificar e documentar que o sistema computadorizado, após ser instalado no ambiente de produção e estar adequadamente parametrizado, cumpre satisfatoriamente com os requisitos pré-definidos pela Especificação de Requerimentos do Usuário e/ou Especificação Funcional.

Matriz de Rastreabilidade (TM – Traceability Matrix)

A Matriz de Rastreabilidade estabelece a relação entre os documentos desenvolvidos durante o processo de validar software industrial. Ela pode ser demonstrada de várias maneiras, desde a elaboração de uma tabela de informação cruzada ou referências diretamente inseridas nos documentos.

A ideia é conseguir conectar tudo de forma rápida. A matriz deve responder o seguinte: “Quais itens do protocolo de validação comprovam a funcionalidade solicitada pelo usuário descrita no requisito?”

Documentos para validar software industrial finalizados. E agora?

Agora entra a manutenção do estado validado, que é gerida por uma série de procedimentos operacionais de forma a assegurar que seja mantido este estado do sistema.

Um dos procedimentos extremamente relevantes é o de Controle de Mudanças, que deve apresentar a descrição das ações a serem tomadas para execução de uma alteração ou correção do sistema validado durante ou após o término da Qualificação (relembre no fluxograma 1 apresentado neste post os demais procedimentos relevantes).

Para finalizar o assunto

Este é o terceiro post que tratamos de validação de software, o que mostra que este tema é bastante extenso não é mesmo?

Mas ainda tem mais. Devido a complexidade dos sistemas computadorizados, existe uma padronização global que visa classificá-los conforme sua atuação, facilitando o entendimento de sua aplicação. E para cada classificação, o Guia da ANVISA descreve respectivas particularidades a serem consideradas neste processo de validar software industrial.

Mas destacamos novamente que, com a orientação correta, o processo de validar software industrial pode ser desenvolvido de forma robusta e eficiente, comprovando a segurança das suas informações e tornando-se uma ferramenta de melhoria e prevenção de falhas.

Se você precisa de ajuda com a validação de software ou cumprimento com a FDA CFR 21 Part 11, entre em contato conosco para mais detalhes de como a nossa equipe pode auxiliá-lo neste processo.