``Fetish requirement'' is my own term, grown from my own experiences in software development, specifically software engineering & programming. A definition of fetish requirements might be
fetish requirement n. In software development, a requirement which is not from the user's requirements, does not necessarily follow from the user's requirements, & isn't necessarily derivable from the user's requirements.
So much for the formal definition. It's decently accurate, but a better definition is
Fetish requirements: The way you want the developers who work for you to do it. You really, really, really want them to do it this way, & you're afraid that they won't because it's not the only way to do it (though it might be the best way).
It's that second definition, silly & cynical as it might be, that's important.
Let's say you are in charge of some developers. Maybe you are their development manager, their lead developer, or their architect. You dislike threads because you've so often seen developers create too many threads, all of them busy-waiting. You've seen it so many times that you practically hate threads, not because they are bad but because you have almost not faith in anyone else's ability to use threads without chewing up processor cycles in busy-wait loops. So you want to make sure your developers use just one thread & that they always do blocking waits. You tell them so. This is a fetish requirement.
You are a developer in charge of no one but yourself. Your architect thinks the C++ Standard Library is pretty damn cool for reasons you may or may not share. He tells you that all I/O in your program must be done with C++ iostreams even though there are no features of the program which definitely demand this (like linking with a third-party library that uses iostreams). This is a fetish requirement.
Some are, & some aren't.
Fetish requirements originate from personal preferences & prejudices. Those preferences & prejudices might have been born from experience, hype, or just a sense of how things should be done.
Fetish requirements derived from experience can be very beneficial. Hell, that's what experience is for, to tell us how things should or shouldn't be done. So fetish requirements that come from experience-and are applied to or filtered from the program at hand in an objective manner-are a good use of experience. I'd even say they might be some of the least costly benefits that can be applied to a project, especially considering that the experience might have been aquired at an entirely different company, years ago, & at that company's expense. So your current employer can take advantage of your experience, via the fetish requirements you give to the developers who work for you, at no cost to them. When used this way, fetish requirements are an example of good software engineering.
Some fetish requirements exist because someone read some news or hype & believed it. If the news was correct, maybe in what trends the future holds, these fetish requirements might be beneficial, but beware fetish requirements that come from hype (news that's incorrect or sensational). Think of all those people who bought Amazon.com at $ 390 (or whatever it got to) on hype. Yeah, that's what hype can do. Filter the hype from your news.
If you've been given some fetish requirements that come from hype, you have a problem. On the other hand, just because some fetish requirements don't make sense to you now doesn't mean they are from hype. Maybe the guy who gave them to you got them from good experience & is applying them objectively.
Remember that fetish requirements, good or bad, come from personal preferences & prejudices. The main danger of fetish requirements is in not recognizing them. They are connected to our emotional ideas (preferences & prejudices) of how things ought to be, so it's easy for them to miss our attention. They can creep into the demands we place on others without us realizing. They can go unstated until we see what others have produced & we say ``Icghbubbh! That's not what I want!''