Reading "Code Complete 2" in a Quality of Requirements paragraph I found this:

Are acceptable trade-offs between competing attributes specified — for example, between robustness and correctness?

(this above is a point of a large checkbox list in order to check the quality of the requirements)

So, I found a lot of definitions of Robustness and Correctness, in the web, academic books, etc..

e.g. :

In the "Object Oriented Software Construction, 2nd Edition, Bertrand Meyer, Prentice-Hall, 1997" book:

  • Correctness: The degree to which a system is free from [defects] in its specification, design, and implementation.
  • Robustness: The degree to which a system continues to function in the presence of invalid inputs or stressful environmental conditions.

Despite this, it's not clear why and in which situations these two might be in conflict.

My question is: why are these two attributes in competition?

  • 11
    Different books give different definitions to these terms. (Typically, books written for ordinary programmers do not use the same definitions as academic publications.) Perhaps you can take a look at how this book defines them, if ever. (Sometimes these terms are used by books without any definition.)
    – rwong
    Commented Mar 7, 2018 at 8:26
  • I'm not aware of any definition of "robust" other than "handles all sorts of unexpected inputs gracefully" (in addition to the functionally required inputs).
    – Kaz
    Commented Mar 8, 2018 at 1:12
  • I have edited my question trying to be as clear as possible so that it can be reopened.
    – overcomer
    Commented Mar 22, 2018 at 10:10

3 Answers 3


There are many situations in which these two might be in conflict. For instance, robustness can involve resilience under heavy load. If an approximate (i.e., incorrect) response to a request can be computed much faster than an exact (correct) response, it's important to know whether the system should deliver an approximate result, or fail delivering altogether.


These two are just examples as you said. In fact, all non-functional requirments of that sort can potentially conflict with each other. In the book "Building Evolutionary Architectures" there is a table of roughly a hundred of these "-ilities" (as they are also often called).

It is sort of an exercise for software architects to consider the potential conflict between any two of these. You can basically decide on which of these are important to your projects, then keep track of these conflicts.

To get back to your precise example and take a look at the definition of the term robustness in Wikipedia:

In computer science, robustness is the ability of a computer system to cope with errors during execution[1][2] and cope with erroneous input.

As you can see from the definition, robustness involves errors. On the other hand, you want to have correctness, which basically means the absence of errors.

To make the conflict more apparent, let's consider a simple input field. From the correctness requirement it's easiest for any erroneous input made by the user to be rejected. But robustness requires you to be able to work with this input, which may not be entirely correct.

To bring it all around to your book: what is the acceptable trade-off now? Let's say you write a scientific application in which the user can input a voltage amount, including the magnitude. So correct inputs would be something like "10 kV" or "200 mV". Acceptable trade-offs may include allowing inputs like "10kV", "10kVolt", or even just "10" and for the sake of correctness map these to a valid voltage value. Note that this is still a trade-off and not a "best-of-both-worlds" thing. Consider upper-case vs lower-case: "10 kV" and "10 KV" might be fine, but "10 mV" and "10 MV" may not be. Correctness becomes questionable as you are not sure if it's milli or mega now, but if you insist on the right upper/lower-casing you lose out on robustness again, because some erroneous inputs won't work.


A practical example is XHTML vs. HTML.

  • Browsers (in strict mode) reject XHTML that has syntax errors. This ensures that incorrect results are not displayed to the user, and aids in finding the errors.
  • Browsers attempt to continue parsing HTML code even if it has very obvious problems. This often lets the user view the page, even if the contents are mangled a bit.

Thus XHTML aims for correctness, while HTML aims for robustness. Currently HTML seems more popular, but both sides have good arguments.

Not the answer you're looking for? Browse other questions tagged or ask your own question.