Subjective Quality - Negative Quality Requirements?

Doing Pesach reminded me what subjective feature "quality" is. For those who don't know observant Jews basically use pretty much an entirely new set of kitchen equipment for 8 days every year during Passover. Just google it if you really want to know.

For the past few Pesach's we have used a dirt-cheap K-Mart special kitchen starter set for all our cooking needs, and a bunch of the most basic electric fry pans and blenders you can buy. And every year I love them. They do exactly what I need to do, do it with no fuss, and then I put them away for a year.

But if I were to use the same set all year I guarantee I would hate it, they have no fancy features, they feel cheap in my hand, the knives lose their edge every second tomato, and a host of other things.

But because my expectation were well managed, and they do the basic minimum well-enough for the price-point I am actually very satisfied.

The manufacturers compromised on some non-functional requirements to deliver the ones I care about.

So why don't we do this for NFR in our own docs? We spend so long talking about the ones that we want to be good - why don't we list the ones we really don't care about?

For example my kitchen set could have:
* Can fall apart after 6 months of normal use (That's 23 years of Pesach after all!)
* Can be ugly (8 days, who cares? We use disposable plates and cutlery for the table anyway)
* Does not need to be dishwasher safe (We don't use our dishwasher either, hence the plastic plates and cutlery)

These negative quality requirements are actually useful in designing a solution. The undifferentiated mass of positive quality requirements in most design docs are really only used to hold the delivery side to account (e.g. blame the vendor or IT) later on.

In a way it's a lot like "Scope" documents. Don't bother reading what's in-scope, whats out-of-scope is the important bit.