Estos dos son solo ejemplos como usted dijo. De hecho, todos los requisitos no funcionales de ese tipo pueden potencialmente entrar en conflicto entre sí. En el libro "Construyendo arquitecturas evolutivas" hay una tabla de aproximadamente un centenar de estas "-ilidades" (como también se las llama a menudo).
Es una especie de ejercicio para los arquitectos de software considerar el posible conflicto entre dos de estos. Básicamente, puede decidir cuáles de estos son importantes para sus proyectos y luego realizar un seguimiento de estos conflictos.
Para volver a su ejemplo preciso y echar un vistazo a la definición del término robustness
en Wikipedia:
En informática, la robustez es la capacidad de un sistema informático para hacer frente a errores durante la ejecución [1] [2] y hacer frente a entradas erróneas.
Como puede ver en la definición, la robustez implica errores . Por otro lado, desea tener la corrección, lo que básicamente significa la ausencia de errores.
Para hacer más aparente el conflicto, consideremos un campo de entrada simple. Desde el requisito de corrección, es más fácil rechazar cualquier entrada errónea realizada por el usuario. Pero la robustez requiere que pueda trabajar con esta entrada, lo que puede no ser del todo correcto.
Para llevarlo todo a su libro: ¿cuál es la compensación aceptable ahora? Supongamos que escribe una aplicación científica en la que el usuario puede ingresar una cantidad de voltaje, incluida la magnitud. Entonces las entradas correctas serían algo así como "10 kV" o "200 mV". Las compensaciones aceptables pueden incluir entradas permitidas como "10kV", "10kVolt", o incluso solo "10" y, en aras de la corrección, asigne estas a un valor de voltaje válido. Tenga en cuenta que esto sigue siendo una compensación y no una cosa de "lo mejor de ambos mundos". Considere mayúsculas y minúsculas: "10 kV" y "10 KV" pueden estar bien, pero "10 mV" y "10 MV" pueden no estarlo. La corrección se vuelve cuestionable ya que no estás seguro si es mili o mega ahora,