That's just one type of customer.

But I don't think you are every capable of seeing anything with someone elses eyes. That's just not possible for you.

There are more than one type of customers.

There are more than one type of products.

A lamp timer can be specified in measurable metrics. You can specify button press sequences. Size of display. Current consumption. Color. Shape. Materials.

But there are other products. How do you document the "feeling" that makes a customer select MP3 player A instead of MP3 player B? What makes a user select one car instead of another. Or one house instead of another?

A customer can't put metrics to such things, so in a number of situations, you need to help with simulations and prototypes (sometimes just mockups) to let them touch and feel. And you need to bring in the customer's customers. You really can't write in a requirements specification exactly what "feels comfortable", or what "feels wow".

The military, or the industry, doesn't care about "comfortable" or "wow". So they can write technical requirements specifications. But do try to realize that there are other products than that. How do someone order the development of a new tooth brush? By giving 50 pages of full specificatins? Hardly. If they had 50 pages of specifications, they wouldn't order any development. They would just ask the factory to produce. Somewhere they must involve industrial designers etc. And they need to try different strength and thickness of the fibres. And possibly different length. And possibly vary the parameters for the tip compared to other parts of the brush.

I don't think you have every really thought about the development process. You have only every thought about the narrow "engineering" situation where most of the development have already been done by the customer. You are just the hired hand that clues together a couple of components and slaps in a couple of thousand lines of code. No "invention" part in the work.

Have you never, ever, had a customer wanting you to try to produce multiple - different - solutions, for them to evaluate?

Whatever your customers may have supplied to you in requirements documentation, they are not representative of all situations. Some products can't just be fully specified before the development work starts - the specifications may actually be the majority work of the development process. That really should be obvious, if you spend some time and think about it.

But the thing is that you have, year in and year out, continued to only comment about the specific case where the customer can supply a full specificatin, similar to a machine shop being given complete blueprints that they just have to produce from. Why, just why, can't you see that that view can not be projected onto all development processes and that you obviously can not again, and again, tell people what failures they are if they do a development project without full specifications?