Adaptation based on Tom Gilb's list

This is a slightly adapted/interpreted version of Tom Gilb's list at the end of chapter 4 from his book "Competitive Engineering".

Gilb uses the term "Performance Requirements" for what we call Quality Requirements. I find his term ambiguous when talking about software systems since we typically talk about the performance of a piece of software as being a more specific thing and not including all qualities.

Gilb also uses slightly different tag names than what has been proposed in other literature on PLanguage. His "survival" is Intel's "must" and so on. I have added Intel's tags in parentheses.

Principles for Quality Requirements

  1. Bad numbers beat good words - Poor quantification is more useful than no quantification; at least it can be improved systematically.
  2. Performance quantification - All quality attributes can be expressed quantitatively, "qualitative" does not mean unquantifiable.
  3. Threats are measurable - If the lack of a quality attribute can destroy your project, then you can measure it some time; the only issue is "how early?".
  4. Put up or Shut up - There is no point in demanding a quality requirement, if you cannot pay or wait for it.
  5. Deadline or die - There is no point in demanding a quality requirement, if you would always give priority to something else, for example, a deadline.
  6. Dream, but don't hold your breath - There is no point in demanding a quality requirement, if it is outside the state of your art.
  7. Benchmarks and targets - Numeric past "history" levels and numeric future requirement levels together complete the quality requirement definition of relative terms like "improved".
  8. Scalar priority - In practice, the first priority will be survival (must), the second priority will be avoiding failure (fail), the third priority will be success (plan), and the required levels for all of these will be constantly changing.
  9. Many-splendored things - Most quality ideas are usefully described by several measures of goodness.
  10. Limits to detail - There is a practical limit to the number of facets of quality you can define and control. It is far less than the number of facets that you can imagine to be relevant. (Try a limit of just the top ten!)