Sir you are damned naive. We have no money for shit like reason and qa. potentially shippable product will be shipped as soon as it compiles and sometimes even without fulfilling this requirement. Actually in a project I work for we reached release and discuss happily faults on a fault list while a customer on which our industrial application got installed for testing gave us another very short but not empty list with faults that it sees as a show stoppers. The lists do not overlap on any single point. Which of the lists would you start discussing at the release meeting? Yes bravo - the ones on the little problems list. I actually had some designers denying that the customer list existed, that the faults on the list existed and one stubborn guy claimed that the problems on the list have been fixed albeit question about how that was verified was left without answer. The funny thing is - 2 of these faults I have seen before even the preliminary software version our customer got was packaged. Now you say this is anecdotal and has no bearing on wider production practice - I dare to differ on that based on experience I had over last 10y.
I agree with you at least as far as to say that if need be such considerations have to be made at some point during development. Often enough they are not because people live their fantasy of craftsmanship or being an artisan doing some fancy stuff where hard rules of reality do not apply.
In other words: there are no requirements in the jungle. There is only you and your agile team in search of holy Grail of software development practice (BTW: I think agile manifesto is actually nicely organized set of principles of what is important but none of the agilists I worked for over the years, did actually read it).
