Come spiegare a un fornitore che quando dati errati vengono cancellati / disattivati lo stato futuro dell'applicazione dovrebbe essere come se i dati non fossero mai stati inseriti?

Strettamente, questa è in realtà colpa tua. Se il meccanismo da utilizzare qui per annullare le modifiche è "L'utente scrive manualmente nel database", è responsabilità dell'utente assicurarsi che, si scriva sul database ciò che si desidera.

Anche se consentire all'utente di scrivere direttamente nel database in questo modo è un progetto terribile, non esiste una regola che dice che non può essere consentito in ogni caso.

È davvero una questione su cosa hanno detto le specifiche concordate. Se non includesse una funzione di annullamento, il venditore ha i diritti per non offrire una funzione di annullamento corretta. Se hai bisogno di una funzione di annullamento, dovrebbe essere nella specifica. Se le specifiche includevano una funzione di annullamento, sei perfettamente in diritto di dire al venditore che in realtà dovrebbe annullare.

In senso stretto un bug si verifica quando il comportamento del programma differisce dalle specifiche.

Anche se il comportamento non funziona come ci si aspetterebbe, anche se è giustificato che tu pensi che il tuo caso sia, in realtà stai discutendo sul cambiamento delle specifiche. Che da un punto di vista commerciale è completamente diverso dall'identificazione di un bug.

Altri clienti che utilizzano l'applicazione possono essere utilizzati per questo comportamento e pensano che sia un bug se cambia.

Il comportamento potrebbe essere stato lasciato in questo modo perché un annullamento completo era considerato al di fuori dell'ambito, troppo costoso o dispendioso in termini di tempo per l'implementazione.

Alla fine della giornata lo sviluppo del software è caratterizzato da compromessi sia nelle specifiche che nell'implementazione e nella "crescita organica" di caratteristiche che finiscono per produrre un comportamento che non è sempre l'ideale.

Se vuoi che questo comportamento cambi, devi giustificare il costo di effettuare la modifica. Le discussioni accademiche su "ciò che è giusto" non lo taglieranno

Il problema più grande qui è che stanno essenzialmente usando quella riga nella tabella come variabile globale. Lo stato globale utilizzato dal resto dell'applicazione è generalmente disapprovato.

Ciò che è anche confuso è l'idea che il tuo staff "scrive su questo tavolo". Gli utenti non dovrebbero scrivere direttamente dati su una tabella. Le scritture dovrebbero attraversare una sorta di livello di logica aziendale e BLL è responsabile di intraprendere altre azioni. Il fatto che un utente possa semplicemente cancellare una riga in una tabella di database e che l'applicazione dovrebbe recuperare è ... strano .

Ciò che manca a questa cosa è un meccanismo di "annullamento". Se vuoi la possibilità di annullare l'inserimento di dati errati, devi ricordare uno "stack di annullamento" dei valori precedenti.

Tuttavia, rompere i modelli non significa necessariamente che la tua applicazione abbia un bug. Se l'applicazione soddisfa tutti i requisiti delle specifiche funzionali (alcuni dei quali sono probabilmente impliciti), allora non ha un bug, non importa come sia programmato. Non cercare una violazione del pattern: cerca una violazione delle specifiche funzionali.

Quando acquisti un sistema chiavi in mano, deve funzionare secondo il manuale. Se è possibile dimostrare che il comportamento è contrario a una dichiarazione nel manuale, si può fare un caso in cui vi è un bug o un'inesattezza nel manuale. Se il manuale non è chiaro sulla funzionalità, in alcuni casi, hai una certa leva per fare una richiesta ... Ma potrebbe comunque non esserci un bug.