I much prefer the "The stakeholders are happy with the results of their investment" definition rather than tying quality to requirements.

My experience is that humans seem to be notoriously and consistently bad at producing 'requirements'. 'Good requirements' should completely define the thing to be delivered...but it seems that we are not so insightful or complete in our understanding of what is needed to be able to make it truely 'complete.' There always seems to be 'things forgotten' or 'things misunderstood' by the requirements producers.

Hence it seems to be all too frequently that things that exactly match requirements are still not what the stakeholder, as chromatic noted, wanted. Though I have seen too many stakeholders reluctantly/begrudgingly decide (often, it seems to be in the interest of keeping cost and schedule to a minimum) that they're happy enough to go ahead and accept the product. I'd be hard pressed to consider such an outcome as having delivered a 'quality product.'

The weak (in my opinion) linkage between 'quality' and 'requirements' is one of the reasons that my teams have so much trouble delivering satisfactory systems even though we've thoroughly tested that every single requirement is proven to work. So we've gone to broader testing to try to ensure that what we've come to call 'essential services' (which are end-to-end functional capabilities/services as defined/requested by the stakeholders...somewhat similar to Use Cases) are provided correctly and consistent with what the stakeholder expects. It is one of the key elements of our movement towards defining 'quality': a stakeholder-expectations-centric strategy.

ack Albuquerque, NM

In reply to Re^3: The dangers of perfection, and why you should stick with good enough by ack
in thread The dangers of perfection, and why you should stick with good enough by redhotpenguin

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.