Dossiê técnico com evidências de validação

Um dossiê técnico não é uma pasta cheia de arquivos. É um conjunto coerente que permite responder: qual requisito está sendo avaliado, qual documento descreve a solução e onde está o registro que a sustenta?

Para o monitor de temperatura didático, o dossiê reúne o que já foi produzido ao longo do projeto: requisitos, arquitetura, cálculos, esquemático, lista de componentes, firmware, layout, procedimentos e registros de ensaio. Cada documento precisa ter uma finalidade clara e ser localizável dentro do próprio conjunto.

Uma estrutura local simples pode separar os documentos por finalidade. Os nomes são apenas um exemplo; adapte-os ao seu projeto, mas mantenha a separação compreensível.

• 01_requisitos_arquitetura/: requisitos mensuráveis e diagrama de blocos.
• 02_decisoes_calculos/: justificativas, orçamento de consumo, erro e incerteza.
• 03_esquematico_bom/: esquemático e lista de componentes.
• 04_firmware_layout/: código-fonte e documentos do layout.
• 05_procedimentos_evidencias/: roteiros de ensaio, tabelas de leituras e registros.
• 06_pendencias_conclusao/: lacunas conhecidas e síntese de validação.

Essa divisão não afirma que algo foi validado; ela apenas torna possível encontrá-lo e avaliá-lo depois.

Um índice pode ser um arquivo de texto, documento ou planilha salvo na raiz do dossiê. Ele é o ponto de entrada: informa onde procurar, para que serve cada item e o que ainda está ausente.

Não é necessário fabricar a placa para fazer esta organização. Para este monitor didático, por exemplo, o layout pode existir como documento de projeto, enquanto a montagem em protoboard e seus registros ficam associados aos ensaios que realmente foram feitos.

No seu computador, crie uma pasta para o dossiê e, dentro dela, as seis pastas do exemplo. Em seguida, crie um arquivo chamado INDICE.md ou indice.txt na raiz.

Você pode listar documentos próprios já existentes. Se ainda não tiver registros suficientes, use o caso fictício do exemplo somente para treinar a organização e marque-o como fictício. Dados fictícios ilustram um formato de registro; eles não comprovam o funcionamento do seu projeto.

Evite referências que só façam sentido fora do conjunto, como “arquivo na área de trabalho de alguém”. Quem consultar o dossiê deve conseguir seguir os caminhos a partir de sua pasta raiz.

Associe cada documento à pasta cuja finalidade permite encontrá-lo mais facilmente.

Resultado só existe dentro de uma configuração

Uma leitura, cálculo, relatório de ERC/DRC ou ensaio não pertence simplesmente ao “projeto”. Ele pertence à configuração de referência que estava em uso quando foi produzido.

Registre uma configuração como um conjunto identificável e compatível: montagem física, revisão do esquemático, BOM, layout, firmware e parâmetros relevantes. Assim, quem consulta o dossiê sabe exatamente o que foi analisado ou ensaiado — e não infere que o resultado vale para arquivos posteriores.

Exemplo: uma medição feita na protoboard com HW-PROT-01, firmware FW-1.2.0 e ganho configurado como 5,7 não demonstra o comportamento de uma placa PCB-R02 ainda não montada.

Use uma ficha curta para cada configuração analisada ou ensaiada. Ela não substitui os arquivos; funciona como a chave que os relaciona.

Para o monitor de temperatura didático, uma ficha pode identificar a montagem usada e as revisões exatas dos documentos. Inclua também parâmetros que alterem o comportamento, como ganho, referência do ADC, período de aquisição e condições de compilação.

Ferramentas entram no registro quando podem afetar a interpretação ou a reprodução: versão do editor, biblioteca do componente, compilador/placa selecionada, opções de compilação e conjunto de regras usado em ERC ou DRC. Não é necessário inventariar programas sem relação com o resultado.

A pasta pode conter um firmware mais novo, mas a evidência continua ligada ao firmware que a originou. “Atual” não significa “aplicável ao resultado anterior”.

Preserve os arquivos ou cópias identificadas que sustentam uma evidência. Ao mudar algo, crie uma nova revisão e anote a alteração. Uma estrutura local simples já resolve:

• configuracoes/CFG-ENSAIO-01.txt
• firmware/FW-1.2.0/
• firmware/FW-1.3.0/
• evidencias/ENSAIO-TEMP-01/

Evite substituir FW-1.2.0 pelo conteúdo de FW-1.3.0 mantendo o mesmo nome. Isso quebra a ligação entre resultado e origem. Uma tabela de alterações pode complementar as pastas; não é obrigatório usar controle de versões.

Um relatório de ensaio foi feito na protoboard MON-PB-01, com esquemático SCH-R03 e firmware FW-1.2.0. Depois foi salvo FW-1.3.0, alterando o filtro digital. Qual registro é tecnicamente correto para o relatório já existente?

Uma evidência deve trazer dois rótulos independentes:

1. Origem — como o registro foi obtido.
2. Alcance — qual afirmação ele realmente sustenta.

Use quatro situações explícitas:

• Medição: leitura obtida em uma configuração e condição registradas.
• Cálculo ou previsão: resultado de modelo, especificação ou hipótese declarada.
• Verificação por ferramenta: resultado de regras executadas, como ERC ou DRC.
• Não verificado: ainda não há demonstração suficiente para a afirmação.

“Não verificado” não significa que o requisito falhou, nem que provavelmente atende. Significa apenas que o dossiê não permite concluir.

O alcance também depende do objeto ensaiado. Uma leitura na protoboard pertence à protoboard, com seus componentes, fiação, alimentação e firmware identificados. Ela não se transfere automaticamente para uma placa cujo layout foi apenas revisado por DRC.

Da mesma forma, injetar uma tensão conhecida na entrada do ADC pode demonstrar parte do condicionamento e da aquisição, mas não demonstra por si só a medição física de temperatura pelo sensor.

Associe cada registro à afirmação que ele sustenta diretamente.

Da matriz de verificação à cadeia de rastreabilidade

Uma matriz de verificação fica mais útil quando cada requisito aponta para uma cadeia consultável:

requisito → decisão → artefato e revisão → procedimento → evidência → conclusão.

Os elos respondem a perguntas diferentes: o requisito define o que avaliar; a decisão explica a escolha; o artefato mostra o que foi implementado; o procedimento define como avaliar; a evidência registra o que ocorreu; e a conclusão compara a evidência com o critério, dentro do escopo aplicável.

Use identificadores e caminhos locais específicos. Assim, quem consulta o dossiê consegue partir de um requisito até sua sustentação ou começar por uma evidência e descobrir quais conclusões dependem dela. A cadeia não amplia o alcance de um registro: a conclusão continua limitada à configuração e às condições efetivamente avaliadas.

Justificar não é comprovar

A justificativa de projeto explica por que uma escolha parece adequada. Registre de modo conciso:

• necessidade atendida;
• alternativas consideradas;
• motivo da seleção;
• margem adotada;
• limitação conhecida.

A comprovação de atendimento, por outro lado, depende de evidência aplicável, configuração identificada, procedimento e regra de decisão. Uma escolha bem fundamentada ainda pode exigir ensaio. Por exemplo, registrar o fator de ganho usado na conversão pode tornar a implementação coerente com a configuração, mas não transforma automaticamente um requisito de erro em “atendido”.

O registro da decisão e a evidência de verificação devem permanecer ligados, mas não devem ser confundidos.

Consulte nos dois sentidos e preserve as lacunas

Partindo de RQ-03, siga os vínculos até a evidência para revisar a sustentação da conclusão. Partindo de EV-RES-04, percorra o caminho inverso para identificar quais requisitos e conclusões usam esse resultado. Se uma evidência tiver escopo insuficiente, você saberá o que precisa ser reavaliado.

Não complete uma cadeia por inferência. Registre o estado apropriado:

• vínculo ausente: o documento ou a referência não foi localizado;
• cobertura parcial: há evidência, mas ela cobre apenas parte das condições ou da faixa do requisito;
• inconclusivo: a evidência disponível não permite decidir atendimento ou não atendimento.

Esses estados não são falhas a esconder. Eles tornam os limites do dossiê visíveis e evitam que uma previsão, uma decisão bem escrita ou uma evidência de outro escopo seja usada como comprovação indevida.

Um pacote de evidência reproduzível não é apenas o valor final de um ensaio. Ele permite que outra pessoa localize a configuração usada, entenda o que foi feito e confira como os dados levaram à conclusão.

Para cada resultado, reúna no dossiê local:

• identificação da configuração e dos artefatos correspondentes;
• condições, instrumentos e ajustes relevantes;
• sequência efetivamente executada;
• dados brutos preservados;
• tratamento aplicado aos dados;
• resultado e regra de decisão já definida;
• limitações e informações indisponíveis.

O pacote pode usar arquivos de texto, tabelas e planilhas locais. Uma foto própria pode complementar a descrição da montagem, mas não substitui condições de ensaio, leituras numéricas ou o procedimento.

Use caminhos relativos ao diretório-raiz do dossiê. Assim, a consulta não depende de uma pasta pessoal ou de uma máquina específica.

Exemplo de estrutura local para um ensaio de temperatura em protoboard:

Divergência não é falha “apagada”

Quando uma previsão e uma medição divergem, crie um registro próprio e preserve os dois lados da comparação. O registro deve apontar a configuração, as condições e os pacotes de evidência usados em cada resultado.

Não basta escrever “valor incorreto”: informe o que foi previsto, o que foi observado, em quais condições e a quais versões esses dados se aplicam. Assim, outra pessoa consegue verificar se a comparação é válida e localizar os dados originais.

Um registro de divergência pode seguir esta sequência:

1. Observação: fato diretamente presente na evidência.
2. Hipótese de causa: explicação ainda a investigar.
3. Causa confirmada: conclusão sustentada por verificação adicional.
4. Ação corretiva: mudança aplicada em um artefato identificado.
5. Situação atual: o que já foi demonstrado e o que ainda permanece pendente.

A hipótese não vira causa confirmada porque parece plausível. E uma ação corretiva implementada não comprova, por si só, que o comportamento foi corrigido.

Uma medição anterior pertence à configuração que foi ensaiada. Se o firmware, o esquemático, a montagem ou um parâmetro mudou, identifique a nova revisão em vez de reaproveitar automaticamente a conclusão antiga.

Ao registrar uma correção, ligue-a aos artefatos modificados e aos requisitos que podem depender deles. Isso não exige decidir agora todos os ensaios posteriores: basta tornar o impacto consultável e declarar a comprovação que ainda falta.

Uma alteração não pede automaticamente “todos os testes”. Ela pede uma análise de impacto registrada.

Separe dois conjuntos:

• Confirmação da correção: reproduz ou verifica o comportamento que havia divergido, na configuração alterada. Responde: “a alteração resolveu o problema?”
• Regressão: verifica requisitos e funções que podem ter mudado indiretamente. Responde: “o que continuou válido depois da alteração?”

Os dois conjuntos podem compartilhar um procedimento, mas têm objetivos diferentes. Uma correção no filtro, por exemplo, pode precisar ser confirmada na resposta filtrada e também exigir regressão de atualização e indicação, se essas funções dependem do valor filtrado.

Parta do artefato alterado e siga as ligações já registradas: bloco ou recurso compartilhado → requisito dependente → procedimento e evidência anteriores. Inclua um ensaio quando a mudança puder alterar seu resultado ou invalidar a aplicabilidade da evidência anterior.

Exclua um ensaio somente com justificativa: ausência de caminho conhecido, configuração sem alteração relevante ou impacto analisado e delimitado. Se o alcance não puder ser delimitado, amplie a regressão em vez de supor que não houve efeito.

O plano de regressão deve registrar, para cada teste: alteração analisada, requisito ou função coberta, motivo de inclusão ou exclusão, configuração-alvo, procedimento a usar e estado. Após executar, acrescente a referência da evidência e o resultado; não substitua o registro anterior.

Mudança de ganho, temporização ou montagem pode alterar caminhos diferentes. Use a mesma lógica: confirme a divergência e percorra as dependências conhecidas. Não é necessário energizar novamente o circuito para elaborar este plano.

Antes de concluir, faça uma revisão de navegabilidade do dossiê local. A pergunta não é “há muitos arquivos?”, mas “uma pessoa consegue seguir uma afirmação até sua sustentação?”.

Confira cinco pontos:

1. Índice: aponta onde estão os documentos e revela ausências.
2. Configuração de referência: identifica montagem, revisões, firmware, parâmetros e ferramentas aplicáveis.
3. Rastreabilidade: liga requisito, decisão, procedimento, evidência e conclusão.
4. Pacote de evidência: preserva condições, dados brutos, tratamento e regra de decisão.
5. Alterações e regressão: mantém a divergência anterior, a correção, o impacto e o estado dos testes.

Se um resultado não permite encontrar sua configuração ou seus dados de origem, ele não sustenta sozinho uma conclusão de validação.

Uma conclusão deve declarar o escopo, e não apenas uma frase de aprovação. Ela informa a qual configuração se aplica, quais condições e métodos foram efetivamente usados e que tipo de evidência sustenta cada resultado.

Use estados distintos:

• Atendido no escopo declarado: evidência suficiente para a condição registrada.
• Não atendido: evidência mostra que o critério não foi cumprido.
• Inconclusivo: o resultado não permite decidir pelo critério adotado.
• Não verificado: falta demonstração aplicável; não é aprovação nem reprovação.

Uma previsão por cálculo pode justificar uma expectativa condicionada às hipóteses. Uma medição sustenta apenas a configuração e as condições medidas. Uma verificação por ERC ou DRC sustenta somente as regras executadas. Nenhuma dessas evidências deve receber um alcance maior do que o seu registro permite.