Non conosco alcuna prova formale, ma ecco alcuni suggerimenti per risolvere il tuo vero problema. Stai pensando a questo troppo come un programmatore. Non prendere letteralmente "ogni possibile situazione di errore", quando tutti sappiamo che non è possibile documentare cose di cui non si è a conoscenza. Nella tua mente sembra che stiano richiedendo un documento perfetto. Sia che ci sia una prova definitiva o meno, hai già concluso che è impossibile in questa situazione.
Qualcuno deve avere una discussione su ciò che realmente chiedono e su cosa è in grado di creare e arrivare ad un accordo.
Anche se un codice base non cambia, ci sono applicazioni in cui gli utenti adattano le funzionalità facendo cose che i progettisti non hanno mai immaginato. Sarà difficile per un sacco di personale di supporto pensare a diversi modi in cui l'app può essere utilizzata e come supportarla. Esempio: ho lavorato come responsabile del supporto per una società di software per la fatturazione dell'acqua e un cliente ha chiesto a uno dei nostri dipendenti del personale di supporto iniziale se potevano fatturare la spazzatura. Era un prezzo forfettario e la nostra app aveva la possibilità di personalizzare l'etichetta su ogni tariffa. Nella mia mente era ovvio, chiamarlo flat-fee come vuoi.
La tua documentazione potrebbe dover adattare un approccio un po 'agile per tenerlo aggiornato. Forse questo potrebbe essere sotto forma di wiki o qualche altro tipo di sito web che puoi mantenere e aggiornare frequentemente. Certo, vogliono che tutto sia scritto in anticipo e perfetto, ma non succederà. Dovrai apportare correzioni e aggiunte e questa sarà una tassa continua che stanno cercando di evitare. Chiedi al cliente con quale frequenza sono in grado di leggere le istruzioni per qualsiasi cosa e di comprenderlo appieno? Il software è molto più complicato rispetto alla creazione di una libreria.