Quantitative requirements are generally preferable, i.e. clear pass/fail.

However, in practice it can be easier said than done & incorrect quantitative requirements are themselves be problematic.

Of course you are correct.

If you are trying to design something to a specification that has unquantified requirements for you to meet you have two options available.

Ask for a quantified value from whoever wrote the spec.

Use your engineering judgement, assume a value, document your assumption and get on with things.

LPS for MintJulep. Often I think that's our role as engineers - we take qualitative requests and turn them into quantitative requirements. If you're extremely lucky, path 1 according to MintJulep will get you there. More often than not, the imprecise nature of the request actually contains more meaning than you might think. By specifying something is "infrequent", not only are you saying that it doesn't happen very often, but you're also saying that the actual occurrence rate is poorly defined. It's up to us as engineers to tease out the boundaries and negotiate a value. The negotiation is very important. Let me illustrate:

Customer: I want a toilet. I'll use it infrequently.
Unreasonable engineer: That's meaningless, how frequently are you going to use it?
C: Um, well, maybe once a day?
UE: Okay, I'll make it work once a day.
C: Can I still use it twice a day sometimes?
UE: Argh! Stop changing your mind! I have to change the requirements now and re-do the design!

Or...

Customer: I want a toilet. I'll use it infrequently.
Reasonable engineer: Okay, frequency of use is a low priority. I can please you in terms of water usage, and colour range, but it means I can only guarantee two operations a day. Based on some usage figures I found, that seems to meet the low range of frequency of usage metric. Would that suffice?
C: Hmm, well now given those options, I'm willing to give up the colour options if I can get four uses a day.
RE: Okay, no problems. Lets go with single colour, but maximum four operations a day.

No prizes for guessing which engineer I'd prefer to be seen as.

LiteYear,

I am getting your point which is interesting but let me make some further remarks to illustrate my concern.

Suppose the toilet has a flushing system with a sort of mechanism connected to a mechanical floater.
Suppose I ask to quantify how "often" utilization will occur?
The answer I get on paper is that frequency should be going to toilet between 1 to 4 times in a day ;
Real world situation: One user turned out to be extensive user and doubled usage with frequency of 8 times in a day.

Now assume two supposed locations for installing the toilet : A or B.

A is located in a desert / remote area where there is poor water availability to no water, so only water made available for flushing is obtained from a local reservoir of limited capacity which is automatically filled once in a day by the water distribution company.

B is located in a big city near shore where water is available 24/7 so no issues there.

It turns out that because the frequency of utilization has been under-estimated the consequences for each case are:

On location B consequence of over-utilization is that the mechanical system which incorporate a sort of floater will wear more rapidly, that means more costs and premature maintenance activity. To some extent operating costs could have been compensated by going for a sober design of less first costs (e.g. use only one color).

On location A however the system will simply not cope. Means that the 5th time in a day toilet is used, there is no water for flushing. Lets put the consequences in the register of "HSE-related issues" ; ultimately toilet is temporarily unavailable for hygienic reasons.

So my point here is that the requirement of quantification has also to do with the system that you deal with.

You might need to negotiate as you said but not always ; location A has shown a situation where system is simply not coping also affecting normal utilization.