Questi due sono solo esempi come hai detto. In effetti, tutti i requisiti non funzionali di quel tipo possono potenzialmente entrare in conflitto tra loro. Nel libro "Costruire architetture evolutive" c'è una tabella di circa un centinaio di queste "abilità" (come spesso vengono anche chiamate).
È una specie di esercizio per gli architetti del software considerare il potenziale conflitto tra due di questi. Puoi sostanzialmente decidere quali di questi sono importanti per i tuoi progetti, quindi tenere traccia di questi conflitti.
Per tornare al tuo esempio preciso e dare un'occhiata alla definizione del termine robustness
in Wikipedia:
Nell'informatica, la robustezza è la capacità di un sistema informatico di far fronte agli errori durante l'esecuzione [1] [2] e far fronte a input errati.
Come puoi vedere dalla definizione, la robustezza comporta errori . D'altra parte, vuoi avere la correttezza, il che significa sostanzialmente l'assenza di errori.
Per rendere più evidente il conflitto, consideriamo un semplice campo di input. Dal requisito di correttezza è più semplice rifiutare qualsiasi input errato fatto dall'utente. Ma la robustezza richiede di essere in grado di lavorare con questo input, che potrebbe non essere del tutto corretto.
Per portare tutto intorno al tuo libro: qual è il compromesso accettabile ora? Supponiamo che tu scriva un'applicazione scientifica in cui l'utente può inserire una quantità di tensione, compresa l'entità. Quindi gli input corretti sarebbero qualcosa come "10 kV" o "200 mV". I compromessi accettabili possono includere l'abilitazione di input come "10kV", "10kVolt" o anche solo "10" e, per motivi di correttezza, mapparli su un valore di tensione valido. Nota che questo è ancora un compromesso e non una cosa "migliore di entrambi i mondi". Considera maiuscole e minuscole: "10 kV" e "10 KV" potrebbero andare bene, ma "10 mV" e "10 MV" potrebbero non esserlo. La correttezza diventa discutibile poiché non sei sicuro che sia milli o mega ora,