Engenharia Forense em Projetos de Software: Requisitos, Entregas e Evidências Técnicas

Resumo executivo

Projetos de software frequentemente se tornam objeto de controvérsias técnicas quando há divergências sobre escopo, requisitos, entregas, qualidade, aderência funcional, prazos, desempenho, integração, documentação, suporte, implantação ou responsabilidade por falhas.

Em ambientes corporativos, essas disputas podem envolver sistemas desenvolvidos sob encomenda, plataformas de ERP, CRM, aplicações web, sistemas acadêmicos, soluções financeiras, ferramentas de automação, softwares embarcados, aplicações SaaS, integrações por API, bancos de dados, módulos customizados e projetos de transformação digital.

A engenharia forense aplicada a projetos de software tem por finalidade examinar evidências técnicas e documentais para compreender o que foi contratado, o que foi especificado, o que foi desenvolvido, o que foi entregue, o que foi homologado, quais falhas foram registradas, quais impactos foram observados e quais limitações técnicas afetam as conclusões possíveis.

O trabalho não se confunde com auditoria genérica de tecnologia, nem com simples opinião sobre a qualidade do software. Trata-se de análise técnica estruturada, voltada à produção de evidências e à reconstrução de fatos relevantes em disputas corporativas, judiciais, arbitrais ou institucionais.

1. O software como objeto de prova técnica

Software é um objeto técnico complexo. Ele não se resume ao código-fonte, nem à interface visível ao usuário. Um sistema corporativo envolve requisitos, arquitetura, regras de negócio, dados, integrações, permissões, infraestrutura, ambientes, versões, documentações, testes, logs, configurações, contratos, tickets e registros de implantação.

Em uma controvérsia, a análise técnica pode exigir o exame de elementos como:

• contrato e anexos técnicos;
• proposta comercial;
• termo de referência;
• documentação de requisitos;
• atas de reunião;
• backlog;
• histórias de usuário;
• especificações funcionais;
• especificações não funcionais;
• documentação de arquitetura;
• código-fonte;
• repositórios de versão;
• commits e branches;
• registros de homologação;
• planos e evidências de testes;
• manuais;
• tickets de suporte;
• logs de erro;
• registros de implantação;
• bases de dados;
• APIs e integrações;
• ambientes de produção, homologação e desenvolvimento;
• mensagens corporativas e e-mails técnicos;
• relatórios de incidentes;
• registros de aceite ou rejeição.

Esses materiais permitem examinar a evolução do projeto e a coerência entre obrigação contratual, expectativa técnica, execução, entrega e resultado observado.

2. Tipos de controvérsias em projetos de software

As disputas envolvendo software podem surgir em diferentes momentos do ciclo de vida do projeto. Algumas ocorrem ainda na fase de especificação; outras aparecem durante a implantação, após a entrada em produção ou em momentos de manutenção e suporte.

Entre as controvérsias mais recorrentes estão:

2.1 Divergência sobre requisitos

Pode haver discussão sobre quais funcionalidades foram efetivamente contratadas, especificadas, aprovadas ou alteradas ao longo do projeto. Em muitos casos, requisitos são descritos de forma genérica, incompleta ou ambígua, gerando conflito entre expectativa do contratante e interpretação do fornecedor.

2.2 Entrega incompleta ou inadequada

A controvérsia pode envolver a alegação de que determinado módulo, funcionalidade, integração ou relatório não foi entregue, foi entregue parcialmente ou não atende ao propósito contratado.

2.3 Falhas de implantação

Projetos podem apresentar problemas na migração de dados, parametrização, treinamento, integração com sistemas legados, configuração de ambientes, transição operacional ou entrada em produção.

2.4 Defeitos e instabilidade

A disputa pode envolver erros recorrentes, indisponibilidade, lentidão, perda de dados, inconsistências, falhas de segurança, comportamento inesperado ou impossibilidade de uso adequado.

2.5 Ausência de documentação

A falta de documentação técnica, funcional, operacional ou de suporte pode dificultar manutenção, validação, continuidade do projeto e responsabilização técnica.

2.6 Mudança de escopo

Conflitos podem decorrer de alterações solicitadas durante o projeto, funcionalidades não previstas, customizações adicionais, prazos reestimados ou ausência de controle formal de mudanças.

2.7 Descontinuidade ou abandono

Em alguns casos, a controvérsia envolve paralisação do projeto, encerramento antecipado, ruptura contratual, impossibilidade de continuidade por terceiro ou dependência excessiva do fornecedor original.

3. Perguntas técnicas que orientam a análise

A engenharia forense em projetos de software procura transformar uma disputa ampla em perguntas tecnicamente examináveis. Algumas perguntas são recorrentes:

O escopo estava definido de forma suficiente?
Examina-se se contratos, anexos, propostas e documentos técnicos permitem identificar as funcionalidades, integrações, critérios de aceite e obrigações relevantes.

Os requisitos foram documentados, aprovados e controlados?
Analisa-se a existência de registros formais de requisitos, mudanças, validações e decisões.

As entregas correspondem ao que foi contratado?
Comparam-se entregáveis, versões, módulos, funcionalidades e evidências de homologação com o escopo técnico aplicável.

As falhas relatadas são reproduzíveis e tecnicamente demonstráveis?
Verifica-se se há logs, prints, vídeos, tickets, bases de teste, registros de erro ou condições técnicas que permitam confirmar os problemas.

As falhas decorrem do software, da infraestrutura, da parametrização ou do uso?
Diferenciam-se causas possíveis para evitar atribuição indevida.

Houve aceite, homologação ou uso continuado?
Analisa-se o significado técnico de registros de aceite, aprovações parciais, entrada em produção, pagamentos, uso operacional e ressalvas documentadas.

Há evidências de impacto operacional ou econômico?
Examinam-se indisponibilidades, retrabalho, produtividade, interrupções, perda de dados, custos adicionais e efeitos sobre processos de negócio.

Quais limitações impedem conclusões mais amplas?
Identificam-se lacunas documentais, ausência de logs, ambientes não preservados, código indisponível, mudanças posteriores ou dados incompletos.

4. Matriz de evidências em projetos de software

Uma análise técnica consistente deve relacionar as perguntas investigativas às fontes de evidência disponíveis. A matriz abaixo ilustra essa relação.

Essa matriz ajuda a evitar conclusões baseadas em impressões gerais ou narrativas unilaterais. A análise deve demonstrar de que forma cada achado se conecta a uma fonte verificável.

5. Requisitos: o ponto de partida da controvérsia

Grande parte das disputas em software decorre de requisitos insuficientemente definidos. Requisitos podem ser funcionais ou não funcionais.

Requisitos funcionais descrevem o que o sistema deve fazer: cadastros, consultas, cálculos, relatórios, fluxos de aprovação, integrações, permissões, validações e regras de negócio.

Requisitos não funcionais descrevem como o sistema deve operar: desempenho, disponibilidade, segurança, escalabilidade, usabilidade, compatibilidade, rastreabilidade, recuperação, integridade e capacidade de auditoria.

Em análise forense, é importante verificar se esses requisitos foram:

• documentados;
• aprovados;
• versionados;
• modificados;
• testados;
• homologados;
• vinculados a entregas;
• convertidos em critérios de aceite;
• refletidos no contrato ou nos anexos técnicos.

A ausência de requisitos claros não impede a análise, mas aumenta a necessidade de examinar documentos complementares, comunicações, práticas do projeto, versões entregues e expectativas razoáveis decorrentes do contexto técnico.

6. Entregas, homologação e aceite

Em projetos de software, “entrega” e “aceite” não são conceitos equivalentes.

Uma entrega pode consistir em disponibilizar uma versão, módulo, ambiente, pacote, repositório, funcionalidade ou documentação. O aceite, por outro lado, pressupõe algum grau de validação pelo contratante, que pode ser formal, parcial, condicionado ou contestado.

A análise técnica deve avaliar:

• quais entregáveis foram previstos;
• quando foram disponibilizados;
• em que ambiente foram entregues;
• se havia critérios de aceite;
• se houve testes de homologação;
• se as falhas foram registradas;
• se houve correções;
• se o sistema entrou em produção;
• se a produção ocorreu com ressalvas;
• se o uso continuado indica aceitação técnica ou mera necessidade operacional.

Em disputas, é comum que uma parte alegue entrega satisfatória e a outra alegue impossibilidade de uso. A engenharia forense deve examinar os registros disponíveis para verificar se a divergência é suportada por evidências técnicas.

7. Código-fonte, repositórios e versionamento

Quando disponível, o código-fonte pode ser uma evidência relevante, mas sua análise deve estar vinculada ao objeto da controvérsia. Nem toda disputa de software exige revisão completa de código. Em muitos casos, a análise pode se concentrar em módulos, funções, commits, trechos relacionados a falhas, integrações específicas ou histórico de alterações.

Repositórios de versionamento podem fornecer informações sobre:

• evolução do desenvolvimento;
• datas de alterações;
• autoria técnica dos commits;
• branches e merges;
• correções de bugs;
• remoção ou inclusão de funcionalidades;
• relação entre entregas e versões;
• alterações próximas a incidentes;
• maturidade de práticas de desenvolvimento;
• documentação associada.

A análise de código deve ser feita com cautela. A existência de código não utilizado, comentários, trechos legados ou débitos técnicos não significa, por si só, descumprimento contratual. É necessário relacionar os achados a requisitos, falhas demonstradas, impacto e obrigações técnicas aplicáveis.

8. Falhas, defeitos e responsabilidade técnica

Nem todo comportamento indesejado de um sistema decorre de defeito de software. A análise precisa distinguir causas possíveis, como:

• erro de código;
• requisito ambíguo;
• parametrização incorreta;
• uso inadequado;
• falha de infraestrutura;
• indisponibilidade de serviço externo;
• integração mal especificada;
• inconsistência em dados migrados;
• configuração de segurança;
• limitação contratual do produto;
• customização incompatível;
• ausência de treinamento;
• ambiente subdimensionado;
• falha operacional.

Essa distinção é essencial porque a responsabilidade técnica pode variar conforme a origem do problema. Uma lentidão, por exemplo, pode decorrer de código ineficiente, consulta mal construída, banco de dados sem índices, infraestrutura insuficiente, tráfego elevado, configuração inadequada ou integração externa instável.

O trabalho pericial deve evitar conclusões simplificadas. A análise adequada exige correlação entre evidências, testes, logs, arquitetura, documentação e condições reais de uso.

9. Ambientes, dados e implantação

A implantação é uma fase particularmente sensível em projetos corporativos. Mesmo sistemas corretamente desenvolvidos podem apresentar problemas relevantes se houver falhas na migração de dados, configuração de permissões, parametrização, integração com sistemas legados ou treinamento de usuários.

A análise forense pode examinar:

• plano de implantação;
• cronograma de migração;
• scripts de carga de dados;
• logs de importação;
• inconsistências em bases migradas;
• parametrizações;
• perfis de acesso;
• integrações ativas;
• registros de deploy;
• chamados de suporte;
• evidências de indisponibilidade;
• rollback ou correções emergenciais;
• comunicação entre equipes técnicas e áreas usuárias.

Em disputas, é importante verificar se o problema está no software desenvolvido, no processo de implantação, nos dados fornecidos, no ambiente do cliente, em sistemas de terceiros ou na governança do projeto.

10. Relatório técnico em disputas de software

Um relatório de engenharia forense em software deve apresentar os achados de forma compreensível para públicos técnicos e não técnicos. O documento deve demonstrar o caminho entre evidência e conclusão.

Elementos recomendáveis incluem:

• objeto do exame;
• escopo da análise;
• documentos e sistemas examinados;
• metodologia aplicada;
• limitações;
• descrição do projeto;
• linha do tempo;
• requisitos relevantes;
• entregas identificadas;
• falhas ou controvérsias examinadas;
• evidências técnicas;
• análise de aderência;
• avaliação de impacto técnico;
• hipóteses consideradas;
• conclusões;
• anexos técnicos.

O relatório deve separar fato documentado, constatação técnica, inferência e opinião fundamentada. Essa distinção é importante para preservar a objetividade do trabalho e evitar afirmações que ultrapassem a evidência disponível.

11. Entregáveis possíveis

A atuação do IBPTECH em disputas de software pode gerar diferentes produtos técnicos, conforme o escopo do caso, a finalidade do exame e os materiais disponíveis:

• relatório técnico sobre projeto de software;
• parecer sobre aderência funcional;
• análise de requisitos e entregas;
• avaliação de falhas em implantação;
• exame de código-fonte;
• análise de logs de aplicação;
• matriz de evidências;
• linha do tempo do projeto;
• relatório sobre incidentes e defeitos;
• análise de documentação técnica;
• parecer sobre impacto de falhas;
• subsídios técnicos para quesitos;
• assistência técnica em processo judicial ou arbitral;
• nota técnica para negociação ou mediação.

Cada entregável deve ser compatível com a profundidade da análise realizada e com as limitações das evidências disponíveis.

Considerações finais

Projetos de software são ambientes complexos, nos quais escopo, requisitos, código, dados, integrações, infraestrutura, documentação, implantação e operação se combinam. Quando surgem disputas, a análise técnica deve ir além da percepção dos usuários ou da narrativa das partes.

A engenharia forense em projetos de software busca reconstruir os fatos a partir de evidências: documentos, versões, logs, requisitos, entregas, tickets, código, testes, comunicações e registros de operação. Sua finalidade é esclarecer o que pode ser tecnicamente demonstrado sobre o projeto, suas falhas, seus limites, seus impactos e sua conformidade com o que foi contratado ou esperado.

Em contextos B2B, esse tipo de análise contribui para decisões mais informadas em litígios, arbitragens, negociações, auditorias, investigações internas e avaliações de responsabilidade técnica. O valor do trabalho está na combinação entre método, rastreabilidade, análise crítica e apresentação clara dos achados.

Imagem: iStock.com/NicoElNino