Você precisa substituir um sistema legado e ninguém sabe como ele funciona. Como você aborda isso?

Reconstrua o comportamento a partir de três fontes: os dados que ele produz, as pessoas que o usam e o código ou a configuração, se alguém conseguir ler. Trabalhe de trás para frente a partir das saídas, porque as saídas são os requisitos que de fato importam. Espere regras não documentadas, registre cada uma que encontrar, e planeje um período de operação em paralelo para pegar as que você perdeu.

Eu trabalho de trás para frente a partir das saídas, porque o que ele produz é do que o negócio realmente depende, e a lógica interna só interessa onde ela muda uma saída. Então eu pego amostras de tudo que ele emite, relatórios, arquivos, interfaces, e rastreio de volta o que precisa ser verdade para cada uma. Em paralelo eu converso com quem usa aquilo há mais tempo e pergunto especificamente sobre os casos esquisitos, porque é ali que moram as regras escondidas. Se ainda tem alguém que consegue ler o código ou a configuração, essa é a terceira fonte e ela resolve disputas. Em uma substituição, a gente achou uma regra de arredondamento enterrada em uma stored procedure que ninguém vivo conhecia, e ela afetava cerca de um quinto das transações por um valor pequeno que o financeiro vinha conciliando manualmente havia anos. A coisa em que eu insisto é operação em paralelo, porque você nunca acha todas as regras, e a conciliação contra o sistema antigo é como você acha as que escaparam antes dos clientes.